[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