[00:36] <slangasek> somerville32: pong
[00:37] <somerville32> mthaddon, you totally cut the topic off :P
[00:37] <mthaddon> oops
[00:38] <mthaddon> that's one enormous topic...
[00:38] <somerville32> slangasek, Would you be willing to sponsor ubuntu-wallpapers?
[00:38] <somerville32> I know this isn't the best time but kwwii would like it for Alpha 2
[00:38] <slangasek> er, no, I'm kinda busy trying to get working CDs, sorry
[00:39] <crimsun> somerville32: debdiff/url?
[00:39] <somerville32> Oh, hey crimsun
[00:39] <somerville32> crimsun, We use bazaar to manage the package, is there any fancy was you can do something with that or do I need to give you a standard debdiff?
[00:40] <crimsun> somerville32: I can bzr branch.  Is there a specific one?
[00:40] <somerville32> I'll provide you the link
[00:43] <somerville32> crimsun, https://code.edge.launchpad.net/~ubuntu-art-pkg/ubuntu-wallpapers/ubuntu
[01:25] <TheMuso> somerville32: WHy did you change the topic back
[01:25] <somerville32> TheMuso, I didn't
[01:25] <somerville32> :)
[01:25] <TheMuso> somerville32: You did, you removed the lanuchpad downtime message.
[01:25] <somerville32> TheMuso, No, I really didn't, lol
[01:25] <TheMuso> launchpad
[01:25] <somerville32> TheMuso, Unless my client is acting up, it is just at the end now
[01:26] <TheMuso> Oh sorry didn't see that.
[01:26] <somerville32> No problem.
[01:26] <somerville32> TheMuso, I've updated ubuntu-artwork
[01:26] <TheMuso> But thats something I don't agree with.
[01:26] <TheMuso> Because, not all clients show the whole topic, and not everyone is likely to type /t or /topic every time they have a look in here.
[01:26] <somerville32> Why?
[01:26] <somerville32> Ah
[01:27] <TheMuso> I'm using irssi in gnome-terminal at a high res, and even then I don't see the whole topic.
[01:27] <somerville32> better? :)
[01:28] <lamont> TheMuso: that's where moving the mouse over the topic line in xchat is love.
[01:28] <TheMuso> lamont: Good for you and your GUI client.
[01:28] <lamont> or /topic, of course
[01:28] <lamont> just don't type any garbage on the line...
[01:28] <TheMuso> somerville32: Yes, it is.
[01:28] <somerville32> TheMuso, On to more pressing matters, I've updated ubuntu-wallpapers package
[01:28] <TheMuso> somerville32: I saw.
[01:29] <somerville32> crimsun uploaded it but I fear it got rejected or lp has stopped processing uploads in lieu of the downtime or something
[01:29] <TheMuso> Well 2:00 UTC is not for another half an hour or so.
[01:30] <somerville32> crimsun, I think it got rejected.
[01:30] <TheMuso> Unless you made an error in writing the topic.
[01:33] <crimsun> somerville32: I have not received a REJECTED e-mail
[01:34] <TheMuso> There doesn't seem to be any mail from lp atm. I just did a bzr branch change that I am subscribed to, and have received no mail for it either.
[01:34] <somerville32> mthaddon, ^^
[01:35] <mthaddon> somerville32, yeah, that's right - been turned off in anticipation of the rollout - will be sent after the rollout is complete
[01:35] <mthaddon> TheMuso, ^
[01:36] <somerville32> mthaddon, So the package was most likely rejected and the e-mail hasn't been sent out?
[01:36] <crimsun> no, it has been queued.
[01:36] <StevenK> mthaddon: I'm in the middle of a 25Mb upload, that'll get processed after the 1.12 rollout?
[01:36] <crimsun> (after a few releases, you'll get the hang of interpreting "where's the ACCEPTED?")
[01:37] <mthaddon> StevenK, I believe so, yes
[01:38] <somerville32> Heya bddebian
[01:39] <bddebian> Hi somerville32
[02:05] <bluszcz> hello
[02:05] <bluszcz> i am creating just dapper custom cd with new kernel, i create all di packages
[02:06] <bluszcz> but i don't know how to create initrd for di kernel
[02:06] <bluszcz> update-initramfs -c should be fine?
[02:07] <bluszcz> anyone?
[02:08] <Burgundavia> bluszcz: given it is near the holidays and after US workday and in European night...
[02:09] <bluszcz> Burgundavia: i am on my holidays
[02:09] <bluszcz> unfortunately i have to work
[02:10] <bluszcz> i need to prepare special dapper cd on tomorrow morning
[02:10] <bluszcz> (3:10AM here)
[02:22] <TheMuso> bluszcz: Are you creating a custom live CD, or a custom alternate CD?
[02:23] <bluszcz> TheMuso: server
[02:24] <TheMuso> Ok. In order to use your new kernel, you nee to rebuild the debian-installer package, and modify it to use your own kernel.
[02:25] <TheMuso> bluszcz: Without digging myself, I couldn't tell you how exactly its done, but you need to download the debian-installer source package, unpack it, make the changes to use your kernel, and then rebuild it.
[02:25] <TheMuso> This will generate a .tar.gz file that will have the new initrd file you need.
[02:25] <bluszcz> TheMuso: i made it
[02:25] <bluszcz> i got all udeb modules packages
[02:25] <bluszcz> but i don't see initrd.gz file
[02:29] <TheMuso> How did you make it?
[02:29] <bluszcz> ow, you are talking about debian-installer
[02:29] <bluszcz> i only create modules *udeb
[02:29] <bluszcz> ok, i am going try rebuild debian-installer
[02:29] <bluszcz> thanks for the hint
[02:31] <bluszcz> debian/rules binary after change will be fine?
[02:34] <TheMuso> bluszcz: dpkg-buildpackage -rfakeroot is how you build it.
[02:35] <TheMuso> YOu also need to ensure you have it's build dependencies installed.
[02:35] <bluszcz> apt-get build-dep
[02:35] <TheMuso> Yes.
[02:35] <bluszcz> Package glibc-pic is a virtual package provided by: libc6-pic 2.3.6-0ubuntu20.5
[02:35] <bluszcz> You should explicitly select one to install.
[02:35] <bluszcz> E: Package glibc-pic has no installation candidate
[02:36] <bluszcz> huh
[02:37] <TheMuso> What choices do you have?
[02:37] <bluszcz> i don't understand your question, sorry
[02:38] <TheMuso> Well, it says that there is no installation candidate for glibc-pic. It should give you a list of possible packages that are similar to that one.
[02:43] <bluszcz> Package glibc-pic is a virtual package provided by: libc6-pic 2.3.6-0ubuntu20.5
[02:43] <bluszcz> apt-get install
[02:47] <TheMuso> without knowing what choices there are, I don't know.
[02:47] <bluszcz> ok, now i am reading about doc/custom kernel
[02:55] <Hobbsee_> so, uh...
[02:55] <LongPointyStick> ...wow
[02:56] <ajmitch> yes?
[02:56] <Hobbsee> apparently i *do* have wifi
[02:56] <ajmitch> that's good
[02:56]  * Hobbsee saw it magically switch to wifi, as the wired connection dropped out
[02:56] <bluszcz> wifi is weird
[02:56] <Hobbsee> however....the wifi light *still* *isnt* *on*
[02:57] <ajmitch> the light shouldn't matter
[02:57] <Hobbsee> well, i thought it'd decided the kill switch was on
[02:57] <Hobbsee> but this is true.  others say it works
[02:58] <ajmitch> iirc I have led=1 set as an option for the ipw220 module
[02:58] <ajmitch> sometimes (rarely) I've had to toggle the kill switch from windows
[02:59]  * Hobbsee wonders how you set teh led option
[02:59] <ajmitch> in /etc/modprobe.d/options, though that has probably changed since then
[03:00]  * bluszcz fakeroot make build_cdrom_isolinux
[03:00] <bluszcz> on my linksys main error led is always red
[03:01] <bluszcz> but hw works fine, weeird
[03:01] <bluszcz> and two weeks ago some script kiddie 'hacked' my router ;)
[03:02] <slangasek> ok, what
[03:02] <slangasek> who broke /dev/cdrom in the ISOs?
[03:04] <StevenK> ajmitch: My wireless LED works without that options
[03:05] <slangasek> Keybuk: awoooga
[03:05] <StevenK> s/ns/n/
[03:05] <ajmitch> StevenK: this option has been set since before dapper release & I haven't bothered to change what's working
[03:05] <StevenK> Ah, right
[03:06] <Keybuk> slangasek: ?
[03:07] <slangasek> Keybuk: all the hardy2 CDs I'm testing come up with /dev/scd0 and not /dev/cdrom, looks like it might be a regression introduced with the new upstream udev?
[03:07] <slangasek> s/hardy2/alpha2/
[03:07] <jdstrand> cd ../no
[03:07] <Keybuk> what version of udev is on them?
[03:07] <jdstrand> uhh... wrong terminal
[03:08] <slangasek> Keybuk: cjwatson did a d-i rebuild within the past three days, so should be 117-2 AFAIK; looking to confirm
[03:09] <slangasek> (and hmm, what happened to the "ubuntu" in the udev version numbers?
[03:09] <slangasek> )
[03:09] <Keybuk> I dropped it
[03:10] <Keybuk> we're not derived from Debian there, and 0ubuntu kept tripping me up with things
[03:12] <bddebian> likely story.. ;-)
[03:14] <blueyed> BenC: nvidia-glx-new should provide "xserver-xorg-video-2" instead of "xserver-xorg-video", correct? Currently is conflicts with xserver-xorg-core. (s/xserver-xorg-video/xserver-xorg-video-2/ in debian/control)
[03:18] <Keybuk> slangasek: ack or nak?
[03:20] <slangasek> Keybuk: regarding the version on the disk? trying to figure out how to confirm that without LP available
[03:20] <Keybuk> do you not have a booted CD? :)
[03:21] <Keybuk> I guessed you did since you noticed /dev/cdrom wasn't there
[03:22] <slangasek> Keybuk: how do I get a version number from there?
[03:22] <slangasek> hmm, I suppose that's recorded in dpkg/status
[03:23] <Keybuk> dpkg-query -W udev :-)
[03:24] <slangasek> udev-udeb, rather. :)
[03:24] <StevenK> blueyed: Does nvidia work with the new -xorg-core?
[03:24] <slangasek> Keybuk: yeah, udev-udeb 117-2 is on the alternates
[03:25] <blueyed> StevenK: not tried yet. I'm looking at manipulating the .deb (instead of rebuilding l-r-m).
[03:25] <blueyed> StevenK: I've seen it for 2.6.22, so I suppose it should do it for 2.6.24, too.
[03:25] <StevenK> It looks okay for me ...
[03:25] <StevenK> Just trying it in a Hardy chroot
[03:25] <TheMuso> /c
[03:26] <TheMuso> ugh
[03:26] <blueyed> StevenK: the dependencies look ok for you?
[03:26] <blueyed> with 2.6.24?
[03:26] <StevenK> blueyed: 'apt-get install nvidia-glx-new' sorted it out
[03:26] <Keybuk> oh, hmm
[03:26] <Keybuk> udev-udeb
[03:27] <StevenK> This is in a chroot, no kernel. It dragged in 2.6.22
[03:27] <Keybuk> slangasek: back up a bit
[03:27] <Keybuk> what's wrong?
[03:27] <Keybuk> be more specific
[03:27] <Keybuk> ie. where is /dev/cdrom missing
[03:27] <blueyed> StevenK: I guess you still have 2.6.22 then.. yes, different story.
[03:27] <Keybuk> on the desktop CD inside casper/initramfs, or after boot
[03:27] <Keybuk> or is it on the live cd, but not on the installed image
[03:27] <blueyed> BenC: nvidia-glx-new-Provides appears to be OK for 2.6.22, but not 2.6.24.
[03:27] <Keybuk> or is it missing on the alternate while the installer is running, but on the installed system
[03:27] <StevenK> blueyed: But nvidia-glx-new doesn't need to be updated
[03:27] <Keybuk> etc.
[03:27] <slangasek> Keybuk: "alternate CD"
[03:28] <Keybuk> slangasek: alternate CD inside the installer?
[03:28] <slangasek> yes
[03:28] <Keybuk> we've never had /dev/cdrom there
[03:28] <Keybuk> what's trying to use it?
[03:28] <StevenK> blueyed: I thought nvidia-glx-new Provided the xserver-xorg bits, not the lrm bits.
[03:28] <StevenK> blueyed: Can you dig more?
[03:28] <blueyed> bug 177575
[03:29] <StevenK> ENOLP
[03:29] <slangasek> Keybuk: well, ok; the exact error message is "No common CD-ROM drive was detected"
[03:29] <slangasek> Keybuk: let me dig into d-i then to see what it's looking for
[03:29] <Keybuk> slangasek: that's far more likely "udevinfo: command not found" :)
[03:29] <slangasek> hrm, ok
[03:30] <Keybuk> I've just realised that I never touched the installer
[03:30] <Keybuk> I grepped all the diff.gzs in the archive for using udevinfo, udevtrigger, udevsettle, etc.
[03:30] <Keybuk> but the installer would be inside .tar.gz wouldn't it
[03:30] <StevenK> Keybuk: Right, being native
[03:30] <slangasek> sure
[03:30] <StevenK> Which also means you missed native packages
[03:31] <Keybuk> right
[03:31] <Keybuk> so that's the problem then
[03:31] <StevenK> So, how do you grep a tarball? :-P
[03:32] <StevenK> blueyed: Right, I see what's going on, I think
[03:32] <Keybuk> don't suppose you know which bit of the installer does that?
[03:32] <StevenK> My chroot doesn't have 2.6.24 stuff, which is odd
[03:33] <slangasek> Keybuk: debian-installer-utils
[03:33] <blueyed> StevenK: the packages in l-r-m must provide "xserver-xorg-video-2" instead of "xserver-xorg-video". Pretty sure.
[03:33] <blueyed> StevenK: yes, the deps for 2.6.24 are not really in place yet.
[03:33] <StevenK> blueyed: Mmmm. You're going to have to rebuild lrm, though
[03:34]  * Hobbsee is fairly sure he's right, from dealing with the intel variety a month or so ago
[03:35] <Keybuk> StevenK: hmm
[03:35]  * StevenK grabs a .deb from a.u.c, in leiu of LP
[03:35] <Keybuk> slangasek: hmm
[03:35] <Keybuk> Colin usually doesn't like it when I change installer code in a non-backwards-compatible way
[03:35] <blueyed> StevenK: no, you can extract a .deb (using dpkg-deb -x/-e), edit the control files, then repack (dpkg-deb -b). Works.
[03:35] <slangasek> Keybuk: can you brain-dump me what's supposed to happen here instead of udevinfo?
[03:35] <StevenK> Keybuk: Was that aimed at me, or were you aiming at slangasek?
[03:35] <Keybuk> slangasek: udevadm info
[03:35] <StevenK> blueyed: But, ew
[03:36] <StevenK> Keybuk: Why does it need to change? if [ -x /usr/bin/udevinfo ];  ?
[03:36] <Keybuk> because that doesn't exist in the udeb
[03:36] <Keybuk> it's /sbin/udevadm now
[03:37] <StevenK> But it used to exist, so if it exists, you do what it usually does, else test for /sbin/udevadm?
[03:37] <StevenK> If I'm actually making sense.
[03:37] <slangasek> right, so to avoid backwards-incompatibility, check for /sbin/udevadm first and fall back to udevinfo
[03:37] <Keybuk> yeah, that code is a bit trickier to modify if you read it
[03:37]  * slangasek watches the clock and glances at LP
[03:38] <StevenK> Keybuk: Right, it's not me being wrong, it's the code being hard. :-)
[03:38] <Keybuk> slangasek: I'm guessing this problem is somewhat urgent?
[03:39] <slangasek> Keybuk: only if we /want/ alpha2 released before break ;)
[03:39] <Keybuk> I can upload a udev package to work around the problem for now
[03:39] <slangasek> Keybuk: I think I can manage the d-i-utils side if you'd rather, now that we've pinpointed the problem
[03:40] <Keybuk> slangasek: if you're happy to do that, that's good too
[03:40] <slangasek> given that it's more correct but not much more work, yeah
[03:40] <slangasek> does udevadm info have the same syntax as udevinfo did?
[03:40] <Keybuk> yup
[03:40] <slangasek> ok
[03:41] <Keybuk> all the tools got merged together to make the installed size much smaller
[03:41] <Keybuk> since they were 90% the same code
[03:41] <Keybuk> so udevtrigger is udevadm trigger, udevsettle is udevadm settle, etc.
[03:41] <slangasek> then as soon as LP is back up to where it'll let me branch d-i-utils, I'll take care of that
[03:41] <slangasek> heh, right :)
[03:42] <Keybuk> Kay likes to change things ;)
[03:42] <Keybuk> oh, and there's at least one release note
[03:42] <Keybuk> there's a new wireless card driver that won't work properly
[03:42] <Keybuk> it's the one that makes a "wmaster" interface, I forget which
[03:42] <Keybuk> Colin has one ;-)
[03:43] <Keybuk> slangasek: meh
[03:43]  * slangasek notes that di-utils has no dependency on udev-udeb at all, that's clever
[03:43] <slangasek> meh?
[03:43] <Keybuk> I can see about half a dozen packages that use udevinfo directly
[03:43] <slangasek> within d-i?
[03:43] <Keybuk> grub-installer, partman-basicfilesystems, partman-target, ubiquity (!!)
[03:43] <slangasek> nice
[03:44] <Keybuk> the udev upload will take less time ;)
[03:44] <slangasek> yeah, please go ahead then
[03:44] <Keybuk> (udevinfo can exist as a symlink to adm, and it will work -- I just didn't put any of those in the udeb or initramfs)
[03:44] <slangasek> sure
[03:44]  * Keybuk fights debhelper
[03:44] <Keybuk> debhelper attacks
[03:45]  * Keybuk dies
[03:45] <slangasek> hmm, that's interesting, the scheduled LP downtime moved from 1am to 2am?
[03:45] <Fujitsu> It did.
[03:45] <Fujitsu> And it was extended by 30 minutes.
[03:46] <slangasek> it was? http://news.launchpad.net/maintenance doesn't mention any extension
[03:46] <Keybuk> (loss of -0ubuntu ... I got sick of uploading accidentally native packages or forgetting the orig.tar.gz)
[03:46] <slangasek> but ok, that does mean they're only 15 minutes late. :)
[03:46] <Fujitsu> See topics of here and #launchpad.
[03:46] <slangasek> yes, the topic here says it was moved, not that it was extended...
[03:47] <Fujitsu> `Estimated downtime is approx 120 mins'
[03:47] <slangasek> and where do you see that in the topic here?
[03:48] <Fujitsu> Oh, I see a shorter one was used here. Oops.
[03:50] <TheMuso> Yes.
[03:50]  * TheMuso glares at somerville32.
[03:52] <Keybuk> slangasek: ok, udev 117-3 uploaded
[03:53]  * Fujitsu wonders how it is uploaded without LP.
[03:56] <wasabi> so this has been kicking my ass for awhile now......  apt-get runs dpkg.... and when dpkg exits, apt-get locks up
[03:56] <wasabi> Looks like dpkg is defunct.
[03:57] <wasabi> cept it only does it when I don't remember to attach something to it. =/
[04:05]  * Hobbsee wonders when tjaalton will be interested in tracking regressions on the intel drivers
[04:07] <bluszcz> guys
[04:07] <bluszcz> i found weird problem
[04:07] <bluszcz> i built udebs in a https://help.ubuntu.com/community/Kernel/Compile way
[04:07] <bluszcz> but i don't have cdrom udeb
[04:07] <bluszcz> when i dig into modules/ i found, that there is no cdrom file
[04:07] <bluszcz> why?
[04:08] <bluszcz> i cannot rebuild debian-installer without cdrom, from second way - update-initramfs withot cdrom create initrd without cd module
[04:11] <bluszcz> i can make my own file modules/cdrom with sr_mod and cdrom entry
[04:11] <bluszcz> but it will be fine?
[04:11] <bluszcz> i mean enough?
[04:12] <bluszcz> and what is easiest way to build udebs?
[04:13] <slangasek> Keybuk: cheers
[04:14] <slangasek> ah, and LP is back, hurray
[04:16]  * Keybuk goes back to drawing stick figures
[04:17] <slangasek> hmm, is "20070308ubuntu23build1" the desired version number for a rebuild-only upload of d-i? :)
[04:17] <Keybuk> 20070308ubuntu23build1+but+really+20070307ubuntu22build4
[04:18] <Hobbsee> oof
[04:18]  * Hobbsee wonders what teh longest version number accepted actually *is*
[04:19] <slangasek> compiz | 1:0.6.2+git20071119-0ubuntu1~gutsy1
[04:19] <slangasek> there's a good candidate if you're looking for the longest in existence
[04:19] <Hobbsee> slangasek: i liked the xserver-xorg-input-synaptics ones for a while
[04:20] <Keybuk> Hobbsee: the firefox but-really one I think
[04:20] <minghua_> slangasek: I've always seen rebuilds of -ubuntuX just use -ubuntu(X+1) version numbers.
[04:21] <slangasek> fair enough
[04:21] <Hobbsee> slangasek: 0.14.3+revertedto+0.13.6-0ubuntu1... and then 0.14.3+seriouslythistime-0ubuntu1
[04:21] <slangasek> and sensible too :)
[04:21] <Keybuk> 1.5.dfsg+1.5.0.12+sg1.8.1.5~prepatch070716-0ubuntu1
[04:21] <Hobbsee> Keybuk: nice...
[04:21] <Hobbsee> Keybuk: qt had a but-really too, iirc
[04:22] <Keybuk> the trouble with insane version numbers is you can justify every single part of them
[04:28] <Fujitsu> !info mplayer dapper
[04:28] <ubotu> mplayer: The Ultimate Movie Player For Linux. In component multiverse, is extra. Version 2:0.99+1.0pre7try2+cvs20060117-0ubuntu8.1 (dapper), package size 3265 kB, installed size 7916 kB
[04:33] <bluszcz> anyone can help me with creating custom kernel for installer?
[04:33] <bluszcz> i tried with http://wiki.debian.org/DebianInstaller/Modify/CustomKernel, but it tells me that i have'nt got cdrom-core-modules
[04:45] <nanley>  /#ubuntu
[04:45] <nanley>  /join #ubuntu
[05:07]  * lamont waves, heads to bed.
[05:32] <bluszcz> is there any good howto about creating bootable cd with custom kernel?
[05:59] <TheMuso> c/c
[05:59] <TheMuso> ugh
[05:59] <TheMuso> go go orca
[06:03] <bluszcz> TheMuso: ayt?
[06:38] <dholbach> good morning
[06:39] <bluszcz> morning
[06:40] <dholbach> hey bluszcz
[06:43] <bluszcz> dholbach: have you experience in building debian installer kernel?
[06:44] <dholbach> bluszcz: not at all - I'd expect people who are more knowledgeable in #ubuntu-kernel
[07:21] <bluszcz> hm, anyone debian installer?
[07:22] <bluszcz> i've created dapper server install with new kernel 2.6.22, but installer shouts "lack of kernel modules"
[07:22] <dholbach> bluszcz: you could also try the mailing list
[07:23] <dholbach> did you try #ubuntu-kernel?
[07:24] <bluszcz> i've just try
[07:25] <dholbach> so best try the mailing list
[07:38] <warp10> Hi all!
[07:52] <bluszcz> hello warp10
[07:52] <warp10> bluszcz: yo!
[07:53] <somerville32> warp10, You are now known as: transwarp
[07:54] <warp10> somerville32: yep! I'm everywhere in the universe... and multiverse too :P
[07:54] <somerville32> hi5
[07:55] <warp10> :D
[07:57] <pitti> Good morning
[07:58] <somerville32> Morning
[07:58] <warp10> morning pitti
[07:59] <pitti> hey warp10
[07:59] <pitti> warp10: sorry, haven't forgotten your mail, will get to it
[07:59] <warp10> pitti: np, take your time :)
[08:10]  * pitti sighs at iwl3945; free or not, it doesn't work :/
[08:10] <dholbach> hey pitti, hey MacSlow
[08:11]  * pitti hugs dholbach and macd
[08:11] <pitti> and MacSlow, too
[08:11] <MacSlow> hey dholbach, pitti
[08:11] <MacSlow> *yawn²*
[08:11] <dholbach> :-)
[08:11]  * dholbach hugs y'all back
[08:17]  * pitti files bug 177624; anyone else who has a 3945 wifi and suffers from this?
[08:17] <ubotu> Launchpad bug 177624 in linux "iwl3945 has very poor signal reception, whereas ipw3945 works perfectly" [Undecided,New] https://launchpad.net/bugs/177624
[09:07] <geser> good morning
[09:23] <pitti> hi geser
[09:24] <geser> Hi pitti
[10:42] <Usiu> Hi
[10:44] <Usiu> Where I can get Ubuntu installer with latest xorg intel driver. The one included in gutsy 7.10 is buggy for some intel cards and cause black screen. On Debian I was using old one precompiled for new API. Now its fixed in debian and current git, but older one is a bit faster.
[10:44] <Usiu> I would like to know if there are any ubuntu snapshots with updated packages, or maybe new xorg intel driver ?
[11:07] <posingaspopular> hey all, im wondering if someone in here knew where which directory the C header files for the gcc 4.1.3 compiler are stored in kubuntu gutsy
[11:11] <cjwatson> posingaspopular: /usr/lib/gcc/i486-linux-gnu/4.1/include (depending on architecture), but do you really want the compiler-specific headers rather than just using the system default /usr/include?
[11:12] <posingaspopular> cjwatson: i don't. vmware does.
[11:12] <posingaspopular> on an x86 arch.
[11:12] <cjwatson> err, never has for me
[11:12] <slangasek> vmware asks for the location of the kernel headers, not the compiler headers.
[11:12] <cjwatson> do you have libc6-dev installed?
[11:13] <cjwatson> oh, yeah, what slangasek said too
[11:13] <posingaspopular> it's asking for which the matching dir in 2.6.17-12-generic kernel
[11:13] <posingaspopular> ah yea i knew i had the question wrong
[11:13] <cjwatson> install the linux-headers package corresponding to whatever linux-image package you have, and run 'dpkg -L' on it after installation
[11:13] <cjwatson> once you have it installed, though, vmware should find it automatically
[11:14] <cjwatson> (so linux-headers-2.6.17-12-generic is probably the one you want)
[11:15] <posingaspopular> ah i see. this is where i should give up, because i have the 2.6.22-14 headers installed and that's why virtualbox hated me so much
[11:15] <posingaspopular> so installing vmware wouldn't actually sort the problem out. hmm
[11:16] <cjwatson> why not just install the right headers/
[11:16] <cjwatson> ?
[11:16] <cjwatson> they coexist ...
[11:16] <posingaspopular> because apt can't find them ;p
[11:16] <posingaspopular> that's where my life has been for the past 5 night
[11:16] <posingaspopular> it's very exciting
[11:17] <posingaspopular> well it has 'no instillation candidate'
[11:18] <pitti> lool: great merging work on gtkmm & friends!
[11:18]  * pitti hugs lool
[11:21] <cjwatson> posingaspopular: exactly what package name are you installing, and which release of Ubuntu are you using?
[11:21] <cjwatson> (I'm assuming 6.10, so 'edgy' should be in your /etc/apt/sources.list)
[11:21] <posingaspopular> i *think* it's commented out of the repos
[11:22] <cjwatson> and what does 'uname -a' say?
[11:22] <posingaspopular> im on gutsy (kubuntu) trying to install vmware-server
[11:22] <posingaspopular> 2.6.17-12-generic
[11:22] <posingaspopular> uname -r ^
[11:22] <cjwatson> so how come you're using edgy's kernel on gutsy?
[11:22] <slangasek> which is not the gutsy kernel
[11:24] <posingaspopular> um afaik, i upgraded from edgy to feisty to gutsy
[11:24] <posingaspopular> however, ls_release -a tells me im running gutsy
[11:24] <slangasek> without ever rebooting, then?
[11:24] <cjwatson> you may well be otherwise, but your kernel is out of date
[11:24] <posingaspopular> i have no idea why my computer is doing this
[11:24] <cjwatson> install the 'linux' package
[11:24] <posingaspopular> because i have rebboted many times
[11:24] <posingaspopular> sudo apt-get install linux?
[11:24] <cjwatson> you didn't really complete the upgrade process, even though it may have seemed as if you did
[11:24] <cjwatson> yes
[11:25] <cjwatson> if you had used the release upgrade tool, then it should have taken care of this for you
[11:25] <cjwatson> if you did it by hand with apt, then you may need to do some things yourself
[11:26] <posingaspopular> i did one upgrade with adept (to feisty) and one via CLI
[11:27] <pitti> posingaspopular: your default selection in the grub boot menu might be wrong then :)
[11:27] <posingaspopular> that's most likely. however this grub selection is the only one that boots...
[11:27] <posingaspopular> which might have something to do with the kernels being all out of sync
[11:32] <posingaspopular> okay thanks all!
[11:32]  * posingaspopular heads off with answers and some understanding for a change ;p
[13:00] <soren> I'm working on the new libvirt version. It's started to use PolicyKit, and my polkit-fu isn't strong..  It's using polkit to accept/reject users' access to a unix socket. How is this usually accomplished? Does the socket usually have 0777 permissions and the polkit will take care to approve or reject the user *after* the connection has been established, or are the sockets usually root/root owned and 0700 and then polkit will determine ahead of time
[13:02] <soren> I'm guessing the former...
[13:08] <pitti> tjaalton: FYI, current alternate install in vmware still has the wrong resolution; I do have an xorg.conf now, but it's totally empty
[13:08] <pitti> soren: if the socket is 0777, there's little point in faking access control to it in the UI?
[13:09] <soren> pitti: Did I mention my polkit-fu isn't strong? :)
[13:10] <tjaalton> pitti: hrm.. could you post your /var/log/casper.log somewhere?
[13:10] <soren> I was thinking that after you connected, some polkit magic would happen out-of-band that would end up either accepting or rejecting the connection.
[13:11] <Mithrandir> I thought that was how policykit worked.
[13:12] <Mithrandir> basically the app would say "yo, you're not authed, go auth yourself!", then it'd wait for pk to ack the auth before going ahead.
[13:12] <pitti> soren: ah, so PK doesn't control access to the socket, the socket talks to the service which then uses PK to verify privs?
[13:13] <soren> pitti: That's what I'm asking, basically. The docs are not very precise, so I'm trying to work out how this is *usually* done.
[13:14] <Keybuk> usually anyone can send a request to you
[13:14] <Keybuk> and you reply with an error indicating not auth'd, and hinting what kind of auth they need
[13:14] <Keybuk> the client responds to the error by running the auth helper, and then tries again
[13:15] <Kmos> pitti: can you give back nip2 on sparc (hardy) ?
[13:15] <pitti> Kmos: done
[13:15] <Kmos> pitti: thanks
[13:15] <tjaalton> pitti: err, I meant /var/log/installer/casper.log
[13:16] <tjaalton> duh
[13:16] <tjaalton> alternate install -> no casper.log :)
[13:16] <pitti> right
[13:16] <pitti> Kmos: nothign to give back, it's built everywhere
[13:16] <soren> Keybuk: Ok, so translating that to my scenario: Any can open a connection to the UNIX socket? and then polkit works out the policy details out-of-band, correct?
[13:16] <Kmos> pitti: it says on LP: hardy sparc   Failed to build
[13:17] <pitti> Source version: 7.12.5-2ubuntu1
[13:17] <pitti> sparc: Successfully built
[13:17] <pitti> Kmos: maybe you look at an old version?
[13:17] <tjaalton> pitti: well, let's try /var/log/installer/syslog instead
[13:17] <Kmos> pitti: yep, it's changed..
[13:17] <Kmos> sorry
[13:17] <Keybuk> soren: as I understand it, yup
[13:18] <soren> Keybuk: Cool. Thanks.
[13:18] <Keybuk> otherwise how would it connect?
[13:18] <Keybuk> you'd have to have an ACL on the socket, and some kind of "I auth'd, now change the permissions" notification
[13:18] <Keybuk> and then you'd need some kind of un-change the permissions as well
[13:18] <Keybuk> which would make "auth once" harder, etc.
[13:18] <Mithrandir> Keybuk: it could auth to policykit which would then pass the fd back to the process requesting access.
[13:19] <Mithrandir> so you'd go "policykit, I want to talk to food", then policykit goes "you need to solve a math question for me then; what's sqrt(2+2)?", "uh, 2?" "here's your fd which is connected to food".
[13:20] <Keybuk> Mithrandir: that would require policykit being a process
[13:20] <Keybuk> and that process would have to have access to your X session to ask these questions
[13:20] <Keybuk> and that process would have to be privileged in lots of different ways to pass back the fds, etc.
[13:21] <soren> Keybuk: I'm not sure. I thought polkit had a privileged process that i might be able to use to pass through data or something.
[13:21] <Keybuk> no
[13:21] <Mithrandir> Keybuk: yes, it'd have some ramifications for the rest of the system.  And the app would be the one responsible for asking the question, not policykit.
[13:21] <Mithrandir> Keybuk: it'd be a similar design to pam, really.
[13:21] <Keybuk> you could do that *with* PAM :-)
[13:22] <pitti> soren: the only long-standing PK process is the daemon that maintains the db (user -> privs mapping)
[13:23] <cjwatson> pitti: re tjaalton's question, installing with DEBCONF_DEBUG=developer on the kernel command line might produce more useful information
[13:23] <Keybuk> pitti: isn't that a dbus service, so it's not long-standing?
[13:23] <pitti> cjwatson: ah, it will land in syslog then?
[13:24] <pitti> Keybuk: ah, indeed, mixed that up with ConsoleKit
[13:24] <pitti> ConfusionKit
[13:24] <ion_> :-D
[13:24] <Keybuk> just wait until DeviceKit comes along
[13:25] <bluszcz> confusion or illusion
[13:25] <Mithrandir> KitCatKit
[13:25] <soren> Ok... /me is starting to grok policykit
[13:25] <ion_> Let’s rename Linux as KernelKit.
[13:25] <pitti> Keybuk: I still need a name for the rewritten restricted-manager without 'restricted' in the name; I seriously considered 'DriverKit' :)
[13:25] <pitti> (for about 2.5 seconds)
[13:25] <bluszcz> pitti: Bad2TheBoneK1t
[13:26] <cjwatson> pitti: yes
[13:27] <Keybuk> WhereAreYouKit
[13:27] <Keybuk> NeedYouNowBuddy
[13:27] <ion_> KITTKit
[13:28] <maswan> Kitty!
[13:29] <pitti> alternates should be good now, desktops rebuilding (hopefully working now)
[13:30] <tjaalton> l-r-m needs to fix the nvidia/fglrx Provides
[13:30]  * Hobbsee waves
[13:31] <pitti> tjaalton: doing another test install with DEBCONF_DEBUG now
[13:33]  * Hobbsee wonders what the 8heck8 has happened.
[13:33] <tjaalton> pitti: thanks. I noticed that I have vmware-server installed myself, so will test that myself too
[13:33] <pitti> tjaalton: I'll attach the log to the bug I filed previously, ok?
[13:33] <tjaalton> pitti: sure
[13:33] <soren> Hobbsee: ?
[13:34]  * Hobbsee appears to have no shift, tab, or capslock
[13:34] <soren> Hobbsee: Cat took them?
[13:34] <Hobbsee> or escape
[13:34] <StevenK> Ah, hence the '8heck8'
[13:34] <Hobbsee> i don't know.  was working fine before1
[13:36] <Hobbsee> wait.  tab works, alt doesnt'
[13:36] <pitti> Hobbsee: sometimes happened to me when using vmware
[13:36] <pitti> a 'setxkbmap us' fixed it again
[13:37] <Hobbsee> pitti: hrm. then restart x, or/
[13:37] <pitti> no, just that
[13:37] <tjaalton> damn, the 3G connection is faster than my ADSL.. should use that for cd images :P
[13:37] <pitti> restarting X would help, too, of course
[13:37] <pitti> Hobbsee: i. e. it killed the 'outside' gnome's shift when vmware was running
[13:42] <tjaalton> does anyone know what it takes to integrate wvdial with network-manager?
[13:42] <Usiu> Hi
[13:42] <Usiu> how to update packages on ubuntu live cd ?
[13:42] <Hobbsee> YAY!!!!
[13:42] <Hobbsee> tjaalton: btw, when will you be interested in tracking regressions for this intel driver?
[13:42] <soren> This channel is not for support. #ubuntu is what you want.
[13:42] <Hobbsee> Usiu: #ubuntu for support
[13:43] <tjaalton> Hobbsee: when they concern the 965GM I have? :)
[13:43] <Hobbsee> tjaalton: oh, i thought you cared about all of them.  got it.
[13:43] <tjaalton> hehe
[13:44] <Hobbsee> pity
[13:44] <tjaalton> actually, bryce is working more closely with intel bugs
[13:44] <Hobbsee> ah right
[13:44] <Hobbsee> BenC: i lie.  my wifi does work.
[13:44] <tjaalton> Hobbsee: what this time?-)
[13:44] <Hobbsee> tjaalton: just slow to refresh
[13:44] <tjaalton> EXA goodness
[13:44] <Hobbsee> tjaalton: nothing new...but more people will start testing
[13:44] <Hobbsee> yeah.  if slow == good, then..
[13:45] <pitti> tjaalton: n-m> I was told that 0.7 supported modems now?
[13:45] <tjaalton> pitti: oh good
[13:49] <tjaalton> bbl
[13:54] <Hobbsee> TheMuso: about time, too!
[13:58] <StevenK> Heh
[13:58] <Keybuk> pitti, MacSlow: pre-ping
[13:59] <StevenK> pitti: curl uploaded
[14:04] <soren> Ok, policykit experts. When I try to do something I'm allowed to, but haven't authenticated to do yet, what's supposed to happen? Currently, I just get a "please go away" from the app, and it terminates (it's a cli). If I "polkit-grant --gain blahblah", give my password, and then try again, it works.
[14:10] <soren> Is it the job of the application itself to do the magic required, or does libvirt have some built in mechanisms for acquiring the privileges required?
[14:20] <pitti> tjaalton: I attached the installer syslog to bug 172821
[14:20] <ubotu> Launchpad bug 172821 in xorg-server "[hardy] only get 800x600 in vmware" [Undecided,New] https://launchpad.net/bugs/172821
[14:20] <soren> Continuing the flow of policykit questions: I'm curious why policykit _configuration_ is under /usr/share ?   How does that make sense?
[14:24] <pitti> soren: the app needs to invoke a dbus call to spawn the gnome/kde policykit auth dialog itself
[14:24] <pitti> soren: look at gnome-mount for an example
[14:24] <pitti> soren: i. e. normally you just get "NOAUTH" (denied, but you can authenticate as admin)
[14:24] <soren> pitti: Oh, it's just a dbus call? Cool.
[14:25] <pitti> then you invoke the auth frontend, and if you type in the correct auth, the PK DB will then know that you have the token and return "YES" for the privileged op
[14:27] <soren> pitti: I see.
[14:27] <pitti> soren: too hard for the dbus backend to poke a hole back to your X session
[14:29] <soren> pitti: Hmm... I suppose.
[14:30] <soren> pitti: Ok, this sounds useful to know, but it doesn't seem like the right workflow here, though. I think I just want to allow access to a particular group, no questions asked.
[14:30] <soren> ...which seems to be simple enough, but I feel dirty putting configuration stuff in /usr/share.
[14:30] <pitti> soren: (I don't know what your goal is)
[14:30] <soren> pitti: :) Sure.
[14:31] <pitti> soren: right, group-based access isn't too evil either
[14:39] <pitti> slangasek, BenC: I filed bug 177666 about the unionfs oops which kills the desktop CDs
[14:39] <ubotu> Launchpad bug 177666 in linux "desktop CD boot hangs eternally; kernel oops in unionfs_create()" [High,New] https://launchpad.net/bugs/177666
[14:50]  * soren kicks policykit... hard
[14:51] <soren> pitti: Well, group-based access might not be evil.. Another thing it's not is "supported".
[14:53] <soren> pitti: The <match> directive supports two attributes: action and user.
[14:54] <soren> I think that concludes my policykit adventure for now.
[14:56] <Keybuk> which group?
[14:56] <soren> Not "admin".
[14:56] <Keybuk> you could always patch PK to add group-based matching
[14:57] <Keybuk> why "not admin" ?
[14:57] <Keybuk> that's hard to authenticate to
[14:57] <Keybuk> though PK in theory is supposed to do away with group-based matching
[14:57] <soren> WEll, because it can grant access based on whether or not you're in "admin".
[14:57] <Keybuk> how do you mean?
[14:57] <soren> Er... Ok, I'll try again..
[14:57] <soren> I wanted to grant access based on membership of the "libvirt" group.
[14:58] <Keybuk> right, but that's the kind of group that PK is supposed to make no longer necessary, isn't it? :)
[14:58] <soren> Er.... it might be?
[14:58] <Keybuk> the idea of PK is that you do:
[14:59] <Keybuk>   "can I access this device?"
[14:59] <Keybuk>   "no, enter your password"
[14:59] <Keybuk>   "ok, now can I access this device?"
[14:59] <Keybuk>   "yes"
[14:59] <soren> Well, every user has a password? How do I limit access then?
[14:59]  * soren is missing something obvious, it seems
[14:59] <Keybuk> well, the RH model assumes a root password
[15:00] <Keybuk> so for "secure" things
[15:00] <Keybuk>   "no, enter the root password"
[15:00] <Keybuk> we would probably want to extend that to recognise the admin group
[15:00] <Keybuk> so if you're in admin, it could respond "no, enter your password"
[15:00] <soren> That's already done, afaics.
[15:00] <Keybuk> and if you're not, it could respond "no."
[15:00] <Keybuk> (or "no, enter the root password" if it's set)
[15:00] <Keybuk> that way, the access is granted for you
[15:00] <Keybuk> and you had access to add yourself to the group *anyway*
[15:00] <Keybuk> so this bypasses the requirement for pre-authorising yourself to use something
[15:00] <soren> Well, I want a different set of users to have access to this.. How would I accomplish that in a policykity way?
[15:01] <Keybuk> authorisation can be permanent
[15:01] <Keybuk> you can use PK to add "this user can always use this device" to its db
[15:01] <Keybuk> this bit of PK replaces the groups admin tab
[15:01] <soren> ergh...
[15:01] <soren> So if I have this sort of thing in ldap, I'm screwed?
[15:02] <Keybuk> "this sort of thing" being?
[15:02] <soren> I don't, but I could have.
[15:02] <soren> Well, if I used to grant access to stuff based on group membership..
[15:02] <soren> I'd have that info stored in ldap. With policykit, I'd have to log into every machine, do some "getent group foo | while read ...." magic, etc?
[15:03] <Keybuk> errr?
[15:03] <Keybuk> why?
[15:03] <Keybuk> http://people.freedesktop.org/~david/Screenshot-Grant.png
[15:03] <soren> How else would I be granting the privilege?
[15:04] <Keybuk> I don't see any reason that PK couldn't use ldap for its auth db as well
[15:05] <soren> Ok, I'll explain the scenario, I'm working with here..
[15:06] <stgraber> asac: around ?
[15:06] <asac> stgraber: yes
[15:07] <soren> libvirt allows a user to connect to a running qemu or kvm instance. Up until now, this access has been granted by membership of a group (which owned a certain UNIX socket). If I have a cluster of machines running virtual machines, and I want to give a particular user access to the libvirtd instance on every node in the cluster... How would I do this now that policykit is doing the authorisation?
[15:08] <soren> This might all be very clear to me if the clients actually supported policykit properly. Right now, they just tell me to sod off, if I haven't polkit-grant'ed beforehand.
[15:11] <Keybuk> well
[15:11] <Keybuk> ok
[15:11] <Keybuk> so you have a permission
[15:12] <Keybuk> "Access to running virtualisation instance"
[15:12] <soren> Right.
[15:12] <Keybuk> you abstract this permission with a group, "libvirt"
[15:12] <soren> Right.
[15:12] <Keybuk> so you assume that members of this group have this permission
[15:12] <Keybuk> and you enforce this with privilege
[15:12] <Keybuk> e.g. only members of the group can write to a file, or members of the group can execute a binary
[15:12] <soren> Right.
[15:14] <stgraber> asac: I just switched from 2.6.22 to 2.6.24 and my wireless interface is now called "wlan0_rename", this happened with the switch from ipw3945 to iwl3945. Is there any known work around for that (not that I don't like to type this long name but I would prefer something shorter) ? Do you know of an open bug or shall I file one (against udev ?) ?
[15:15] <Hobbsee> stgraber: do you get a LED for your wifi nwo?
[15:15] <Keybuk> stgraber: known bug
[15:15] <stgraber> Hobbsee: what do you mean ?
[15:15] <Keybuk> soren: the problem here is that the number of permissions is very large
[15:15] <Keybuk> and the number of groups a user is limited to is much smaller
[15:16] <Keybuk> so we tend to lump them into large super-groups
[15:16] <Hobbsee> stgraber: a flashing light, showing that your wifi is active, and hwo much data it's sending?
[15:16] <Keybuk> "plugdev"
[15:16] <Keybuk> "admin"
[15:16] <Keybuk> etc.
[15:16] <soren> Keybuk: Uh huh..
[15:16] <Keybuk> the other problem is that for more complicated permissions, the application may need to keep the privilege
[15:16] <Keybuk> so you have a privileged application running inside an X session
[15:17] <stgraber> Hobbsee: On my laptop I just have a static LED just showing that my wireless is powered up
[15:17] <Pici> stgraber: but that works for you?
[15:18] <Keybuk> PK attempts to solve these
[15:18] <Keybuk> permissions become first class
[15:18]  * soren is still waiting for the epiphany to hit him
[15:18] <Keybuk> you aren't "a member of admin"
[15:19] <stgraber> yes, but I don't think it's driver related here as even with iwl3945 unloaded it's still on
[15:19] <Keybuk> you have "permission to change the system timezone"
[15:19] <soren> Keybuk: How did I get that?
[15:19] <Hobbsee> stgraber: ah, right.  strange.
[15:19] <Keybuk> permissions can also be abstract, rather than specific matches
[15:19] <Keybuk> groups only allow "these users"
[15:19] <Keybuk> permissions can have default grants based on meta
[15:19] <Keybuk> ie. "all users a local console have permission to use local devices"
[15:20] <Keybuk> "soren has permission to change the system timezone if he is on the local console"
[15:20] <Keybuk> etc.
[15:20] <soren> Keybuk: Ah, yes. The local-users-are-trustworthy thing.
[15:20] <soren> Keybuk: Ok.
[15:20] <Keybuk> these are done by entries in the authorisation db
[15:20] <Keybuk> consider the PK auth db a souped up version of the groups file
[15:20] <Keybuk> it says who can do what
[15:21] <Keybuk> if you don't have permission, it's possible to authorise again to get it
[15:21] <Keybuk> (if the permission allows that)
[15:21] <soren> Ok.
[15:21] <Keybuk> so you might have permission if you enter your password
[15:21] <Keybuk> or the password of the root user
[15:21] <soren> Makes sense.
[15:21] <Keybuk> first time you get no, you run a helper to pop up the auth dialog, second time you get yes
[15:21] <Keybuk> and that permission can be one-shot, per session or forever
[15:21] <Keybuk> you can also do speculative requests
[15:21] <tjaalton> pitti: I'm afraid the log isn't helpful, but I'll try to install it myself now to see where it fails
[15:22] <Keybuk> like changing the timzone
[15:22] <Keybuk> the dialog can show the timezone always
[15:22] <Keybuk> and since you always have permission to change YOUR timezone, it can let you set that
[15:22] <Keybuk> it can make a speculative request to PK to determine whether you have permission to change the SYSTEM timezone
[15:22] <Keybuk> if it gets "no", it just lets you set yours
[15:23] <Keybuk> if it gets "no, auth first", it can show the disabled "set system timezone too" button with a lock next to it - clicking the lock will make you auth, and undisable the button
[15:23] <Keybuk> if it gets "yes", the button is enabled
[15:23] <soren> Again assuming that users-at-the-console-are-not-evil ?
[15:24] <Keybuk> sure
[15:24] <Keybuk> you can add any assume you want
[15:24] <Keybuk> that's the idea
[15:24] <pitti> soren: users-at-the-console-can-be-as-evil-as-they-like
[15:24] <Keybuk> if there was a permission grant for users at the console, they would see the button always
[15:24] <soren> Keybuk: No, I mean..
[15:24] <soren> er..
[15:25] <soren> It seems to me that if you're not at the console, you're not granted access to much at all.
[15:25] <Keybuk> that's just defaults
[15:25] <soren> If you're at the console, all you have to do is be able to type your password, and the world is at your feet.
[15:25] <Keybuk> consider PK permissions as ACLs
[15:25] <Keybuk> the ACL can have a reasonable default
[15:25] <Keybuk> it just happens that many of those defaults are "local console after entering password"
[15:26] <Keybuk> you can set the default for any permission to whatever you like
[15:26] <Keybuk> it can be default to everyone, and you can deny certain users
[15:26] <soren> Ok... I think that's a pretty crappy default, but ok.
[15:26] <Keybuk> it can be default off, with users explicity added
[15:26] <maswan> soren: Makes for a resonable default for a personal [home] desktop, for large scale deployment you'd probably want a different policy set
[15:26] <Keybuk> default PER permission
[15:26] <Keybuk> there's no "system default"
[15:26] <soren> Keybuk: Sure.
[15:26] <Keybuk> ie. if you add a new permission, the default is "no access"
[15:26] <Keybuk> and for most things, default being console user after password makes sense
[15:26] <Keybuk> it's their laptop
[15:26] <soren> Keybuk: Or someone else's.
[15:27] <Keybuk> depends on what the permission is
[15:27] <soren> They might just have gotten a login on it.
[15:27] <Keybuk> accessing usb devices etc.
[15:27] <lamont> Keybuk: can grant "users in the group 'foo' may change the timezone"?
[15:27] <soren> Surely, there's a reason we don't make adduser automatically add every new user to "admin"?
[15:27] <lamont> that would make it easier to integrate PK in a multi-platform environment
[15:27] <Keybuk> lamont: why would you?
[15:28] <lamont> my Solaris box doesn't have PK yet, but all the machines share a user/group map in NIS
[15:28] <lamont> e.g.
[15:28] <Keybuk> so just use NIS
[15:28] <Keybuk> if you have groups, you don't need to use PK
[15:28] <soren> Aha!
[15:28] <Keybuk> why attempt to use both systems at the same time
[15:28] <lamont> one reason would be because a distro forced it on me.
[15:28] <Keybuk> ?
[15:28] <lamont> another would be because it's shiny
[15:29] <Keybuk> if you're interested in PK, drop the group and port to PK
[15:29] <lamont> ok.  makes sense from that perspective
[15:30] <lamont> though allowing groups to be granted perms would possibly help transition.
[15:30] <soren> Keybuk: Ok.. Help me out here.. Let's say I'm the admin of this cluster for machines running a stack of kvm instances and I want to grant a set of users access to manage those... In the brave new world of policykit... How do I do that?
[15:30] <maswan> Keybuk: Hm.. How would you restrict permissions to an arbitraty subset of console users? Like me and my sister knows what we're doing, but the rest of the family shouldn't be able to mess up too badly?
[15:31] <lamont> or allow shortcutting, by using the group as nothing more than (uh) "a group of similar users"
[15:31] <lamont> soren: it sounds like you do it with "for user in .....; do ..."
[15:32] <soren> lamont: That's what I suggested 20 minutes ago, and I was met with a stack of question marks.
[15:32] <pitti> maswan: don't give them admin?
[15:32] <lamont> soren: right.  groups have nothing to do with permissions other than allowing you to specify one token for a group of users. (in a _GROSSLY_ oversimplified version of reality)
[15:33] <lamont> pitti: "local console users can..."
[15:33] <Keybuk> soren: you grant the permission
[15:33] <maswan> pitti: admin is just a group membership, PK does away with all group memberships (AFAICT)
[15:33] <lamont> now add in maswan's cousin who comes to visit, and he wants to say "everything I can do, let him do too"
[15:33] <pitti> lamont: right, but if you have a privilege you don't want to grant to local console users, then just grant it to admins
[15:33] <Keybuk> maswan: "you can do it if you're on the console", "your system can do it if you're on the console"
[15:33] <soren> Keybuk: To each user on each system?
[15:34] <pitti> i. e. it does not make sense to restrict shutting down the system to admins
[15:34] <Keybuk> soren: or you write a PK LDAP backend and make it read your LDAP db
[15:34] <pitti> since if you are on the console, you just press teh power button
[15:34] <soren> Keybuk: Ok.
[15:34] <pitti> but it does make sense to restrict creating new users or changing TZ to admins
[15:34] <lamont> soren: and then you put your groups in the PK LDAP db. -)
[15:34] <pitti> maswan: no, admin is still relevant in Ubuntu
[15:34] <soren> lamont: Exactly. :)
[15:35] <lamont> pitti: _ALL_ groups die in Keybuk's PK world.
[15:35] <pitti> lamont: hm, not in hardy at least
[15:35] <lamont>  /etc/group becomes an empty file
[15:35] <Keybuk> no, you need admin
[15:35] <Keybuk> since admin is our alternate for root
[15:35] <lamont> Keybuk: so let me say 'group admin' in granting PK privs
[15:35] <maswan> I don't quite see why all groups should die, just the audio/usb/video/blah/blah.
[15:35] <pitti> later we might change Ubuntu to define admins in terms of PK policies instead of admin members, but right now that's the status quo
[15:35] <Keybuk> lamont: I think you should be able to
[15:36] <pitti> lamont: right, system groups/users make perfect sense and should stay
[15:36] <lamont> then why are we arguing?
[15:36] <soren> Keybuk: Why not just put that into /etc/PolicyKit/PolicyKit.conf?
[15:36] <Keybuk> but you should avoid adding a permission group and granting to it
[15:36] <lamont> ah, so no new groups, just the grandfathered ones?
[15:37] <pitti> lamont: we'll get rid of some that we can better express with PK privileges, too
[15:37] <pitti> lamont: like, plugdev, cdrom, audio
[15:37] <Keybuk> not even just the grandfathered ones
[15:37] <Keybuk> just the sensible ones
[15:37] <lamont> Keybuk: as defined by who? the sysadmin?
[15:37] <soren> Who is allowed to grant privileges and who's not could be in the PK config, too? That would do away with /etc/groups completely.
[15:37] <Keybuk> lamont: THE DISTRO
[15:37] <Keybuk> oops
[15:37] <pitti> soren: you still need /etc/groups for the system groups
[15:37] <soren> pitti: Like what?
[15:38] <Keybuk> admin, groups for daemons
[15:38] <maswan> I still see a need (with larger usersets) to have groups as _groups_, where they are set of users. It would be useful if PK could have policy decisions on those too, instead of having huge lists of users listed there too
[15:38] <soren> Oh, that's deemed out-of-scope for policykit?
[15:38] <soren> Keybuk: Well, admin could in theory be maintained directly in pk's config.
[15:38] <Keybuk> right, a daemon running as a group to reduce its privilege is fine
[15:38] <pitti> soren: dhcp, syslog, ssl-cert, messagebus, hal,
[15:38] <maswan> But I guess the PK.conf could have some #include statements for lists of users or so
[15:38] <Keybuk> soren: only if you made sudo use PK :)
[15:38] <Keybuk> maswan: agree it should be able to check groups of users
[15:38] <soren> Keybuk: Sure.
[15:39] <pitti> soren: we should get rid of the groups which define privs for users, but not the ones which separate away the processes of daemons
[15:40] <soren> pitti: Hm... Right.
[15:40] <stgraber> and what about the groups for directory access ? we still need those too (like www-data) no ?
[15:40] <lamont> Keybuk: so i'm an admin of a group of machines at a university, and I install your distro.  I need to grant specific permissions to a group of people who will be using certain resources on the computer.  how do I know whether to add them to a new group, or to use PK?
[15:40] <pitti> stgraber: right
[15:40] <pitti> lamont: usually you only fiddle with groups like admin
[15:41] <soren> Well, that's just until IOKit comes along.
[15:41] <pitti> lamont: AFAICS, PK privs are not usually granted by sysadmins for users
[15:41] <soren> Then you politely ask IOKit to return a list of files in a directory or to open a file an hand you the fd or something.
[15:41] <pitti> since they mostly describe dynamic actions, like changing the network in nm-applet or mounting an USB stick
[15:41] <lamont> ok.  so it's in a different realm of things then.
[15:41] <Keybuk> lamont: you use PK
[15:42] <Keybuk> pitti: sure they are?
[15:42] <pitti> Keybuk: eventually, I agree, but not in Hardy
[15:43] <pitti> but with the current PK version you usually don't
[15:43] <lamont> pitti: I wasn't talking about hardy... I was talking about keybuk's distro where everything has migrated to his endgame.
[15:43] <Keybuk> right
[15:43]  * Keybuk is talking about Ubuntu 10.04+
[15:43] <pitti> ah, ok; misunderstood that then
[15:43] <pitti> Keybuk: you're planning ahead well :)
[15:43] <Keybuk> yes
[15:43] <lamont> 10.06. :)
[15:43]  * Keybuk is actually, quite seriously, doing 10.04 planning
[15:44] <Keybuk> I can't decide what codename to use <g>
[15:44] <Keybuk> lamont: you expect it to be late?
[15:44]  * pitti counts
[15:44] <Keybuk> pitti: I liked "Ubuntu Odyssey" because it's 2010
[15:44] <Keybuk> but then I realised that the ship in 2010 was the Leonov
[15:44] <pitti> it's "L", isn't it?
[15:44] <Keybuk> and that begins with "L"
[15:44] <lamont> Keybuk: nah... 10.03 if you must... it's just convenient when LTS != *.{04,10}
[15:44] <Keybuk> lamont: hardy is 8.04 LTS
[15:44] <lamont> yeah
[15:45]  * lamont just isn't sure how to encode 'LTS' as a number. :)
[15:45] <Keybuk> 1+5
[15:45] <soren> Ok, disregarding what we're doing in Hardy, what we'll be doing in hardy+x.. Do you guys really consider granting administrative privileges to any user at the console (provided he remembers his password) as sensible default security policy?
[15:45] <lamont> ==6.  see! :)
[15:46] <pitti> lamont: easy: $ echo LTS | od -h :)
[15:46] <lamont> soren: admin privs, no.  access to sound/display/etc? sure.
[15:46] <pitti> soren: no, not really
[15:46] <soren> Ok. Good!
[15:47] <pitti> soren: not as long as we still have systems with multiseats and physically protected computers (where you can't just press the power button, etc.)
[15:47] <soren> You had me going for a second there..
[15:47] <pitti> for most computers out there you are root, since they don't have physical protection
[15:48] <pitti> but if you use encrypted disks, and/or physical hardening, then the notion of an admin can be enforced
[15:48] <pitti> or, rather, *not* being one :)
[15:49] <Keybuk> multiseat -> ConsoleKit :-)
[15:49] <soren> I really, really don't agree with that.
[15:49] <pitti> soren: the great thing about PK is right now that you can dynamically grant certain aspects of root where it makes sense (network-manager, USB mount, etc.) through a consistent system rather than through endless suid root wrappers
[15:49] <Keybuk> (which provides PK with info)
[15:50] <pitti> soren: you don't agree with enforcing non-admin privs through encryption/physical security?
[15:50] <soren> pitti: Sure.
[15:50] <soren> pitti: Not as the only measure, no.
[15:50] <pitti> soren: maybe I didn't express myself correctly
[15:51] <soren> pitti: I've seen on TV that the type of lock I have on my front door can be picked in < 2s if you know how and got the right tools. I still lock my door at night.
[15:51] <pitti> soren: if I walk to your desktop and you didn't put a big iron lock on it, then I am root on this machine
[15:51] <pitti> soren: that's physical security
[15:51] <soren> pitti: Not without me noticing it.
[15:52] <soren> pitti: I also don't leave a root prompt open and no screensaver when I lave a machine.
[15:52] <Keybuk> reboot, init=/bin/bash
[15:52] <pitti> soren: as long as I can reboot, I win
[15:52] <pitti> soren: unless you encrypted your disks, as I said
[15:52] <Keybuk> or since you've broken into the house, you can just take the computer out with you
[15:52] <soren> I know.
[15:53] <soren> And since the lock on my door can be picked, I might as well put my laptop outside the door with a root prompt open?
[15:53] <cjwatson> Keybuk: 'h' + 4 == 'l' - don't see a problem with that for 10.04
[15:53] <pitti> so, I was just saying that, while physical access is usually root, there are means to defend against this, and thus we shuold keep a difference between admins and mere-mortal users forever
[15:54] <pitti> soren: no? who was claiming that?
[15:54] <Keybuk> cjwatson: "that" being?
[15:54] <cjwatson> Keybuk: Leonov
[15:54] <soren> pitti: Well, you. By extension.
[15:54] <Keybuk> :-)
[15:54] <pitti> soren: hm, I said exactly the opposite
[15:54] <soren> pitti: Since they can break in easily, and just snatch the machine anyway, why even bother locking?
[15:54] <soren> pitti: Assume no encryption. Just for the sake of the argument.
[15:55] <pitti> soren: well, most humans still have some sort of conscience/respect/call it what you want to not do that :)
[15:55] <pitti> and we have laws, polices, etc.
[15:55] <soren> pitti: You're saying that if you can get within arm's length of my box (no encryption), you're root on it.
[15:56] <pitti> soren: but e. g. since (I assume) you don't question your wife getting around in the house, your wife has root on your box regardless of whether you decide to put her into 'admin'
[15:56] <Keybuk> soren: also bear in mind that if you had to type your password for every single operation it would
[15:56] <pitti> soren: right, exactly
[15:56] <Keybuk>  a) drive you nuts
[15:56] <Keybuk>  b) get you so used to typing it, you'd be vulnerable to phishing attacks
[15:56] <soren> pitti: Then why don't we leave a root shell open on one of the ttys?
[15:56] <Keybuk>  c) make you more vulnerable to snooping
[15:56] <Keybuk> etc.
[15:56] <pitti> soren: you just as well can, it doesn't matter
[15:56] <soren> pitti: We could make tty6 always be a perpetually logged in root shell.
[15:56] <Keybuk> it's about finding a balance between the two
[15:57] <pitti> soren: right, it wouldn't make a difference security-wise
[15:57] <Keybuk> everything as root <----------------------------------> auth for everything
[15:57] <pitti> soren: if you boot into rescue mode, you get exactly that
[15:57] <Keybuk> we try and be somewhere in the middle
[15:57] <soren> pitti: Yes, but you have to reboot.... At the very least,someone will notice.
[15:58] <pitti> soren: in fact, if people would use that instead of using sudo under X you actually increase your defences against local trojans
[15:58] <pitti> soren: notice> depends on how thorough you are, but sure; but once you do, the damage is done already
[15:59] <soren> pitti: I'm perfectly aware that anyone who get within arm's length of me could stab me, but I don't walk around handing out knives.
[15:59] <pitti> but usually you trust the people you share your house with, so that shouldn't be auch an issue
[15:59] <pitti> and at least in our university, the computers had some physical protection
[16:00] <pitti> and the servers with the actually interesting bits were quite heavily stored and locked away
[16:00] <pitti> so you just have to add more physical protection the less you trust the people who can access it
[16:00] <pitti> soren: hm, I think I have lost what we are actually discussing about
[16:00] <soren> Ok. Do you agree that it's very likely that your machine undiscovered security bugs somewhere?
[16:00] <wasabi> What we really need is AppArmor for everything. ;)
[16:00] <wasabi> Oh, we have it!
[16:01] <pitti> soren: yes, I do agree
[16:01] <soren> pitti: Well, in that case, I have root on your box regardless. You might as well hand it over?
[16:01] <pitti> soren: you are a core-dev; upload a new coreutils or something else I have installed and you got me
[16:01] <soren> pitti: No? Why not? Because it shouldn't be any easier than absolutely necessary?
[16:01] <soren> pitti: bah
[16:02] <Keybuk> it also shouldn't be harder than absolutely necessary
[16:02] <Keybuk> no?
[16:02] <pitti> soren: that's why we don't grant core-dev to everyone :)
[16:02] <pitti> soren: while I trust you to not 0wn everyone's box out there, that's not true for everyone on the world
[16:02] <soren> Keybuk: Point beig?
[16:02] <soren> being?
[16:02] <Keybuk> soren: same as yours
[16:02] <Keybuk> you're afraid of making it too easy
[16:02] <Keybuk> I'm afraid of making it too hard
[16:03] <soren> For malicous users to root my machine?
[16:03] <Keybuk> if it's too easy to gain admin privs, we lose
[16:03] <Keybuk> if it's too hard to gain admin privs, we also lose
[16:03] <pitti> as I said, I think I lost the original topic of what we are discussing
[16:03] <Keybuk> if I have to enter my password just to change wireless network, I'm going to be very grumpy ;)
[16:03] <Keybuk> or to use the digital camera *I just plugged in* :-)
[16:04] <soren> pitti: We're discussing whether it's sensible to hand a root shell to any user who has physical access to a machine.
[16:04] <pitti> soren: I disagree in that generality
[16:04] <pitti> you?
[16:05] <soren> pitti: Then what have you been arguing for the last fifteen minutes?
[16:05] <pitti> soren: I said that you have root IF you don't use encryption or physical security
[16:06] <pitti> and I have explained that for a lot of cases this condition is not true (like in my university or my laptop)
[16:06] <pitti> but on my desktop it's true, for example
[16:06] <pitti> everyone who walks into my room can 0wn my desktop
[16:06] <soren> pitti: Do you leave a root shell open on that?
[16:06] <soren> pitti: If not, why not?
[16:06] <pitti> soren: you have a good chance that sudo has a ticket, yes
[16:07] <pitti> soren: I don't because usually I prefer sudo because it's more comfortable
[16:07] <pitti> but indeed before I used sudo I did have a root shell open on my desktop
[16:07] <pitti> just because I need it very often
[16:07] <soren> pitti: And you left in unlocked an unattended for anyone to use?
[16:07] <pitti> soren: yes, because I trust my wife
[16:08] <Keybuk> my desktop at home isn't locked either
[16:08] <Keybuk> it has a screensaver for the pretty pictures
[16:08] <pitti> if some thief steals my desktop, the presence or absence of a root shell is insignificant
[16:08] <Keybuk> but if you shake the mouse, it goes away
[16:08] <Keybuk> I don't see a point in it being locked, it's my computer
[16:08] <Keybuk> likewise, it'll have a gpg and ssh agent, etc. with my keys loaded
[16:08] <pitti> for the same reason I don't lock my fridge
[16:08] <Keybuk> and likely a root shell, or at least a sudo ticket
[16:09] <pitti> because at home I can be sure that nobody will put poison into my milk
[16:09] <soren> pitti: You're assuming the anyone who might root your box is also a thief.
[16:09] <pitti> (I lock my front door for that)
[16:09] <pitti> soren: no, I'm not?
[16:09] <pitti> soren: if my wife wants to sabotage my desktop, she can do without me noticing
[16:10] <pitti> (well, assuming that she knew how to do that :) )
[16:10] <pitti> 'security through ignorance' :)
[16:10] <pitti> soren: so, what do you want to actually say?
[16:12] <soren> I'm contesting that because anyone can do X anyway, there's not point in making it hard at all.
[16:13] <pitti> I agree to the conclusion, but I disagree that anyone can get physical access to your box
[16:13] <soren> Ok, rephrasing: I'm contesting that because someone can do X anyway, there's not point in making it hard at all.
[16:14] <Keybuk> soren: depends what X is, no?
[16:15] <soren> Apart from the moral implications and such, why is the conclusion different for X = "get a root shell", X = "stab me"?
[16:15] <cjwatson> you might not notice that somebody has got a root shell
[16:15] <soren> Both are things I really want to avoid.
[16:15] <Keybuk> why is the conclusion the same for X = "get a root shell" and X = "change the wireless network" ?
[16:16] <soren> For that reason I a) don't leave a root shell open on my machine for anyone (who happens to be in my vicinity) to use and b) don't hand out knives to random passers-by.
[16:16] <soren> cjwatson: If they did it by rebooting my machine, I think I'd notice.
[16:16] <cjwatson> soren: sure, but that's just one path
[16:17] <cjwatson> (you might not, if you had left your machine at a gdm prompt)
[16:17] <soren> cjwatson: Indeed, but it's the very path that's been presented here as the arugment.
[16:17] <cjwatson> and with sufficient session management, you might even not notice a reboot if they took care to log back in as you when they were done
[16:17] <Keybuk> pitti is arguing at a much more moderate level than that
[16:17] <Keybuk> (you don't need to reboot)
[16:17] <Keybuk> you just hibernate it, and then boot with different options to avoid the resume
[16:18] <Keybuk> fuck around
[16:18] <Keybuk> then resume :-)
[16:18] <Keybuk> sorry, I may have slipped into evil mode there
[16:18] <soren> Think servers..
[16:18] <Keybuk> a "Muahahahaha!" may be in order, or possibly a goatee
[16:19] <soren> People might be connected to them and notice if it suddenly goes missing.
[16:19] <Keybuk> not if you're quick
[16:19] <soren> I'm not.
[16:19] <soren> So there.
[16:19] <Keybuk> won't look much different to any net burp
[16:19] <Keybuk> pop into the DC, hibernate the server, fiddle, unhibernate
[16:19] <Keybuk> could do it in a smaller window than TCP timeouts
[16:19] <soren> Yes, because those are two weeks long.
[16:19] <soren> ...or thereabouts.
[16:20]  * persia once knew an admin who typically rebooted the sendmail server when the queue jammed, and it booted quickly enough that the users didn't notice.  This was 10+ years ago, and machines are faster now.
[16:20] <soren> persia: smtp is not a very interactive service..
[16:21] <persia> soren: Well, not any more.  Used to be more so (before local mail queues were common).  Point being that a reboot can take less time than calling support.
[16:21] <seb128> Keybuk: did you not bump the fontconfig shlibs version on purpose when you added the lcd filter changes?
[16:21] <soren> You are all arguing why it might be possible to not notice anyone rooting your box.
[16:22] <soren> I find it more interesting that it might actually be possible to notice it.
[16:22] <Keybuk> seb128: err, no
[16:22] <pitti> soren: those are two different questions, too
[16:22] <pitti> soren: fiddling with your box vs. fiddling with your box without you noticing
[16:22] <Keybuk> I may have not bumped it through incompetance ;)
[16:23] <seb128> Keybuk: I'm wondering if that's worth changing the shlibs or if updating the libcairo requirement is enough
[16:23] <Keybuk> ah no
[16:23] <Keybuk> I think I did think about it
[16:23] <seb128> theorically the shlibs should be updated I think
[16:23] <Keybuk> and didn't bother since there wasn't a library change
[16:23] <Keybuk> the API and ABI remain the same
[16:23] <Keybuk> the only difference is in the xsettings, no?
[16:23] <Keybuk> and packages using it work either way
[16:23] <Keybuk> (I may have been wrong)
[16:24] <seb128> right
[16:25] <seb128> ok, let's bump the libcairo requirements then
[16:25] <seb128> I like that better than updating the shlibs ;-)
[16:25] <soren> pitti: I've got a real-life appointment in about an hour and I've got a stack of stuff to do before then. We can shout at each other another time, shall we?
[16:26] <pitti> soren: heh :) and let's involve beer into that discussion
[16:26] <pitti> I'm off to the xmas fair soon, too
[16:26] <pitti> just want to test Ben's shiny new unionfs.ko
[16:29] <tjaalton> pitti: ok, vmware problem reproduced here. even reconfiguring xserver-xorg didn't help
[16:30] <pitti> yay
[16:40] <tjaalton> pitti: touché :)
[16:40] <tjaalton> it's not just vmware, this should affect every installation
[16:40] <tjaalton> "RET=10 xserver-xorg/config/display/modes doesn't exist"
[16:40] <tjaalton> so dexconf fails
[16:41] <tjaalton> it hasn't been cleaned up properly
[16:47] <pitti> tjaalton: "touch"?
[16:48] <pitti> tjaalton: oh, argh
[16:51] <tjaalton> pitti: I still use latin1 :)
[16:52] <dholbach> hahaha, http://www.ubuntu.com/ looks great :)
[16:52] <seb128> ;-)
[16:52] <stgraber> :)
[16:52] <pitti> oh, sweet!
[16:54] <ion_> Mr. Hankey the Christmas Poo with a pink face painting?
[17:00] <Kmos> I want a Ubuntu house :-) hehe
[17:01] <Pici> I think its a gibbon wearing the yellow jumpsuit from kill bill
[17:02] <Kmos> Pici: yeah
[17:02] <Kmos> hehe
[17:11] <cjwatson> tjaalton: so is that just a matter of clearing out the answers to every question owned by xserver-xorg in livecd-rootfs?
[17:12] <tjaalton> cjwatson: no, it's done in xserver-xorg.postinst, but in this case dexconf just tried to fetch a key that's not there, and thus fails
[17:12] <tjaalton> ie. a key that has already been cleared (or, in this case not used at all since it's a fresh install)
[17:12] <cjwatson> err, what happened to xserver-xorg/config/display/modes?
[17:12] <tjaalton> gone with xresprobe
[17:13] <cjwatson> damn, usplash and ubiquity both refer to that
[17:13] <tjaalton> oops :)
[17:13] <cjwatson> care to suggest replacements for what they do?
[17:14] <cjwatson> neither usplash nor ubiquity will actually *break* in its absence; usplash will revert to 640x480 and ubiquity will ignore it
[17:14] <cjwatson> but still, it's not ideal
[17:14] <tjaalton> cjwatson: I understand.. let me think about it for awhile
[17:15] <cjwatson> fixing dexconf is more urgent, so don't let me drag you away from that
[17:15] <tjaalton> sure, it's a simple commit
[17:15] <cjwatson> what's the substitution in dexconf?
[17:16] <tjaalton> ubiquity should also be fine, since it'll use whatever the hw would allow
[17:16] <tjaalton> dexconf doesn't write the mode anymore
[17:16] <cjwatson> tjaalton: the code in ubiquity is directly related to whatever usplash does
[17:17] <cjwatson> it's copying the value across for use by usplash
[17:17] <tjaalton> oh, in that case it should not do that
[17:17] <tjaalton> instead rely on the xserver
[17:18] <tjaalton> ..and driver to do the right thing
[17:18] <cjwatson> uh ... how would usplash depend on the X server?
[17:18] <tjaalton> I meant ubiquity
[17:18] <cjwatson> ubiquity is just setting up debconf for usplash
[17:18] <cjwatson> nothing more
[17:18] <tjaalton> ok, I was confused there
[17:19] <cjwatson> I shouldn't have mentioned it, it's a direct consequence of whatever's done in usplash
[17:19] <tjaalton> I'll commit the fix first, and then we'll sort this out
[17:19] <cjwatson> ok
[17:19] <cjwatson> though I'm about to head out for the evening
[17:20] <tjaalton> hmm ok
[17:20] <tjaalton> so I'll get usplash & ubiquity to have a look
[17:23] <cjwatson> usplash is really just trying to ask "what mode should I use?"
[17:23] <cjwatson> s/mode/screen size/
[17:26] <mjg59> cjwatson: ubiquity can probably just query that at runtime now?
[17:26] <mjg59> Or was there some reason this was hard? I forget.
[17:26] <tjaalton> cjwatson: is it before the session is loaded?
[17:29] <mhb> Keybuk: many of the Kubuntu developers want to make KDE4 the default now that somebody decided there is not going to be an LTS. Is the Kubuntu council allowed to make such a decision? I mean it would be a shame if we announced it but somebody else decided on which CD will get shipped.
[17:31] <mhb> Keybuk: if we should put our efforts into KDE4, we'd like to have a guarantee that something or somebody won't block our work in the 2/3rds of the development cycle.
[17:31] <cjwatson> mjg59,tjaalton: it's done in usplash's postinst. Relying on the X session being up and doing it in ubiquity would break non-ubiquity installs which still need to do the same thing, not to mention putting yet more stuff into ubiquity that belongs in packages.
[17:31] <cjwatson> (I only saw up to "<tjaalton> cjwatson: is it before the session is loaded?"; apologies if there was more after that)
[17:36] <tjaalton> cjwatson: yep, I agree
[17:39]  * keescook wonders about reading the scroll-back between soren and pitti...
[18:17] <pwnguin> did i miss something? hardy isn't a LTS?
[18:17] <pwnguin> i was without power for a week, so it's possible
[18:24] <pochu> pwnguin: it is. why?
[18:25] <pwnguin> then whats this about kde 4.0
[18:25] <pochu> Oh, I don't know anything about kubuntu. Ubuntu is LTS for sure, at least.
[18:35] <keescook> Keybuk: hibernate/evil/resume> I think the fs would get corrupted.  However, I wonder if mount -o remount,ro /; *hibernate*; *single-user*; vi /etc/passwd; *reboot/resume*; mount -o remount,rw /   would work?
[19:04] <keescook> soren: I would say that "security" is intended to reduce risk.  (things like users/groups assist both security and organization)
[19:05] <keescook> soren: fewer people will reboot a system to get root than those that would use an existing open root shell.
[19:05] <keescook> so, by not leaving a root shell open, you reduce risk.
[19:38] <pitti> hi again
[19:41] <pitti> BenC: testing your new module now
[19:42] <jdstrand> keescook: well put
[19:43] <jdstrand> soren: I would also add that it isn't always all or nothing
[19:44] <jdstrand> soren: having a system in your house is often *enough* physical security for most people
[19:44] <jdstrand> soren: and a non-open tty is *enough* for co-workers, because often you or others will notice them at your computer, fiddling it
[19:45] <jdstrand> but pitti's argument is absolutely valid-- if someone is actively seeking your box, physical access == root
[19:47] <jdstrand> to use an analogy-- I have ssh listening on a non-default port.  this offers no actual protection from someone who wants to connect.  but it keeps the vast majority of people away
[19:48] <jdstrand> (this is of course an imperfect analogy-- but gets to kees' reducing risk argument, while also supporting pitti's and your own :)
[19:49] <pitti> jdstrand: ssh port> heh, me too; got sick of the millions of logcheck spam mails from bots which try random user names and passwords
[19:49] <pitti> BenC: hm, I get a different crash now :/
[19:50] <jdstrand> pitti: :)
[19:55] <pitti> BenC: new crash screenshots attached
[20:18] <BenC> pitti: thanks
[20:20] <BenC> pitti: same crash, different trace is all
[20:20]  * pitti tries to imagine the end of that sentence
[20:21] <BenC> pitti: better wording: same crash, it's just a different traceback :)
[20:21] <pitti> ah, ok
[20:25] <BenC> pitti: ok, I think I've found the problem, 10 minutes and I'll have another .ko
[20:29] <BenC> pitti: new module attached to the bug report
[20:30] <pitti> BenC: rock, trying
[20:31] <pitti> oh, I need to reboot back into .22 for vmware
[20:37] <pawalls> keescook, ping
[20:39]  * pitti hugs BenC
[20:39] <BenC> yay!
[20:39] <pitti> BenC: that did it, no oops any more
[20:40] <pitti> I don't get X started, but I think that's another bug
[20:40] <BenC> pitti: I'll wait till the install is over to declare victory
[20:40] <BenC> oh, damn
[20:40] <pitti> oh, no, X comes up now
[20:40] <pitti> just took a while
[20:40] <BenC> keep on truckin brotha
[20:40] <pitti> BenC: yep, doing a test install now :)
[20:40] <pitti> BenC: but the alternate install with the same kernel worked, so let's cross fingers
[20:41] <pitti> ergh, install at 800x600, ubiquity doesn't like taht
[20:42] <pitti> slangasek: the desktop background is broken (no elephant skin, just plain orange), but that's hardly RC :)
[20:43] <pitti> BenC: ok, installation is grinding away
[20:43] <BenC> pitti: I'll prepare everything for upload
[20:43] <slangasek> pitti: ok :)
[20:43] <pitti> "The ext3 file system creation in aprtition #1 of SCSI3(0,0,0) failed."
[20:43] <pitti> that's less good
[20:43] <slangasek> are the alternates getting any testing while we wait?
[20:44] <pitti> I just gave them a smoke test, I was busy with the desktops in the afternoon
[20:44] <BenC> pitti: the kernel uploaded earlier will give us ppc and lpia as well
[20:44] <pitti> but I announced them in the tracker etc.
[20:44] <BenC> only thing failing now should be ia64
[20:44] <pitti> slangasek: when xorg is built we shuold rebuild the alternates, though
[20:44] <pitti> slangasek: forcing 800x600 upon everyone is no fun
[20:44] <pitti> BenC: great
[20:44] <pitti> ia64, what's that :)
[20:45] <pitti> BenC: formatting issue is not an oops at least
[20:45] <BenC> ia64 was this crazy notion that slow 64-bit was better than fast 32-bit
[20:45] <pitti> "program parted_devices is using a deprecated SCSI ioctl, please convert it to SG_IO"
[20:45] <BenC> hrmm
[20:45] <pitti> evand, cjwatson: ^ any idea?
[20:46] <BenC> I wonder if that's some compatibility we disabled in the kernel that can be fixed with a config option
[20:46] <pitti> so that might or might not be considered a kernel bug
[20:49] <BenC> pitti: that doesn't return error in the code
[20:49] <BenC> it's just a warning
[20:49] <pitti> hm
[20:49] <pawalls> keescook, I'm available if you need information on the kernel OOPS bug. I uploaded a patch that fixes the problem also.
[20:49] <pitti> ubiquity just gives that error message and returns to the partitioner
[20:50] <BenC> pitti: the only way it can return error is -EINVAL if there is no arg to the SEND_COMMAND ioctl, which would be a program bug, but that's not a new condition
[20:51] <pitti> ok; trying again with more debugging output
[20:52] <pitti> hm, I wonder whether this actually was PEBCAK
[20:52] <pitti> I think I forgot to unmount /dev/sda1 in the initramfs after I insmod'ed the new unionfs.ko from there
[20:52] <pitti> I did it this time
[20:53] <BenC> pitti: ah, that could do it
[20:53] <pitti> oh, c'mon tracker notifications, get out of my eyes
[20:54] <BenC> -EBUSY
[20:54]  * pitti holds his breath
[20:55] <markvandenborre> persia, should I file a bug report on packaging libtimidity?
[20:55] <pitti> AWOOGA!
[20:56] <pitti> evand, cjwatson: unping; PEBCAK, sorry
[20:56] <markvandenborre> pitti, ... awooga:  	
[20:56] <markvandenborre> of and or relating to sex and or sexual intercourse. comes from the sound of the horn of an old studenbaker.
[20:57] <markvandenborre> http://www.urbandictionary.com/define.php?term=awooga&defid=627268
[20:57] <pitti> lol
[20:57] <slangasek> ...
[20:57] <pitti> to me it sounds more like a cry for battle from something in between a gibbon and a Neanderthal :)
[20:58] <pochu> cool version of Eurika (I found it!), too ;-)
[20:58] <pochu> (same page)
[20:58] <slangasek> yes, but the people who write for urbandictionary think that *everything* is of and relating to sex and/or sexual intercourse
[20:58] <BenC> slangasek, pitti: latest linux is finished building...I think ppc and lpia will need NEW, if you could please
[20:58] <pitti> BenC: with pleasure
[20:58] <pitti> BenC: right in time for publisher
[20:58] <BenC> pitti: excellent, thanks
[20:58] <jdstrand> slangasek: you mean everything isn't?
[20:59] <pitti> BenC: ah, this time with -rt again
[20:59] <pitti> BenC: done
[20:59]  * jdstrand goes off and rethinks the meaning of life...
[20:59] <slangasek> heh
[20:59] <pitti> jdstrand: 42!
[21:00]  * pitti wouldn't be surprised if urbandictionary would define that as how much sex you should have per month or so :-P
[21:00] <Keybuk> pitti: err, what unit of measurement?
[21:00] <pitti> jdstrand: ah, no, wasn't it "We apologize for the inconvenience" in the 4th novel?
[21:01] <jdstrand> pitti: mana that takes me back...
[21:01] <jdstrand> s/mana/man/
[21:01] <jdstrand> but maybe mana(sp.) is more appropriate here...
[21:01] <pitti> Keybuk: in the interest of staying alife I don't hope it's counting :)
[21:02] <pitti> alive, even
[21:03] <pitti> . o O { will I ever get that one right the first time? }
[21:03] <pitti> BenC: unionfs is l-u-m, right?
[21:03] <BenC> pitti: right
[21:04] <pitti> BenC: it progressed fairly well, I think upload should be good
[21:04] <pitti> BenC: thanks, that was super-fast
[21:05] <pitti>       xorg | 1:7.3+8ubuntu2 |         hardy | source, amd64, hppa, i386, ia64, lpia, powerpc, sparc
[21:05] <pitti> slangasek: ^ there we go, shall I kick new alternates or do you want to?
[21:06] <pitti> slangasek: I don't think we need to wait for fixed unionfs on alternates, but your call
[21:06] <tjaalton> pitti: it doesn't force 800x600 for everyone, just vmware
[21:06] <pitti> tjaalton: oh, then I misunderstood
[21:07] <slangasek> pitti: I'll fire it off now
[21:07] <pitti> tjaalton: you'll still get the wrong keyboard layout, though, I guess?
[21:07] <pitti> so people can't even log in if they have a nontrivial password?
[21:07] <tjaalton> pitti: no, now dexconf works and you'll get it right
[21:07] <pitti> tjaalton: I mean with the previous one which is on the current alternates
[21:07] <pitti> i. e. why I think we need to rebuild them
[21:07] <tjaalton> yeah, right
[21:07] <BenC> pitti: lum is passing through my T1 to the upload queue as we speak
[21:08] <pitti> mmm, T1
[21:08] <tjaalton> BenC: shall I fix l-r-m or?
[21:08] <BenC> tjaalton: what's wrong with it?
[21:08] <tjaalton> read the email
[21:08] <tjaalton> on u-d
[21:09] <tjaalton> nvidia/fglrx should not provide xserver-xorg-video, but x-x-v-2
[21:09] <slangasek> pitti, tjaalton: too much discussion, the alternates are already rebuilding ;)
[21:09] <pitti> slangasek: and rightly so
[21:10] <jdstrand> pitti: well that was a fun little break-- "We apologize for the inconvenience" is most definitely the 4th book-- chapter 40
[21:10] <jdstrand> ;)
[21:10] <pitti> jdstrand: ah, it's been years since I read it the last time
[21:10] <jdstrand> pitti: me too-- your memory is far superior to mine to pull that one out! :)
[21:11] <pitti> jdstrand: just remember, that was the almost-dying Marvin which by that time was 37 times as old as the entire universe or so? :)
[21:11] <pitti> climbing up that hill from where you see that sentence
[21:12] <jdstrand> there was some sort of coin-op device too
[21:12] <jdstrand> long live Marvin!
[21:12] <pitti> Marvin for president!
[21:13] <markvandenborre> persia, https://bugs.launchpad.net/ubuntu/+bug/177759
[21:13] <ubotu> Launchpad bug 177759 in ubuntu "libtimidity needs packaging for gstreamer sw midi playback to work" [Undecided,New]
[21:14] <pitti> instead of rebooing, the live session just got hung and stuck
[21:15] <jdstrand> huhuh... pitti said 'rebooing'
[21:15] <pitti> whoops
[21:15]  * jdstrand has clearly been looking at his mysql update for too long
[21:15] <pitti> Give me a T!
[21:16] <jdstrand> T!
[21:16] <pitti> give me a "he desktop install worked"!
[21:16] <pitti> What's the sentence?
[21:16] <jdstrand> haha
[21:16] <slangasek> he desktop install worked-tuh!
[21:16] <jdstrand> easy: "she desktop install worked"
[21:16]  * pitti congratulates slangasek, very good!
[21:17] <pitti> slangasek: so, after that  lum upload the desktop should be good *phew*
[21:17]  * jdstrand bangs his head on his desk for missing that one
[21:17] <pitti> (clearly time for a christmas break here...)
[21:19] <pitti> BenC: btw, I take it that the .24 kernel does not have any apport patches any more?
[21:20] <BenC> pitti: nope
[21:20] <pitti> cool
[21:20] <pitti> then I can go ahead and convert apport to the new interface
[21:20] <pitti> finally, it'll run on a vanilla upstream kernel \o/
[21:20] <slangasek> pitti: and the source is pending, so looks like we're on track hurray
[21:27] <slangasek> ubuntu,kubuntu,edubuntu alternates republished
[21:29] <pochu> rz
[21:30] <pochu> woops
[21:30] <slangasek> rzszczyk
[21:31] <pochu> I feel better now ;)
[21:46] <pitti> hm, most of lum is in depwait for headers-rt
[21:46] <pitti> so that'll take a while still
[21:48] <slangasek> pitti: ?
[21:48] <slangasek> powerpc/lpia are dep-wait on the kernels from new, no?
[21:49] <slangasek> oh, I'm looking at 2.2 instead of 2.3
[21:49] <slangasek> why is that
[21:50] <slangasek> are we sure that's "will take a while", not "needs a reupload without a dep on a package that isn't going to get here any time soon"?
[21:58] <slangasek> ubuntu-server, ubuntustudio also available for testing
[21:58] <BenC> slangasek: 2.3 is uploaded, but not processed yet...just needs to wait for the buildd run
[21:58] <slangasek> BenC: see pitti's comment above that it's dep-wait on a headers-rt package that doesn't seem to exist
[21:59] <BenC> slangasek: was the headers-rt package put into main or universe?
[21:59] <BenC> the latter would be bad
[22:00] <slangasek> hmm, it's in main
[22:00] <slangasek> so that was just now published then?
[22:00] <BenC> not too long ago, yeah
[22:00] <slangasek> ok
[22:01] <slangasek> well, i386 is now dep-wait on linux-headers-2.6.24-2-ume, checking
[22:01] <slangasek> that one's not in universe or main
[22:02] <BenC> hmm, where did that dep come from
[22:02] <BenC> completely bogus
[22:05] <Ahmuck> hi, i noticed that when doing a "sudo aptitude install xserver-xorg" that it downloaded and installed all the xserver modules (graphics, wacom pad, etc) for xserver.  however i  really don't need this.  is there a way to not do that?  i noticed that using apt-get for firefox only get's firefox and saves a 10mb download.  would xserver-xorg be the same
[22:06] <pitti> slangasek: yes, it was amongst the packages I NEWed a while ago
[22:06]  * somerville32 gets out a sledge hammer to beat Xubuntu into shape.
[22:07] <tjaalton> Ahmuck: not without force
[22:07] <Ahmuck> try e17
[22:08] <tjaalton> Ahmuck: actually, just install the driver you need
[22:09] <slangasek> BenC: you'll work on a -2.4 that removes these references to japanese plums, then?
[22:09] <Ahmuck> yes, i noticed that perhaps i could install, xserver-xorg base and then the driver?
[22:09] <Ahmuck> i assume
[22:10] <BenC> slangasek: yeah, 5 minutes to upload
[22:10] <slangasek> BenC: cool, thanks
[22:10] <Spads> Ahmuck: when you assume, you make an ass out of ume, which is a japanese plum
[22:10] <slangasek> haha
[22:10] <Ahmuck> spads, ever had a japanese plum?
[22:10] <Spads> Ahmuck: Yes.
[22:10] <Ahmuck> it will make you pucker as well
[22:11] <Ahmuck> :-p
[22:11] <Spads> depends on the plum
[22:11] <Spads> slangasek: when you assist, you make an ass-cyst.  this aphorism shows you the folly of assistance.
[22:11] <pitti> slangasek: running amd64 alternate test install now; btw, did you already put them into isotracker?
[22:11] <slangasek> pitti: yes
[22:11] <pitti> cool
[22:14] <BenC> slangasek: on its way
[22:14] <slangasek> BenC: thanks
[22:19] <pitti> BenC: hm, just saw the 'removed ipw3945' item in the lum changelog; too bad :/
[22:19] <pitti> BenC: any chance to keep it for a while?
[22:19] <BenC> pitti: not needed
[22:20] <BenC> pitti: iwl3945 in upstream kernel supersedes it
[22:20] <pitti> (bug 177624)
[22:20] <ubotu> Launchpad bug 177624 in linux "iwl3945 has very poor signal reception, whereas ipw3945 works perfectly" [Undecided,Confirmed] https://launchpad.net/bugs/177624
[22:20] <BenC> hmm, we'll report that to intel then
[22:20] <pitti> BenC: can do, they have an upstream bug tracker?
[22:21] <BenC> they have an lp project to file against, IIRC
[22:21] <pitti> ah, great
[22:22] <pitti> https://edge.launchpad.net/intellinuxwireless?
[22:22] <pitti> BenC: so the recommended way is to just add an upstream task?
[22:23] <BenC> pitti: right
[22:23] <pitti> yay LP :)
[22:25] <pitti> BenC: they didn't set a bug contact, though, and mark it as 'uses LP for bugs'
[22:26] <BenC> hmm, I'll check it
[22:29] <pitti> cjwatson: argh, the 'erasing data' for encrypted LVM is back (merge regression)
[22:31]  * pitti reopens bug 151244
[22:31] <ubotu> Launchpad bug 151244 in partman-crypto "encrypted lvm initialisation is very slow" [Medium,Triaged] https://launchpad.net/bugs/151244
[22:44] <mjj29> hi, I'm a DD and one of my packages (which was copied from unstable) doesn't build
[22:44] <mjj29> (on ubuntu)
[22:44] <mjj29> however, I could make some (minor) modifications to it so that it would
[22:44] <mjj29> (specifically, ubuntu now has icedtea whereas I have to depend on sun-java in debian)
[22:45] <mjj29> how would I go about getting such a branch of the package into ubuntu?
[22:46] <pochu> mjj29: which package?
[22:46] <mjj29> pochu: dbus-java
[22:46] <slangasek> mjj29: the standard way is to file a bug against the source package in launchpad with a patch (incl. a changelog with a <foo>ubuntu1 version number), and then subscribe ubuntu-universe-sponsors
[22:46] <mjj29> (the build failure is that while the buildd will install sun java it can't accept the dlj, so it fails)
[22:47] <pitti> mjj29: dlj?
[22:47] <TheMuso> mjj29: Alternatively, if you wish to make a change in Debian, make the change, upload it, and then request a sync.
[22:47] <mjj29> alternatively, it's arch all; does ubuntu insist on sourceful uploads
[22:47] <slangasek> separately, I suppose that once dbus-java is building against icedtea, someone should ask for it to move from multiverse to universe?
[22:47] <mjj29> TheMuso: icedtea isn't in debian yet, so I can't use that
[22:47] <pitti> mjj29: yes, source uploads only
[22:47] <TheMuso> mjj29: Ok
[22:47] <pitti> mjj29: you could also use an alternate build dep to keep it in sync in debian and ubuntu
[22:47] <mjj29> pitti: fair enough. Debian buildds don't have the problem since it's arch all
[22:48] <pitti> mjj29: b-dep: sun-java | icedtea should DTRT
[22:48] <slangasek> pitti: it does?
[22:48] <pitti> since we don't have sun-java in Ubuntu
[22:48] <mjj29> pitti: yes you do
[22:48] <mjj29> according to the buildd log
[22:48] <pitti> slangasek: hm, not according to madison
[22:48] <pochu> Then do icedtea | sun-java
[22:48] <pitti> might be a provides
[22:48] <mjj29> http://launchpadlibrarian.net/10787839/buildlog_ubuntu-hardy-i386.dbus-java_2.3.1-1_FAILEDTOBUILD.txt.gz
[22:48] <slangasek> pochu: that won't work for Debian.
[22:49] <mjj29> pochu: indeed
[22:49] <slangasek> sbuild only considers the first branch of an ORed build-dep
[22:49] <pochu> slangasek: why not? It can't find icedtea, then it picks sun-java?
[22:49] <slangasek> well, ok, it's arch: all so this doesn't matter in practice
[22:49] <pitti> slangasek: not our sbuild
[22:49] <pochu> ORed?
[22:49] <geser> pitti: the build dependency is sun-java5-jdk which is in multiverse
[22:49] <pitti> slangasek: we patched it to consider the alternatives and provides, too, AFAIK, to avoid such deltas
[22:50] <pochu> alright, acked
[22:50] <pitti> geser: ah, that would be it
[22:50] <slangasek> pitti: yes, but that doesn't help when the Debian build-dep is the one listed last :)
[22:50] <pitti> mjj29: it doesn't work at all with gcj?
[22:50] <slangasek> pitti: because the Debian build-dep is the one that has to work with Debian's sbuild :)
[22:50] <pitti> slangasek: right, since I didn't see sun-java I would have put that last
[22:51] <mjj29> pitti: no, I have a bug filed with gcj upstream about that
[22:51] <mjj29> it _compiles_
[22:51] <mjj29> it doesn't run
[22:51] <mjj29> actually, I could probably build-dep on gcj and dep on sun-java
[22:52] <mjj29> since that would work in both, perversely
[22:52] <pitti> mjj29: ah, it doesn't miscompile, it just mis-"runs"?
[22:52] <slangasek> dep on sun-java | icedtea, I guess?
[22:52] <mjj29> slangasek: that fails as it does atm
[22:53] <mjj29> because ubuntu sbuild tries to install sun-java and fails
[22:53] <pitti> Unpacking sun-java5-bin (from .../sun-java5-bin_1.5.0-13-0ubuntu1_i386.deb) ...
[22:53] <pitti> sun-dlj-v1-1 license could not be presented
[22:53] <mjj29> unless it then retries?
[22:53] <pitti> try 'dpkg-reconfigure debconf' to select a frontend other than noninteractive
[22:53] <pitti> oh, argh
[22:53] <mjj29> pitti: mmm
[22:53] <pitti> so it's not a problem of being in universe vs. multiverse, but the silly license question
[22:53] <mjj29> yeah
[22:53] <mjj29> which can only be done interactively, or by preseeding debconf
[22:53] <mjj29> neither of which you can do on a buildd
[22:53] <pitti> infinity: any chance this could be fixed in the buildds?
[22:54] <pitti> how does that work in Debian then?
[22:54] <slangasek> mjj29: dep, not build-dep
[22:54] <pitti> oh, right, no actual buildd builds in Debian
[22:54] <slangasek> right
[22:54] <mjj29> slangasek: oh, yeah
[22:54] <pitti> mjj29: that means that it is actually buildd-FTBFS in Debian, too?
[22:54] <mjj29> pitti: 1. it's in contrib, so all bets are off
[22:54] <slangasek> pitti: yes, but never an issue in practice, there are no Debian buildds that ever build arch: all packages
[22:55] <mjj29> 2. it never gets built
[22:55] <geser> what about archive rebuilds in Debian?
[22:55] <pitti> mjj29: ok; so AFAICS you could either use "b-dep: icedtea | sun-java" and don't care (since it's broken either way in Debian)
[22:55] <pitti> mjj29: or we introduce that small delta
[22:55] <slangasek> geser: no reason for this to be release-critical
[22:56] <pitti> until openjava sees the light of the day and we can get rid of all that mess in both D and U
[22:56] <mjj29> pitti: or I b-d on gcj and then d on sun | icedtea
[22:56] <slangasek> or option 3, mjj29 can package icedtea-java for Debian
[22:56] <slangasek> >:)
[22:56] <mjj29> slangasek: heh
[22:56] <infinity> pitti: Which release is this on?
[22:56] <pitti> mjj29: right, that would be elegant in a nasty way :-D
[22:56] <pitti> infinity: hardy
[22:56] <infinity> pitti: Grr.  That's supposed to be fixed.
[22:57] <mjj29> unless infinity fixes it magically
[22:57] <pitti> infinity: licenses are sticky as superglue, so it seems
[22:57] <mjj29> and I can go back to not caring about ubuntu until someone else emails me to ask me to fix it for you (-;
[22:58]  * infinity grumbles.
[22:58] <pitti> mjj29: oh, I'm glad that you brought it up, don't get us wrong :)
[22:59] <infinity> root@vernadsky:~# debconf-get-selections | grep dlj
[22:59] <infinity> buildd  shared/accepted-sun-dlj-v1-1    boolean true
[22:59] <infinity> *cry*
[22:59] <infinity> And it still bails out in the postinst, due to the debconf frontend?
[22:59] <mjj29> infinity: that should DTRT
[22:59] <mjj29> hang on
[22:59] <mjj29> I have a preseed which does that around here
[22:59] <pitti> infinity: see above FTBFS URS
[23:00] <mjj29> sun-java5-bin   shared/accepted-sun-dlj-v1-1    boolean true
[23:00] <mjj29> sun-java5-jdk   shared/accepted-sun-dlj-v1-1    boolean true
[23:00] <mjj29> sun-java5-jre   shared/accepted-sun-dlj-v1-1    boolean true
[23:00] <slangasek> surely the owner field shouldn't matter?
[23:00] <infinity> mjj29: Same pre-seed as mine.
[23:00] <infinity> mjj29: The bit that breaks is a check against the frontend, it seems.
[23:01] <mjj29> ^^ thats what I pipe to debconf-set-selections
[23:01] <infinity> Wait, no.  It WORKS in my chroot here.
[23:01] <infinity> Which is identical to the chroot in soyuz.
[23:01] <slangasek> Burgundavia: hey, were you still working on alpha2 release notes? I don't see any changes on https://wiki.ubuntu.com/HardyHeron/Alpha2
[23:01] <pitti> infinity: maybe you fixed it recently and the build is older?
[23:01]  * pitti swings the giveback axe
[23:01] <infinity> Oh!
[23:01] <infinity> How old is this log?
[23:01] <mjj29> infinity: dunno, got emailed it by an ubuntu user today
[23:01] <infinity> Ah-ha.
[23:01] <geser> infinity: Finished at 20071207-1736
[23:01] <infinity> Yeah.
[23:01] <infinity> pitti: Just give it back.
[23:02] <infinity> pitti: Should work now.
[23:02] <pitti> done
[23:02] <infinity> Thought I was losing my mind...
[23:02] <pitti> so, let's cross fingers :)
[23:02] <mjj29> cool
[23:02] <mjj29> "Pending (0)"
[23:03] <geser> infinity: while speaking of buildds: any progress on fixing bug #87077 on the buildds?
[23:03] <ubotu> Launchpad bug 87077 in scons "The build of xmms2 fails because of HASH(0x82db558)="" in the environment" [Undecided,Fix released] https://launchpad.net/bugs/87077
[23:04] <infinity> geser: It's on my radar, but I have other stuff that's more pressing right now. :/
[23:04] <geser> ok
[23:04] <slangasek> yes, hash is bad for the environment
[23:05] <geser> infinity: I guess bug #174851 is at the other end of your work queue
[23:05] <ubotu> Launchpad bug 174851 in mig "mig and gnumach need a manual boot-strapping on the buildds" [Undecided,New] https://launchpad.net/bugs/174851
[23:06] <infinity> geser: I'm guessing no one told me about that one. :)
[23:07] <infinity> geser: At this point, it's not likely to be done before Christmas (ie: tomorrow afternoon), but it should be up there, yeah.
[23:08] <infinity> geser: Subscribed to it now...
[23:09] <geser> infinity: I gave you that bug number after I filed it, but I guess it was the wrong time and it got lost
[23:10] <infinity> geser: Possibly.
[23:15]  * pitti just realizes what he writes when he does $ killall cat
[23:16] <pitti> those poor kittens *sob*
[23:16] <slangasek> meow
[23:32] <pitti> ah, that alternate test install looks good; I even have an xorg.conf again
[23:32] <cjwatson> pitti: parted_devices has been saying that for ages,
[23:33] <cjwatson> BTW
[23:33] <cjwatson> pitti: the "regression" in partman-crypto is intentional; the erase step is now cancellable
[23:33] <pitti> cjwatson: ah, ok; was a red herring apparently
[23:33] <cjwatson> which solves the problem more elegantly, IMO
[23:33] <pitti> cjwatson: oh, indeed
[23:36] <StevenK> pitti: Please give-back libofa on all arches
[23:37] <pitti> done, and thanks for fixing curl
[23:42] <TheMuso> Is there likely to be another linux-meta upload before alpha goes into testing/releae?
[23:42] <TheMuso> Since lum was updated?
[23:44] <slangasek> I didn't expect there to be, is there a reason that one would be needed?
[23:45] <TheMuso> slangasek: I don't really know, th is is why I'm asking. If not, no matter.
[23:45] <slangasek> AFAIK there's no need for linux-meta updates after non-ABI-changing lum
[23:45] <TheMuso> Fair enough then.
[23:48] <slangasek> stgraber: help
[23:49] <slangasek> stgraber: I managed to get builds added to the iso tracker which the tracker couldn't find on cdimage.u.c; so I tried to "remove selection", but now readding them doesn't cause them to be visible
[23:49]  * slangasek considers faking the build names
[23:51] <EvanCarroll> will heron have perl5.10?