[00:03] <cjwatson> compbrain: netboot kernel == all other kernels
[00:03] <cjwatson> I don't know offhand, but you might find that bit of information useful ;-) it's just the regular generic kernel
[00:03] <compbrain> Alrighty.
[00:06] <compbrain> looks like 2048 bytes. probably a gpxe issue then.
[02:06] <bryce> kirkland: hey I see in the server team meeting notes that you're putting man pages up on the web - awesome, I've had on my todo list to post the Xorg man pages (particularly for the input and video drivers and xorg.conf).  I'd be quite interested in seeing your work in this area
[02:55] <superm1> slangasek, i saw the re-rolled hardy on cdimages from yesterday with the newer kernels.  thanks for that.  it will help immensely on some otherwise non functional boxes
[02:55] <slangasek> superm1: hmm, which one did you see with newer kernels that's actually usable? :)
[02:55] <slangasek> superm1: the alternates are all oversized unless someone fixed this for me, the liveCDs didn't have the new kernel yet
[02:56] <superm1> the live disk
[02:56] <superm1> the 2008-06-11.1
[02:56] <superm1> i extracted it to a flash key
[02:56] <superm1> so if it was oversize, wouldn't have mattered
[02:56] <superm1> it boots on the box in question :)
[02:56] <slangasek> ok :)
[03:22] <Hobbsee> ogra: sorry, i'd gone to bed by that point.
[03:22] <Hobbsee> exams and all :(
[03:41] <marcot> ﻿﻿Hello, I've downloaded the synaptic source package with apt-get source, and i'm looking at the pt_BR.po file, and the strings are different from the strings shown in my installed package.
[03:41] <marcot> ﻿I get a welcome message with some mistakes, including </b without >, and in the po file the sentence is writen with other words, and it's not with these erros.
[05:55] <pitti> Good morning
[05:56] <ScottK> Good morning.
[05:56] <ScottK> Urgh.
[05:56] <ScottK> When pitti is saying good morning, it's well past time for me to get to bed.
[05:57] <pitti> kirkland: hmm; fstab for user-side mounts is soo much 1990..
[05:57] <ajmitch> hello pitti
[05:57] <kirkland> pitti: suggestions?
[05:57] <pitti> kirkland: oh, still awake? :-)
[05:58] <kirkland> pitti: 2 more hours until slangasek's party
[05:58] <ScottK> Heh.
[05:58] <pitti> kirkland: I'd rather use the existing hal/dbus infrastructure
[05:58] <ScottK> pitti: Would you be up for accepting the SRU for Bug #226845?
[05:58] <pitti> kirkland: I think it's much easier and cleaner to write a command-line frontend which does the dbus calls than to reinvent the entire backend
[05:58] <pitti> ScottK: will process the queue in a bit
[05:58] <kirkland> pitti: interesting.... can you point me to some examples of how I might do this for ecryptfs mounts?
[05:58] <ScottK> pitti: Thanks.
[05:59] <pitti> kirkland: well, hal doesn't support ecryptfs yet, we have to teach it about it
[05:59] <kirkland> pitti: i need to do the equivalent of this in /etc/fstab:
[05:59] <kirkland> /home/dustin/.Private /home/dustin/Private ecryptfs rw,ecryptfs_sig=7ab2a4d59b181d9b,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,user,noauto 0 0
[05:59] <kirkland> pitti: i can easily generate that, or the explicit mount -t foo -o bar options
[06:00]  * ScottK goes to bed.  Good night all.
[06:01] <pitti> kirkland: what's that signature?
[06:01] <kirkland> pitti: signature of the passphrase stored in the kernel's keyring
[06:01] <kirkland> pitti: used to retrieve the appropriate key from the keyring without giving anything away
[06:02] <kirkland> pitti: a hash, so to speak
[06:02] <pitti> kirkland: is that a secret that the user needs to supply, or the hal side?
[06:02] <pitti> kirkland: anyway, the existing dbus mount API supports passing mount options
[06:02] <kirkland> pitti: the sig isn't secret... it can be stored in a 644 permed /etc/fstab
[06:03] <kirkland> pitti: the passphrase/key, of course, is secret
[06:03] <pitti> we just need to add a tiny patch that allows ecryptfs as a valid file system, and the set of options that the user needs to/can supply
[06:03] <kirkland> pitti: cool, sounds good to me
[06:04] <pitti> kirkland: as for supplying the passphrase, that needs a deeper look, of course
[06:04] <kirkland> pitti: and then, what does the UI look like for the user to do the mount, then?
[06:04] <kirkland> pitti: nah, that's already handled by an ecryptfs pam module
[06:04] <pitti> we already do it on the desktop for luks encrypted devices
[06:04] <kirkland> pitti: i'm good on that part
[06:04] <pitti> kirkland: ah, great
[06:04] <kirkland> pitti: how does one trigger the mount?
[06:04] <pitti> kirkland: well, shuold there be an UI at all? I thought it should happen on login?
[06:04] <kirkland> pitti: i want it to happen on login
[06:05] <kirkland> pitti: right, exactly
[06:05] <pitti> 'zactly
[06:05] <pitti> kirkland: hm, two things come to my mind
[06:05] <kirkland> pitti: so right now, i have a shell script that I call in .bash_profile (and .config/autostart)
[06:05] <pitti> /etc/bash_profile, or a PAM extension for common-session
[06:06] <pitti> the former is easier, the latter more elegant, but takes some more effort
[06:06] <kirkland> pitti: is that a question?
[06:06] <kirkland> pitti: oh
[06:07] <pitti> kirkland: anyway, this is a pretty interesting problem, since a CLI version of gnome-mount is generally useful, not just for ecryptfs
[06:07] <pitti> well, of course there's always the highly comfortable CLI called "dbus-send" :-P
[06:07] <kirkland> pitti: yeah, i can see that... i'm using a custom script, /usr/bin/ecryptfs-mount-confidential
[06:08] <kirkland> pitti: and the /etc/fstab hackery is just that... hackery
[06:08] <pitti> kirkland: right; please let's not do that (fstab)
[06:08] <pitti> kirkland: I propose three implementation steps:
[06:08] <pitti> 1) implement the support for ecryptfs mounts in hal; this can be tested with standard gnome-mount
[06:09] <pitti> 2) develop a CLI version of gnome-mount
[06:09] <pitti> or,
[06:09] <pitti> 2b) write a small shell script wrapper around dbus-send to trigger the mount
[06:09] <pitti> 3) think about how to trigger the mount, i. e. where to call that script: PAM module or bashrc
[06:10] <kirkland> pitti: okay, regarding (3)....
[06:11] <kirkland> pitti: we'll want to mount /home/user/.Private on top of /home/user/Private whenever they login and if it's not already mounted (ssh, console, desktop, whatever)
[06:11] <pitti> kirkland: in the interest of not depending on a shell and supporting upgrades, a PAM-based solution would certainly be better
[06:11] <kirkland> pitti: agreed, PAM would be better, but let me mention one other thing....
[06:11] <pitti> kirkland: we can probably just extend libpam-mount to support our script, or even better, directly issue the dbus call
[06:11] <kirkland> pitti: i'd also like to see to it that the last one logging out umounts
[06:12] <kirkland> pitti: (my shell script is handling that with a "who | grep user | wc -l")
[06:12] <pitti> kirkland: that call can check if it's already mounted (in fact, that's what hal already does; users aren't allowed to double-mount, you'll just get an error back)
[06:12] <kirkland> pitti: and, I really want to chmod 500 both ~/.Private and ~/Private when it's not mounted, and 700 when it is
[06:13] <pitti> kirkland: as for the 'last one switches out the light', that's more interesting
[06:13] <pitti> kirkland: but PAM should certainly know which other sessions you are running?
[06:14] <kirkland> pitti: hmm, i don't know about that
[06:14] <superm1> hurm.  i uploaded a new upload of crash today that is supposed to build for lpia (at least as I put in debian/control).  does it need some archive admin love to do that too?
[06:14] <superm1> https://edge.launchpad.net/ubuntu/intrepid/+source/crash/4.0-6.3-1ubuntu2
[06:14] <kirkland> pitti: i mean, i don't know enough about PAM's session management to know
[06:15] <pitti> superm1: you added the Architecture: field?
[06:15] <superm1> i added lpia to the Architecture field yeah
[06:16] <pitti> kirkland: I know that it is possible
[06:16] <superm1> it already had one
[06:16] <superm1> just was missing lpia in it's list
[06:16] <pitti> kirkland: in earlier times we used libpam-foreground
[06:16] <pitti> kirkland: and that wrote a /var/run/console/<user>:<vt> stamp for all logins
[06:16] <kirkland> pitti: ah, so it used /var for accounting?
[06:16] <pitti> kirkland: PAM runs code when the user logs out
[06:17] <pitti> kirkland: nowadays we use ConsoleKit as a replacement, but I'm not sure whether you want to depend on that on servers
[06:17] <kirkland> pitti: yeah, i have to keep servers+desktops in mind
[06:17] <pitti> kirkland: anyway, I think on logout it should probably just test whether the user still has any process running? and if not, umount/clean up?
[06:18] <pitti> superm1: let me check P-a-S
[06:18] <kirkland> pitti: yeah, i'd just need to think about corner cases of a logged out user with processes still hanging around
[06:19] <pitti> superm1: yep, that's it; P-a-S has "crash: amd64 i386 ia64 alpha powerpc      # not yet ported to other platforms"
[06:19] <pitti> superm1: you need lamont's or infinity's help for that to add it there
[06:19] <superm1> pitti, what's P-a-S actually?
[06:19] <pitti> superm1: it's called "Packages-arch-specific" and overrides wrong Architecture: fields
[06:19] <pitti> i. e. it blacklists packages from being built on particular architectures
[06:20] <superm1> oh i see.  well it builds nicely on lpia at least
[06:20] <persia> (And also overrides right architecture fields, if an entry exists)
[06:20] <Hobbsee> afternoon pitti!
[06:20] <superm1> i ran it through a PPA to verify
[06:20] <persia> Is there anything that works on i386 that wouldn't work on lpia?
[06:20] <pitti> hey Hobbsee
[06:20] <superm1> whether it's entirely functional, that's a different story. I'm sturggling with other issues in reproducing this exact trace
[06:21] <persia> Might it be sensible to have lpia check P-a-S for "i386"?
[06:21] <superm1> *struggling
[06:21] <kirkland> pitti: regarding (1), i'm looking at hal-storage-mount.c, right?
[06:21]  * Hobbsee belatedly throws pitti a gummy bear.
[06:22] <kirkland> superm1: I like "sturggling"
[06:22] <kirkland> ;-)
[06:22] <pitti> kirkland: right; but it doesn't hardcode the user-permitted file systems and mount options
[06:22] <superm1> :)
[06:23] <pitti> kirkland: those are defined in fdi/policy/10osvendor/20-storage-methods.fdi
[06:24] <kirkland> pitti: aha
[06:25] <pitti> kirkland: you should probably add a separate FDI instead of patching this
[06:25] <kirkland> pitti: really?
[06:25] <pitti> kirkland: e. g. fdi/policy/10osvendor/15-storage-luks.fdi is an extension for LUKS-encrypted devices
[06:25] <kirkland> pitti: there's a bunch in there
[06:25] <kirkland> pitti: ah
[06:25] <pitti> kirkland: that should make a good template for you to copy
[06:26] <kirkland> pitti: the leading 15- ... is that a priority or something?
[06:26] <pitti> kirkland: hm; wait a minute; there's more to do for that, of course
[06:26] <pitti> kirkland: yes, they are read in asciibetical order
[06:26] <pitti> kirkland: i. e. latter ones can override the previous ones
[06:26] <pitti> kirkland: with hal you can only mount "volumes" (block devices) which hal knows about
[06:26] <kirkland> pitti: um, hang on a second....
[06:27]  * pitti ponders
[06:27] <kirkland> pitti: with ecryptfs, we're not dealing with block devices
[06:27] <kirkland> pitti: it's a vfs
[06:27] <pitti> kirkland: right, that's ok
[06:27] <kirkland> pitti: overlay mounting
[06:27] <pitti> kirkland: that's why it's called "volume" (an entity you can mount)
[06:27] <kirkland> pitti: okey doke
[06:27] <pitti> so this volume shuold be created in hal's database so that it can be properly represented in the hal tree
[06:28] <pitti> it's no problem to create that on the fly when you try to mount it, but it does need some code
[06:30] <pitti> kirkland: so either you use the existing code in hal-storage-mount.c which needs a representation of the volume in the hal tree (better IMHO, and upstream compatible) or special-case ecryptfs in hal-storage-mount.c and just do what you currently do to mount it
[06:30] <pitti> kirkland: I can give you a hand with the hal side, of course
[06:30] <kirkland> pitti: assistance accepted ;-)
[06:31] <kirkland> pitti: let's go with upstream compatibility
[06:31] <pitti> kirkland: well, as for that, I wouldn't worry too much
[06:31] <kirkland> pitti: assuming that everything can be done in time for intrepid
[06:31] <pitti> kirkland: hal is going to die in favor of devicekit
[06:32] <pitti> kirkland: but I wouldn't want you to block on getting devicekit and devicekit-disks packaged and into intrepid
[06:32] <pitti> kirkland: thus we should just do the custom Ubuntu patch for hal in intrepid, and then properly port it to DK-disks in intrepid+1 and make it upstream compatible
[06:33] <kirkland> pitti: okay, and the custom ubuntu patch would be against hal-storage-mount.c ?
[06:34] <pitti> kirkland: hmm; actually, what stops us from doing the mount right in the PAM module (libpam-mount)?
[06:34] <pitti> kirkland: yes, that and the FDI
[06:34] <pitti> but actually, maybe we are just overdesigning it
[06:34] <pitti> isn't libpam-mount meant for exactly those cases?
[06:34] <kirkland> pitti: does the PAM run with root privilege?
[06:34] <pitti> kirkland: yes
[06:35] <kirkland> pitti: oh, libpam-mount right.... i just read about that today
[06:35] <kirkland> pitti: i haven't given much thought to libpam-mount yet
[06:35] <kirkland> pitti: i bookmarked a howto on it ;-)
[06:36] <pitti> kirkland: it can already be used to mount a LUKS partition or image as your home dir when you log in
[06:36] <pitti> that shouldn't be too far apart from what you want to do
[06:36] <kirkland> pitti: right, that's pretty much exactly what i need to do
[06:38] <kirkland> pitti: where does a given user set up their libpam-mounts?
[06:38] <pitti> kirkland: TBH I don't know; I didn't use it myself yet
[06:38] <kirkland> pitti: okay, i'll dig into that
[06:39] <slangasek> I don't believe libpam-mount provides for user-level configuration
[06:42] <kirkland> slangasek: bummer, so it still requires a privileged user/admin to collect all libpam-mount's in an /etc config file?
[06:42] <slangasek> AFAIK, yes
[06:42] <kirkland> ewww.... pam_mount.conf.xml
[06:48] <kirkland> slangasek: man pam_mount(8): "Individual  users  may define additional volumes to mount if allowed by pam_mount.conf.xml (usually ~/.pam_mount.conf.xml)"
[06:48] <kirkland> \o/
[06:49] <slangasek> ah, ok
[06:58] <TiMiDo> hey i have a question
[06:58] <TiMiDo> can someone guide me or help me?
[06:59] <ion_> Yes: you type it and hit return. :-)
[06:59] <Hobbsee> no
[06:59] <Hobbsee> ion_: ++
[06:59] <dholbach> good morning
[06:59] <ion_> Hi
[06:59] <kirkland> howdy
[07:00] <TiMiDo> look im trying to make a packaged and i'm getting this error
[07:00] <TiMiDo> Source archive you specified ( ../mdk-1.2.4 ) was not found!
[07:00] <TiMiDo> any ideas?
[07:00] <ion_> #ubuntu-motu is the place for packaging.
[07:12] <kirkland> pitti: btw, i don't know if you noticed, but kees sponsored the select-editor patch.  thanks for looking at it with me at UDS.
[07:12] <pitti> kirkland: I saw it, also your bug fixes yesterday; great!
[07:13] <kirkland> pitti: ;-)
[07:58] <emgent> morning
[08:40] <hunger> Is alpha1 today?
[08:41] <slangasek> hunger: afraid not; there's still work that needs to be done for the bootstrapping
[08:42] <hunger> slangasek: Ah, thanks for the info. I was already wondering since almost every package I do care about is at the same version as in hardy:-|
[08:42] <hunger> slangasek: The kerel in hardy is actually newer than the one in intrepid!
[08:43] <slangasek> correct, the kernel team has been somewhat, er, distracted by the upcoming hardy point release :)
[08:43] <slangasek> we should be able to let them loose on intrepid soon
[08:44] <hunger> slangasek: Why are there so few things merged with debian yet?
[08:44] <hunger> s/with/from/
[08:45] <slangasek> hunger: again, I think it's largely due to the developers' attention being split between 8.04.1 and intrepid
[08:45] <hunger> slangasek: Thanks again for the info.
[08:46]  * hunger usually is at the current+1 release about 2 weeks after the repos open but has not found anything to make the upgrade to intrepid necessary yet.
[08:53] <robinp> is there a generic Java extensions directory on ubuntu ? (i.e. that works across all java runtimes )
[09:01] <persia> robinp: Java extensions directory?  How do you mean?  For libraries?
[09:03]  * Hobbsee wonders why sections of gnome are borked on intrepid
[09:03] <Hobbsee> half of the top panel missing is strange - and means there is no close button
[09:06] <seb128> Hobbsee: ask mvo that's a compiz issue and he said he would upload a new snapshot version yesterday ;-)
[09:06] <Hobbsee> seb128: ahhhh.  i'll have to boot to there, and update then
[09:06] <mvo> Hobbsee: its already in bzr, but compiz FTBFS currently (I think somewhere in kde, need to investigate)
[09:06] <Hobbsee> oh, tasty.
[09:06] <Hobbsee> want a hand?
[09:07]  * Hobbsee fixes hardy, so it actually boots.
[09:08] <mvo> maybe, let me look at it again
[09:09] <slangasek> seb128: as of ~11h ago, the packages were still not fixed as far as antimony was concerned
[09:10] <slangasek> pitti: hrm, does ia32-libs really need updated for alsa-lib?  Isn't that just lib32asound2, built from alsa-lib source?
[09:11] <seb128> slangasek: could you check if that's fixed now?
[09:11] <pitti> slangasek: right, but we should update it to .16 for completeness
[09:11] <TheMuso> slangasek: I think ia32-libs will need updating as it has plugins in it I think.
[09:11]  * TheMuso checks
[09:12] <TheMuso> slangasek: alsa-lib and alsa-plugins are in there.
[09:12] <slangasek> seb128: sorry, s/antimony/livefs buildd/.  anyway, trying a rebuild now; if it still doesn't see the fixed package, I'll probably need to grab infinity about it in the morning
[09:12] <seb128> ok
[09:14] <slangasek> TheMuso, pitti: I only see the plugins inside the ia32-libs binary package
[09:15] <slangasek> seb128: oh, the cronjob already ran for this morning; evolution-exchange looks ok, now we just need to straighten out libffi4 and apt
[09:15] <slangasek> (http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu/20080612/livecd-20080612-amd64.out)
[09:16] <seb128> cool
[09:16] <seb128> so I've fixed the desktop things correctly ;-)
[09:17] <mvo> Hobbsee: so what is the deal with kde in intrepid, the default kde switched to 4 but 3 is still available?
[09:19] <Hobbsee> mvo: iirc, yes.
[09:19] <Hobbsee> mvo: and it's still all going thru the mir process
[09:21]  * mvo nods
[09:25] <psypointer> hi
[09:26] <psypointer> i just used the netboot images from hardy proposed to install my computers via pxe and preseed. after adding the kernel parameter apt-setup/proposed=true the installations works without errors, but it ignores my preseed commands (preseed_late for example). how can i fix this?
[09:27] <psypointer> d-i preseed/late_command string wget http://10.255.255.254:88/files/preseed_late.sh -O /tmp/preseed_late.sh; sh /tmp/preseed_late.sh; thats what i'm using in my preseed conf but its simply ignored by the proposed version of the installe
[09:28] <psypointer> preseed ealry works..
[09:28] <psypointer> s/ealry/early/
[09:32] <pitti> dendrobates: anyone in the server team who could test the php5 package in dapper-proposed for bug 52866?
[09:37] <pitti> ogra: did you get any feedback to any of the ltsp bug fixes in -proposed? none of them are verified ATM
[09:37] <ogra> i can verify all of them, but i guess thats not enough ?
[09:38] <slangasek> if you uploaded them, then that shouldn't be enough, no :)
[09:39] <slangasek> hard to eliminate blind spots that way :)
[09:39] <ogra> yeah, thats what i suspected ...
[09:40] <ogra> bad thing is that the usual habit of ltsp users is to not upgrade the client chroot they use whats been set up during install ... so best feedback would come from 8.04.1 CD users ... somewhat a chicken <-> egg problem
[09:41] <ogra> but i'll try to gather some feedback
[09:41] <pitti> ogra: well, if you do tests with teh actual .debs from -proposed and give feedback in the bugs, that's already a good data point
[09:42] <pitti> for testing misbuilds, screwed dependencies, etc.
[09:42] <pitti> feedback from the uploader is very helpful, just not entirely sufficient
[09:42] <ogra> yep
[09:42]  * pitti hugs ogra, thanks
[09:43] <ogra> :)
[09:51] <stgraber> ogra: I'll regenerate a new chroot at home, probably this afternoon. I can enable -proposed and have a look at the fixes
[09:52] <ogra> stgraber, gracias !
[09:53] <stgraber> I can actually generate the chroot from there, I forgot that this server is on my VPN :)
[09:57] <stgraber> ogra: should I also enable -proposed in the chroot ?
[09:57] <ogra> yes, best is to use --copy-sourceslist
[09:57] <stgraber> ok
[09:58] <stgraber> Fetched 133MB in 1min8s (1946kB/s), /me loves new home internet speed :)
[09:58] <ogra> heh
[09:58] <pitti> nice!
[10:15] <stgraber> ogra: what's the easiest way to test that xubuntu fix ?
[10:16] <ogra> hmm
[10:17] <ogra> it checks if xubuntu-desktop is installed and the default
[10:17] <ogra> thats hard to reproduce, leave that one to me, i'll do a xubuntu install during the day in vbox and test it there
[10:17] <ogra> (need to grab the iso though)
[10:17] <stgraber> ok
[10:19] <stgraber> ogra: I confirmed two fixes, others will need that I boot a thin client (I can't really do that from the train station over VPN :))
[10:20] <ogra> bah
[10:20] <ogra> get a better train station
[10:20] <ogra> :)
[10:21] <stgraber> I don't think the download speed is the problem but rather my upload speed at home :) 2Mbit/s seems to be too slow to boot a thin client :)
[10:38] <cjwatson> hunger: looking at the graph at the bottom of http://merges.ubuntu.com/main.html, I'm not sure that's a fair characterisation of merge progress; there is certainly a lot to do, but somewhere between a third and half the main merges have been done
[11:22] <sdfg> can somebody help me with a cres-dev toolchain for powepc
[11:37] <kirkland> slangasek: are you still around?
[11:44] <hunger> cjwatson: I have not checked that graph. I just checked which packages would get updated by aptitude if I did a upgrade to intrepid and almost everything I care about is not, even though debian has newer versions.
[12:59] <kirkland> pitti: i officially *hate* pam_mount
[13:07] <pitti> kirkland: is it that bad?
[13:38]  * lamont tries to figure out what exactly causes his brain the most pain about a package 'db_4.7.25-1' being the first upstream 4.7 version to land
[13:38] <fabbione> ouch
[13:47] <pitti> lamont: let's just hope it's a date :)
[13:47] <lamont> or that the 7 and the 25 are independent counters
[13:48] <lamont> previous version being 4.6.21
[13:59] <\sh> dholbach: is it possible to use the single cookie line for lp/edge.lp and save it somewhere for python-launchpad-bugs?
[13:59] <ScottK> Was there a discussion about adding Landscape to the SRU exception list (as there recently was with hal-info) that is publically archived somewhere?
[14:11] <dendrobates> pitti: we are short handed, could the php bug test wait a couple days?
[14:12] <pitti> dendrobates: absolutely; it's waiting for half a year already, that won't make much of a difference
[14:12] <pitti> I'm just looking for someone who touched php to test it
[14:27] <ScottK> pitti: Back in February you added Landscape as a special SRU case (rev 85 of the SRU wiki page).  Was this discussed?  I'm trying to understand why it would be there.
[14:27] <dholbach> \sh: best to ask thekorn about that
[14:30] <\sh> dholbach: k
[14:32] <pitti> ScottK: ah, complicated story
[14:32] <pitti> ScottK: we actually discussed it, but only within Canonical so far; there hasn't been a TB decision about it yet, and we actually didn't do a landscape update yet
[14:32] <ScottK> pitti: I think it ought to not be there then.
[14:33] <ScottK> There are a lot of packages that would meet the same criteria.
[14:33] <pitti> ScottK: there's still an ongoing (but dragged) attempt to reformulate the SRU policy to provide something consistent for SRU, -backports, partners, etc.
[14:34] <ScottK> I think "Canonical has this proprietary product we have to keep up with" is a bad policy (which is what that reads like to me).
[14:34] <pitti> ScottK: well, I know tor, which we actually updated to a new upstream in stables in the past
[14:34] <pitti> ScottK: right; we need to formulate it differently, and thus cover similar cases as well
[14:34] <ScottK> Tor is a special case for reasons that we discussed widely at the time.
[14:35] <ScottK> pitti: Would you mind if I removed it pending a better formulation?
[14:35] <pitti> already at changing it
[14:35] <Hobbsee> ScottK: it's in main.  you're not part of the main release team.  why do you care?
[14:35] <ScottK> pitti: Thanks.
[14:37] <ScottK> Hobbsee: I care because I believe that Ubuntu and Canoncial are different entities with different governence.  It is benificial in the long run for Ubuntu to not be seen as having excessive favoritism for Canonical (and particularly it's proprietary products).
[14:37] <Mithrandir> it's similar to many other products where the protocol for talking with a server Ubuntu does not control changes and the client therefore needs updating.  IMO.
[14:38] <Hobbsee> ScottK: then shouldn't you be pushing for more people on the ubuntu release team (for main) who are not canonical employees?  They are the ones who should know about it, and make those decisions.
[14:38] <Hobbsee> ScottK: for all intents and purposes, you don't know if it was discussed privately among the relevant release team, and decided.
[14:38] <pitti> in fact we did this already, for some google service protocol in hardy-updates
[14:38] <pitti> (can't remember which one any more, though)
[14:38] <ScottK> Hobbsee: I would be in favor of that.
[14:38] <Mithrandir> pitti: yeah, it's not really a happy situation, but it's probably not a problem we can solve easily.
[14:38] <ScottK> Hobbsee: That's why I asked pitti if it was discussed.
[14:39] <pitti> so, it was, but not in the right Ubuntu forum so far
[14:39] <ScottK> He's the one that put it on the wiki.
[14:39] <Hobbsee> obviously, it would have been better if it was open, but just because it wasn't particularly public doesn't necessarily mean that it's an inside canonical thing, and they're rorting the system.
[14:39] <ScottK> As I understand it TB is the authority for such blanket waivers.
[14:39] <ScottK> it/is
[14:40] <Mithrandir> I believe it's been decided by the release team in the past.
[14:41] <ScottK> Dunno, but I'm happy with the markup as it now.
[14:41] <ScottK> pitti: Thanks.
[14:59] <ScottK> pitti: When you get ready to work on improving the process documentation, I'd be glad to contribute something about updating unmaintainable libraries with the rdepends via -backports as I did with clamav (BTW, no user complaints about the Feisty/Gutsy updates to what Hardy has on that one).
[16:38] <kirkland> pitti: hey, so, yeah, pam_mount doesn't quite work as advertised
[16:40] <pitti> kirkland: what does it do?
[16:40] <kirkland> pitti: doesn't unmount on logout
[16:40] <kirkland> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736
[16:41] <kirkland> pitti: see what you make of that
[16:48] <pitti> kirkland: urgh, messy; so that PAM configuration is Debian/Ubuntu specific
[16:49] <kirkland> pitti: possibly, i have a Fedora kvm, that I'm also looking at
[16:51] <kirkland> pitti: your pointer to pam_mount is a good one; if it did what it's designed to do (unmount on logout), this would be a perfect fit
[16:51] <pitti> kirkland: so maybe let's aim to fix this, that would make a lot of other people happy as well
[16:51] <kirkland> pitti: yea
[16:52] <kirkland> pitti: i worked through the night on it, and i can't decide whether to fix this in pam, ssh, or pam_mount
[16:52] <kirkland> pitti: would be nice if it were fixable just in pam policy (no code)
[16:52] <pitti> apparently not in pam_mount, if our pam_mount source works on mandriva
[16:52] <pitti> and not in ssh, if it also affects local console logins
[16:52] <pitti> kirkland: might just be hidden in /etc/login.defs?
[16:52] <kirkland> pitti: i don't think it does affect local logins
[16:53] <kirkland> pitti: i tried enabling CLEAN_SESSIONS (some people said it helped--a few years ago)
[16:53] <kirkland> pitti: no avail
[16:54] <kirkland> pitti: i assume a setuid umount would be a no-no?  even if it were a special one for just this case?
[16:54] <pitti> kirkland: it is already suid (needs to be for user umount)
[16:54] <kirkland> pitti: i think umount.crypt was written to handle this issue
[16:55] <kirkland> pitti: hmm, right, doh
[17:15] <Misterio> hi all
[17:16] <Misterio> ;D
[17:16] <Misterio> bye all :) ;) :·)
[17:17]  * mkrufky says "hi" to mario_limonciell
[17:17] <mario_limonciell> hi mkrufky
[17:17] <mkrufky> any final word on that thread... kinda went nowhere
[17:18] <mario_limonciell> unfortunately not.  i'll try to revive it
[17:18] <mkrufky> k
[17:18] <mkrufky> im merging power management fixes today
[17:19] <kirkland> pitti: interesting, i've managed to fenagle a working pam policy for Fedora
[17:19] <kirkland> pitti: i'll try to duplicate this on Intrepid after i get some coffee in me
[17:26] <mathiaz> kirkland: pitti: could pam_mount be used to mount a user home directory via cifs at login ?
[17:29] <kirkland> mathiaz: yes
[17:29] <kirkland> mathiaz: that's one of its classical use cases
[17:30] <kirkland> mathiaz: however, there is a bug, it seems on Debian-based distros, that keeps unmount from working when logging out of ssh
[17:30] <mathiaz> kirkland: ok
[17:30] <kirkland> mathiaz: see https://bugs.edge.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736
[17:50] <mathiaz> bdmurray: does python-launchpad-bugs support extract the list of packages a team is subscribed to (ex from https://bugs.launchpad.net/~ubuntu-server/+packagebugs) ?
[17:52] <bdmurray> mathiaz: no it does not
[17:54] <bdmurray> slangasek: what is the nomination / milestone document you've worked on?
[18:24] <calc> jcastro: ping
[18:25] <jcastro> calc: pong
[18:26] <calc> jcastro: just replied to your question about upstream'd bugs
[18:26] <jcastro> rock, thanks
[18:26] <calc> jcastro: afaict there are several hundred for OOo
[18:26] <calc> jcastro: so either i don't understand what the new page shows or there is a bug in it
[18:26] <jcastro> yeah I am strongly leaning towards "there has to be a bug in it."
[18:27] <calc> i included the link to show most of the upstreamed bugs for OOo
[18:27] <jcastro> calc: when you forward a bug or patch do you make a link from an existing bug in lp to the upstream bug tracker?
[18:27] <calc> its a bit long:
[18:27] <calc> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bugs?field.searchtext=&orderby=-importance&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.status_upstream=resolved_upstream&field.status_upstream=open_upstream&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.ta
[18:27] <calc> jcastro: yea, eg https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/36424
[18:28] <calc> it has a upstream project called "OpenOffice" with the ooo issue tracker number and link
[18:28] <jcastro> ah ok.
[18:28] <jcastro> this lists looks more sane. :D
[18:29] <calc> maybe the page only works if the upstream project has the same name as the Ubuntu package?
[18:30] <jcastro> substituting firefox in the url comes up with a sane list as well
[18:30] <jcastro> calc: excellent, thanks, I'll forward this along to kiko and see about fixing it
[18:32] <kirkland> slangasek: are you around yet?
[18:32] <calc> jcastro: great :)
[18:32] <kirkland> slangasek: pam_mount frustrations....
[18:33] <jcastro> calc: if I hover over the 0 for OOo it shows that it's looking for status "triaged", maybe that's it?
[18:41] <calc> jcastro: ah maybe so
[18:41] <calc> jcastro: there is a separate section for triaged though
[18:41] <jcastro> yeah, those are all the ones that are triaged but not linked upstream
[18:42] <jcastro> the upstream column is a subset of those
[18:42] <calc> hmm so the new rule is a upstream bug has to be marked triaged as well?
[18:42] <calc> i don't think i have used triaged for any OOo bugs
[18:42] <calc> i mark them confirmed and upstream if they are upstream bugs
[18:43]  * calc could back and mark them all as triaged but an upstream bug should automatically be considered done enough
[18:43] <calc> i guess confirmed that i have verified would be better marked as triaged if they aren't also upstream bugs
[18:44] <calc> i think the url is also wrong
[18:44] <jcastro> well, the onus is on us to make sure we're following what people are using. It should probably do all open bugs
[18:44] <calc> it uses edge. instead of bugs.
[18:44] <calc> https://bugs.launchpad.net/ubuntu/+source/openoffice.org?field.status_upstream=open_upstream works but edge. doesn't (if you remove the triaged bit)
[18:45] <calc> that also only shows open upstream bugs not ones that have been fixed upstream (i think?)
[18:45] <calc> just because a bug is fixed upstream doesn't necessarily mean we can use it yet, in OOo case many of those are fixed in 3.0
[18:45] <calc> which isn't actually released yet
[18:48] <jcastro> yes, it's only measuring open bugs
[19:05] <wwinter> Hey everyone.
[19:05] <wwinter> I was interested in helping with the development of ubuntu, I'm fairly competant in C++ and C, and was interested in maybe being mentored if that'd be possible?
[19:06] <ScottK> wwinter: What are you most interested in (Ubuntu, Kubuntu, Ubuntu Server, Etc.)?
[19:06] <wwinter> Ubuntu, mainly use it for audio production.
[19:07] <smallfoot-> make ubuntu faster, its slower than windows xp
[19:08] <ScottK> wwinter: Then I'd look into #ubuntustudio or #ubuntu-desktop.  If you want to learn about packaging programs for Ubuntu, there's #ubuntu-motu
[19:08] <wwinter> Thanks :)
[19:08] <wwinter> smallfoot: get a better pc :P
[19:08] <smallfoot-> i have intel dual-core, 4gb ram
[19:08] <smallfoot-> kickass pc, with 8600gt
[19:08] <smallfoot-> 2.13 GHz
[19:08] <wwinter> Okay.. is it just slow all the time or what?
[19:09] <smallfoot-> and its blazing fast in XP, but in Ubuntu, its slower
[19:09] <smallfoot-> no, its just less responsive
[19:09] <wwinter> What version are you running?
[19:09] <smallfoot-> when i open calculator, notepad or something in xp, it opens immediatly <1ms delay, in ubuntu 8.10, when i open gedit or gcalc, it takes 0,5-2s delay
[19:10] <wwinter> Are you using the proper driver for your gfx card in Ubuntu?
[19:11] <smallfoot-> yes
[19:12] <wwinter> Hmm I see what you mean, never really noticed it before lol
[19:12] <wwinter> It's not that bad though.
[19:14] <smallfoot-> yeah, its not that bad
[19:14] <smallfoot-> its like its "god this is slow"
[19:14] <smallfoot-> its not liek its "god this is slow"
[19:14] <smallfoot-> but after i use ubuntu for long time, then i reboot to xp, i feel "wow, xp is fast, everything happens immediatly!"
[19:15] <wwinter> I guess so, but I always found ubuntu more stable than windows.
[19:15] <wwinter> Especially so with Vista.
[19:15] <smallfoot-> yeah, vista sucks
[19:15] <smallfoot-> xp is rock solid though, and has been more stable for me than ubuntu
[19:15] <smallfoot-> applications crash a lot more often in ubuntu than in xp
[19:16] <smallfoot-> example, firefox, but it might have todo with the flash plugin
[19:16] <wwinter> Hmm, I've never had problems with ubuntu, but I'd say the short delay's just due to the gnome code being less optimised than xp explorer.
[19:17] <smallfoot-> yeh, or maybe gtk library
[19:17] <wwinter> You could try using KDE and see if it happens there too.
[19:17] <wwinter> If not, it's gnome, or the gtk libs
[19:19] <smallfoot-> yeah, just cant be bothered install whole big kde, or get kubuntu
[19:23] <slangasek> kirkland: I haven't used pam_mount personally, fwiw :)
[19:23] <slangasek> bdmurray: https://wiki.ubuntu.com/RCBugTargetting
[19:23] <kirkland> slangasek: ;-)  ... so this is about https://bugs.edge.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736
[19:24] <kirkland> slangasek: a note from you on the topic http://www.redhat.com/archives/pam-list/2003-April/msg00015.html from 4 Apr 2003 ;-)
[19:25] <kirkland> slangasek: i've added some debugging to sshd and pam_mount.  it looks to me like the problem is that sshd is running with a real uid of 1000 (well, not 0) when it calls the pam_close_session()
[19:26] <kirkland> slangasek: which means that pam doesn't have the authority to do what it needs to do (like unmount filesystems)
[19:26] <ogra> old known problem
[19:26] <kirkland> ogra: cool, i thought you might have some insight....
[19:26] <kirkland> ogra: gimme the dirt....
[19:26] <slangasek> kirkland: ah, well, for that you need to talk to cjwatson with his ssh hat :-)
[19:26] <ogra> you can work around it by disabling privilege separation in shh
[19:26] <ogra> *ssh
[19:26] <ogra> but that drops security
[19:27] <kirkland> ogra: i've actually tried dropping privilege separation, but that doesn't fix the problem for me
[19:30] <kirkland> ogra: any other ideas on the problem?  a way to solve it in the code without dropping priv separation?
[19:30] <ogra> use pam_script instead of pam_mount and script something together with a suid binary would be one ugly solution ...
[19:31] <kirkland> ogra: yup, that's what i was trying to move away from in favor of pam_mount
[19:31] <ogra> i dont really think there is a clean one
[19:35] <kirkland> ogra: okay, thanks.  i can actually avoid the setuid binary if i add the mounts to /etc/fstab and use the "user" flag
[19:35] <ogra> indeed
[19:35] <ogra> but then you have to fiddle with fstab
[19:35] <kirkland> ogra: this all started about 13 hours ago when I became damned and determined to remove those entries from /etc/fstab :-/
[19:36] <ogra> cant you do something with fuse instead of using real mount ?
[19:36] <kirkland> ogra: i think i want/need a real mount
[19:36] <ogra> oh, and nbd works fine fuly in userspace (even as the user) you can loopmount a file from localhost with it
[19:36] <kirkland> ogra: what are the limitations of fuse?
[19:37] <kirkland> ogra: this is an ecryptfs filesystem
[19:37] <kirkland> ogra: it's a vfs, mounting an encrypted directory on a mountpoint
[19:37] <kirkland> ogra: in kernel, uses the kernel keyring
[19:39] <ogra> hmm, sad, nbd could solve your prob (it can work like a user owned loopback device) but that uses only images
[19:40] <kirkland> ogra: one of the advantages that i'm trying to use of ecryptfs is that the underlying encrypted files can be incrementally backed up, not practical if you only have a single encrypted 4G file
[19:40] <ogra> fuse is likely to top layer ...
[19:42] <kirkland> ogra: i don't see where fusermount would let me specify a filesystem type of -t ecryptfs
[19:51] <kirkland> pitti: okay, i'm right back where i started....  using /etc/fstab
[19:51] <kirkland> pitti: for good reasons, now, mind you
[20:17] <jussi01> pitti: If you are around, just wanted to thank you for your tv drivers package :D works a treat :)
[20:19] <ssam> i am running hardy with proposed-updates enabled. today my mouse is very jerky, some clicks are being ignored and keeeys are multiply pressing. i am not surrre if its one of the updates that has caused     this or which oneeee. where should i report itttt?
[20:34] <calc> jcastro: wrt the bug report it might be useful if it can be squeezed in to show the number of incomplete bugs
[20:34] <calc> jcastro: OOo in particular has lots of those
[21:35] <jdstrand> kees: what is the url for checking the build status of a package in Debian? (I'd like to see what is happening with openssl-blacklist)
[21:40] <kees> jdstrand: I assume it's stuck in binary NEW, but let me go dig it up
[21:40] <kees> jdstrand: oh, right, no build logs -- it's an _all package, so my upload of it IS the build.  :P
[21:40] <kees> jdstrand: http://ftp-master.debian.org/new.html
[21:41] <jdstrand> kees: cool thanks
[21:41] <RainCT> bryce: Do you know when the problem that your  21_fix_dpll_prg_in_crtc_mode_set.patch patch in xserver-xorg-video-intel fixes was introduced?
[21:47] <bryce> hi RainCT, let me doublecheck
[21:48] <bryce> RainCT: do you mean 20_dpll_prg_in_crtc_mode_set.patch?
[21:50] <bryce> RainCT: ah, right, for hardy.
[21:51] <bryce> RainCT: the bug was first reported to us on 5/30
[21:53] <bryce> RainCT: the problem was introduced in commit 3c22ed633be2ac96eea7bc533839e956f1f31b84
[22:07] <RainCT> bryce: Ah, it isn't the problem I'm experiencing then. Well, thanks :)
[22:07] <bryce> np
[22:14] <pzn> Hi... already asked in #ubuntu, but no answer... do you know then gutsy will be discontinued? I need to plan the dates of some upgrades.
[22:15] <soren> pzn: 18 months after release.
[22:15] <pzn> soren: thanks!
[22:21] <YokoZar> So, Wine 1.0 and Firefox 3 might release on the same day by pure coincidence
[22:53] <cjwatson> kirkland: it might be possible to change it, although messing around with pam_session handling in sshd has a very strong history of fixing one thing and breaking another
[22:53] <kirkland> cjwatson: thanks for the update...  i think i'm going back to adding entries to /etc/fstab
[22:54] <kirkland> cjwatson: pam_mount just isn't going to cut it
[22:54] <cjwatson> changing pam_open_session is more likely to break things than close, of course; though I suspect that there are some modules that rely on open and close being called with the same privileges
[22:54] <kirkland> cjwatson: and i don't want to negatively affect anyone's ssh configuration
[22:55] <slangasek> well, pam_mount is such a module that relies on them being called with the same privs
[22:55] <kirkland> cjwatson: i think it's one step back from that....  ssh calls pam_close_session as a non-priv user
[22:55] <cjwatson> right, we went through a period several years ago when it got changed back and forward a bit
[22:55] <cjwatson> kirkland: because it also calls pam_open_session with dropped privileges
[22:55] <cjwatson> if you change that, I *know* it breaks other things
[22:55] <slangasek> hmm, but then the question is, how does pam_mount work at all under ssh
[22:56] <kirkland> cjwatson: it looks to me like the only universally available "proper" way for a non-priv user to mount/unmount is to have an entry in /etc/fstab with "user" option
[22:56] <cjwatson> it doesn't have a set-id helper does it?
[22:56] <cjwatson> not sure how that could be made to work securely, mind you
[22:56] <cjwatson> (!)
[22:57] <kirkland> cjwatson: slangasek: looks to me like pam_session_open is called with uid 0, but close with uid 1000 (in my case)
[22:57] <cjwatson> oh, you're right
[22:57] <cjwatson> and indeed it should be called with raised privileges, I had it the wrong way round
[22:57] <kirkland> cjwatson: "it" = open|close ?
[22:57] <cjwatson>     - New PAM implementation based on that in FreeBSD. This runs PAM session
[22:57] <cjwatson>       modules before dropping privileges (closes: #132681, #150968).
[22:58] <cjwatson> open should (i.e. I expect that that is the way it works right now); close should (i.e. ought to in an ideal world)
[22:59] <cjwatson> kirkland: https://bugzilla.mindrot.org/show_bug.cgi?id=926
[23:00] <kirkland> cjwatson: yeah, i pointed https://bugs.edge.launchpad.net/ubuntu/+source/pam/+bug/117736 to that
[23:02] <cjwatson> apparently that patch screws pam_mount in other ways though ...
[23:03] <cjwatson> I'll be upgrading to openssh 5.0p1 once all the openssl mitigation stuff is definitively out of the way, so we can try it then
[23:05] <cjwatson> kirkland: ah yes, so you did
[23:07] <kirkland> cjwatson: cool, thanks.
[23:07] <kirkland> cjwatson: in the meantime, i was thinking of writing a little utility that would cleanly update fstab for my purposes
[23:07] <kirkland> cjwatson: right now, its embedded in another script (ecryptfs-setup-confidential)
[23:08] <kirkland> cjwatson: but I think it would be more easily reviewable, and potentially useful elsewhere
[23:08] <kirkland> i gotta drop for a bit, see ya.
[23:21] <mathiaz> slangasek: in a SRU (openldap in this case), do you prefer to have the patches deleted from the debian/patches/ when they're no longer applied or just have then uncommented in the series file ?
[23:30] <slangasek> mathiaz: deleted, please
[23:31] <mathiaz> slangasek: even if the debdiff will be bigger ?
[23:31] <slangasek> mathiaz: yes, because it's also clearer that way precisely what's been changed
[23:32] <mathiaz> slangasek: ok