[01:01] <verb3k> Whatever happened to the to the kernel scheduler bug? (I've been trying to find it's entry in launchpad but no luck so far)
[02:08] <Hobbsee> morning all
[02:09] <LaserJock> hi Hobbsee!
[02:13] <TheMuso> Afternoon Hobbsee.
[02:14] <Hobbsee> hey LaserJock, TheMuso!
[03:02] <LaserJock> jdong, imbrandon : around?
[04:18] <lamont> slangasek: if we just do dund, then there's no bug in LP...
[04:20] <lamont> hrm... maybe I should get dbus working again on this machine before I upload a new bluez-utils, eh?
[04:22] <slangasek> ... ok :)
[04:25] <lamont> 105      12403  0.0  0.0   4268  1792 ?        Ss   Mar27   0:03 /usr/bin/dbus-daemon --system
[04:26]  * lamont is pretty sure there should be a name there, rather than '105' :-)
[04:26] <StevenK> 105       5380  0.0  0.0  23876  1248 ?        Ss   Feb05   0:19 /usr/bin/dbus-daemon --system
[04:26] <StevenK> It's like that on my machine too
[04:27] <lamont> interesting
[04:27] <lamont> I'm betting you don't get a dbus permission denied when you plug in a usb drive, though
[04:28] <StevenK> Right, I don't.
[04:28] <lamont> cannot mount volume.  Error org.freedesktop.DBus.Error.AccessDenied.
[04:28] <lamont> \o/
[04:28] <lamont> am I supposed to have a 'hal' group?
[04:29] <StevenK> I have a haldaemon group
[04:29] <StevenK> But no hal group
[04:29] <lamont> haldaemon:x:131:
[04:29] <lamont> ok
[04:30] <lamont> the other thing I did right about the time I upgraded to hardy was to rip out the ldap entries in nsswitch.conf... I fear maybe I needed some of that...
[04:30] <lamont> for my next trick, I'll just --reinstall all the hal and dbus crap
[04:30] <lamont> er, pacakges
[04:32] <slangasek> lamont: that's just because strlen("haldaemon") > 8 :P
[04:32] <lamont> slangasek: iz not.
[04:32] <slangasek> the 105 in your ps output? yes it is
[04:32] <lamont> oh, that
[04:32] <lamont> ok
[04:33] <lamont> actually, it's because strlen("messagebus") > 8 :-p
[04:33] <lamont> so, iz not. :-)
[04:33] <slangasek> ah, heh :)
[04:33] <lamont> interesting.  reinstall hal/dbus --> system restart required.  heh
[04:34] <StevenK> Yes.
[04:34]  * lamont applies the full-on redmond solution
[04:34] <lamont> brb
[04:34] <StevenK> Upstream are convinced you can't restart the dbus message bus, you need to reboot
[04:34] <slangasek> The full-on redmond solution?  You're going to buy someone else's innovation to solve your business needs?
[04:35] <StevenK> Hahah
[04:35] <lamont> well, I'm gonna guess that maybe the 5 "dbus-daemon --fork --print-address 25 --print-pid 27 --session" processes on the machine _might_ be related to my challenges
[04:35] <lamont> slangasek: lol
[04:35] <lamont> I was referring to the "reboot and see if that fixes it" approach, you ninny. :-p
[04:35]  * lamont really reboots
[04:41] <lamont> well, that was less than successful...
[04:42] <StevenK> Now it fails to boot?
[04:42] <lamont> nah
[04:42] <lamont> it boots
[04:42] <lamont> still refuses to mount media
[04:42] <lamont> A security policy in place prevents this sender from sending this message to this recipient
[04:42] <lamont> where is "message bus configuration file"
[04:42] <lamont> ?
[04:43] <lamont> error name "(unset)" destination "org.freedesktop.Hal"
[04:43] <StevenK> /etc/dbus-1/system.{conf,d/}
[04:43] <lamont> or am I missing something trivial?
[04:47] <lamont> well, on the bright side, I only have one dbus-daemon --session process now (and one --system)
[04:48] <lamont> does the user need to be in any particular group to mount USB media, I wonder?
[04:48] <StevenK> plugdev
[04:49] <lamont> plugdev:x:46:lamont,haldaemon
[04:52] <lamont> hrm... gutsy laptop has /var/run/hal, broken hardy desktop does not... I wonder if it should?
[04:52] <lamont> OTOH nothing is using /var/run/hal on the laptop
[04:52]  * lamont actually logs in on the laptop
[04:55] <lamont> ah.  that's just var/run/hal -> var/run/hald in the gusty->hardy transition
[04:55]  * lamont wishes he had some clue of how dbus/hal/etc actually bolt together so he could debug this...
[04:55] <lamont> I guess I'll just file the bug and see what happens... :-(
[05:05] <lamont> I wonder what package I should file that bug against?
[05:14] <lamont> well, adding dund fix0rs my palm syncing at least.
[05:14] <lamont> slangasek: last chance to squawk before I upload it (just added --enable-dund)
[05:21]  * lamont smiles at http://www.coloradoan.com/apps/pbcs.dll/article?AID=/20080331/BUSINESS/803310324/1046/CUSTOMERSERVICE02
[05:36] <slangasek> cjwatson: huh, system-tools-backends already has code that scans for matching zone files in some cases
[06:53] <warp10> Good morning
[07:03] <ogra_cmpc_> bryce, are you aware of problems with via chipsets and framebuffer memory detection ? seems i have some users where X doesnt start due to a memory mistmatch of what the framebuffer driver detects and what the xserver wants ao allocate
[07:03] <ogra_cmpc_> s/ao/to
[07:04] <ogra_cmpc_> bug #208137 (and probably related) bug #197514
[07:04] <ubotu> Launchpad bug 208137 in ltsp "HP t5000 - vt8623fb - memory size detection failed" [Undecided,New] https://launchpad.net/bugs/208137
[07:04] <bryce> ogra_cmpc_: nope; is that due to recent via changes?
[07:04] <ubotu> Launchpad bug 197514 in xserver-xorg-video-openchrome "VIA/S3G VT8623 [Apollo CLE266] display no longer works" [Undecided,Confirmed] https://launchpad.net/bugs/197514
[07:05] <ogra_cmpc_> bryce, i have feedback from three people, they claim it worked with one of the alphas
[07:05] <dholbach> good morning
[07:06] <ogra_cmpc_> bryce, https://lists.ubuntu.com/archives/edubuntu-users/2008-March/003815.html might be intresting as well
[07:06] <ogra_cmpc_> morning dholbach
[07:06] <dholbach> hi ogra
[07:12] <bryce> ogra_cmpc_: looks like superm1 has been posting updates to it - I'd speak with him.  Looks like a new upstream version was released in early January
[07:12] <ogra_cmpc_> ok, i'll try to catch him
[07:14] <bryce> ogra_cmpc_: timo has also done some recent updates, but only packaging stuff
[07:14] <ogra_cmpc_> yeah, i asked him already, he didnt know about the prob
[07:15] <bryce> ogra_cmpc_: it looks like the driver hasn't changed since january, so if the problem cropped up later than that, then it may be due to something other than the driver
[07:16] <ogra_cmpc_> bryce, do you mean the frameboffer driver or the X server ?
[07:16] <bryce> the X driver
[07:17] <ogra_cmpc_> to me it looks like X wants 32M while FB only allocates 16M
[07:55] <TheMuso> evand: Before you vanish, as I said in the meeting, I can start earlier tomorrow so we can work through a11y issues, if thats any help.
[07:55] <kagou> Hi
[07:57] <evand> TheMuso: ok, fwiw fixing the SUDO_* issue alone doesn't seem to solve the problem.
[07:57] <TheMuso> Ok, but that still needs addressing...
[07:57] <evand> I don't need to be anywhere tomorrow night, so I should be around to work through it with you.
[07:57] <evand> indeed
[07:58] <evand> I'm just invalidating my earlier statement about us being really close :)
[07:58] <evand> s/should/will
[07:58] <TheMuso> ok
[07:59] <TheMuso> And sorry, I meant this for the installer channel. :p
[08:03] <evand> heh, no worries
[08:16] <slangasek> Hobbsee, TheMuso: would you mind having a look at bug #209783 for a universe FFe?
[08:17] <ubotu> Launchpad bug 209783 in translate-toolkit "UVF exception / sync request for translate-toolkit" [Undecided,Confirmed] https://launchpad.net/bugs/209783
[08:18] <ogra_cmpc_> tjaalton, q-funk is using his ppa atm
[08:18] <tjaalton> ogra_cmpc_: hmm ok
[08:18] <ogra_cmpc_> so indeed he wont complain
[08:19] <ogra_cmpc_> and imho we should pull his packages for an SRU (with extreme testing in advance indeed)
[08:19] <ogra_cmpc_> we lost many users due to the amd breakage i'd love to win back
[08:20] <tjaalton> hmm the packages he's ppa has are for gutsy
[08:20] <ogra_cmpc_> (but i fear SRUs of such a size and possible impact)
[08:20] <tjaalton> so hardy should be fine
[08:20] <ogra_cmpc_> yeah, for hardy you dont need SRUs yet :0
[08:20] <ogra_cmpc_> :)
[08:20] <tjaalton> ah :)
[08:59] <LaserJock> is there a buildd admin about?
[09:01] <cjwatson> $ bzr checkout bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu
[09:01] <cjwatson> bzr: ERROR: Repository KnitPackRepository('file:///home/cjwatson/src/ubuntu/grub/bzr/ubuntu/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/grub/ubuntu/.bzr/)
[09:01] <cjwatson> slangasek: do you have any idea what's going on here?
[09:02] <slangasek> hrm, can't say that I do
[09:02] <cjwatson> hmm, the remote is a rich-root repository
[09:02] <slangasek> old version of bzr locally?
[09:02] <cjwatson> bug 205579
[09:02] <ubotu> Launchpad bug 205579 in bzr "bzr checkout doesn't work with rich-root-pack" [Undecided,New] https://launchpad.net/bugs/205579
[09:02] <cjwatson> includes workaround too, woo
[09:02] <slangasek> mm
[09:03] <slangasek> ah, good :)
[09:03] <slangasek> rich-root was unfortunately the only option that would let me splice a Debian svn branch with an upstream bzr branch
[09:03] <slangasek> ... and then I haven't been able to use it since because of a bzr-svn bug
[09:03] <cjwatson> yeah, it would be
[09:05] <seb128> does moving a conffile between binary packages require maintainer script handling?
[09:05] <slangasek> no
[09:06] <seb128> or just the appropriate replaces in the new binary?
[09:06] <slangasek> yes
[09:06] <seb128> ok, good
[09:06] <seb128> thanks
[09:16] <\sh> cjwatson: hmm....what about the daily of hardy server from today? I see, that alternate is already there...is server still in preparation? :)
[09:18] <pitti> Good morning
[09:18] <\sh> moins pitti :)
[09:19]  * pitti yawns and radiates hate towards EINTR, which kept him awake debugging half of the night
[09:19] <seb128> hey hey pitti
[09:23] <LaserJock> pitti!
[09:23] <LaserJock> just the man I wanted to see
[09:23]  * pitti hides
[09:24] <LaserJock> pitti: I need ghemical given back
[09:24] <pitti> LaserJock: done
[09:24] <LaserJock> pitti: excellent, thanks
[09:29] <cjwatson> \sh: cron job runs at a different time *shrug*
[09:30] <cjwatson> 31 7 * * *      for-project ubuntu cron.daily; for-project ubuntu cron.daily-live
[09:30] <cjwatson> 29 10 * * *     for-project ubuntu-server cron.daily; for-project ubuntu-server cron.ports_daily
[09:30] <\sh> cjwatson: ah...so it's still in makeing ;) -ENO it's UTC or CDC? or is CDC now UTC? :)
[09:31] <soren> CDC?
[09:31] <cjwatson> \sh: London time (UTC+0100 right now). Please have patience
[09:31] <cjwatson> Canonical Data Centre, I imagine
[09:31] <slangasek> asac: well, mozilla-plugin-gnash prerm is buggy, it uses "set -e" and then a "&&" instead of if;then
[09:31] <soren> Ah.
[09:32] <\sh> soren: in the past there was this special timezone named CDCT ;) Canonical DataCenter Timezone ;)
[09:32] <cjwatson> slangasek: is that buggy? I always used to think it was, but && is supposed to be enough to prevent set -e firing
[09:32] <soren> timezones are confusing enought withou people inventing their own acronyms and adding them to the soup.
[09:32] <soren> (how did that 't' wander all the way from the end of "without" to the end of "enough"?)
[09:33] <cjwatson> bash(1) says "The shell does not exit if the command that follows is [...] part of a && or || list"
[09:33] <cjwatson> dash(1) says "The exit status of a command is considered to be explicitly tested [...] if the command is the left hand operand of an "&&" or "||" operator"
[09:34] <cjwatson> http://www.opengroup.org/onlinepubs/009695399/utilities/set.html has similar language
[09:35] <cjwatson> so I think any shell that terminates under 'set -e' when you run 'false && true' is buggy
[09:36] <slangasek> oh, hmm
[09:37] <harrisony> has ext2 support being removed from the ubuntu installer (trying to debug why it isnt working)
[09:37] <cjwatson> harrisony: ! no
[09:38] <pitti> I created an ext2 partition with last week's daily
[09:38] <cjwatson> slangasek: bash, dash, and posh all seem to get this right; I think this is one of those pervasive shell myths, since both you and I had picked it up (unless it really does fail in some case more sophisticated than 'false && true')
[09:38] <slangasek> cjwatson: ok, you're right then; I guess I was mistaking this for the fact that it'll kill make if you do this :)
[09:38] <harrisony> argh, must be lvm then
[09:39] <cjwatson> harrisony: desktop CD?
[09:39] <cjwatson> slangasek: wow, so it does
[09:39] <slangasek> asac: ok, so instead it's just buggy because xulrunner-addons is missing from the list :-)
[09:40] <harrisony> cjwatson:  http://ubuntuforums.org/showthread.php?p=4635054
[09:40] <cjwatson> of course, because the compound command exits 1 and make can't/doesn't-want-to tell that it's part of a && list
[09:40] <harrisony> yes desktop cd
[09:40] <slangasek> cjwatson: right :)
[09:40] <cjwatson> harrisony: desktop CD doesn't support LVM, RAID, or encrypted partitions
[09:40] <cjwatson> harrisony: use the alternate CD
[09:40] <emgent> heya
[09:41] <cjwatson> ooh, the kernel guys made EDD a boot option
[09:41] <harrisony> cjwatson: ah ok, thanks
[09:41] <cjwatson> we might actually be able to do something with all those grub device mapping bugs, at least with a release note saying "if it breaks, use edd=on"
[09:42] <cjwatson> with a little bit of glue in grub ...
[09:42] <dneary> Any sign of Jono about?
[09:42] <asac> slangasek: oh its missing in prerm you mean?
[09:43] <slangasek> asac: correct
[09:43] <asac> slangasek: ok fixing
[09:43] <asac> slangasek: hmm ... do i need to do some cleanup?
[09:43] <slangasek> asac: ok, thanks - I haven't looked yet whether there's an open bug about this
[09:44] <slangasek> not really, the only opportunity you'd have to cleanup is if the user installed mozilla-plugin-gnash again?
[09:44] <slangasek> in which case, it's automatically not an issue? :)
[09:45] <asac> slangasek: no ... i mean cleanup for all those poor users that ended up in manual state :)... but i don't think i can detect if that happened by accident
[09:45] <slangasek> mmm, yes, difficult
[09:45] <pitti> tkamppeter: cupsys' ppd-poll-with-client-conf.dpatch was apparently rejected upstream; what should happen with that patch? Mike said it's incorrect?
[09:46] <slangasek> asac: some additional cleanup /may/ be possible, but there's no reason to tie it to fixing this part of the bug
[09:46] <asac> slangasek: i will upload the fix without cleanup for now
[09:48] <slangasek> ok, cheers
[09:48] <asac> at least there is a pattern. same is missing for gnash
[09:48] <asac> doing that too now
[09:51] <slangasek> :)
[09:52] <tkamppeter> pitti, it is some way to work around problems caused by badly implemented routers. I have a T-Online router which answers DNS requests with "noname" to all IPs which it has given via DHCP, and for which no hostname was set manually in the router.
[09:53] <pitti> tkamppeter: hm, why does upstream neglect that problem? i. e. does Mike refuse to fix the problem, or does he ack it, but he doesn't like the patch?
[09:53] <tkamppeter> Reverse DNS lookup of "noname" returns the IP of one arbitrary machine, always the same one.
[09:54] <pitti> tkamppeter: (BTW, I prepared 1.3.7 last night, will upload soon)
[09:54] <tkamppeter> CUPS covers the sace of not having DNS at all, but on my router one cannot turn off the DNS.
[09:55] <tkamppeter> Mike does not relly like to fix something here. He simply rejected the bug report once telling the patch is wrong and second telling it is a configuration problem of the network.
[09:58] <tkamppeter> It seems that Mike is strictly against workarounds for buggy hardware. See also the Ubuntu bug report about Brother printers which do return broken device IDs erratically. Bug 35638]
[09:58] <ubotu> Launchpad bug 35638 in cupsys "Printer is not detected properly over USB" [Medium,Confirmed] https://launchpad.net/bugs/35638
[09:58] <tkamppeter> I think this bug can probably fixed somehow by patching the USB CUPS backend.
[09:59] <dholbach> Keybuk: do you think we could have       create_devices || true        in udev's postinst? that'd fix its installation in my vserver :)
[09:59] <tkamppeter> I think this bug can probably fixed somehow by patching the USB CUPS backend.
[09:59] <tkamppeter> I was already thinking about starting some initiative with the distros (and also driver developers of manufacturers) about patching CUPS concerning hardware bug workarounds.
[10:00] <tkamppeter> Mike supports only what follows EXACTLY the standards.
[10:00] <tkamppeter> pitti, WDYT, what should we do here?
[10:02] <pitti> tkamppeter: ok, let's keep the patch for a bit then; maybe you can add some details to the ## DP: of the dpatch, an explanation, rationale, pointers to STRs?
[10:05] <ogra_cmpc_> seb128, if i understand 03_blacklist-directories.patch in glib2.0 right, everything mounted under /live/cow and /live/image should be completely ignored by nautilus ?
[10:05] <seb128> ogra_cmpc_: yes
[10:05] <ogra_cmpc_> hmm
[10:05] <ogra_cmpc_> doesnt work here
[10:05] <seb128> at least you should get no mount icons for those
[10:05] <seb128> not sure what you call completely ignored
[10:06] <ogra_cmpc_> i still se the cow device on my classmate desktop and its definately mounted under /live/cow everywhere
[10:07] <seb128> weird
[10:07] <seb128> only /media and user directory mounts should be listed
[10:08] <ogra_cmpc_> /dev/sdb2 /live/cow ext3 rw,noatime,relatime,data=ordered 0 0
[10:08] <ogra_cmpc_> unionfs / unionfs rw,relatime,dirs=/live/cow=rw:/live/rofs=ro,debug=4294967295,delete=whiteout 0 0
[10:08] <ogra_cmpc_> unionfs /dev/.static/dev unionfs rw,noatime,relatime,dirs=/live/cow=rw:/live/rofs=ro,debug=4294967295,delete=whiteout 0 0
[10:08] <ogra_cmpc_> thats what /proc/mounts has
[10:09] <ogra_cmpc_> shoould be ok i think
[10:09] <ogra_cmpc_> oh, wait
[10:09] <ogra_cmpc_> seb128, does it read mtab or /proc/mounts ?
[10:10] <ogra_cmpc_> i dont have a line for /live/cow in the output of mount
[10:10] <seb128> ogra_cmpc_: mtab I think
[10:10] <ogra_cmpc_> (i.e. no mtab entry)
[10:10] <ogra_cmpc_> aha
[10:11] <beasty_> morning
[10:13] <beasty_> is there some way to build your own .deb package out of a modified 'apt-get source' package ?
[10:14] <tkamppeter> pitti, I have added the description to the patch on SVN.
[10:15] <pitti> tkamppeter: to trunk?
[10:15] <pitti> tkamppeter: right, thanks!
[10:18] <cjwatson> beasty_: debuild (devscripts package)
[10:21] <pitti> keescook: you'll love the new cups' test suite, it's very rigorous (and it too me until 3 am to fix the bugs that it caught :) )
[10:22] <YokoZar> pitti: looks like we might need to add another package to ia32-libs https://bugs.edge.launchpad.net/ubuntu/+source/ia32-libs/+bug/210572
[10:22] <ubotu> Launchpad bug 210572 in ia32-libs "No sound in wine under amd_64" [Medium,New]
[10:22] <beasty_> cjwatson: thanks i'll take a look at it
[10:34] <tkamppeter> pitti, I have now reduced the fdi file for HPLIP to 10.5 kB, making space for one more package on the live CDs.
[10:34] <tkamppeter> Thank you for the tip.
[10:35] <pitti> tkamppeter: yay, with int_outof?
[10:35] <pitti> great
[10:35] <tkamppeter> I have tested it with my printers and it works. I have uploaded it to the Debian SVN of HPLIP and now I am test-building the package.
[10:36] <tkamppeter> Yes, it is with int_outof now.
[10:40] <beasty_> cjwatson: thanks it worked
[10:46] <tkamppeter> pitti, I have now replaced my HPLIP 2.8.2-0ubuntu5 packages by new ones with the same name, containing the new script which generates the smaller fdi file. Please re-download and upload them into Hardy.
[10:46] <pitti> tkamppeter: right, I'll do that
[10:46] <pitti> tkamppeter: what was the URL again?
[10:46] <laga> slangasek: did you have a change to talk to pitti or cjwatson about the priority of mythbuntu-diskless-client-builder for the alternate disk?
[10:47] <slangasek> laga: ah, no
[10:48] <slangasek> pitti, cjwatson: trying to get mythbuntu-diskless-client-builder installed by default on the mythbuntu alternate CDs; is setting Priority: standard on it in the archive a reasonable means of achieving this, or is that a Bad Idea?
[10:49] <pitti> slangasek: do we even look at Priority:? I thought our way of doing that was to put it into the ship seed?
[10:49] <slangasek> pitti: udebs don't go in the seed...
[10:49] <pitti> erm, not ship, mythbuntu  desktop?
[10:49] <slangasek> sorry, I guess I omitted that part
[10:49] <slangasek> this is a udeb :)
[10:49] <pitti> ah, udeb; no idea about that one, sorry; installer seed?
[10:50] <ogra_cmpc_> seb128, now thats silly, the device is ignored if i have an fstab entry for /live/cow ... no matter what mtab says
[10:50] <pitti> slangasek: AFAICS udebs are in the 'installer' seed
[10:50] <slangasek> pitti: I'm pretty sure the alternate CD doesn't use seeds at install time
[10:50] <pitti> right, they don't
[10:50] <slangasek> pitti: this is about being able to get a udeb automatically installed in the installer environment
[10:50] <pitti> slangasek: definitively cjwatson's domain now, I'm afraid
[10:51] <ogra_cmpc_> seb128, i mean it helps me to work around on the classmate and i can cover that from the installer, but i really dont understand the logic here
[10:51] <slangasek> unless Ubuntu d-i is different than Debian d-i, this is achievable by setting the Priority
[10:51] <seb128> ogra_cmpc_: describe your usecase with an easy example and steps to trigger the bug in a bug report and I'll speak with upstream about it
[10:51] <slangasek> pitti: well, I was first soliciting opinions on whether it would be sane to set a universe udeb to Priority: standard
[10:53] <ogra_cmpc_> seb128, it might be because the dir is move mounted in intramfs ... i'll add a bug and work around it on the classmate in the way that works for now
[10:55] <cjwatson> slangasek: hmm, no, Priority not a great idea because that could affect netboot images
[10:55] <slangasek> cjwatson: ok, thought that might be the case
[10:55] <slangasek> laga: that means we're back to trying to auto-select udebs for install using preseeding, I think; sorry
[10:56] <cjwatson> though that was the solution we used for Edubuntu
[10:56] <cjwatson> but it was problematic
[10:56] <cjwatson> if it does nothing by default, then using Priority is OK, just ugly
[10:56] <slangasek> right
[10:56] <cjwatson> is using preseeding a problem?
[10:57] <slangasek> I don't think so, it was just that setting priority was the first thing that had come to my mind
[10:57] <cjwatson> i.e. 'd-i anna/choose_modules string mythbuntu-diskless-client-builder'
[10:57] <laga> cjwatson: oh, i haven't tried that yet.
[10:57] <cjwatson> I'm pretty confident that will work
[10:58] <laga> i didn't know you had to tell d-i explicitly to install something.. i think i was told it would just work if i just preseeded debconf questions for the package itself
[10:58] <laga> thanks, i'll try that asap
[10:58] <cjwatson> ah, if so you were told wrongly I'm afraid
[10:58] <pitti> tkamppeter: looks fine, uploaded
[10:59] <laga> cjwatson: or i mistunderstood something, happens all the time :)
[10:59] <cjwatson> namespacing of debconf questions is just a convention; d-i can't and doesn't rely on it to figure out where the questions come from
[11:00] <cjwatson> for instance, most of the mirror/* questions are actually in the choose-mirror-bin udeb
[11:00] <pitti> mvo: *nag* do you happen to have a dist-upgrade /etc diff -Nur somewhere? time's getting tight for fixing everything, I feel
[11:01] <pitti> mjg59: hm, so what would you recommend that we do for bug 162654? revert the network module unloading in pm-utils, or add a /e/i/networking restart call?
[11:01] <ubotu> Launchpad bug 162654 in pm-utils "networkmanager (0.6.5-0ubuntu16.7.10.0) needs to be restarted manually after suspend using pm-utils, while functioning correctly using acpi" [Undecided,In progress] https://launchpad.net/bugs/162654
[11:04] <ogra_cmpc_> cjwatson, the optimal solution would have been to add the code from laga to ltsp-client-builder ... and just have switches ... something for intrepid ...
[11:05] <laga> ogra_cmpc_: it'd be very nice to merge some of my stuff back. i'm still not keen on maintaining my own initramfs scripts for example :)
[11:05] <ogra_cmpc_> yeah
[11:08] <james_w> pitti: I think I have the fix you want now, it's attached to the bug report.
[11:08] <james_w> https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/153625
[11:08] <ubotu> Launchpad bug 153625 in ca-certificates "update-ca-certificates error. ca-certificates.crt empty (with pt_BR locale)" [High,In progress]
[11:09] <james_w> pitti: do you want to look now, or shall I subscribe the sponsors and let you get to it in your own time.
[11:09] <pitti> Keybuk: WDYT about https://bugs.edge.launchpad.net/ubuntu/+source/rhythmbox/+bug/62400/comments/15 ?
[11:09] <ubotu> Launchpad bug 62400 in rhythmbox "Podcasts directory should be created when required" [Low,In progress]
[11:09] <pitti> james_w: great! looking
[11:12] <mok0> I suggest to remove gcalctool (a calculator claiming to be a calendar :-)) from hardy. It has a lot of serious unfixed bugs associated with it; yet a desktop calculator is an important item on the desktop! We can't ship hardy with a calculator that doesn't work
[11:12] <mok0> https://edge.launchpad.net/gcalctool/
[11:13] <pitti> james_w: that's thorough analysis and testing! *hug*
[11:13] <james_w> \o/
[11:13] <pitti> james_w: the patch looks good to me; maybe cjwatson can also have a look, just to get more eyes on it?
[11:13] <james_w> now to do it for several previous releases :-)
[11:13] <mjg59> pitti: I'll look into it later today
[11:14] <pitti> mjg59: thanks
[11:14] <james_w> more eyes would be good, I'd especially like the preseed thing confirming
[11:14] <pitti> james_w: that should just be changing the $fixed_version thing, right?
[11:14] <mjg59> pitti: Though, argh. Why are people suspending machines with static networking configuration?
[11:14] <mvo> pitti: I look at it again after lunch, sorry
[11:14] <pitti> james_w: (and the previous debconf template fix, of course)
[11:15]  * pitti hugs mvo, thanks
[11:15] <james_w> pitti: yep, but it's the testing part that takes the time
[11:15] <pitti> mjg59: :/
[11:15] <james_w> does anyone know a way to make pbuilder run a script for "login"?
[11:15] <pitti> mjg59: I do it myself, though, since my secondary ethernet is a static configuration (my desktop acts as a router for laptop, etc.)
[11:16] <pitti> james_w: maybe you don't want --login then, but --execute?
[11:17]  * james_w hugs pitti 
[11:17] <james_w> perfect, thanks.
[11:33] <Keybuk> pitti: mdz's follow-up seems reasonable
[11:34] <pitti> Keybuk: hmkay; I find that pretty unexpected when opening the prefs dialog TBH, but *shrug*
[11:34] <pitti> mdz: ^
[11:35] <Keybuk> which bit?
[11:35] <pitti> popping up a dialog about creating a directory
[11:35] <pitti> when opening the podcasts tab
[11:35] <Keybuk> well, I wouldn't do that
[11:36] <Keybuk> why can't it just have a default directory that it makes the first time it downloads a podcast?
[11:37] <tkamppeter> pitti, thanks.
[11:37] <pitti> Keybuk: GTK file/dir selector widget can't do nonexisting directories
[11:37] <pitti> (good thing IMHO)
[11:37] <Keybuk> but it has a non-existing one as the default, no?
[11:37] <pitti> that's what it breaks on, AFAIUI
[11:38] <pitti> (for me it just shows my home dir, need to try on a fresh profile)
[11:40] <james_w> mok0: https://bugs.edge.launchpad.net/ubuntu/+source/gcalctool/ doesn't look too bad, are there things that should be given higher severity?
[11:40] <james_w> or are there just a lot of unreported bugs?
[11:40] <Keybuk> pitti: hmm, it seems set to just HOME by default now?
[11:42] <pitti> Keybuk: right, here too (for a fresh user)
[11:42] <pitti> just tried it
[11:44] <ogra_cmpc_> lamont, do you happen to have any say about the debian build queue priority of hppa ?
[11:44] <seb128_> pitti: what bug are you working on?
[11:45] <pitti> seb128_: bug 62400
[11:45] <ubotu> Launchpad bug 62400 in rhythmbox "Podcasts directory should be created when required" [Low,In progress] https://launchpad.net/bugs/62400
[11:51] <cjwatson> james_w: quote $pt_BR_fixed_version (not required, but good habit); use [ test ] && [ test ] rather than [ test -a test ] (likewise); I think it would be a good idea to set seen=true at the top, rather than it being uninitialised in a few cases
[11:53] <cjwatson> james_w: also, I don't think the language test is quite right
[11:57] <james_w> cjwatson: what do you think the language test should be?
[11:57] <cjwatson> james_w: I'm just trying to work it out :)
[11:57] <mdz> pitti: agreed, it shouldn't do anything when you first open the dialog (that's the real bug)
[11:58] <james_w> LC_ALL=pt_BR.UTF-8 was the way I could trigger it, there may be non-UTF-8 ones affected I assume
[11:58] <cjwatson> james_w: testing LC_ALL is definitely wrong; LC_ALL might not be set, and yet you could still have LC_MESSAGES set
[11:58] <cjwatson> james_w: but to get it right you have to test LANGUAGE too, and as you mention there are non-UTF-8 locales affected too
[11:58] <james_w> cjwatson: just LC_MESSAGES doesn't trigger the bug in the first place in my testing
[11:58] <cjwatson> james_w: you might have something else set that overrides it
[11:58] <cjwatson> james_w: I'm trying to work out an entirely different test
[11:59] <cjwatson> ideally, we would check for the actual failure condition
[12:00] <james_w> LANGUAGE on it's own does trigger it though.
[12:01] <cjwatson> the override system there is rather complicated and best implemented by hand only where absolutely necessary
[12:04] <cjwatson> urgh, unfortunately we can't do better because there has been an intervening version that had correct pt_BR templates
[12:05] <james_w> that's my fault
[12:05] <cjwatson> if that hadn't been the case, we could have shipped some code in the .config (or .preinst? haven't thought about it) that did db_metaget ca-certificates/enable_crts Choices && [ -z "$RET" ]
[12:06] <james_w> we can do that for the SRU can we?
[12:06] <cjwatson> oh, no, that isn't true either, because dpkg-preconfigure loads the new templates before calling any maintainer scripts
[12:06] <cjwatson> drat
[12:06] <cjwatson> ok, I guess we have to implement the environment variables in toto
[12:08] <cjwatson> ideally, we would ask debconf for the language it thinks we're using, or have a shell binding for setlocale(), but I don't think either of those exist
[12:14] <cjwatson> james_w: http://paste.ubuntu.com/6356/ is the best I can do
[12:15] <cjwatson> james_w: it's still wrong in at least these situations: (1) you have LANGUAGE=ll:pt_BR but there's no translation of those templates in ll so debconf falls back to pt_BR (2) pt_BR<something> is set in the environment but that locale is not actually configured so is not used
[12:15] <cjwatson> but AFAICS there's nothing we can do about (1), while (2) is not very important in this case
[12:18] <james_w> cjwatson: is this normal? http://paste.ubuntu.com/6357/
[12:18] <james_w> if it is then my previous testing of this was incorrect.
[12:22] <cjwatson> james_w: yes, if you don't have the pt_BR.UTF-8 locale generated (run 'sudo locale-gen pt_BR.UTF-8')
[12:23] <cjwatson> james_w: or if you have LC_ALL=C
[12:23] <james_w> I have the locale
[12:23] <cjwatson> in fact you must have LC_ALL=C because if it's unset then you would see LC_ALL=
[12:25] <james_w> ah, ok, it's set by default to C, at least in my pbuilder environment
[12:26] <james_w> ah, I get your function now, it seems right to me.
[12:27] <mok0> james_w: It's the severity of the bugs I am concerned about. Last time I tested the app it didn't work correctly at all.
[12:27] <james_w> mok0: well there's nothing High or above in the above source package list.
[12:29] <mok0> james_w: why is that? I think it's severe if the calculator gives the wrong (or not-understandable) results
[12:29] <dholbach> thekorn, bdmurray: is a new upload of pylpbugs planned anytime soon?
[12:29] <james_w> cjwatson: as for the other comments I'll fix them, but seen is a variable I have re-used, so it is set further up.
[12:29] <james_w> I realise it's not in the diff
[12:30] <james_w> mok0: I'm not sure, maybe they just haven't been triaged?
[12:30] <emgent> dholbach: i should complete anteater (tool for ubuntu-whitehat team) with pylbugs support. you have some docs about it ?
[12:30] <james_w> mok0: although some where the summary suggests wrong results are set to Low.
[12:31] <mok0> james_w: I am not at my Ubuntu desktop atm so I can't test it now
[12:31] <dholbach> emgent: http://wiki.ubuntu.com/BugHelper has some and "pydoc launchpadbugs" should have some too
[12:31] <cjwatson> james_w: oh, ok
[12:31] <emgent> dholbach: ok thanks
[12:32] <mok0> james_w: a desktop calculator is likely to be pulled out by casual and first time users. It is crucial that it works correctly. Imagine a reviewer getting wrong results, I would reflect badly on Hardy
[12:32] <mok0> s/I would/it would/
[12:33] <mok0> james_w: hehe, with my new-earned powers I can change the Importance of the bug :-)
[12:34] <james_w> mok0: true. I was just reflecting that the bugs page didn't reflect the concerns that you were having, so it's hard to know what's going on.
[12:36] <mok0> james_w: I am afraid many bugs get a superficial treatment partly as a result of karma-hunting members of the 5-a-day team (sorry dholbach)
[12:37] <seb128_> mok0: do you have some examples?
[12:37] <mok0> err... gcalctool?
[12:37] <mok0> :)
[12:37] <dholbach> mok0: that's a general bug triage problem we had with Launchpad Bug Karma before - I agree with you that it'd be good to have some kind of solution for it
[12:38] <dholbach> maybe we should disucss it on ubuntu-bugsquad@
[12:38] <seb128_> mok0: there is no abuse there, do you have a bug number where you had an issue?
[12:38] <mok0> bug 208260
[12:38] <ubotu> Launchpad bug 208260 in gcalctool "Too many commas in gcalctool" [Low,Triaged] https://launchpad.net/bugs/208260
[12:38] <james_w> mok0: these don't appeared to have been triaged by 5-a-day people, and don't seem at all superficial.
[12:38] <seb128_> mok0: I'm reading most of the desktop bugs and didn't notice wrong comments or triaging
[12:38] <mok0> bug 198250
[12:38] <ubotu> Launchpad bug 198250 in gcalctool "Calculator uses 06 in place of decimal" [Undecided,Fix released] https://launchpad.net/bugs/198250
[12:38] <seb128_> that one has been sent upstream, fixed and the fix has been confirmed
[12:39] <seb128_> what is wrong with the handling it got?
[12:39] <mjg59> Yeah, 208260 really shouldn't be low
[12:39] <mok0> seb128_: I don't see a fix has been issued?
[12:40] <seb128_> mok0: 198250? It's closed
[12:40] <mok0> seb128_: right, I see it now
[12:40] <seb128_> mjg59: well, it's not high neither seems it seems to be specific to a locale
[12:41] <seb128_> and that's not a major application
[12:41] <mjg59> seb128_: Well, it seems to be failing in en_GB
[12:42] <mjg59> seb128_: It may not be a major application, but it /does/ make the application basically unusable under common locales
[12:42] <mok0> All this makes me feel gcalctool is a shoddy app
[12:42] <seb128_> mok0: "all this" = 1 bug?
[12:43] <seb128_> mjg59: agreed it should be fixed, but what it lacks now is not settings tweaking but somebody looking at the bug and writting a patch for the issue
[12:43] <mok0> seb128_: I am looking at the number of serious bugs on gcalctools bug page
[12:43] <asac> smurf: there?
[12:44] <mjg59> seb128_: The point of priorities is surely to inform people as to which bugs need patches writing more urgently?
[12:44] <seb128_> mok0: there is only 16 bugs on launchpad
[12:44] <Keybuk> cjwatson: around?
[12:44] <asac> smurf: could you approve me to the german translators team so i can approve firefox/xulrunner suggestions?
[12:44] <cjwatson> Keybuk: yep
[12:44] <mok0> seb128_: "calculator not working", "... problems with big sums", "too many commas" ... etc
[12:44] <asac> smurf: i applied already. thanks
[12:45] <seb128_> mjg59: right, but we have lot of other issues at the moment and as said that's only the calculator
[12:45] <mok0> mjg59: But are the priorities always correctly set?
[12:45] <mjg59> seb128_: I was under the impression that priorities related to the package, not to the distribution?
[12:46] <seb128_> it's not clear to me
[12:46] <mok0> mjg59: I interpret it as relating to the bug
[12:46] <laga> smurf: while you're at it? can you please approve me to the german translators team as well? i'd like to translate some of my apps ;)
[12:46] <mjg59> As in, this is a high priority bug for gcalctool (even if not a high priority bug for the distribution)
[12:46] <seb128_> mjg59: I do concern the priority as being for ubuntu
[12:46] <seb128_> s/concern/consider
[12:46] <mok0> mjg59: a wrong result is clearly a more severe bug than no color or buttons
[12:46] <mok0> s/or/on
[12:46] <seb128_> mjg59: well, that's the ubuntu bug tracker not the upstream one
[12:47]  * mvo wonders if adding a upstream task with high prioriy is the best solution for this and a distro task with e.g. medium
[12:47] <mjg59> seb128_: But that renders the priority field effectively meaningless when relating to packages in universe
[12:47] <seb128_> mjg59: I consider the importance of the issue for ubuntu as a whole, not for the specific package
[12:47] <afflux> calc: may I ask why you closed bug 122976 some time ago? bug 198083 seems to be the same issue.
[12:47] <ubotu> Launchpad bug 122976 in openoffice.org "package openoffice.org-style-human 2.2.1-2ubuntu1 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,Invalid] https://launchpad.net/bugs/122976
[12:47] <ubotu> Launchpad bug 198083 in ubuntu "Error on Update" [Medium,Incomplete] https://launchpad.net/bugs/198083
[12:47] <seb128_> mjg59: I don't say I'm right there but that's how I use launchpad right now
[12:47] <Keybuk> cjwatson: err, let's take this to a less busy channel? #udev ?
[12:47] <Keybuk> mvo: could you pop in too
[12:48] <seb128_> mjg59: otherwise we would have hundred of critical bugs and it would be hard to know what to fix in priority for hardy
[12:48] <cjwatson> Keybuk: sure
[12:48] <seb128_> mjg59: I consider gnome-settings-daemon crashing a higher priority that gcalcool being buggy for ubuntu
[12:48] <mok0> seb128_: that's true
[12:49] <mok0> seb128_: but still, the desktop calculator often gives the first impression for a casual users
[12:50] <seb128_> mok0: well, as said if gnome-settings-daemon crash you will have a first impression before opening any calculator
[12:52] <mok0> seb128_: I agree. Perhaps there should be an effect category too for bugs: "effects other programs", "effects usability", "effects user experience" etc.
[12:53] <seb128_> mok0: the way we work for desktop bugs right now is to milestone things that should be considered for hardy
[12:53] <mok0> seb128_: ... and the bug triager could click on one or several of those
[12:53] <seb128_> so this one would be a low importance milestoned for hardy
[12:53] <seb128_> ie, the world is not going to break if it's not fixed but it should be considered
[12:53] <mok0> seb128_: ok, I understand
[12:54] <seb128_> especially that I don't get this issue
[12:54] <seb128_> so it's locale specific or something
[12:54] <mok0> seb128_: yes that's very likely
[12:54] <seb128_> and the bug has not been opened using apport so it lacks informations
[12:54] <seb128_> ie, the locale used
[12:56] <mjg59> seb128_: As I said, it's visible under en_GB
[12:56] <seb128_> mjg59, mok0: did you guys activate the "show thousand separator" option?
[12:56] <mjg59> seb128_: Does French even use a separator?
[12:57] <mjg59> seb128_: I don't recall doing so deliberately, but yes, it is activated
[12:57] <mok0> seb128_: I am not on my desktop atm, so I can't test the most recent version, but yes, I did try that some days ago
[12:57] <seb128_> ok
[12:57] <mok0> My locale is "C" :-)
[12:57] <seb128_> so it's an issue for people activating this option under locales have a thousand separator apparently
[12:57] <mjg59> seb128_: Unsurprisingly, without it there isn't an issue
[12:59] <james_w> pitti, cjwatson: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/153625 updated. Thanks for the comments.
[12:59] <ubotu> Launchpad bug 153625 in ca-certificates "update-ca-certificates error. ca-certificates.crt empty (with pt_BR locale)" [High,In progress]
[13:02] <lamont> ogra_cmpc_: I happen to have 2 buildds that I need to finish getting online...
[13:02] <lamont> (re hppa/debian
[13:02] <lamont> but I'm not planning to shuffle any build priorities
[13:02] <ogra_cmpc_> lamont, ah, i rather meant in the debian infrastructure
[13:03] <lamont> I run the debian buildds for hppa.  I have the ability to drag something into "next up" status
[13:03] <ogra_cmpc_> ah
[13:03] <ogra_cmpc_> thats what i wanted to know, but you gave a statement about shuffluing already :) thanks
[13:04] <lamont> yeah - we had one die, and the priority for builds is to get -security done first once I get the two new ones online
[13:05] <lamont> so what does it mean and how do I fix it when plugging in a USB drive gets me:  Cannot mount volume.  Error org.freedesktop.DBus.Error.AccessDenied ??
[13:06] <ogra_cmpc_> you are not in the plugdev group ? or consolekit doesnt like you at all
[13:07] <ogra_cmpc_> lamont, how did you start your x session ? DM or startx
[13:07] <lamont> DM, I assume
[13:07] <lamont> it's on vt7 or 9 or whereever hardy likes it
[13:08] <ogra_cmpc_> what does ck-list-sessions show ?
[13:11] <lamont> ck-list-sessions
[13:11] <lamont> ** (ck-list-sessions:32282): WARNING **: Failed to get list of seats: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success
[13:11] <lamont> I _LOVE_ that error
[13:12] <pitti> james_w, cjwatson: language test> locale |grep LC_MESSAGES is the most robust test I can think of
[13:15] <Riddell> pitti: could you give back qtnx?
[13:15] <lamont> -rwsr-xr-- 1 root messagebus 228628 2008-02-29 02:23 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
[13:15] <pitti> Riddell: done
[13:15] <lamont> ogra_cmpc_: I wonder if it being mode 4754 has anything to do with it...
[13:15] <Riddell> thanks
[13:16] <ogra_cmpc_> lamont, no, that looks about right
[13:17] <lamont> OTOH, making it 4755 doesn't fix anything - it just makes ck-list-sessions successfully print nothing
[13:17] <cjwatson> pitti: I looked at that but didn't feel like sedding it out
[13:17] <cjwatson> but I guess that would work too; however, you still need the LANGUAGE check
[13:17] <cjwatson> $ LANGUAGE=de locale | grep LC_MESSAGES
[13:17] <cjwatson> LC_MESSAGES="en_GB.UTF-8"
[13:18] <pitti> cjwatson: LANGUAGE is not related to gettext, it's a GNOMEism AFAICS
[13:18] <pitti> so, LANG should work
[13:19] <lamont> ogra_cmpc_: it's quite possible that I have gid/uid matching issues, although I expect not (nsswitch.conf used to point at ldap)
[13:19] <ogra_cmpc_> lamont, hmm consolekit maintans all ACLs for the desktop nowadays
[13:20] <ogra_cmpc_> if ck-list-sessions doesnt list anything thats your basic prob
[13:21] <lamont> ogra_cmpc_: ah, ok.  so how do I fix0r that?
[13:21] <ogra_cmpc_> http://paste.ubuntu.com/6359/
[13:21] <ogra_cmpc_> you should see something like that
[13:22] <ogra_cmpc_> lamont, gdm should have set the session for you in CK, is your gdm outdated ?
[13:22] <\sh> lamont: hey...did you get the mail from loic because of adding lpia arch to p-a-s for wine? :) what do you think?
[13:22] <lamont> gdm 2.20.4-0ubuntu2
[13:23] <cjwatson> pitti: LANGUAGE is *not* a GNOMEIsm
[13:23] <cjwatson> ism
[13:23] <cjwatson> pitti: you'll find documentation on LANGUAGE in 'info gettext'; furthermore, even if it weren't in gettext, debconf cares about it
[13:23] <lamont> cjwatson: man locale doesn't know about it
[13:24] <ogra_cmpc_> lamont, hmm, mine here is even older ...
[13:24] <cjwatson> lamont: *shrug*
[13:24] <cjwatson> lamont: fact is, it's in gettext
[13:24] <lamont> ogra_cmpc_: recent changes to the system: 1) upgrade-manager love to hardy-beta, 2) drop ldap from nsswitch.conf
[13:24] <lamont> cjwatson: yeah.
[13:24] <ogra_cmpc_> dpkg -l policykit|grep ii
[13:24] <cjwatson> lamont: also in locale(7)
[13:25] <cjwatson> "The GNU gettext family of functions also obey the environment variable LANGUAGE."
[13:25] <lamont> ogra_cmpc_: 0.7-2ubuntu4
[13:25] <ogra_cmpc_> hmm
[13:25] <ogra_cmpc_> looks all fine
[13:25] <ogra_cmpc_> weird
[13:26] <afflux> does the live CD warn the user that he has not enough RAM (ie. 256mb)?
[13:27] <cjwatson> no
[13:27] <cjwatson> bug open
[13:27] <afflux> cjwatson: was that targeted to me?
[13:27] <cjwatson> sorry, I mean there already is a bug open somewhere about it
[13:27] <cjwatson> afflux: yes
[13:28] <afflux> ah, right. against ubiquity I guess? bug 162664 looks like it's a dup then.
[13:28] <ubotu> Launchpad bug 162664 in vlc "no video output module play nice with Compiz" [Undecided,New] https://launchpad.net/bugs/162664
[13:28] <afflux> err
[13:28] <afflux> no
[13:28] <cjwatson> afflux: ubiquity would be wrong; casper or gfxboot-theme-ubuntu
[13:28] <afflux> okay
[13:28] <afflux> I meant bug 208365
[13:28] <ubotu> Launchpad bug 208365 in gnome-settings-daemon "There was an error starting the GNOME Settings Daemon (timeout?)" [Undecided,Confirmed] https://launchpad.net/bugs/208365
[13:28] <lamont> ogra_cmpc_: so where do I go from here?
[13:28] <ogra_cmpc_> lamont, there is a gui in System->Administration->Authorizations ... in the freedesktop/hal/strorage branch of that tree you can check the permissions
[13:29] <cjwatson> afflux: having a warning at the boot menu level would not excuse applications from the responsibility of dealing correctly with out-of-memory errors
[13:29] <ogra_cmpc_> usually mount and umount should be allowed for local users
[13:29] <cjwatson> afflux: those could happen in situations other than the live CD
[13:29] <ogra_cmpc_> oh, wait, your prob will lie deeper
[13:30] <lamont> implicit auth: anyone = no.  explicit auth == $EMPTY
[13:30] <ogra_cmpc_> pitti, any idea why lamont doesnt get a CK session ?
[13:30] <ogra_cmpc_> (on a freshly upgraded system it seems)
[13:33] <cjwatson> would anyone like to code-review http://paste.ubuntu.com/6360/ for me? This is an initial attempt at bug 8497, and will only work if you supply edd=on at boot
[13:33] <pitti> re from phone call
[13:33] <ogra_cmpc_> i dont see why it wouldnt register a session, all bits and pieces seem to be where they belong
[13:33] <ubotu> Launchpad bug 8497 in grub "grub guessed BIOS disk order incorrectly" [Medium,Confirmed] https://launchpad.net/bugs/8497
[13:33] <cjwatson> I haven't even compiled this yet, let alone tested it; just want to get some early eyes
[13:34] <pitti> cjwatson: thanks for the review
[13:34] <pitti> ogra_cmpc_: no?
[13:35] <cjwatson> edd> the idea is that this won't affect normal installs at all (risky!), but if people have trouble getting grub to see their disks in the right order, they can try booting with edd=on and we'll opportunistically use the information
[13:35] <cjwatson> in the knowledge that BIOSes can return partial or broken information, or that two identical disks out of the factory may well have identical MBR signatures, though, I had to program very defensively
[13:36] <james_w> afflux: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/204821 looks familiar
[13:36] <ubotu> Launchpad bug 204821 in gnome-settings-daemon "[hardy beta 1] GNOME Settings Deamon gives error when starting live CD" [Undecided,Incomplete]
[13:37] <seb128_> james_w: that's likely a "too slow to boot and goes in dbus timeout"
[13:38] <james_w> ah, ok
[13:39] <afflux> seb128_: see also bug 208365, that's a low ram system (128mb)
[13:39] <ubotu> Launchpad bug 208365 in gnome-settings-daemon "error starting g-s-d on systems with low memory" [Medium,Triaged] https://launchpad.net/bugs/208365
[13:39] <seb128_> afflux: this bug is no a g-s-d one, dunno who changed it to triaged
[13:40] <afflux> seb128_: I did so
[13:40] <lamont> dear gnome.  please use a firefox window in the current workspace, rather than dragging that other window across 3 workspaces just to use it. kthx
[13:40] <seb128_> afflux: why?
[13:41]  * lamont chuckles at the bug list for consolekit... I bet at least _some_ of those are dupes
[13:41] <seb128_> afflux: we already have this dbus change
[13:41] <seb128_>     - debian/patches/81-session.conf-timeout.patch: Raise the service startup
[13:41] <seb128_>       timeout from 25 to 60 seconds. It may be too short on the live CD with
[13:41] <seb128_>       slow machines.
[13:41] <afflux> seb128_: so? I'm sorry, I'm not very much in g-s-d startup stuff
[13:42] <afflux> seb128_: sorry for setting this to triaged, it was more like "looks complete to me, let the dev's look at it"
[13:43]  * lamont considers reinstalling apport
[13:43] <seb128_> afflux: that is "confirmed"
[13:43] <seb128_> well not really
[13:43] <seb128_> in this case it's rather incomplete or invalid
[13:44] <afflux> seb128_: I don't get your point
[13:44] <pitti> Keybuk: with my latest comment on bug 62400, would you agree to removing the milestone and setting to wishlist?
[13:44] <ubotu> Launchpad bug 62400 in rhythmbox "Podcasts directory should be created when required" [Low,In progress] https://launchpad.net/bugs/62400
[13:45] <seb128_> afflux: this bug is of no use, it has no useful informations, no description about how to trigger it, etc
[13:45] <ogra_cmpc_> afflux, also note that running g-s-d as root might be a very bad idea
[13:45] <ogra_cmpc_> (your .xsession-errors show it was run via sudo)
[13:46] <afflux> ogra_cmpc_: hm, right. Seems like he did that on his own.
[13:46] <afflux> seb128_: okay, then please close it or request information, as you like.
[13:47] <seb128_> afflux: will do
[13:47] <afflux> thanks!
[13:47] <seb128_> thank *you* for your work on it
[13:47] <seb128_> those bugs are not easy
[13:48] <Keybuk> pitti: it's "good enough" for now I think
[13:48] <pitti> Keybuk: right
[13:48] <lamont> bug 210792
[13:48] <ubotu> Launchpad bug 210792 in consolekit "no sessions after logging in" [Undecided,New] https://launchpad.net/bugs/210792
[13:49] <lamont> ogra_cmpc_: I grew tired. :-)
[13:49] <ogra_cmpc_> lamont, yeah, no idea what causes this
[13:50] <ion_> Argh. :-) Away nicks for the lose.
[13:51] <\sh> ion_: more likely a dying desktop where totem told me: no I don't like: strace totem example.flv ,->
[13:52] <\sh> and that means..disconnecting from my proxy
[13:52] <ogra_cmpc_> just stop using dd to create .flv movies :P
[13:54] <cjwatson> \sh: it's your proxy, so you can tell it to stop doing /nick \sh_away
[13:54] <lamont> \sh: please
[13:54] <\sh> cjwatson: yes...I'll do it this evening :(
[13:55]  * ogra_cmpc_ curses that kernel panics on a classmate always have to end up in his garage ...
[13:55] <pitti> cjwatson, james_w: can't the is_pt_BR() function be replaced with something like CUR_LOC=$(eval `locale`; echo $LC_MESSAGES) ?
[13:55]  * ogra_cmpc_ goes to dig for the screwdriver
[13:56] <cjwatson> pitti: no. see my comment about LANGUAGE.
[13:56] <cjwatson> pitti: that does NOT match debconf's behaviour
[13:56] <pitti> ah, I see
[13:56] <cjwatson> but you could certainly reduce the LC_ALL/LC_MESSAGES/LANG part of it with something like your example
[13:56] <pitti> but it would at least avoid reimplementing the LC_ALL -> LANG -> LC_MESSAGES priority
[13:57] <pitti> yeah
[13:58] <james_w> so, we could use pitti's suggestion to get those three, and the if $LC_MESSAGES or $LANGUAGE start with pt_BR then assume the user would have been affected?
[13:58] <james_w> s/LC_MESSAGES/CUR_LOC
[13:59] <pitti> james_w: oh, btw, your $LANGUAGE test is wrong, too
[13:59] <pitti> since it does not match if you have LANGUAGE=de_DE:pt_BR:en_US or so
[13:59] <pitti> and don't actually have de_DE configured
[13:59] <james_w> pitti: yeah, but I don't think that's detectable is it?
[13:59] <cjwatson> pitti: yes, but there's no real way to do better. I noted that in my comments above
[14:00] <pitti> if debconf really implements locale choosing different from /usr/bin/locale, then we need to reimplement debconf's algorithm
[14:00] <cjwatson> pitti: which is what I did
[14:00] <cjwatson> and gave to james_w
[14:00] <pitti> cjwatson: I agree, it's a pathological case, but if we look at $LANGUAGE at all, it should at least be correct?
[14:00] <cjwatson> and is what you're now busy arguing with ;-)
[14:00] <pitti> ok, thanks
[14:01] <james_w> so, another alternative would be to ask debconf, for instance by doing something hacky like adding a new template and then using two known strings, one for pt_BR and one for the rest.
[14:01] <cjwatson> I did the best that I believed was possible
[14:01] <pitti> james_w: "ugh" :)
[14:01] <james_w> pitti: yeah, I'd need a shower after doing it :-)
[14:01] <cjwatson> james_w: better to add debconf/language to debconf itself, but I doubt you want to depend on a new debconf feature for an SRU
[14:02] <james_w> nope, but we can simulate it with a template.
[14:02] <cjwatson> vomit. but yes, theoretically. :)
[14:02] <lamont> so when we introduce a change to a package whose debian maintainer is an ubuntu maintainer, we change the maintainer field so that he doesn't get any notifications of the change.  nice.
[14:03] <cjwatson> lamont: notifications can be had on request through the PTS
[14:03] <lamont> yeah
[14:03] <cjwatson> derivatives keyword, IIRC
[14:03] <lamont> debian's pts?
[14:03] <cjwatson> yes
[14:03] <cjwatson> and the maintainer field change you mention was by voted request from Debian
[14:04] <lamont> oh, I understand... I just found certain humor(?) in finding that postfix had been uploaded
[14:05] <mvo> pitti: here is a first diff for the server upgrade http://people.ubuntu.com/~mvo/automatic-upgrade-testing/kvm/profile/server/
[14:06] <pitti> mvo: ooh
[14:06] <mvo> more to come, takes a bit to generate this stuff
[14:07] <pitti> mvo: pkgs.diff looks reasonable, yay
[14:07] <mvo> yeah, need to filter out the deinstall lines
[14:07] <pitti> oh, it still has the gutsy apt sources?
[14:08] <mvo> pitti: it shouldn't, you most likely see the backup of sources.list
[14:08] <pitti> etc/apt/sources.list.distUpgrade
[14:08] <pitti> ah, that's the backup
[14:09] <mvo> odd that the UUID in the fstab changed
[14:09] <pitti> etc/cron.daily/find should probably disappear on upgrade
[14:09] <mvo> I think that is relatead to a incorrect compare-version (see #210699)
[14:09] <pitti> mvo: well, you probably reformatted the disk on fresh install?
[14:10] <mvo> a second opinion on #210699 would be nice
[14:10] <mvo> pitti: of course, stupid me :)
[14:10] <pitti> hm, no ipv6 stuff in /etc/hosts for fresh install?
[14:12] <pitti> mvo: is /etc/init.d/makedev an orphan? I don't see a corresponding 'deinstall' package in pgk.diff
[14:14] <pitti> Keybuk: is the /etc/udev/rules.d/70-persistent-net.rules diff (at the very bottom) in http://people.ubuntu.com/~mvo/automatic-upgrade-testing/kvm/profile/server/etc.diff something to be concerned about?
[14:14] <pitti> mvo: except for that ^, #210699, and the orphaned makedev stuff it actually looks surprisingly good )
[14:14] <mvo> no idea about the ipv6, both base-images are generated with jeos-builder
[14:15] <pitti> mvo: I wonder how it looks like with dapper; I just recently fixed some bad upgrade bugs, there might be more lurking
[14:15] <mvo> yeah, lets see what ubuntu-desktop looks like, let me check the makedev stuff
[14:15]  * pitti reads your bug (210699)
[14:16] <jdstrand> mvo: this is a bit of a drive-by commnet-- but doesn't jeos-builder create a really stripped down version? wouldn't ubuntu-vm-builder be better? (though I don't know why jeos-builder would strip out ipv6)
[14:16] <lamont> W: postfix source: build-depends-on-1-revision build-depends: libdb-dev (>= 4.6.19-1)
[14:16] <lamont> Dear lintian.  Yes, that's absolutely correct.  kthx.
[14:16] <lamont> since build-depending on multiple versions leads to build failures on crackful buildds with polluted chroots.
[14:17] <mvo> jdstrand: I don't know about ubuntu-vm-builder, I can have a look. please note that the generate image is only used to be able to login and do more stuff (like installing ubuntu-desktop etc)
[14:17] <mvo> jdstrand: its not perfect, the best solution for this would be to have a non-interactive d-i install
[14:17] <mvo> but my scripts can't do that (yet?)
[14:18] <jdstrand> mvo: ubuntu-vm-builder may get you really close to that
[14:18] <jdstrand> mvo: you may want to talk to mathiaz-- I think he has it completely automated for server installs
[14:19] <mvo> jdstrand: oh, sounds nice
[14:19] <jdstrand> mvo: I use ubuntu-vm-builder/kvm/virt-clone for security updates and can get i386 and amd64 vms with multple vcpus-- works great
[14:20] <jdstrand> mvo: but I don't use mathiaz' scripts, so it's not *totally* automated for me (yet)
[14:20] <jdstrand> (but it's darn close)
[14:21] <lamont> why did rmadison switch to defaulting to ubuntu?
[14:21] <StevenK> Because
[14:22] <soren> lamont: YEah, what StevenK said.
[14:22] <lamont> well then fix the manpage
[14:22] <StevenK> Because Colin and Matt asked me
[14:22] <lamont>             debian or qa http://qa.debian.org/madison.php (the default)
[14:22] <mvo> jdstrand: the script looks almost identical to what I use, was it just renamed at some point?
[14:22] <lamont> Lying!
[14:22] <soren> Because we fixed the "rmadison defaults to Debian even on UBuntu" bug. :)
[14:22]  * StevenK deals ramdison.1.gz a penalty card
[14:23] <jdstrand> mvo: I am not sure of it's history-- I believe ubuntu-vm-builder grew out of jeos-builder.  talk to soren and/or nijaba
[14:23]  * lamont adds an rmadison alias right above umadison in his .bashrc
[14:23]  * Hobbsee did that months ago :)
[14:23] <soren> mvo, jdstrand: jeos-builder was renamed to ubuntu-vm-builder just before feature freeze.
[14:23] <jdstrand> oh ha, well, don't I feel silly
[14:23] <Hobbsee> only confusion is which one is which, when i'm sometimes on gutsy, sometimes on hardy.
[14:23]  * soren hugs jdstrand 
[14:23]  * jdstrand has only ever used ubuntu-vm-builder
[14:24]  * lamont files a bug against devscripts so people don't forget to fix0r the manpage to match reality.
[14:24] <jdstrand> mvo: still, my comment about mathiaz' work stands, even if I don't know what I'm talking about with jeos-builder ;)
[14:24] <mvo> :)
[14:25] <mvo> thanks for the info, I'm too busy before the release, but its definitely something worth exploring
[14:25] <lamont> there.  bug 152424 reopened. :-)
[14:25] <ubotu> Launchpad bug 152424 in devscripts "rmadision should default to 'ubuntu' URL when under Ubuntu." [Wishlist,Confirmed] https://launchpad.net/bugs/152424
[14:26] <lamont> interesting... it accepts short hand for the URL as well
[14:28]  * lamont wonders if he should complain about dput being totally ugly in screen
[14:29] <lamont> I mean, there is a certain amount of humor in lines starting at column -5 or so.
[14:29] <lamont> as in 5 chars before end-of-line on the previous line
[14:33] <mvo> pitti: makedev looks like it does not clean up the old /etc/init.d/makedev conffile
[14:33] <pitti> ah, and update-rc.d -f
[14:35] <pitti> is it only me, or do other people have a broken gnome-screensaver after suspend, too? (it doesn't accept my password, I have to "change user" and log in there)
[14:38] <pitti> mvo: wow; for the first time ever, logging into my laptop (compiz) restored my terminals properly \o/
[14:38] <wasabi> I've had similar things, but they were related to winbind dying on suspend (or randomlly as the day goes by)
[14:39] <seb128> pitti: must be a bug
[14:39] <seb128> ;-)
[14:39] <pitti> seb128: the compiz session one? yeah, definitively
[14:39] <pitti> don't you EVER touch that again!!!111!!! :)
[14:40] <pitti> s/you//
[14:59] <james_w> pitti, cjwatson: I've uploaded pitti's suggestion as well to the bug. If I can have an ack on one of the approaches then I will move forward with the SRU work. If you're busy please say so and I'll move on to something else.
[15:00] <pitti> james_w: I have a phone call now, can do afterwards
[15:00] <james_w> thanks
[15:01] <pitti> james_w: thanks to you! (ugh, that turned out to be much harder than it seemed on first look)
[15:01] <cjwatson> lamont: sounds like you misunderstood that lintian warning, from your description; did you read the lintian-info output for it?
[15:01] <pitti> seb128, mvo: compiz session: ah, nevermind; I rebooted, it's broken again
[15:02] <pitti> seems that a session start with hot cache gets it right, a cold start doesn't
[15:03] <lamont> cjwatson: ah, ok.
[15:03] <lamont> maybe I should fix that
[15:03] <lamont> otoh, there would be great humor in a backport of libdb 4.6 :-)
[15:03] <cjwatson> james_w: I'm OK with pitti's, though I'd suggest echo $LC_MESSAGES -> echo "$LC_MESSAGES" for style (doesn't actually make a difference in this case)
[15:05] <jdong> lamont: you're a day late for backport humor ;-)
[15:05] <lamont> jdong: that's in ref to W: postfix source: build-depends-on-1-revision build-depends: libdb-dev (>= 4.6.19-1)
[15:05] <lamont> and the fact that lintian wants ">> 4.6.19" instead
[15:06] <jdong> lamont: grumble am I too  loose or is that really pedantic of lintian?
[15:07] <lamont> jdong: "breaks backports" :-)
[15:07] <james_w> cjwatson: done, thanks.
[15:08] <dneary> sabdfl: Ping?
[15:18] <mvo> pitti: could you please have a quick look at http://paste.ubuntu.com/6361/
[15:19] <pitti> mvo: ah, looks fine to me; thanks!
[15:19] <mvo> great, uploading
[15:19] <pitti> mvo: if that cleans it up properly, fine
[15:19] <mvo> does so in my local tests at least :)
[15:20] <mvo> I will run the upgrade test when it enter the archive again to verify the fix
[15:32] <dneary> No sign of Jono today?
[15:36] <jpatrick> dneary: he's in -locoteams right now
[15:37] <jpatrick> dneary: ok, ~10 minutes ago, last message
[15:42] <dneary> jpatrick: Thanks
[15:42] <jpatrick> dneary: pinged him.
[15:44] <dneary> Thanks
[15:48] <lamont> jdstrand: what's this mean:
[15:48] <lamont> Apr  2 08:01:45 mix kernel: [37412.728264] audit(1207144905.043:16): operation="file_mmap" request_mask="mr::" denied_mask="m::" name="/var/lib/misc/group.db" pid=7152 profile="/usr/sbin/cupsd" namespace="default"
[15:50] <jdstrand> lamont: 'm' is for 'memory map as executable'.  this is usually only needed for binaries
[15:50] <jdstrand> lamont: is this on i386 per chance?
[15:50] <lamont> yep
[15:51] <jdstrand> lamont: slapd had a similar problem on i386
[15:51]  * jdstrand goes to find the bug
[15:51] <pitti> james_w: latest patch looks good to me
[15:51] <pitti> james_w: shall I sponsor it?
[15:51] <lamont> cupsys 1.3.6-3ubuntu1
[15:51] <jdong> jdstrand: why do many apps want m on files that seem like they should only be reading?
[15:51] <jdstrand> lamont: bug #202161
[15:51] <ubotu> Launchpad bug 202161 in apparmor "apparmor broken after reboot on i386" [Undecided,New] https://launchpad.net/bugs/202161
[15:51] <james_w> pitti: that's your call :-)
[15:52] <jdstrand> jdong: ^^
[15:52] <pitti> james_w: ok, doing
[15:52] <james_w> pitti: I didn't give it the thorough testing that the other one got, but I have tested a couple of the scenarios
[15:52] <jdstrand> lamont: would you mind adding your log entry to that bug?
[15:52] <james_w> pitti: thanks.
[15:54] <pitti> james_w: uploaded; thanks a lot!
[15:54] <lamont> jdstrand: added
[15:54] <jdstrand> jdong: it *might* be an arch thing, but keescook is talking to upstream about it
[15:54] <jdstrand> lamont: thanks
[15:55] <jdong> jdstrand: interesting. I've just been noticing like, for example, it seems like Skype wants m on next to everything
[15:55] <james_w> pitti: thanks for the help.
[15:55] <jdong> jdstrand: does m carry any security implications that r does not?
[15:56]  * lamont notes that bind9 and postfix will want syncs after today's dinstall run
[15:56] <jdstrand> jdong: m is equivalent to 'ix'-- execute under the current profile
[15:57] <jdstrand> jdong: when you specify 'm', you are really saying "yes, you can execute this file"
[15:57] <jdstrand> jdong: so yes, there is a difference
[15:59] <jdstrand> jdong: but remember that apparmor is supplemental to unix perms, so if the file isn't executable there, it won't be executable just cause 'm' was used in apparmor
[15:59] <lamont> jdstrand: so WTH is it asking for exec perms?
[16:00] <jdstrand> lamont: yes, that is the question
[16:00] <jdstrand> lamont: keescook is talking to upstream about it
[16:00] <jdstrand> so far it seems to be i386 only
[16:06] <tkamppeter> pitti, hi
[16:07] <tkamppeter> pitti, hi
[16:07] <bryce> BenC: could you let amd know that colin and I are trying to connect to the conf call but it's not responding to the access code
[16:38] <keescook> jdstrand, lamont, jdong: I'm lacking a bit of context, but the AppArmor "m" is for "mmap".
[16:38] <keescook> for .so files this means it can load and run it.
[16:38] <keescook> presently our executables aren't PIE so this won't work for running them.  :P
[16:38] <lamont> keescook: and for /var/lib/misc/group.db, it would be executing it why?
[16:39] <jdong> keescook: what lamont and I are seeing are apps seemingly requesting mmap on textual/data/config type files
[16:39] <mvo> pitti: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/kvm/profile/ubuntu/
[16:39] <jdong> we're wondering why that happens
[16:39] <pitti> hi tkamppeter
[16:39] <pitti> hey keescook, good morning
[16:39] <pitti> mvo: ooh
[16:39] <pitti> argh, phone
[16:39] <mvo> pitti: running lts-ubuntu next
[16:40] <jdstrand> keescook: it is that slapd/i386 bug
[16:40] <jdstrand> keescook: except lamont found it with cupsys/i386
[16:41] <jdstrand> keescook: and updated the bug report
[16:44] <lamont> keescook: oh, and good morning. :-)
[16:46] <jdstrand> hi keescook!
[16:48] <pitti> mvo: ugh, 1.5 MB /etc diff?
[16:50] <keescook> morning!  :)
[16:50] <keescook> pitti: yeah, saw the notes, the cupsys tests sound great :)
[16:51] <keescook> jdong, lamont, jdstrand: it's not that it's trying to exec it -- it's just trying to mmap the file (generally to read it faster, etc)
[16:51] <keescook> that said, it still may be a AA bug
[16:51] <jdstrand> keescook: yes, but having 'm' means that it can exec it
[16:52] <Keybuk> BenC: ping?
[16:52] <keescook> that's true, but why is that a big problem?
[16:52] <mvo> pitti: fun!
[16:52] <jdstrand> it isn't a problem on it's own, but it is odd that it only happens on i386
[16:53] <jdstrand> keescook: ^ and we may see these types of bug reports and failures on i386 when the profile is 'correct'
[16:54] <keescook> jdstrand: yeah, I will re-ping upstream about it.  having a stand-alone test case would be nice, but I realize that's the _problem_.  :P
[16:55] <lamont> and if it doesn't want to actually exec the file, it should be mounting it without exec, no?
[16:55] <BenC> Keybuk: ?
[16:55] <Keybuk> BenC: I did not realise you were going to do a udev upload
[16:55] <Keybuk> so I think we just had a mid-air collision
[16:56] <BenC> Keybuk: woops...how unlikely, hehe
[16:56] <Keybuk> and without checking the debdiff, given you didn't get the version number right, I'm a little concerned you didn't get the rules file migration right
[16:56] <Keybuk> what did you change to move that rules file?
[16:56] <BenC> Keybuk: version number?
[16:57] <BenC> I went from -4ubuntu1 to -4ubuntu2
[16:57] <Keybuk> BenC: our udev packages aren't XubuntuY, we maintain them ourselves natively so they-re just -X
[16:57] <Keybuk> yes, mvo mucked up the last one; yours should have been -5
[16:57] <BenC> Keybuk: Oh, then blame dch and mvo for being misleading :)
[16:57] <Keybuk> what did you change to move that rules file?
[16:57] <BenC> Keybuk: I Changed the dh_install command to copy it to 66- instead of 65-
[16:57] <BenC> in debian/rules
[16:57] <keescook> lamont: it's trying to just call mmap() on it
[16:58] <Keybuk> BenC: so now people will have two copies? :)
[16:58] <lamont> keescook: ah, ok
[16:58] <Keybuk> and will get update-initramfs errors because of the missing file? :)
[16:58] <lamont> I thought mmap could specify
[16:58] <BenC> Keybuk: true, but the first one wont cause any problems :)
[16:58] <BenC> since it never gets run
[16:58] <lamont> OTOH, it's not like I've actually looked at mmap() recently
[16:58] <Keybuk> BenC: why doesn't it get run?
[16:59] <BenC> Keybuk: it gets run, but it has to come _after_ persistent-storage.rules, else the env is setup enough
[16:59] <BenC> Keybuk: udev initially has it right (60-persistent-storage and 61-persistent-storage-edd
[16:59] <BenC> )
[16:59] <Keybuk> persistent-storage-edd will come after persistent-storage
[16:59] <BenC> Keybuk: it's been installed on Ubuntu as both 65
[16:59] <Keybuk> it's alphabetically greater
[17:00] <BenC> Keybuk: It doesn't seem to DTRT then...moving it to 66- makes it work, and I tested that
[17:00] <Keybuk> that's worth knowing
[17:00] <BenC> Keybuk: boot with edd=on and you will see nothing for /dev/disk/by-id/edd-*
[17:00] <BenC> Keybuk: Unless you move that file
[17:01] <BenC> Keybuk: considering udev upstream has it as 60/61, and we had it as 65/65(and it didn't work), I believe someone figured that out already :)
[17:01] <Keybuk> heh
[17:01] <Keybuk> yeah that's likely
[17:01] <cjwatson> BenC: did you see the EDD grub hackery I was working on?
[17:01] <Keybuk> it might be because it ends up between storage and storage-tape
[17:02] <BenC> depending on alpha ordering makes little sense for this anyway
[17:02] <Keybuk> wouldn't surprise me if a goto jumps from one to the other
[17:02] <cjwatson> BenC: http://paste.ubuntu.com/6364/ is the current version
[17:02] <Keybuk> BenC: err, by changing the number you're still depending on alpha ordering :p
[17:02] <BenC> Keybuk: No, that's numeric ordering :P
[17:02] <Keybuk> BenC: done by sort() :p
[17:03] <Keybuk> udev is noway near intelligent enough to try and parse the filenames ;)
[17:03] <BenC> Well the storage{-,.} sorting is a little ambiguous for me
[17:03] <jdstrand> pitti: do you know off-hand of a way to test cups browsing via the command line or it's web interface?
[17:03] <cjwatson> BenC: if you have a spare system with multiple disks that you've booted with edd=on, I could do with a run of an instrumented version to make sure I'm getting it right
[17:03] <cjwatson> the reordering code is a bit hairy
[17:03] <pitti> jdstrand: you need another cups on a second machine for that
[17:03] <BenC> cjwatson: Hmm, I could check it out...but I don't know if I have a multi-disk setup to test
[17:04] <pitti> jdstrand: you enable browsing on one, sharing on the other host (easiest with the web UI or system-config-printer, or change it in cupsd.conf and force-reload), then check with lpstat -p whether you see the printer
[17:04] <jdstrand> pitti: ok thanks
[17:07] <cjwatson> BenC: I've tested it on a single-disk system, but that's a bit trivial :)
[17:07] <cjwatson> I have a two-disk system, but I don't know if it supports EDD and it's my server so I don't really want to reboot it to find out
[17:07] <keescook> lamont: on reboot, does /var/lib/misc/group.db exist already?
[17:08] <cjwatson> BenC: I'd welcome code review, at any rate
[17:08] <soren> cjwatson: When I'm done with my meeting I can do a quick reboot. I have 3 disks in my workstations and it's fairly recent, so chances are good :)
[17:09] <lamont> yes
[17:09] <lamont> keescook: yes
[17:09] <BenC> cjwatson: ok
[17:11] <mvo> pitti: looks like most of the diff is bt* in /etc/alternative
[17:12] <cjwatson> soren: let me come up with an instrumented version for you, then
[17:13] <BenC> Keybuk: are you following up on udev?
[17:13] <soren> cjwatson: Cool. I'm on amd64, by the way.
[17:16] <cjwatson> I was going to give you source
[17:17] <Keybuk> BenC: yup
[17:17] <Keybuk> BenC: merged your changes with mine
[17:17] <BenC> Keybuk: thanks
[17:18] <keescook> ogasawara_: weather report> any way to split up the failed package builds metric by architecture?
[17:19] <ogasawara_> keescook:  yup, I've got it on my todo list
[17:19] <cjwatson> soren: OK, apply debdiff from http://paste.ubuntu.com/6365/plain/
[17:20] <keescook> ogasawara_: sweet
[17:20] <cjwatson> soren: with that grub installed, I'd like you to run 'rm -f device.map.test; echo quit | grub --batch --device-map=device.map.test; cat device.map.test' and send me the output
[17:20] <cjwatson> should be some instrumentation on stderr
[17:20] <soren> cjwatson: I still need to reboot with edd=on, right?
[17:21] <cjwatson> soren: right
[17:21] <soren> cjwatson: Or do you want before and after?
[17:21] <cjwatson> no, I know what it'll do before
[17:21] <cjwatson> well
[17:21] <cjwatson> actually, I guess the ordering before is vaguely interesting
[17:21] <soren> Alright.
[17:21] <cjwatson> more interested in the instrumentation though
[17:22] <soren> cjwatson: Er... It just has my (non-existing) floppy drive now.
[17:23] <soren> That seems rather suboptimal :)
[17:23] <cjwatson> anything on stderr?
[17:23] <soren> Nope.
[17:23] <soren> http://pastebin.com/m4b28b1ad
[17:25] <soren> cjwatson: Er... The same happens with the grub that's in hardy right now.
[17:25] <keescook> lamont, slangasek: what do you think of the patch in bug 120015?  I think it looks sane, but wanted some other opinions.
[17:25] <ubotu> Launchpad bug 120015 in shadow "useradd too slow with LDAP nsswitch" [Wishlist,Triaged] https://launchpad.net/bugs/120015
[17:28]  * soren blushes
[17:28] <soren> cjwatson: Runing it as root helps :)
[17:29] <soren> cjwatson: Sorry for the scare there. :)
[17:29] <cjwatson> heh
[17:31] <jdstrand> pitti: I had the bright idea to run two cupsd processes on the local machine, with different cupsd.conf (and browse.conf and ports.conf) files, but it seems that I can't configure cupsd to use something other than printers.conf-- do you know of a way to do this?
[17:32] <pitti> jdstrand: the test suite runs the entire thing in /tmp/ as normal user; look at test/run-stp-tests.sh for how it configures that cupsd
[17:33] <jdstrand> pitti: excellent, thanks
[17:37] <cjwatson> seb128: I don't understand why you converted bug 210688 to a question; it seems like a legitimate bug report, and should either be addressed or marked invalid with an explanation, surely?
[17:37] <ubotu> Launchpad bug 210688 in gcc-defaults "upgrade from feisty to gutsy tries to remove apt" [Undecided,Invalid] https://launchpad.net/bugs/210688
[17:38] <seb128> cjwatson: I discussed with the submitter on #ubuntu-bugs this morning
[17:38] <jdstrand> pitti: fyi, it'll take some finagling to get it going, but ServerRoot is what will do the trick
[17:39] <jdstrand> pitti: this is all coming from writing a qa-regression-testing script for cupsys
[17:40] <jdstrand> pitti: browsing is the last bit (for today). I'll let you know when I'm done and maybe you can comment on it sometime?
[17:40] <seb128> cjwatson: but right, could have set the bug as incomplete or invalid rather
[17:40] <jdstrand> (no rush)
[17:40] <pitti> jdstrand: oh, rock; sure
[17:43] <soren> cjwatson: http://pastebin.com/m70a3862a
[17:44] <cjwatson> seb128: ah
[17:44] <cjwatson> seb128: I didn't have that context, just getting the bugmail
[17:44] <cjwatson> soren: whoopsie
[17:44] <cjwatson> soren: can you gdb that and get me a backtace
[17:45] <cjwatson> backtrace?
[17:45] <soren> cjwatson: Yeah, working on it.
[17:45] <seb128> cjwatson: I'll add a note saying that has been discussed on IRC next time ;-)
[17:45] <cjwatson> soren: yours is an excellent test case since it actually does seem to need reordering
[17:46] <cjwatson> and the BIOS doesn't seem to be able to get working EDD information for one of your drives, but two of them are fine
[17:46] <cjwatson> which is actually OK, two out of three is all we need to construct a working ordering
[17:46] <soren> cjwatson: http://pastebin.com/m64f740fc
[17:47] <soren> cjwatson: I actually specifically bought this system for testing this. No kidding.
[17:47] <soren> cjwatson: It had 2 SATA and 2 PATA disks in it to make it as error prone as possible.
[17:47] <soren> (I've since yanked the one PATA disk for other purposes)
[17:48] <cjwatson> ugh, well that's a horrible way for it to go wrong
[17:49] <soren> cjwatson: Well, not for testing your patch, obviously, but for testing booting with interesting disk configurations.
[17:49] <cjwatson> soren: 'print i' in gdb please?
[17:49] <soren> print i
[17:49] <soren> No symbol "i" in current context.
[17:49] <soren> (gdb)
[17:49] <cjwatson> soren: err, go up to frame 6 first
[17:50] <soren> Erm.. how?
[17:50] <cjwatson> 'up 6'
[17:50] <soren> Heheh..
[17:50] <soren> 135225248
[17:50] <cjwatson> busted stakc
[17:50] <cjwatson> stack
[17:50] <cjwatson> could you try again, break on restore_device_map, and step through it?
[17:51] <cjwatson> it might be easier if you did "make clean; sed -i 's/-O2/-O0/g' lib/Makefile; make" first
[17:52]  * soren -> phone call
[17:53] <cjwatson> oh, I have a guess
[17:53] <cjwatson> soren: could you put this at the end of the move_device function? (sorry about the nested functions, seems to be grub style)
[17:54] <cjwatson>         (*map)[0] = 0;
[17:54] <cjwatson>         device_mbr_sig[0] = 0;
[17:54] <cjwatson>         device_mbr_sig_avail[0] = 0;
[17:54] <soren> Sure.
[17:55] <cjwatson> that would cause a double free
[17:55] <cjwatson> this code is rather "I have only proven it correct, not run it"
[17:56] <Keybuk> cjwatson: I'd trust you've proven correct more than code I've run ;)
[17:57] <soren> cjwatson: That didnt' seem to help.
[17:57] <cjwatson> Keybuk: hmm, your confidence may be misplaced ;-)
[17:57] <cjwatson> soren: OK, thanks; I'll get back to you tomorrow morning, have to go out now
[17:58] <soren> cjwatson: Alrighty.
[18:05] <soren> cjwatson: Ah, I think I know what's going on.
[18:06] <soren> cjwatson: copy_device does a (*map)[dest] = (*map)[src];, so map has two indices pointing to the same memory chunk.
[18:10] <soren> cjwatson: Simply adding a (*map)[src] = 0; after that line removes the double free, but only gives me (hd0) and (hd1) in my device.map.
[18:17] <keescook> mvo, slangasek: is the "openssl prompts during upgrade" bug known already?
[18:17] <keescook> (I see to remember seeing some discussion about it)
[18:18] <keescook> *seem
[18:23] <mvo> keescook: I'm not sure if we have a open bug about it, its not milestoned (but it should IMO)
[18:23] <mvo> (its not milestoned if we have one)
[18:24] <keescook> mvo: okay, I will open it
[18:25] <keescook> mvo: ah, found it 182446
[18:29] <keescook> bryce: say, the "Unknown" title in xrandrgui seems ominous.  What do you think of changing that to "Unnamed" or similar?
[18:29] <bryce> it's Unknown in this case, because it's on a KVM switch which seems to be dropping the EDID info
[18:30] <bryce> so 'Unknown' is indeed the correct terminology...  sorry if it sounds ominous
[18:30] <bryce> fwiw, that's just my devel box; on all the other 9 systems I tested, it got the monitor's name correctly
[18:31] <bryce> (of course, I cheated and made sure all my monitors were listed in the monitor database to begin with *grin*)
[18:51] <slangasek> keescook: 120015> patch looks sane to me as well, so I'm surprised that's not already what adduser does
[19:01] <keescook> slangasek: thanks for checking it.  I'll upload it.
[19:03] <jeromeg> slangasek: hello
[19:03] <slangasek> jeromeg: hi
[19:04] <jeromeg> there seems to be a problem with the backported wesnoth in gutsy
[19:04] <mario_limonciell> bryce, did you ping me at some point on something early this morning?
[19:04] <bryce> ogasawara_: could you look into bug 151327?  It sounds like the kernel team fixed it, but we have one reporter saying it still does not work as of alpha 5.  It would be useful to have an update on that bug regarding what the kernel team did to fix it, and if it's still a known issue by them or believed to be fixed
[19:04] <ubotu> Launchpad bug 151327 in linux-restricted-modules-2.6.24 "[Gutsy] binary graphics drivers don't load with Xen (2.6.22 and 2.6.24)" [Medium,Incomplete] https://launchpad.net/bugs/151327
[19:04] <jeromeg> slangasek: the old version (1.2.8) is still in the repo
[19:05] <bryce> mario_limonciell: I didn't ping you, but last night ogra_cmpc had some questions for you about openchrome
[19:05] <slangasek> jeromeg: well, that indicates a build failure, then?
[19:05] <ogasawara_> bryce:  I'll take a look
[19:05] <mario_limonciell> bryce, ah.  ogra_cmpc what's up?
[19:06] <jeromeg> slangasek: i seems to be a sync problem etween different repos, because everything is fine in some other repos
[19:06] <jeromeg> *it
[19:06] <slangasek> jeromeg: oh, no, it appears to be in NEW
[19:06] <slangasek> jeromeg: er, everything should /not/ "be fine", the i386 binary hasn't been accepted out of NEW...
[19:06] <jeromeg> oh ok
[19:06] <jeromeg> slangasek: but i get :
[19:06] <jeromeg>  wesnoth | 1:1.4-1~gutsy1 | http://archive.ubuntu.com gutsy-backports/universe Sources
[19:07] <jeromeg> how can that be ?
[19:07] <slangasek> are you not on i386?
[19:07] <jeromeg> slangasek: i'm
[19:07] <slangasek> oh, that's a sources line
[19:07] <slangasek> the sources are there.  the binaries are not.
[19:07] <jeromeg> oh right ;)
[19:07] <jeromeg> sorry :)
[19:08] <jeromeg> but this seems to have caused weird bugs for some persons
[19:08] <bryce> brian, I'd love it if you could take another look at bug 181121.  Possibly the new driver fixes the crash for you
[19:08] <ubotu> Launchpad bug 181121 in linux-restricted-modules-2.6.24 "[fglrx] glplanet crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/181121
[19:08] <bryce> brian, no hurry, I'm just triaging through fglrx bugs (ATI has been asking about current ones)
[19:09] <jeromeg> slangasek: it also seems that wesnoth-data has to be pushed
[19:09] <slangasek> jeromeg: yes, that's all part of the i386 build.
[19:09] <jeromeg> ok
[19:09] <jeromeg> slangasek: you can do something to fix this ?
[19:10] <slangasek> yes, it's already pushed out of NEW
[19:10] <jeromeg> i think this would fix bug 209463
[19:10] <ubotu> Launchpad bug 209463 in wesnoth "wesnoth in gutsy-backports does not have required dependency" [Undecided,Invalid] https://launchpad.net/bugs/209463
[19:10] <jeromeg> slangasek: great, thank you !
[19:29] <JohnPhys> If this is not the place to ask this question, I apologize.  Why does fontconfig now create symlinks in /etc/fonts/conf.d/ to some of the "10-*" files in /etc/fonts/conf.avail ?  This seems to cause issues such as bug # 190848 , and makes some apps (gnome-terminal, possibly qt apps) not respect the preferences set in the appearances -> fonts dialog.  On earlier installs (gutsy/feisty/etc) these links are not created, so
[19:43] <mvo> pitti: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/kvm/profile/lts-ubuntu/ (even bigger ./
[19:47] <slangasek> fta: bug #192333 - the next obvious question is, when is beta 5 supposed to land? :)
[19:55] <fta> bug 192333
[19:56] <Keybuk> err
[19:56] <Keybuk> my dpkg-fu must be waning
[19:56] <Keybuk> if package A conflicts and replaces package B, doesn't that mean it can be installed and automatically remove the other
[19:56] <Caesar> Err, the most recent nfs-utils upload seems to have dropped a pile of Ubuntu patches
[19:57] <Caesar> Or should I be saying this in #ubuntu+1 ?
[19:58] <fta> slangasek, soon. we have the branches ready, i'm checking a regression
[20:01] <Caesar> I retract that, the Debian unstable upload that Ubuntu just merged has more patches removed than it should have
[20:04] <elmo> Keybuk: I thought you need CRP for auto removal
[20:04] <elmo> but my dpkg-fu is definitely waned
[20:05] <Keybuk> apparently I did *and* --auto-deconfigure
[20:05] <Keybuk> and maybe --force-everything --fuck-it --just-do-it-and-ill-pick-up-the-pieces-later
[20:06] <Keybuk> we should just use rpm
[20:07] <Mithrandir> Keybuk: C+R ought to be enough unless it's a virtual package in which P might be useful too.
[20:09] <Keybuk> Mithrandir: it wasn't
[20:10] <Mithrandir> Keybuk: paste?
[20:11] <Keybuk> Mithrandir: lost the paste, will play again later
[20:20] <slangasek> tjaalton: see Caesar's comments above?
[20:21] <slangasek> Caesar: what patches went missing that hadn't been merged?
[20:23] <Caesar> slangasek: at least 11-gssd-use-kernel-supported-enctypes.diff
[20:24] <Caesar> Spectacular breakage for Kerberized NFS here
[20:24] <Caesar> But the problem is the Debian package, although I will say a pile of Ubuntu changelogs fell out from the merge, not sure if that's supposed to happen or not when you merge from unstable
[20:25] <slangasek> no, it's not
[20:25] <Caesar> I didn't think so
[20:25] <slangasek> was 11-gssd-use-kernel-supported-enctypes.diff ever in Debian? It's not mentioned in the changelog at all
[20:25] <Caesar> Let me just check my facts
[20:26] <Caesar> Okay, so 11-gssd-use-kernel-supported-enctypes.diff was in 1.1.1-12ubuntu4
[20:27] <slangasek> tjaalton: where did all of the Ubuntu package history go when you merged nfs-utils?
[20:27] <Caesar> It's not in 1.1.2-2ubuntu1
[20:27]  * slangasek nods
[20:30] <Caesar> slangasek: and there was no such patch in 1:1.1.1-14 in Debian
[20:30] <Caesar> So I'm pretty sure that was an Ubuntu-specific patch, which got dropped
[20:30] <Caesar> (it'd be nice to get it upstream, I suspect we've already filed it there though)
[20:31] <slangasek> right; when tjaalton pops up, we should be able to have that sorted
[20:31] <Caesar> I can provide a debdiff it'll help
[20:32] <slangasek> that may, if you can file it in LP against nfs-utils
[20:33] <Caesar> slangasek: yep
[20:33] <Caesar> I'll look at doing that after I get my home directory back :-)
[20:33] <slangasek> ok :)
[20:34] <Caesar> hooray for downgrading
[20:38] <Caesar> seb128: can we talk about #191512 in a little bit?
[20:39] <seb128> bug #191512
[20:39] <ubotu> Launchpad bug 191512 in gvfs "gnome displays nfs mounts on the desktop" [Low,New] https://launchpad.net/bugs/191512
[20:39] <seb128> Caesar: sure
[20:40] <Caesar> seb128: cool, let me fix nfs-utils, then pawalls and I can talk to you about that bug
[20:40] <seb128> ok
[20:50] <tjaalton> slangasek: dpkg-genchanges segfaulst
[20:50] <tjaalton> -ts
[20:51] <tjaalton> if there's something missing I'll add it back
[20:52] <Mithrandir> tjaalton: dpkg-genchanges is written in perl, so that's thepthul.
[20:52] <slangasek> tjaalton: see Caesar's comments above; at least one patch went missing, and it's hard to know what else might have regressed because none of the previous Ubuntu changelog entries were carried over
[20:53] <tjaalton> slangasek: right, I'll check it out
[20:55] <bryce> bdmurray: hey, how do you attach upstream bug reports to a package which has multiple upstreams?  I.e., I want to hook one of the fglrx bugs to its upstream ati bug tracker in linux-restricted-modules-2.6.24 (bug #196617)
[20:59] <bdmurray> bryce: is the ati bug tracker registered in Launchpad?
[21:00] <bryce> bdmurray, no
[21:00] <tjaalton> slangasek: duh, that patch is from upstream but apparently not merged in 1.1.2 :/
[21:01] <tjaalton> so I'll add it back. it's the only one that was added by us (me)
[21:01] <bryce> heya tjaalton
[21:02] <bdmurray> bryce: What's the bug tracker url?
[21:03] <tjaalton> hi bryce
[21:03] <bryce> e.g. http://ati.cchtml.com/show_bug.cgi?id=902
[21:03] <bdmurray> Okay so that seems to be know to launchpad - https://launchpad.net/bugs/bugtrackers/ati-linux-bugs
[21:04] <bryce> ahh there it is.  odd name
[21:04] <bryce> hmm, I had searched for "ati" "amd" and "fglrx" but it didn't present that
[21:04] <bdmurray> Well looking at it that tracker doesn't seem to have a project which might be required to add the bug watch now.
[21:05] <bryce> could you set it to project 'fglrx'?
[21:07] <bdmurray> bryce: do you mean an exisiting project?  I don't see one.
[21:08] <Caesar> seb128: okay, we've got our act together
[21:09] <Caesar> seb128: so we really need a solution to #191512
[21:09] <Caesar> seb128: in an environment with autofs mounted NFS home directories, Nautilus is behaving really retardedly
[21:09] <bryce> bdmurray: no...  well don't worry about it, I've closed the bug as invalid anyway
[21:09]  * bryce shudders at the autofs mention
[21:10] <Caesar> seb128: what happens is autofs will periodically try to unmount the user's home directory, and succeeds from time to time
[21:10] <Caesar> seb128: then some user-process will cause it to be remounted
[21:10] <Caesar> seb128: that unmount/remount cycle causes a *new* Nautilus window to pop up
[21:11] <Caesar> seb128: so if that happens say a hundred times in a 24 hour period (or even overnight), the user comes back the next morning to a gazillion Nautilus windows for their $HOME
[21:11]  * Caesar wonders if he was just talking to the wall
[21:12] <Caesar> seb128_: how much of what I just said did you catch?
[21:12] <seb128_> Caesar: nothing
[21:12]  * Caesar sighs. Deeply.
[21:12] <norsetto> LOL
[21:13] <seb128_> Caesar: either you didn't use highlight or that was after the disconnect
[21:13] <Caesar> seb128_: see PM
[21:13] <seb128_> are you register?
[21:13] <seb128_> I didn't get any query
[21:14] <Caesar> seb128_: just pasted it
[21:14] <seb128_> got it now
[21:14] <seb128_> I don't know how automount works and how to configure it easily
[21:15] <Caesar> seb128_: so I don't think you need to care
[21:15] <seb128_> the mount issue could be https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/210468
[21:15] <Caesar> seb128_: the problem from my ignorant point of view is not autofs/automount, it's gvfs
[21:15] <tjaalton> Caesar: sorry for the nfs-utils goof, a new version on the way
[21:15] <Caesar> tjaalton: thanks
[21:16] <seb128_> Caesar: well, your description seems to describe several issues
[21:17] <Caesar> seb128_: autofs unmounting idle automounts is normal behaviour as far as I know
[21:17] <slangasek> seb128_: "unmounted again when not in use" is normal behavior for autofs.
[21:17] <seb128_> Caesar: you could try to remove the trash applet and move gvfsd-trash somewhere else and see if you still get those incorrectly mounted
[21:17] <Caesar> seb128_: that bug is not mine
[21:17] <Caesar> Mine is the nautilus windows popping up ad nauseum
[21:17] <seb128_> Caesar: well, you are saying that something is triggering the mount though no?
[21:17] <Caesar> seb128_: IMO, there shouldn't even be a volume icon on the desktop for an NFS mounted $HOME
[21:17] <slangasek> seb128_: no, he's saying that /when/ the homedir is mounted, it opens a new window and shouldn't
[21:18] <Caesar> slangasek: thanks
[21:18] <slangasek> homedir mounts coming and going is totally normal in an autofs env
[21:18] <seb128_> slangasek:  13:10 < Caesar> seb128: then some user-process will cause it to be remounted
[21:18] <seb128_> slangasek: he copied that to query
[21:18] <slangasek> seb128_: yes - which it's perfectly well allowed to do :)
[21:18] <Caesar> seb128_: I'm not complaining about the remount
[21:18] <seb128_> ah ok, I though it was part of the issue
[21:18] <seb128_> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/210468 does
[21:18] <Caesar> I'm complaining about the *behaviour* when it remounts
[21:18] <seb128_> and seems to be valid as well
[21:18] <slangasek> the only time the homedir is mounted is when it's being used; lots of things might use it periodically
[21:18] <seb128_> weird that you don't get it
[21:19] <Caesar> seb128_: you're conflating two bugs
[21:19] <seb128_> no I'm not
[21:19] <seb128_> I'm trying to have a view of all the issues we need to fix
[21:19] <pawalls> seb128_, Here's the problem. /home/$USER gets shown as a new mount on the desktop by gvfs and it shouldn't.
[21:19] <Caesar> seb128_: I'm not aware of us experiencing the problems described in #210468
[21:19] <seb128_> I read about this bug and I'm surprised it doesn't happen in your case
[21:20] <seb128_> well, all the media and home mounts are listed
[21:20] <Caesar> seb128_: I've just grepped for "Trash" in a few days worth of syslog and can't find a mention
[21:20] <seb128_> all the mounts in those directories rather
[21:21] <Caesar> The problem in #210468 appears to be that it's looking in /net for stuff?
[21:21] <seb128_> no
[21:21] <seb128_> the trash code is using mtab to list mounts and not doing filtering
[21:21] <seb128_> which is an another issue
[21:21] <Caesar> ok
[21:21] <seb128_> and those mounts are likely in mtab
[21:21] <seb128_> though I've no such setup to confimr
[21:22] <pawalls> seb128_, That's fine that things *relative* to /home/$USER are shown, but /home/$USER itself shouldn't be.
[21:22] <pawalls> seb128_, Is that an unreasonable request?
[21:22] <seb128_> pawalls: I don't think so, I need to talk to upstream about it though
[21:22] <seb128_> pawalls: they might be usecase where you want to list other nfs mounts there
[21:23] <pawalls> seb128_, Great! The problem also will make people sad if they use encrypted /home
[21:23] <seb128_> why?
[21:23] <pawalls> seb128_, Because they get an icon for their home directory on their desktop and it pops up a window.
[21:23] <pawalls> also, if /home/$USER is a separate partition (eg. nfs, this happens)
[21:23] <seb128_> well, you have different issues there
[21:23] <seb128_> is the icon an issue
[21:23] <pawalls> Is there a compelling reason to have a separate mount on the desktop for the user's home dir?
[21:23] <Caesar> seb128_: I think the icon is a symptom of the issue
[21:23] <pawalls> seb128_, It's a regression.
[21:23] <seb128_> or only nautilus opening a view on it ?
[21:23] <Caesar> I'd personally prefer not to see it
[21:23] <pawalls> seb128_, And the regression *also* causes a separate window to pop up.
[21:24] <pawalls> seb128_, Making the problem even worse.
[21:24] <seb128_> if people could stop using "regression" every time there is a behaviour change
[21:24] <seb128> that's not a regression
[21:24] <seb128> that's a completly new stack
[21:24] <seb128> and it has different design decisions
[21:24] <pawalls> seb128, It's a change in behavior that introduces a poor user experience.
[21:24] <Caesar> It's a behaviour change. Call it what you will.
[21:24] <pawalls> Regression is shorter to type.
[21:24] <seb128> no it's not
[21:25] <seb128> it's a new stack behaving differently
[21:25] <Caesar> Let's not debate semantics
[21:25] <seb128> it's not a change in something which was used before
[21:25] <pawalls> seb128, It's a change in user experience. Users with their home dir on a separate partition now get nautilus popping up and an icon on their desktop when they did not before.
[21:25] <pawalls> It doesn't matter what underlying code has changed.
[21:25] <pawalls> The end result is the same.
[21:26] <Caesar> seb128: if it'll help, I can try to work on giving you a configuration so you can locally reproduce the behaviour, but it might require a fair bit of work and infrastructure on your side
[21:26] <seb128> ok, let's not debate semantic
[21:26] <seb128> but I start being annoyed about people calling behaviour change regression and argumenting that regression should be fixed right now
[21:26] <seb128> anyway not the topic there
[21:26] <pawalls> seb128, Sorry if I gave that impression.
[21:26] <Caesar> seb128: I think that comes down to personal opinion/perception
[21:26] <Caesar> seb128: let's not get bogged down on that
[21:26] <pawalls> seb128, I thought I was pretty relaxed in our previous conversations via launchpad.
[21:27] <seb128> pawalls: it is, don't worry ;-)
[21:27] <pawalls> seb128, Recommended some possible solutions, offered to talk to you in real time if you liked.
[21:27] <Caesar> seb128: I think you agree that having zillions of Nautilus windows for your $HOME is not a good user experience though, yes?
[21:27] <seb128> just don't use regression as an argument
[21:27] <seb128> though I agree we have an issue to fix there
[21:27] <pawalls> seb128, Fair enough. Now the question is.. is it reasonable to keep the old behavior.
[21:27] <pawalls> or is there a compelling reason to not revert to the old behavior.
[21:27] <seb128> I'm not sure what the old behaviour is
[21:27] <seb128> I'm rather looking for what we should change now in gvfs
[21:27] <pawalls> seb128, Create a separate partition (any type) at /home/$USER
[21:27] <seb128> rather than copying the old stack
[21:28] <Caesar> seb128: the old behaviour is no volume icons on the desktop for NFS mounts, and no Nautilus windows popping up
[21:28] <pawalls> seb128, And then log into gnome.
[21:28] <pawalls> seb128, You will see an icon on your desktop named "$USER" and nautilus will pop up a window on login.
[21:28] <pawalls> seb128, You resolved the problems with /auto and other /home volumes not appearing.. but this one remains.
[21:29] <seb128> I'm looking at the code, a min
[21:29] <pawalls> seb128, Thanks.
[21:30] <pawalls> seb128, I'd be happy actually to provide a patch if it's still not clear. I actually haven't looked at the code personally. I didn't report the original bug, so I didn't feel compelled to provide a patch. I was originally just trying to give a 'me too' ;-)
[21:30] <seb128> ok, I think your usecase is a corner case
[21:30] <seb128> in the code
[21:31] <seb128> the code does
[21:31] <seb128>       if (g_str_has_prefix (mount_path, "/media/"))
[21:31] <seb128>         return TRUE;
[21:31] <seb128>       
[21:31] <seb128>       if (g_str_has_prefix (mount_path, g_get_home_dir ()))
[21:31] <seb128>         return TRUE;
[21:31] <seb128>     }
[21:31] <seb128>   
[21:31] <seb128>   return FALSE;
[21:31] <seb128> which means it consider only mounts in the current user directory
[21:32] <seb128> but doesn't filter out the user dir though
[21:32] <seb128> so likely a && !strcmp(mount_path, g_get_home_dir ()) would fix your issue there
[21:32] <Caesar> seb128: cool
[21:33] <seb128> Caesar, pawalls: does any of you know how to build a package to try a change?
[21:33] <pawalls> seb128, Yes.
[21:33] <Caesar> seb128: is the Pope Catholic? ;-)
[21:33] <slangasek> seb128: ... Caesar is a DD..:)
[21:33] <seb128> pawalls: in glib2.0, gio/gunixmounts.c g_unix_mount_guess_should_display()
[21:34] <seb128> could you change the
[21:34] <pawalls> seb128, I'm happy to see that it's explicit instead of implicit :)
[21:34] <seb128>      if (g_str_has_prefix (mount_path, g_get_home_dir ()))
[21:34] <seb128>         return TRUE;
[21:34] <seb128> to also check than the mount_path is not the user directory
[21:35] <pawalls> seb128, Yes.. that should work fine.
[21:35] <seb128> add a && !strcmp(mount_path, g_get_home_dir ()) or similar
[21:35] <pawalls> seb128, Ceaser or myself will test it.
[21:35] <seb128> thanks
[21:35] <seb128> I'll talk to upstream about the issue
[21:35] <seb128> let me know if that solves your bug
[21:35] <Caesar> seb128: okay, will do, thanks
[21:36] <seb128> thank you
[21:37] <seb128> slangasek: hey
[21:37] <seb128> slangasek: I changed gnome-panel to use time-admin again rather than the new dialog
[21:38] <seb128> slangasek: that workaround the fix milestoned issues about the new dialog and users asked to get the time-admin dialog which let sync on ntp and change timezone rather than the one
[21:39] <seb128> let me know if you think the change is not appropriate
[21:39] <seb128> but I think that should be no issue
[21:39] <Caesar> seb128: unsatisfiable build dependencies :-(
[21:40] <seb128> s/the one/the new one
[21:40] <seb128> Caesar: for?
[21:40] <Caesar> glib2.0
[21:40] <slangasek> seb128: right, saw your comment about that in one of the bugs, was waiting for it to show up on my mirror so I could test
[21:40] <seb128> slangasek: ok
[21:40] <Caesar> seb128: The following packages have unmet dependencies: libfam-dev: Depends: libfam0 (= 2.7.0-13)
[21:40] <slangasek> seb128: but time-admin certainly should be an improvement over the current behavior, I think
[21:40] <seb128> Caesar: which one? that is weird because hardy is sort of stable now and glib2.0 has not a lot of build-depends
[21:41] <seb128> Caesar: install libgamin rather
[21:41] <Caesar> seb128: ok
[21:41] <seb128> slangasek: ok, then we agree, good ;-)
[21:44] <slangasek> seb128: ah, and I'll wait a bit longer, it's on my mirror now but the upgrade wants to break both the kernel and OOo due to packages still being in the process of building :)
[21:45] <seb128> no hurry ;-)
[21:49] <tedg> How do I ignore the "maintainer isn't @ubuntu.com" error in debuild?
[21:49] <tedg> (or more correctly, how do I make debuild ignore it)
[21:49] <seb128> tedg: it's not a blocker, just ignore it ;-)
[21:50] <Lamego> close your eyes :P
[21:50] <slangasek> tedg: don't use "ubuntu" in the version number if you're not uploading to Ubuntu?
[21:51] <tedg> seb128: No, it does seem to be fatal.
[21:51] <slangasek> and if you are uploading to Ubuntu, comply with the DebianMaintainer spec instead of ignoring the error
[21:51] <tedg> slangasek: The problem is that I'm just trying to do this security patch, so I'm trying to avoid changing as much as possible...  the previous packager (on dapper) didn't do it.
[21:52] <slangasek> tedg: I would argue that the DebianMaintainer spec should be applied to security updates to dapper, the same as to any other new uploads
[21:52] <Caesar> tedg: changing the maintainer isn't changing functional behaviour
[21:52] <slangasek> tedg: update-maintainer --section=[main|universe] will DTRT to the changelog
[21:52] <slangasek> er, control file
[21:53] <slangasek> anyway, your other option would be to use a dapper version of debuild... :)
[21:53] <tedg> Okay, I'll change it.  If keescook rejects it I'm coming back after you guys ;)
[21:54] <seb128> thinking about this automount issue
[21:54] <seb128> how come that the current logged user directory is unmounted?
[21:55] <seb128> there is usually files used there
[21:55] <slangasek> if keescook rejects it, I'm going to tease him mercilessly about his glib2.0 version numberb ug
[21:55] <slangasek> >:)
[21:56] <Caesar> heh
[21:56] <slangasek> seb128: evidently, there are no open file descriptors associated with the mount, so it idle unmounts?
[21:56] <ogra_cmpc> i think the maintainer spec was not in place in dapper, we should have a clear rule for handling such cases
[21:56] <Caesar> slangasek: which surprises me somewhat
[21:57] <Caesar> I've asked someone to keep a terminal window open with their $CWD == $HOME overnight and see what happens
[21:57] <slangasek> oh, $CWD alone should trip it, shouldn't it, hmm
[21:57] <slangasek> that is odd, then
[21:57] <Caesar> Unless automount is doing a lazy unmount?
[21:57] <slangasek> that would be... an error
[21:57] <slangasek> :)
[21:58] <Caesar> I'll be intrigued to see what keeping a terminal window open does
[21:59] <slangasek> anyway, I would consider it a bug for nautilus to auto-open a window for /any/ autofs mount
[22:00] <Caesar> slangasek: previously it was doing it for everything in /auto
[22:00] <Caesar> That was just awesome when slocate went berko and tried to index /auto
[22:00] <slangasek> heh
[22:00] <Caesar> But I believe both those problems have been fixed
[22:00] <slangasek> wonder what it does with /afs
[22:01] <seb128> gvfs only lists shares in media and in the user directory nowadays
[22:01] <slangasek> ok
[22:01] <seb128> the user directory which is the issue there being a corner case
[22:03] <Caesar> seb128: will you proposed glib-2.0 modification stop $HOME appearing on the desktop, or just fix the Nautilus window popping issue?
[22:03] <Caesar> s/you/your/
[22:08] <james_w> what should be the version number of an SRU to http://packages.ubuntu.com/ca-certificates in feisty?
[22:08] <james_w> i.e. a native package with a different version to every other release.
[22:08] <cjwatson> soren: (*map)[src] = 0 in copy_device is definitely wrong - it really is supposed to just copy. Obviously it's being used wrong since the intent (a logical assertion, indeed) at the end of move_device is that there should be only one reference to each device.
[22:09] <soren> cjwatson: Makes sense.
[22:10] <infinity> james_w: 20061027.1
[22:10] <cjwatson> gutsy is the hard one
[22:10] <cjwatson> ca-certificates |   20061027 |        feisty | source, all
[22:10] <cjwatson> ca-certificates |   20070303 |         gutsy | source, all
[22:10] <cjwatson> ca-certificates | 20070303-0ubuntu1 |         hardy | source, all
[22:10] <infinity> james_w: Or 20061027feisty1 (or some variant)
[22:10] <slangasek> mathiaz: muhaha, my runes in this samba upload are going to be SO much more crackful than yours
[22:11] <cjwatson> 20070303-0gutsy1 would be OK, I guess
[22:11] <infinity> cjwatson: Is the hardy one still native?  I hate native packages with seemingly non-native version numbers. :/
[22:11] <Ward1983> i found a annoyance when installing ubuntu for the first time on my laptop, and its still in 7.10, so i would like to file a bug but have no clue how or what to write, so i thought i'd come explain it here
[22:11] <cjwatson> infinity: probably
[22:11] <Caesar> seb128: So a modified glib2.0 doesn't prevent the $HOME volume appearing on the desktop
[22:11] <mathiaz> slangasek: which bug are you trying to fix ?
[22:11] <cjwatson> infinity: note the version number in Debian, though ...
[22:11] <cjwatson> ca-certificates |   20070303 |        stable | source, all
[22:11] <cjwatson> ca-certificates | 20070303-0.1 |       testing | source, all
[22:11] <cjwatson> ca-certificates | 20070303-0.1 |      unstable | source, all
[22:11] <Caesar> seb128: won't be able to say about the Nautilus thing for a bit
[22:12] <infinity> cjwatson: Yeah, which is also a policy no-no, that should have been $date.0.1
[22:12] <Ward1983> when i install i just get virtical random colored lines and the rest of the LCD slowly turns white
[22:12] <infinity> cjwatson: Oh well.
[22:12] <slangasek> mathiaz: bug #206036
[22:12] <ubotu> Launchpad bug 206036 in samba "package samba 3.0.28a-0ubuntu3 failed to install/upgrade: " [Undecided,Incomplete] https://launchpad.net/bugs/206036
[22:12] <Ward1983> now the only problem was Option "UseDisplayDevice" "DFP" was missing
[22:12] <slangasek> mathiaz: the fix is " || ! getent passwd "$USER" >/dev/null"
[22:13] <Ward1983> so every new user with a similar laptop just doesnt get anything on their screen
[22:13] <Ward1983> at least for the 2 last releases
[22:13] <infinity> slangasek: I'd comment on how vile that looks if I wasn't sure I that I have almost that precise test in one of my own maintainer scripts.
[22:13] <slangasek> heh
[22:14] <seb128_> re
[22:14] <seb128_> need to give some kicking to my isp tomorrow
 Caesar: both
[22:14] <seb128_>  Caesar: it'll make it stop being listed as an user visible mount
[22:14] <seb128_>  Caesar: ie, be a standard directory on the disk
[22:14] <james_w> infinity: yes it is still native.
[22:15] <james_w> cjwatson: pitti recommended 20070303-0ubuntu0.7.10 for gutsy
[22:15] <Caesar> seb128: well it didn't work then
[22:15] <Caesar> I'm also trying to forcible reproduce the problem by SIGUSR1ing automount, which should force an expire of mounts
[22:15] <Caesar> s/forcible/forcibly/
[22:16] <Caesar> seb128: let me just give it a reboot to make sure everything cops a restart
[22:16] <infinity> james_w: There's no right answer, really, just many wrong ones (ie: ones that don't eval >> or << the versions in previous/later releases, or versions which are just plain unparseable to the human eye)
[22:16] <seb128_> Caesar: ok
[22:16] <infinity> james_w: pitti's suggestion maps to what he and I decided on for Mozilla security backports years ago, and now seems to be used by much of the security team.
[22:16] <slangasek> #define right !wrong
[22:17] <infinity> james_w: And it is readable, I'll give it that.
[22:17] <james_w> infinity: I'm using 20061027-0ubuntu0.1 at the moment, but I don't want to steal a security number, is there a danger of doing that?
[22:17] <infinity> james_w: The security folk are good at reading.
[22:17] <infinity> james_w: (And they pretty much have to anyway)
[22:17] <james_w> :-)
[22:18] <james_w> I had a look at the packages in gutsy-updates, and there didn't seem to be scheme that was discernible to my feeble mind
[22:18] <Caesar> seb128_: no, definitely didn't work
[22:18] <infinity> james_w: No matter what you pick, the security team still needs to look it up and make sure not to clash, so don't worry too much.
[22:18] <james_w> I'll submit it like that, pitti can ask for a different one if he likes.
[22:19] <james_w> a second question, does the SRU team handle sponsored SRUs, or would I still subscribe u-m-s?
[22:19] <infinity> james_w: $ver.0.1, $ver-0ubuntu0.1, $ver-0ubuntu0.7.10, $ver.gutsy.1, $ver.yomamma.1... They all "work".
[22:19] <Ward1983> anyone?
[22:19] <james_w> thanks infinity
[22:20] <slangasek> james_w: it appears that pitti will just upload any of these packages for you directly, before I have a chance to blink twice, so I'd go with that :)
[22:20] <seb128_> Caesar: ok, something else to try for you
[22:20] <seb128_> Caesar: get the gvfs source
[22:20] <james_w> slangasek: thanks, I'll make sure he does it while you're asleep tonight :-)
[22:20] <infinity> james_w: Usually, I'd suggest finding a sponsor, but vorlon seems to be implying that in your case you already have one with pitti. :)
[22:20] <seb128_> Caesar: hal/ghalvolumemonitor.c _g_unix_mount_point_guess_should_display
[22:20] <seb128_> Caesar: similar change
[22:20] <Caesar> seb128_: ok, getting
[22:21] <james_w> infinity: pitti sponsored the fix in to hardy, and was helping with the SRUs, so I think he'll be willing to do it.
[22:55] <keescook> james_w: -updates and -security tend to follow the same conventions.  I've outlined the versioning styles here: https://wiki.ubuntu.com/SecurityUpdateProcedures under "Preparing an update"
[22:58] <james_w> keescook: thanks
[22:58] <emgent> hi kees :)
[22:59] <keescook> heya emgent
[22:59] <keescook> james_w: and, as infinity says, we're good about making sure we don't step on something.  (or rather, soyuz is perfect at it, and we can't)
[22:59] <soren> cjwatson: Anything else you want me to try this evening? I just remembered I won't be around tomorrow and the day after.
[23:13] <Caesar> So, ah, when is there going to be a linux-restricted-modules-2.6.24-14-generic package to go with the kernel?
[23:15] <Caesar> seb128: that mod to gvfs didn't get rid of the $HOME volume on the desktop
[23:17] <seb128> Caesar: ok, so you have a weird config I've no idea about
[23:17] <seb128> the easier would be to describe how to config easily a similar setup so it can be debugged
[23:17] <Caesar> seb128: s/weird/large enterprise or academic institution/
[23:18] <Caesar> seb128: how much infrastructure do you have at your disposal
[23:18] <seb128> none
[23:18] <seb128> a compuiter
[23:18] <Caesar> Then we've got a problem
[23:18] <seb128> computer
[23:19] <seb128> well, a desktop and laptop so I can do networking between those
[23:19] <Caesar> You'll need an NFS server
[23:19] <Caesar> So you'll have to use one as an NFS server for your home directory and automount it on the other one
[23:20] <Caesar> I'll update the bug with specifics once I've figured them out for you
[23:20] <seb128> ok, weird though that the gvfs change didn't work
[23:20] <Caesar> Yeah
[23:20] <Caesar> Sounded promising
[23:20] <seb128> is your nfs mount listed in gvfs-mount -li ?
[23:20] <seb128> Caesar: and is the nfs thing in fstab?
[23:21] <Caesar> seb128: no, that's the point of autofs
[23:22] <Caesar> seb128: and yes, my home directory is listed in the output of gvfs-mount -li
[23:25] <pawalls> seb128, I'll try to hack together a patch for this.
[23:25] <pawalls> seb128, Thanks for the pointers and for being available.
[23:26] <Caesar> Yeah, thanks seb128
[23:27] <seb128> Caesar: do you still get the icon listed and the mount in gvfs-mount -li with the glib and gvfs changes?
[23:27] <Caesar> seb128: yes
[23:30] <seb128> Caesar: speaking with on of the upstream guy
[23:30] <seb128> he did recommend doing the same changes that I suggested
[23:30] <seb128>  if (strcmp (mount_path, g_get_home_dir()) == 0) return FALSE;
[23:30] <seb128> " if (strcmp (mount_path, g_get_home_dir()) == 0) return FALSE;" is what he suggested
[23:30] <seb128> Caesar: maybe you could try to make sure the function in gvfs returns false as expected?
[23:32] <seb128> Caesar: are those mounts listed in mtab?
[23:36] <cjwatson> soren: just figuring it out now with a reduced harness; I'll see if I can get you something before I crash
[23:36] <seb128> pawalls: still around?
[23:37] <soren> cjwatson: Ok, I'll be around for a little bit more, but I'm getting sleepy eyed, too.
[23:38] <cjwatson> fortunately I think I've just seen the bug
[23:39] <cjwatson> soren: ok, on top of the change you've already made, find the bit in move_device that looks like this:
[23:39] <cjwatson>             if (walk == limit || next == dest)
[23:39] <cjwatson>               break;
[23:39] <cjwatson>             copy_device (next, cur);
[23:39] <cjwatson> ... and change it to this:
[23:39] <cjwatson>             if (walk == limit)
[23:39] <cjwatson>               break;
[23:39] <cjwatson>             copy_device (next, cur);
[23:39] <cjwatson>             if (next == dest)
[23:39] <cjwatson>               break;
[23:39] <cjwatson> that fixes my test harness at least
[23:45] <Dossy> Hi.  What team is responsible for VNC?  the X Swat team?
[23:46] <cjwatson> soren: any luck?
[23:46] <soren> Trying right now.
[23:46] <cjwatson> cool
[23:46] <soren> Sorry, got stuck in an e-mail.
[23:47] <soren> That seems to have done it.
[23:47] <soren> I'll pastebin the results.
[23:47] <soren> http://pastebin.com/m2c5e2894
[23:51] <pawalls> seb128, yessir
[23:52] <seb128> pawalls: could you try editing gvfs hal/ghalmount.c g_hal_mount_new()
[23:52] <seb128> and change the && in
[23:52] <seb128>   if (volume == NULL && !g_unix_mount_guess_should_display (mount_entry))
[23:52] <seb128> to ||
[23:54] <seb128> pawalls: just a random try, not sure it'll work
[23:56] <cjwatson> soren: awesome. Thanks!
[23:57] <soren> cjwatson: Any time.
[23:57]  * soren crashes