[00:00] <crashsystems> https://bugs.edge.launchpad.net/ubuntu/+source/totem/+bug/180457/comments/7
[00:00] <ubottu> Launchpad bug 180457 in totem "totem-gstreamer crashed with SIGSEGV" [Medium,Invalid]
[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:01] <ubottu> Launchpad bug 338022 in polybori "python-polybori fails to install in Jaunty (python 2.6 transition)" [Undecided,New] https://launchpad.net/bugs/338022
[00:01] <ubottu> Launchpad bug 338024 in python-processing "python-processing fails to install in Jaunty (python 2.6 transition)" [Undecided,New] https://launchpad.net/bugs/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:03] <ubottu> Launchpad bug 337863 in pywebkitgtk "python-webkitgtk depends on a version of python earlier than 2.6" [Undecided,New]
[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:29] <ubottu> Launchpad bug 338022 in polybori "python-polybori fails to install in Jaunty (python 2.6 transition)" [Undecided,New] https://launchpad.net/bugs/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
=== jgoguen|away is now known as jgoguen
=== asac_ is now known as asac
[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 :(
=== crashsystems is now known as ubuntu2
=== ubuntu2 is now known as crashsystems
[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 :=)
=== asac_ is now known as asac
[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:02] <ubottu> Launchpad bug 317860 in mobile-broadband-provider-info "Request to upgrade to latest SVN 3G profiles" [Undecided,Confirmed] https://launchpad.net/bugs/317860
[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:25] <ubottu> Launchpad bug 338079 in python-4suite "[Jaunty] packages incompatible with python 2.6" [High,Confirmed] https://launchpad.net/bugs/338079
[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
=== r0bby_ is now known as r0bby
=== dantalizh is now known as dantalizing
=== dantalizing is now known as zz_dantalizh
=== zz_dantalizh is now known as dantalizing
=== dantalizing is now known as zz_dantalizing
=== dantalizing is now known as zz_dantalizing
=== zz_dantalizing is now known as dantalizing
[06:40] <YoBoY> good morning
=== seb128_ is now known as seb128
=== elmargol_ is now known as elmargol
[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
=== mnem0 is now known as mnemo
=== BrunoX1ambert is now known as BrunoXLambert
[14:26] <YoBoY> someone on 8.04 can see if the bug 239426 is reproductible?
[14:26] <ubottu> Launchpad bug 239426 in flashplugin-nonfree "some text not displayed in flash applets - fonts" [Undecided,New] https://launchpad.net/bugs/239426
[15:08] <bddebian> Boo
=== jgoguen is now known as jgoguen|away
=== ogra_ is now known as ogra
=== jgoguen|away is now known as jgoguen
=== Brownout is now known as Brown
[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] <ubottu> A large amount of the first questions asked in this channel start with "Does anyone/anybody..."  Why not ask your next question (the real one) and find out?
[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:43] <ubottu> Launchpad bug 326667 in acpid "pressing (laptop) power button should show shutdown dialog on kde4" [Undecided,New]
[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
=== thunderstruck is now known as gnomefreak
[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:30] <ubottu> Launchpad bug 225197 in flashplugin-nonfree "Empty window appears" [Undecided,Incomplete] https://launchpad.net/bugs/225197
[17:30] <ubottu> Launchpad bug 226471 in nspluginwrapper "untitled popup window" [Undecided,New] https://launchpad.net/bugs/226471
[17:30] <ubottu> Launchpad bug 262693 in nspluginwrapper "Flash not working: Intrepid, 2.6.27, FF3" [Undecided,Fix released] https://launchpad.net/bugs/262693
[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 :)
=== maco_ is now known as maco
=== fader is now known as fader|lunch
[18:24] <mcas> hi
[18:24] <mcas> bug #337490
[18:24] <ubottu> Launchpad bug 337490 in libopensync-plugin-python "package opensync-module-python None [modified: /var/lib/dpkg/info/opensync-module-python.list] failed to install/upgrade: tentata sovrascrittura di `/usr/lib/opensync/plugins/python_module.so', che si trova anche nel pacchetto libopensync-plugin-python" [Undecided,New] https://launchpad.net/bugs/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
=== fader|lunch is now known as fader
[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
=== Hurtz_ is now known as Hurtz
[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
=== Brown is now known as Brownout
[19:30] <maxb> charlie-tca: Surely that bug should be invalidated. It's not a bug in ubuntu.
[19:31] <charlie-tca> <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: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
=== dantalizing is now known as zz_dantalizing
=== zz_dantalizing is now known as dantalizing
[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
=== lacqui_ is now known as lacqui
[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
=== dantalizing is now known as zz_dantalizing
=== zz_dantalizing is now known as dantalizing