[00:03] compbrain: netboot kernel == all other kernels [00:03] I don't know offhand, but you might find that bit of information useful ;-) it's just the regular generic kernel [00:03] Alrighty. [00:06] looks like 2048 bytes. probably a gpxe issue then. === Ben1 is now known as BenC [02:06] 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] 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] superm1: hmm, which one did you see with newer kernels that's actually usable? :) [02:55] superm1: the alternates are all oversized unless someone fixed this for me, the liveCDs didn't have the new kernel yet [02:56] the live disk [02:56] the 2008-06-11.1 [02:56] i extracted it to a flash key [02:56] so if it was oversize, wouldn't have mattered [02:56] it boots on the box in question :) [02:56] ok :) [03:22] ogra: sorry, i'd gone to bed by that point. [03:22] exams and all :( [03:41] 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] I get a welcome message with some mistakes, including , and in the po file the sentence is writen with other words, and it's not with these erros. [05:55] Good morning [05:56] Good morning. [05:56] Urgh. [05:56] When pitti is saying good morning, it's well past time for me to get to bed. [05:57] kirkland: hmm; fstab for user-side mounts is soo much 1990.. [05:57] hello pitti [05:57] pitti: suggestions? [05:57] kirkland: oh, still awake? :-) [05:58] pitti: 2 more hours until slangasek's party [05:58] Heh. [05:58] kirkland: I'd rather use the existing hal/dbus infrastructure [05:58] pitti: Would you be up for accepting the SRU for Bug #226845? [05:58] Launchpad bug 226845 in amavisd-new-milter "amavisd-new-milter: unmet dependencies" [Medium,Fix committed] https://launchpad.net/bugs/226845 [05:58] 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] ScottK: will process the queue in a bit [05:58] pitti: interesting.... can you point me to some examples of how I might do this for ecryptfs mounts? [05:58] pitti: Thanks. [05:59] kirkland: well, hal doesn't support ecryptfs yet, we have to teach it about it [05:59] pitti: i need to do the equivalent of this in /etc/fstab: [05:59] /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] 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] kirkland: what's that signature? [06:01] pitti: signature of the passphrase stored in the kernel's keyring [06:01] pitti: used to retrieve the appropriate key from the keyring without giving anything away [06:02] pitti: a hash, so to speak [06:02] kirkland: is that a secret that the user needs to supply, or the hal side? [06:02] kirkland: anyway, the existing dbus mount API supports passing mount options [06:02] pitti: the sig isn't secret... it can be stored in a 644 permed /etc/fstab [06:03] pitti: the passphrase/key, of course, is secret [06:03] 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] pitti: cool, sounds good to me [06:04] kirkland: as for supplying the passphrase, that needs a deeper look, of course [06:04] pitti: and then, what does the UI look like for the user to do the mount, then? [06:04] pitti: nah, that's already handled by an ecryptfs pam module [06:04] we already do it on the desktop for luks encrypted devices [06:04] pitti: i'm good on that part [06:04] kirkland: ah, great [06:04] pitti: how does one trigger the mount? [06:04] kirkland: well, shuold there be an UI at all? I thought it should happen on login? [06:04] pitti: i want it to happen on login [06:05] pitti: right, exactly [06:05] 'zactly [06:05] kirkland: hm, two things come to my mind [06:05] pitti: so right now, i have a shell script that I call in .bash_profile (and .config/autostart) [06:05] /etc/bash_profile, or a PAM extension for common-session [06:06] the former is easier, the latter more elegant, but takes some more effort [06:06] pitti: is that a question? [06:06] pitti: oh [06:07] kirkland: anyway, this is a pretty interesting problem, since a CLI version of gnome-mount is generally useful, not just for ecryptfs [06:07] well, of course there's always the highly comfortable CLI called "dbus-send" :-P [06:07] pitti: yeah, i can see that... i'm using a custom script, /usr/bin/ecryptfs-mount-confidential [06:08] pitti: and the /etc/fstab hackery is just that... hackery [06:08] kirkland: right; please let's not do that (fstab) [06:08] kirkland: I propose three implementation steps: [06:08] 1) implement the support for ecryptfs mounts in hal; this can be tested with standard gnome-mount [06:09] 2) develop a CLI version of gnome-mount [06:09] or, [06:09] 2b) write a small shell script wrapper around dbus-send to trigger the mount [06:09] 3) think about how to trigger the mount, i. e. where to call that script: PAM module or bashrc [06:10] pitti: okay, regarding (3).... [06:11] 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] kirkland: in the interest of not depending on a shell and supporting upgrades, a PAM-based solution would certainly be better [06:11] pitti: agreed, PAM would be better, but let me mention one other thing.... [06:11] kirkland: we can probably just extend libpam-mount to support our script, or even better, directly issue the dbus call [06:11] pitti: i'd also like to see to it that the last one logging out umounts [06:12] pitti: (my shell script is handling that with a "who | grep user | wc -l") [06:12] 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] pitti: and, I really want to chmod 500 both ~/.Private and ~/Private when it's not mounted, and 700 when it is [06:13] kirkland: as for the 'last one switches out the light', that's more interesting [06:13] kirkland: but PAM should certainly know which other sessions you are running? [06:14] pitti: hmm, i don't know about that [06:14] 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] https://edge.launchpad.net/ubuntu/intrepid/+source/crash/4.0-6.3-1ubuntu2 [06:14] pitti: i mean, i don't know enough about PAM's session management to know [06:15] superm1: you added the Architecture: field? [06:15] i added lpia to the Architecture field yeah [06:16] kirkland: I know that it is possible [06:16] it already had one [06:16] just was missing lpia in it's list [06:16] kirkland: in earlier times we used libpam-foreground [06:16] kirkland: and that wrote a /var/run/console/: stamp for all logins [06:16] pitti: ah, so it used /var for accounting? [06:16] kirkland: PAM runs code when the user logs out [06:17] kirkland: nowadays we use ConsoleKit as a replacement, but I'm not sure whether you want to depend on that on servers [06:17] pitti: yeah, i have to keep servers+desktops in mind [06:17] 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] superm1: let me check P-a-S [06:18] pitti: yeah, i'd just need to think about corner cases of a logged out user with processes still hanging around [06:19] superm1: yep, that's it; P-a-S has "crash: amd64 i386 ia64 alpha powerpc # not yet ported to other platforms" [06:19] superm1: you need lamont's or infinity's help for that to add it there [06:19] pitti, what's P-a-S actually? [06:19] superm1: it's called "Packages-arch-specific" and overrides wrong Architecture: fields [06:19] i. e. it blacklists packages from being built on particular architectures [06:20] oh i see. well it builds nicely on lpia at least [06:20] (And also overrides right architecture fields, if an entry exists) [06:20] afternoon pitti! [06:20] i ran it through a PPA to verify [06:20] Is there anything that works on i386 that wouldn't work on lpia? [06:20] hey Hobbsee [06:20] whether it's entirely functional, that's a different story. I'm sturggling with other issues in reproducing this exact trace [06:21] Might it be sensible to have lpia check P-a-S for "i386"? [06:21] *struggling [06:21] pitti: regarding (1), i'm looking at hal-storage-mount.c, right? [06:21] * Hobbsee belatedly throws pitti a gummy bear. [06:22] superm1: I like "sturggling" [06:22] ;-) [06:22] kirkland: right; but it doesn't hardcode the user-permitted file systems and mount options [06:22] :) [06:23] kirkland: those are defined in fdi/policy/10osvendor/20-storage-methods.fdi [06:24] pitti: aha [06:25] kirkland: you should probably add a separate FDI instead of patching this [06:25] pitti: really? [06:25] kirkland: e. g. fdi/policy/10osvendor/15-storage-luks.fdi is an extension for LUKS-encrypted devices [06:25] pitti: there's a bunch in there [06:25] pitti: ah [06:25] kirkland: that should make a good template for you to copy [06:26] pitti: the leading 15- ... is that a priority or something? [06:26] kirkland: hm; wait a minute; there's more to do for that, of course [06:26] kirkland: yes, they are read in asciibetical order [06:26] kirkland: i. e. latter ones can override the previous ones [06:26] kirkland: with hal you can only mount "volumes" (block devices) which hal knows about [06:26] pitti: um, hang on a second.... [06:27] * pitti ponders [06:27] pitti: with ecryptfs, we're not dealing with block devices [06:27] pitti: it's a vfs [06:27] kirkland: right, that's ok [06:27] pitti: overlay mounting [06:27] kirkland: that's why it's called "volume" (an entity you can mount) [06:27] pitti: okey doke [06:27] so this volume shuold be created in hal's database so that it can be properly represented in the hal tree [06:28] it's no problem to create that on the fly when you try to mount it, but it does need some code [06:30] 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] kirkland: I can give you a hand with the hal side, of course [06:30] pitti: assistance accepted ;-) [06:31] pitti: let's go with upstream compatibility [06:31] kirkland: well, as for that, I wouldn't worry too much [06:31] pitti: assuming that everything can be done in time for intrepid [06:31] kirkland: hal is going to die in favor of devicekit [06:32] kirkland: but I wouldn't want you to block on getting devicekit and devicekit-disks packaged and into intrepid [06:32] 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] pitti: okay, and the custom ubuntu patch would be against hal-storage-mount.c ? [06:34] kirkland: hmm; actually, what stops us from doing the mount right in the PAM module (libpam-mount)? [06:34] kirkland: yes, that and the FDI [06:34] but actually, maybe we are just overdesigning it [06:34] isn't libpam-mount meant for exactly those cases? [06:34] pitti: does the PAM run with root privilege? [06:34] kirkland: yes [06:35] pitti: oh, libpam-mount right.... i just read about that today [06:35] pitti: i haven't given much thought to libpam-mount yet [06:35] pitti: i bookmarked a howto on it ;-) [06:36] kirkland: it can already be used to mount a LUKS partition or image as your home dir when you log in [06:36] that shouldn't be too far apart from what you want to do [06:36] pitti: right, that's pretty much exactly what i need to do [06:38] pitti: where does a given user set up their libpam-mounts? [06:38] kirkland: TBH I don't know; I didn't use it myself yet [06:38] pitti: okay, i'll dig into that [06:39] I don't believe libpam-mount provides for user-level configuration === tkamppeter_ is now known as tkamppeter [06:42] slangasek: bummer, so it still requires a privileged user/admin to collect all libpam-mount's in an /etc config file? [06:42] AFAIK, yes [06:42] ewww.... pam_mount.conf.xml [06:48] 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] \o/ [06:49] ah, ok [06:58] hey i have a question [06:58] can someone guide me or help me? [06:59] Yes: you type it and hit return. :-) [06:59] no [06:59] ion_: ++ [06:59] good morning [06:59] Hi [06:59] howdy [07:00] look im trying to make a packaged and i'm getting this error [07:00] Source archive you specified ( ../mdk-1.2.4 ) was not found! [07:00] any ideas? [07:00] #ubuntu-motu is the place for packaging. [07:12] 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] kirkland: I saw it, also your bug fixes yesterday; great! [07:13] pitti: ;-) [07:58] morning [08:40] Is alpha1 today? [08:41] hunger: afraid not; there's still work that needs to be done for the bootstrapping [08:42] 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] slangasek: The kerel in hardy is actually newer than the one in intrepid! [08:43] correct, the kernel team has been somewhat, er, distracted by the upcoming hardy point release :) [08:43] we should be able to let them loose on intrepid soon [08:44] slangasek: Why are there so few things merged with debian yet? [08:44] s/with/from/ [08:45] hunger: again, I think it's largely due to the developers' attention being split between 8.04.1 and intrepid [08:45] 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] is there a generic Java extensions directory on ubuntu ? (i.e. that works across all java runtimes ) [09:01] robinp: Java extensions directory? How do you mean? For libraries? [09:03] * Hobbsee wonders why sections of gnome are borked on intrepid [09:03] half of the top panel missing is strange - and means there is no close button [09:06] Hobbsee: ask mvo that's a compiz issue and he said he would upload a new snapshot version yesterday ;-) [09:06] seb128: ahhhh. i'll have to boot to there, and update then [09:06] Hobbsee: its already in bzr, but compiz FTBFS currently (I think somewhere in kde, need to investigate) [09:06] oh, tasty. [09:06] want a hand? [09:07] * Hobbsee fixes hardy, so it actually boots. [09:08] maybe, let me look at it again [09:09] seb128: as of ~11h ago, the packages were still not fixed as far as antimony was concerned [09:10] pitti: hrm, does ia32-libs really need updated for alsa-lib? Isn't that just lib32asound2, built from alsa-lib source? [09:11] slangasek: could you check if that's fixed now? [09:11] slangasek: right, but we should update it to .16 for completeness [09:11] slangasek: I think ia32-libs will need updating as it has plugins in it I think. [09:11] * TheMuso checks [09:12] slangasek: alsa-lib and alsa-plugins are in there. [09:12] 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] ok [09:14] TheMuso, pitti: I only see the plugins inside the ia32-libs binary package [09:15] 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] (http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu/20080612/livecd-20080612-amd64.out) [09:16] cool [09:16] so I've fixed the desktop things correctly ;-) [09:17] Hobbsee: so what is the deal with kde in intrepid, the default kde switched to 4 but 3 is still available? [09:19] mvo: iirc, yes. [09:19] mvo: and it's still all going thru the mir process [09:21] * mvo nods [09:25] hi [09:26] 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] 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] preseed ealry works.. [09:28] s/ealry/early/ [09:32] dendrobates: anyone in the server team who could test the php5 package in dapper-proposed for bug 52866? [09:32] Launchpad bug 52866 in php5 "SOAP response for associative array is different on ubuntu 6.06" [Undecided,Fix committed] https://launchpad.net/bugs/52866 [09:37] ogra: did you get any feedback to any of the ltsp bug fixes in -proposed? none of them are verified ATM [09:37] i can verify all of them, but i guess thats not enough ? [09:38] if you uploaded them, then that shouldn't be enough, no :) [09:39] hard to eliminate blind spots that way :) [09:39] yeah, thats what i suspected ... [09:40] 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] but i'll try to gather some feedback [09:41] 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] for testing misbuilds, screwed dependencies, etc. [09:42] feedback from the uploader is very helpful, just not entirely sufficient [09:42] yep [09:42] * pitti hugs ogra, thanks [09:43] :) === nijaba` is now known as nijaba [09:51] 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] stgraber, gracias ! [09:53] I can actually generate the chroot from there, I forgot that this server is on my VPN :) [09:57] ogra: should I also enable -proposed in the chroot ? [09:57] yes, best is to use --copy-sourceslist [09:57] ok [09:58] Fetched 133MB in 1min8s (1946kB/s), /me loves new home internet speed :) [09:58] heh [09:58] nice! [10:15] ogra: what's the easiest way to test that xubuntu fix ? [10:16] hmm [10:17] it checks if xubuntu-desktop is installed and the default [10:17] 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] (need to grab the iso though) [10:17] ok === DktrKranz is now known as DktrKranz2 [10:19] 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] bah [10:20] get a better train station [10:20] :) [10:21] 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 :) === broonie_ is now known as broonie [10:38] 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] can somebody help me with a cres-dev toolchain for powepc [11:37] slangasek: are you still around? [11:44] 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. === Robot101_ is now known as Robot101 [12:59] pitti: i officially *hate* pam_mount [13:07] kirkland: is it that bad? === dashua_ is now known as dashua [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] ouch [13:47] lamont: let's just hope it's a date :) [13:47] or that the 7 and the 25 are independent counters [13:48] 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] 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] pitti: we are short handed, could the php bug test wait a couple days? [14:12] dendrobates: absolutely; it's waiting for half a year already, that won't make much of a difference [14:12] I'm just looking for someone who touched php to test it [14:27] 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] \sh: best to ask thekorn about that [14:30] <\sh> dholbach: k [14:32] ScottK: ah, complicated story [14:32] 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] pitti: I think it ought to not be there then. [14:33] There are a lot of packages that would meet the same criteria. [14:33] 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] 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] ScottK: well, I know tor, which we actually updated to a new upstream in stables in the past [14:34] ScottK: right; we need to formulate it differently, and thus cover similar cases as well [14:34] Tor is a special case for reasons that we discussed widely at the time. [14:35] pitti: Would you mind if I removed it pending a better formulation? [14:35] already at changing it [14:35] ScottK: it's in main. you're not part of the main release team. why do you care? [14:35] pitti: Thanks. [14:37] 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). === Mez is now known as Mez|DPC [14:37] 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] 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] ScottK: for all intents and purposes, you don't know if it was discussed privately among the relevant release team, and decided. [14:38] in fact we did this already, for some google service protocol in hardy-updates [14:38] (can't remember which one any more, though) [14:38] Hobbsee: I would be in favor of that. [14:38] pitti: yeah, it's not really a happy situation, but it's probably not a problem we can solve easily. [14:38] Hobbsee: That's why I asked pitti if it was discussed. [14:39] so, it was, but not in the right Ubuntu forum so far [14:39] He's the one that put it on the wiki. [14:39] 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] As I understand it TB is the authority for such blanket waivers. [14:39] it/is [14:40] I believe it's been decided by the release team in the past. [14:41] Dunno, but I'm happy with the markup as it now. [14:41] pitti: Thanks. [14:59] 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] pitti: hey, so, yeah, pam_mount doesn't quite work as advertised [16:40] kirkland: what does it do? [16:40] pitti: doesn't unmount on logout [16:40] pitti: https://bugs.edge.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736 [16:41] Launchpad bug 117736 in libpam-mount "pam_mount unable to unmount needs root priv" [Medium,Confirmed] [16:41] pitti: see what you make of that [16:48] kirkland: urgh, messy; so that PAM configuration is Debian/Ubuntu specific [16:49] pitti: possibly, i have a Fedora kvm, that I'm also looking at [16:51] 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] kirkland: so maybe let's aim to fix this, that would make a lot of other people happy as well [16:51] pitti: yea [16:52] 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] pitti: would be nice if it were fixable just in pam policy (no code) [16:52] apparently not in pam_mount, if our pam_mount source works on mandriva [16:52] and not in ssh, if it also affects local console logins [16:52] kirkland: might just be hidden in /etc/login.defs? [16:52] pitti: i don't think it does affect local logins [16:53] pitti: i tried enabling CLEAN_SESSIONS (some people said it helped--a few years ago) [16:53] pitti: no avail [16:54] pitti: i assume a setuid umount would be a no-no? even if it were a special one for just this case? [16:54] kirkland: it is already suid (needs to be for user umount) [16:54] pitti: i think umount.crypt was written to handle this issue [16:55] pitti: hmm, right, doh [17:15] hi all [17:16] ;D [17:16] bye all :) ;) :·) [17:17] * mkrufky says "hi" to mario_limonciell [17:17] hi mkrufky [17:17] any final word on that thread... kinda went nowhere [17:18] unfortunately not. i'll try to revive it [17:18] k [17:18] im merging power management fixes today [17:19] pitti: interesting, i've managed to fenagle a working pam policy for Fedora [17:19] pitti: i'll try to duplicate this on Intrepid after i get some coffee in me [17:26] kirkland: pitti: could pam_mount be used to mount a user home directory via cifs at login ? [17:29] mathiaz: yes [17:29] mathiaz: that's one of its classical use cases [17:30] mathiaz: however, there is a bug, it seems on Debian-based distros, that keeps unmount from working when logging out of ssh [17:30] kirkland: ok [17:30] mathiaz: see https://bugs.edge.launchpad.net/ubuntu/+source/libpam-mount/+bug/117736 [17:30] Launchpad bug 117736 in libpam-mount "pam_mount unable to unmount needs root priv" [Medium,Confirmed] [17:50] 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] mathiaz: no it does not [17:54] slangasek: what is the nomination / milestone document you've worked on? [18:24] jcastro: ping [18:25] calc: pong [18:26] jcastro: just replied to your question about upstream'd bugs [18:26] rock, thanks [18:26] jcastro: afaict there are several hundred for OOo [18:26] jcastro: so either i don't understand what the new page shows or there is a bug in it [18:26] yeah I am strongly leaning towards "there has to be a bug in it." [18:27] i included the link to show most of the upstreamed bugs for OOo [18:27] 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] its a bit long: [18:27] 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] jcastro: yea, eg https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/36424 [18:27] Launchpad bug 36424 in openoffice.org "[Upstream] [hardy] OpenOffice fails to open file over ftp when user not anonymous" [High,Confirmed] [18:28] it has a upstream project called "OpenOffice" with the ooo issue tracker number and link [18:28] ah ok. [18:28] this lists looks more sane. :D [18:29] maybe the page only works if the upstream project has the same name as the Ubuntu package? [18:30] substituting firefox in the url comes up with a sane list as well [18:30] calc: excellent, thanks, I'll forward this along to kiko and see about fixing it === mkrufky is now known as mkrufky-away [18:32] slangasek: are you around yet? [18:32] jcastro: great :) [18:32] slangasek: pam_mount frustrations.... [18:33] calc: if I hover over the 0 for OOo it shows that it's looking for status "triaged", maybe that's it? === asac_ is now known as asac [18:41] jcastro: ah maybe so [18:41] jcastro: there is a separate section for triaged though [18:41] yeah, those are all the ones that are triaged but not linked upstream [18:42] the upstream column is a subset of those [18:42] hmm so the new rule is a upstream bug has to be marked triaged as well? [18:42] i don't think i have used triaged for any OOo bugs [18:42] 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] i guess confirmed that i have verified would be better marked as triaged if they aren't also upstream bugs [18:44] i think the url is also wrong [18:44] 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] it uses edge. instead of bugs. [18:44] 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] that also only shows open upstream bugs not ones that have been fixed upstream (i think?) [18:45] 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] which isn't actually released yet [18:48] yes, it's only measuring open bugs === Shely is now known as iShely === SWAT_ is now known as swat [19:05]