[01:19] <lifeless> ok,thats amusing:
[01:20] <lifeless> robertc@lifelessgwy:/etc/ppp/ip-up.d$ sudo sudo do-release-upgrade
[01:20] <lifeless> Checking for a new ubuntu release
[01:20] <lifeless> No new release found
[01:20] <lifeless> robertc@lifelessgwy:/etc/ppp/ip-up.d$ less /etc/issue
[01:20] <lifeless> Ubuntu 6.06.2 LTS \n \l
[01:26] <wgrant> lifeless: That's correct.
[01:27] <wgrant> lifeless: Dapper upgrades won't be activated until 8.04.1.
[01:27] <lifeless> wgrant: not according to https://help.ubuntu.com/community/HardyUpgrades
[01:27] <lifeless> it claims it should work now
[01:27] <lifeless> wgrant: I appreciate you may be right; but the docs out there disagree
[01:28] <wgrant> http://changelogs.ubuntu.com/meta-release-lts says that the docs are wrong.
[01:29] <wgrant> You might want to add a -p
[01:29] <lifeless> (because its pointing at dapper ? )
[01:29] <wgrant> Because there's no Hardy in there.
[01:30] <wgrant> Whereas meta-release-lts-proposed does have it.
[01:30] <lifeless> k; I've not actually dug around the meta-release internals before
[01:31] <lifeless> thanks; I'll documentt his
[01:31] <lifeless> *this*
[01:31] <wgrant> They're what the upgrade tool uses to work out what's new.
[01:31] <lifeless> yes, I'm aware of the principle
[01:31] <lifeless> just hadn't looked at the details
[01:31] <wgrant> Ah.
[01:31] <wgrant> Documentation is good.
[01:32] <lifeless> time to see how the upgrade goes
[01:33] <lifeless> (this machine has 96MB of memory)
[01:33] <wgrant> Heh.
[01:34] <lifeless> P133, firewall/cache for my home network. LOTS of disk - a whole 2.7GB
[01:34] <lifeless> sorry, 3.9GB, 2.7GB of which is used.
[01:35] <wgrant> I don't think I've run Ubuntu on anything that old.
[01:36] <lifeless> digital obselescence is vastly exaggerated
[04:32] <cody-somerville> grr... I hate how Firefox opens your homepage when you open a new window.
[04:32]  * cody-somerville has his homepage set to 30 or so tabs.
[04:40] <johanbr> cody-somerville: Why not keep those 30 tabs as bookmarks or as a saved session instead?
[04:40] <cody-somerville> thats what I'll end up doing.
[04:42] <chubs_> cody-somerville: I feel sorry for your bandwidth
[04:42]  * cody-somerville has only used 5GB this month :P.... he spends too much time at work :(
[05:26] <Tyrone_man> Hey everyone, I was wondering if there is a way to get an iso of intrepid, or do I have to work up from an existing system by a dist-upgrade to a given repo? Thanks
[05:27] <RAOF> Tyrone_man: http://iso.qa.ubuntu.com/ ?
[05:27] <persia> Tyrone_man: There's no livecd yet, but the alternate CD has testing images from http://iso.qa.ubuntu.com/ : report success/failure please.
[05:28] <Tyrone_man> oh, thanks.
[05:28]  * persia loses the race to RAOF again: maybe glue is the answer
[05:31] <Tyrone_man> I will see about a virtual install, but I'd like to let you all know of a little bug in hardy (for your safety). Sometimes, when deleting big (1gb+) files, the userfs will just go psycho and swell up the ram and swap, even after deletion, resulting in a HUGE slowdown, and misstypes at a terminal, such as messing a keystroke, along the lines of rm -R ./* to rm -R /* ... thus forcing you to type this from fedora..
[05:40] <pwnguin> userfs?
[05:41] <lifeless> whats an rfs, that you use it?
[05:41] <Tyrone_man> yea, the new gfs. Ya know, the big shiny upgrade that everyone was waiting for
[05:42] <pwnguin> oh that
[05:42] <Tyrone_man> I meant userspace fs
[05:42] <Tyrone_man> sorry, my bad
[05:42] <pwnguin> so this is a network mount?
[05:44] <Tyrone_man> It was just a local partition on my disk, was doing some video editing, sent something to trash can while I was cleaning another dir, and bam... I figured it out when i hit 'ls' and got 'cannot locate /bin/ls' .. i was like :<
[05:46] <Tyrone_man> I'm sorry, did I mess that up again? It's gvfs isn't it? Or was that the old one... gfs is a network fs?
[05:48] <pwnguin> the new gnome stuff is supposed to be a FUSE thing
[05:49] <pwnguin> normally you shouldnt need that for a local partition...
[05:50] <pwnguin> my suspicion is that deleting your large file triggered a copy
[05:50] <Tyrone_man> Hmm, weird,
[05:50] <pwnguin> or maybe forced some actual deletions
[05:50] <Tyrone_man> Yea, I never read up its spec more than it was outside the kernel
[05:50] <pwnguin> anyways, i know of a few people having performance problems in hardy with disk
[05:51] <wgrant> GVFS is the GNOME-VFS replacement.
[05:51] <Tyrone_man> yea, probably a copy, it went from a 200mb ram usage to 999mb in 5 secons, then in 1 minute it flooded my swap
[05:51] <wgrant> GFS is a different filesystem altogether.
[05:51] <pwnguin> i believe gvfs is what this topic is about ;)
[05:51] <Tyrone_man> I see, that makes sense, thanks for the correction. It makes sense, I remember something from the kernel config on fs's
[05:52] <wgrant> There kernel knows nothing of GVFS.
[05:52] <pwnguin> well
[05:52] <wgrant> But GVFS uses FUSE, which the kernel does know about.
[05:52] <pwnguin> FUSE
[05:52] <Tyrone_man> Ah, so FUSE is a new generic api for userspace?
[05:52] <pwnguin> but a performance problem who knows
[05:52] <RAOF> Well, gvfs doesn't really use fuse.
[05:52] <pwnguin> FUSE aint new
[05:52] <wgrant> RAOF: For non-GVFS apps it does.
[05:52] <pwnguin> RAOF: waa?
[05:52] <RAOF> wgrant: Right.
[05:53] <RAOF> But anything using gvfs itself won't be touching fuse.
[05:53] <wgrant> Hopefully.
[05:53] <Tyrone_man> I see
[05:53] <Tyrone_man> But FUSE is just an api, correct?
[05:54] <pwnguin> that statement seems wrong but i dont know where
[05:54] <RAOF> Kinda. It's also a kernel module.
[05:54] <Tyrone_man> So it's a modular module api.
[05:54] <Tyrone_man> ...hmm
[05:54] <Tyrone_man> I see
[05:54] <pwnguin> plus some processes
[05:55] <RAOF> Yup.  The fuse module farms out the actual filesystem access to external processes.
[05:55] <pwnguin> its sorta a microkernel approach to filesystems
[05:55] <RAOF> ya
[05:55] <wgrant> That's a fairly good way of putting it, pwnguin.
[05:55] <Tyrone_man> I recall that implies lag from call to action
[05:55] <Tyrone_man> yes?
[05:55] <wgrant> Of such an incredibly small amount it's probably not noticable, but sure.
[05:56] <RAOF> There's _always_ lag from call to action?
[05:56] <Tyrone_man> Right, I was looking into microkerns when reading up on Hurd
[05:56] <wgrant> FUSE will introduce a tiny bit more.
[05:56] <lifeless> its called clock cycles :P
[05:56] <wgrant> But nothing at all significant.
[05:56] <RAOF> Right.  But not of a qualitatively different kind.  You'll still block on a blocking write, etc.
[05:56] <pwnguin> fuse will introduce copy problems etc
[05:56] <lifeless> so its a bug in pqm/bzrlib
[05:56] <RAOF> pwnguin: Really?  In what way?
[05:57] <pwnguin> but for stuff that isn't disk, its invaluable
[05:57] <lifeless> meh echannel
[05:57] <RAOF> lifeless: :)
[05:58] <RAOF> pwnguin: Oh, you mean needing to copy data from userspace to kernelspace?
[05:58] <pwnguin> RAOF: correct me if im wrong, but with sshfs, incoming data is written to the ssh process, then to the destination, etc
[05:59] <RAOF> Dunno about the specifics.  It would of course be perfectly possible.
[05:59] <pwnguin> thats the traditional microkernel argument
[05:59] <pwnguin> extra copying to move data around, extra context switches
[05:59] <RAOF> Right.
[06:00] <Tyrone_man> extra possibilities to toast your drive??
[06:00] <Tyrone_man> or, rather, your mem?
[06:00] <lifeless> well
[06:00] <lifeless> copying is orthogonal, thats what the MMU allows us to prevent
[06:00] <pwnguin> if swap went through the roof it was an application
[06:01] <pwnguin> Tyrone_man: its going to be very hard to diagnose your problem with the OS blown out of the way etc =(
[06:01] <RAOF> lifeless: Mapping parts of someone else's address space to your own?
[06:01] <pwnguin> right
[06:01] <Tyrone_man> Hey, nothing was writting to the file, it was dead. Its done this many times, in various ways, but yea. Always when trashing it, not doing RM. Well, I still saved my /home and /root
[06:02] <lifeless> RAOF: handing off data via zero-copy
[06:02] <pwnguin> 0 copy messaging
[06:07] <Tyrone_man> maybe a dumb question, but is the trashing function handled by a script or an actual compiled app? I never really noticed either way.
[06:50] <pitti> Good morning
[06:50]  * slangasek waves
[06:52]  * bliZZardz smiles
[06:53]  * StevenK waves to pitti 
[06:53] <StevenK> pitti: Would you mind casting your gaze over bug #195260?
[06:54] <pitti> StevenK: right, looks like v-done
[06:55] <StevenK> pitti: So it gets slammed into -updates and the Hardy task closed?
[06:55] <pitti> StevenK: yes
[06:55] <StevenK> Cool
[06:55] <StevenK> pitti: Make it so, when you have a chance :-)
[06:56] <pitti> done
[06:56] <StevenK> pitti: Thanks :-)
[06:57]  * StevenK checks intrepid's NEW queue
[06:59]  * StevenK wonders how libhildonthumbnail-dev is in testing and unstable and not intrepid
[07:07] <geser> Good morning pitti
[07:07] <StevenK> pitti: Could you be convinced to pull that over?
[07:07] <pitti> hey geser
[07:21] <dholbach> good morning
[07:24]  * pitti hugs dholbach
[07:25]  * dholbach hugs pitti back
[07:27] <pitti> StevenK: weird, no idea why the autosync scripts don't pick that up
[07:27] <StevenK> pitti: Me neither
[07:27] <StevenK> pitti: It seems to be a perfect candidate
[07:27] <pitti> E: libhildonthumbnail-dev: not found
[07:27] <pitti> eh?
[07:28] <StevenK> pitti: That's a binary package name
[07:28] <pitti> oh, hildon-thumbnail
[07:28] <pitti> https://edge.launchpad.net/ubuntu/+source/hildon-thumbnail
[07:28] <StevenK> Maybe it failed to build
[07:28]  * StevenK digs
[07:28] <pitti> StevenK: we have a much newer version
[07:28] <pitti> s/newer/greater/
[07:29] <StevenK> Oh, hildon-thumbnail-dev
[07:29]  * StevenK will stop being thick soon. Hopefully.
[08:14] <Tyrone_man> exit
[08:15] <fabbione> superm1: ping?
[08:15] <pitti> hey fabbione, good morning!
[08:15] <pitti> fabbione: sorry, dude, for not winning the championship this time :)
[08:16] <fabbione> pitti: hey man...
[08:16] <fabbione> it's ok.. Spain did play much better than Italy
[08:16] <fabbione> they for sure deserve to go further more than we do :)
[08:16] <superm1> fabbione, pong, but only on the condition that it's quick. i'm headed to bed in a few minutes
[08:17] <fabbione> superm1: yeps. very..
[08:17] <fabbione> dpkg: error processing /var/cache/apt/archives/libmyth-0.21_0.21.svn20080607-0.0_amd64.deb (--unpack): trying to overwrite `/usr/lib/libmythlivemedia-0.21.so.0.21.0', which is also in package libmyth-0.21-0
[08:17] <fabbione> i know this is happening becuase i have a mixed archives
[08:17] <superm1> that looks like weekly builds
[08:17] <superm1> or something
[08:17] <fabbione> ubuntu + debianmultimeida
[08:17] <superm1> oh yuck
[08:17] <superm1> why did you do that?
[08:17] <pitti> \o/ different package names
[08:17] <fabbione> because there are a couple of packages i need from there
[08:18] <fabbione> and i am pretty sure i am not the only one
[08:18] <fabbione> can we either sync package names
[08:18] <fabbione> or perhaps be smart and nice to fools like me and add a C/R/P into our packages?
[08:18] <superm1> well honestly anything that we "need" from debian multimedia should be pulled into ubuntu multiverse at minimum
[08:19] <fabbione> i am pretty sure you can't pull everything...
[08:19] <superm1> but i'll talk to marillat about syncing up to our package naming standards
[08:19] <superm1> its a little nicer the way we do it
[08:19] <fabbione> that would be sort of nice
[08:19] <fabbione> it's really nothing urgent for me
[08:19] <fabbione> let's get this straight.. just very nice to have
[08:19] <superm1> well remember that d-m is not necessarily binary compatible
[08:19] <superm1> so if there are packages that you need, lets try to at least get those in ubuntu?
[08:20] <fabbione> right..
[08:20] <fabbione> ok
[08:20] <fabbione> get some sleep.. i will try to remember what i need from there :)
[08:20] <fabbione> this installation is somehow X years old :)
[08:20] <superm1> there is a filter in synaptic that shows you where stuff comes from
[08:20] <superm1> it might be useful to you
[08:20] <superm1> g'night
[08:21] <fabbione> night
[08:21]  * fabbione doesn't even have synaptic installed...
[08:22] <persia> fabbione: apt-cache policy?
[08:22] <fabbione> yeah.. no worries.. i just need to remember the packages first
[08:23] <persia> Ah.  I was thinking of some pipe that fed the results of grep-dctrl on your debian-multimedia packages.gz into apt-cache policy to make you a handy list.
[08:25]  * fabbione ponders a much simpler solution with apt pinning
[10:10] <seb128> is launchpad working correctly for other people?
[10:11] <seb128> it sorts of work for me but I've to retry several times on some pages because it's being slow or something
[10:11] <seb128> I don't get errors but pages just don't load
[10:11] <slangasek> seems too be working for me
[10:11] <seb128> hum, ok
[10:23] <cody-somerville> slangasek, please accept bug #232364 as release critical.
[10:24] <slangasek> cody-somerville: from what I read in scrollback over the weekend, we don't have a confirmed fix for that yet?
[10:24] <cody-somerville> slangasek, I believe I have a fix so that Xubuntu logins won't freeze.
[10:24] <cody-somerville> slangasek, It doesn't fix the libxcb issues, just avoids them
[10:24] <cody-somerville> slangasek, I'm working very hard to get it tested and will be doing uploads today.
[10:24] <slangasek> ok, I'm happy to include that if you can get it SRUed today
[10:25] <slangasek> (or tomorrow, even, but today is better :)
[10:25] <persia> Be nicer to fix the xcb issues.  Might also help with bug #87947
[10:25] <persia> (which is broken for multiverse non-free java, so can't be fixed there)
[10:25] <cody-somerville> Well, we could recompile without libxcb
[10:26] <cody-somerville> but I don't think we have time for the point release
[10:26] <slangasek> yeah, I haven't responded to the email thread yet, but I'm not keen on "completely change how we're building libX11" as a last-minute SRU for .1
[10:26] <slangasek> to be accurate, I'm not keen on it as an SRU at all :)
[10:27] <cody-somerville> slangasek, it is either that or wait 4-6 weeks for the next stable release of libxcb
[10:27] <cody-somerville> Which will introduce massive changes
[10:28] <cody-somerville> Massive, untested, changes
[10:28] <slangasek> I'm going to go with option C
[10:28] <cody-somerville> is that all of the above?
[10:28] <slangasek> I don't know what it is yet, but I'm assuming it's better than the other two ;)
[10:28]  * persia removes the Java considerations from any influence on SRU: that's only interesting for intrepid.
[10:29] <cody-somerville> I thought Java stuff was fixed in hardy?
[10:29] <persia> cody-somerville: For some JREs (the ones for which we have source).
[10:30] <persia> slangasek: Is there a handy tool that generates the list of CD-inclusive packages, or is it just the union of the various seeds for the various derivatives?
[10:30] <slangasek> persia: the latter
[10:31] <persia> slangasek: Ah.  Thanks in advance for your difficult and patient processing of the hardy-proposed queue :)
[10:32] <slangasek> heh :-)
[10:33] <cody-somerville> slangasek, fyi, upstream thought disabling xcb in Hardy was the best way to go.
[11:02] <mvo> BenC: removing-old-kernels looks really excellent!
[11:04] <ion_> https://blueprints.launchpad.net/ubuntu/+spec/removing-old-kernels
[11:04] <wgrant> Thanks ionbotu.
[11:05] <ion_> (Read: “it’s not here, so URL please”)
[11:07]  * mvo was reading https://wiki.ubuntu.com/KernelTeam/removing-old-kernels
[11:07] <ion_> Thanks
[11:09] <ion_> mvo, benc: I suggest making hardlinks instead of copying.
[11:12] <persia> ion_: Can you guarantee it's the same filesystem?
[11:13] <ion_> persia: do_cp() { cp -al "$@" || cp -a "$@"; }
[11:13] <persia> ion_: That works :)
[11:14] <wgrant> It's only copying within /boot and /lib, so it shouldn't be a problem.
[11:14] <ion_> Better make sure to fall back to copying anyway.
[11:14]  * persia has /boot and /lib on different partitions
[11:14] <wgrant> persia: Right, but it's copying within those two, not between them.
[11:15] <persia> Ah.  "within" :)
[11:15] <wgrant> If you have subdirectories of both on different filesystems, you've probably got bigger problems.
[11:15] <ion_> Heh
[11:19] <ogra> rmbl
[11:19] <ogra> did anyone here ever try to use gnome bugzilla through https  ?
[11:26] <ogra> their cert seems *really* boked ... FF complains all the time with popups
[11:31] <TheMuso> cjwatson: With my community hat on, I'm happy to take care of yaboot-installer if you don't have time for it, and if you are ok with me doing it.
[11:39] <cjwatson> TheMuso: I think kirkland was doing it; the first time round his merge was a bit busted, but I need to look at it again
[11:40] <TheMuso> cjwatson: oh ok.
[11:40]  * cjwatson has another look
[11:41] <cjwatson> liw: you might want to look at https://wiki.ubuntu.com/KernelTeam/removing-old-kernels too and see how it relates to your plans
[11:47] <cjwatson> kirkland: how are things going with yaboot-installer, anyway?
[12:18] <doko> asac, pitti: bug #211309: I don't see how the code requires the xulrunner -dev package.
[12:24] <asac> doko: do we really want to support ffox 2?
[12:24] <asac> doko: how do you link? do you use pkg-config?
[12:28] <doko> asac: sure, using xulrunner-1.9
[12:29] <asac> doko: how?
[12:30] <doko> asac: http://launchpadlibrarian.net/15062865/buildlog_ubuntu-hardy-i386.icedtea-gcjwebplugin_1.0-0ubuntu7_FULLYBUILT.txt.gz
[12:31] <asac> doko: how is the MOZILLA check done?
[12:31] <doko> asac: using pkg-config
[12:31] <asac> how?
[12:32] <asac> what .pc file is used?
[12:33] <doko> PKG_CHECK_MODULES(MOZILLA, mozilla-plugin libxul-unstable, [MOZILLA_FOUND=yes], \
[12:33] <doko>   [MOZILLA_FOUND=no])
[12:34] <asac> doko: does it build without libxul-unstable?
[12:34] <doko> asac: no, we had this discussion last year ...
[12:34] <asac> cant remember
[12:35] <asac> and using firefox-2-dev doesnt work either?
[12:36] <doko> asac: for both firefox2 and firefox3?
[12:38] <asac> doko: ah right. since its xpcom and we dont have the glue files in firefox 2, we cannot build it for both at the same time
[12:38] <asac> doko: i would just invalidate that bug if i was you
[12:39] <asac> otherwise we might need a SRU for firefox-2 to provide the complete sdk
[12:39] <doko> hurray for sane packaging ;-p ok, will do that
[12:40] <asac> doko: well. i didnt't put much work into that for obvious reasons
[12:41] <asac> and iirc we already discussed that we cannot do it :)
[12:44] <liw> cjwatson, yeah, that page is on my todo list
[12:49] <ogra> asac, https://bugs.gnome.org/show_bug.cgi?id=359592 is there a way to avoid getting a popup about the ssl cert on *every* action ?
[12:50] <ogra> i even get it if i switch to a differnt tab
[12:54] <asac> ogra: i dont get a ssl cert popup except for the first time
[12:56] <ogra> i get a sec_error_untrusted_issuer error every time i switch towards or away from the tab
[12:56] <asac> ogra: ok. thats != every action :)=
[12:56]  * asac tries
[12:56] <asac> ogra: nope
[12:56] <asac> ogra: accept cert. stop browser
[12:57] <asac> maybe you never close it (as usual) and some settings need to be safed?
[12:58] <ogra> http://people.ubuntu.com/~ogra/ff-ssl.png
[12:59] <ogra> thats what i get in my face all the time
[12:59] <ogra> and i restarted the browser etc
[13:00] <asac> ogra: yeah. i see that dialog too, but just one time per session
[13:00] <asac> ogra: i think its a bug, but its not as bad as you see it
[13:02] <ogra_> http://people.ubuntu.com/~ogra/ff-ssl.png
[13:02] <ogra_> thats what i get in my face all the time
[13:02] <ogra_> and i restarted the browser etc
[13:02] <asac> ogra: got that
[13:02] <asac> 14:00 < asac> ogra: yeah. i see that dialog too, but just one time per session
[13:02] <asac> 14:00 < asac> ogra: i think its a bug, but its not as bad as you see it
[13:02] <ogra_> good, i wasnt sure
[13:03] <ogra_> well, i'll switch to non https for gnome in the future ... its just so heavily in your face
[13:03] <asac> I have to do something else today. remind me tomorrow and I'll try to figure figure whats going on.
[13:03] <ogra_> it wont make 8.04.1 anyway, i guess we have time to look at it :)
[13:04] <asac> ogra_: yeah. if it re-pops up everytime its pretty annoying i presume
[13:04] <asac> ogra_: most likely not. but you never know :)
[13:04] <ogra_> right, as i said no prob to switch to http instead ...
[13:05] <ogra_> i rarely put confidential data in public bugtrackers anyway, no real need for https
[13:05] <ogra_> :)
[13:05] <ogra_> and i mean, in the end gnome should just fix their cert :)
[13:05]  * asac applaudes
[13:10]  * ogra scratches head about the tuxtype package ... the only diff i have are two translations there, no code or packaging diffs ... 
[13:11] <mvo> ogra: then sync it :P
[13:12] <ogra> well, i dont want to lose the translations (and dont want to upset translators), i guess i'll file a debian bug and attach them so holger can pull them in
[13:12] <cjwatson> anyone want to take my netbase merge?
[13:13] <cjwatson> oh, hey, Reinhard already caused himself to be assigned to it :-)
[13:13] <ogra> is it big ? apart from ltsp i'm nearly done
[13:13] <cjwatson> shouldn't be too bad
[13:13] <ogra> tedg, how about xscreensaver ?
[13:14] <ogra> its idling on MOM since a while :)
[13:14] <mvo> ogra: yes
[13:14] <mvo> ogra: I'm poking it right now
[13:14] <ogra> mvo, xss ?
[13:14] <mvo> should be good again
[13:14] <ogra> good
[13:14] <mvo> oh, sorry
[13:14] <mvo> I mean mom was ideling for a day or so
[13:14] <mvo> now its updated again
[13:14] <ogra> ah
[13:14] <siretart> cjwatson: wh00ps. I guess I need to do it then ;)
[13:15] <tedg> tedg: ?
[13:15] <tedg> ogra: ?
[13:15] <tedg> (wow, that was funny)
[13:15] <ogra> tedg, http://merges.ubuntu.com/x/xscreensaver/REPORT
[13:16] <tedg> ogra: Would you sponsor it from my PPA?
[13:17] <ogra> sure, got something there already ? else ping me if its ready for upload
[13:18] <tedg> tedg: Yeah, it's there already.
[13:18] <ogra> oh, https://launchpad.net/~tedg isnt you it seems :)
[13:18] <tedg> ogra: https://edge.launchpad.net/~ted-gould/+archive
[13:18] <tedg> ogra: Can one get an alias in LP?
[13:18] <ogra> yup, there now
[13:19] <mvo> there is a sponsoring request for xss in dholbach page too
[13:19] <mvo> (just fyi)
[13:20] <tedg> Yeah, I'm trying to figure out how that guy didn't have problems with the Debian and Ubuntu URL patch.
[13:20] <ogra> mvo, right, but without having bene assigned to ted for a while, i am (and want to be) just the upload bitch :)
[13:21] <ogra> *been
[13:21] <seb128> ogra: GNOME doesn't use broken certs?
[13:22] <ogra> seb128, bugzilla tells me so, see the screenshot ...
[13:22] <seb128> never had a such issue and I use bugzilla daily
[13:23] <ogra> seb128, with https or http ?
[13:23] <Ng> it's a self-sign cert
[13:23] <ogra> right
[13:23] <ogra> you have to approve it first anyway
[13:23] <seb128> ogra: dunno, whatever is the default
[13:23] <ogra> but usually it doesnt show any further error messages ... here i get a popup every time i change tabs
[13:24] <seb128> I don't think I ever got a such error messages, but I'm using epiphany-browser and not firefox
[13:28]  * ogra sighs about packages using quilt in the clean target 
[13:28] <cjwatson> ogra: just wanted to draw your attention to bug 242315 - sorry about the mess there
[13:30] <ogra> cjwatson, i commented, the op fixes seem to be in debin
[13:30] <ogra> *po
[13:30] <ogra> *debian
[13:30] <ogra> *sigh*
[13:30] <MacSlow> in a package I've to merge I've in the ubuntu-variant: (= ${Source-Version}) and in the debian-variant: (= ${binary:Version})
[13:30] <cjwatson> ogra: I didn't see them in the new debian/rules; were they done in the upstream source instead?
[13:31] <cjwatson> MacSlow: the Debian variant is superior
[13:31] <ogra> hmm, i saw them in rules, wrid
[13:31] <MacSlow> cjwatson, ah ok thanks
[13:31] <ogra> *weird
[13:31]  * ogra checks again
[13:32] <cjwatson> definitely not there
[13:33] <ogra> hum
[13:33] <ogra> (sorry my line is maxed out with the xss upload ... takes a min)
[13:35] <MacSlow> Does each dpatch-based patch have to start with a unique ordinal number?
[13:35] <cjwatson> MacSlow: (further information in the deb-substvars(5) manual page)
[13:35] <cjwatson> (for Source-Version et al)
[13:35] <doko> pitti: what does your comment for the bonnie++ sync mean? it's not yet synced
[13:37] <cjwatson> doko: looks like the start of an abortive sync run; i.e. something went wrong with the bot
[13:37] <cjwatson> doko: oh, I know. the Debian version is less than the current Ubuntu version
[13:38] <cjwatson> 1.03c+nmu1 < 1.03ubuntu1 - so we can't sync, you have to invent a version number and merge. I think the nearest we have to best practice is 1.03ubuntu2, merge the changelog, and explanatory comment
[13:38] <doko> argh ... yeah for a "debian native" tarball
[13:39] <cjwatson> doko: looks like your merge in hardy should have been 1.03bubuntu1, not 1.03ubuntu1
[13:42] <doko> cjwatson: hmm, no, it was 1.03aubuntu1
[13:42] <cjwatson> doko: no, that was the gutsy merge
[13:42] <cjwatson> I'm looking at the changelog right now ;-)
[13:42] <cjwatson> bonnie++ (1.03ubuntu1) hardy; urgency=low
[13:42] <cjwatson> bonnie++ (1.03b) unstable; urgency=low
[13:42] <cjwatson> bonnie++ (1.03aubuntu1) gutsy; urgency=low
[13:43] <doko> hmm, mom doesn't show this version ...
[13:43] <cjwatson> mom may be confused due to Ubuntu being newer
[13:43] <cjwatson> but that's what's in the archive
[13:44]  * doko merges ...
[13:44] <cjwatson> (cf. https://launchpad.net/ubuntu/+source/bonnie++)
[13:46] <cjwatson> soren: mind if I merge console-tools?
[13:46] <soren> Not at all.
[13:46] <soren> In fact, I'd appreciate it if you did :)
[13:46] <soren> Thanks.
[13:47] <cjwatson> it's a clean merge anyhow
[13:49] <asac> ogra: intrepid or hardy?
[13:50] <ogra> asac, hardy
[13:50] <Ng> top
[13:50] <Ng> bah
[13:51]  * Ng curses thinkpad trackpoints for their wandering pointer syndrome
[13:51] <ion_> I have had no problems with them.
[13:52] <Ng> both of mine will just wander off in a straight line for a few seconds every now and then
[13:52] <Ng> which is great when you have sloppy focus and don't realise ;)
[13:52] <ion_> Funny. I have never encountered that.
[13:53] <Spads> I've run into it pretty often
[13:53] <ogra> Ng, that only gets intresting at password input :)
[13:53] <Spads> that's why I stick to the touchpad for switching focus
[13:54] <Ng> ogra: I'm pretty paranoid about that, thankfully :)
[13:57] <tedg> Spads: How do you have the touchpad change focus independent of the trackpointer?
[13:58] <mvo> mine too
[13:58] <Spads> tedg: I don't.  I just don't move the trackpointer because it will wander after
[14:00]  * tedg is trying to come up with some mischief based on this new information... I need a blowgun...
[14:03] <asac> ogra: give the latest nss a try from my ppa
[14:03] <asac> ogra: https://edge.launchpad.net/~asac/+archive
[14:03] <asac> (hardy)
[14:04] <ogra> will do
[14:26] <BenC> ion_: It already is making hard links :)
[14:27] <ion_> benc: Alright, good.
[14:29] <BenC> ion_: And the good thing is, depmod and update-initramfs unlink before updating, so there's no chance of modifying what's in last-good-boot
[14:33] <ion_> benc: Wouldn’t it be better to write to a temporary file and then move it over the old one instead of unlinking and then writing?
[14:34] <BenC> ion_: If depmod did that, it would taint the files I've saved in last-good-boot
[14:34] <BenC> So no, that would not be better
[14:35] <BenC> But I assume you meant, write a tmp file, unlink and rename, which is what happens
[14:35] <ion_> benc: Ah, i misunderstood.
[14:35] <BenC> but the point was that with hardlinks, I had to make sure programs that modified the files I saved away didn't overwrite them
[14:37] <ion_> Yeah
[14:52] <dholbach> seb128: is your stock-reply script the 'newest one' or is somebody maintaining their version of it more actively?
[14:53] <seb128> dholbach: mine is all but the newest one, I didn't change it since the oslo sprint
[14:53] <dholbach> OK :)
[14:53] <seb128> dholbach: kees wrote a nice one where you can add entries directly in the webbrowser, etc but when I tried it was not working under epiphany-browser so I stayed on my version
[14:53] <dholbach> seb128: right now it's the only one I can find
[15:03] <seb128> james_w: hi, will you do the gnome-system-tools merge or should I look at it?
[15:04] <kirkland> TheMuso: yeah, i started yaboot-installer, but didn't finish it...  cjwatson gave me some great feedback, but I hadn't gotten a chance to pick it back up
[15:04] <TheMuso> kirkland: Ok.
[15:04] <james_w> seb128: hi, I started to take a look the other day, but it was a bit larger than I had time for then. I'm happy to look again if you are busy with other things.
[15:05] <kirkland> TheMuso: I'll forward you cjwatson's review, if you'd like
[15:05] <seb128> james_w: let's say that I'm not looking for extra work at the moment so if you want to look at it you are really welcome ;-)
[15:05] <TheMuso> kirkland: If you don't have time to go through with finishing it, sure I'll have a poke, that might be useful, in case there is something I need to be aware of.
[15:06] <james_w> seb128: sure, I'll get to it once I've finished my current task, hopefully today.
[15:06] <mvo> doko: do you mind if I take the opensp merge?
[15:06] <seb128> thanks
[15:06] <seb128> james_w: there is no hurry, any time this week will be alright
[15:06] <cjwatson> TheMuso: feel free to just upload once you're done
[15:07] <kirkland> TheMuso: sent
[15:07] <TheMuso> cjwatson: Ok, it won't e tonight now, but I'll get to it tomorrow evening. :)
[15:07] <TheMuso> kirkland: Thanks.
[15:09] <doko> mvo: please go ahead, working through my outstanding merges from the bottom of the list
[15:10] <mvo> doko: thanks
[15:16] <mvo> doko: you can remove "recode" from your list too, its a sync (I just filed a request)
[15:25] <kirkland> TheMuso: hey, if you won't be offended, I'll take another crack at the yaboot-installer merge and run it by you.  That's the only merge I've attempted using bzr rather than deb, and cjwatson pointed out a few fundamental things I did wrong.
[15:25] <TheMuso> kirkland: I'm easy. I don't remember seeing a bzr branch for it anywhere...
[15:28] <seb128> mvo: what syncs are you looking at?
[15:28] <pitti> Riddell: does KDE use PolicyKit anywhere?
[15:29] <seb128> doko: you can remove scim-anthy from your list too
[15:31] <mvo> seb128: I can not do syncs myself, but I just requested one for recode (not urgent at all)
[15:31] <cjwatson> already processed
[15:32] <mvo> woah, thanks :)
[15:33] <Riddell> pitti: no :(
[15:33] <pitti> Riddell: oh, hm; I'm just changing jockey to use PK
[15:34] <wgrant> Package, Policy, or somethingelse, Kit?
[15:34] <pitti> Riddell: however, if jockey-kde just continues to run as root, that will be transparent
[15:34] <pitti> wgrant: both actually eventually, but PolicyKit for now
[15:34] <pitti> I moved the backend bits into a D-BUS service
[15:34] <wgrant> Right, I thought both would be applicable.
[15:34] <pitti> since with the current version some bits are really awkward
[15:34] <Riddell> pitti: so ideally it would use some kde policykit thing and work properly?
[15:49] <pitti> re (sorry, doorbell)
[15:50] <pitti> Riddell: the only thing which is really necessary is the "authentication agent"
[15:50] <pitti> Riddell: i. e. the thing which presents which auth is requested and asks for your password
[15:50] <pitti> Riddell: http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html has some screenshots
[15:50] <pitti> Riddell: the rest is UI independent (all just D-BUS services)
[15:51] <pitti> Riddell: but if the frontend continues to run as root for now, the dialog is not necessary
[15:51] <pitti> since root already has all possible PK privileges implicitly
[15:51] <pitti> Riddell: (policykit-kde would be a nice bounty or GSoc project, I think)
[15:52] <pitti> back in 30 mins
[15:57] <dholbach> bryce, soren: did you get any weird bug reports about the mouse cursor just moving in the top left 50x20 pixels in an intrepid KVM guest?
[15:58] <asac> ogra: could you test?
[15:58] <dholbach> it feels like the map of mouse movement is scaled from 1024x800 (or whatever it is) to 50x20 (or whatever it is)
[15:58] <dholbach> it sucks :)
[15:58] <soren> dholbach: Not that I've noticed. That doesn't mean they aren't there, though. I'm still way behind on LP bug mail.
[15:58] <ogra> asorry had a long phonecall and some other cleanup to do afterwards, i'll test it right now, gimme a min to update
[15:59] <ogra> asac, ^^^
[16:00] <dholbach> soren: do you think it'd make sense to compare an intrepid xorg.log of a working guest with my broken one?
[16:00] <tkamppeter> Someone here who knows about svn-buildpackage and the Perl infrastructure?
[16:00] <asac> ogra: thx
[16:01] <jclinton> does Ubuntu have an equivalent of the NMU process?
[16:02] <jclinton> i'm Gnome Games upstream maintainer and we're drowning under duplicates generated from a bug in Ubuntu's version of python-support
[16:02] <jclinton> debian's copy was patched this morning
[16:02] <jclinton> hoping someone in Ubuntu can get the fix in today
[16:02] <seb128> jclinton: the intrepid ubuntu version has been fixed by mvo too I think
[16:02] <ogra> asac, hmm, it forgot about the cert completely now, i have to re-allow it
[16:02] <dholbach> jclinton: https://wiki.ubuntu.com/SponsorshipProcess explains how to get a fix uploaded
[16:02] <jclinton> seb128: the drowning is coming from hardy users
[16:03] <jclinton> dholbach: i'm not an ubuntu dev
[16:03] <asac> jclinton: we dont need a term for that as we are not maintainer focussed, we work in teams and its considered an exceptional procedure to upload a package you havent touched before
[16:03] <ogra> asac, and the popup is gone :)
[16:03] <asac> ogra: funny
[16:03] <asac> ogra: can you please file a bug so we can get this "crash" fix into 8.04.1?
[16:03] <seb128> jclinton: that is not going to be fixed quickly, hardy updates are frozen for 8.04.1 and it usually take a least one week for an update to be tested, etc before being actually moved to hardy-updates
[16:03] <Lightkey> jclinton!
[16:03] <ogra> asac, will do
[16:03]  * Lightkey goes to play another round of GNOME Mines :-D
[16:04] <dholbach> jclinton: right - it explains how to get a fix uploaded if you're not part of the ubuntu-dev team
[16:04] <asac> ogra: let me know
[16:04] <jclinton> alright, i'll just have gnome bugzilla maintainers blacklist the bug reports from ubuntu then
[16:04] <seb128> jclinton: what are the upstream and ubuntu bug numbers for the issue?
[16:05] <jclinton> seb128: i'll grab, a moment
[16:05] <seb128> jclinton: you can still try, I doubt they will do that ;-)
[16:05] <wgrant> It was a pretty impressively long bug when I saw it a few hours ago.
[16:05] <seb128> well, as always when bug-buddy send duplicates
[16:05] <seb128> we stop it for C program but nobody adapted the python code to do that
[16:06] <jclinton> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=524665 and http://bugs.debian.org/486516
[16:07] <jclinton> seb128: we have an autoreject policy for bugbuddy
[16:07] <jclinton> seb128: it's a pain to do it and its not perfered but this kind of case is why its there
[16:07] <seb128> jclinton: right, I know how the GNOME bugzilla works, you can add bugs to the autoreject list
[16:07] <seb128> jclinton: but the criterious is on the bug content, not the distribution
[16:07] <cjwatson> is this a regression from hardy in hardy-updates?
[16:08] <jclinton> seb128: right
[16:08] <jclinton> cjwatson: yes
[16:08] <cjwatson> how can that be? glchess and python-support are not in hardy-updates
[16:08] <seb128> cjwatson: not likely, python-support didn't change there
[16:08] <jclinton> cjwatson: sorry i mean to say that python-support's unstable version is in hardy
[16:08] <cjwatson> although gnome-games is newer in hardy-updates
[16:09] <seb128> wgrant: oh, 100 duplicates is a small count
[16:09] <cjwatson> jclinton: the bug appears to have been introduced by python-support's triggers support, which is not in hardy
[16:09] <ogra> asac, bug 242379 for you
[16:09] <seb128> I doubt that's the same bug
[16:09] <cjwatson> python-support | 0.7.5ubuntu1 |         hardy | source, all
[16:09] <seb128> what cjwatson said
[16:10] <cjwatson> if there is a regression from hardy to hardy-updates, it should be fixed regardless of the freeze
[16:10] <jclinton> there are two ubuntu users there confirm that it is in hardy
[16:10] <cjwatson> bear in mind that Ubuntu users may have deliberately chosen to upgrade parts of their system to intrepid but not said so
[16:10] <cjwatson> the version of Ubuntu they supply in bug reports basically only confirms the version of base-files
[16:11] <jclinton> hrm... and bugbuddy can't collect that information...
[16:11] <seb128> the bug has been opened upstream on 2008-03-27
[16:11] <seb128> so I doubt that's a regression
[16:11] <seb128> and there is not an increase in the duplicates
[16:12] <seb128> in the duplicates rate rather
[16:12] <jclinton> so, since i'm not an ubuntu user, what does someone have to do to install glchess right now? (which should have been removed from the repos two years ago)
[16:13] <jclinton> do they have to install parts of intrepid?
[16:13] <seb128> jclinton: and we don't package glchess out of gnome-games
[16:13] <jclinton> seb128: it was standalone before it was part of gnome-games
[16:13] <wgrant> seb128: We do...
[16:13] <wgrant> !info glchess hardy
[16:14] <stgraber> synced from debian, same version in the archive since gutsy it seems
[16:14] <seb128> wgrant: we don't split the gnome-games version out I meant
[16:14] <cjwatson> glchess is still in Debian unstable too
[16:14] <jclinton> yea, working on that one in those channels, also
[16:15] <jclinton> but in any event, it should cause the insanity with python-support even if they are both in the repos
[16:15] <jclinton> shouldn't*
[16:16] <seb128> glchess and gnome-games have packaging conflicts
[16:16] <seb128> you can't install glchess if you have gnome-games installed
[16:16] <jclinton> seb128: right
[16:16] <seb128> so I doubt those users are using the glchess universe package
[16:16] <jclinton> seb128: the problem is when glchess is uninstalled and gnome-games is installed in the same apt transaction
[16:16] <jclinton> seb128: they are
[16:17] <seb128> are you sure?
[16:17] <jclinton> seb128: yes
[16:17] <jclinton> i've recreated the same thing in debian unstable and have two confirmations from ubuntu hardy users
[16:17] <seb128> I'm not sure why so many users would like to install glchess when it's already installed as part of gnome-games
[16:17] <doko> seb128: will we demote scrollkeeper for intrepid?
[16:17] <seb128> doko: likely yes
[16:17] <jclinton> seb128: because our 3d is broken because of an xorg driver fuckery
[16:18] <jclinton> seb128: they are almost certainly trying to get 3d to work
[16:18] <seb128>   File "/usr/sbin/update-python-modules", line 125, in install_modules_func
[16:18] <seb128>     raise "Trying to overwrite %s which is already provided by %s"%(os.path.join(dir,file),otherdir)
[16:18] <seb128> Trying to overwrite glchess/game.py which is already provided by /usr/share/python-support/gnome-games-data
[16:18] <seb128> urg
[16:18] <jclinton> yep
[16:18] <seb128> glchess doesn't install on hardy for me
[16:19] <jclinton> you have to do it manually to go TO glchess
[16:19]  * ogra hugs seb128 frantically, reading that scrollkeeper answer 
[16:19] <jclinton> but doing it in reverse works
[16:19] <seb128> ogra: ;-)
[16:19] <seb128> jclinton: I've tried to sudo apt-get install glchess and I run into this issue
[16:20] <jclinton> seb128: i'm getting exhausted defending my claim that this really is a bug in ubuntu; if you don't want to believe me i'll just resort to the blacklisting method
[16:20] <seb128> jclinton: heh, calm down, I don't deny anything, I'm just trying to understand the issue
[16:21] <jclinton> seb128: i am happy to provide you with any information that i have
[16:21] <seb128> jclinton: you come here, say that the has to be fixed today or you will reject ubuntu bugs and point to a python-support bug which doesn't concern the hardy version
[16:21] <seb128> jclinton: I can understand you are frustrated by the issue but let's try to be constructive
[16:21] <jclinton> seb128: hold and i'll show you why it does
[16:21] <jclinton> seb128: a moment
[16:21] <siretart> cjwatson: netbase merged, ifupdown has had an "cleanup" NMU upload only, so I don't plan to work on that
[16:22] <seb128> jclinton: having a testcase would be nice
[16:22] <seb128> jclinton: I don't get why the standalone glchess bugs would go to bugzilla.gnome.org
[16:22] <seb128> if those users are really installing the glchess package you should get no bug
[16:27] <jclinton> seb128: still getting you the info but the bug happens after they install glchess and discover that its worse and decide to go back to gnome-games
[16:28] <dholbach> can anybody give me their Xorg.0.log of a working KVM intrepid guest?
[16:29] <seb128> jclinton: I did install glchess and gnome-games back on my hardy system and I didn't get the bug, maybe there is some extra steps required ...
[16:29] <jclinton> seb128: so perhaps these people really do have parts of intrepid installed?
[16:29] <seb128> no
[16:30] <seb128> the bugzilla bug has been opened before hardy
[16:30] <seb128> and there is most like a python-support issue somewhere, but not sure how to trigger it
[16:30] <jclinton> seb128: the first half of the bug was our own stupidity
[16:30] <seb128> ah
[16:30] <jclinton> seb128: that was fixed in ubuntu's upload of 2.22.2.1
[16:31] <seb128> looking at some recents duplicates now
[16:33] <jclinton> seb128: i /think/ this is the root cause: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446730
[16:33] <jclinton> seb128: the 'fix' was uploaded to debian in 0.7.5
[16:33] <jclinton> seb128: which may or may not be part of the ubuntu version
[16:34] <seb128> hardy has 0.7.5 yes
[16:34] <jclinton> seb128: either way the fix points to a more fundamental problem with python module overwrites
[16:36] <seb128> ok, I managed to get the bug
[16:36] <seb128> that's a corner case
[16:36] <jclinton> for my own edification, what did you have to do?
[16:37] <seb128> have gnome-games installed
[16:37] <seb128> sudo apt-get install glchess
[16:37] <seb128> there is a file conflict between this one and gnome-games-data but gnome-games-data doesn't get remove because the packaging conflict is only on gnome-games
[16:37] <seb128> so you are in a broken installation state
[16:38] <jclinton> seb128: ah; someone doing this via synaptic would have no idea?
[16:38] <seb128> on the first try I remove gnome-games-data to have the packaging system in a consitant state
[16:38] <seb128> and reinstalled gnome-games
[16:38] <seb128> if you reinstall gnome-games directly you are screwed
[16:38] <seb128> right
[16:38] <jclinton> seb128: ok i can file a bug against gnome-games in launchpad for the conflict
[16:38] <seb128> or they would get an installation error but can revert to gnome-games
[16:39] <seb128> jclinton: would be nice, I'll do a sru adding the conflict
[16:39]  * mvo hugs seb128 for finding this error
[16:39] <jclinton> seb128: but really glchess should not be in the repos
[16:39] <seb128> sru = stable update
[16:39] <jclinton> ok awesome
[16:39] <seb128> jclinton: well, it's there because some people might want it and not the whole gnome-games, it's coming from debian
[16:39] <seb128> you can try to convince them they should not have it
[16:40] <seb128> but everybody is not a GNOME user ;-)
[16:41] <jclinton> seb128: looks like theres already a few dups of this in your LP
[16:41] <jclinton> seb128: i'll get you the oldest
[16:41] <seb128> jclinton: thanks
[16:42] <jclinton> seb128: https://bugs.launchpad.net/ubuntu/+source/glchess/+bug/138509
[16:42] <jclinton> seb128: i see 6 other dups; i'll marks then as such
[16:42] <seb128> jclinton: this one is fixed in fact
[16:43] <seb128> jclinton: gnome-games Conflicts on glchess
[16:43] <seb128> the issue is gnome-games-data now
[16:43] <seb128> (the .desktop are in gnome-games)
[16:45] <jclinton> seb128: but glchess should conflict with gnome-games-data dont we agree?
[16:45] <seb128> jclinton: yes
[16:46] <seb128> jclinton: in fact I'll change gnome-games-data rather
[16:46] <seb128> to make it conflict on glchess
[16:47] <jclinton> seb128: ok
[16:47] <MacSlow> I've a merge-related question...
[16:47] <seb128> jclinton: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-games/+bug/234865
[16:47] <seb128> jclinton: I'll use this bug
[16:47] <MacSlow> in the REPORT for planner files debian/control and debian/control.in are marked to need work
[16:48] <MacSlow> but <something>.in is the template from  which <something> is generated
[16:48] <seb128> MacSlow: control is autogenerated when doing clean
[16:48] <ogra> usually
[16:48] <MacSlow> do I really have to touch both?
[16:48] <jclinton> seb128: ok
[16:48] <seb128> MacSlow: no, just the control.in
[16:48] <ogra> MacSlow, i usualy only change .in
[16:48] <MacSlow> seb128, ok... just needed assurance
[16:48] <ogra> but do a testbuild to confirnm its really used
[16:49]  * ogra had packages with ,in files that werent in the past
[16:49] <seb128> jclinton: thanks for your help on the issue, the fix will be uploaded today
[16:49] <MacSlow> ogra, I've a pbuilder environment setup by now and tend to use that before I "upload" (read: ask you folks for sponsorship)
[16:49] <jclinton> seb128: and thank you as well, especially for your patience
[16:49] <jclinton> seb128: much appreciated
[16:50] <seb128> always happy to work with upstream and fix issues ;-)
[17:09] <seb128> doko: ups, I synced scim-hangul a bit quickly, there was still an ubuntu change, you might want to do the merge still ;-) (or I'll fix it later but I've to go for sport soon)
[17:11] <doko> seb128: I did ask ArneGoet1e to merge the scim-* packages, I'm not doing those today
[17:13] <seb128> doko: ok, thanks
[17:13] <seb128> ArneGoet1e: ^
[18:41] <ogra> Keybuk, do i understand right that 70-persistent-net.rules replaces iftab nowadays ?
[18:41] <ogra> (i have an edubuntu user where the devices seem to flip around on every boot)
[18:51] <ion_> ogra: AFAIK yes.
[19:01] <zul> jcastro: ping
[19:01] <jcastro> zul: pong
[19:02] <zul> jcastro: can you register bugs.mysql.com into launchpad?
[19:02] <jcastro> zul: certainly
[19:02] <zul> jcastro: thank you
[19:02]  * ogra thoguht they switched to LP
[19:02] <ogra> why didnt they switch the bugtracker as well ?
[19:03] <jcastro> hmm, what kind of bugtracker is it?
[19:04] <zul> jcastro: its based on the php.net one
[19:04] <jcastro> does lp support it?
[19:05] <zul> I dunno :)
[19:05] <jcastro> https://bugs.edge.launchpad.net/malone/+bug/74449
[19:05] <zul> merci buckets
[19:50] <Tyrone_man> Hey everyone, just checking in to let you know that virtual machine install from yesterdays alt-i386 iso was a no go. Missing the generic restricted kernel package
[20:30] <kirkland> soren: one other weakness in the regexes is that they both require that the path is double-quoted
[20:30] <kirkland> soren: is that a big deal to you?
[20:32] <soren> kirkland: Only a bit.
[20:34] <kirkland> soren: this works better: echo PATH=\"~/bin:blah\" | grep "^PATH=.*[:\"]~/bin[:\"]"
[20:34] <kirkland> soren: well, see the regex at the end of that cut-n-pastable test
[20:36] <kirkland> soren: actually, I could strip the quotes out with a first sed
[20:36] <kirkland> soren: and put them back in with a second one
[20:37] <kirkland> soren: hmm, but i don't like that...  makes the sed -i inline bit wierd
[20:39] <kirkland> soren: so are you still in favor of prepending, or are you comfortable with appending in both new installs and upgrades?
[20:39] <soren> "^PATH="?(~/bin|.*:~/bin)[:$\"]\"?" perhaps?
[20:40] <soren> kirkland: Well, I would have said prepend, but Jamie has a good point in the ~/bin/ls attack. It's a long shot, but that's the case for most vulnerabilities.
[20:41] <kirkland> soren: right
[20:41] <jdstrand> not to mention, people can use 'alias' if the want to override a system command
[20:41] <kirkland> soren: ~/bin/ls was my reasoning for the safe/conservative approach
[20:41] <soren> Hehh.
[20:41] <soren> Although, .bashrc prepends it.
[20:42] <slangasek> I think it's fairly typical to want to prepend
[20:43] <jdstrand> hmm, I don't like it
[20:43] <slangasek> having the system directories listed first to prevent a command being overridden doesn't buy you any security - who has write access to your ~/bin directory that doesn't also have write access to your .bashrc
[20:43] <jdstrand> but I setup my PATH on my own, and wasn't aware that there was precedent for prepending
[20:43] <slangasek> ?
[20:44] <sbeattie> even without security considerations, if you have buggy scripts that don't fully list pathnames, you can get weird errors due to name collisions with scripts in ~/bin/
[20:45] <slangasek> true, but that's a "so don't write buggy scripts then" :)
[20:45] <sbeattie> Uh, yeah, "don't write buggy software" is working so well for our underworked security team. :-)
[20:46] <slangasek> hey, the security team doesn't have to support anything users put in ~/bin >:)
[20:46] <jdstrand> heh
[20:48] <jdstrand> slangasek: while technically you are correct regarding writable .bashrc vs prepended ~/bin, I think certain attacks may find ~/bin more interesting or easier to implement than .bashrc edits, but that gets us into an even less likely scenario
[20:49] <jdstrand> slangasek: not to mention that .bashrc already does it, so if we don't in /etc/environment, that is inconsistent
[20:49] <kees> .bashrc already does it?
[20:49] <sbeattie> slangasek: sure, but you can waste a lot of time figuring out that something is broken due to that issue, even if in the end you get to say "not my problem". Not that I'm speaking from experience here.
[20:50] <jdstrand> kees: soren said yes
[20:50] <jdstrand> I'm looking into it
[20:50] <kees> jdstrand: where?
[20:50] <kees> or rather
[20:50] <kees> soren: where does ~/bin go into bashrc on a default system?
[20:50] <kees> I don't see it in /etc/skell or /etc/bash.bashrc
[20:51] <jdstrand> kees: .profile
[20:51] <jdstrand> ./.profile:    PATH="$HOME/bin:$PATH"
[20:51] <jdstrand> that's in /etc/skel
[20:51] <kees> yeowza
[20:52] <kees> kirkaldn actually... would that work better than ~ ($HOME)
[20:52] <kees> hm
[20:52] <kees> kirkland: ^^ (I can't type)
[20:52] <kees> yay I have my ~bin in two places in my path.
[20:53] <sbeattie> kees: since you're underemployed, do you think someday /etc/skel/ could contain tmp/ ?
[20:53] <kirkland> kees: hmm, i ran into a couple of issues in my testing, when using $HOME/bin in /etc/environment
[20:54] <sbeattie> kees: hah! I have /opt/wabi/bin in my path, I haven't used wabi in a good 10 years.
[20:54] <kees> sbeattie: afaik, it's been a xdg (or maybe just fedora?) plan to have per-user tmp dirs
[20:54] <soren> kirkland: Sorry, I have a few things around the house I need to handle....
[20:54] <jdstrand> heh-- apparently I noticed this at some point-- I commented it out of my ~/.profile
[20:54] <kirkland> soren: okay, i couldn't get your suggested regex to work correctly
[20:55]  * kees holds his head
[20:55] <kees> argh path
[20:55] <kees> this is pretty goofy
[20:56] <kees> should we _remove_ the .profile prepending?  This really smells like it needs a full spec
[20:56] <kirkland> sorry to stir up another pooh storm :-)
[20:56] <jdstrand> well, I certainly am n favor of it
[20:56] <kirkland> automatically prepending ~/bin seems all around dangerous
[20:57] <kirkland> willing and knowledgable users can certainly do so
[20:57] <kirkland> but if we're going to set this up automatically for users (as I am in favor of), I'd think appending would be the safest way to go
[20:58] <slangasek> I believe the difference between safest and unsafest here is trivial
[20:58] <slangasek> whereas the difference in convenience may be substantial
[20:59] <jdstrand> honestly, from a usability point of view, I think that we must be consistent
[21:01] <kirkland> jdstrand: what does that mean?
[21:01] <jdstrand> it looks like it happened way back in 2.04-6 or so
[21:02] <jdstrand> kirkland: it means we should be consistent with .profile, otherwise the patch doesn't work right (ie you still don't get the same environment you are striving for)
[21:02] <kirkland> jdstrand: okay
[21:02] <jdstrand> debian bug #67714 references it as recently changing
[21:02] <jdstrand> that was back in 2000 :)
[21:03] <jdstrand> perhaps that is when I noticed it, and changed it in my own .profile ;)
[21:04] <jdstrand> hey, that was on the beloved woody
[21:05] <kirkland> jdstrand: i agree with your comment for consistency
[21:05] <kirkland> jdstrand: at least between ~/.profile and /etc/environment
[21:05]  * jdstrand nods
[21:22] <slangasek> superm1: preliminary mythbuntu CDs are available for 8.04.1 at http://cdimage.ubuntu.com/mythbuntu/hardy/current/, if you would care to give them a smoke test
[21:24] <mario_limonciell> laga, ^ if you've got a few cycles.  otherwise i'll give a run tonight or tomorrow night
[21:24] <kirkland> slangasek: mario_limonciell: I have a new mythbuntu box to install... i'll give them a go too....
[21:25] <laga> mario_limonciell: ugh, not tonight, sorry
[21:25] <mario_limonciell> laga, did you update the kernel version in the base seeds?
[21:25] <mario_limonciell> laga, or have you lately?
[21:25] <laga> no
[21:25] <kirkland> slangasek: your url wasn't quite right.... http://cdimage.ubuntu.com/mythbuntu/hardy/daily/current/
[21:25] <mario_limonciell> then most definitely those are broke right now
[21:25] <mario_limonciell> laga, could you commit a fix to the branch for that?
[21:25] <laga> i haven't been doing stuff on the alternate disks since the release. which is a shame.
[21:25] <laga> ya, will do.
[21:26]  * laga hangs his head in shame
[21:26] <slangasek> kirkland: ah yes, sorry
[21:26] <slangasek> I should delegate all URL composition to my browser :)
[21:28] <mario_limonciell> and then kirkland pull tomorrow's disk if you can
[21:28] <mario_limonciell> laga, do you know if Daviey has rolled the new live's yet on hardy?
[21:28] <slangasek> tomorrow's disk?
[21:28] <mario_limonciell> slangasek, they're not dailieis?
[21:28] <kirkland> mario_limonciell: ah, okay
[21:28] <laga> mario_limonciell: -19 is the current kernel, right?
[21:28] <mario_limonciell> yeah
[21:28] <laga> mario_limonciell: no clue about daviey
[21:28]  * kirkland cancels his current download at 40%
[21:28] <slangasek> mario_limonciell: they're not being built on a daily basis, no
[21:29] <mario_limonciell> slangasek, oh.  well after laga commits the change for the kernel bump, can you queue up one more?
[21:29] <slangasek> mario_limonciell: sure
[21:29] <mario_limonciell> thanks
[21:29] <kirkland> mario_limonciell: ping/remind me when new iso's go up and i'll test them out
[21:29] <mario_limonciell> okay great.  Thanks!
[21:31] <laga> mario_limonciell, slangasek: okay, i've just pushed rev 1183
[21:31] <laga> i think you need to merge it?
[21:32]  * slangasek watches gvfsd-smb-browse suddenly decide not to do Kerberos authentication, and pulls out his hair
[21:33] <slangasek> laga: pushed it to where, please?
[21:33] <Daviey> !test
[21:34] <laga> slangasek: heh, sorry! http://bazaar.launchpad.net/%7Emythbuntu/ubuntu-seeds/platform.hardy/
[21:34] <slangasek> laga: hrm?  what needs to be changed in platform?
[21:34] <slangasek> well, I guess I'll see if I try to merge it :)
[21:35] <laga> slangasek: ah. i guess now comes the part mario_limonciell warned me about.
[21:35] <kirkland> slangasek: jdstrand: soren: kees: so is the consensus then to have the libpam-modules.postinst script *prepend* ~/bin, in order to be consistent with ~/.profile?  And, at the point in which we decide *appending* is better, we'll change both at the same time?
[21:35] <laga> slangasek: we have our own platform.hardy.
[21:35] <laga> slangasek: because we need a different set of packages. or something like that.
[21:35] <jdstrand> kirkland: unfortunately, I think we need to do that for consistency, unless we are prepared to change bash now
[21:35] <slangasek> laga: ummm.  that defeats the purpose of the "platform" seed
[21:35] <kees> I would prefer to start with it correct (appended).
[21:35] <jdstrand> I'd rather change both
[21:35] <slangasek> which is to have a common seed for shared components
[21:36] <mario_limonciell> a problem came up that the platform seed wasn't working when updating the metas
[21:36] <mario_limonciell> and there were extra components in it that weren't desirable afaik
[21:36] <laga> slangasek: yes. i'll let mario_limonciell explain it. he also warned me that you were going to yell at me  ;)
[21:36] <mario_limonciell> haha
[21:36] <slangasek> mario_limonciell: is something already implemented to make the CD building scripts look at this platform seed?
[21:36] <Daviey> and it was leaving crap behind, wasn't it?
[21:36] <jdstrand> kees: that defeats the purpose of kirkland's patch though
[21:36] <mario_limonciell> somehow it gets pulled correctly during build yes slangasek
[21:37] <jdstrand> kees: the problem is ultimately that the enviroments are different-- granted, appending gets it closer, but not the same
[21:37] <mario_limonciell> Daviey, i dont know that it was leaving stuff behind, but a lot of extra stuff got pulled in via it
[21:37] <slangasek> mario_limonciell: because AFAICS, the right way to do this would be to keep a single mythbuntu.$dist repo and just have it not inherit from the platform seeds <shrug>
[21:37] <mario_limonciell> yeah i agree
[21:37] <mario_limonciell> someone had suggested to adopt the platform seed since everyone else was doing it
[21:37] <slangasek> mario_limonciell, laga: anyway, if debian-cd is already looking at this seed, then I shouldn't need to do anything wrt merging
[21:37] <mario_limonciell> and then things started to break
[21:37] <laga> so no merging needs to be done.
[21:37] <jdstrand> kees: I'd like to change bash *and* append in pam
[21:37] <laga> yeah, sorry for the confusion
[21:37] <Daviey> mario_limonciell: ahh, didn't we try and remove the extra stuff or something.. and that was the problem. Geez it was so long ago, i can barely remember
[21:38] <kees> jdstrand: I think that's good
[21:38]  * laga hands out cookies to anyone involved
[21:38] <jdstrand> kees: which is good?
[21:38] <sbeattie> jdstrand: I concur with changing both to append, despite my below zero influence in this matter.
[21:38] <kirkland> jdstrand: kees: okay, so i'll need to form two patches....
[21:38] <jdstrand> sbeattie:
[21:39] <jdstrand>  5
[21:39] <jdstrand> o/
[21:39] <kees> :)
[21:39] <kirkland> jdstrand: kees: an updated one for pam, that APPENDS ~/bin in both the "new install" and "update" case (with the exceptions that soren mentioned)
[21:39] <kirkland> jdstrand: kees: plus a patch to bash that creates a .profile wthat APPENDS ~/bin
[21:40] <jdstrand> kirkland: that is a hearty +1
[21:40] <kees> yeah, sounds right.
[21:40] <jdstrand> I *might* even go 1.5
[21:40]  * kirkland is ready to put this issue to bed and get back to ecryptfs :-)
[21:40] <jdstrand> heh
[21:41] <jdstrand> it always nice getting *everyone* to weigh in on a 4 line patch
[21:41] <jdstrand> it's
[21:41]  * kees mutters about 1 line patches
[21:41] <kirkland> jdstrand: kees: does this need a new LP bug, or shall I continue to use 64064 ?
[21:41] <jdstrand> kirkland: bash needs a new bug
[21:41] <kirkland> jdstrand: okey doke, doing that now
[21:43] <kirkland> kees: one more question...  I see the one-line to be changed in skel.profile ... but again are we concerned about "fixing" this for upgrading users?
[21:45] <jdstrand> kirkland: while you didn't ask me, sed'ing user's .profiles makes me feel a little nauseated
[21:45] <jdstrand> just a little
[21:45] <kirkland> jdstrand: agreed!
[21:45] <jdstrand> kirkland: though it is a good question :)
[21:45] <kirkland> jdstrand: sorry for not addressing you on that one :-)  no offense
[21:46] <kirkland> kees raised it last time
[21:46] <jdstrand> kirkland: none taken
[21:47] <kees> kirkland: er, well, we shouldn't change users's .profiles, but we should deal with /etc/skel/profile in a fashion similar to the pam patch
[21:48]  * jdstrand may have misinterpreted kirkland's question based on kees' response
[21:48] <kees> I saw a few questions, so maybe I'm confused too
[21:48] <kirkland> kees: jdstrand: i think i understand....
[21:49] <kirkland> kees: jdstrand: don't "fix" user's .profiles (I wasn't planning on) ... but do "fix" /etc/skel/profile (which was my question)
[21:49]  * jdstrand feels considerably less nauseated now
[21:50] <kees> right, good.  heh
[21:53] <emgent> congrats ember
[21:53] <emgent> welcome in ubuntu family.
[21:54] <ember> thanks emgent
[21:56] <slangasek> mario_limonciell, laga: new mythbuntu hardy image up
[21:56] <laga> great! kirkland ^^
[21:56] <kirkland> laga: sweet!
[21:56] <mario_limonciell> that was fast
[21:56] <kirkland> no kidding, mario_limonciell
[21:57] <slangasek> well, hopefully I wasn't too fast for seed propagation ;)
[21:58] <mario_limonciell> according to http://cdimages.ubuntu.com/mythbuntu/hardy/daily/20080623.2/hardy-alternate-i386.list looks good to me
[21:59] <mario_limonciell> er why did that show up in bold?
[22:00] <laga> didnt do that here
[22:05] <Caesar> Is there a known issue with the Hardy alternative installer?
[22:06] <Caesar> We're seeing problems downloading installer components
[22:06] <slangasek> the alternate installer should not normally need to download any installer components, it should be self-contained on the CD?
[22:06] <Caesar> PXE boot man
[22:06] <slangasek> ah
[22:07] <Caesar> Today it's complaining about apt-mirror-setup
[22:07] <Caesar> On Friday it was a different udeb
[22:07] <Caesar> We updated the installer today, because I saw someone had respun it
[22:08] <slangasek> apt-mirror-setup has a newer version in hardy-updates; could be a mirror sync issue of some kind?
[22:08] <Caesar> Could be
[22:10] <Caesar> On Friday it was kickseed-common
[22:16] <kirkland> kees: jdstrand: http://pastebin.ubuntu.com/22434/
[22:17]  * kirkland notes that the grep/sed regex is very tight, will only match if the sysadmin has not modified the default value of PATH in /etc/skel/.profile ...  kirkland calls this a "feature".
[22:20] <Tyrone_man> Sorry for interupting, I just tried today's iso for alt-i386, linux-generic doesn't work still, only the specific 2.6.26 kern entry, due to lack of restricted modules, and then pkgselect will not initiate. I can get a booting root shell, but as of yet, no applications
[22:22] <jdstrand> kirkland: so you are only changing it on upgrade if the path is $HOME/bin:$PATH. I like it
[22:22] <jdstrand> kirkland: should the compared bash version be 3.2-0ubuntu18?
[22:22] <jdstrand> dpkg --compare-versions "$2" le 3.2-0ubuntu19
[22:23] <jdstrand> +bash (3.2-0ubuntu19) intrepid; urgency=low
[22:23] <jdstrand> kirkland: or use lt-- I like lt better personally
[22:23] <kirkland> jdstrand: good catch, agreed on lt
[22:25] <Caesar> Is there a way to get more information out of anna about why a udeb retrieval failed?
[22:26] <Caesar> "Loading apt-mirror-setup failed for unknown reasons. Aborting" doesn't really tell you much...
[22:26] <jdstrand> kirkland: stylistic point-- I generally like to separate out the files modified. I think it makes it slightly more clear
[22:26] <jdstrand> kirkland: eg:
[22:26] <kirkland> jdstrand: sure, in the changelog, okay
[22:26] <slangasek> Caesar: I think there should be more information in the logs, which are normally on ttys 3 and 4?
[22:27] <jdstrand> debian/skel.profile: put $HOME/bin at end of path
[22:27] <jdstrand> debian/bash.postinst: <something fairly specific>
[22:27] <jdstrand> kirkland: not that you need to change it now-- but maybe it makes sense to you. I think it makes it easier when merging
[22:28] <Caesar> slangasek: negative
[22:28] <Caesar> It just mentions it's queuing it for download
[22:28] <Caesar> It's quite unhelpful
[22:28] <kirkland> jdstrand: sure... i'll rev another one right now
[22:29] <jdstrand> kirkland: note, when outside of debian/, it is often not required, but in debian/, I think it makes it easier
[22:30] <kirkland> jdstrand: would I mention the (LP: #242479) on both, one, neither?  the first or the second?
[22:30] <kirkland> jdstrand: obviously not "neither" :-P
[22:31] <jdstrand> kirkland: what is the original bug again?
[22:31] <jdstrand> kirkland: (the pam one)
[22:31] <kirkland> jdstrand: https://bugs.edge.launchpad.net/ubuntu/+source/pam/+bug/64064
[22:31] <jdstrand> kirkland: yeah, just the bash one
[22:32] <kirkland> jdstrand: sorry, my question is whether I put it on both lines?  now that there is one for each file I touched?
[22:32] <jdstrand> kirkland: oh, can do:
[22:32] <jdstrand> * References
[22:32] <jdstrand>   LP: #NNNNNN
[22:33] <jdstrand> kirkland: in this case, it's clear cause it's just the one
[22:33] <jdstrand> kirkland: othertimes you can do:
[22:34] <jdstrand> just on the first one
[22:34] <jdstrand> first listed
[22:34] <jdstrand> kirkland: it isn't a hard and fast rule, mind you :)
[22:35] <kirkland> jdstrand: patch updated: http://pastebin.ubuntu.com/22436/
[22:35] <kirkland> jdstrand: if that's good, i'll attach to the bug and perhaps you can sponsor
[22:36] <jdstrand> kirkland: sure no problem
[22:37] <jdstrand> kirkland: I like the text, it's very clear
[22:38] <kirkland> jdstrand: patch attached to https://bugs.edge.launchpad.net/ubuntu/+source/bash/+bug/242479
[22:38] <kirkland> jdstrand: I'll subscribe you
[22:39]  * jdstrand nods
[22:40] <cjwatson> Caesar: you have to use the installer image in hardy-updates
[22:40] <cjwatson> Caesar: the one in dists/hardy became bust once stuff started to be duplicated in hardy-security/updates
[22:42] <kirkland> cjwatson: hey, good news... i floated your idea of a "root_squash" to mhalcrow (kernel ecryptfs maintainer) and he's working on a patch, says it's relatively trivial
[22:42] <cjwatson> ok, great
[22:42] <kirkland> cjwatson: jdstrand and I talked about something similar this weekend
[22:42] <cjwatson> bad news is I hate your ~/bin munging
[22:42] <cjwatson> it's totally pointless and a waste of effort, no security relevant
[22:42] <cjwatson> relevance
[22:42] <cjwatson> just leave it the way it is, it's just fine!
[22:43] <cjwatson> Tyrone_man: I processed the relevant linux-restricted-modules binaries this morning, so tomorrow's should be better, thanks
[22:43] <kirkland> cjwatson: at this point, tis mainly a consistency-thing...  i have a separate patch for /etc/environment in PAM
[22:43] <kirkland> cjwatson: there seems to be some back/and/forth about whether we prepend or append
[22:44] <cjwatson> consistency with what we've done so far is far more important
[22:44] <kirkland> cjwatson: i think we all agreed that it should be the same in both /etc/skel/.profile and /etc/environment (wrt to prepending/appending)
[22:44] <cjwatson> people hate distros changing defaults back and forward on this kind of thing
[22:44] <cjwatson> I agree that it should be the same in different login modes, yes
[22:44] <kirkland> kees and jdstrand both leaned toward appending in both cases
[22:45] <cjwatson> I think the security arguments are completely specious
[22:45] <kees> for note, my opinion was based on utility, not security.  it seemed like a bad idea to override system tools with things in ~/bin, but I'm sure that's a matter of opinion.  :)
[22:46] <cjwatson> the situation this will break is as follows:
[22:46] <kirkland> i thought it was something a user should do "consciously"
[22:46] <kirkland> (ie, override system tools)
[22:46] <cjwatson> user has been maintaining ~/bin for years across a variety of Ubuntu installations
[22:47] <cjwatson> user installs a new Ubuntu system, and copies over their ~/bin like they always did
[22:47] <cjwatson> some time later, user notices that some random script doesn't work, and gets horribly confused
[22:47] <kees> okay.  so, in the case of the /etc/environment change, it should also prepend?
[22:47] <cjwatson> it may well have been a conscious decision at some point, but now we're requiring them to make it again, long after they've forgotten making it
[22:48] <cjwatson> it should be a consistent rule across the system that user customisations override the system by default
[22:48] <cjwatson> and that we don't mess around with user customisations
[22:49] <cjwatson> sorry to be blunt, and I know I'm coming late to this, but I feel quite strongly about the general principle
[22:49] <Caesar> cjwatson: that's just awesome
[22:49] <Caesar> Thanks
[22:52] <seb128> slangasek: hey, could you consider the gnome-games upload I just did for 8.04.1? It adds a gnome-games-data conflicts on glchess, the non conflict leads to a broken gnome-games installation and upstream seems to get quite some duplicates from users running into the issue
[22:52] <kirkland> cjwatson: kees: okay, i can drop the bash patch, and mark "invalid" ....  but the pam /etc/environment should probably prepend ~/bin to be consistent.  would this be acceptable?
[22:53] <jdstrand> cjwatson: I take your point about user customizations. I did mention that the risk was low, but I don't think it's completely specious
[22:53] <pwnguin> seb128: on a related note, is it really a good idea to have bug reports go directly to upstream?
[22:53] <jdstrand> cjwatson: I am not arguing against you for leaving it as is either
[22:53] <seb128> pwnguin: if the issue is an upstream one, yes
[22:53] <cjwatson> jdstrand: ok, we may have to agree to disagree on that (low vs. specious) :-)
[22:54] <jdstrand> cjwatson: I can accept that :)
[22:54] <kirkland> jdstrand: are you willing to concede the point, and are we back to prepending?
[22:54] <cjwatson> I think that road leads to things like writing C code where scripts would be more appropriate because otherwise it's easier to modify the code
[22:54] <seb128> pwnguin: we often just forward the bug and act as a gateway between bug trackers, which is not really efficient, if you are able to open the bug upstream directly that's better
[22:55] <cjwatson> kirkland: /etc/environment makes sense if $HOME expansion is possible there and if PAM clients actually handle that properly (i.e. have set $HOME when they run pam_env)
[22:55] <pwnguin> seb128: that has to generate some amount of friction in the cases where its not an upstream problem
[22:55] <seb128> if the bug is something we should consider for the current ubuntu version you might want to open the bug in launchpad too and add a watch on the upstream bug
[22:55] <jdstrand> kirkland: to me, cjwatson's point outweighs the risk, and I'm glad he weighed in
[22:55] <seb128> pwnguin: well, I said "if the issue is an upstream one"
[22:56] <pwnguin> seb128: as far as i know, none of our tools can place blame correctly ;)
[22:56] <seb128> ?
[22:56] <seb128> none of the tool open bugs automatically either
[22:56] <kirkland> cjwatson: i have tested extensively....  all of the major window managers (Gnome, KDE, XFCE) handle it properly, and the Bourne-compatible shells do (bash, ash, dash, ksh)
[22:56] <seb128> you always have an user confirming the action
[22:57] <seb128> pwnguin: I'm not sure to get the question now
[22:57] <cjwatson> kirkland: well, the shells don't deal with /etc/environment, normally
[22:57] <pwnguin> when glchess crashes, a bug-buddy window opens up
[22:57] <cjwatson> I was thinking more login, sshd, etc.
[22:57] <kirkland> cjwatson: and to be precisely, "~/bin" works with more shells than "$HOME/bin" does, and so my pam patches have used "~/bin"
[22:57] <seb128> pwnguin: if you know the issue is an upstream one you can open it directly in their bug tracker, if you don't know open it in launchpad and we will do the work for you
[22:58] <seb128> pwnguin: that's bug #88227, patches are welcome
[22:58] <cjwatson> kirkland: hmm, so you're saying that literally '~/bin' ends up in getenv("PATH")? That sounds a bit sketchy - doesn't the libc need to support that in order for that to be reliable?
[22:58] <kirkland> cjwatson: right, so I've tried login, ssh, and gdm/kdm
[22:58] <cjwatson> kirkland: I was thinking it would be much more appropriate to actually expand $HOME in getenv("PATH")
[22:58] <cjwatson> it should be /home/cjwatson/bin:... not ~/bin:...
[22:59] <seb128> pwnguin: we disable bug-buddy for crashers
[23:00] <seb128> pwnguin: there is just not so many programs using gnome-python and bug-buddy integration and nobody did the work to disable that code when apport is used yet
[23:00] <kirkland> cjwatson: yes, if ~/bin is in PATH in /etc/environment, then yes, ~/bin ends up in getenv("PATH").  same goes for $HOME/bin.
[23:00] <kirkland> cjwatson: it seemed to me that the bourne-compatible shells eval $PATH, and other shells do not
[23:00] <cjwatson> kirkland: if ~/bin is in getenv("PATH"), execlp does not wok
[23:00] <cjwatson> work
[23:01] <cjwatson> it has to actually be expanded to work reliably
[23:01] <cjwatson> shells might get this right, but other programs that use execvp or execlp directly will fail
[23:02] <cjwatson> kirkland: demonstration: http://paste.ubuntu.com/22449/
[23:02] <kirkland> cjwatson: okay, so in the bug i was originally fixing, a user wants to hit "alt-f2" in Ubuntu/Gnome, and type "ff"--their firefox wrapper they put in /home/user/bin/ff and it just "work"
[23:03] <cjwatson> kirkland: this may need to be fixed by having pam_env expand something in /etc/environment
[23:03] <cjwatson> rather than just using the value verbatim
[23:04] <cjwatson> kirkland: try ${HOME}/bin:...
[23:04] <kirkland> cjwatson: k
[23:04] <cjwatson> /usr/share/doc/libpam-doc/html/sag-pam_env.html documents that as the proper method
[23:04] <cjwatson> however, that may only work in pam_env.conf
[23:04] <kirkland> cjwatson: no difference if I put ${HOME}/bin in /etc/environment
[23:05] <cjwatson> worth a try, though, and would seem like the best thing to support if a PAM extension is needed
[23:05] <pwnguin> seb128: thanks for the explaination. I wondered why they were going immediately to GNOME, now it makes more sense
[23:05] <cjwatson> OK, I think that you need to extend pam_env to expand that, then
[23:05] <cjwatson> I absolutely agree this ought to be fixed, but we can't rely on shell expansion
[23:05] <seb128> pwnguin: writting the patch to not use bug-buddy there should not be too hard, it's somewhat on my todo list
[23:06] <seb128> pwnguin: you are welcome to work on it if you want though ;-)
[23:06] <pwnguin> at the moment I don't know enough python to make it happen any time soon
[23:07] <kirkland> cjwatson: the expansion needs to be in pam_env, then?
[23:07] <cjwatson> yeah, the PATH environment variable must be expanded
[23:07] <cjwatson> pre-expanded I mean
[23:08] <kirkland> cjwatson: is that the only variable i should worry about expanding?
[23:08] <kirkland> cjwatson: or should it be a full eval?
[23:08] <kirkland> cjwatson: sorry, I meant $HOME
[23:08] <cjwatson> the semantics of environment variables depends on what uses them
[23:09] <cjwatson> but I think it would be generally appropriate to apply ${...} expansion to everything in /etc/environment, even though it's technically a behaviour change; however slangasek should have a say there
[23:09] <cjwatson> it would definitely be confusing to expand PATH but not others
[23:13] <kirkland> cjwatson: okay, i've marked 242479 invalid.
[23:13] <cjwatson> thanks
[23:13] <kirkland> cjwatson: i'm looking at pam_env.c to see how painful env variable expansion will be
[23:16] <kirkland> cjwatson: this patch http://halcrow.us/~mhalcrow/patches/ecryptfs-excl-access-20080623.txt (untested) would allow a mount-time option, ecryptfs_exclusive_access_uid=1000, that the kernel would respect by not serving read/write requests to any other uid (even root).
[23:17] <cjwatson> sounds reasonable
[23:26] <slangasek> seb128: gnome-games> glchess is in universe; SRU yes, 8.04.1 no, sorry
[23:38] <slangasek> kirkland, cjwatson: if we're going to start expanding variables in /etc/environment (which I agree is the right way to do it), we should be consistent about it rather than special-casing $HOME
[23:38] <kirkland> slangasek: yessir...
[23:39] <kirkland> slangasek: i'm still digging into the problem...  looking at pam_env.c, the code does try to expand env variables
[23:39] <kirkland> slangasek: but it's not doing so on /etc/environment
[23:41] <slangasek> kirkland: right, the variable expansion is only done on pam_env.conf; I don't know why this is
[23:42] <slangasek> if possible, please run any patches you come up with past upstream, since we'll want to avoid diverging here and my pam patch load is already up to my chin
[23:42] <kirkland> slangasek: okay, i'm not going to spend much more time on this....
[23:43] <slangasek> ok
[23:43] <kirkland> slangasek: this was a 5-minute fix that I've devoted > 2 days on now :-/
[23:43] <slangasek> oh, I could've told you it wasn't a 5-minute fix from the beginning... :)
[23:44] <slangasek> wait, that didn't get tagged bitesize, did it?
[23:44] <kirkland> slangasek: "Nothing to see here, move along, move along..."  :-)
[23:44] <kirkland> slangasek: yes, it was
[23:44] <slangasek> yah, madness
[23:44] <kirkland> slangasek: I removed the tag after about hour 6
[23:44] <slangasek> good, thanks :)
[23:44]  * jdstrand is back for just a moment
[23:45] <jdstrand> cjwatson: here is why I believe it's low, rather than specious-- group or other writable ~/bin
[23:46] <jdstrand> I happen to have access to one of those, on a machine where I am not the admin, and didn't setup that directory
[23:46] <jdstrand> plus, I just reviewed a perl vuln that accidentally followed symlinks and made things 777
[23:47] <jdstrand> so, obviousy, there is an amount of trust in group writable, but accidents happen
[23:47] <jdstrand> anyhoo, I'm off again
[23:49] <kirkland> cjwatson: slangasek: argh....  # Note that many environment variables that you would like to use
[23:49] <kirkland> # may not be set by the time the module is called.
[23:49] <kirkland> # For example, HOME is used below several times, but
[23:49] <kirkland> # many PAM applications don't make it available by the time you need it.
[23:49] <kirkland> slangasek: that's exactly what I'm seeing with login and /etc/security/pam_env.conf
[23:49] <slangasek> right, that's a potential concern
[23:51] <kirkland> slangasek: cjwatson: Okay, then I don't even think this is solvable with pam_env, sadly.
[23:52] <slangasek> well, it's less of an issue for login because login spawns a shell which reads .profile, surely?
[23:52] <slangasek> the problematic use case is gdm which runs lots of things that aren't under a login shell
[23:55] <kirkland> slangasek: right.  well, the simple, non-expanded ~/bin in /etc/environment works well in my simple tests worked well with Gnome/KDE/XFCE, as for allowing for running scripts in ~/bin
[23:56] <slangasek> hrm, I'm not sure how it manages to do that given cjwatson's counterexample
[23:56] <kirkland> slangasek: cjwatson has a test c program in a pastebin above where he shows, however, that a non-expanded PATH is not good for c programs
[23:57] <kirkland> slangasek: my test consisted of "alt-f2"
[23:58] <kirkland>  slangasek: which was the user issue described in the original bug
[23:58] <slangasek> right
[23:58] <slangasek> I wonder why that works :)