[00:36]  * Keybuk wonders whether moblin have fixed their boot yet
[00:42] <slangasek> Keybuk: I think we should start calling you The Cobbler for all the time you spend working on boots
[00:43] <Keybuk> a co-worker once called me a Blind Cobbler's Thumb
[00:55]  * ogra orders a pair of new laces from Keybuk 
[01:18] <Keybuk> \o/
[01:21] <StevenK> slangasek: Woot!
[01:27] <directhex> yays!
[01:28] <directhex> slangasek, how's cd space looking right now?
[01:29] <slangasek> directhex: reasonable; we've got a bunch of langpacks fitting now that weren't before (or last cycle)
[01:29] <slangasek> if you have more we can trim, though, I'd be happy to get the clippers back out. :)
[01:29] <directhex> slangasek, i am officially calling ":)" on that, then
[01:29] <slangasek> amusingly, Ubuntu amd64 DVD is oversized
[01:29] <directhex> there is some possible trimming to be done, but i don't know if there'll be enough time for jaunty
[01:30] <slangasek> maybe because we now have too many translations; I haven't looked in detail yet
[01:31] <directhex> but having klingon on there is vital!
[01:32] <Keybuk> HIja!  tlhIngan maH!
[01:32] <slangasek> TheMuso, dtchen: why does pulseaudio build-depend on libcap-dev (instead of libcap2-dev)?
[01:36] <directhex> Keybuk, you win, i've been thoroughly out-nerded
[01:36] <directhex> even throwing babylon 5 references at slangasek won't hide my shame
[01:36] <Keybuk> Ah, hell
[01:37] <slangasek> Keybuk: you were hoping for a rebuttal in Klingon? :)
[01:37] <Keybuk> slangasek: no, but I was hoping someone would get _that_ language-related Babylon 5 reference <g>
[01:38] <slangasek> Keybuk: what, "ah, hell"?  Kind of a thin reference. :)
[01:38] <Keybuk> it's Minbari
[01:38] <Keybuk> for "open fire" :p
[01:39] <Keybuk> (or, at least, something phonetically very similar)
[01:40] <directhex> Keybuk, NOW i remember, but slangasek has a point, a bit thin given the 80.67 hours of series to try & spot it from
[01:40] <Keybuk> directhex: it's hardly geek trumps if I pick the easy ones, is it? :p
[01:40] <directhex> :'(
[01:41] <LaserJock> good grief, the next time somebody tells me chemists are nerdy I'm pointing them to this log :-)
[01:42]  * directhex flings LaserJock through a jump point
[01:44]  * LaserJock focuses his laser down to create some plasma then uses some lenses laying around the lab to launch it at directhex 
[01:44] <slangasek> Keybuk: yes, you win, deh fers't
[01:44] <directhex> and so to bed
[01:44] <Keybuk> ;)
[01:45] <Keybuk> didn't I read somewhere that Minbari was basically polish?
[01:45] <directhex> zoot zoot
[01:45] <slangasek> you may have read that somewhere, but I dispute this :)
[01:46] <Keybuk> dunno
[01:46] <Keybuk> the only phrases of any Eastern European languages I know come from pornography
[01:47] <directhex> well, what's "continuous fire" in polish porn? ;)
[01:47] <StevenK> "Much of the Minbari spoken on screen is derived from Polish, with phrases such as "не можно" (ne mozhno) spoken with a subtitle saying Don't be, such as in the episode War Without End Part I."
[01:47] <StevenK> From http://en.wikipedia.org/wiki/Minbari
[01:47] <Keybuk> StevenK: if Wikipedia says it, it must be true
[01:47] <directhex> StevenK, ehm, isn't polish written with latin alphabet?
[01:48] <StevenK> Keybuk: I wasn't saying that, I was pointing out that is where you might have read it.
[01:48] <slangasek> the wikipedia is mother, the wikipedia is father. trust the wikipedia
[01:48] <directhex> the wikipedia hurts us?
[01:48] <directhex> *zap*
[01:48] <Keybuk> what's it got in its wikis, hmm?
[01:49] <directhex> nobody listen to poor directhex :(
[01:50] <Keybuk> heh
[01:50] <Keybuk> I wrote my entire A-Level Computing mock paper as Zathras
[01:50]  * Keybuk was a little disenchanted with school at that point
[01:50] <directhex> that's awesome
[01:51] <directhex> i think i used lines from jimi hendrix's "hey joe" as variable names for mine
[01:51] <directhex> int heyjoewhereyougoingwiththatguninyourhand = 3;
[01:52] <directhex> or whatever the pascal equivalent to that is. my mind has faded with age
[01:52] <Keybuk> "Zathras not know why 6502 has both direct and indirect jump statements.  Zathras not understand, but Zathras do".  etc.
[01:52] <Keybuk> I still have it somewhere
[01:52] <directhex> heh
[01:52] <directhex> okay, now bedtime fo'realz.
[01:52] <Keybuk> because the school sent it to my parents with a "We are seriously concerned about your child not taking this seriously" type letter
[01:52] <directhex> it's nearly the hour of the wolf, and i lack the required vodka
[01:53] <Keybuk> you missed a fine moment for an "hour of scampering" reference, there
[01:54]  * slangasek traces the wikipedia article's history, and finds that the Polish claim is manufactured out of whole cloth, awesome
[01:57] <Keybuk> ah!
[01:57] <Keybuk> pulseaudio has finished building ...
[01:57] <Keybuk> ... 25 separate debs!
[02:02] <TheMuso> slangasek: Not sure, something from Debian, and didn't notice. Would you like it changed in the next upload, and are there any advatnages etc? Or is this a transition?
[02:02] <slangasek> TheMuso: we currently have both libcap1 and libcap2 in main, it'd be nice to transition one of them out
[02:02] <TheMuso> slangasek: right
[02:02] <slangasek> TheMuso: there's not much formal transitioning needed
[02:02] <TheMuso> fair enough
[02:04] <slangasek> Keybuk, StevenK: hope you're happy, Vorlon has now edited the Minbari article
[02:05] <TheMuso> Keybuk: Unless there is something for pulseaudio/alsa/etc that cannot wait, would it be possible to push a diff to dtchen or myself, and we can get it lined up for our next upload, since we often have stuff queued for a few days before we upload it, just in case something pops up upstream that we want to pull in?
[02:06] <Keybuk> TheMuso: I've already uploaded it
[02:06] <TheMuso> Keybuk: I know, hense my request.
[02:07] <Keybuk> TheMuso: where would you like the diff?
[02:07] <Keybuk> http://people.ubuntu.com/~scott/pulseaudio_0.9.14-0ubuntu9.debdiff
[02:08] <TheMuso> Keybuk: We have a bzr repo for the pulseaudio packaging metadata at lp:~ubuntu-core-dev/pulseaudio/ubuntu. I'm already merging your changes now, so its fine for now,.
[02:08] <Keybuk> TheMuso: you should add the Vcs-Bzr header to debian/control
[02:08] <Keybuk> because then I would have already given you the change via bzr ;)
[02:08] <TheMuso> fair enough
[02:08] <dtchen> i totally added Vcs-Bzr at some point
[02:08] <Keybuk> I always make sure to check for that header
[02:09] <TheMuso> dtchen: looks like it got lost somewhere. I'll re-add it.
[02:09] <TheMuso> dtchen: and merge your branch.
[02:10] <dtchen> TheMuso: ok, thanks. i've a bunch of alsa-lib and alsa-kernel workarounds i'll be pushing to /timing before they end up in /ubuntu
[02:11] <TheMuso> ok
[03:59] <calc> umm evolution preferences is too big to fit on a 1280x800 screen with proper DPI set
[04:41] <calc> anyone know if samba is generally broken or just for me? i segfaults on startup
[04:45] <ajmitch> calc: I recall a fix being talked about a couple of days ago for a samba crasher
[04:54] <calc> ajmitch: hmm must not be uploaded yet, it crashes every time on start for me
[05:04] <ajmitch> 2:3.3.0-4ubuntu1?
[05:04] <ajmitch> I guess it's file-a-bug time :)
[05:06] <TheMuso> 8/c
[05:12] <calc> ajmitch: i just upgraded and didn't get 4ubuntu1
[05:12] <hyperair> meh pbuilder doesn't seem to want to create a sid chroot
[05:13] <giunzin> hi. anybody here?
[05:13] <giunzin> i am using Hardy, and have no Direct Rendering.
[05:13] <giunzin> from glxinfo:
[05:13] <giunzin> ﻿﻿direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
[05:14] <giunzin> my video card is: ﻿00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
[05:14] <giunzin> i reported in ubuntu-bugs, but it seems everybody is sleeping? so i come here for some helps
[05:22] <calc> ajmitch: 4ubuntu1 is dep wait still so it missed alpha 5
[05:23] <calc> its dep wait because someone added a dep ctdb which is universe without getting it into main first
[05:23] <calc> d0h
[05:27] <calc> zul: getting ctdb into main anytime soon? being able to run samba would be nice :)
[05:51] <dholbach> good morning
[05:51] <dholbach> can somebody take a look at bug 23435?
[05:52] <dholbach> and bug 201495?
[05:52] <dholbach> doko: is bug 324708 a jaunty target?
[05:53] <dholbach> ArneGoetje: what about bug 329435 and bug 329425?
[05:59] <hyperair> dholbach: regarding bug 201495, it looks like /etc/passwd has trailing commas.
[06:00] <hyperair> is there supposed to be any information between the commas?
[06:00] <andersk> Yes, that is the GECOS information (full name, room, phone numbers).
[06:01] <hyperair> ah i see
[06:09] <slangasek> calc: uploaded and dep-wait.
[06:09] <slangasek> calc: right, I shall learn to read my scrollback in reverse.
[06:15] <calc> slangasek: heh yea :)
[06:15] <calc> slangasek: its waiting on a MIR i guess
[06:16] <calc> i was attempting to test a bug in OOo that needed working samba and noticed that issue :)
[06:18]  * calc off to bed
[06:23] <ScottK> slangasek: Would you please accept plasmoid-am4rok in intrepid-backports and throw 335296 kepas at syncbugbot?
[06:23] <ScottK> Details are in Bug 335296.
[06:24] <ScottK> That hopefully will be the last backport needed to get in sync with kde 4.2.0.
[06:34] <slangasek> ScottK: plasmoid-am4rok is a backport, but isn't in jaunty?
[06:35] <slangasek> ah, I guess that's why it's sourceful :)
[07:15] <lool> bryce_: I see there's a new upload of xorg-server being prepared, I guess it's meant for now (post-a5) it's a new upstream; I prefer not pushing that but will commit a lpia fix right now; please git pull before uploading  :-)
[07:19] <lool> bryce_: Ah nevermind, my change is in xorg; not xorg-server
[07:39] <cjwatson> slangasek: re grub2-by-default, it's unusual to approve a spec that has an "Unresolved issues" section. Is there anything we can do about that - perhaps some of it can be marked as future work?
[07:39] <cjwatson> slangasek: UUID support is mentioned there but seems to be also mentioned in the main body of the spec
[07:40] <slangasek> cjwatson: hrm, the spec template implies that the "unresolved issues" section is meant to be used precisely for identifying unresolved issues that are out of scope for the current spec
[07:41] <cjwatson> hmm, last I looked at the spec template it said that a spec couldn't be approved with unresolved issues
[07:41] <cjwatson> ah, I see
[07:41] <cjwatson> I guess I read that too strictly, or else it's been revised
[07:42] <slangasek> UUID support ought only be mentioned in the body, since we're doing that by default everywhere and rather need it to work - I just don't know if it does work or if it would imply an FFe
[07:42] <pitti> Good morning
[07:42] <slangasek> moin
[07:43] <slangasek> dropped UUID from the unresolved issues section
[07:43] <cjwatson> I can't really see how an FFe would be necessary for that, since it's dealing with software that (by presumption) hardly anyone installs right now, and the feature is present in the implementation people are actually using ...
[07:44] <cjwatson> approved the spec now
[07:45] <slangasek> thanks
[07:45] <maco> pitti: the xserver-xorg-video-intel change you made 2 days ago. was it extensive enough to have broken VT switching, or should i be looking at xorg-core?
[07:47] <maco> (or elsewhere)
[07:48] <pitti> maco: I doubt it, it just adjusted some numbers; but please downgrade to the previous version and check if it fixes it?
[07:50] <maco> will that require downgrading other xorg packages? if not, that won't narrow things down.
[07:52] <dholbach> hiya juanje
[07:53] <juanje> dholbach: good morning :-)
[08:00] <pitti> Keybuk: in your init script moving efforts, did you consider moving dkms_autoinstaller, hotkey-setup, kvm, postfix, too?
[08:03] <pitti> Keybuk: uh, you just call update-rc.d -f cups remove? that doesn't respect user configuration if the symlinks were removed in some runlevels
[08:28] <scizzo-> slangasek: I am sorry to ask but is that grub information about UUID in the menu.lst and error 11 from trying to boot from latest grub and grub2?
[08:28] <apw> bah, all these apps just popping up all over the place is awful
[08:30] <tjaalton> how to make a debian/pkg.install -file arch dependent? appending .arch doesn't work, and I can't find it in the debhelper documentation :/
[08:32] <cjwatson> debhelper(1) claims that debian/pkg.install.arch should work ...
[08:32] <cjwatson> but you could take ubiquity's approach and just build debian/pkg.install dynamically in debian/rules
[08:33] <tjaalton> I'm trying to modify adobe-flashplugin which is currently i386-only, and the goal is to minimize the changes :)
[08:33] <tjaalton> building them dynamically is what I've done before
[08:36] <tjaalton> maybe just having debian/install.arch doesn't work, so I'll try renaming it..
[08:38] <tjaalton> yeah, pkg.foo.arch works, foo.arch doesn't
[08:38] <tjaalton> thanks
[08:56] <cafetiere> the new notifiers, what package are those for reporting bugs?
[08:56] <cafetiere> (the new jaunty see through ones)
[08:57] <pitti> cafetiere: notify-osd
[08:59] <pitti> thekorn: thanks for merging the subscriber fix
[08:59] <pitti> thekorn: any chance you could commit doko's p-lp-bugs change? http://launchpadlibrarian.net/23161188/python-launchpad-bugs_0.3.2_0.3.3.diff.gz
[08:59] <apw_> pitti, yeah just testing the alpha CD and they are all appearing overlapping the menus
[09:00] <apw_> and pretty sure thats not what they are meant to do
[09:00] <pitti> previously they were a little further down indeed
[09:01] <apw_> and they are too narrow to even fit connection established in
[09:02] <apw_> which given they are so small they are almost unreadable is daft
[09:03] <thekorn> pitti, sure, will merge the change in a bit
[09:04]  * pitti hugs thekorn
[09:04]  * thekorn hugs pitti 
[09:06] <cjwatson> pitti: dunno if you saw, but ronne's firewall has been fixed
[09:08] <pitti> cjwatson: no, just replied; it's still broken :(
[09:08] <pitti> at least for the things I care about, launchpadlib and smtp; ssh also doesn't work
[09:09] <cjwatson> ah :(
[09:09] <pitti> thekorn: after you merged it, I'll do a new jaunty upload then, so that the retracers can be started again
[09:10] <pitti> thekorn: could you use 0.3.4 as next version number?
[09:12] <thekorn> pitti, yes, /me was thinking about the correct version number, 0.3.4 sounds sensible
[09:14] <thekorn> pitti, pushed
[09:17] <apw> apw_ ping
[09:17] <apw> apw_ ping
[09:18] <pitti> thekorn: uploaded
[09:18] <thekorn> pitti, danke
[09:18] <pitti> apw: testing yourself? :-)
[09:19] <apw_> testing the popups for highlighted messages, or as they are now know Highlig...
[09:21] <apw_> bah they don't concatenate either
[09:24] <doko> thekorn: thanks
[09:32] <pitti> doko: jockey with python2.6-ification uploaded
[09:32] <doko> dholbach: yes, I set it to "progress"
[09:33] <dholbach> doko: ok super - thanks
[09:34] <doko> pitti: \o/
[09:37] <arthur-> doko: /query please
[09:41] <pitti> cjwatson: do you want intrepid-proposed d-i against 2.6.27-12 accepted? (linux is at -13 now)
[09:46] <cjwatson> pitti: I can reupload for -13 now
[09:46] <liw> upgrading a machine from hardy to intrepid to jaunty removes the openssl-blacklist package -- is that intentional?
[09:47] <cjwatson> removes due to conflict or due to lack-of-dep?
[09:47] <liw> I didn't look yet, just saw it in update-manager's list of packages it wanted to remove
[09:47] <IntuitiveNipple> Which package should this bug be against? When operating more than one X screen and working on the additional screens for some time, the displays will try to go to screensaver unless there's activity on screen 0
[09:51] <mdz> calc: I haven't worked out exactly which package it is the trigger, but oo.o often seems to crash while I'm installing updates.  is this a known issue?
[09:51] <liw> bah, the upgraded machine blanks its screen about when usplash should be shown
[09:53] <mdz> calc: maybe fonts?
[10:03] <pitti> cjwatson: thanks
[10:04] <seb128> mdz: could be bug #286175 as a random guess
[10:05] <seb128> ctrl-w on the wrong dialog
[10:09] <ogra> hmm, trying our pitti's "xdpyinfo |grep dimensions" from teh ML my screen size is totally wrong ...
[10:09] <mdz> seb128: maybe, thanks
[10:10] <seb128> mdz: you're welcome
[10:10] <ogra> i wonder how to tell Xorg about the right values
[10:11] <mdz> ogra: DisplaySize in xorg.conf
[10:11] <mdz> unfortunately it is not in HAL (yet?)
[10:12] <ogra> mdz, thanks !
[10:23] <ogra> funny
[10:23] <ogra> intel(0): Display dimensions: (262, 165) mm ... from Xog.0.log
[10:23] <ogra> ogra@osiris:~$ xdpyinfo |grep dimensions
[10:23] <ogra>   dimensions:    1280x800 pixels (339x212 millimeters)
[10:24] <ogra> (**) intel(0): DPI set to (124, 197) ... log again ...
[10:24] <ogra> ogra@osiris:~$ xdpyinfo |grep resolution
[10:24] <ogra>   resolution:    96x96 dots per inch
[10:24]  * ogra looks puzzled
[10:24] <ion_> Perhaps Gnome or something forces the DPI to 96, and then xdpyinfo computes the dimensions based on it?
[10:25] <ogra> gnome forces X ?
[10:25]  * ogra cant imagine that
[10:37] <apw> this new login screen, is it really almost all black, with black background and black bacgrounds in the menus and dialogs?
[10:38] <pitti> apw: yes
[10:39] <apw> doh
[10:39] <apw> is that going to be fixed?
[10:39] <pitti> apw: complaints -> kwwii, I think for now that's intentional
[10:39] <apw> is kwwii a person?
[10:40] <ogra> the buttons of the popup windows look a bit lost
[10:40] <ion_> Unlike some UI change’s we’ve seen during Ubuntu alphas, this one is quite nice. :-)
[10:40] <ogra> without a window frame for the popups
[10:40] <wgrant> People at work today were quite pleased, apart from it possibly being slightly too black.
[10:41] <apw> the overall effect is fine, its the lack of border to the menus and popups thats plain odd
[10:54] <cjwatson> pitti: (debian-installer/intrepid-proposed reuploaded now)
[10:54] <cjwatson> siretart: I'd appreciate your comments on my last entry in bug 44194, when you have a moment
[10:54] <cjwatson> and indeed those of others
[10:58]  * ogra wonders why he doesnt have human icons anymore even though they are selected 
[11:15] <lool> Keybuk: Just a heads up that I provided the details for the autoconf / dash? issue I've been seeing; it's definitely not a local config as I reproduced in a clean jaunty vm
[11:29] <Adri2000> Keybuk: hmm the comments disappeared and adding a comment produces an internal server error. know what happened?
[11:36] <Adri2000> Keybuk: I'm afraid the comments file got corrupted by something... if that's the case, it may mean we missed a security hole :/
[11:40] <pitti> evand: oh, usb-creator isn't in bzr? I wanted to commit a fix for bug 331327 (which completely breaks cration with persistent storage)
[11:41] <evand> pitti: it is, lp:~ubuntu-installer/usb-creator/trunk
[11:41] <pitti> evand: ah; can you please add Vcs-Bzr:?
[11:41] <evand> perhaps I should move that to core-dev, or make a ~ubuntu-installer team composing both core-dev and ubuntu-installer
[11:41] <evand> pitti: will do
[11:41] <pitti> evand: and I just saw that I can't commit anyway
[11:41] <pitti> evand: just testing the proposed fix there
[11:43] <evand> committed vcs-bzr change as r81
[11:43] <pitti> evand: cool, thanks
[11:44] <evand> I'll work on getting usb-creator open to core-dev as well.  If you'd prefer for the meantime, feel free to point me at a patch and I'd be happy to commit it.
[11:46] <pitti> evand: not a diff -u patch, but explanation and new code line is in https://bugs.edge.launchpad.net/ubuntu/+source/usb-creator/+bug/331327/comments/3
[11:48] <evand> whoa, whoops
[11:48] <pitti> evand: okay, that works
[11:48] <cjwatson> is there anyone in ubuntu-installer but not in ubuntu-core-dev who needs to commit to usb-creator?
[11:48] <evand> thanks for catching that pitti
[11:48] <cjwatson> it could just be moved to core-dev and then we wouldn't have to think about the messy bugmail consequences :-)
[11:48] <cjwatson> of course ubiquity has the same problem ...
[11:48] <pitti> evand: the "successful" dialog (as well as the error dialog) is horribly broken, but that's another issue
[11:48] <evand> cjwatson: good point, just trying to be forward thinking in case usb-creator gets some contributors who are not in core-dev
[11:48] <cjwatson> maybe we should just disable ubuntu-installer's bug subscriptions and subscribe to things individually
[11:49] <pitti> evand: usually you have a trunk (with an upstream team) and an ubuntu branch (with the packaging added, and being owned by core-dev)
[11:49] <evand> pitti: indeed, that's my wraplabel code being rubbish.  Working on a fix ever so slowly.
[11:49] <cjwatson> pitti: excess complexity for native packages
[11:49] <evand> pitti: this is a very ubuntu specific project though
[11:49] <evand> indeed
[11:49] <pitti> evand: ubuntu specific> oh, is it? okay, then it's sensible to just keep one branch
[11:50] <pitti> I didn't know that it just works for ubuntu CDs
[11:50] <evand> yeah, I hope to finish up my code to call gnome-app-install soon, among other deb specific bits (it is dependent on our syslinux and casper setup).
[11:50]  * pitti goes to test-boot it on wife's machine
[11:51] <evand> pitti: what's wrong with saying bs=1M?
[11:51] <pitti> evand: you can say bs=1M, but then you need to use int(persistent)/1048576
[11:51] <pitti> for count=
[11:51] <pitti> evand: and you really don't want bs=1
[11:52] <pitti> so I thought bs=%size and count=1 is both efficient and correct
[11:52] <evand> size is in MB though
[11:52] <evand> I think
[11:52] <pitti> not for me
[11:52]  * evand checks
[11:52] <pitti> PythonArgs: ['/usr/share/usb-creator/install.py', '-s', '/tmp/tmpi9gLFd/.', '-t', '/media/LinBoot', '-p', '1103998510']
[11:52] <evand> ah, so you're right
[11:52] <evand> wonderful
[11:53] <pitti> on my system (250 MB free) I had ~ 250000000
[11:57] <pitti> nice, it boots
[11:57] <evand> Right, so any objections to me making a new usb-creator-hackers team and adding core-dev as a member?  As previously stated, this is so the few people providing occasional patches who are not in core-dev can contribute without having to jump through hoops.
[11:58] <pitti> sounds fine to me
[11:59] <evand> great, will do.  I'm about to commit your suggested fix for the dd issue as well.
[12:02] <Keybuk> Adri2000: you should probably fix that, then ;)
[12:04] <Adri2000> Keybuk: yeah, but I'd need to see the comments file first
[12:05] <Keybuk> it's zero bytes
[12:06] <Keybuk> and mysteriously owned by the merge user
[12:06] <Keybuk> race condition or bug between user updates via addcomment.py and system-updates via manual-status/merge-status run maybe?
[12:07] <Keybuk> you could do with some locking too
[12:07] <Keybuk> a read lock around get_comments
[12:08] <Keybuk> likewise a lock around remove_old_comments
[12:08] <Keybuk> which should be in a common file
[12:08] <Keybuk> *and*
[12:08] <Keybuk> just looks plain wront
[12:08] <Keybuk>     file_comments = open(comments, "w")
[12:08] <Keybuk>     for line in open(comments, "r").readlines():
[12:09] <Keybuk> opening it for writing like that will truncate the file
[12:09] <pitti> evand: this was actually the first time I tried an USB stick with persistance; this is so cool
[12:09] <Keybuk> so when you open it for reading, *boom*
[12:09] <pitti> a workstation to be carried on your keyring
[12:09] <Keybuk> (no idea why it jumped user though)
[12:09] <evand> pitti: wonderful, let me know if you run headfirst into any bugs :)
[12:09] <apw> cjwatson, who is the right person to whine at if i am doing an upgrade to jaunty using upgrade manager, and the thing gets stuck sitting there with 2 mins remaining.  Nothing is obviously going on until one open the Termina where it is asking a question
[12:10] <cjwatson> apw: mvo
[12:10] <apw> checkbox is asking to replace its configuration files (which are unmodified)
[12:10] <apw> cjwatson, thanks
[12:10] <evand> pitti: I'm hopefully adding a button for gnome-app-install in a chroot for -updates, so it very much will be your custom workstation on your keyring
[12:10] <cjwatson> such prompts should cause the terminal to open automatically
[12:10] <directhex> importing the debian keyring takes a while
[12:10] <apw> cjwatson, that they don't
[12:10] <pitti> evand: only difficulty I had was wrestling with the bios; interestingly, it didn't work with any of USB-{CDROM,FDD,ZIP,HDD}, but was detected as a proper hard disk, and there was a separate menu for the hard disk priority; *grumpf* :)
[12:10] <evand> (chroot of the unpacked squashfs, that is)
[12:10] <cjwatson> apw: I mean "ought to, and used to"
[12:10] <apw> i assume that is a bug in update-manager
[12:10] <evand> odd
[12:10] <apw> yeah i took you to mean that :)
[12:11] <apw> will file a bug on it
[12:11] <cjwatson> used to be that a read on the tty caused the window to open
[12:11] <apw> seems to ahve stopped workgin
[12:11] <apw> will also file a bug on checkbox as something is wrong there too
[12:11] <Adri2000> Keybuk: argh... strange because I had no problem when testing that
[12:12] <Keybuk> Adri2000: the code is clearly wrong
[12:13] <Keybuk> common practice would be to
[12:13] <Keybuk> open a temporary file for writing
[12:13] <Keybuk> open the original file for reading
[12:13] <Keybuk> lock the original file
[12:13] <Keybuk> read lines from the original, write to the temporary
[12:13] <Keybuk> close the temporary file
[12:13] <Keybuk> rename the temporary file to the original filename
[12:13] <Keybuk> close the original file
[12:15] <Adri2000> yep, that indeed doesn't look correct when reading the code now. dunno why I didn't catch it when testing
[12:17] <doko> lool: hmm, the last xorg update forced a logout
[12:18] <Adri2000> Keybuk: and the internal server error is caused by the wrong ownership?
[12:18] <siretart> cjwatson: is it already shown that moving the required libs to /lib will indeed solve the race conditions of that bug?
[12:19] <cjwatson> siretart: which race conditions are those?
[12:19] <cjwatson> siretart: the existence of race conditions here seems to be complete speculation?
[12:20] <siretart> sorry, I cannot fully focus on that bug right now (I'm at work), but AFAIR the race that the networking must not be initialized too early else it will fail
[12:20] <Keybuk> Adri2000: yes
[12:20] <siretart> that bug does AFAIUI not only occur on systems with seperate /usr
[12:21] <Keybuk> that doesn't sound like a race condition
[12:21] <Keybuk> that sounds like a "hey, where did my dependencies go" condition
[12:22] <Keybuk> or a "ra ra ra before the left foot went in" condition
[12:22] <cjwatson> if it relied on being able to write to the root filesystem at some point, that would also explain why the udev rule didn't work
[12:22] <siretart> I have to admit that I didn't understand yet why wpasupplicant actually fails here
[12:22] <Keybuk> oh, wpa supplicant
[12:22] <Keybuk> it fails because most of the things wpa supplicant wants are under /usr
[12:22] <Keybuk> and wpa supplicant tries to write to the filesystem
[12:23] <Keybuk> both of these are false assumptions
[12:23] <cjwatson> Keybuk: yes, that was what I was asking siretart about way up ^- there
[12:23] <cjwatson> see my last comment in bug 44194
[12:23] <cjwatson> I think most of the write-to-the-filesystem bits have been fixed since the original bug was filed
[12:23] <siretart> Keybuk: err, why would that fail on systems with /usr on /?
[12:23] <cjwatson> the only thing I see remaining is the logging
[12:24] <Adri2000> Keybuk: k, well I'm going to fix the code. in the meantime, we should restore the comments file from DaD. also when is merge-status.py run? if I can't give you a patch before the next run, we should disable remove_old_comments() call until then
[12:24] <cjwatson> siretart: writing to the root filesystem would fail even so - and you would certainly make that "go away" by forcing the device to come up after S40networking
[12:24] <Keybuk> Adri2000: please just fix it
[12:24] <Keybuk> no point working around it until then
[12:24] <Keybuk> since it'll just break again in 40 minutes time
[12:24] <Keybuk> and an hour after that
[12:24] <Keybuk> etc.
[12:25] <siretart> cjwatson: okay, so your suggestion only covers the "/usr is seperate" problem, right?
[12:26] <cjwatson> siretart: no, I think it covers both provided that the original problem was in fact due to trying to write to the root filesystem
[12:26] <cjwatson> I agree that there is some speculation here
[12:26] <cjwatson> but I think it would be a whole lot easier to work out what's going on if wpa devices were working like the rest of the boot sequence
[12:26] <siretart> sure
[12:27] <cjwatson> you suggested wpasupplicant failing to start yourself as a possible cause
[12:28] <cjwatson> but I do concede I have not proven anything yet
[12:28] <cjwatson> this just seems like the best path to satisfying everyone
[12:28] <cjwatson> I think we can move the libraries to / regardless, and then proceed with wpasupplicant testing out of a PPA
[12:29] <cjwatson> anything that hardcodes those library paths is truly broken :-)
[12:29] <siretart> that would affect 3 packages: openssl, pcsc-lite and libz
[12:29] <siretart> with libcrypto being the largest
[12:30] <siretart> for local testing, wouldn't it be sufficient to hardlink these 4 libs to /usr?
[12:30] <siretart> for local testing, wouldn't it be sufficient to hardlink these 4 libs to /lib?
[12:35] <cjwatson> I guess, but it seems obviously correct to move them regardless of anything else
[12:35] <cjwatson> and ITYM copy, if /lib and /usr/lib are on different filesystems
[12:35] <siretart> of course
[12:36] <Adri2000> Keybuk: what about http://adrishost.net/~adri2000/ubuntu/MoM-comments.patch ? (not tested, and the same is needed for manual-status.py)
[12:36] <cjwatson> but I could start with PPA packages of  openssl pcsc-lite zlib wpasupplicant  and see what happens, I support
[12:36] <cjwatson> suppose
[12:36] <ion_> Let’s just make /usr/lib a symlink to /lib ;-)
[12:37] <cjwatson> I'm not going there
[12:37] <Mithrandir> ion_: let's make /usr a symlink to / :-)
[12:37] <ion_> :-)
[12:39] <Adri2000> Keybuk: if you don't have any more recent backup of the comments, use those we imported yesterday: http://adrishost.net/~adri2000/ubuntu/DaD.comments
[12:40] <Keybuk> Adri2000: looks better
[12:40] <Keybuk> you need locking in get_comments
[12:41] <Adri2000> why? it doesn't write anything, it just reads the file
[12:45] <evand> Is setting a contact address the only thing I need to do to prevent core-dev from getting spammed by being a member of another team?
[12:46] <LordMetroid> Where can I see what the repositories contains for the upcomming Jaunty
[12:47] <directhex> LordMetroid, http://mirror.ox.ac.uk/sites/archive.ubuntu.com/ubuntu/dists/jaunty/main/binary-amd64/Packages.bz2
[12:49] <lool> doko: Really?  I don't think it was my change as I only changed:
[12:49] <lool> -    alpha|hurd-i386|i386|amd64)
[12:49] <lool> +    alpha|hurd-i386|i386|amd64|lpia)
[12:49] <lool> in the postinst
[12:49] <lool> But it might be a bug in this package still
[12:54] <Stskeeps> Keybuk: ping
[12:55] <Laney> could it be made more obvious that there is a text field on mom?
[12:59] <sistpoty|work> Laney: that's security by obscurity :P
[13:00] <Stskeeps> Keybuk: (and if you're pondering why i'm pinging you: is it possible to seperate bootchart into gathering and chart generation, much like bootchart and bootchart-view in debian.)
[13:06] <RainCT> Laney: it's more obvious in my new design
[13:06] <RainCT> Laney: (and Ajax will also come)
[13:12] <ogra> doko, did you have qemu running by chance when that happened ? i noticed if i hit page down in qemu my X seems to crash
[13:12] <doko> ogra: no
[13:12] <ogra> i had that twice yestrday but didnt have time to research ir more yet
[13:12] <ogra> *it
[13:15] <apw> is the main login screen part of the gdm package?
[13:15] <apw> for reporting bugs in it?
[13:16] <cjwatson> broonie: I don't suppose you still have the diff from zlib 1:1.1.4-12 -> 1:1.1.4-13? It would save me resurrecting it ...
[13:16] <cjwatson> or rather redoing
[13:16] <cjwatson> (see above discussion about wpasupplicant library dependencies in /usr)
[13:17] <broonie> cjwatson: I very much doubt it.
[13:18] <broonie> snapshot.debian.net?
[13:18] <amitk> apw: apt-cache search gdm-themes?
[13:18] <cjwatson> looked there
[13:18] <cjwatson> I wasn't sure, I take the packrat approach to my uploads but I know not everyone does :-)
[13:18] <doko> asac: please upload xulrunner-1.9
[13:19] <broonie> I do but the machine that's got the archives that old on is kaput right now.
[13:19] <cjwatson> ah
[13:19] <cjwatson> oh well, sure it can't be that hard
[13:19]  * broonie wonders WTF I was doing up early enough to do uploads at 8am
[13:19] <broonie> No, from memory it's very straightforward.
[13:20] <broonie> and bitrotted by an intervening upstream build change IIRC
[13:20] <apw> amitk, there are only three bugs ever in there
[13:20] <amitk> apw: I thought I saw ubuntu-gdm-themes being updated today
[13:20] <amitk> but I could be wrong
[13:21] <apw> amitk, i have no clue how to find the package for half the things i see these days ... its probabally that one... will try and figure it out
[13:26] <lamont> pitti: gar.
[13:27] <ogra> amitk, uploaded tue.
[13:27] <ogra> apw, the gdm theme is ubuntu-gdm-themes ...
[13:27] <apw> ogra, thanks ...
[13:28] <asac> doko: for the transition?
[13:28] <asac> doko: you can just upload by appending .doko to current revision
[13:28] <asac> ;)
[13:29] <asac> if its just a respin i mean
[13:29] <doko> asac: ok, will do, but without the doko ...
[13:30] <asac> doko: whatever just use ubuntu1.something
[13:30] <asac> and not ubuntu2 ;)
[13:30] <asac> otherwise i have to bump in bzr ;)
[13:40] <pitti> lamont: sorry..
[13:40] <cjwatson> broonie: lp:~ubuntu-core-dev/zlib/ubuntu, FYI (figured I might as well!)
[13:42] <dholbach> Matthias "doko", "Upload king" Klose
[13:46] <broonie> cjwatson: Thanks, patches from Ubuntu is hte main reason I tried bzr :(
[13:54] <Keybuk> Stskeeps: I've never seen the point of that
[13:55] <Stskeeps> Keybuk: of seperating them? well, example - mobile device, limited space, you don't want to install a jre to get a simple bootchart
[13:55] <cjwatson> broonie: well, the two outstanding patches are lpia (fairly Ubuntu-specific) and the amd64 library path stuff which would break on Debian. I've sent you a bug for the lpia addition just in case you want it though
[13:55] <cjwatson> (since it's harmless)
[13:55] <Keybuk> Stskeeps: but then you have all the faff of trying to copy off tarballs, etc.
[13:56] <Stskeeps> Keybuk: which is immensely less troublesome than making space for a JRE :P if i wanted to generate bootcharts on-device, i could always apt-get install bootchart-view, but in 95% of cases, i wouldn't
[13:56] <Stskeeps> and i would delegate the work to a more powerful machine
[13:57] <Stskeeps> also, there are tools generating bootchart format files as well, and would like to not have to include the data gathering part, but would want the chart generator.
[13:58] <Keybuk> Stskeeps: fair enough
[14:01] <seb128> Keybuk: have you seen that some guys rewrote bootchart in python now?
[14:01] <Keybuk> seb128: no, I hadn't seen
[14:01] <Keybuk> *sigh* @ language elitism
[14:02] <seb128> Keybuk: http://mail.gnome.org/archives/performance-list/2009-February/msg00000.html
[14:02] <seb128> Keybuk: I've to admit I would prefer using python, some update recently installed me a lot of jre things only for bootchart and it breaks since when bootcharting desktop login
[14:02] <Keybuk> breaks how?
[14:03] <seb128> I've to look into details, it just didn't write an image in the log directory when running the stop-bootchart script after login
[14:04] <seb128> I will have a look at next book and file a bug if that's still an issue
[14:04] <broonie> cjwatson: Yeah, I know - it was more of a general comment, really.
[14:04] <Keybuk> if you could have a look, that would be appreciated
[14:04] <Keybuk> in the bug, note:
[14:04] <Keybuk> is bootchart-collector running before you run stop-bootchart
[14:04] <Keybuk> if not, can you see a core file in /dev/.bootchart or similar?
[14:04] <seb128> ok, I don't want to reboot now but I will try a bit later and let you know
[14:05] <Keybuk> try adding debugging stuff (like ulimit -c unlimited and >logfile 2>&1) to the initramfs init-stop script, regenerate and reboot
[14:30] <Riddell> james_w: bzr-buildpackage -S -sa  why is -sa not an option?  how do I get it to include the .orig?
[14:31] <james_w> "bzr-buildpackage -- -S -sa" if you are on an up-to-date jaunty
[14:31] <Riddell> but of course
[14:32] <james_w> annoying, I realise, but a huge improvement on Intrepid
[14:35] <lool> Keybuk: Did you fail reproducing the Gtk+ issue locally?  would be faster if you could reproduce
[14:36] <doko> pitti: is #334834 a real problem?
[14:36] <Keybuk> lool: it needs a newer version of glib than I have
[14:36] <Keybuk> so it failed to even configure
[14:43] <BUGabundo> bryce ping
[14:43] <BUGabundo> bug 335465
[14:44] <lool> Keybuk: You're running?  intrepid?
[14:45] <ScottK> slangasek: Thanks for taking care of the backports.  plasmoid-am4rok was for amarok 1, so it's dropped in Jaunty, but since we backported KDE4.2, it needed to be updated in backports for libplasma3.  Sorry I didn't explain it.
[14:45] <liw> today does not seem to be the day when I get jaunty installed... upgrading broke the machine completely (every boot crashed hard), and today's installer tells me the kernel doesn't see partitions it has just created
[14:45] <Keybuk> lool: yes
[14:46] <BUGabundo> liw: humm is it the udev bug? wasn't that fixed?
[14:47] <Keybuk> the kernel doesn't see the partitions?
[14:47] <Keybuk> BUGabundo: we didn't include the fix in alpha 5
[14:47] <liw> BUGabundo, I have no idea what bug it is
[14:48] <liw> Keybuk, is it in the daily iso image on cdimage right now?
[14:48] <pitti> doko: how do you mean?
[14:48] <Keybuk> liw: the live image is yesterday's
[14:48] <Keybuk> so no
[14:49] <BUGabundo> guys the LP retracer is closing all bug as invalid
[14:49] <BUGabundo> with this text
[14:49] <BUGabundo> However, processing it in order to get sufficient information for the developers failed (it does not generate an useful symbolic stack trace). This might be caused by some outdated packages which were installed on your systemat the time of the report:
[14:49] <BUGabundo> bug 334834 , bug 333530 and few other dups
[14:49] <liw> Keybuk, hmm, damn, then there's no point in getting the alpha5 image, either (should be the same iamge)
[14:49] <pitti> doko: looks like python sigsegved, but that particular report is fairly useless
[14:49] <BUGabundo> liw did you upgrade with CD or UM -d ?
[14:50] <liw> BUGabundo, upgarde with update-manager, install from scratch with cd (really: usb)
[14:50] <liw> the installer thinks helsinki is in murmansk, but I could live with that
[14:50] <BUGabundo> s/cd/live image/
[14:50] <Keybuk> liw: all of the city locations seem a little bit out
[14:51] <Keybuk> I guess that the projection of the map changed from the original graphic to the timezone one
[14:51] <Keybuk> and the city location overlay hasn't been adjusted to the new projection
[14:53] <liw> Keybuk, something like that
[14:58] <doko> seb128: I need another pygobject upload (hardcoded python2.5 interpreter version causing build failures)
[14:58] <seb128> doko: just upload if you need to, there is no bzr nor pending work for thise
[14:58] <seb128> those
[14:58] <seb128> I'm about to run for a bit now but I can have a look later if you don't
[15:09] <RainCT> savvas: weird, I got it
[15:14] <RainCT> savvas: now?
[15:14] <savvas> RainCT: yes
[15:14] <RainCT> :)
[15:15] <savvas> what was wrong? :P
[15:15] <RainCT> (don't ask :))
[15:15] <savvas> ah come on
[15:16] <RainCT> savvas: was giving it 'email1, emails2, email3' but it wanted them in a list.. if I tried with more than one mail only the first person in the list got it :p
[15:17] <savvas> hehe, glad it was solved, revu back in action!
[15:18] <RainCT> The sad thing is that nobody beside you noticed this :P
[15:18] <RainCT>  
[15:19] <RainCT> err.. /me wonders why he moved to -devel :P
[15:19] <cafetiere> for better weather?
[15:28] <calc> mdz: on jaunty?
[15:36] <cjwatson> liw: the partitioner problem is a race condition, so repeated tries should eventually succeed
[15:39] <cjwatson> ogra: given the slug workaround we discussed yesterday and documented in the release notes, can I safely assume that you no longer need a custom build?
[15:50] <mdz> calc: yes
[16:01] <calc> mdz: i'll test it out and see if i can reproduce the problem
[16:08] <mdz> calc: seb128 pointed out it may be bug #286175
[16:09] <calc> mdz: ah so its a fontconfig bug?
[16:09] <mdz> calc: I don't know
[16:10] <calc> ah i see i responded to the bug a while back
[16:10] <calc> looks like it is probably fontconfig if it affects both OOo and evince the same way
[16:10] <calc> i haven't triggered the OOo crash in a while which was why I had forgotten about it
[16:12]  * calc sees a patch and checks to see if it is in ooo-build yet
[16:25]  * BUGabundo and uswsusp hibernate support discussion starts again
[16:32] <calc> mdz: i should have the issue fixed in the next upload, which should be next week
[16:36] <mdz> calc: cool, thanks!
[16:50] <savvas> bzr suggests an upgrade for lp:~ubuntu-core-dev/software-properties/main - http://paste.ubuntu.com/123882/
[16:52] <Keybuk> lool: kooky
[16:52] <Keybuk> libtool: link:  cat .libs/libgdk_pixbuf-2.0.exp | sed -e "s/\(.*\)/;/" >> .libs/libgdk_pixbuf-2.0.ver
[16:53] <lool> Keybuk: Ah great, I searched for similar constructs but didn't find them
[16:54] <lool> Keybuk: Actually that's from libtool isn't it?
[16:54] <lool> Keybuk: But *libtool* is corrupted way before that
[16:54] <lool> Keybuk: Which is why you see a \001
[16:55] <Keybuk> you're supposed to see a \001 there though, right?
[16:55] <Keybuk> ohhhh
[16:55] <Keybuk> hahahahahahaha
[16:55] <Keybuk> something is turning \1 into the ^A :p
[16:55] <Keybuk> where \1 is the sed "first thing I matched" thing
[16:57] <Keybuk> interesting that immediately after configure, the libtool script is valid
[17:00] <Keybuk> lool: it's the po-properties subdir doing it
[17:00] <Keybuk> ah
[17:00] <Keybuk> hahaha
[17:00] <Keybuk> this Makefile is just wrong
[17:01] <Keybuk> 	  && CONFIG_FILES=po-properties/Makefile.in CONFIG_HEADERS= \
[17:01] <Keybuk> 	       /bin/sh ./config.status
[17:05] <Keybuk> lool: anyway, not a libtool bug
[17:06] <Keybuk> replace SHELL=/bin/sh with SHELL=@SHELL@ in po-properties/Makefile.in.in
[17:09] <lool> Keybuk: /usr/share/gettext/po/Makefile.in.in
[17:09] <lool> SHELL = /bin/sh
[17:09] <lool> Keybuk: And there are more examples
[17:09] <lool> Keybuk: I raised this in my report
[17:09] <calc> zul: ping
[17:09] <lool> Keybuk: These makefiles are all awful, but I don't think there are the origin of the issue since we have these Makefile.in.ins since years
[17:11] <lool> Keybuk: I described the same symptoms you listed here in my bug report BTW
[17:17] <lool> doko: I upgraded to new xorg just fine; didn't cause any issue here; not sure what you had
[17:28] <tedg> Keybuk: So can root get all the DBus session busses?
[17:36] <pitti> asac: can you followup on bug 314778, since you already handled that before?
[17:37] <asac> pitti: i am still fighting to get a go from upstream
[17:38] <asac> its kind of a wierd situation. everybody say "usually we dont break ABI/API in security updates"
[17:38] <asac> weird
[17:39] <asac> but when you ask for a promiss/policy, it becomes hard
[17:39] <asac> so far the only promise they have is to track XPCOM components
[17:39] <asac> but i will poke around, hopefully getting a definite go or no by monday
[17:40] <pitti> asac: I see; thanks
[17:46] <kirkland> asac: hey, question about /etc/network/interfaces, i thought you might know ....
[17:46] <kirkland> asac: is it possible to configure an interface to set it's wake-on-lan bit there?
[17:47] <kirkland> asac: i'm currently hacking it with "ethtool -s eth0 wol g" in /etc/rc.local
[17:47] <kirkland> asac: i'd like a more configurable way of setting this, and /etc/network/interfaces seems to be an ideal place for it
[17:48] <kirkland> asac: thoughts?
[17:49] <hyperair> kirkland: ethtool
[17:50] <hyperair> oh whoops mentioned already
[17:50] <hyperair> i should really read the entire scrollback before replying
[17:50] <hyperair> kirkland: actually the wake-on-lan bit should be persistent once you set it once.
[17:50] <kirkland> hyperair: no worries. i'd like to make that configuration stick
[17:50] <hyperair> kirkland: why are you sticking it in ethtool?
[17:50] <IntuitiveNipple> kirkland: I usually add such commands to a pre-up or up statement in interfaces
[17:50] <hyperair> it should be tracked by.... erm... the card i think
[17:50] <hyperair> and the BIOS
[17:50] <hyperair> yeah
[17:51] <hyperair> traditionally, you'd configure this only in the BIOS, but ethtool brought a way of configuring it within the OS
[17:52] <kirkland> hyperair: hmm, i'll test again
[17:52] <kirkland> hyperair: i had to do it in both bios and the os
[17:52] <asac> kirkland: not that i know. if you use ifupdown you can use pre-post-up things maybe to hook your manually tweakage
[17:54] <kirkland> asac: how hard/bad would it be to add a parser for "wakeonlan 1" / "wakeonlan 2" in /etc/network/interfaces?
[17:54] <kirkland> asac: how hard/bad would it be to add a parser for "wakeonlan 1" / "wakeonlan 0" in /etc/network/interfaces?
[17:54] <hyperair> asac: generally that gets called on boot too, so you don't have to use ifupdown
[17:54] <kirkland> ie, toggle on/off there
[17:54] <hyperair> kirkland: there probably wouldn't be a point in that, because it is _supposed_ to be persistent
[17:54] <hyperair> it is on my hardware.
[17:55] <asac> kirkland: are there other options from ethtool that one would want?
[17:56] <asac> kirkland:  and yes, i am not really sure that this belongs to ifupdown; not sure where the best place to put such configuration would be though
[17:56] <zul> calc: pong
[17:57] <kirkland> asac: okay, fair enough
[17:57] <kirkland> hyperair: let me check
[17:57] <asac> kirkland: maybe even udev?
[17:57] <asac> kirkland: technically it should be easy to add options like ethtool-OPTION <value>
[17:57] <asac> but i dont think that we want it
[17:58] <kirkland> asac: right.  let me make sure my request is even valid.  if that ethtool command is something you only have to run once, it shouldn't be something that we should have to worry about
[17:59] <asac> kirkland: yeah. i think the question is if that config is really assocaiatede with a certain interface/connection configuration
[17:59] <asac> if its not , then it has to be done somewhere else
[18:00] <Keybuk> lool: yeah they are
[18:00] <Keybuk> remember that Autoconf and libtool are designed to be portable
[18:00] <Keybuk> that means they can't just use POSIX shell, since that's a relatively modern invention which most old-style UNIXes haven't adopted
[18:00] <Keybuk> it turns out it's pretty near impossible to write shell that operates exactly the same
[18:00] <Keybuk> at least, not useful shell
[18:00] <Keybuk> so m4sh works by picking a shell, and coding to it
[18:01] <Keybuk> it generally prefers bash, since bash behaves predictably
[18:01] <Keybuk> so it then outputs, on your machine, all shell written for bash
[18:01] <Keybuk> not for posix sh, not for sun sh, etc.
[18:01] <Keybuk> that means that the value of $SHELL is kinda important
[18:05] <kirkland> asac: wakeonlan is absolutely something that's associated with a given interface
[18:05] <kirkland> asac: you send wakeonlan packets to a MAC address
[18:06] <lool> Keybuk: So where does the regression come from?
[18:06] <Keybuk> lool: the regression is caused by that Makefile doing something it shouldn't
[18:07] <lool> Keybuk: Plenty of makefile.in.in do it
[18:07] <Keybuk> (calling an Autoconf-generated script with something that's not the Autoconf-chosen SHELL)
[18:07] <lool> Keybuk: gettext and intltool's are frequent examples
[18:07] <Keybuk> yes, that doesn't mean it's write
[18:07] <Keybuk> err, right
[18:07] <Keybuk> I'd guess gettext did it wrong first
[18:07] <Keybuk> and everybody copied that Makefile.in.in
[18:07] <lool> Keybuk: I understand, but we can't simply drop support for all the Makefile.in.in in the tarballs currently available from download sites
[18:07] <Keybuk> It's specifically wrong according to the Autoconf documentation
[18:07] <asac> kirkland: yes. its assocaited to a given interface, but not to a given connection
[18:07] <Keybuk> autoconf.info 11.9
[18:08] <Keybuk> If you
[18:08] <Keybuk> use Autoconf, do
[18:08] <Keybuk>      SHELL = @SHELL@
[18:08] <Keybuk>    Do not force `SHELL = /bin/sh' because that is not correct
[18:08] <Keybuk> everywhere.
[18:08] <asac> kirkland: think about the "mapping" feature of ifupdown ... you can have HOME and WORK connection for eth0 interface
[18:08] <lool> Keybuk: I know, I even pointed it out in my report, but I can't fix all the released tarballs and tell all upstream to change the Makefile.in.in, therefore I think we should revert the change which expose this bug
[18:08] <Keybuk> lool: I disagree
[18:08] <lool> It's ok to raise the Makefile.in.in in parallel with the relevant upstreams, but will take long
[18:08] <Keybuk> we should fix this bug
[18:08] <lool> Keybuk: I don't intend to not fix it
[18:08] <lool> I'm just saying it's the wrong thing to fix first
[18:09] <Keybuk> when did you first notice the bug?
[18:10] <asac> kirkland: also, does the interface need to be up to set wol?
[18:10] <asac> kirkland: e.g does it work even if you ifconfig eth0 down first?
[18:11] <lool> Keybuk: When I used the new autoconf with gtk+2.0
[18:11] <Keybuk> "the new autoconf" ?
[18:11] <Keybuk> what version of autoconf were you using before?
[18:11] <lool> I don't know when it was that I built gtk+ from source in the past, and I expect it's not specific to gtk+
[18:11] <kirkland> asac: i'm not sure;  i just assumed that ethtool would send an ioctl() of some kind to the device itself, and flag a bit on or off in the device
[18:11] <lool> Did you try with intrepid's autoconf?  Does it expose the same bug?
[18:12] <Keybuk> without knowing the time scale of when you first see the bug, it's impossible to identify any particular change
[18:12] <Keybuk> I did this on intrepid, yes
[18:12] <Keybuk> without knowing any more detail, I would say that all versions of autoconf since 2.50 would exhibit this
[18:12] <Keybuk> as would all libtool 2.x versions
[18:12] <lool> Keybuk: So you reproduced with pure intrepid?
[18:13] <lool> Keybuk: I can't believe gtk+ would have been un-bootstrapable for that long, that doesn't seem possible; we routinely have to relibtoolize it for ubuntu upadtes
[18:13] <Keybuk> lool: afaik, this is pure intrepid
[18:14] <Keybuk>  *** 2.61-7ubuntu1 0
[18:14] <Keybuk>         500 http://gb.archive.ubuntu.com intrepid/main Packages
[18:14] <Keybuk>         100 /var/lib/dpkg/status
[18:14] <pitti> ScottK: with your motu-release hat on, would you mind if I sync gtkperf from Debian to jaunty universe? I've been asked to get it into Ubuntu
[18:14] <Keybuk> automake:
[18:14] <Keybuk>  *** 1:1.10.1-3 0
[18:14] <Keybuk>         500 http://gb.archive.ubuntu.com intrepid/main Packages
[18:14] <Keybuk>         100 /var/lib/dpkg/status
[18:14] <Keybuk> libtool:
[18:14] <Keybuk>  *** 2.2.4-0ubuntu4 0
[18:14] <Keybuk>         500 http://gb.archive.ubuntu.com intrepid/main Packages
[18:14] <Keybuk>         100 /var/lib/dpkg/status
[18:14] <lool> Keybuk: How come it doesn't break all autoreconfing of all tarballs using gettext or intltool?
[18:14] <pitti> ScottK: do you want bug red tape for it?
[18:14] <Keybuk> lool: well, that config.status rule would be very rarely invoked
[18:14] <asac> kirkland: yeah. i really think the hook belong further down
[18:15] <Keybuk> lool: or at least, it _should_ be very rarely invoked
[18:15] <Keybuk> but it doesn't seem to be
[18:15] <Keybuk> infact
[18:15] <Keybuk> it's quite odd
[18:15] <Keybuk> it seems to be expecting POTFILES to be a source to its own Makefile
[18:15] <lool> Keybuk: This rules seems to be run on all builds since Makefile isn't generated by config.status
[18:16] <Keybuk> yeah but that again should be the same as gettext
[18:16] <lool> Keybuk: argh
[18:16] <lool> Keybuk: AC_OUTPUT_COMMANDS is specific to gtk+2.0
[18:17] <Keybuk> how do you mean?
[18:17] <primes2h> pitti: Hi, this bug 259505 has been fixed upstream. Can I set it as "fix released" in upstream package in Launchpad?
[18:18] <lool> Keybuk: I was searching for something specific to gtk+2.0 which would explain why all gettext wouldn't break
[18:18] <lool> Keybuk: One thing which is clearly specific is this AC_OUTPUT_COMMANDS() in configure.in
[18:18] <Keybuk> lool: well, on normal gettext you see this in config.status
[18:18] <Keybuk> config.status: executing po-directories commands
[18:18] <Keybuk> config.status: creating po/POTFILES
[18:18] <Keybuk> config.status: creating po/Makefile
[18:18] <pitti> primes2h: that'll happen automatically after a while, Launchpad updates the states according ot upstream changes
[18:18] <Keybuk> ie. it makes po/Makefile
[18:18] <Keybuk> GTK+ doesn't seem to do that
[18:19] <primes2h> pitti: I know, but it has been fixed on 19 and still set as "New". Is it normal?
[18:19] <pitti> primes2h: hm, that's not normal then
[18:20] <pitti> primes2h: can you ask on launchpad-users@, or ping some launchpad guys on IRC?
[18:20] <lool> Keybuk: It does, but doesn't output "creating"
[18:20] <primes2h> pitti: what is the name of launchpad IRC channel?
[18:21] <primes2h> please?
[18:21] <Laney> are you kidding?
[18:21] <pitti> primes2h: I'm not actually sure; usually the mailing list is okay
[18:21] <Keybuk> lool: if it makes po-properties/Makefile - why does the Makefile rule to generate it get called at all?
[18:21] <pitti> primes2h: or just file a bug against malone
[18:21] <primes2h> pitti: ok, thanks.
[18:22] <lool> Keybuk: I wonder; the only thing I can think of is POTFILES being generated later
[18:23] <lool> But we'd see this with po/ as well
[18:23] <kirkland> why do i have to hit ctrl-alt-f1 twice in Jaunty to get to my tty1?
[18:24] <kirkland> when starting from gnome/X
[18:24] <Keybuk> lool: weird
[18:24] <kirkland> bryce: any idea?
[18:24] <Keybuk> kirkland: probably consolekit
[18:24] <Keybuk> lool: I've mailed the gettext people, btw
[18:24] <kirkland> Keybuk: is this desired behavior?
[18:24] <Keybuk> kirkland: no
[18:24] <bryce> yes that's a consolekit bug
[18:24] <Keybuk> lool: there's not really much we can do though, unless it's a specific patch that broke things
[18:24] <Adri2000> Keybuk: did you try to apply my patch?
[18:24] <kirkland> bryce: is it already reported, or should i do the duty?
[18:25] <Keybuk> Adri2000: what patch?
[18:25] <Adri2000> for MoM
[18:25] <Keybuk> Adri2000: lp url?
[18:25] <Adri2000> it's still borken
[18:25] <bryce> kirkland: dunno, it's pretty well known though.  Probably could use additional investigation in any case
[18:25] <Keybuk> lool: from what I can tell, this affects all current autoconf/libtool/etc.
[18:25] <lool> Keybuk: Either other projects have been particularly lucky because of po/ being built last or it's gtk+2.0 specific in which case we're safe
[18:25] <Keybuk> and is a direct side-effect of the way they write shell scripts
[18:25] <Keybuk> lool: I think that it's gtk+ specific
[18:25] <Adri2000> Keybuk: I gave it to you earlier and you answered "looks better"
[18:25] <Adri2000> http://adrishost.net/~adri2000/ubuntu/MoM-comments.patch
[18:25] <Keybuk> Adri2000: that was an incomplete patch to only one file, and I told you other changes that were needed
[18:25] <lool> Keybuk: I want to believe it is, but can't understand where it goes wrong
[18:26] <Adri2000> 13:40:43 <Keybuk> you need locking in get_comments
[18:26] <Adri2000> 13:41:36 <Adri2000> why? it doesn't write anything, it just reads the file
[18:26] <Adri2000> and?
[18:26] <Keybuk> Adri2000: otherwise while reading, what happens if someone writes
[18:26] <Keybuk> lool: to me, it's a bug that that Makefile rule gets called at all
[18:26] <Keybuk> lool: it shouldn't - those kinds of rules are *only* for rebuild after editing auto* source scenarious
[18:27] <Adri2000> Keybuk: everywhere something is written, the file is locked before. the get_comments() function only reads
[18:27] <Keybuk> Adri2000: but get_comments() doesn't lock the file
[18:27] <Keybuk> so while it's reading, something can write to the file
[18:28] <Keybuk> and since you don't use atomic overwrite everywhere ...
[18:28] <lool> Keybuk: Ah
[18:28] <lool> Keybuk: after configure, po-properties doesn't have a POTFILES while po has!
[18:28] <Keybuk> lool: ah!
[18:28] <Keybuk> lool: that's probably a bug ;)
[18:28] <Keybuk> I've just tested here btw, general gettext fails here too
[18:28] <Keybuk> but it's quite hard to replicate
[18:29] <Keybuk> ohhhhhhhhhhhhhhhh
[18:29] <Keybuk> I've just realised why general gettext doesn't replicate this ;)
[18:30] <Keybuk> gettext upstream only calls config.status with its own directory name
[18:30] <Keybuk> so it only regenerates po/Makefile
[18:30] <lool> Which is cleaner
[18:30] <Keybuk> so it doesn't smash libtool
[18:30] <lool> Keybuk: Ok, the po/POTFILES generation is in glib-gettext.m4, so it's specific to this implementation as well
[18:30] <Keybuk> it's still a bug that SHELL is overwritten, but it minimises it
[18:30] <Adri2000> Keybuk: so, if get_comments reads, and in the meantime something else writes. what happens? reading will fail?
[18:30] <lool> Keybuk: I think we have a bunch of bugs to fix here; thanks for debugging!
[18:31] <kirkland> Keybuk: bryce: thanks guys, i found the existing bug, Bug #271962
[18:31] <Keybuk> lool: I'll follow up with the gettext guys upstream
[18:31] <Keybuk> Adri2000: the fact you don't know what happens means you shouldn't tell me you don't need locking there <g>
[18:32] <Adri2000> Keybuk: I *think* reading will work and that's all. you tell me it needs locking, so you need to tell me why :)
[18:33] <Keybuk> no, I just need to tell you and not apply your patch until you add it <g>
[18:33] <Adri2000> a priori, no locking is needed IMO. except if you can tell me it's needed because ...*
[18:33] <Adri2000> -*
[18:34] <Keybuk> what happens will be a bit random
[18:34] <Keybuk> UNIX doesn't have per-session file images
[18:34] <Keybuk> if two people open a file, one for reading, and one for writing
[18:34] <Keybuk> the read() will return bits of the old file and bits of the new file
[18:35] <Keybuk> the reader doesn't get an "old copy"
[18:35] <ScottK> pitti: I don't mind gtkperf.  Since the main reason we stop allowing new packages is to stop burdening the archive-admins with New'ing them, if you're up for the New, there's no reason not to.
[18:35] <pitti> ScottK: ok, thanks; I found an existing request for it and did it
[18:35] <Keybuk> so you need to avoid concurrent writes and reads
[18:35] <Keybuk> easiest way
[18:35] <ScottK> pitti: OK.
[18:35] <Keybuk> (whilst still allowing concurrent reads)
[18:35] <Adri2000> Keybuk: I clearly understand that two people opening a file for writing will result in unexpected behaviors. I don't understand the same for one person reading and another writing. but... ok, with what you just said, I'll add a lock :)
[18:36] <Keybuk> take out the reading lock with LOCK_SH
[18:36] <Keybuk> take out the writing lock with LOCK_EX
[18:36] <ScottK> LaserJock: I just skimmed the Edubuntu meeting.  I can tell you that my 5 year old absolutely loves Ktuberling.
[18:36] <Keybuk> that way, someone writing will queue up behind someone reading
[18:36] <Keybuk> while multiple people can read simultaneously
[18:38] <LaserJock> ScottK: awesome, thanks
[18:38] <Adri2000> Keybuk: okay
[18:38] <Keybuk> Adri2000: well, take this for an example
[18:38] <Keybuk> one process is using get_comments() as it exists currently
[18:38] <Keybuk> and is reading lines from the file
[18:39] <Keybuk> the merge-status.py runs
[18:39] <Keybuk> and that opens the file for writing (truncating it to zero bytes)
[18:39] <Keybuk> what happens to the process reading lines from that file?
[18:39] <Adri2000> it will see nothing in the file
[18:39] <Keybuk> but it's already read some of the file
[18:39] <Keybuk> it may even be halfway through a line
[18:39] <Keybuk> may not have reached the ":" yet
[18:39] <Adri2000> I see
[18:40] <Keybuk> suddenly it's off the end, and will return EOF
[18:40] <Keybuk> that person may see an exception, because you don't handle the ":" being missing
[18:40] <Keybuk> or that person will at best see incomplete comments
[18:40] <Keybuk> maybe even the last comment cut in half
[18:40] <Keybuk> clearly this is undesirable behaviour
[18:44] <Adri2000> Keybuk: patch updated, available at the same place
[18:47] <Adri2000> wait, I should add another LOCK_SH
[18:49] <Adri2000> everything is locked now
[18:49] <Adri2000> Keybuk: files open with r are LOCK_SH and files open with w or a are LOCK_EX. sounds good?
[18:50] <Keybuk> yup
[18:50] <Keybuk> pushed
[18:51] <Keybuk> now we just need to figure out how to deal with .comments changing permissions
[18:52] <lool> Keybuk: You have an upstream bug for gettext?
[18:52] <Keybuk> gettext doesn't have a bug tracker
[18:52] <Keybuk> it's a GNU project
[18:53] <Keybuk> they use bug-* mailing lists
[18:53] <Adri2000> Keybuk: my latest change has one more lock in manual/merge-status.py than what you committed
[18:53] <lool> Keybuk: I wonder whether it should use something else than $(SHELL) in Makefile.in.in; SHELL is used for all subcommands, so it might wiser to simply call ./config.status, or use another var e.g. CONFIG_SHELL = @SHELL@
[18:54] <Adri2000>      fcntl.lockf(file_comments, fcntl.LOCK_EX)
[18:54] <Adri2000> and
[18:54] <Adri2000>      fcntl.lockf(file_comments, fcntl.LOCK_SH)
[18:54] <Adri2000>      fcntl.lockf(file_comments_new, fcntl.LOCK_EX)
[18:54] <Adri2000> Keybuk: ^
[18:54] <Keybuk> SHELL is guaranteed by Autoconf to be a POSIX-compatible shell
[18:54] <Keybuk> that's kinda the point :p
[18:54] <Keybuk> Adri2000: I've already applied the patch, if you want me to make any other changes, you need to supply a new patch
[18:54] <Keybuk> Adri2000: no need to lock the "new" file
[18:54] <Keybuk> you only use it when you have a lock on the old file
[18:55] <Adri2000> I put lock everywhere now :P
[18:55] <Keybuk> (arguably you should not open the new file until you have the lock on the old)
[18:55] <Adri2000> hmm
[18:56] <Adri2000> and the lock on file_comments (open for reading) should be LOCK_SH rather than LOCK_EX no?
[18:56] <Keybuk> yes
[18:56] <Adri2000> ok, let me a minute and I give you a new patch
[18:56] <Keybuk> you should probably make comments_new be 666
[18:56] <Keybuk> otherwise the web server can't write to it
[18:57] <Adri2000> why would the web server write to it?
[18:58] <Keybuk> addcomments.py
[18:58] <Adri2000> adding a comment write directly to the comment file, it doesn't use a temporary "new" file
[18:58] <Adri2000> writes*
[18:59] <Keybuk> and how is it going to have permission to do that?
[18:59] <Adri2000> hmm when mv foo bar. bar gets foo's permissions?
[19:00] <Keybuk> yes
[19:00] <Keybuk> that's my point
[19:00] <Keybuk> when merge-status replaces the .comments file
[19:00] <Keybuk> the new .comments will only be writable by the user merge-status runs as
[19:01] <Keybuk> the web server runs as a different user
[19:01] <Keybuk> so now addcomments.py can't write to the file
[19:01] <hellocuckoo> Hi :)
[19:01] <Adri2000> Keybuk: right
[19:02] <hellocuckoo> hello, Im interested in Ubuntu development bu dunno where to start with my skill set... any1 there to help
[19:02] <hellocuckoo> ?
[19:03] <lool> Keybuk: What I'm saying is that SHELL in make is always set by make (at least in GNU make); if some commands rely on bash or /bin/sh and aren't compatible with the POSIX shell which configure selects (which might be e.g. zsh AFAIK), it might break random makefiles
[19:04] <Keybuk> lool: god no!
[19:04] <Keybuk> POSIX specifically forbids make from doing that
[19:06] <Keybuk> GNU make leaves SHELL at whatever is set in the Makefile
[19:06] <Keybuk> and if it's not set, uses /bin/sh
[19:06] <Keybuk> and *does not* pick it up from the environment
[19:06] <Keybuk> (so SHELL can never be zsh unless configure sets it that way)
[19:06] <Adri2000> Keybuk: os.chmod is strange
[19:07] <Keybuk> Adri2000: yeah, the API needs to be far more complicated than just a path and a mode
[19:07] <Keybuk> you want fchmod() and fchown() anyway
[19:07] <onnadi3> Hello all: is this the right channel to discuss ideas that were marked [IDEA] in the forums? I would like to contribute to one of them.
[19:08] <Keybuk> Adri2000: but I don't think the python on casey has those
[19:10] <Adri2000> Keybuk: I don't seem to have them either...
[19:11] <hellocuckoo> hello, Im interested in Ubuntu development but dunno where to start with my skill set... any1 there to help ??
[19:11] <directhex> hellocuckoo, depends on the skill set
[19:12] <slangasek> so, which component of GNOME is responsible for parsing of .desktop files?
[19:14] <hellocuckoo> i know java, html/css, PHP, Javascript and AJAX(learning)...... alittle C also.....
[19:14] <hellocuckoo> good at using linux environment...bash and stuff.........im very eager to learn all tht stuff
[19:14] <Adri2000> Keybuk: ah, actually os.chmod wants 0666 and not 666...
[19:15] <Keybuk> yes, it's called Octal
[19:15] <onnadi3> directhex: Hi. Do you know in which channel I can discuss possible additions to the ubuntu mouse preferences?
[19:16] <mneptok> onnadi3: any reason you don't want to bring this GNOME?
[19:16] <directhex> mneptok, thou shalt not make the mouse prefs useful
[19:16] <directhex> mneptok, linus learnt that lesson when he sent patches
[19:17] <mneptok> directhex: exactly, that's why i'm pointing him upstream ;)
[19:17] <Adri2000> Keybuk: http://adrishost.net/~adri2000/ubuntu/MoM-comments-more-fixing.patch
[19:18] <onnadi3> mneptok. Ah, I see. Well, I saw this thread in the ubuntuforums (http://ubuntuforums.org/showthread.php?t=410342) and thought some people here might be working on it
[19:18] <onnadi3> directhex: what kinds of patches did linus send anyway? :)
[19:19] <directhex> onnadi3, dunno, some mouse prefs stuff
[19:19] <lool> Keybuk: That's exactly what I'm saying: SHELL is currently set to /bin/sh by make, and that might be bash; if we start adding SHELL = @SHELL@ in the Makefile it wont be the case anymore
[19:20] <mneptok> onnadi3: ideas passed around on forums and never added as actual blueprints on LP have no chance of implementation.
[19:20] <hellocuckoo> directhex: am intersted in packagin too, but dunno how.... and the biggest prob is my collg LAN has irc blocked so i can't connect to irc usually....
[19:20] <mneptok> hellocuckoo: use an alternate port
[19:21] <hellocuckoo> only http and ftp work bro....
[19:21] <hellocuckoo> mneptok:
[19:21] <onnadi3> mneptok: I see. Thanks. I'll swim upstream and see what they say there
[19:21] <mneptok> hellocuckoo: no e-mail?
[19:21] <mneptok> hellocuckoo: no https?
[19:21] <hellocuckoo> mneptok: hav all tht, but not used to mailing lists and stuff..
[19:22] <mneptok> hellocuckoo: connect to irc.freenode.net:8000
[19:22] <hellocuckoo> mneptok: wat do u work on?
[19:22] <mneptok> hellocuckoo: usually a chair and a flat surface, like a desk.
[19:22] <bdmurray> tkamppeter: can bug 299011 be Fix Released?
[19:22] <hellocuckoo> mnetok: hahha.....wat team do u work with?? which software?
[19:24] <mneptok> hellocuckoo: i'm an (almost) former Canonical support monkey
[19:25] <hellocuckoo> mneptok: now?
[19:25] <mneptok> hellocuckoo: as of Monday a MariaDB boilerman
[19:26] <hellocuckoo> mneptok: so any advise where i shud start with?
[19:27] <mneptok> hellocuckoo: if you aren't doing active development, it's probably best to keep this channel clear for such work. i recommend idling in #ubuntu-motu and getting a sense of how Universe works.
[19:28] <Keybuk> lool: but that's ok
[19:28] <Keybuk> lool: because whatever SHELL is set to by Autoconf will be the right thing
[19:28] <Keybuk> /bin/sh might be the Solaris shell from hell
[19:28] <directhex> Keybuk, /bin/sh is awesome. tab complete is for girls
[19:29] <tkamppeter> bdmurray: Yes, bug 299011 is completely fixed with HPLIP 3.9.2. I have closed the bug now. I have posted an FFE for 3.9.2: bug 335116
[19:32] <bdmurray> tkamppeter: also the next upload of cups will have the apport-hook that gathers printing info in it.  What other packages could use it?
[19:33] <tkamppeter> bdmurray, I do not exactly know what the new apport hook does. pitti has added it. pitti, can you help bdmurray.
[19:34] <bdmurray> tkamppeter: I wrote it pitti sponsored it.  It gathers the same info as the printingbuginfo script.  I'm curious what other packages would benefit from that information.
[19:39] <Adri2000> Keybuk: now even the status pages themselves return internal server errors :/
[19:41] <tkamppeter> bdmurray, Ghostscript, all foomatic-... packages and printer drivers.
[19:42] <tkamppeter> bdmurray: They all get invoked by CUPS when executing a print job. So the error_log of CUPS helps also to debug all these packages.
[19:43] <bdmurray> tkamppeter: okay, great thanks
[19:44] <kirkland> hyperair: okay, i've tested it out ... that ethtool setting is not persistent across boots
[19:45] <kirkland> hyperair: sudo ethtool eth0 | grep Wake-on:
[19:45] <kirkland> hyperair: on a fresh boot, it's always "d"  (disabled)
[19:45] <hyperair> how very strange
[19:45] <kirkland> hyperair: i need to give it "g" to enable it
[19:45] <kirkland> hyperair: it might be particular to this hardware
[19:45] <kirkland> hyperair: but i've read elsewhere with people saying the same thing
[19:45] <hyperair> i see
[19:46] <hyperair> generally it's the bios which handles this =\
[19:47] <jdong_> I don't think that is true
[19:47] <jdong_> generally it is your OS's ACPI implementation that should handle it.
[19:48] <jdong_> BIOS handling it should be "legacy"
[19:48] <jdong_> for some silly misuse of the quoted term
[19:51] <porter1> Hey, anyone know why on x86_64, lib32 doesn't directly name the libraries (e.g. libGLU.so.1 instead of libGLU.so)
[19:51] <porter1> Is it to give x64 libs precdence?
[20:10] <EtienneG> hey guys
[20:10] <EtienneG> who do we poke when there is a -dbgsym missing on ddebs.u.c?
[20:12] <Mr-Woof> #join ubuntu-bugs
[20:12] <Mr-Woof> oops :)
[20:13] <EtienneG> pitti, my man, are you the one we should go to about missing -dbgsym on ddebs?
[20:14] <EtienneG> ha, /away
[20:14] <EtienneG> I will catch on Monday then
[20:18] <jdong_> EtienneG: missing or outdated?
[20:19] <EtienneG> jdong_, missing
[20:19] <jdong_> it kidna sucks that we dont get -updates and -security dbgsyms :(
[20:19] <EtienneG> stunnel4 for i386 in hardy
[20:19] <EtienneG> it is not from -update or -security
[20:19] <jdong_> interesting
[20:28] <slangasek> EtienneG: after the fact, there's not really a way to reconstitute the missing package short of doing another upload
[20:28] <slangasek> and you can't upload to the release pocket anyway, so...
[20:28] <EtienneG> slangasek, too bad then!  thanks for the info
[21:10] <bdmurray> slangasek: should bug 332962 be about grub?
[21:11] <slangasek> bdmurray: that's where it's already assigned - are you suggesting it's mis-assigned?
[21:12] <bdmurray> slangasek: I'm not suggesting, just wondering.
[21:12] <slangasek> bdmurray: I have no idea if grub is what OpenSUSE is using as their talking bootloader.  I think it's unlikely that we would want to support two different bootloaders, so grub (or eventually grub2) is probably the right place for it
[21:43] <tedg> Does Ubuntu Server have DBus?
[21:45] <Nafallo> tedg: apt-get install...
[21:45] <Nafallo> ;-)
[21:45] <ogra> cjwatson, right and i guess before the first user would complain we'd have a new d-i build anyway
[21:49] <Aquina> hy
[21:49] <Aquina> Is there a check routing in the kernel or somewhere else within the installer to perform a small CPU and RAM check? I often whished that was included due to the fact I already had several issues with corrupt AMD CPUs caused by ESD/EMI issues.
[21:59] <jdong_> Aquina: IMO the memtest and CD checksum items on the boot menu are for that purpose.
[21:59] <jdong_> the memtest for short period of time even will catch most of the RAM-related problems that might cause you grief
[21:59] <jdong_> and the CD checksum calculation should exercise the CPU a bit too
[22:16] <Aquina> thx, jdong_
[23:22]  * calc larts doko for uploading during freeze week :-\
[23:27] <slangasek> calc: ?
[23:35] <calc> slangasek: he uploaded OOo during the freeze i think because i wasn't going to upload it during the freeze just for a simple one line change
[23:35] <calc> slangasek: i have a bunch of things queued up to change for the next upload which i will be doing early next week anyway
[23:35] <calc> so it was just a waste of buildd time really :\
[23:36] <ogra> well, they are idle most of the time during a freeze
[23:36] <slangasek> I'm pretty sure the upload didn't happen during the milestone freeze
[23:36] <RainCT> (and download time for users :))
[23:36] <bdmurray> kirkland: is there a reason bug 313812 is private?
[23:37] <slangasek> calc: I see that the package was uploaded today, which isn't during the milestone freeze...
[23:37] <slangasek> (setting aside the question of whether OOo should be uploaded for a one-liner change :)
[23:37] <calc> slangasek: ah ok the changelog was from tue 24
[23:38] <calc> i didn't know if it had just been queued during the freeze..
[23:38] <kirkland> bdmurray: sort of ...
[23:38] <kirkland> bdmurray: it came from the RH security team, and it was private on their end
[23:39]  * calc is back to working on new OOo upload
[23:39] <kirkland> bdmurray: we went a few rounds with them as to whether or not it should be considered a security vulnerability (I don't believe so --  it's just a function of the way keyrings work)
[23:40] <bdmurray> kirkland: okay, thanks I was just curious
[23:40] <slangasek> calc: queued yes, but on his side. :)
[23:40] <kirkland> bdmurray: i'm okay with un-marking it private, but that should probably be cleared by jdstrand/kees/mdeslaur
[23:53] <slangasek> kirkland: want to test out a pam change before I upload it, to see whether it regresses anything for ecryptfs
[23:53] <slangasek> ?
[23:53] <kirkland> slangasek: yes
[23:54]  * kirkland is afraid already
[23:55] <slangasek> kirkland: lp:~ubuntu-core-dev/pam/ubuntu
[23:55] <kirkland> slangasek: I just replaced a few rungs on a stepladder... wanna climb to the top and make sure it still works?
[23:56]  * Nafallo replaces kirkland's stepladder
[23:56] <Nafallo> ;-)
[23:58] <slangasek> kirkland: as long as you're standing below to break my fall ;)
[23:59] <kirkland> slangasek: fair enough, sounds like a deal
[23:59]  * kirkland building