[00:00] <crashsystems> https://bugs.edge.launchpad.net/ubuntu/+source/totem/+bug/180457/comments/7
[00:01] <andersk> Where should I direct requests to rebuild packages for the python 2.6 transition, such as bug 338022 and bug 338024?
[00:02] <crashsystems> Also, I do believe that a bug I reported earlier today is related to Python 2.6 breakage. #337863
[00:03] <crashsystems> since ubottu did not seem to like that, the link is https://bugs.edge.launchpad.net/ubuntu/+source/pywebkitgtk/+bug/337863
[00:28] <geser> crashsystems: it's being worked to transition pywebkitgtk to python2.6
[00:28] <crashsystems> ok, cool
[00:29] <andersk> Wow, 338024 was fixed 22 minutes after I reported it!  How can I make that happen to bug 338022?  :-)
[00:31] <geser> andersk: give me some minutes :)
[00:33] <andol> geser: How do you want those minutes transfered? :-)
[01:00] <andersk> geser: So there are over 200 packages that have a broken dependency on python < 2.6.  Are these going to be automatically rebuilt eventually, or do bugs need to be filed on all of them?
[01:00] <andersk> aptitude search '~S~VCANDIDATE~DB^python$'
[01:01] <crashsystems> I thought there was going to be an automatic rebuild
[01:01] <james_w> andersk: we don't need bugs for them all
[01:01] <james_w> "automatic" in the sense of "manual", yes
[01:01] <james_w> perhaps scripted for some
[01:01] <geser> andersk: if "automatically" == "a developer looks at them" then hopefully yes, we are aware of the breakage caused by the python 2.6 transition and working on fixing it
[01:02] <geser> but as you mentioned there are still over 200 packages left so it will take some time
[01:02] <andersk> Okay, great.
[01:02] <geser> once this batch is done the packages depending on python2.5 are next
[01:02] <crashsystems> are there any plans for Python 3.0, perhaps in 9.10?
[01:03] <james_w> heh
[01:03] <james_w> it is in 9.04
[01:03] <crashsystems> 9.10 + 3?
[01:03] <james_w> it's never really going to be default as such though
[01:03] <geser> crashsystems: that will be an even bigger transition
[01:04] <james_w> it will be more a sense of removing python 2
[01:40] <vbgunz> can someone help me troubleshoot a suspend to disk failure? not sure wheres its screwing up bad at but one thing for sure, it doesn't work :(
[02:47] <andresmujica> hmm an old bug that was solved by dapper, was reintroduced again sometime ago.. it seems that the patch never made it to debian and with some resync it appeared again.. should i open a new bug or reopen the original one??
[02:51] <maco> andresmujica: id reopen the old one. i recall someone saying that a bug going from "fix released" to open again was something to worry about because it's a regression
[02:52] <maco> was it reintroduced in intrepid or jaunty? if intrepid, tag regression-release and if jaunty regression-potential ...i think
[02:52] <andresmujica> that's the problem it seem it was somewhere around hardy...
[02:53] <andresmujica> i'll reopen the old one, lucky me that pitti was the one who solved before.. so i hope it solves it again :=)
[03:00] <andresmujica> asac, aut?
[03:02] <andresmujica> asac: can you help me with bug #317860 i tried with Wellark without luck, but maybe you can help me.. all the bugs include the corresponding patch..
[03:03] <andresmujica> it would be great if those patches can be uploaded so Jaunty gets an almost complete 3g provider db
[03:25] <Laibsch> I just opened bug 338079 which describes a major problem we seem to be having in going for python 2.6 in Jaunty
[03:26] <Laibsch> a number of packages depend on python-4suite packages
[03:26] <Laibsch> but python-4suite seems to not build with 2.6 and it is not clear if anybody is willing to fix it
[03:27] <andresmujica> you must tag it like python-2-6
[03:27] <andresmujica> and subscribe the python team
[03:28] <andresmujica> and probably would be better to look for the metabug..
[03:28] <andresmujica> don't know if it exist or not.. but that bug is already reported -several times-
[03:51] <Laibsch> certainly not for python-4suite-xml
[03:51] <Laibsch> That package has only 2 bugs
[03:51] <Laibsch> if you know what needs to be changed to put it on the radar, maybe you can make the changes?
[03:52] <Laibsch> I guess that makes more sense than me doing it, I did what I thought was appropriate
[06:40] <YoBoY> good morning
[12:58] <pedro_> Hey folks, today is hug day and there's still a good quantity of bugs waiting to be triaged, feel free to grab any of them https://wiki.ubuntu.com/UbuntuBugDay/20090305
[14:26] <YoBoY> someone on 8.04 can see if the bug 239426 is reproductible?
[15:08] <bddebian> Boo
[16:40] <bliq> hello, anybody ?   I am here for the first time and I have a bug related question
[16:41] <charlie-tca> !anybody
[16:41] <savvas> bliq: just ask, someone will reply :)
[16:41] <bliq> ok
[16:43] <bliq> It is a quite long time, that I filled a bug https://bugs.launchpad.net/bugs/326667  and nobody seems to care  ... i even wrote the 'possible' solution ...
[16:44] <bliq> i hoped it gets fixed to jaunty , but this way not even in koala
[16:45] <YoBoY> bliq: have you tried with the last Alpha ?
[16:48] <bliq> well, I submitted in alpha 3 (if i do remember)  , then changed on my machine because i wanted this funcionality. I do not know how to 'get what is currently in alpha' ...should i delete the file and reinstall acpid package ?
[16:50] <YoBoY> what is your actual version?
[16:50] <bliq> current jaunty, i update almost everyday
[16:50] <bliq> kubuntu
[17:30] <jgoguen> I've got 3 bugs all about empty windows appearing when using flashplugin-nonfree. Bug 225197 was first but has the least done, bug 226471 has some work done but nothing beyond triaging and confirming that it works after reinstall of flashplugin-nonfree, and bug 262693 is where it seems most of the work was done.  Would it be correct to mark the first two bugs duplicates of the third in this case?
[17:34] <pedro_> jgoguen: second one seems to be the same as the last one and solved by the same way, feel free to mark it as dup, but i'm not sure about the first one
[17:35] <pedro_> jgoguen: ah you already asked for confirmation there, nice, i was about to tell you that ;-)
[17:35] <pedro_> jgoguen: great work on the hug day btw ;-)
[17:35]  * pedro_ hugs jgoguen
[17:35] <jgoguen> pedro_: thanks :)
[18:24] <mcas> hi
[18:24] <mcas> bug #337490
[18:25] <mcas> i think this bug has to be closed because the package is from a ppa
[18:25] <mcas> i am right?
[18:26] <charlie-tca> I don't think so. PPA's are often given out for testing
[18:26] <charlie-tca> It tells developers if the bug is fixed before the package is released
[18:26] <mcas> but it is not a official repo
[18:27] <charlie-tca> Often, the devel will tell a reporter to check a package in a PPA and report a new bug against any issues
[18:29] <charlie-tca> I'm looking for people to report against Xfce 4.6 from https://launchpad.net/~jerome-guelfucci/+archive/ppa
[18:29] <Awsoonn> before I report a but, is there any known issues with apport?
[18:29] <charlie-tca> and the bugs will be reported upstream!
[18:29] <bdmurray> But a ppa is not an "Ubuntu" package, actually I don't think apport should (it might be fixed now) allow these to be reported.
[18:29] <charlie-tca> I agree. Apport should not allow them.
[18:30] <charlie-tca> I have asked to be subscribed to the bugs against that ppa
[18:30] <bdmurray> It might be fixed in Jaunty, I'll have a look.
[18:30] <charlie-tca> so I can handle them
[18:30] <charlie-tca> But, the fact it is a PPA should not invalidate the bug
[18:31] <bdmurray> However, the bug doesn't belong about Ubuntu necessarily.
[18:32] <charlie-tca> No, it should be against the PPA package, shouldn't it?
[18:32] <bdmurray> Perhaps but that capacity doesn't exist afaik.
[18:32] <charlie-tca> Although, I don't know the reporter would necessarily know to add the package, either
[18:36] <bdmurray> charlie-tca: there is no other place for it though
[18:37] <Awsoonn> I thought I saw something on the planet recently about some newfangled suspend/resume automated testing script, Anyone have a link to that article?
[18:37] <charlie-tca> Perhaps asking for more information, like "did someone ask you to use the PPA" or a way to tag it back to the ppa is needed
[18:38] <charlie-tca> I would hope that whoever put the thing in PPA would be looking for some kind of feedback?
[18:39] <charlie-tca> bdmurray: what is the right answer?
[18:41] <bdmurray> charlie-tca: I don't think there is a right answer yet
[18:54] <bdmurray> Well, leaving the bug open seems like the right thing however maybe it should be tagged ppa or identified in another way as applying to a ppa package.
[19:05] <charlie-tca> Thank you. That's all I ask for
[19:30] <maxb> charlie-tca: Surely that bug should be invalidated. It's not a bug in ubuntu.
 Well, leaving the bug open seems like the right thing however maybe it should be tagged ppa or identified in another way as applying to a ppa package.
[19:31] <charlie-tca> Just because it is a ppa is not reason to close it
[19:32] <maxb> Well, it's a reason to close the bugtask relating to Ubuntu itself
[19:32] <charlie-tca> what package are you going to change it too?
[19:33] <maxb> There'd need to be a launchpad project/distro record for the PPA
[19:33] <bdmurray> maxb: part of the reaseon for keeping it open is that there's nowhere else for it to go and invalidating it would make it harder to find
[19:33] <charlie-tca> and which reporters will know to open it and how to do it?
[19:34] <maxb> But is there any action that needs to be taken in Ubuntu relating to this bug?
[19:35] <bdmurray> No there isn't
[19:35] <maxb> Then isn't leaving it open just as wrong as filing a bug about a ppa packaging in the project's upstream bugtracker?
[19:37] <charlie-tca> That is not necessarily wrong either. For Xfce 4.6 in the ppa, we will be filing the bugs upstream
[19:38] <maxb> Yes, but not concerning bugs relating to the debianization, surely?
[19:38] <charlie-tca> I won't be.
[19:38] <bdmurray> I agree that the bug report doesn't belong against Ubuntu but there is nowhere else for it to go.  So I think keeping open but identifying it is the less of two bad things.
[19:39] <charlie-tca> Why must every open bug have to be closed, incomplete, or other action? Maybe it is okay to leave it openj
[19:39] <mr_pouit> Xfce 4.6 packages from jeromeg's ppa are backports from the jaunty ones, so if there is a packaging bug, it'll be present on jaunty as well...
[19:39] <charlie-tca> But if the ppa bug is closed before we get to it, it is much more work
[19:40] <maxb> bdmurray:  I disagree strongly. That's like filing a bug on arbitrary packaging flaws in third party packagings in an upstream's bugtracker. upstream would be rightly annoyed.
[19:41] <bdmurray> I think this would be a useful discussion to have with a wider audience perhaps on the bugsquad or devel-discuss mailing list.  There is no clear policy on what to do about PPA bug reports and there should be.
[19:42] <charlie-tca> I'll start that later today, then.
[19:42] <bdmurray> charlie-tca: great, thanks!
[19:42] <charlie-tca> np, I just don't want a valid bug invalidated just for being ppa
[19:43] <bdmurray> well, the might bug might very well not affect the Ubuntu version of the package
[19:43] <bdmurray> There are arguements both ways
[19:43] <charlie-tca> correct. If it is invalid, it should be closed
[19:44] <charlie-tca> bbl
[20:23] <BrunoXLambert> hello
[20:52] <ripps> Does anybody know if it's possible to add my PPA key to pbuilder? I sometimes use my ppa to store packages development packages that aren't in Jaunty.
[20:54] <maxb> ripps: Yes, it's entirely possible.
[20:55] <ripps> maxb: any clue how to do it?
[20:55] <ripps> I already have my PPA setup as OTHERMIRROR, so I need is pbuilder to have the key.
[20:56] <maxb> Well, you've got two options, either add the key persistently to your basetgz, or reinject it every build via a pbuilder hook script.
[20:56] <hggdh> (late, but anyways) PPA bugs should be accepted, as long as it is clear the bug will be worked on by the PPA responsible party
[20:57] <maxb> Actually OTHERMIRROR gets saved into the basetgz sources.list anyway, so I'd just do something like
[20:57] <maxb> sudo pbuilder execute --save-after-execute "apt-key adv --keyserver keyserver.ubuntu.com --recy-key HEXKEYID"
[20:57] <maxb> *recv-key
[20:59] <ripps> maxb: do I put --overide-config after that? or is there some way to add that to my .pbuilderrc?
[20:59] <maxb> IIUC --override-config is only relevant to "update"
[21:00] <maxb> It basically means "redo some of the configuration file creation that happens during a create" (AFAIK)
[21:00] <maxb> If you wanted the key automatically added to newly created basetgz-es, you would need to do it via a pbuilder hook
[21:01] <ripps> maxb: Error: Unknown option [--save-after-execute] was specified
[21:02] <maxb> To do that you'd put something like HOOKDIR=$HOME/.pbuilderhooks in your .pbuilderrc, create the directory and create (I think) a G hook
[21:02] <maxb> oh, apparently it's just --save-after-exec
[21:03] <ripps> Command line parameter [apt-key adv --keyserver keyserver.ubuntu.com --recv-key ######] does not exist  (I  hid the hexkey)
[21:04] <maxb> ripps: You realize that HEXKEYID is supposed to be the public one, yes?
[21:04] <maxb> :-)
[21:04] <ripps> does it matter?
[21:04] <ripps> Command line parameter [apt-key adv --keyserver keyserver.ubuntu.com --recv-key EEB23232] does not exist
[21:04] <maxb> So hiding it's pointless
[21:05] <maxb> oh, whoops, I've misunderstood what execute does. It runs a script, not a command.
[21:06] <maxb> So either you'd have to put the apt-key command in a minimal shell-script, or "sudo pbuilder login --save-after-login" and type the apt-key command inside the session
[21:07] <ripps> what exactly does pbuilderrc do? is it a script that is run within the pbuilder environment?
[21:08] <maxb> No, it's a config file for pbuilder
[21:09] <ripps> so, there's no way for pbuilder to run the apt-key command, by adding something to my .pbuilderrc
[21:10] <ripps> I just ran the apt-key command using pbuilder login method, we'll see if that works now.
[21:10] <ripps> Will I have to do this everytime I decide to wipe and renew my pbuilder base?
[21:11] <maxb> Of course - all you just did was within your pbuilder base, after all
[21:11] <maxb> I did mention the option of defining a hookdir and adding a hook
[21:11] <ripps> sound kinda complicated, and I don't even understand what hooks are. So this will have to work for now.
[21:13] <ripps> I'm going to read up on hooks in the pbuilder wiki, and see if I can use it.
[21:22] <ripps> Okay, I understand what hooks are, there scripts that run in the pbuilder environment. I've made a script to install apt keys, but I'm not sure what to name it so that it executes at the correct time.
[21:30] <maxb> ripps: When do you want it to run? At "pbuilder create"? That's a G hook.
[21:30] <maxb> Or just before every build? That's a D hook
[21:30] <ripps> hmm.. since I already have the key in the environment, I guess on create, for when I remake the enviroment.
[21:31] <ripps> So... G90aptkey
[21:33] <ripps> I've been reading up on using pbuider with COW to speed up startup, how do I implement that with the pdebuild command?
[21:34] <maxb> I just have PDEBUILD_PBUILDER=cowbuilder in my .pbuilderrc
[21:35]  * maxb afk
[21:38] <ripps> cool, thanks


[02:03] <jbicha> the autoimporter from sid appears to have got stuck yesterday around https://launchpad.net/debian/+source/gnome-settings-daemon 3.22.2-3
[04:29] <elopio> Trevinho: it is. Sorry, super late reply. Go to http://ubuntuonair.com, it's still there.
[04:30] <elopio> Trevinho: our most watched video so far. Thanks!
[10:11] <jbicha> cjwatson: just making you saw my earlier comment about the autoimporter from sid getting stuck
[10:11] <jbicha> let me know if there's someone else I should ping
[10:25] <cjwatson> jbicha: William fixed that earlier; next run should work
[10:29] <jbicha> thanks! maybe I'll ping him next time then :)
[10:45] <Trevinho> elopio: yay :)
[14:17] <coreycb> hello sru team, i have a few small libvirt uploads that I could use a review for if someone has a moment.  this is for bug 1644507.
[14:52] <cpaelzer> coreycb: I'll look at the change in general
[14:53] <cpaelzer> coreycb: if possible in the future at least ping smb or me so we can make it part of the git as well
[14:53] <cpaelzer> since libvirt is packaged via a git repo
[14:53] <cpaelzer> otherwise things get lost too easily in e.g. a merge
[14:54] <coreycb> cpaelzer: ah yeah will do, i know that is a pita.  i meant to look into that but forgot.
[14:54] <cpaelzer> also the new "policy" is to try to upstream apparmor changes :-)
[14:54] <cpaelzer> more pita but the only way to stop growing infinitely
[14:55] <cpaelzer> I'll make the change also part of the continuous upstremaing efforts
[14:55] <cpaelzer> might reference to you for discussion at some point in the future
[14:55] <cpaelzer> coreycb: ^^
[14:56] <coreycb> cpaelzer: ok thanks
[14:59] <seb128> slangasek, hey, did you have any chance to look at that nplan autopkgtest/n-m/mtu issue?
[15:03] <cpaelzer> coreycb: hmm isnt't that failing for snapshots?
[15:03] <cpaelzer> coreycb: old rules for base  .../_base/**
[15:04] <cpaelzer> old rules for snapshots .../snapshots/**
[15:04] <coreycb> cpaelzer: maybe. we've only done basic deploy an instance testing.
[15:04] <cpaelzer> and you add .../snap/nova-hipervisor/ in the path for base
[15:04] <cpaelzer> I'm pretty sure it will need snapshots as well
[15:04] <coreycb> cpaelzer: ok. i'll take a look.
[15:04] <coreycb> cpaelzer: thanks
[15:06] <cpaelzer> coreycb: do you mind if for now I carry it as http://paste.ubuntu.com/25025524/ ?
[15:07] <cpaelzer> and take you as the author still
[15:15] <cpaelzer> nacc: dpb1: will you be aroudn for the stanup?
[15:15] <cpaelzer> +d
[15:15] <dpb1> cpaelzer: yes
[15:15] <coreycb> cpaelzer: sure np, i'll test that out today
[15:15] <coreycb> cpaelzer: and will get back to you
[15:15] <cpaelzer> coreycb: ok, I already added it to the coming merge for artful that way
[15:15] <cpaelzer> coreycb: so let me know what/if needs to be modified
[15:22] <slangasek> seb128: I have been looking, but have struggled to set up a proper reproducer environment; when I run the autopkgtests in a VM, the tests wind up clobbering the network config and then failing in unrelated ways.  Have you had better results?
[15:24] <seb128> slangasek, no, I struggled as way  with the env and since cyphermox_ seems to have a better handle on how to test that I let it to him and stopped trying
[15:25] <seb128> slangasek, I guess at this point we could wait for him to be back (but unsure how high it's going to be in his backlog/priority list then)
[15:26] <slangasek> seb128: ok. I'll spend some more time on it today, and if I can't figure it out it'll wait for cyphermox_.  I think unblocking the desktop team's work and keeping p-m functioning correctly should be fairly high up the priority list
[15:26] <seb128> slangasek, thanks
[17:02] <rbasak> Bug 1693850: will adding -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 cause any ABI break or similar?
[17:26] <juliank> slangasek: You're right, it seems we never really documented dir::etc::netrc somewhere - the path is /etc/apt/auth.conf
[17:26] <juliank> that's not god
[17:26] <juliank> s/god/good/
[17:26] <slangasek> juliank: :)
[17:27] <slangasek> it certainly seems like a good change, it just doesn't help us much if it's undocumented :-)
[17:28] <juliank> slangasek: We have this since 2009, and nobody mentioned that before :)
[17:29] <juliank> Despite us telling people since about 5 years or so to please use it instead of non-world-readable sources.list files, so that's a bit strange
[17:29] <juliank> Should add that to sources.list(5) and apt.conf(5)
[17:38] <juliank> slangasek: the request for that is in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811181
[17:40] <slangasek> juliank: awesome, thanks :)
[17:41] <juliank> I gotta learn this snapcraft stuff.
[17:41]  * juliank wants to build an apt snap just to be weird
[19:47] <clivejo> anyone having issues with networking on Artful?
[19:49] <clivejo> my DNS just seems to keep dying :/
[20:25] <jbicha> clivejo: if you have dnsmasq or dnsmasq-base installed, I would uninstall them


[03:04] <Sarvatt> one day i'll learn mesa master builds are broken after 7.7 branch merges almost every time... always end up packaging mesa right after it happens
[03:10] <bryyce> Sarvatt, heya
[03:16] <Sarvatt> might be a good time to update ati soon, quite alot of bug fixes in the past 2 months on master like signifigant speedups for r600 2D, low memory EXA fixes (and fixing NoAccel to work with KMS), a ton of dpms/incorrect resolution fixes, and a fix for a VT problem I've seen people having
[03:16] <Sarvatt> heyo bryyce
[03:17] <bryyce> update just the -ati ddx ?
[03:17] <Sarvatt> had a question for ya, with this new archive restructuring thing, is X going to have a team or is it going to be part of desktop (or core-dev still)?
[03:17] <Sarvatt> yeah
[03:18] <bryyce> ok I'll todo getting -ati updated either this week or next
[03:18] <bryyce> (next week is the developer sprint so I may not get much done)
[03:18] <bryyce> re: restructuring
[03:19] <bryyce> well there's certainly advantages either way
[03:19] <bryyce> I think I'd like to see Ubuntu-X be its own team  separate from the desktop
[03:19] <Sarvatt> noone really wants to work on X stuff, really strange
[03:19] <bryyce> heh
[03:20] <bryyce> Sarvatt, I don't know, I guess I don't have a strong feel either way.  What do you think?
[03:21] <bryyce> it seems like "X stuff" is distinct enough from "Gtk application stuff" that it splits off easily
[03:21] <bryyce> on the other hand, if having it be two teams means that there's an extra barrier of entry to people who might get involved, that'd be bad...
[03:23] <bryyce> I suppose the thing to look at would be if the desktop team is set up to include both gnome and kde; if not, and if there are separate teams for each, then having X be a separate team may make sense
[03:24] <bryyce> if gnome and kde are both included in the desktop team, then there's less reason to have X separate
[03:24] <Sarvatt> probably not enough people to even make it worth splitting off, I was just reading the ubuntu-motu logs earlier and was confused where X packages would fall with the new changes since one day down the line when I have enough experience with it i'd be interested in helping out there and dont know which team or whatever I should look into joining. have to dig up the wiki pages again, was reading on my phone :)
[03:27] <Sarvatt> like is there still going to be a core-dev team and the desktop team has a subset of upload permissions of that? I'm not really interested in stuff outside of X components so I've been on the fence about MOTU and it seems like thats dissolving or something
[03:30]  * bryyce nods
[03:31] <bryyce> that's another reason favoring a stand-alone X team... there may be people who are *only* interested in X, and joining the full Desktop team just to get access to X stuff might seem a bit too broad for them
[03:57] <Sarvatt> oh nice, didn't know -ati disabled EXA pixmaps for cards with <=32MB vram under KMS now, that should fix up those problem cards that needed XAA under UMS back in the day now that KMS is on by default
[04:03] <Sarvatt> wonder why they didnt branch intel 2.10, post 2.10 is in even worse state right now than 2.10 was for me, compositing is all messed up here
[04:12] <superm1> bryyce, does that mean you're gonna hire more people to work on X? =]
[04:27] <bryyce> superm1, you can bet on it
[04:27] <superm1> that's great! you can never have too much love hacking on X stuff
[05:21] <Sarvatt> yay for blindly reverting random batchbuffer related commits in -intel 2.10 around when it started to try to find the problem since I cant bisect it :D
[05:22] <bryyce> :-(
[05:23] <Sarvatt> -intel master was unusable from 11-11 to 12-10 on 945 here
[05:29] <Sarvatt> hmm theres a few commits that change things for just <965, maybe that'd be a better place to start
[05:46] <Sarvatt> hmm, -joystick has some issues
[05:46] <Sarvatt> took over the mouse
[05:47] <Sarvatt> ah I had my weirdo udev rule I was experimenting with still installed
[05:48] <Sarvatt> cant move the mouse away from the top gnome-panel bar with a controller plugged in
[06:00] <Sarvatt> got it, adding ENV{x11_options.MapAxis1}="disable-mouse", \ to /lib/udev/rules.d/67-xorg-joystick.rules worked
[06:02] <Sarvatt> hmm that cant be right, thats a MapButton option, it probably disabled that axis or something. should have read the man better
[06:19] <bryyce> yeah every so often I have to go through doing a full reinstall in order to clear out all the experimental crap I'd been playing with :-)
[06:19] <bryyce> which has made me be quite strict about not doing any testing on my main desktop
[06:24] <Sarvatt> i've had this install since intrepid and used devel releases the day they opened since jaunty,  probably really due a reinstall here sometime
[06:25] <Sarvatt> ext3 converted to ext4 didn't help fsck times at all, my 40gb ext4 native partition fscks in seconds vs a minute or two for the 10gb / so I'm due a reinstall there for that too
[06:25] <Sarvatt> hmm havent seen this one http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.7.1-gamma-kdm-fix.patch?view=markup
[12:58] <Ng> ugh there's that segfault on USB plug again
[12:58] <Ng> and that wasn't even crazy confused USB afaict, that was just me unplugging my hub and plugging it back in
[12:59] <Ng> did I ask last time I was talking about this why apport doesn't catch Xorg server crashes?
[13:01] <seb128> Ng, because the xorg change to allow that was crashy
[13:01] <seb128> Ng, it's on the todolist for sprint to rewrite it
[13:02] <Ng> ah ok :)
[13:02] <Ng> I'd really like to be able to give a good quality bug report for this segfault other than "erm, I just kinda plug/unplug USB a bit and it crashes" :)
[13:15] <tjaalton> Ng: log in remotely and run gdb?
[13:15] <tjaalton> if it's the server crashing
[13:15] <Ng> tjaalton: I can't reliably reproduce it though
[13:16] <Ng> it's just sometimes USB insertions seem to make X segfault. weirdly it doesn't get restarted, so I'm left looking at the last state of the framebuffer and think the machine has wedged hard, but I can still ssh in
[13:19] <tjaalton> Ng: ok
[15:17] <Sarvatt> Duke`_: if you want something to try -- https://edge.launchpad.net/~sarvatt/+archive/ppa
[15:17] <Sarvatt> (use it on top of edgers)
[15:18] <jcristau> Ng: there's a related bug that got fixed upstream recently iirc
[15:19] <Duke`_> Sarvatt, do I have to add it to my source.list (periodic updates) or just download it once now?
[15:19] <Sarvatt> just download it once
[15:19] <Duke`_> ok
[15:20] <Ng> jcristau: ooh :)
[15:20] <Duke`_> what did you add in it?
[15:20] <Sarvatt> i'm just blindly trying to find what broke it but its better than doing nothing for 2 more months :D
[15:20] <Sarvatt> Revert "uxa: Don't treat prepare_access as a flush synchronisation point."
[15:20] <Sarvatt>       Commit 637f003b047e426901cab6b1fe3a0924bcb9a38a
[15:21] <Duke`_> is it compatible amd64? I'm running X86_64
[15:21] <Sarvatt> uptime
[15:21] <Sarvatt>  10:21:05 up 10:40,  3 users,  load average: 0.02, 0.05, 0.15
[15:21] <Duke`_> ah, build finished.
[15:21] <Sarvatt> yeah whenever it builds, i just uploaded it
[15:22] <Sarvatt> whoa
[15:22] <Sarvatt> mozilla must be on a break :D
[15:22] <jcristau> Ng: http://bugs.freedesktop.org/show_bug.cgi?id=25640
[15:23] <Ng> ah, that was pointed out to me last time I mentioned this. The one key difference is that theirs was really reliably reproducible
[15:23] <Sarvatt> hmm i thought that was fixed a month ago
[15:23] <Ng> mine really isn't
[15:24] <Ng> I plug in to a USB hub at least 5 times a week and it doesn't even crash once a week atm
[15:24] <jcristau> Sarvatt: the patch is 2 weeks old, but not pushed, i think
[15:28] <Sarvatt> ah thats a totally different issue now that i'm looking at it, it was Xi: reset device properties to NULL after deleting them. (#25374) that I was remembering
[16:39] <johanbr> hmmm... suspend does not seem to work anymore with nouveau
[16:39] <johanbr> suspending with nvidia on the same kernel works (but gives graphical artifacts on resume)
[18:37] <apw> bryyce, hey ... how did that testing go?
[19:07] <bryyce> apw, sorry, got sidetracked on another issue.  It's on the todo list for today.
[19:08] <apw> bryyce, np
[19:57] <kees> jcristau: say, can this bug get some love? I'd like to figure out what next-steps are: https://bugs.freedesktop.org/show_bug.cgi?id=9209
[19:58] <jcristau> talk to ajax, i guess
[19:58] <kees> hm, ok
[19:58]  * kees when is he usually online?
[19:58] <kees> oh, he is, just not in here
[19:59] <jcristau> he's at RH in boston, so daytime there
[22:13] <AssertFalse> hi
[22:13] <AssertFalse> anyone to help me configuring my display settings with Dell Latitude E5400 / Ubuntu here ?
[22:15] <jbarnes> AssertFalse: also see /topic :)
[22:15] <jbarnes> lots of good links there
[22:17] <AssertFalse> have tryied many many thing involving xrandr, modeline, xorg.conf but I can't get my resolution above 1024x800 ; which (i guess) is not the max I can get
[22:18] <jcristau> what resolution you can get depends mostly on the monitor..
[22:18] <AssertFalse> (and the /topic is mysteriously not visible with irssi)
[22:18] <jbarnes> https://wiki.ubuntu.com/X
[22:18] <jbarnes> that's /topic
[22:19] <AssertFalse> xrandr says "Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192", am I misunderstanding that i can get 8192 x 8192 resolution ?
[22:19] <jcristau> probably not
[22:20] <jcristau> it's the max size of the framebuffer.  but your monitors won't display that much
[22:20] <AssertFalse> i guess
[22:23] <strycore> Hi
[22:23] <strycore> I've set a wrong resolution on my laptop , how do i reset it to default in a TTY ?
[22:24] <strycore> X has detected wrong refresh rates, i'm getting a black screen on lower resolutions
[22:29] <johanbr> strycore, try "DISPLAY=:0 xrandr --output <OUTPUT NAME> --mode <MODE NAME>"
[22:29] <johanbr> where you get the output and mode names from "DISPLAY=:0 xrandr"
[22:32] <strycore> arrh , I get a X Error of failed request: Badmatch (invalid parameters or attributes)
[22:33] <strycore> Major opcode : 148 (RANDR) , Minor: 7 (RRSetScreenSize)
[22:33] <strycore> if that makes any sense
[22:38] <RAOF> When you run “DISPLAY=:0 xrandr”?
[22:40] <strycore> i got the wrong resolution with gnome-display-properties
[22:40] <strycore> RAOF, no with the output and name
[22:40] <strycore> DISPLAY=:0 xrandr --output LVDS --mode 1280x800
[22:41] <RAOF> And “DISPLAY=:0 xrandr” had LVDS as an output and 1280x800 as a possible mode?
[22:41] <strycore> yes that's the native resolution
[22:41] <RAOF> Can you pastebin the output of “DISPLAY=:0 xrandr -q”?
[22:42] <strycore> I'm afraid i can't , I would need a command line version of pastebin ;)
[22:42] <RAOF> pastebinit!
[22:42] <RAOF> sudo aptitude install pastebinit.
[22:42] <RAOF> The worlds finest remote debugging tool.
[22:43] <strycore> ah ok :)
[22:43] <RAOF> Then you'd run “DISPLAY=:0 xrandr -q | pasetbinit”
[22:44] <strycore> hmm, I would need network-manager now :(
[22:44] <strycore> oh wait, xterm session works
[22:45] <RAOF> Oh.  You don't have your wireless set up as a system-wide thing?  That's a good thing to do :)
[22:46] <strycore> I know but I haven't configured my laptop that much since i installed lucid
[22:48] <RAOF> Heh.  Setting my home's wireless to system-wide is one of the first things I do - for pretty much this reason :)
[22:49] <strycore> well , I'm trying to figure out in gnome-display-properties' source code where it saves its settings
[22:51] <RAOF> In ~/.config/gnome-something-or-other/monitors.xml
[22:52] <strycore> ah
[22:53] <strycore> i typed Alt+F2 and typed xrandr -s 0 blindly , it worked :)
[22:54] <RAOF> :)
[22:54] <strycore> how does xrandr "guesses" the resolutions and refresh rate ?
[22:55] <strycore> 1360x768 , that pretty new to me !
[22:55] <RAOF> By asking your monitor for the resolutions and refresh rates it supports.
[22:56] <RAOF> IE: X grabs the EDID via DDC.
[22:57] <RAOF> Whoops!  Phoronix is wrong about xserver-xorg-video-nouveau.
[22:57] <RAOF> Also, yay for the kernel team!
[22:57] <strycore_> http://pastebin.com/m7b1ec797
[22:58] <strycore_> 1280x800 and 1024x768 works , that's all
[22:59] <RAOF> None of the other ones do?
[23:00] <RAOF> I'm surprised by that output, though.
[23:00] <strycore_> nope, black screen
[23:00] <RAOF> You might want to submit a bug against your video driver; it would appear to be returning invalid modes (which probably means that your monitor has a broken EDID).
[23:01] <strycore_> I'm pretty sure there's something wrong with the monitor
[23:02] <RAOF> And filing a bug with the EDID attached means we (or, rather, upstream) can add a work-around.
[23:02] <strycore_> I had a really hard time to get it working on gutsy and dapper (back when fglrx supported my chipset)
[23:05] <RAOF> https://wiki.ubuntu.com/X/Troubleshooting/Resolution is the page of wonder.
[23:13] <strycore_> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/513011


[06:46] <lifeless> wgrant: hmm, I can't find the oauth connect bug that IIRC I opened on LP.... ring any bells ?
[06:47] <wgrant> lifeless: OAuth Connect isn't a thing.
[06:48] <lifeless> ah yes bad search terms
[06:48] <wgrant> I'm not sure you filed a bug about the OAuth thing you ran into, though.
[06:49] <lifeless> and found it
[06:49] <wgrant> Oh, where?
[06:49] <lifeless> https://bugs.launchpad.net/launchpad/+bug/1420348
[06:49] <mup> Bug #1420348: Support OpenID Connect <Launchpad itself:Expired> <https://launchpad.net/bugs/1420348>
[06:49] <lifeless> I remembered your question and wanted to sit down and think abou tit
[06:50] <wgrant> Oh, I thought you meant the OAuth Haskell thing you had trouble with.
[06:50] <lifeless> no, my patches were merged into a release ages ago
[06:51] <lifeless> I've finally gotten back to that side project in fact
[06:51] <lifeless> but thats separate
[07:01] <lifeless> wgrant: does SSO support OAuth 2 ?
[07:03] <wgrant> lifeless: Not last I knew, but I haven't checked in a while.
[07:18] <lifeless> ok, commented :0
[20:33] <blr_> morning
[22:07] <wgrant> Morning blr
[22:09] <blr> hi wgrant, how was your weekend?
[22:22] <wgrant> blr: Pretty good. You?
[22:28] <blr> good, have family from out of town here atm, so busy... glad i can hide in my office today :)
[22:29] <blr> I see your pygit2 issue still hasn't had a response heh
[22:39] <wgrant> Indeed, but no rush.
[23:08] <cjwatson> wgrant: I'm pretty sure that dep-waited before, yes, because the old sbuild noticed the unsatisfiable version after installing and we picked up its strange output.   Hmm.
[23:20] <wgrant> cjwatson: Do you have a plan for dose-builddebcheck? It's rather messier for us as we have an awful lot of archives.
[23:21] <wgrant> (and then there are questions like bootstrap archives)


[00:26] <JackFrost> fossfreedom_: https://launchpad.net/ubuntu/+source/gobject-introspection/1.78.1-12 I shouldn't have to, just hit rebuild.
[09:07] <fossfreedom_> ah - excellent ... yeah that upload now will enter autopkgtest hell.
[12:29] <fossfreedom_> JackFrost: many thx again for all your help - libxfce4windowing is in the release pocket.  Yay!


[17:40] <tsimonq2> Hey!
[17:40] <tsimonq2> I'm trying to access this page from Firefox nightly and I'm getting a Content Encoding Error: https://ubuntu.com/security/cves
[17:41] <tsimonq2> Where's the best place to report this?
[19:34] <sdeziel> tsimonq2: works for me ATM, maybe it was transient?
[19:34] <tsimonq2> sdeziel: Can confirm. Thanks for listening. :)
[19:35] <sdeziel> np
[19:39] <ItzSwirlz> o/ sorry, but can someone take a look at LP #1977694?
[19:40] <ItzSwirlz> the cve tracker also claims jammy is vulnerable but its not if you check the changelog
[19:40] <tsimonq2> ItzSwirlz: It's been a while since I've done Universe security updates but I believe it isn't SRU'ed, it's direct-pushed. Do you have testing results?
[19:41] <tsimonq2> ItzSwirlz: Ah, I see there's a test in the patch. Have you done any verification thus far?
[19:42] <tsimonq2> Otherwise besides some changelog formatting it seems okay.
[19:43] <tsimonq2> Also, I'll add the serieses on there for you. I don't know if you have access. :)
[19:57] <ItzSwirlz> tsimonq2: Crates now actually force pushes latest version of regex
[19:57] <ItzSwirlz> I tried to make a POC (See my github repo) but results were lame. I tried redirecting it to old regex but i need to test it a bit more to find the bug but now its fine. On my local laptop no DoS.
[19:58] <ItzSwirlz> What's the changelog issue + did it not get added to d/patches/series? It's at the bottom of the debdiff
[19:58] <ItzSwirlz> If it is an external service that requires access of course I do not have it.  Jammy isn't. https://launchpad.net/ubuntu/+source/rust-regex sorry for the confusion
[20:00] <tsimonq2> hi big dumb I'm dad
 "What's the changelog issue + did..." <- Just minor formatting, see other security update changelogs for ref
[20:06] <ItzSwirlz> oh i see, with the -'s
[20:07] <tsimonq2> yeah you catch my drift :)
[20:07] <tsimonq2> I'm sure that the Ubuntu Security Team is better at reviewing this but it seems okay from first look
[20:08] <ItzSwirlz> ill also create a focal patch. idrc about impish as its EOL shortly
[20:14] <tsimonq2> It's a Universe package, I doubt that would be required (re: impish)
[20:17] <ItzSwirlz> do you guys care about the comments or not
[20:17] <tsimonq2> In where?
[20:18] <ItzSwirlz> in the commit/patch specifically
[20:18] <ItzSwirlz> without comments (or the testusuite but I think that should be kept) the commit would be 1/2 the size
[20:18] <ItzSwirlz> https://github.com/rust-lang/regex/commit/ae70b41d4f46641dbc45c7a4f87954aea356283e
[20:21] <tsimonq2> I wouldn't say that more documentation is a bad idea but the Ubuntu Security Team would know for sure.
[20:22] <tsimonq2> Thanks for formatting it with DEP-3.
[20:28] <ItzSwirlz> np


[03:02] <rockets> Anybody know where I can find the Hardy roadmap? I've been googling for days
[03:03] <bazhang> release schedule?
[03:03] <RAOF> What do you mean by 'roadmap'? :)
[03:03] <rockets> right
[03:03] <rockets> release schedule
[03:03] <rockets> e.g.
[03:03] <rockets> tribe 1
[03:03] <rockets> tribe 2
[03:03] <rockets> etc.
[03:03] <bazhang> not final yet--topic
[03:03] <rockets> ah
[03:04] <crimsun> (https://wiki.ubuntu.com/HardyReleaseSchedule)
[03:04] <rockets> ty
[03:04] <rockets> wow
[03:05] <rockets> alpha 1 so soon
[03:05] <rockets> i cant believe it
[03:05] <rockets> i mean gutsy is barely out
[03:05] <crimsun> it's an LTS.  We have a boatload of testing to do.
[03:05] <rockets> true.
[03:07] <rockets> ah i forgot who you were for a second crimsun
[03:07] <rockets> alsa right
[03:08] <crimsun> among other silly things, yes.
[03:08] <rockets> lol
[03:08] <rockets> any chance of pulse-as-default in hardy?
[03:08] <crimsun> the desktop team (Ubuntu, that is) plans to ship it as default in 8.04 LTS, yes.
[03:11] <rockets> sweet.
[03:11] <rockets> but, silly question, doesnt it break flash audio
[03:11] <rockets> i mean theres a fix but its a bit of a hack
[03:12] <RAOF> Eh.
[03:12] <crimsun> No.
[03:12] <rockets> ah
[03:12] <rockets> well it breaks flash in feisty. like i said theres a fix
[03:12] <crimsun> the current public incarnation of Flash 9 is arguably "broken"
[03:12] <rockets> well yeah. it screws with firefox a fair bit
[03:12] <rockets> but gnash isnt a viable alternative
[03:13] <crimsun> it does inane things like attempting to open every subdevice enumerated.
[03:13] <crimsun> which, as one might imagine, is a bit over the top.
[03:13] <rockets> hah.
[03:13] <rockets> yeah.
[03:13] <crimsun> the "fix" is actually a hook into the libflash routine to bypass that mess
[03:14] <rockets> hah
[03:14] <rockets> nice
[03:19] <rockets> crimsun, i remember you, because i once asked you like two hours of inane questions
[03:19] <rockets> mostly about pcm multiplexing and kernel vs software implementations of it
[03:20] <crimsun> I've fielded a lot of those.
[03:20] <rockets> hehe
[03:20] <rockets> well.
[03:21] <rockets> my soundcard works fine *mostly*
[03:21] <rockets> i very rarely have to use Esd
[03:21] <rockets> once in a while i hit a problem
[03:21] <rockets> i havent had any issues since gutsy
[03:21] <rockets> so thanks!
[03:21] <crimsun> mostly not my work, but duly noted
[03:22] <rockets> i know its upstream, but you integrate it into ubuntu
[03:22] <rockets> or at least manage that process
[03:22] <crimsun> right, I did that for a few releases
[03:22] <crimsun> I've stepped back to give the community a bit more space to become involved
[03:22] <rockets> heh


[00:31] <poolie> jelmer, what's the eta for testing daily builds for real?
[00:31] <poolie> by which i mean on production launchpad?
[00:31] <jelmer> poolie: basically we're waiting for IS to open some ports
[00:36] <jelmer> poolie: That would make it possible to use on edge/staging. I'm not sure when it'll be enabled on production, but I imagine it would be soon afterwards unless we find things that need to be fixed.
[02:58] <sinzui> thumper, I am starting the next review...
[02:58] <thumper> sinzui: ta
[02:59] <sinzui> I am concerned about ec2. I see a failure that must be from my branch, but ec2 sent me a success message
[02:59] <wgrant> Well, Windmill is switched off in EC2 at the moment, so that was always going to happen.
[02:59] <sinzui> This happened last Thursday too. my confidence is shaken
[03:01] <sinzui> I think lib/lp/blueprints/tests/../stories/standalone/xx-personviews.txt and lib/lp/soyuz/tests/../stories/soyuz/xx-distributionsourcepackagerelease-pages.tx are broken in trunk
[03:01] <sinzui> The last one was run by StevenK before he sent it off to  PQM. it had unicode in it which cause ec2 to barf
[03:03] <rockstar> Is there a way I can run a single test in ec2?  It's one that fails with the GPGmeError on my local box.
[03:03] <wgrant> Erm, what was the failure in the latter file?
[03:04] <wgrant> That looks like it could be one of mine.
[03:04] <wgrant> rockstar: What's the gpgme error?
[03:04] <wgrant> Is it the one with the one-liner fix?
[03:04] <sinzui> I want a thunder dome form test runners, pqm vs ec2 vs buildbot. 3 runners enter one leaves
[03:04] <rockstar> wgrant, I don't remember specifically, but it's a known issue (one that abentley spent some time trying to sort out)
[03:05] <lifeless> sinzui: you forgot hudson
[03:05] <lifeless> 2 in 1 out, 2 in 1 out, 2 in 1 out :)
[03:05] <lifeless> thumper: I'd like a link to activereviews on https://edge.launchpad.net/lmirror/trunk
[03:06] <lifeless> thumper: what do you think?
[03:06] <rockstar> lifeless, no tournament, battle royale!  :)
[03:06] <sinzui> wgrant, the fault was smart quotes pasted into actual test. the test was not loaded run because of a decode error. StevenK ellipsisised the quotes and ran the test locally before submitting it.
[03:06] <wgrant> sinzui: Yeah, and it is now broken because of my change last night.
[03:06] <sinzui> I am preparing a fix for the two tests...if the error really is just the tests
[03:06] <wgrant> So it wasn't running before?
[03:07] <sinzui> right, it did not run.
[03:07] <sinzui> I have seen this before when I used to hack a lot in answers
[03:07] <thumper> lifeless: in the code for this series ?
[03:07] <lifeless> yeah
[03:07] <thumper> lifeless: just targetting the series branch?
[03:07] <lifeless> yeah
[03:08] <wgrant> sinzui: http://pastebin.ubuntu.com/440648/
[03:08] <thumper> sure
[03:08] <lifeless> one less click, one step closer to series-are-just-big-branches
[03:08] <sinzui> wgrant, regardless of who changed it and who fixed it. we are getting mixed message from test runs about whether is it broken
[03:08] <wgrant> sinzui: are we? StevenK probably fired the test off before my thing landed.
[03:08] <thumper> lifeless: in which case we should add a codebrowse link too
[03:08] <lifeless> thumper: YES
[03:09] <lifeless> thumper: that would make many people happy
[03:09] <wgrant> It's been in devel only 13 hours.
[03:09] <thumper> lifeless: maybe not many, maybe just a few
[03:09] <lifeless> thumper: maybe
[03:09] <lifeless> thumper: Lots of people get lost finding codebrowse
[03:09] <thumper> lifeless: I think many people would be happy if we had a bigger brighter "see the code here" on the front page
[03:09] <lifeless> starting at lp.net/PROJECT
[03:09] <poolie> hi
[03:09] <lifeless> thumper: yes
[03:09]  * thumper agrees
[03:09] <wgrant> Well, that's because everywhere other than LP has codebrowse integrated into the app.
[03:10] <thumper> wgrant: that's true
[03:10] <poolie> if i write to a python logger from inside launchpad's mail processor, will that just turn up in a log file in product?
[03:10] <poolie> *production
[03:10] <thumper> wgrant: I'd love to have loggerhead more integrated, but it isn't up to it just yet
[03:10] <lifeless> poolie: I think it has its own system
[03:10] <lifeless> you raise an event
[03:10] <poolie> i see some other code uses it...
[03:10] <sinzui> wgrant the error is different now, and this command certainly confirms the unicode is gone:  iconv -f ascii lib/lp/soyuz/stories/soyuz/xx-distributionsourcepackagerelease-pages.txt > /dev/null
[03:10] <thumper> poolie:  what are you after?
[03:11] <thumper> poolie: and yes, writing to a logger should end up in the process-mail logfile
[03:11] <wgrant> sinzui: The diff I pasted fixes it in an up-to-date devel.
[03:12] <poolie> i want to log the results of the dkim check
[03:13] <sinzui> wgrant, I just got this which matches the error I see in buildbot: http://pastebin.ubuntu.com/440653/
[03:14] <wgrant> sinzui: That's what my diff is for.
[03:14] <wgrant> I broke that test last night.
[03:14] <sinzui> ah!
[03:15] <sinzui> sorry, I was promoted over my abilities years ago.
[03:16] <lifeless> darn
[03:16] <lifeless> I forgot my second battery
[03:16] <lifeless> ah well, not like I'll need it on a cross-tasman hop :P
[03:17] <sinzui> wgrant, thank you. I committed that fix to my branch
[03:17] <wgrant> sinzui: Thanks, and sorry.
[03:18] <wgrant> What caused someone to notice and reenable it?
[03:18] <wgrant> Remarkably bad timing.
[03:29] <lifeless> ok, later - ciao
[03:39] <sinzui> thumper, I am starting your review again after dealing with the buildbot distraction.
[03:39] <thumper> sinzui: the second review?
[03:40] <thumper> sinzui: I'm working on the branch subscription one right now
[03:41] <lifeless> I like the iwlagn driver
[03:41] <lifeless> lets me change mac addresses *and doesn't filter its own traffic*
[03:42] <wgrant> Its MAC spoofing functionality was very handy at LCA.
[03:42] <wgrant> Since the hotel granted 30 minutes free Internet connectivity per day.
[03:43] <lifeless> yes
[03:43] <lifeless> this waiting area is 30/4 hours, which is == for me :)
[03:43] <lifeless> n+1, associate again.
[03:43] <wgrant> Yep.
[03:44] <mwhudson> :)
[03:46] <thumper> sinzui: where is the code that does the magic user.in_admin et al?
[03:46] <thumper> sinzui: for the security adapters
[03:46] <thumper> sinzui: I'd love to move the code specific adapters out of that file
[03:46] <sinzui> .me thinks
[03:46] <sinzui> something "roles"
[03:47] <thumper> sinzui: although I do recall that the security file is "special"
[03:47] <thumper> sinzui: and processed by a script in a special way
[03:47] <thumper> sinzui: to register the security adapters
[03:47] <thumper> personally I'd prefer a metaclass
[03:47] <wgrant> It's not that special. There's just an <authorizations> ZCML directive referencing it.
[03:50] <thumper> wgrant: oh, is that all?
[03:50]  * thumper tries to move some code ones :)
[03:51] <wgrant> Yeah, it looks like it should work fine if you have another one.
[03:51] <wgrant> Since it just registers adapters.
[03:51] <thumper> hmm...
[03:51] <thumper> perhaps not in this branch...
[03:51] <thumper> later.
[03:51]  * thumper must not get distracted
[03:51] <wgrant> But yes, a good idea to chop that damn file up.
[03:57]  * thumper collects children
[04:00] <sinzui> thumper, you have my RC for the second branch.
[04:07] <poolie> are the python logging logs recorded anywhere special during a unit test?
[04:23] <thumper> sinzui: ta
[04:26] <poolie> thumper, is there any way to get into pdb inside a launchpad unit test?
[04:26] <thumper> -D
[04:26] <poolie> it looks like stdin is redirected if i just call set_trace
[04:26] <thumper> poolie: sometimes it is
[04:27] <thumper> it depends on the layer
[04:27] <thumper> and if it is a subprocess test
[04:27] <thumper> not always easy to do
[04:27] <poolie> ok thanks
[04:27] <thumper> bin/test -vvt some_test -D *should* drop into the debugger on a fail
[04:28] <poolie> thanks
[04:29] <poolie> also do you know off hand why things are marked with IWeaklyAuthenticatedPrinciple
[04:29] <poolie> rather than being marked if they're strongly authenticated
[04:29] <poolie> it doesn't really matter, it just seems backwards
[04:29] <poolie> so i wondered if there was a reason
[04:41] <poolie> thumper, my test, after parsing the email, gets
[04:41] <poolie> ForbiddenAttribute: ('email', <Person at 0xe73280c name16 (Foo Bar)>)
[04:41] <thumper> preferredemail.email
[04:48] <thumper> sinzui: being bitten by two things
[04:48] <thumper> sinzui: You should not import BranchSubscriptionEdit from canonical.launchpad.security
[04:48] <thumper> sinzui: and ForbiddenAttribute: ('in_admin', <Person at 0xca7e950 ...
[04:48] <thumper> :(
[04:48] <thumper> too much special casing
[04:49] <sinzui> yuck
[04:49]  * thumper thinks
[04:50]  * thumper could avoid the first by making lp.code.security and putting the class in there with the configuration change
[04:50] <thumper> and then not using the "special in_...." methods
[04:51] <thumper> AAARRRRGGGHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!
[04:52] <thumper> canonical.launchpad.security line 452
[04:52] <sinzui> odd, I am already there
[04:57] <wgrant> thumper: So you get a different object if you're in another module?
[04:57] <poolie> thanks thumper that fixed it
[04:57] <thumper> wgrant: which question?
[04:57] <wgrant> Or are you grabbing another person manually and not adapting to IPersonRoles?
[04:57] <wgrant> The ForbiddenAttribute.
[05:00] <thumper> the IPersonRoles thing will fix the second issue
[05:01] <poolie> actually wgrant (hi) do you know why we have IWeaklyAuthenticatedPrincipal rather than IStronglyAuthenticatedPrincipal?
[05:02] <wgrant> poolie: No idea, sorry.
[05:02] <thumper> yes
[05:02] <thumper> poolie: it is because the email code was written second
[05:02] <poolie> ok... and?
[05:03] <thumper> poolie: and I'm guessing that all the existing code wasn't wanted to be updated to check for strongly authenticated
[05:04] <poolie> mm i can imagine that
[05:04] <poolie> i just wondered if it was easier for them to assert the absence of IWeakly... than to check for IStrongly
[05:04] <poolie> it's just curiousity
[05:32]  * _thumper_ cleans as visitors coming, back tonight
[06:02]  * sinzui find bed
[06:08] <StevenK> (I think ...)
[06:08] <StevenK> thumper: Oh, duh. Thanks. :-)
[06:08] <thumper> np
[06:24] <BjornT> poolie: IWeaklyAuthenticatedPrincipal is really old code. iirc, it's really a start of a rework of the security system, that didn't get finished. the idea was to have both IWeaklyAuthenticatedPrincipal and IStronglyAuthenticatedPrincipal, but the latter never got added. the end result would be to have different security adapters for the two
[06:56] <poolie> ah thanks BjornT
[07:32] <adeuring> good morning
[09:15] <mrevell> Morning
[10:47] <krkhan> i'm getting the "nonce used already" error no matter what value i choose for the nonce. i've even tried FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF as the value
[10:47] <krkhan> (for the api reqs)
[10:49] <krkhan> is there a way for clearing the nonce records
[12:23] <jml> krkhan: look inside ~/.launchpadlib/, there's probably a file you can delete
[12:23]  * jml going offline to get some work done
[12:27] <maxb> If krkhan is choosing nonces, this presumably means not using launchpadlib
[12:34] <james_w> no, the error is misleading I think. I've seen that before, but I can't remember the cause now
[12:41] <krkhan> i wasn't using launchpadlib. i wanted to clear the cache at launchpad server's side. anyways, i have disabled nonce checking for the time being as a workaround
[12:42] <krkhan> i have another question though. i'm currently using the cycle of "make run; change code; ctrl-c; make run again" to play with lp's code. make run takes around 30 seconds to launch each time and it's a bit cumbersome. is it possible to modify lp's code while it's running?
[14:12] <james_w> krkhan: were you using lp.me by any chance? Or accessing anything else that will result in a redirect?
[14:12] <james_w> if you get a redirect then you need to re-sign the resulting request, not send the same headers to the new URL
[15:03] <mars> gmb, ping, there is something odd going on here.
[15:04] <mars> gmb, I ran bzr branch -r 9415 lp:~gmb/launchpad/hook-up-stored-proc-boom-bug-585803
[15:04] <gmb> mars, Ah, the phrase I love to hear Friday of week 3
[15:04] <mars> Good!  We are on the same page :)
[15:05] <mars> gmb, so I ran that test locally, r9415 as the SUCCESS mail says, and the test passes?  Does it work for you too?
[15:05] <gmb> mars, let me just try.
[15:05] <mars> going to try it via 'make check'
[15:06] <gmb> K
[15:12] <mars> passes 'make check'
[15:12] <mars> make check TESTOPTS='-t xx-temporary-blob-storage_txt'
[15:13] <mars> so either a test isolation failure + testrunner fault, or a test environment factor + testrunner fault
[15:14] <gmb> mars, Weird.
[15:14] <gmb> mars, But it *should* fail
[15:14] <gmb> Ah,... or should it
[15:14] <gmb> Hmm.
[15:14] <krkhan> james_w: i was requesting a non-existent page actually. i guess that was the root of all evil
[15:15] <mars> gmb, your mail says "a stray line of output I'd left in a pagetest", but it looks like the doctest failure is producing "{}" when it shouldn't?
[15:15] <mars> gmb, that means the error is that "{}" does not appear in the doctest when it should, correct?
[15:15] <gmb> mars, What I meant was that I'd left 'job.metadata' in the test, so it outputted {}, which I hadn't accounted for
[15:15] <gmb> So by right, it *should* have failed.
[15:16] <gmb> mars, Ah, but, it fails locally
[15:16] <mars> gmb, ok, so why is job.metadata not producing that same output here.
[15:16] <gmb> mars, I have *no* idea.
[15:16] <mars> gmb, it fails for you locally?  What command?
[15:16] <gmb> bin/test -cvvt xx-temporary-blob-storage
[15:17] <mars> wtf, it failed this time
[15:17] <gmb> (!)
[15:19] <mars> argh, my mistake, I was testing "xx-temporary-blob-storage_txt" instead of "xx-temporary-blob-storage"
[15:19] <mars> gmb, ok, thanks!  I can reproduce locally.  Now to figure out why it reports success.
[15:20] <gmb> mars, Best of luck :)
[15:20] <gmb> let me know if I can help further
[15:20] <mars> gmb, ok.  I'll be out for a while, probably up to your EOD, so we may have to pick this up on Monday
[15:20] <mars> make that Tuesday, Monday is a holiday there
[15:21] <gmb> mars, It's a national holiday Monday here too, so no worries :)
[16:10] <rockstar> Is anyone working on the db_lp failure?
[16:17] <jelmer> rockstar: I think curtis said he was going to look into it
[16:20] <noodles775> jelmer, rockstar, sinzui: I think there's some confusion there... sinzui it looks like you replied to the db_lp failure, but meant to reply to the lp failure (in your email)?
[16:21] <rockstar> noodles775, I'm handling the db_lp one.
[16:24] <sinzui> rockstar, db_lp is fixed in devel
[16:24] <noodles775> rockstar: great. Just note that it was already fixed in devel with r10935, so you might just want to merge the change from there.
[16:24] <rockstar> sinzui, ah, okay.  So it WASN'T caused by my branch then (which landed directly into devel)
[16:25] <sinzui> rockstar, This is dumbfounding: https://lpbuildbot.canonical.com/builders/lp/builds/931/steps/shell_7/logs/summary
[16:25] <rockstar> Er, landed directly into db_devel I mean.
[16:25] <rockstar> sinzui, what's dumfounding about that?
[16:25] <sinzui> ^ the error we see is because there is an actual error in how we setup oops reporting. That is hiding the real error that caused the oops
[16:25] <nigelb> bryceh: poke
[16:26] <rockstar> sinzui, this is the one I was looking at: https://lpbuildbot.canonical.com/builders/db_lp/builds/830/steps/shell_7/logs/summary
[16:26] <sinzui> yes I fixed that with wgrant
[16:27] <rockstar> sinzui, okay, I'll leave it alone then.  As I started investigating, I started to realize it probably wasn't my fault anyway, but still was happy to fix it.
[16:27] <noodles775> rockstar: it might be worth checking your ec2 results when your branch landed (see gmb's 'email "Er, this isn't a SUCCESS").
[16:27] <bryceh> nigelb, yep
[16:28] <nigelb> bryceh: wondering if we could interface lp api to talk to reportbug for easy forward to debian
[16:28] <nigelb> something that can pull bug title and description and give to reportbug if we give it the lp bug number
[16:29] <nigelb> if I start off a branch, can help me out?
[16:29] <bryceh> jelmer, btw sorry last night in the middle of our conversation Verizon decided I didn't need internet and switched it off for a few hours.
[16:29] <rockstar> noodles775, well, my output seems truncated, but there's no failures logged.
[16:29] <bryceh> nigelb, sure
[16:29] <nigelb> bryceh: awesome, thanks :)
[16:30] <sinzui> devel is the one I am out of my depth. I cannot see the real error. I think the test env is not setup right for reporting codeimportworker oopses. apparently the section is missing
[16:30] <jelmer> bryceh: ah :-)
[16:30] <bryceh> nigelb, the lp side for that should be pretty straightforward; I've got most of that in arsenal now
[16:30] <jelmer> bryceh: I figured it was something like that
[16:31] <nigelb> bryceh: just pulling from launchpadlib should be enough right?
[16:31] <bryceh> nigelb, yeah
[16:31] <nigelb> bryceh: I'll give it a go i about an hour, I'll poke if I have something working :)
[16:31] <nigelb> (or not working)
[16:32] <bryceh> jelmer, anyway, dunno if you got everything I wrote.  In short, pulling bugs into gtg as tasks isn't implemented but with the latest backends work in theory it should be possible to do now
[16:32] <bryceh> jelmer, I've got plans to do it, just haven't gotten time yet
[16:34] <bryceh> nigelb, sounds good, I've got a meeting at the hour but will be around before and after that
[16:35] <nigelb> bryceh: cool :)
[16:37] <jelmer> bryceh: ah, cool
[16:37] <jelmer> bryceh: are you planning on landing this in mainline or as a separate plugin?
[16:38] <bryceh> jelmer, it would be a plugin which would be included in bzr trunk
[16:38] <bryceh> jelmer, although during development would be in a branch of course
[16:39] <bryceh> jelmer, btw I'm interested in hearing ideas of how it should work, use cases, etc.
[16:40] <jelmer> bryceh: for me personally, I'd be interested in having a way to automatically add all bugs that are assigned to me to gtg, inheriting tags from lp
[16:40] <jelmer> bryceh: as well as all my merge proposals that are work-in-progress
[16:43] <bryceh> jelmer, mm
[16:46] <bryceh> jelmer, some questions that have come up in relation to this...  would you want the import to be read-only or read-write (e.g. if you close the imported bug task or change tags, should it cause some change on lp or not)?  Would you want to make sub-tasks off of bug tasks (LP doesn't support sub-items so we'd have to figure out some alternate way to track it in gtg)?  Do you want to make notes on the bug task in gtg?
[16:50] <jelmer> bryceh: I hadn't thought that far ahead. read-only would be very useful by itself, and a nice first milestone but read-write would certainly also be nice.
[16:50]  * bryceh nods
[16:51] <bryceh> yeah that's what I'll be aiming for first
[17:39] <nigelb> bryceh: how do I query if a bug is private?
[17:42] <bryceh> nigelb, if [ bug.private ]
[17:42] <bryceh> or if you're using arsenal, if [ arbug.bug.private ]
[17:42] <nigelb> I'm directly querying
[17:43] <nigelb> I'll file a bug to tweak the apidocs soon enough.  Its not clear this is how I go about it
[18:10] <nigelb> bryceh: anyway to expose the pcakage name of a bug via api? I see only bug_tasks_collection_link
[18:40] <maxb> nigelb: A bug is not associated with a package directly. A bug has bug tasks. The bug tasks are associated with projects, distributions, or packages.
[18:42] <nigelb> maxb: oh, thats tough :D
[18:42] <maxb> no, that's good :-)
[19:34] <bryceh> nigelb, yeah it gets complicated
[19:34] <nigelb> bryceh: I got everything working except the plugging to reportbug
[19:35] <nigelb> playing with subprocess right now :x
[19:35] <bryceh> nigelb, what you have to do is given the bug #, look at its bug_tasks.  Exclude ones which are closed or that are external watches.
[19:35] <nigelb> nah, I found easier way
[19:35] <bryceh> oh?
[19:36] <nigelb> First line of report is usually "Binary package hint: <package-name>"
[19:36] <nigelb> not perfect, but works :D
[19:40] <maxb> eww, that's horrid
[19:41] <maxb> You really don't want to do that
[19:41] <maxb> iterate the bugtasks, find the ones which are ubuntu packages, and take it from that
[19:42] <nigelb> the problem is that package name might be wrong, so I'm only giving a hint and then user has to manually choose
[19:42] <nigelb> anywy, I'm stuck up against a brick wall called subprocess.open
[19:50] <nigelb> bryceh: help!
[19:51] <bryceh> ok
[19:51] <bryceh> yeah, I would not suggest relying on the Binary package hint text, that is going to be wrong a large percentage of the time
[19:52] <bryceh> yeah like I suggested before, go through the bug_tasks and exclude what you can
[19:52] <nigelb> bryceh: trust me, that's the least of my worries right now
[19:52] <nigelb> bryceh: https://code.launchpad.net/~nigelbabu/ubuntu-review-overview/report-debian
[19:52] <bryceh> ok what's the worry?
[19:53] <nigelb> if you can get this beast working, it would be great
[19:53] <nigelb> I can't get python to pass the arguments to reportbug
[19:55] <nigelb> bryceh: ok, now the arguments are passing correctly, but still #fail
[19:56] <bryceh> what command line are you using to run it?
[19:58] <nigelb> python report-but -b 33333
[19:58] <nigelb> s/bug/bug
[19:59] <bryceh> ahh process handling
[19:59] <nigelb> um, whats wrong?
[20:01] <nigelb> bryceh: ok, now its partly working :)
[20:01] <nigelb> yay to mentors :)
[20:04] <bryceh>     p = subprocess.Popen(args)
[20:04] <bryceh>     p.wait()
[20:05] <bryceh> or perhaps p.communicate() is better than p.wait() depending on how you intend to use it
[20:06] <bryceh> nigelb, anyway, other folk are probably better skilled than me at python to help with process handling stuff, but if you get stuck on launchpadlib-isms feel free to ping me further
[20:06] <nigelb> ok :)
[20:06] <nigelb> thanks :)
[20:08] <mars> nigelb, are you trying to interact with the subprocess using the current script, or just call it?
[20:09] <bryceh> nigelb, lp:~bryceharrington/ubuntu-review-overview/report-debian
[20:10] <nigelb> mars: try to interact with the current script
[20:12] <mars> ok, yes, you'll need .communicate() then to send data to the subprocess' Standard Input, and to read it's Standard Output
[20:12] <nigelb> ah
[20:19] <jml> g'night all
[20:20] <bryceh> I'm trying to find where the package-requests table is in my launchpad.dev environment... could anyone suggest a path to get to this page?
[20:22] <bryceh> the title of the page is "Copy archive contents" fwiw
[20:42] <maxb> Does anyone understand *why* OAuth uses split request/access tokens, rather than just having one token, that gets activated?
[20:43] <maxb> (Purely out of curiosity)
[21:05] <nigelb> mars: I'm getting wierd errors
[21:06] <nigelb> the lp_bug.description becomes the name of the attachment instead of the content :x
[21:09] <nigelb> bryceh, mars: any thoughts on ^ ?
[21:09] <bryceh> right that's correct
[21:10] <bryceh> I have a snippet for getting the content, hang on
[21:11] <bryceh> 	for a in bug.attachments:
[21:11] <bryceh>             # Retrieve content
[21:11] <bryceh>             hosted_file = a.data
[21:11] <bryceh>             hosted_file_buffer = hosted_file.open()
[21:11] <bryceh>             content = hosted_file_buffer.read()
[21:11] <nigelb> hang on
[21:11] <nigelb> whats ^ for?
[21:11] <bryceh> a.message has additional info about the attachment
[21:11] <nigelb> I'm not talking about LP attachment
[21:12] <bryceh>             author = a.message.owner.name
[21:12] <bryceh> nigelb, then maybe you should clarify
[21:12] <nigelb> I meant the description of the bug that I pass to reportbug ends up being the name of the attachment to a debian bug instead of an actual bug
[21:13] <bryceh> oh, I don't really know much about reportbug
[21:13] <nigelb> does arsenel talk to debian bts?
[21:13] <bryceh> nigelb, probably best you save me for launchpadlib questions specifically ;-)
[21:13] <bryceh> nigelb, nope
[21:13] <bryceh> nigelb, bugzilla.freedesktop.org
[21:13] <bryceh> but doesn't do attachments (yet)
[21:14] <nigelb> bryceh: hm, probably I need to write something to talk to debian bts then
[21:14] <nigelb> this is getting me nowhere otherwise
[21:15] <nigelb> bryceh: I'll try to write something to talk to bts and perhaps you can add to arsenel too :)
[21:16] <bryceh> nigelb, ok that would be great :-)
[22:08] <mars> bryceh, ping, could you please tell me the *exact* command you used to execute your test?
[22:10] <mars> bryceh, and the location of the ec2 script that was executed?  (was it in the same branch, or somewhere else like trunk/?)
[22:24] <bryceh> mars, ./utility/ec2 test
[22:24] <bryceh> mars, yeah same branch
[22:26] <mars> bryceh, ok, thanks.  I'm writing a reply to your mail.  Must be past EOD where you are?
[22:26] <bryceh> mars, yeah getting close
[22:28] <mars> ok.  After I get the mail out, feel free to write back whenever you have the time.
[22:29] <bryceh> ok will do
[22:54] <maxb> Ursinha: Hello. Have you considered registering a special Launchpad person to run your QA bot as? It would make notifications/bug histories somewhat more obvious to the uninitiated
[22:54] <Ursinha> maxb, yes, I've considered but haven't executed the idea
[22:55] <maxb> well, +1 :-)
[22:59]  * Ursinha appends on her TODO list
[22:59] <Ursinha> :)


[02:49] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/4249 Successfully built
[07:05] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4251 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[07:06] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4251 Generating diffs
[08:12] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4251 Uploading build
[08:31] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4251 Pending binary packages
[08:51] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4251 Successfully built
[09:39] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4239 Diff missing
[09:43] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4222 Diff missing (groovy/openvswitch). Successfully built (groovy/dpdk)
[12:43] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4252 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[13:33] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4252 Pending binary packages
[14:33] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4252 Diff missing (groovy/dpdk). Pending binary packages (groovy/openvswitch)
[14:53] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4252 Diff missing
[15:09] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4253 Preparing packages
[21:13] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4212 Failed to build


[23:59] <rodgerr> sebsebseb: thanks want to PM to keep it off the grid
[23:59] <sebsebseb> rodgerr: why?