[00:36] <tkamppeter> Cansomeone approve my uploads (ghostscript, hplip, system-config-printer, hal-cups-utils)? Seems that the beta freeze did not get deactivated.
[00:52] <slangasek> tkamppeter: the freeze is still in effect; when it's over, all the packages will be released from the queue.
[00:54] <tkamppeter> slangasek, why is the beta freeze still active with the beta already being released and announced.
[00:56] <JanC> tkamppeter: are all the images built already?
[00:56] <slangasek> because it gives us a grace period after the announcement when the jigdo files remain valid, and when we can respin a new image for something we overlooked if we absolutely have to
[00:56] <slangasek> JanC: and released
[00:56] <tkamppeter> OK. Thanks.
[01:01] <directhex> i think i had some sponsorships pending that the freeze got in the way of
[01:11] <wgrant> slangasek: I've often wondered why you can't declare a set of Soyuz publishings to stick around for a while. It would seem not too hard to implement, and would make downloading images much nicer.
[01:40] <DaemonFC> Who would be the person to talk to about maybe getting Ubuntu to use Smolt eventually?
[01:41] <directhex> smolt?
[01:41] <directhex> fedora's hardware database?
[01:41] <DaemonFC> yes, and it's not just for Fedora
[01:41] <DaemonFC> other distributions contribute
[01:42] <DaemonFC> Suse does
[01:42] <DaemonFC> I was wondering who I could make a suggestion to about a monthly Smolt checkin like other distributions do
[01:42] <DaemonFC> with user consent of course
[01:44] <directhex> a package might be a starting point
[01:44] <DaemonFC> currently, Ubuntu doesn't seem to be participating in that or kerneloops, though kerneloops probably makes less sense in Ubuntu
[01:44] <DaemonFC> (as more Ubuntu kernels will be tainted)
[01:44] <slangasek> Ubuntu is participating in kerneloops.
[01:44] <DaemonFC> oh?
[01:45] <slangasek> sure, http://www.ubuntu.com/testing/jaunty/beta#Kerneloops :)
[01:45] <DaemonFC> oh, it's just not there by default
[01:45] <slangasek> correct
[01:45] <slangasek> there were some integration issues that prevented us from shipping it by default for 9.04
[01:46] <DaemonFC> I'm running a vanilla kernel, so I would suppose they'd be interested upstream if my kernel oopsed
[01:47] <directhex> as long as it doesn't bother upstream over every little oom
[01:48] <DaemonFC> I noticed that Ubuntu tends to stay behind one kernel and cherry pick
[01:49] <directhex> DaemonFC, kernel version is picked fairly early in the release process
[01:50] <DaemonFC> I've been running 2.6.29 since rc5
[02:08] <twb> Ubuntu has a branch of a package (midori) I maintain for Debian.  How do I find out who maintains this branch?
[02:09] <dtchen> twb: as a universe source package, MOTU do collectively. See #ubuntu-motu
[02:09] <twb> dtchen: well, nominally that's the case, but in the past I got the impression of other packages that there were one or two people who actually did the work.
[02:09] <twb> I'll take it to -motu, thanks.
[03:10] <DaemonFC> sandeen: Just because I'm curious
[03:10] <DaemonFC> I'm going to download and install the Ubuntu kernel
[03:10] <DaemonFC> and compare bootup performance
[03:10] <DaemonFC> errr, wrong channel
[03:55]  * calc thinks a spiffy resource monitor like in win7 would be nice on gnome
[04:16] <calc> whoa win7 has no way to turn off, just hibernate and sleep from the look of it
[04:16] <maco> calc: not like vista where it has that little arrow thing to choose other options?
[04:16] <maco> ...i hope they at least encrypt pagefile.sys then
[04:17] <calc> it has options just none that equate to new boot the next time you turn on the system
[04:18] <calc> unless the main shut down button means off instead of hibernate
[04:18] <calc> it has sleep, hibernate, restart, logoff, etc
[04:19] <calc> it has "shut down" with an arrow beside it that you can select specific options
[04:23] <calc> ah i think that whatever it says on the main button is what it does, so it just doesn't show it in the menu
[04:24] <Amaranth> right, they got rid of the stupid button that did random things
[04:25]  * calc deletes win7 its slightly improved over vista but not worth the time
[04:26]  * calc will stick with xp for OOo testing
[04:26] <Amaranth> I'd say if you have to use windows it is at least the best choice
[04:26] <Amaranth> Or will be once they release it
[04:27] <calc> it still uses a lot more ram than xp
[04:27] <calc> and ubuntu :)
[05:48] <dholbach> good morning
[05:55] <slangasek> pitti: the changed conflicts in gnome-themes-ubuntu look wrong to me; eliminating the conflict based on the presumed contents of package versions that don't exist yet?
[05:55] <slangasek> dholbach: morning
[05:56] <dholbach> hiya slangasek!
[06:30] <pitti> Good morning
[06:30] <Hobbsee> morning pitti
[06:30] <pitti> slangasek: it's from one of the authors of community-themes, the themes we ship in ubuntu-themes now will be removed from there
[06:30] <pitti> slangasek: it's a little brittle, I know; if it concerns you, I'll revert this
[06:31]  * pitti hugs Hobbsee
[06:31] <slangasek> pitti: doesn't concern me enough to worry about a revert, just caught my attention while looking through the queue
[06:31] <Hobbsee> :)
[06:31] <pitti> slangasek: congratulations for the beta release!
[06:32]  * pitti didn't see it on the list yet, just spotted the topic
[06:32] <slangasek> on ubuntu-announce?
[06:34] <slangasek> thanks - looks like a pretty happy beta
[06:35] <StevenK> slangasek: I note UNR was not mentioned in the announcement, did I miss it?
[06:35]  * slangasek ponders the seahorse upload in the queue, which appears to break feature freeze and UI freeze
[06:35] <slangasek> StevenK: it was linked from the announcement; I didn't include explicit highlights for it
[06:36] <StevenK> It's in /releases/jaunty/beta which is what I care about. :-)
[06:37] <Mithrandir> congrats on the beta.
[06:37] <Hobbsee> siretart: ping?
[06:50] <pwnguin> i wonder why ubuntu-devel ML is considered an appropriate venue to broadcast to all Ubuntu Members
[06:51] <Hobbsee> pwnguin: it's not - it's just a member of the ubuntumembers team.
[06:51] <Hobbsee> pwnguin: it got sent to all ubuntu members too
[06:52] <pwnguin> ah
[06:53] <Mithrandir> the linkedin spam?
[06:53] <pwnguin> well that and hobbsee's lwn announcement
[06:53] <Hobbsee> Mithrandir: yeah
[06:54] <Hobbsee> pwnguin: it was copied from jono's blog, but yes
[06:54] <infinity> slangasek: Any qualms about me completely disabling antimony's cdimage cron for a bit (seems like less hassle than trying to surgically remove all the buildlive bits) while I upgrade the livefs buildds?
[06:55] <slangasek> infinity: disabled
[06:56] <infinity> slangasek: I was just going to save it and crontab -r, but that works too. :)
[06:57] <slangasek> this way we at least know if there's anything going on with some of the alternate builds
[06:58] <Mithrandir> infinity: you know the master copy is saved in /home/cdimage/etc/crontab?
[06:58] <infinity> Mithrandir: Yeah, but I'm all about preserving current state.
[06:59] <Mithrandir> next time you'll be telling me you have backups too
[06:59] <Mithrandir> s/time/thing/
[06:59] <infinity> Mithrandir: Having backups would involve "learning from my mistakes", which is something I'm less good at. :)
[07:00] <Mithrandir> :-)
[07:01] <infinity> Mithrandir: My general theory is that I make sure anything REALLY important lives on remote systems that someone else can worry about backing up.
[07:01] <infinity> Mithrandir: And if I lose any of my local stuff, it sucks, but I move on.
[08:10] <superm1> slangasek, i just uploaded a mesa upload that fixes bug 341898.  hopefully it won't be too late to re-roll disks with that?
[08:11] <slangasek> superm1: hmm, archive is already coming unblocked, and the livefs buildds are also currently down for maintenance :/
[08:11] <slangasek> so there'd be more of a delta wrt the rest of the beta than just mesa, by the time we could reroll
[08:11] <superm1> slangasek, oh :(
[08:13] <dholbach> please don't use<EMAIL_ADDRESS>in the Maintainer field, THANKS!
[08:14] <superm1> slangasek, okay well at least having it as a web update for those people post-install will be beneficial then.  i'll make sure our release notes are updated for that
[08:16] <siretart`> Hobbsee: pong
[08:16] <siretart`> morning, folks
[08:21] <pitti> hey siretart`
[08:21]  * siretart` hugs pitti :-)
[08:25]  * pitti hugs siretart` back, wie gehts?
[08:40] <dholbach> does anyone know why I'd have to run "LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype" to make video stuff in skype work?
[08:40] <dholbach> http://ubuntuforums.org/showthread.php?t=976467
[08:42] <james_w> because skype is closed source?
[08:42] <james_w> it can't be patched to decode the video stream now that the kernel no longer does it
[08:43] <siretart`> pitti: thanks, fine! (a bit tired, and we just had a blackout in the room students are writing their examination. A really fun friday morning here...)
[08:43] <siretart`> "vordimplom", of course...
[08:48] <dholbach> james_w: alright, thanks :)
[08:48] <mvo> pitti: in bug #347019 the attached log seems to be corrupted, do you have any idea if that is a apport upload problem?
[08:49] <mvo> (I have seen some of those corrupted logs)
[08:49] <dholbach> james_w: I wasn't saying that anybody of us is not doing their job properly - just wondered why I suddenly had to do it :)
[08:49] <james_w> dholbach: I couldn't resist the chance to troll now could I?
[08:49] <dholbach> james_w: hope you enjoyed it ;-)
[08:50] <james_w> are you using the latest version? I was under the impression that newer versions were fixed
[08:51] <dholbach> james_w: <IP_ADDRESS>-1
[08:51] <pitti> mvo: indeed, that's weird; never saw it
[08:52] <pitti> dholbach: ekiga! :-)
[08:52] <pitti> (while we are on the subject of trolling)
[08:58] <mvo> pitti: I think I saw it when I submited a bugreport with links or w3m (can't remember which one)
[08:59] <pitti> mvo: I submitted bug reports through w3m before
[08:59] <pitti> but no package install failures
[09:07] <dholbach> seb128: do you know of any strange bugs atm where metacity takes up a lot of CPU?
[09:09] <seb128> dholbach: no but I'm using compiz nowadays
[09:10] <seb128> didn't read any launchpad bug about that though
[09:10] <dholbach> ah ok
[09:11] <dholbach> seb128: seems my brother has the problem right now
[09:13] <seb128> dholbach: is he using the composite manager there?
[09:16] <seb128> dholbach: does it get it every time, ie does it come back if the restart it?
[09:16] <dholbach> seb128: no compositing manager
[09:16] <dholbach> seb128: he says he gets it since a few days
[09:17] <seb128> that's weird that package didn't change in a while
[09:17] <seb128> ie 1.5 month now
[09:18] <seb128> I would recommend opening a GNOME bug
[09:18] <seb128> be careful if you want to attach gdb to it don't do it from the running session
[09:18] <dholbach> seb128: I'm sure it's something else, what could be sources for that sort of mayhem?
[09:18] <seb128> that would freeze ie and let you no way to switch the focus or open anything on screen
[09:19] <seb128> dholbach: random guess X ....
[09:20] <seb128> brb session restart
[09:32] <DreadKnight> crap... totem crashing
[09:32] <DreadKnight> Segmentation fault (core dumped)
[09:35] <DreadKnight> actually here's a better error log http://paste2.org/p/172274
[09:40] <DreadKnight> miro not starting; error log http://paste2.org/p/172278
[09:48] <mvo> TheMuso: I uploaded a small fix for ubuntustdio-control, if you want it in bzr, please let me know, I will merge it then
[09:52] <mdz> cjwatson: where does /testing/jaunty/beta come from?  it differs from the email announcement in at least one important way (bug reporting instructions are wrong)
[09:53] <tjaalton> nxvl: looks like the change in aterm was wrong (remove the alternatives link to /usr/bin/aterm)
[09:54] <Mithrandir> me, unicode(1) is broken in hardy.
[09:57] <Mithrandir> anybody know why our python is compiled without support for wide unicode characters?
[10:07] <lool> bryce: Around?
[10:07] <lool> bryce: Pigment/Elisa upstream contacted me about a serious mesa issue with drivers using DRI
[10:07] <lool> bryce: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/349127
[10:08] <lool> bryce: It affects more than just elisa though; he says it's a recent regression, and would like it to be fixed for jaunty; he thought he had bisected a patch, but was incorrect
[10:08] <lool> bryce: Should I milestone this for final?
[10:08] <lool> bryce: I will leave it to you to decide and review a candidate patch if he finds one
[10:09] <seb128> bah
[10:09] <seb128> python2.6 is broken
[10:10] <seb128> $ python -c "import gtk"
[10:10] <seb128> ImportError: /var/lib/python-support/python2.6/gtk-2.0/glib/_glib.so: undefined symbol: PyUnicodeUCS4_DecodeUTF8
[10:10] <seb128> note to self, don't upgrade just after beta next time ;-)
[10:11] <seb128> that's going to be fun for users since update-manager can't start now
[10:11] <seb128> they will never get upgrades again
[10:11] <infinity> seb128: Is that broken in Beta, or a post-beta build?
[10:11] <crdlb> too bad update-notifier won't be able to notify them :P
[10:11] <seb128> infinity: post beta build
[10:11] <infinity> seb128: Ahh, could be worse then.  Quick, phone doko and yell at him. :P
[10:12] <seb128> infinity: I got a python2.6 update this morning I guess that's due to it
[10:12]  * infinity hopes this doesn't end up in some manual bootstrap annoyance...
[10:13] <james_w> doko is at pycon with limited connectivity
[10:13] <infinity> james_w: Convenient!
[10:13] <seb128> he should really learn to test upgrades
[10:13] <james_w> though enough connectivity to upload
[10:13] <seb128> or wait to be around before doing such changes
[10:13] <james_w> http://launchpadlibrarian.net/24209669/python2.6_2.6.1-1ubuntu4_2.6.1-1ubuntu5.diff.gz
[10:13] <directhex> if update-manager is broken, i wouldn't wait for doko
[10:13] <directhex> IMHO
[10:13] <james_w> -		--enable-unicode=ucs4 \
[10:14] <james_w> ^ that's my guess
[10:14] <seb128> yeah, I would guess so too
[10:14] <crdlb> do you think? :)
[10:14] <james_w> I can't see that it was intentional
[10:14] <seb128> but really he should be testing upgrades
[10:14] <seb128> *shrugù
[10:14] <seb128> james_w: can you test if that fix the issue?
[10:15] <seb128> I can sponsor the change
[10:15] <james_w> I don't have the issue yet :-)
[10:15] <seb128> upgrade python2.6 to current jaunty
[10:15] <james_w> doing so now
[10:15] <infinity> james_w: Neither of the two ./configure changes seem to reconcile with the changelog.
[10:16] <infinity> james_w: Though, maybe without-cxx was required for the debug build...
[10:16] <infinity> james_w: (or, removing it, rather)
[10:16] <tkamppeter> pitti, hi
[10:19] <mvo> changelog? why bother
[10:19] <directhex> changelogs are for people too lazy to read the source. evidently!
[10:19] <seb128> testing? why bother? ;-)
[10:19] <seb128> bug #349467
[10:21] <james_w> is it worth denying access to the broken package?
[10:22] <mvo> probably
[10:22] <james_w> is that something for IS?
[10:22] <mvo> it will look really bad if we release beta and the first update breaks all of our python gtk apps :/
[10:22] <mvo> yes
[10:22] <seb128> elmo, mdz, cjwatson: ^
[10:23] <seb128> mvo: the annoying part is that with the new update-manager design user will just never notice and never get any update
[10:23] <mdz> seb128: aren't you sitting a few meters away from elmo?
[10:23] <seb128> or rather they will not notice update-manager crashing
[10:23] <mvo> right :(
[10:23] <seb128> mdz: he's not there to be seen, dunno if he always work from the office
[10:24] <pitti> meh, python is broken
[10:24] <seb128> pitti: ^ read backlog
[10:24] <pitti> sorry, just rebooted
[10:24] <mvo> urgh, lets just revert the entire upload
[10:24] <mdz> seb128: on the phone with Ng right now
[10:24] <seb128> mdz: thanks
[10:25] <mdz> he's responding
[10:26] <maco> pitti: the backlog is "uh oh the update-manager is crashing like mad so itll never open"
[10:26] <mdz> seb128: on the plus side, update manager will only pop up after two weeks now by default, right? :-P
[10:27] <seb128> mdz: right, which means not many users should get the broken update ;-)
[10:27] <mdz> seb128,james_w: can you confirm unambiguously to Ng that the package to clobber is python2.6_2.6.2-1ubuntu5?
[10:27] <james_w> I would say libpython2.6 as well
[10:27] <seb128> let me downgrade to be sure
[10:27] <james_w> without taking the time to investigate which binary actually triggers it
[10:28] <Ng> ok
[10:28] <pitti> is that really python itself, or python-gtk?
[10:28]  * mvo builds a update that reverts the previous diff
[10:28] <pitti> python -c 'import gtk'  -> crashes
[10:28] <seb128> pitti: it's python itself, read backlog ;-)
[10:28] <pitti> importing other stuff works
[10:28] <mnemo> pitti: at least "aptitude changelog pygtk" shows no recent changes
[10:28] <mvo> hm, maybe its enough to rebuild pygtk?
[10:29] <seb128> pitti: doko dropped --enable-unicode=ucs4 from the configure option in the update
[10:29] <pitti> seb128: did we ascertain that reverting python will fix the problem?
[10:29] <pitti> oh, ok
[10:29] <pitti> thanks, I'll shut up now
[10:29]  * Ng detects some remaining ambiguity
[10:29] <james_w> mvo: that may be true, but I'd rather we knew what the extent of the problem was first
[10:29] <cjwatson> mdz: newz2000 copies it from JauntyJackalope/TechnicalOverview
[10:30] <mvo> james_w: agreed, good point
[10:30] <Ng> I've blocked python2.6_2.6.1-1ubuntu5_amd64.deb and python2.6_2.6.1-1ubuntu5_i386.deb - is that not sufficient?
[10:31] <mdz> cjwatson: gar, I missed that one
[10:31] <james_w> Ng: libpython2.6 of those versions as well please
[10:31] <Ng> ok
[10:31] <mdz> Ng: confirmed what james_w says
[10:31] <cjwatson> mdz: are you correcting it or shall I?
[10:31] <mdz> cjwatson: I have corrected the wiki page, but do not know how to update the website - do you?
[10:31] <cjwatson> mdz: "wait for newz to get up", I think
[10:32] <mdz> cjwatson: I used to have the necessary super powers
[10:32] <cjwatson> mdz: I don't think it can be that urgent, directions to bugs.launchpad.net/ubuntu/+bugs have been around for years
[10:32] <seb128> Ng, mdz: python2.6 and python2.6-minimal
[10:32] <seb128> downgrading those fix the issue
[10:32] <mdz> cjwatson: no, it's not urgent
[10:32] <mdz> Ng: python2.6-minimal as well please
[10:32] <cjwatson> I used to have website editing ability as well, but they took it away at some point
[10:32] <Ng> mdz: done
[10:32] <seb128> Ng: thanks!
[10:33] <james_w> thanks Ng
[10:35] <mdz> can someone prepare a python2.6 upload which reverts the patch, so we can test it?
[10:35] <seb128> mdz: I think mvo is on it
[10:35] <mdz> mvo: confirm?
[10:35] <mvo> mdz: uploaded already
[10:35]  * seb128 hugs mvo
[10:36] <james_w> oh, thanks mvo
[10:36] <mdz> mvo: bless you.  reverting the patch fixed it for you?
[10:36] <seb128> james_w: reading backlog even if a pygtk rebuild was enough that's a compatibility breakage
[10:36] <mnemo> ah, apport is written in python too right so that's why apport fails to report this PyUnicodeUCS4_DecodeUTF8 bug... man that's a really nasty bug, it both breaks update manager so you cant get a fixed version and it also breaks apport so you cant report the bug :)
[10:36] <infinity> mvo: I'll push the build ASAP as soon as it's actually accepted.
[10:37] <mdz> is there a bug report open about this yet?
[10:37] <mvo> mdz: I just upload -0ubuntu4 again with a higher version number (and the changelog from doko). that is the version we shipped in beta and there were no issues
[10:37] <seb128> mdz: bug # 349467
[10:37] <mnemo> mdz: https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/349467
[10:37] <seb128> mdz: bug #349467
[10:37] <mvo> bug number is what seb128 said (he is just too fast :)
[10:37] <james_w> infinity: is it in the archive admin queue?
[10:37] <infinity> james_w: Shouldn't be, we're not frozen.
[10:37]  * mdz adjusts the importance somewhat ;-)
[10:38] <mdz> cjwatson: can you confirm that mvo's upload is on its way?
[10:38]  * infinity checks the queues anyway.
[10:39] <cjwatson> mdz: it's in the incoming queue, yes
[10:39] <infinity> Yeah, it's just waiting on the :40 cron run.
[10:40] <cjwatson> the publisher's still running, so I don't think there's any point in me byhanding it
[10:40] <infinity> Nah, there's not.  It needs to build anyway.
[10:41] <infinity> (And building doesn't rely on the source being published)
[10:41] <cjwatson> right
[10:41] <infinity> There we go.  Pending.
[10:41]  * infinity fiddles build records.
[10:41] <mdz> mvo: is there any workaround for people who are affected?
[10:42] <mnemo> upgrade using apt-get maybe?
[10:42] <mvo> yeah, apt-get or aptitude or synaptic
[10:42] <mdz> should work once the update is available
[10:42] <mvo> or downgrade
[10:42] <mvo> if its still in their /var/apt/cache/archives
[10:42] <mvo> I don't know anything else
[10:42] <mdz> has anyone been in touch with doko?
[10:43] <seb128> james_w said that he's at a conference
[10:43] <mdz> oh, he's gone to PyCon, hasn't he
[10:43] <mdz> gah
[10:44] <mdz> mvo: how will the dist-upgrader react to the 403?  will it roll back?
[10:45] <tkamppeter> piiti, in bug 348427 the OP tried to add an Apport log to the bug and Launchpad told that it is too long.
[10:45] <mvo> mdz: it will error out and people will not be able to upgrade. but it will just roll back to the previous system state (so no harm done)
[10:45] <mdz> mvo: thanks
[10:45] <mvo> mdz: I'm testing this to be 100% sure now, but I'm 99% confident
[10:46] <lool> python2.6 forbidden download?
[10:46] <mvo> lool: yes, break pygtk
[10:46] <mvo> s
[10:46] <lool> k
[10:47] <mdz> lool: bug 349467
[10:47] <pitti> tkamppeter: 'add' -> 'attach'?
[10:47] <infinity> mdz, mvo, cjwatson: It's building on the primary arches at least.
[10:48] <tkamppeter> pitti, I only saw
[10:48] <tkamppeter> I followed the suggestion in https://wiki.ubuntu.com/DebuggingPrintingProblems and attached the bug report below, but Launchpad things this is too long.
[10:48] <ogra> Keybuk, cjwatson, i want to report the "useradd doesnt cope with date set to 01011970" bug, do you guys remember what package we exactly identified to be at fault ?
[10:48] <tkamppeter> I do not know what he actually did.
[10:49] <cjwatson> ogra: shadow, IIRC
[10:49]  * ogra was hit by that bug on the NSLU2 install as well yesterday
[10:49] <ogra> ok
[10:50] <pitti> tkamppeter: perhaps he tried to paste the entire log into a comment
[11:00]  * ogra filed Bug #349504
[11:04] <cjwatson> mvo: I realised last night that we forgot to do anything about bug 290234 despite it being in the 8.10 release notes
[11:04] <cjwatson> mvo: I'm testing a tiny apt patch for it now
[11:04] <infinity> ogra: Heh.  I noticed that when netbooting my arm buildds over and over again until I got ntpdate happy. :)
[11:04] <assasusonic> hi everyone
[11:04] <ogra> heh
[11:04] <assasusonic> where can i get the beta build in order to have a test run?
[11:04] <ogra> infinity, yeah, i have a bunch of arm devices without NIC ... there i have to set the hwclock manually
[11:05] <cjwatson> assasusonic: http://www.ubuntu.com/testing/jaunty/beta
[11:05] <mvo> cjwatson: oh, right. thanks for taking care of this
[11:05] <infinity> ogra: Ick.
[11:05] <cjwatson> assasusonic: where did you manage to find an announcement of the beta that *didn't* include download URLs? :-)
[11:05] <maco> so uh, i just got about 15 emals saying the pidgin debdiff i sent for uploading error'd on translations...but i didn't change the translations. what gives?
[11:06] <tjaalton> lool: about bug 349127; sounds weird, since for me it's the opposite, nvidia is broken because of vdpau, and they say the colors should be fixed in the app configs
[11:06] <cjwatson> maco: is it just telling you that you didn't update po-revision-date?
[11:06] <tjaalton> lool: so maybe the elisa guys are optimizing for the wrong driver ;)
[11:06] <mnemo> tjaalton: I can repro the greenish video on intel G45
[11:07] <tjaalton> mnemo: what player?
[11:07] <maco> cjwatson: yes. can i ignore that?
[11:07] <cjwatson> maco: yes, you can - that's a known lp bug for which a fix is in progress
[11:07] <maco> cjwatson: ok, thanks
[11:07] <mnemo> tjaalton: I was using the video.py sample from the pigment-python library
[11:07] <mnemo> tjaalton: pigment is the toolkit that elisa uses
[11:07] <assasusonic> cjwatson: on distrowatch
[11:08] <cjwatson> maco: bug 331094
[11:08] <tjaalton> mnemo: ok
[11:08] <maco> cjwatson: thanks
[11:08] <assasusonic> well i keep getting error 503
[11:08] <cjwatson> assasusonic: I just checked, distrowatch has the download URLs quite prominently
[11:09] <assasusonic> cjwatson: error 503 all the time
[11:09] <cjwatson> though for some reason they are linking to obscure mirrors
[11:09] <BUGabundo> pitti: ping
[11:09] <cjwatson> assasusonic: use the links in the URL I gave (there are several alternatives) or use the bittorrent downloads
[11:10] <BUGabundo> can't do much for bug 347874 now! bug 349462 is messing things
[11:10] <cjwatson> assasusonic: their primary links are to mirrors we don't operate
[11:10] <infinity> mvo: A bit late now, but disabling the test suite on that build might not have made me terribly sad.
[11:10] <infinity> mvo: You know, future reference for the next time you need a lightning revert on python. :)
[11:10] <assasusonic> cjwatson: good idea, didn't think about torrents
[11:10] <mvo> infinity: yeah, sorry for that - I think it would have been a good idea
[11:11] <mvo> I was not aware that it takes *that* long
[11:11] <infinity> mvo: Halfway through the suite on the fast buildds now anyway, so no point "fixing" that.
[11:12] <mnemo> infinity: if there is a test suite, how come this crippled version got through in the first place?
[11:12] <cjwatson> because the test suite doesn't catch this one, of course :)
[11:12] <cjwatson> it only tests python itself rather than its interaction with pygtk ...
[11:12] <infinity> mnemo: Two reasons... 1) The suite disables/ignores tests based on configure options... And more importantly, 2) I'm pretty sure the package ignores suite failures. :P
[11:12] <mdz> mnemo: the crippling issue is that this version broke compatibility with extension modules
[11:13] <wgrant> Is it actually crippled, or did it just break ABI due to the Unicode format change?
[11:13] <mdz> mnemo: the modules built with python itself (and tested by the test suite) naturally aren't affected
[11:13] <mdz> wgrant: the latter
[11:13] <wgrant> mdz: Right.
[11:13] <wgrant> So the test suite couldn't catch it.
[11:13] <infinity> wgrant: ABI break, as well as breaking anything relying on certain unicode functions... But the suite wouldn't catch the former, and probably doesn't test the latter when said functions are intentionally disabled.
[11:13] <geser> what about packages which got build with the "broken" python? need they a check if they still work with the fixed python?
[11:14] <mdz> geser: good point, we should check if there are any such packages
[11:14] <wgrant> infinity: Mm, indeed.
[11:14] <mdz> infinity: can you check if any extension modules were built with -1ubuntu5?
[11:15] <infinity> mdz: I'll look into it.  That might require cprov DB magic.
[11:15] <mnemo> I guess/hope somebody will write a sanity test that runs on each upload that makes sure this bug can't happen again
[11:17] <infinity> mdz: cprov and I are on it.
[11:18] <mdz> infinity: thanks
[11:23] <mvo_> mdz: just confirmed that update-mnager on release upgrade will show a error (403) but rolls back just fine
[11:23] <pitti> BUGabundo: I know, just wait until the fixed python is in
[11:23] <mdz> mvo_: thank you
[11:23] <BUGabundo> okay
[11:28] <mdz> seb128: have you notified pedro about the python2.6 issue?
[11:29] <seb128> mdz: he didn't start his day yet
[11:29] <seb128> mdz: I will do when he's online
[11:29] <mdz> I guess he will want to know about it when he starts looking at bugs :-)
[11:29] <seb128> right
[11:29] <seb128> good point, I will do when he's there
[11:29] <BUGabundo> really bad timing ... since its beta! ppl will be lockout of updates if they get it!
[11:30] <BUGabundo> hope not to many new users testing beta! or they will learn the hard way how to use CLI and APT eheh
[11:30] <seb128> BUGabundo: the binaries have been blocker for download
[11:30] <seb128> blocked
[11:31] <BUGabundo> I got them
[11:31] <BUGabundo> and so may have users who upgraded before the 403
[11:31] <BUGabundo> or if some mirrors have rsynced them
[11:31] <seb128> BUGabundo: right, some have
[11:31] <seb128> nothing we can do about that now
[11:31] <BUGabundo> yep
[11:31] <BUGabundo> np, we are aware on +1
[11:31] <BUGabundo> and letting users go their way, just fine
[11:32] <seb128> they can easily use synaptic to upgrade though
[11:32] <BUGabundo> seb128: New Users is the key word
[11:32] <BUGabundo> synaptic is a bit advanced for them
[11:32] <Laney> seb128: I will review and sponsor libpst shortly
[11:32] <BUGabundo> but then again UM and Update-notifier now don't work
[11:32] <seb128> BUGabundo: right, but as said not a lot else we can do for those who have the new version
[11:33] <BUGabundo> so probably they will update in a week
[11:33] <seb128> Laney: thanks!
[11:33] <infinity> mdz, cjwatson: What do we want to do about binaries that were built with the bad python?  Blind rebuilds?
[11:33] <james_w> BUGabundo: we can publish instructions about fixing up the problem once it is fixed
[11:34] <james_w> infinity: anything Architecture: any might as well be rebuilt
[11:34] <mdz> james_w: I updated the description of the bug with preemptive instructions for when the update is available
[11:34] <mdz> infinity: james_w++
[11:34] <james_w> ah, thanks mdz
[11:34] <BUGabundo> james_w: unfortunately new users DON'T subscribe to announce ML
[11:34]  * james_w realises he isn't subscribed
[11:34] <mdz> I think an email to ubuntu-devel-announce is probably in order
[11:35] <BUGabundo> mdz: unfortunately new users DON'T subscribe to announce ML
[11:35] <james_w> BUGabundo: I didn't say where
[11:35] <mdz> BUGabundo: you said that already.  if you want to post somewhere else, please feel free.
[11:35] <BUGabundo> eheh even james isn't
[11:35] <maco> mdz: agreed
[11:35] <james_w> and we can spread the information around
[11:35] <infinity> james_w: Okay, looks like our only arch:any fallout is python-hildon on lpia.
[11:35] <maco> maybe devel-discuss as well?
[11:35] <BUGabundo> is any forum moderator around?
[11:35] <maco> with a pointer to please subscribe to -announce
[11:35] <BUGabundo> most new users go there!
[11:35] <mdz> maco: agreed
[11:35] <maco> BUGabundo: me!
[11:35] <BUGabundo> maco can you push the info there?
[11:35] <dholbach> BUGabundo: microblog it! :)
[11:36] <maco> yep
[11:36] <mnemo> the most important thing is to create a regression test at the gates so that this cannot happen again... a bug that breaks both update-manager and apport at the same time is worth taking some time to prevent
[11:36] <BUGabundo> dholbach: was jyust going to do it
[11:36] <BUGabundo> LOL
[11:36] <maco> dholbach: james did and 3 of us have redented it
[11:36] <mdz> mnemo: yes, though that can wait until next week
[11:36] <maco> anybody still using twitter?
[11:36] <maco> the twitter ubuntu users should be told too...
[11:37] <BUGabundo> done
[11:38] <BUGabundo> just got done on identica jaiku, qaiku, twitter
[11:38] <BUGabundo> identica got it 4x
[11:38] <mdz> dholbach: james_w could you hit the mailing lists?
[11:38] <mdz> er, one of you ;-)
[11:38] <BUGabundo> we need users, annount, devel-discuss
[11:38] <BUGabundo> I don't have permitions for announce
[11:38] <james_w> mdz: sure thing, I was going to wait for the fixed binaries to be available at least on the primary mirror, what do you think?
[11:39] <maco> http://ubuntuforums.org/forumdisplay.php?f=352 <-- hows that?
[11:39] <dholbach> james_w: sounds like a good idea
[11:39] <BUGabundo> maco: please state its BETA
[11:40] <BUGabundo> it will grab more attention
[11:40] <james_w> maybe this would be a good time to re-visit bug 240445 :-)
[11:40] <maco> its in the jaunty forum
[11:40] <BUGabundo> and mention the bug report
[11:40] <BUGabundo> and copy the instructions
[11:40] <maco> ok the dent version is all ive seen so far, so lemme scroll up and find what youre talking about
[11:40] <wgrant> maco: Can we point other threads to that for instructions when it's fixed?
[11:41] <maco> wgrant: i'm going to lock it but any mod can update it while its locked
[11:41] <mdz> james_w: ok by me
[11:41] <wgrant> maco: Great.
[11:42] <BUGabundo> ok even twitter has now been hit twice
[11:42] <BUGabundo> that just leaves MLs
[11:42] <maco> ok i cant find the long version of the instructions
[11:42] <infinity> james_w: While you're feeling helpful, want to do a rebuild-only upload of python-hildon?  I've already ensured the buildds won't build anything against the broken python.
[11:42] <BUGabundo> maco bugs 277903
[11:42] <maco> what am i supposed to say for the -v on that thread?
[11:43] <BUGabundo> bug!! worng bug
[11:43] <dholbach> bug 349467
[11:43] <james_w> infinity: sure thing
[11:43] <BUGabundo> thanks
[11:44] <BUGabundo> maco:  users are already asking for more info on the forum
[11:44] <maco> i see that
[11:44] <maco> i just locked it and replied to the one asking about un-upgrading with a dpkg --force-downgrade explanation
[11:45] <BUGabundo> thread closes
[11:45] <BUGabundo> *closed
[11:45] <BUGabundo> "The problem is corrected in version 2.6.1-1ubuntu5.1. Note that since Update Manager is one of the affected programs, users affected by this bug will need to upgrade using apt-get in a terminal: $ sudo apt-get update && sudo apt-get dist-upgrade"
[11:45] <BUGabundo> from the bug report would suffice!
[11:46] <lool> tjaalton: erf :)
[11:46] <lool> tjaalton: let's just forget about nvidia, but it affects the opensource dri drivers; at least mplayer gl output and elisa
[11:46] <tjaalton> lool: yeah, hopefully 7.4 fixes it
[11:46] <cjwatson> mm, I don't think we need to advertise --force-downgrade here, it could get pretty complicated
[11:46] <lool> tjaalton: I'm counting on them to identify the issue though; they say the upstream tree works
[11:46] <lool> tjaalton: are we moving to 7.4??
[11:46] <tjaalton> lool: hope so
[11:46] <tjaalton> it's a bugfix release
[11:47] <lool> Crap, I told Intel we wouldn't
[11:47] <cjwatson> surely not a new upstream release of X for Jaunty now, after beta?
[11:48] <tjaalton> a bugfix release of mesa
[11:48] <tjaalton> we have the first devel release of that series
[11:48] <maco> BUGabundo: i didnt know the bug #
[11:48] <maco> BUGabundo: there were like 4 bugs linked
[11:48] <wgrant> maco: You could point out that python2.6 and python2.6-minimal are the relevant packages.
[11:48] <tjaalton> even numbered ones are bugfix releases
[11:48] <maco> cjwatson: ok, ill remove that
[11:48] <BUGabundo> maco all top new posts of the forum are related to python breakge
[11:49] <lool> bryce: Around the 17th of February you told we would go with 7.3?!?
[11:49] <tjaalton> lool: that was loong ago :)
[11:49] <tjaalton> no 7.4 in sight
[11:49] <lool> Yeah, but I committed to it for Intel developing their psb driver
[11:49] <tjaalton> how does it concern psb?
[11:49] <lool> They have a mesa backend for it
[11:50] <cjwatson> 17th of February> i.e. before feature freeze, which now is distinctly not
[11:50] <mdz> python2.6 is built for amd64, i386 still building
[11:50] <tjaalton> ok, so another release of a devel series of mesa?
[11:50] <maco> alright alright, the thread now says what buga posted along with "your mirror might not have it yet. here's how to check" and apt-cache policy stuff
[11:50] <mnemo> the most important thing is to create a regression test at the gates so that this cannot happen again... a bug that breaks both update-manager and apport at the same time is worth taking some time to prevent
[11:50] <mnemo> ops sry
[11:51] <tjaalton> I won't waste time merging it if there's no hope to get it in
[11:51] <mnemo> didnt mean to retype that :o
[11:51] <cjwatson> the only facilities we have for testing are things which are done in the package build
[11:52] <cjwatson> in general a package build can do pretty extensive things, but python can't easily go off and install pygtk
[11:52] <maco> BUGabundo: people dont read the danged stickies *grumble*
[11:52] <lool> tjaalton: I personally don't want to judge the quality of 7.3 versus 7.4; I don't have the slightest idea of the size of the diff between one and the other, it's just that I'm a bad position that I confirmed we would use 7.3 devel release -- which actually surprized Intel folks
[11:52] <cjwatson> so the test would have to be quite carefully targeted
[11:53] <mdz> tjaalton,lool: this is probably worth discussing on ubuntu-devel@, surely not something we would take a quick IRC decision on
[11:53] <lool> Anyway it's looking unlikely that we get psb *in* jaunty so probably no weight in release matters
[11:53] <lool> tjaalton: If you think there's value for mesa 7.4, can you bring it up on @-devel?
[11:53] <tjaalton> mdz, lool: ok, I'll see what the diff looks like and post something
[11:54] <tjaalton> but upstream is very strict to only include bugfixes
[11:54] <tjaalton> for instance they declined to bump the max texture size for i965
[11:54] <tjaalton> er, include the commit to bump it
[11:56] <mdz> tjaalton: even bugfix releases can have massive regressions :-)
[11:58] <tjaalton> mdz: yes, but in this case I doubt it could go worse ;) (there are a number of bugfixes for intel)
[11:58] <mdz> pitti: where can I get a copy of your mutt config which colors the index according to bug status etc.?
[12:01] <pitti> mdz: http://piware.de/tmp/muttrc
[12:02] <mdz> pitti: thanks!
[12:02] <pitti> mdz: you're welcome
[12:03] <pitti> mdz: the original idea is from bryce, but I don't see his config on his people.u.c.
[12:08] <jpds> mdz: Prehaps: http://bryceharrington.org/files/lp-mutt-colors ?
[12:09] <infinity> mdz: Publishing i386, amd64, lpia, and hppa right now.
[12:10] <mdz> infinity: thanks
[12:15] <geser> https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027019.html has an example how to do the colouring in mutt based on the LP header instead of scanning the whole body
[12:17] <mdz> geser: that's handy
[12:17] <mdz> and more accurate
[12:19] <mdz> geser: there is a typo on the second line (mismatched single/double quote)
[12:20] <mdz> it doesn't match duplicates though
[12:20] <mdz> that doesn't seem to be in the headers
[12:21] <Mirv> Ng: (ping blog.ubuntu-fi.org fixing?)
[12:29] <mnemo> infinity: how long until I should be seeing the python fix in apt-get ?
[12:29] <infinity> mnemo: 20ish minutes, maybe?
[12:29] <infinity> mnemo: I'll poke #-devel when it's pushing to mirrors.
[12:29] <mnemo> okok
[12:29] <mnemo> great
[12:32] <BUGabundo> nice to know
[12:34] <Mirv> (well, I was on wrong channel but anyway, message delivered)
[12:43] <slytherin> Considering that grub-installer is supposed to offer grub2 as an option, shouldn't grub2 be in main?
[12:49] <liw> mvo_, https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/147758 looks like a temporary problem in some packages in gutsy beta, since fixed, and could be closed -- do you agree?
[12:53] <mvo_> liw: agreed
[12:56] <seb128> liw: can you get those computer-janitor translation issues fixed to jaunty
[12:56] <liw> seb128, aye, I'll do that next
[12:56] <seb128> thanks
[12:56] <BUGabundo> do 8.04 users upgrading also get it by the python bug?
[12:57] <infinity> New python2.6 binaries are being pushed to mirrors, FWIW.
[12:58] <james_w> thanks infinity
[12:58] <seb128> infinity: when will the index be updated?
[12:58] <infinity> seb128: As in Packages.gz?
[12:59] <seb128> infinity: ie when can I apt-get update and get those?
[12:59] <seb128> infinity: yes
[12:59] <infinity> seb128: It's updated too.
[12:59] <infinity> seb128: Just a question of when the mirror pulse is done.
[12:59] <seb128> infinity: apt-get update doesn't agree
[12:59] <seb128> oh ok
[12:59] <infinity> seb128: Yeah, cause you're not using cocoplum. :)
[12:59] <seb128> right
[12:59] <infinity> seb128: Give it a few minutes at least. :P
[13:00] <liw> hm, launchpad doesn't show the bug to me anymore
[13:00] <apw> pitti, in the unlikely event you go to review my suspend-apport fixes branch, could you just hold off.  i may have just figured out how to trigger the apparent false-positive
[13:02] <cjwatson> slytherin: grub-pc is in main, and that's the package grub-installer actually installs. grub2 is a transitional package.
[13:02] <pitti> apw: oh, I didn't get a merge request, so I wasn't going to
[13:02] <cjwatson> slytherin: see e.g. 'apt-cache show grub2'
[13:02] <pitti> apw: I'm currently working on apport, though, I'll probably do another upload today
[13:02] <apw> ok thanks ... i have something which is triggering falsies, if you would could you check in with me before you close the upload
[13:03]  * liw seems to have entangled himself in too much launchpad complexity (long url, complicated search) and goes back to simple search
[13:03] <pitti> apw: check what?
[13:03] <apw> just let me have a chance to sneak a change in if its ready :)
[13:04] <pitti> apw: sure, no problem
[13:04] <apw> the bug has been causing a lot of false reports, or so it was thought, if its found to be really false
[13:04] <apw> it would help to get them squashed, a simple 1 line fix
[13:04] <apw> though i may have just figured out how it really can be triggered.  if so its real
[13:05] <BUGabundo> apw: btw after suspend/resume cycle I got a kernel oops window asking me to report it!
[13:05] <BUGabundo> is that normal?
[13:06] <apw> after a good one?  what was the oops?  too slow?
[13:07] <Mithrandir> pitti: hmm, vaguely offtopic here, but I'll risk it.  What's really the purpose of the indicator applet?  Its description is roughly "display stuff", which doesn't say why it's useful and why I want it on my panel.
[13:08] <BUGabundo> apw: no idea!
[13:08] <BUGabundo> the window wasn't very clear
[13:08] <BUGabundo> only showed two lines of text at time
[13:08] <BUGabundo> making it hard to read
[13:09] <slytherin> cjwatson: right, my mistake. sorry for bothering.
[13:09] <directhex> Mithrandir, you don't like stuff?
[13:09]  * apw watches to see if Mithrandir gets an answer ... as i have an envelope in there and it won't go away
[13:09] <pitti> Mithrandir: it tells you about incoming pidgin messages, or mails from evo (doesn't work for my setup, though)
[13:09] <BUGabundo> apw: I did send it, so you should have a log of it some where!
[13:09] <mnemo> python fix available through main apt-get (not sure about mirrors)
[13:09] <BUGabundo> lunch now... back latter
[13:10] <pitti> Mithrandir: it's not doing a lot yet, though
[13:10] <seb128> pitti: it indicates emails count from evolution for INBOX only and when evolution is not focussed when you do receive those
[13:11] <seb128> ie, click send&receive, switch workspace
[13:11] <pitti> ah, ok
[13:11] <pitti> I don't keep evo open
[13:11] <pitti> I had expected it to listen to e-d-s
[13:11] <seb128> e-d-s doesn't do emails right now
[13:12] <Mithrandir> pitti: I removed it from the panel, but I still seem to get notifications just fine?
[13:12] <seb128> Mithrandir: it's orthogonal to notifications
[13:12] <pitti> Mithrandir: yeah, notifications and messaging indicator are orthogonal
[13:13] <apw> pitti, if it shows an envelope forever is that something i should file as a bug
[13:13] <pitti> apw: please do
[13:13] <pitti> apw: it seems to be erratic for me
[13:14] <pitti> sometimes I have the envelope with just "pidgin" in it
[13:14] <pitti> sometimes (like just now), I don't
[13:14] <Mithrandir> I have the envelope with just pidgin, since I don't use evo.
[13:14] <seb128> you should get the icon when pidgin is running
[13:14] <Mithrandir> and it looks like it's highlighted all the time, which is odd.
[13:15] <apw> yeah i think it has an odd box round it or something
[13:15] <pitti> well, I shouldn't really get both the pidgin and MI icon in my tray
[13:15] <seb128> Mithrandir: the idea is that unread messages will be listed in the applet
[13:15] <seb128> with the timestamp of when you received those
[13:15] <Mithrandir> pitti: sorry for being dense, what do you mean by notifications and messaging indicator are orthogonal?  It should basically duplicate what the pidgin icon in the tray is doing already?
[13:15] <mdz> I've got the python update, and can confirm that it doesn't break the world (I never installed the broken version)
[13:15] <apw> seb128, so its interaction with pidgeon must be broken as i have none
[13:16] <mnemo> i had the broken python and the update fixed by system... totem, apport and update-manager now works again
[13:16] <Mithrandir> seb128: should it then always have an icon visible when I don't have any "unread" messages in pidgin?
[13:16] <seb128> mdz: how did you do that! is there a proxy in the office or something? I still don't get it there
[13:16] <seb128> Mithrandir: yes, an email icon
[13:16] <pitti> Mithrandir: notifications are the bubbles that pop up if something happens; MI collects instant messages/emails which you got while you were away/not seeing evo/pidgin window
[13:16] <seb128> when you have something unread you get an another icon
[13:16] <mdz> seb128: I got it from archive.ubuntu.com
[13:16] <mnemo> seb128: do you have a mirror configured in software sources?
[13:17] <mnemo> (i got if from apt-get)
[13:17] <seb128> Mithrandir: in new installs pidgin has no notification area icon
[13:17] <mdz> seb128: I am at home
[13:17] <seb128> Mithrandir: the indicator is the way to open the buddy list
[13:17] <Mithrandir> seb128: ok, that makes more sense then, except the icon is about three times as wide as any other icon.
[13:17] <seb128> mnemo: no
[13:17] <Mithrandir> and it has a border around it.
[13:17] <seb128> Mithrandir: that's a bug ;-)
[13:17] <Mithrandir> (and is drawn in a different style than all my other icons.)
[13:24] <slytherin> Mithrandir: in short, you could say it does not match other icons from the theme. :-D
[13:26] <liw> so is there a package I can download to fix the Python "PyUnicodeUCS4_DecodeUTF8" problem while waiting for my mirror to get updated?
[13:27] <ScottK> liw: Presumably you get get the .deb off of LP.
[13:27] <Mithrandir> liw: it's updated on archive.u.c now, so just use that?
[13:27] <liw> Mithrandir, duh, of course
[13:56] <ma10> sd
[13:57] <mdz> slangasek: release meeting in a few?
[13:57] <slangasek> mdz: yes
[13:58] <pitti> hey slangasek
[14:03] <asac> ogra: you saw that font regression for which we added the "no-bitmaps" thing
[14:03] <asac> ogra: do you remember which site?
[14:04] <apw> pitti was there a bug for the 'tags arn't very sensible on suspend/hibernate/resume apport bugs' do you know
[14:05] <pitti> apw: I haven't seen one
[14:05] <pitti> I don't think so
[14:05] <apw> ok tha
[14:05] <apw> t
[14:05] <apw> thanks, will make one
[14:05] <pitti> thanks; please sub me to it
[14:20] <kwwii> cjwatson: funky question, but it's only happened to me once and I can't exactly test the experience. Assuming you are the person to ask:  when you boot and there is a file system failure does it go back to a console and show the text or is it displayed on the usplash bg?
[14:21] <cjwatson> kwwii: pitti implemented this - but IIRC it's displayed as text in usplash
[14:21] <cjwatson> oh, if it actually fails, that drops you to a shell prompt
[14:21] <cjwatson> as in a non-correctable failure which requires manual action
[14:22] <cjwatson> this is in /lib/init/usplash-fsck-functions.sh
[14:22] <kwwii> cjwatson: right, exactly...that is what I thought. thanks!
[14:22] <pitti> right
[14:24] <sladen> kwwii: you can replicate this quite easily by selecting 'ext4' doing install ;)
[14:25] <sconklin> pitti: during an upgrade from intrepid to jaunty, when apport was updated It falsely detected a kernel crash and wanted to submit a report. Is there upgrade logic to avoid resubmitting old reports?
[14:25] <kwwii> sladen: lol, right...anything for documentation!
[14:26] <pitti> sconklin: hm, where did the kernel crash came from then?
[14:26] <pitti> sconklin: we don't currently have such a logic, no
[14:27] <pitti> sconklin: I guess we could teach update-manager to remove all .crash files on upgrades, but I'm not sure whether that would have some unintended consequences
[14:27] <sconklin> pitti: I'm trying to figure out. Sadly it was very early this morning and I just said 'no' before I thought to investigate.
[14:28] <sconklin> pitti: then it was certainly an old crash file left over from testing I was doing weeks ago. I'd hate for us to get resubmissions of things from upgrades.
[14:28] <sconklin> Plus, it might be confusing to some to get a "your kernel has crashed" pop-up during an upgrade
[14:29] <pitti> yeah, I wonder how that happened
[14:29] <pitti> if you saw the report before, it shouldn't have been showed a second time
[14:29] <pitti> sconklin: it could happen by something that touch /var/crash/*, but that sounds unlikely for any .postinst script
[14:30] <sconklin> pitti: what if the crash happened while the previous config was set to not submit, and the new one has that enabled by default?
[14:30] <pitti> sconklin: oh, of course; that would do it
[14:30] <pitti> sconklin: /etc/default/apport only controls the signal and python crashes
[14:31] <pitti> if something else writes .crash files, such as apw's suspend testing script, those wouldn't have been reported in intrepid
[14:31] <pitti> but then they were never displayed before
[14:31] <sconklin> I have a .crash file from the linsmith package in /var/crash
[14:32] <sconklin> But the dialog that popped up said kernel crash
[14:32] <apw> pitti, nope it doesn't
[14:32] <pitti> mvo_: how easy would it be to rm /var/crash/* on upgrades? I'm a little hesitant to do it in apport's postinst based on version comparison, since that would break backports
[14:32] <mvo_> pitti: trivial
[14:32] <mvo_> pitti: on release upgrades I assume?
[14:32] <pitti> mvo_: yes
[14:33] <mvo_> pitti: it just needs to check for the ones that happen during the upgrade I guess
[14:33] <sconklin> pitti: I vote for removing it. If we end up trying to debug reports against a system that's been upgraded since the crash, we could waste a lot of time
[14:33] <pitti> mvo_: I'm not really sure how else to do that without killing legitimate ones
[14:33] <mvo_> pitti: so rm right when the upgrade starts (before the first package is installed)
[14:33] <pitti> mvo_: is there a time when we know that we'll start the upgrade, but didn't install any packages yet?
[14:34] <pitti> mvo_: i. e. coudl they be removed at that time, so that we wouldn't loose package failures during upgrade, but get rid of old .crash reports/
[14:34] <pitti> sconklin: agreed
[14:34] <pitti> mvo_: exactly
[14:34] <mvo_> pitti: ok, I will add this
[14:35] <pitti> mvo_: want a bug report for this?
[14:35] <mvo_> pitti: no, I just add it now
[14:35] <BUGabundo> pitti: can't reproduce bug 347874 anymoe
[14:36] <pitti> mvo_: many thanks! *hug*
[14:36] <pitti> sconklin: ^ seems that's done then
[14:36] <pitti> BUGabundo: so much the better :)
[14:36] <BUGabundo> both from cli and double click it works
[14:36] <sconklin> nice, thanks!
[14:37] <BUGabundo> shall I or you close the bug?
[14:37] <pitti> BUGabundo: please do; thanks for checking again
[14:37] <BUGabundo> I could reproduce it repetedly during almost one week
[14:42] <directhex> hm, "could not install adduser" on an upgrade from intrepid
[14:43] <directhex> ditto libkeyutils1
[14:43] <directhex> lots of things infact
[14:52] <ScottK> directhex: Does it start with Python something not being installable?
[14:55] <marctww> Anyone here have experience with what looks like a redraw-bug with nvidia-177.82 driver in Ubuntu 8.10?
[14:55] <directhex> ScottK, i don't think so. i don't have the bad version available in apt-cache policy
[14:55] <ScottK> OK.
[14:56] <slangasek> dtchen: is bug #330814 the same as bug #343254?
[14:56] <marctww> any ideas?
[14:56] <directhex> "apt-get -f install" seems to have rescued dpkg from the brink of "aborting!"
[14:58] <marctww> ?
[15:02] <directhex> marctww, i know 180 drivers have a redraw bug. didn't think 177 did
[15:04] <marctww> yea :(
[15:04] <marctww> Apparently it does
[15:08] <marctww> directhex: it does man
[15:09] <directhex> terminals not updating properly?
[15:09] <sbeattie> seb128: can you look at the debdiff in bug 270374 (see comment 32) and see if its worth uploading or comment?
[15:09] <marctww> directhex: Not just terminals, everything.
[15:10] <marctww> Then after a while, window decorations fly out the window.
[15:10] <marctww> I restart X and world domination returns.
[15:10] <seb128> sbeattie: is there any hurry?
[15:12] <cjwatson> liw: FYI, Matthew Garrett got a patch into the kernel upstream to default to relatime unless you explicitly say strictatime
[15:12] <cjwatson> liw: so that may be less relevant in computer-janitor in future
[15:13] <sbeattie> seb128: only that I'd like to be able to stop tracking it (it's tagged as a regression) and have it fixed for jaunty; it has a debdiff that people claim works for them (which is a one-liner patch), so hopefully doesn't require significatn review.
[15:15] <seb128> sbeattie: it's on the sponsoring list and I will have a look but not right now
[15:15] <seb128> thanks for pointing it
[15:15] <hyperair> is anyone noticing that vim is not symlinked to vim.tiny in the livecd?
[15:15] <sbeattie> seb128: that's fine.
[15:15] <sbeattie> thanks.
[15:22] <directhex> yay, World of Goo no longer causes X to segfault. there's one Jaunty feature for the changelog
[15:22] <bluefoxicy> http://stackoverflow.com/questions/175854/what-is-the-funniest-bug-youve-ever-experienced/175997#175997
[15:22] <pitti> seb128: handling current i386 retracer failure (hash sum mismatch); I'll fix it properly this time
[15:23] <seb128> pitti: ok
[15:23] <bluefoxicy> ^^^ I don't know about that, but for the longest time I thought the icon for Update-Manager was supposed to be a representation of someone giving me the finger
[15:23] <bluefoxicy> like, for 2 whole releases
[15:25] <directhex> bluefoxicy, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276144
[15:27] <bluefoxicy> directhex:  haha
[15:28] <directhex> ooh, i have a new bug to file
[15:28] <directhex> which package contains those new gtk themes?
[15:29] <asac> heh cowsay fun.
[15:30] <directhex> asac, it was your bug!
[15:30] <cjwatson> hyperair: that was an intentional change; vim-tiny is much more like vi than vim. Just use vi
[15:30] <directhex> asac, back in 2004, when i were a lad
[15:31] <cjwatson>   * [f7bfa57] Don't install vim alternatives for vim-tiny.  vim-tiny is built
[15:31] <cjwatson>     to act like vi, so the vim alternative just causes more confusion than
[15:31] <cjwatson> from vim 2:7.2.049-1
[15:31] <cjwatson>     it's worth (by default).
[15:32] <hyperair> cjwatson: i see.
[15:32] <asac> directhex: yeah. 2004 feels like yesterday ;)
[15:32] <asac> to me
[15:32] <directhex> in 2004 i was just starting out, fresh-faced, on loonicks!
[15:32] <directhex> partly due to enhanced framerates in UT2004 compared to Windows
[15:33] <directhex> anyway, bug filin' time
[15:35]  * hyperair pokes dholbach -- bug #349678
[15:35] <dholbach> hyperair: I'm a bit busy right now - I hope somebody of the other sponsors will pick it up in a bit or I do it later on
[15:37] <hyperair> dholbach: oh okay
[15:40] <mterry> Does http://summit.ubuntu.com/uds-karmic/interest/ work for anyone?  Still says I'm not registered, but I registered quite a while ago
[15:43] <Keybuk> -Wextra is insane
[15:44] <Keybuk> "put braces around empty if statement" WHY?! WHY?! WHY SHOULD I DO THAT?!
[15:44] <calc> slangasek: do you have time to look at bug 299161?
[15:44] <cjwatson> ah, that one I agree with
[15:44] <cjwatson> if (foo); { } is an easy typo to make
[15:45] <cjwatson> but anyway, -Wno-empty-body
[15:52] <seb128> slangasek, pitti: opinion on the python-gnome2-desktop gnomeprint and gtksourceview1 binary splits
[15:53] <seb128> gnomeprint has 1 rdepends in the archive
[15:53] <seb128> gtksourceview 5 rdepends
[15:53] <seb128> I mean the python binding for those
[15:54] <Keybuk> cjwatson: but I don't do that
[15:54] <Keybuk> I do
[15:54] <Keybuk> if (foo)
[15:54] <Keybuk>     ;
[15:54] <Keybuk> it shouldn't warn about *that*
[15:54] <seb128> that would win us some space and allow to move libgtksource libgnomeprint libgnomeprintui out of the CD
[15:56] <pitti> seb128: getting rid of gnomeprint is a win by its own, too
[15:57] <cjwatson> Keybuk: yeah, I very much doubt the optimiser can spot that. I think I've probably attuned my coding style to -Wextra a little. :-)
[15:57] <cjwatson> optimiser? I mean whatever produces the warnings
[15:57] <cjwatson> it'll be working off the AST
[15:58] <Keybuk> -Wall -Wextra -Wno-empty-body -Wno-missing-field-initializers -Wno-unused-parameter
[15:58] <seb128> pitti: right, slangasek was just a bit concerned that the change might break thing which depends on the unsplitted versions out of the archive
[15:58] <Keybuk> seems the most sensible combination so far
[15:59] <pitti> apw: I'm about to do an apport upload; shall I merge anything?
[15:59] <pitti> apw: if not, don't worry, I can always upload another one (apport uploads are cheap)
[15:59] <apw> i am still testing ... will there be a chance for another upload later
[15:59] <apw> fair enough then
[15:59] <pitti> apw: I just want this update in ASAP, to get the retracer in top shape for the expected beta crash reporting flood
[15:59] <pitti> apw: sure, no hurry
[15:59] <apw> yeah don't wait if its something cool going in
[16:00] <Keybuk> cjwatson: I think I'd be less hateful about -Wempty-body if I didn't *also* use -DFORTIFY_SOURCE=2
[16:01] <pitti> seb128: okay, I think apport-retrace properly catches Packages.gz hash sum mismatches now
[16:01] <seb128> pitti: excellent
[16:02] <cjwatson> Keybuk: mm, that one I'm not going to attempt to justify :-)
[16:03] <directhex> oh hells yes. jaunty usplash seems to understand how not to look like distilled ass when faced with a high-res widescreen framebuffer
[16:03] <directhex> *there's* a reason to upgrade
[16:03] <Keybuk> though shouldn't if (foo); { } warn you about the anonymous block?
[16:03] <pitti> kwwii: ^ speaking about that, I noticed the same on my wife's 1920x1200 monitor; looks really good now
[16:04] <cjwatson> Keybuk: anonymous blocks are sometimes useful as a container for more-local-than-function-scope variable declarations
[16:04] <cjwatson> at least in pre-C99 code
[16:04] <Keybuk> cjwatson: but the syntax for anonymous blocks is ({ ... }) :p
[16:04] <kwwii> pitti: hehe, yeah..I added configs up to 1920 (the size of my new monitor)
[16:04] <Keybuk> tests/test_node.c:573: error: ‘node’ may be used uninitialized in this function
[16:04] <Keybuk> *sigh*
[16:05] <cjwatson> Keybuk: err, sorry, I misunderstood what you meant. { } in the example above is not an anonymous block, then
[16:05] <cjwatson> it's just a block
[16:05] <Keybuk> cjwatson: but you can't just have a block suspended in mid-air in C
[16:05] <directhex> who to thank for that...
[16:05] <cjwatson> sure you can
[16:05] <Keybuk> cjwatson: you really can't <g>
[16:05] <directhex> usplash (0.5.30) jaunty; urgency=low
[16:05] <directhex>  -- Martin Pitt <<EMAIL_ADDRESS> Wed, 04 Mar 2009 21:41:36 +0100
[16:05] <Keybuk> C != C++
[16:05] <directhex> cake for pitti!
[16:05] <cjwatson> Keybuk: cite
[16:07] <cjwatson> I can't find my K&R but I am quite certain it's valid
[16:09] <Keybuk> cjwatson: you may be right according to C99, sorry
[16:09] <cjwatson> I am right according to C89
[16:09] <Keybuk> then why do people use do { ... } while (0) when they're trying to be "standards compliant" ?
[16:09] <cjwatson> http://paste.ubuntu.com/139043/
[16:09] <cjwatson> people don't use that for standards compliance
[16:10] <apw> Keybuk, thats about making it behave like a statement
[16:10] <cjwatson> they use it so that macro expansion won't screw up
[16:10] <cjwatson> if (foo) BAR;
[16:10] <apw> right
[16:10] <Keybuk> apw: according to C99 a block *is* a statement
[16:10] <cjwatson> Keybuk: this is a FAQ
[16:10] <Keybuk> cjwatson: I don't follow?
[16:10] <cjwatson> Keybuk: it doesn't quite work the same in all contexts
[16:10] <cjwatson> let me dig up the reference for you
[16:10] <apw> Keybuk, yes, _but_ it has no ; at the end
[16:10] <apw> so a {}; is two statements
[16:11] <Keybuk> true
[16:11] <apw> a do{}while(0); is one
[16:11] <apw> and thats the reason
[16:11] <Keybuk> but an empty statement is allowed in C too ;)
[16:12] <cjwatson> why is the C FAQ site so slow just when I need it?
[16:12] <Keybuk> cjwatson: I was thinking the same thing ;)
[16:13] <cjwatson> oh yes of course
[16:13] <cjwatson> if (foo) BAR; else other(stuff);
[16:13] <cjwatson> misparse if BAR is just a block
[16:13] <Keybuk> ahh
[16:13] <Keybuk> that does make sense
[16:14] <apw> cjwatson, :)
[16:14] <Keybuk> cjwatson: neat, thanks
[16:15]  * Keybuk goes back to figuring out how to persuade gcc that the variable *really* cannot be used uninitialized and that it's silly optimiser is WRONG
[16:15] <apw> Keybuk, assign something to it at init and be happy
[16:16] <Keybuk> apw: yeah, but I keep having to do that all the time
[16:16] <Keybuk> and it annoys me
[16:16] <Keybuk> something about the optimiser doesn't like my "count mallocs and run that many times" loop
[16:16] <apw> the optimiser only looks to see if there is a route thorugh the code from the init to a use which has no init
[16:17] <apw> i doesn't work out if there is a possible route
[16:17] <Keybuk> but there isn't a route to one which has no init
[16:17] <apw> Keybuk, got an example
[16:17] <apw> pastebin it?
[16:18] <apw> if nothing else i can say, yep its stupid sorry
[16:18] <Keybuk> http://pastebin.ubuntu.com/139046/
[16:23] <cjwatson> Keybuk: (C FAQ 10.4, BTW)
[16:24] <cjwatson> now I've managed to get at it
[16:27] <apw> Keybuk, its stupid, so you have written some 'before and after' clauses for the thing
[16:27] <slangasek> seb128: does gnomeprint still have any reverse-deps, or was that fixed with the gnome-games upload?
[16:28] <sladen> apw: can't you just hit with an __attribute__ ?
[16:28] <slangasek> seb128: I think whatever I said before when we talked about this is probably still valid; I think that was "gnomeprint: yes, gtksourceview1: no"}
[16:29] <seb128> slangasek: what I said before, 1 rdpends for gnomeprint
[16:29] <Keybuk> apw: which is stupid? gcc or my macros? :p
[16:29] <apw> the compiler, i think what i am seeing is some code to put things before and after the block which will follow in the source
[16:30] <Keybuk> apw: exactly
[16:30] <apw> and it will happly analyse that as "if i take the first branch every loop then its not defined, bad"
[16:30] <apw> even though its patently false
[16:31] <Keybuk> but it isn't used in the first branch
[16:31] <Keybuk> the weird thing is that the simplest "int" expression of this I can do doesn't exhibit the bug
[16:32] <apw> right but you use it _after_ the loop
[16:32] <apw> so it can decide the output lloop only took the third way and the ineer only the first
[16:32] <apw> and that means you use unitialised data.  its wrong
[16:33] <Keybuk> right, it doesn't seem to observe that the inner if will always have all three expansions
[16:36] <Keybuk> but it's the outer loop it really seems to have an issue with
[16:36] <Keybuk> because the warning is still there if you take the inner loop out
[16:36] <Keybuk> TEST_ALLOC_FAIL {
[16:36] <Keybuk>   node = x;
[16:36] <Keybuk>   // do something with node;
[16:36] <Keybuk> }
[16:36] <Keybuk> fails ;)
[16:39] <slangasek> calc: is the comment in the bug description about needing gcc-4.1 still applicable?
[16:39] <slangasek> calc: because that would be a deal-breaker; gcc-4.1 is universe-only, and we're not going to re-promote it to get a newer memtest86+ in the archive
[16:40] <calc> slangasek: it was worked around by iirc colin with -O1 which made it work
[16:40] <calc> slangasek: yea colin fixed it with O1 in 2.01-1ubuntu2
[16:41] <slangasek> calc: ok, and that fix is verified to also solve the problem for 2.11?
[16:41] <calc> slangasek: yes, i tested it and it works
[16:41] <calc> slangasek: when miscompiled it shows up as lots of errors in the tests, i read through the bug report to check on that part
[16:42] <slangasek> calc: did you also test a known-broken version to be sure the problem manifests on your hardware? :)
[16:42] <calc> slangasek: this is essentially just a merge from debian with the only part still being applied being no stack protector
[16:42] <calc> slangasek: didn't test with -Os, no
[16:42] <mathiaz> stgraber: what's the state of openvz in jaunty?
[16:43] <calc> slangasek: i can recompile it in broken form to see if it fails in the same manner as the old version
[16:43] <slangasek> calc: might be a thing to try just to be sure; but not a blocker for the FFe
[16:43] <calc> ok
[16:44] <calc> i'll see what it does here in a minute
[16:48] <calc> ok, brb, going to test via my laptop
[16:48] <MacSlow> pitti, hi there
[16:48] <MacSlow> pitti, what's the latest time today to hand over a new release-tarball of notify-osd?
[16:48] <calc> slangasek: yep immediate failure with Os
[16:49] <slangasek> calc: ok, cool
[16:49] <calc> it works but it causes athe tests to fail
[16:49] <calc> so eg the ui shows up but as soon as the tests run continous red failure messages scroll by
[16:49]  * slangasek nods
[16:49] <calc> slangasek: what is the next step before i upload the package?
[16:50] <slangasek> calc: uh... sign it? :)
[16:50] <slangasek> calc: I acked the bug
[16:50] <calc> slangasek: oh ok :)
[16:50] <calc> slangasek: thanks
[17:05] <IntuitiveNipple> If I need to provide a custom-kernel for testing and the user is only able to use live-CDs, is it enough for me to replace the kernel images and supporting files in an ISO image, or will I also need to rebuild the casper squashfs?
[17:07] <jordi> Hi,
[17:08] <jordi> slangasek: I don't know how useful this would be or if it's way too late in the game for jaunty, but today I uploaded nano 2.0.9-2 which changes a default option by popular demand both in Debian and Ubuntu, and would fix issues Ubuntu people have been having with line wrapping in config files.
[17:08] <jordi> slangasek: http://packages.qa.debian.org/n/nano/news/20090327T123206Z.html
[17:09] <calc> slangasek: done
[17:15] <stgraber> mathiaz: I have someone looking into it here (Michael Jeanson) though we're mostly working on scripts for LTS releases rather than spending too much time on the kernel work for non-LTS releases
[17:15] <cjwatson> IntuitiveNipple: replacing the kernel image will be fine if the module ABI is compatible with the existing one, but otherwise you'll need to rebuild the squashfs to cope with the kernel modules in there
[17:15] <stgraber> mathiaz: upstream OpenVZ is willing to help for LTS releases, for others we could easily provide vanilla kernels patched with OpenVZ and some drivers from Ubuntu's kernel but patching on top of a regular Ubuntu kernel is almost impossible
[17:15] <cjwatson>    * As we're modifying the manpages, we need to temporarily build-dep
[17:15] <cjwatson>      on groff.
[17:15] <cjwatson> jordi: blink. why?
[17:16] <stgraber> mathiaz: due to a number of issues with apparmor and other big patches like that
[17:16] <cjwatson> do you ship postscript versions of the manual pages or something?
[17:16] <IntuitiveNipple> cjwatson: Thanks alot... that will help enormously then
[17:17] <cjwatson> jordi: it's a shame there's no --wrap option, if nowrap is to be made the default
[17:22] <pitti> MacSlow: I can still upload it
[17:22] <jordi> cjwatson: .html versions are generated at build time
[17:22] <pitti> MacSlow: is it released already?
[17:23] <cjwatson> jordi: ah
[17:25] <jordi> cjwatson: you can use unset nowrap, or meta-L to toggle it while inside nano
[17:25] <jordi> cjwatson: gotta go, I just wanted to point this in case you want to consider it before it's even more late i nthe game
[17:29] <kirkland> evand: https://bugs.launchpad.net/bugs/349440  .... really?
[17:29] <kirkland> evand: that sucks, haven't seen that one
[17:29] <kirkland> evand: any messages in the terminal where you launched kvm?
[17:32] <IntuitiveNipple> kirkland: that's an interesting one. I *think* I may have experienced that a while back now but thought nothing of it since there were some nvidia issues at the time.
[17:32] <pitti> good weekend everyone
[17:32] <kirkland> IntuitiveNipple: interesting ... i wonder if its something power-management related
[17:32] <IntuitiveNipple> screen-saver maybe?
[17:32] <kirkland> like the guest turning off the monitor
[17:33] <kirkland> and qemu's monitor emulator says, "okay, sure, i'll power off the monitor...take that!"
[17:33] <IntuitiveNipple> I wonder if there's anything in the .xsession log
[17:47] <cjwatson> apw: FYI I put bug 290153 on the jaunty bug list since it was in the 8.10 release notes
[17:47] <fabbione> Nafallo: ping?
[17:48] <apw> cjwatson, nnng thanks
[17:49] <Nafallo> fabbione: pong
[17:49] <cjwatson> pgraner: do you know if the issue "Cannot reactivate Intel 3945/4965 wireless if booting with killswitch enabled" from http://www.ubuntu.com/getubuntu/releasenotes/810 has been fixed in jaunty?
[17:49] <fabbione> Nafallo: just got your invitation.. are you going to sponsor me to London for a party? ;)
[17:50] <Nafallo> fabbione: lol. no. I only selected my Ubuntu group and invited everyone in case someone would be in London during those days :-)
[17:50] <fabbione> Nafallo: yeah i did guess that much :)
[17:50] <fabbione> Nafallo: have fun there
[17:50] <Nafallo> fabbione: I bet we will have :-)
[17:51] <cjwatson> asac: did we get round to re-enabling ath5k in network-manager? I'm assuming that the driver that was in backports for intrepid is in jaunty proper (though haven't checked)
[17:52] <asac> cjwatson: we didnt disable ath5k
[17:52] <OsamaK> Hello. Where can I find the recent Ubuntu Documentation source code.
[17:52] <cjwatson> asac: oh, ok, so no further work needs to be done there?
[17:53] <asac> cjwatson: not on network manager side
[17:53] <asac> i think ath5k is still much better in backport modules
[17:53] <asac> same for iwagn
[17:53] <asac> i will check with rtg if there is anything we can do
[17:53] <cjwatson> OsamaK: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-jaunty
[17:53] <cjwatson> asac: if there's anything to be done for jaunty, please make sure there's a bug filed and targeted for jaunty
[17:53] <cjwatson> asac: (just going through 8.10 release notes)
[17:54] <asac> cjwatson: right ;)
[17:54] <asac> cjwatson: you need to check with rtg what went into mainline from backport modules
[17:54] <cjwatson> pgraner: similarly, "Wireless doesn't work after suspend with ath_pci driver", but there's no bug for that in the 8.10 release notes. Do you know if that's been fixed?
[17:55] <cjwatson> surely it would all have been backported from something older than what we have in jaunty now?
[17:55] <pgraner> cjwatson: rtg would be the best one to ask, I do think the killswitch was fixed.
[17:55] <OsamaK> cjwatson, great. thanks.
[17:56] <pgraner> cjwatson: we don't have madwifi in Jaunty (its all moved upstream now) something tells me its fixed. rtg would know for sure, he's out today but will be back on Mon.
[17:56] <cjwatson> ok
[18:00] <OsamaK> cjwatson, is there anyway to get the old po files? about-ubuntu (and others) is bit changed, and I want to add the newly-added thing without retranslate the whole strings.
[18:01] <cjwatson> OsamaK: I haven't looked and I'm not a documentation guy myself, but I'm sure they could be extracted from bzr
[18:02] <cjwatson> OsamaK: try #ubuntu-doc?
[18:05] <kirkland> slangasek: do you a git commit hash for http://launchpadlibrarian.net/24416880/mdadm-316670.patch ?
[18:06] <slangasek> kirkland: no, I pulled it from the debdiff
[18:06] <slangasek> git, icky :)
[18:14] <kirkland> slangasek: hehe
[18:14] <kirkland> slangasek: i'll find it
[18:14] <kirkland> slangasek: i'm building sbeattie a new deb, with just your pruned patch for his verification
[18:14] <kirkland> slangasek: apw has confirmed that the other raid-degraded bug is in fact a kernel race condition
[18:15] <apw> kirkland, yep.  i think i have the actual bug nailed now.  just building you some test kernels so you can confirm my testing
[18:17] <kirkland> apw: cheers
[18:20] <IntuitiveNipple> kirkland: that patch is 43aaf431
[18:20] <kirkland> IntuitiveNipple: awesome... you must be a git fiend?
[18:21] <IntuitiveNipple> I have my moments :)
[18:23] <cjwatson> bryce: is there a bug report for "Hangs with desktop effects on Intel 830MG and 845G video cards" in http://www.ubuntu.com/getubuntu/releasenotes/810, and has it been fixed?
[18:24] <apw> git blame perhaps
[18:26] <IntuitiveNipple> no, I just did: git log -S'if (!avail)' -- Incremental.c
[18:30] <apw> aother good options
[18:41] <bryce> cjwatson: 259385
[18:42] <bryce> cjwatson: upstream does not really work on 8xx card support any longer so I would not expect it to be solved yet
[18:43] <cjwatson> bryce: yeah, I'd gathered, but as a matter of form we should continue to track issues from the 8.10 release notes. I know you're aware of this but I'll target that bug to jaunty so that other people are too
[18:43] <cjwatson> (I'm doing this for all bugs from the 8.10 notes)
[18:45] <evand> kirkland: no messages
[18:45] <kirkland> evand: okay
[18:45] <kirkland> evand: it is a kvm crash of some sort
[18:45] <bryce> cjwatson: fwiw, it is very likely that support for i830 and i845 will be dropped upstream.   I'm not retargeting bugs that are invalid/wontfix/fixreleased
[18:47] <cjwatson> bryce: but with all the usual caveats
[18:48]  * bryce nods
[18:49] <bryce> well, i830/i845 are such old cards it's hard to justify putting canonical resources into it aside from working around the problem as mvo has done, however I would love to see some community form around providing support for these old -intel chips.
[18:49] <bryce> cjwatson: I'll bring this up with rick and see what he thinks.
[18:50] <cjwatson> bryce: "not Canonical" is more ct-rev than wontfix, really
[18:50] <cjwatson> anyway, dinner ...
[18:52] <kirkland> evand: i'll start up 10 KVMs and leave them run overnight tonight
[18:57] <kirkland> cjwatson: if you remember, i added some prerm magic to ecryptfs-utils to keep it from being removed if it was in use....
[18:57] <kirkland> cjwatson: just for the record, it's equally unwise to remove mdadm on a raid-using system, and reboot
[19:00] <evand> kirkland: heh, ok
[19:00] <kirkland> evand: would you mind doing something similar over night tonight?
[19:00] <evand> kirkland: perhaps try the desktop CD, just to see if that's triggering it
[19:00] <kirkland> evand: crank up some number
[19:00] <kirkland> evand: and see how many survive the night?
[19:00] <evand> kirkland: sure, though I don't know how much time I'll have to report back to you.  I leave for Dubai in the morning.
[19:00] <evand> I'll be bringing my laptop though
[19:01] <evand> so I'm sure I'll find some time to update the bug report
[19:01] <kirkland> evand: sweet, vacation?
[19:01] <evand> ja
[19:01] <kirkland> evand: nice
[19:04] <slangasek> pitti: while we're discussing gnome-python-desktop, do you think we can drop bugbuddy.py from the package (letting us kick bug-buddy out to universe)?
[19:04] <bryce> cjwatson: actually it looks like you do  not need to carry 259385 forward.  (Indeed I think the 810 release notes are listing it unnecessarily)
[19:04] <bryce> cjwatson: compiz has a blacklist for these two chipsets already as a workaround:
[19:04] <bryce> T="$T 8086:3577 8086:2562 " # Intel 830MG, 845G (LP: #259385)
[19:05] <bryce> so the problem that the release notes describe will not actually occur in practice
[19:05] <bryce> the compiz fix on that bug solves the issue.  (If it didn't, then the compiz task should be reopened.)
[19:12] <bryce> slangasek: do you know if seb128 re-enabled the 96 dpi forcing in Gnome?  (refbug #349140)
[19:12] <slangasek> bryce: asac did
[19:14] <bryce> slangasek: oh.  was there a bug report on that?  (for duping purposes)
[19:14] <bryce> slangasek: or mailing list post or irc log or something to reference...
[19:16] <slangasek> bryce: libgnome changelog should show
[19:19] <cjwatson> bryce: ok, please do appropriate things to the bug so that we don't need to worry about it then
[19:19] <cjwatson> bryce: thanks for looking into it
[19:19] <cjwatson> http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html says 3230; http://qa.ubuntu.com/reports/bug-fixing/intrepid-fixes-report.html says 3459
[19:20] <cjwatson> so 229 to go until we surpass intrepid; I wonder if we can beat it by a noticeable amount
[19:20] <bryce> cjwatson: is adding ct-rev sufficient for taking it off your list?
[19:21] <cjwatson> bryce: marking it wontfix for jaunty will reopen a non-targeted task
[19:21] <cjwatson> something will need to be done with the actual status of the jaunty task in order to get it off the release team's list
[19:22] <bryce> cjwatson: ok cool, will do
[19:23] <cjwatson> ta
[19:25] <jordi> cjwatson: back
[19:25] <jordi> cjwatson: is there any tag I can add to the bug to get it considered for this release?
[19:26] <jordi> ah, nominate
[19:31] <bryce> cjwatson: wow, I didn't know about those reports, kewl.  Looks like I've fixed exactly twice as many bugs in jaunty as I did in intrepid.  :-)
[19:57] <liw> cjwatson, re mjg59 & relatime: ack, I saw his blog entry, and I've marked it on my list for things to consider for karmic
[20:08] <dtchen> slangasek: they are caused by the same bug that has been fixed in the latest linux upload
[20:09] <dtchen> (the linux tasks, that is)
[20:09] <dtchen> i opted not to mark dupes because of different debug spew to syslog
[20:11] <slangasek> dtchen: ok - could you close out the bug with that explanation then, if you haven't already?  (no longer have the bug numbers in front of me at the moment :)
[20:12] <dtchen> ye,s i'm planning to close all the bugs referenced in the e-mail to kernel-team
[20:22] <kirkland> cjwatson: still around ?  adduser question for ye
[20:25] <sistpoty> asac: got some time to look at FFe bug #340435? looks like that's your domain ;)
[20:30] <ahasenack> hi, I'm trying to build a source package (debuild -S). The package is for jaunty, and I'm on intrepid. I thought it should work, but it fails when trying to include a file from debian/rules that doesn't exist. Should it be possible? Here is the log: http://pastebin.ubuntu.com/139178/
[20:30] <ahasenack>  /usr/share/python/python.mk doesn't exist on intrepid (or I don't know which package installs it)
[20:31] <ahasenack> the reason I want the source package is so I can upload this to ppa and get a binary for jaunty
[20:32] <sistpoty> ahasenack: I guess #ubuntu-motu might be a better place to ask ;)
[20:32] <ahasenack> sistpoty: ok
[20:39] <the99zChris> can anyone help me? i restored my xorg file (didn't help original problem) but now i can't set my screen resolution low enough to play games...(hardy
[20:40] <sistpoty> the99zChris: then you're screwed (just kidding :P)... please try #ubuntu
[20:42] <the99zChris> k thanks
[20:42] <nixternal> ArneGoetje: I uploaded the kubuntu-docs package yesterday and the translations need to be approved as they are waiting to be imported...thanks :)
[21:07] <kirkland> kvm is apportin'
[21:07]  * kirkland braces for the new infusion of bugs
[21:16] <cjwatson> kirkland: not really - is it quick?
[21:16] <kirkland> cjwatson: nah, check my last upload of adduser
[21:17] <kirkland> cjwatson: it's functional, and it causes no harm
[21:17] <kirkland> cjwatson: you might have a stylistic preference of solving it another way
[21:17] <cjwatson> not on lp yet
[21:17] <kirkland> cjwatson: goal is to remove /var/lib/ecryptfs/$user, if doing deluser --remove-home
[21:17] <cjwatson> unless you mean 3.110ubuntu2
[21:17] <kirkland> cjwatson: no
[21:17] <kirkland> cjwatson: ubuntu4
[21:18] <kirkland> cjwatson: there's a debdiff attached to the bug it fixes ....
[21:18]  * kirkland finds it
[21:18] <cjwatson> ok, I'll look at it later when it lands
[21:18] <kirkland> cjwatson: faird enough
[21:18] <cjwatson> bug 347970?
[21:18] <kirkland> cjwatson: http://launchpadlibrarian.net/24314131/out.diff
[21:18] <kirkland> cjwatson: that's the one
[21:19] <cjwatson> I have a stylistic preference for no whitespace damage in patches ;-)
[21:19] <cjwatson> +if ( $File::Find::name !~ /^\/var\/lib\/ecryptfs\/$user/ ) {
[21:20] <kirkland> doh
[21:20] <cjwatson> you should quote variables when substituting them into variables unless you mean metacharacters to be interpreted - \Q$user\E
[21:20] <kirkland> cjwatson: strike 2, okay.
[21:20] <cjwatson> and I'd recommend m[^/var/lib/ecryptfs/\Q$user] to reduce leaning toothpick syndrome
[21:21] <kirkland> cjwatson: alrighty then ...  fail
[21:21] <kirkland> cjwatson: i'll get this cleaned up
[21:21] <kirkland> cjwatson: any arguments with my method?
[21:21] <cjwatson> I'm just looking at the context
[21:21] <kirkland> cjwatson: okay, you can put this off for later, if you wish
[21:22] <kirkland> cjwatson: i considered several different approaches
[21:22] <kirkland> cjwatson: this one was the fewest lines of code to be changed
[21:22] <cjwatson> I find it quite confusing as-is
[21:22] <cjwatson> I think I would prefer a separate ecryptfs_match
[21:23] <cjwatson> I realise it's a style thing to some extent
[21:23] <kirkland> cjwatson: that's fair, that's the feedback i was looking for
[21:24] <cjwatson> mostly just because the remainder is pretty short
[21:24] <kirkland> cjwatson: it's a fair bit of duplicated code doing it that way
[21:24] <cjwatson> not really, it's about half a dozen lines?
[21:24] <kirkland> cjwatson: i was looking for a previous debdiff, don't see it immediately
[21:24] <cjwatson> oh, a bit more, sorry, misread
[21:24] <cjwatson> well, there's another possibility
[21:25] <kirkland> cjwatson: there's also the question of whether this behavior is even appropriate ...  there's also a delete-all-files option
[21:26] <kirkland> cjwatson: pitti could have perhaps used that
[21:26] <cjwatson> have a variable declared in a scope outside home_match, and have the home_match function check that variable to determine what to do
[21:26] <cjwatson> as I said, delete-all-files is really, really slow
[21:27] <cjwatson> I'm sort of inclined to say that the ecryptfs bit is like your home directory
[21:27] <kirkland> cjwatson: okay, fair enough.  i ack'd the bug, and felt the same way
[21:27] <cjwatson> TBH, though, I think if it were me I would favour the duplicate code over making it less clear
[21:28] <cjwatson> but I wouldn't veto the other approach, it's just a preference
[21:28] <kirkland> cjwatson: gracious for your review, i'll rework it now
[21:37] <Laney> does apport somehow remember previous reported crashes?
[21:37] <Laney> and not trigger for the same crash again?
[21:37] <Laney> (after reporting)
[21:42] <nixternal> ArneGoetje: just caught your thread on the translators list. I am the maintainer for the kubuntu-docs package and will do the imports when complete. Been doing it since Dapper, so yes, we would like to have the kubuntu-docs translatable in Rosetta for Jaunty..thanks!
[21:43] <Laney> -- because I cancelled a report after uploading to LP so that I could resubmit with debugging symbols installed
[21:43] <Laney> but now apport won't trigger again and nothing is written in /var/crash
[21:54] <Laney> got it
[21:56] <cody-somerville> Does anyone know the udeb with the modules for squashfs?
[22:14] <kirkland> cjwatson: okay, i have a cleaner one now
[22:18] <slangasek> infinity: since you've saturated the build queues, could you bump jack-audio-connection-kit to the front? :)
[22:20] <infinity> slangasek: Done.
[22:20] <slangasek> thankee
[22:23] <Nafallo> haha
[22:24] <robbiew> slangasek: hey...is there an internal server that I can grab the UNR beta image from...instead of waiting the hour to download from cdimages?
[22:25] <slangasek> robbiew: mm, there's a mirror of cdimage somewhere that internal QA testers can use for speedier access, but I don't remember where to get it
[22:25] <robbiew> ah fooey
[22:25] <robbiew> :P
[22:25] <robbiew> no worries...just being impatient
[22:25] <robbiew> heh
[22:26] <slangasek> you could bittorrent!
[22:26] <robbiew> true
[22:26] <slangasek> then it will still take you an hour, but you'll spend the first 10 minutes feeling like you're doing something
[22:26] <robbiew> heh
[22:26] <robbiew> right
[22:58] <diegoe> bryce: around?
[22:59] <bryce> yes
[23:00] <diegoe> may i bug you about the patch in lp #349113
[23:00] <bryce> diegoe: if you wish
[23:01] <diegoe> just wanted to attract your attention to it, i was just enjoying the bisect experience
[23:02] <diegoe> I wonder if you would like additional confirmation or if you have any thought about it, I wouldn't swear the problem is in every 855GM, but I guess mine's not that much different
[23:02] <bryce> heh 855
[23:03] <bryce> I think anholt has a dislike for the 8xx cards :-/
[23:03] <nxvl> bryce: i'm preparing the debdiff for that package, will upload any minute
[23:03] <diegoe> nxvl: work!
[23:03] <bryce> diegoe: you've confirmed that with those two patches reverted, that your issue is resolved?
[23:04] <diegoe> yes, but let's wait for nxvl debdiff and I will re-confirm with a package built from his new sources
[23:04] <bryce> from anholt's comments it doesn't appear his change is intended to actually fix a bug, just remove code he feels is no longer needed... which due to the existence of the bug may be incorrect
[23:04] <bryce> alright
[23:05] <diegoe> it's curious because in his comment he says this was there since beginning of time
[23:05] <bryce> wait
[23:05] <diegoe> although this font problem never popped
[23:05] <bryce> maybe I've misunderstood - you're saying those patches are *needed* for fixing it?
[23:06] <bryce> sorry, your comments on the bug report confused me
[23:06] <diegoe> let's say patch, since the second one is just a forgot line of the first one
[23:06] <diegoe> sorry :-)
[23:06] <bryce> ok, I'll wait until I see the debdiff :-)
[23:06] <diegoe> without the patch, the intel driver exhibit this funny fonts problem
[23:06] <diegoe> with the patch applied, it doesn't
[23:07] <bryce> diegoe: it's possible that some other change elsewhere in the code triggered the problem
[23:07] <bryce> sometimes there can be two bugs that cancel each other out, and fixing one reveals the other
[23:08] <bryce> nxvl: feel free to assign the bug to me once you have a debdiff to sponsor, and I'll make sure to shepherd it in
[23:08] <diegoe> mmm, well git bisect took me there and i retested going to a clean master, checking out to the commit *before* the suspected fix
[23:08] <diegoe> the commit before this one shows the funny fonts, from this commit and on the fonts are no problem
[23:09] <nxvl> bryce: ok
[23:13] <Hobbsee> cjwatson: I haven't found the killswitch bug for iwl3945 to be fixed (which you asked pgraner), fwiw
[23:14] <pgraner> Hobbsee: you have a bug number?
[23:14] <Hobbsee> pgraner: i thought cjwatson gave you one....
[23:14] <Hobbsee> i don't have one here
[23:15] <pgraner> Hobbsee: nope he just mentioned the issue, he gave me a bug number for a different issue
[23:15] <Hobbsee> pgraner: oh.  I've not gone looking for one so far, i just answered off the symptoms.  I'll go looking for one in a bit, unless you beat me to it
[23:16] <nxvl> diegoe: the code your patch is removing is not present in the ubuntu package
[23:16] <pgraner> Hobbsee: we've squashed several kill switch issues, I was hoping that was one. I would check the next kernel coming out it will have one more killswitch fix I just don't remember if it was for that one, ping apw he might know as he was working on a few.
[23:16] <diegoe> nxvl: that's bad
[23:17] <diegoe> nxvl: all of it or just parts?
[23:17] <slangasek> cjwatson: what's left to do on bug #44194 for wpasupplicant? the daemon is already in /sbin and so are the libs it uses?
[23:17] <nxvl> diegoe: i don't find anything of it
[23:17] <nxvl> diegoe: and when generating a quilt patch for it to be packages i get a patch including that code in the package
[23:17] <nxvl> diegoe: instead of removing it
[23:18] <diegoe> weird
[23:18] <diegoe> i see here that such code is in since 2007
[23:18] <Hobbsee> pgraner: ahhh, OK.  it may be fixed for other people.  I'll take a look and report mine, as once I hit the kill switch, i can't reativate hte wifi, at all, until i get back to the bios / boot windows, iirc.
[23:19] <nxvl> diegoe: not in the debian package
[23:19] <nxvl> well, i'm gone
[23:19] <nxvl> feel free to prepare a debdiff
[23:20] <diegoe> ok thx
[23:22] <diegoe> bryce: looks like 2.6 branch already removed such code since 704177b5dd0ab7a5f5bef937eac53d725bc509b5
[23:23] <diegoe> which leaves me clueless...
[23:24] <diegoe> i have seen the problem since 2.5 (which fedora included), and now in ubuntu's 2.6.x; but not in git master, git bisecting master took me to the commit we were talking about, but turns out 2.6 doesn't have that code already
[23:25] <diegoe> i will bisect in the 2.6 branch and let you know
[23:25]  * diegoe thought the problem was already cornered, sigh
[23:27] <pgraner> Hobbsee: thanks
[23:28] <Hobbsee> pgraner: oh, and thanks collectively to the kernel for making my hibernate work again :)
[23:28] <Hobbsee> s/again/properly/
[23:29] <pgraner> Hobbsee: no worries
[23:34] <bryce> diegoe: you could also doublecheck differences in how the code is configure'd
[23:35] <diegoe> bryce: ?
[23:37]  * diegoe is unable to build the 2.6 branch :-/
[23:39] <diegoe> ah there's a fix in the .deb
[23:41]  * diegoe gives up
[23:42] <bryce> well, at least forward the bug upstream for some additional advice
[23:43] <bryce> actually nevermind, if the bug isn't reproducible in the git tree, they won't care
[23:43] <diegoe> i can't build the 2.6 branch
[23:44] <cody-somerville> pgraner, Do you know if there is a udeb with the squashfs kernel modules?
[23:44] <bryce> diegoe: why not?
[23:44] <diegoe> ftbfs
[23:44] <bryce> diegoe: that's hardly helpful
[23:44] <diegoe> :P
[23:44] <bryce> diegoe: "Doctor, my arm hurts?"  "Why?"  "Because there's a pain in it"
[23:45] <bryce> diegoe: builds fine for me
[23:46] <diegoe> from git 2.6 branch or from the .deb?
[23:46] <bryce> from the deb
[23:46] <diegoe> i was gonna try bisect in 2.6 branch on git
[23:47] <cody-somerville> Whats the cause of the FTBFS diegoe?
[23:50] <diegoe> http://pastie.org/429494
[23:51] <diegoe> i guess i have something too recent for the commit i'm trying to build, which is circa 2.6.1
[23:52] <bryce> libdrm got updated to 2.4.5 in order to allow 2.6.3 to build
[23:52] <bryce> so perhaps downgrading to a pre-2.4.5 libdrm*-dev would enable it to build
[23:54] <diegoe> -.-