[12:31] <mikmorg> Could someone tell me how I can assure my script runs before X starts, when I put it in init.d?
[12:31] <mikmorg> I can't tell where X starts...
[12:32] <mikmorg> oooh, nevermind.. i just noticed rcS.d
[12:46] <yexiaodou> hello guys. Does anyone know how to fix the bug regarding the limitations of maximum number of partitions on Feisty (currently 15) ?
[12:50] <ion_> How many partition do you need? :-)
[12:52] <pygi> ion_, 31+1 :)
[01:08] <Riddell> infinity: I just accepted the binary that libcaptury is dep-wait on, will it automatically re-try itself some point soon?
[01:55] <Kmos> bug 129828
[01:55] <ubotu> Launchpad bug 129828 in Ubuntu "[Gutsy]  creating initrd image fails with "invalid option -- c"" [Undecided,New]  https://launchpad.net/bugs/129828
[01:55] <Kmos> this is a mkinitramfs bug, right ?
[01:57] <Kmos> kmos@bash:~$ apt-cache search mkinitrd.yaird
[01:57] <Kmos> yaird - Yet Another mkInitRD
[01:57] <crimsun> assign it to yaird
[01:57] <Kmos> yeah
[01:58] <Kmos> thx
[02:13] <Kmos> bug 128439
[02:13] <ubotu> Launchpad bug 128439 in Ubuntu "depmod segfault" [Undecided,New]  https://launchpad.net/bugs/128439
[02:13] <Kmos> this is depmod, nothing to do with kernel or sudo
[02:14] <Kmos> i'll ask him to try depmod -a without sudo
[02:15] <crimsun> that would fail
[02:15] <crimsun> if he can run depmod through gdb, that _may_ help in debugging
[02:18] <Kmos> :)
[02:38] <Kmos> bug 129840
[02:38] <ubotu> Launchpad bug 129840 in autoinstall "Installation of Ubuntu 7.04 failed " [Undecided,New]  https://launchpad.net/bugs/129840
[02:38] <Kmos> this one is a bug from debian-installer ?
[02:39] <Kmos> or kernel
[02:39] <crimsun> the former
[02:40] <Kmos> ?
[02:40] <crimsun> debian-installer.
[02:40] <Kmos> :)
[02:40] <Kmos> thx
[02:41] <crimsun> I'm not entirely convinced the user didn't screw something up, but we'll give him the benefit of the doubt.
[02:41] <Kmos> yeah
[02:41] <Kmos> I can ask him if the do anything after the installation
[02:41] <Kmos> *he
[02:42] <Kmos> "You do anything after the installation ? or just install and it didn't work after that ? Thanks"
[02:42] <Kmos> i think it's good this way
[02:47] <crimsun> it's probably more useful to query which installation method he chose
[02:47] <crimsun> further, which boot loader install option was chosen, etc.
[02:47] <Kmos> crimsun: he says "alternate"
[02:48] <crimsun> Kmos: I mean whether he chose any additional "expert" ones.
[02:48] <Kmos> ah ok =)
[02:49] <Kmos> done
[03:06] <avb> hello
[03:06] <avb> guys, can someody tell me what is a difference of configuration of a gnome-sccreensaver on livecd and oninstalled system?
[03:07] <avb> i just copied livecd system to mine harddrive, coz installator was broken
[03:07] <avb> everything is fine, except that i can't lock screen
[03:07] <Chipzz> crimsun: I realise jono  said Kmos should ask on #ubuntu-devel, but what he's doing is basically bug-triaging... wouldn't he be better off on #ubuntu-bugs for that?
[03:08] <avb> i dont think that this is a bug. just because of nonstandrart install
[03:08] <ScottK> IIRC jono said that and then changed his mind after, but didn't say where.
[03:09] <crimsun> Chipzz: yes.  the channel and topic are obscured in this client.
[03:18] <mjg59> Oops. I've lost backscroll.
[03:18] <mjg59> Does anyone have the URL that calc gave me a couple of days ago?
[03:19] <kylem> lastlog calc
[03:20] <kylem> bleh.
[03:20] <kylem> 20070731.log:05:30 < calc> mjg59: http://cheney.ws/debug/vbetool.debug.output.bz2 <- what i have so far, i'll try ctrl-alt-del without sync mount
[03:21] <mjg59> kylem: There should be one after that
[03:21] <mjg59> Though might be the same url
[03:21] <mjg59> Oh, no, that looks like it
[03:22] <kylem> 20070731.log:06:03 < calc> mjg59: i replaced the file on my server with the compressed 678MB one
[03:22] <mjg59> Wow. Compressed well.
[03:22] <mjg59> (~100 times)
[03:24] <mjg59> Also looping
[03:30] <mjg59> calc: Looks like I could probably do with a dump of your video BIOS
[03:31] <mjg59> Oh, wait a second
[03:31] <mjg59> PE is set, but JP is jumping
[03:31] <mjg59> Uh. Rather, the parity flag is even, but JP is jumping.
[03:39] <tkamppeter> Ghostscript 8.60 FINAL is out, get it here:
[03:39] <tkamppeter> http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/ghostscript/
[03:42] <calc> mjg59: back
[03:43] <mjg59> calc: Just trying to find documentation for how this damned instruction is supposed to behave
[03:43] <calc> mjg59: ok
[03:45] <calc> mjg59: if you need a dump i can get it to you if you tell me how to do it :)
[03:49] <mjg59> Ah. Intel manual.
[03:54] <infinity> Riddell: Yes.
[04:02] <mjg59> calc: Hm. I'm probably going to need you to do a test in 32-bit mode
[04:09] <calc> mjg59: ok no problem
[04:09] <calc> i'll go get my tribe3 i386 disk
[04:17] <mjg59> calc: You'll need to grab http://www.codon.org.uk/~mjg59/tmp/libx86-1_0.99-1.2debug1_i386.deb
[04:17] <mjg59> Install that, switch to a terminal, do sudo vbetool post 2>vbetool.output
[04:34] <calc> mjg59: i built it myself and got the log, about to compress and upload it now
[04:35] <calc> mjg59: gar it logged 0 bytes again
[04:36] <calc> mjg59: i'll try it again and see if i can convince it to write out to disk
[04:36] <mjg59> calc: ?
[04:36] <calc> mjg59: how much log do you need? if i mount it sync it will definitely write some out but not 600MB+ amount
[04:36] <mjg59> calc: That's a different package to the one I gave you last time
[04:36] <calc> mjg59: oh ok
[04:37] <calc> i'll try it out and get back to you asap, probably 5-10min
[04:37] <mjg59> Ok
[04:45] <calc> mjg59: ok got it, very short
[04:45] <calc> Calling INT 0x15 (F000:F859) EAX is 0x10005F36
[04:45] <calc> Calling INT 0x15 (F000:F859) EAX is 0x5F34
[04:45] <calc> Calling INT 0x15 (F000:F859) EAX is 0x5F35
[04:45] <calc> there should be CR's before EAX on each line
[04:45] <calc> irssi strips them for some reason
[04:46] <mjg59> calc: Thanks
[04:46] <mjg59> That's really helpful
[04:46] <calc> great :)
[04:50] <mjg59> calc: Ok. Final thing - could you do
[04:50] <mjg59> dd if=/dev/mem of=/tmp/foo bs=1k skip=960 count=64
[04:51] <mjg59> And stick /tmp/foo somewhere?
[04:51] <mjg59> That's an image of your system BIOS
[04:51] <calc> is that safe to do from a feisty boot (i'm guessing yes)
[04:52] <mjg59> Yeah
[04:52] <mjg59> Needs to be done as root
[04:52] <calc> ok done
[04:53] <calc> http://cheney.ws/debug/bios.dump
[04:53] <mjg59> Can you do the same with skip=768 rather than skip=960?
[04:53] <mjg59> That'll be the video bios
[04:54] <calc> oh oops i removed the other one and uploaded the video bios as bios.dump also
[04:54] <mjg59> That's ok
[04:55] <calc> ok they are both up now as system.bios.dump and video.bios.dump
[07:23] <pitti> Good morning
[07:23] <ajmitch> morning pitti
[07:23] <ajmitch> you're up & about early
[07:24] <StevenK> Morning pitti
[07:24] <pitti> ajmitch: my usual time in summer
[07:24] <pitti> hey StevenK
[07:25] <Burgundavia> hey pitti
[07:25] <StevenK> pitti: I note *-386-di and two -generic-di things have hit NBS. debian-installer built so I'm unsure why that is. Would you mind explaining it?
[07:26] <pitti> hi Burgundavia
[07:27] <pitti> StevenK: that's strange
[07:27] <StevenK> pitti: That's what I thought.
[07:34] <pitti> StevenK: reload, please *shrug*
[07:42] <pitti> doko: https://launchpad.net/ubuntu/+source/sip4-qt3/4.6-1ubuntu3 \o/
[07:43] <StevenK> pitti: Thanks.
[07:44] <StevenK> infinity: Am I able to borrow some time of yours now?
[07:44] <StevenK> pitti: Hopefully I can beat pdftk into building sometime today, which will get libgcj7 out.
[07:45] <pitti> StevenK: that'll still need an OO.o ppc build, right?
[07:45] <StevenK> pitti: What's irritating me with pdftk is that isn't the code that's broken, but the build system.
[07:45] <pitti> StevenK: I need infinity, too! we must fix hal in buildds! he's mine, mine, mine!!!11!!
[07:45] <StevenK> pitti: I saw him first! I'll fight you for him. :-P
[07:46] <StevenK> pitti: Do we care about OO.o being uninstallable on ppc? I daresay we can ask calc when he's next wanting to upload OO.o
[07:48] <pitti> StevenK: I don't care on mine, OO.o is way too slow to be useful on a G4 800 MHz :)
[07:51] <StevenK> pitti: But it breaks ubuntu-desktop installability on powerpc
[07:52] <pitti> infinity: btw, Debian bug 435510 might be relevant here, but I doubt that hald is already running on the buildds?
[07:52] <ubotu> Debian bug 435510 in hal "Please permit installation in chroots" [Minor,Open]  http://bugs.debian.org/435510
[07:52] <pitti> StevenK: oh, poing
[07:52] <pitti> StevenK: point, even
[07:54] <pitti> infinity: then again, I can successfully install hal in a feisty chroot with the outside hal running; so maybe the buildd chroots don't have /sys?
[07:56] <StevenK> pitti: Does it fail with /sys not mounted?
[08:01] <pitti> meh, now the init script just hangs eternally
[08:02] <pitti> StevenK: no, it works here without /sys
[08:03] <pitti> bah, I guess I'll just fix it 'blindly'
[08:10] <pitti> infinity: TBH I think that policy-rc.d is the answer here...
[08:19] <infinity> pitti: Is this failing on buildds as a build-dep, on livefs builds...?
[08:19] <pitti> infinity: buildds
[08:20] <pitti> http://launchpadlibrarian.net/8633317/buildlog_ubuntu-gutsy-i386.nautilus-cd-burner_2.19.6-0ubuntu1_FAILEDTOBUILD.txt.gz
[08:21] <infinity> pitti: If I use a policy-rc.d, I'd be curious if any packages start failing because they depend on a running daemon as a build-dep...
[08:21] <infinity> pitti: I, personally, don't think that should ever be done, but who knows if it is...
[08:21] <pitti> infinity: I actually thought by just 101'ing hal
[08:21] <pitti> we can add more stuff to it if we need to later
[08:22] <pitti> infinity: the more expensive way is to find out why it actually fails
[08:22] <infinity> That might not be that much effort. :)
[08:22] <pitti> infinity: that'd require going into a buildd chroot and doing 'hald --verbose=yes --daemon==no'
[08:22] <infinity> Let me unpack a chroot on a buildd.
[08:23] <pitti> infinity: I assume there is no 'outside' hal?
[08:23] <infinity> I sincerely hope not.
[08:24] <infinity> Anyhow, setting up a buildd environment now.
[08:27] <infinity> pitti: Why does this build-dep on runtime stuff like hal and initramfs-tools anyway?
[08:27] <infinity> pitti: That's kinda sketchy.
[08:27] <pitti> infinity: it is indeed, but hard to avoid
[08:28] <infinity> That would be the gnome-mount build-dep, I guess...
[08:28] <pitti> right
[08:28] <infinity> But, why is that needed?
[08:28] <pitti> I asked seb, and he only needs the .pc file inside
[08:28] <pitti> I'm not sure why, gnome-mount doesn't export any .so or .h
[08:29] <infinity> This init script sucks.
[08:29] <infinity> root@vernadsky:~# /etc/init.d/hal start * Starting Hardware abstraction layer hald                                                         root@vernadsky:~# echo $?
[08:29] <infinity> 1
[08:29] <infinity> Why doesn't it output a failure on failure? :P
[08:30] <pitti> I had the same on my first try in my feisty chroot
[08:30] <pitti> but the second time it just hung eternally
[08:30] <infinity> *** [DIE]  osspec.c:watch_fdi_files():349 : Unable to initialize inotify: Function not implemented
[08:30] <infinity> There you go.  No inotify in the buildd kernels.
[08:30] <pitti> hrmpf
[08:31] <infinity> And hald really refuses to start because of that?  Can it not function at all without it?
[08:31] <infinity> Surely, it still contains some static data and other useful stuff, regardless of polling being broken...
[08:31] <pitti> I'll have a look
[08:32] <infinity> So, wait, all these hideous runtime build-deps are pulled in for the sake of a single .pc file?
[08:32] <infinity> Ngh.
[08:32] <pitti> I'm still not convinced that it is necessary at all
[08:33] <infinity> I'd lean pretty heavily to "no, it almost certainly can't be".
[08:34] <pitti> it's the only reverse build dep at least
[08:34] <pitti> infinity: I guess it uses it for build-time detection of whether or not to build gnome-mount support
[08:35] <infinity> pitti: Since we know we want gnome-mount support, surely that can be hardcoded.
[08:35] <pitti> right
[08:35] <infinity> pitti: Just like you don't need to build-dep on random binaries just to tell autoconf where they are (pre-seeding, FTW)
[08:37] <infinity> pitti: Anyhow, I'm down with whatever the "best" solution is, I just like to keep the magic in the buildd chroots to a minimum, so the environment is as easily reproducible as possible for devs.
[08:37] <infinity> pitti: It was one of the arguments for ditching gcc-opt and ccache.
[08:38] <pitti> infinity: if it's just the inotify thing, then hal can certainly be taught not to die on that
[08:38] <pitti> better than chroot hacks, I agree
[08:39] <Fujitsu> Why are mangled kernels used? Surely that makes them particularly unreproducable?
[08:40] <infinity> Fujitsu: We use distro sources, but compile our own kernels.  Even if we didn't, though, the buildds run dapper, so it wouldn't be the same as an end-user machine running a gutsy kernel.
[08:40] <pitti> bryce: still awake?
[08:40] <pitti> bryce: is xserver-xorg-video-amd particularly nasty? or can we just add it to -all and move it to main?
[08:42] <StevenK> infinity: I'm guessing dapper with hacked sbuild and co for the build environments, so it can build gutsy and such?
[08:43] <pitti> infinity: hm, even if explicitly given --enable-gnome-mount it checks for it *grumpf*
[08:43] <infinity> StevenK: We don't use a distro copy of sbuild.
[08:43] <infinity> StevenK: Not even close.
[08:44] <infinity> pitti: autoconf?
[08:44] <infinity> pitti: Preseed the variable on the command line with ac_whatever=/usr/bin/gnome-mount
[08:44] <pitti> infinity: yeah, I'll hit it over the head, I think
[08:44] <pitti> if test "$ENABLE_GNOME_MOUNT" = "yes"; then
[08:44] <pitti>         PKG_CHECK_MODULES(GNOME_MOUNT, gnome-mount >= 0.4,
[08:44] <pitti>                 [ AC_DEFINE(USE_GNOME_MOUNT, 1, [defined if using gnome-mount] )
[08:44] <pitti>                   msg_gnome_mount="yes"] ,
[08:44] <pitti>                 [ USE_GNOME_MOUNT=""] )
[08:44] <StevenK> infinity: I figured.
[08:45] <infinity> Oh, bleh.  That's broken autotools usage, IMO.
[08:45] <infinity> Anything that doesn't allow preseeding should die in the face.
[08:53] <StevenK> infinity: Still no time for libnss-db?
[08:54] <infinity> StevenK: Making time shortly for that and openssl.
[08:54] <StevenK> infinity: Okay, way cool.
[08:56] <pitti>         gnome-mount support:      yes
[08:56] <pitti> \o/
[08:56] <pitti> hi carlos
[08:57] <carlos> pitti: hi!
[08:57] <infinity> StevenK: Surely you have some sort of internet access at home? :P
[08:59] <tepsipakki> pitti: actually, x-x-v-amd is now in debian too, with a maintainer
[08:59] <StevenK> Some sort, yes. :-)
[08:59] <pitti> tepsipakki: right, Martin-Eric just asked me about it (and I sponsored the uploads)
[09:00] <tepsipakki> pitti: yes, same guy :)
[09:00] <pitti> tepsipakki: it'd support the ThinCan thin client, so maybe ogra would be happy, too :)
[09:01] <tepsipakki> I bet
[09:05] <pitti> hi thekorn
[09:06] <thekorn> hey pitti
[09:08] <\sh> moins
[09:08] <pitti> hey \sh
[09:11] <bryce> heya pitti, just checking in on my way to bed
[09:11] <pitti> bryce: ok, nevermind, it's not that urgent; sleep well!
[09:12] <bryce> re the -amd package, yes I think it'd be fine to move into main
[09:13] <bryce> I've been working with Q-FUNK on it, and it's close to getting a release with a real version number soonish
[09:13] <pitti> cool, thanks
[09:17] <pitti> bryce: I'm Q-FUNK's Debian sponsor for it and he just asked me about it
[09:20] <pitti> carlos: can I get a gutsy base export soon?
[09:21] <Q-FUNK> bryce: ?
[09:21] <pitti> Q-FUNK: just went to bed
[09:21] <Q-FUNK> ah
 re the -amd package, yes I think it'd be fine to move into main
[09:21] <pitti> <-- hunger hat sich getrennt (Read error: 113 (No route to host))
 I've been working with Q-FUNK on it, and it's close to getting a release with a real version number soonish
[09:21] <pitti> Q-FUNK: ^ FYI
[09:23] <Hobbsee> pitti!
[09:23] <Hobbsee> :)
[09:26] <carlos> pitti: sure, I'm going to change the export script to generate one today
[09:27] <pitti> carlos: thnaks
[09:28] <pitti> seb128: so, I talked about the hal thing with infinity, and I think the easiest solution is http://people.ubuntu.com/~pitti/tmp/n-c-b.debdiff; WDYT?
[09:28] <pitti> seb128: hal fails on the buildds because their kernels do not have inotify support; that could be fixed in hal, of course, but with some effort
[09:28] <Q-FUNK> pitti: right. you had questions about the upcoming release?
[09:29] <pitti> Q-FUNK: you mean xserver 1.4?
[09:29] <seb128> pitti: looks fine to me
[09:29] <carlos> pitti: you should have it later today
[09:29] <pitti> seb128: ok, uploading
[09:29] <seb128> pitti: thanks ;)
[09:29] <Q-FUNK> pitti: of -amd, as mentionned by bryce
[09:30] <pitti> Q-FUNK: ah; no, no particular questions
[09:30] <carlos> seb128: which package should I look at for problems with the laptop backlight? gnome-power-manager?
[09:30] <carlos> seb128: btw... hi :-P
[09:31] <seb128> hey carlos, yes might be it
[09:31] <seb128> or linux-source
[09:33] <Q-FUNK> alright then :)
[09:33] <carlos> seb128: the main problem is with GNOME's window that shows you how you move it up/down
[09:33] <seb128> gnome-power-manager then most likely
[09:34] <carlos> ok
[09:34] <carlos> thanks
[09:36] <pitti> seb128: do you have a dapper vmware image or installation?
[09:36] <seb128> pitti: no
[09:37] <mvo> pitti: I should have one, do you need one?
[09:37] <seb128> I might have an installation still on a partition on my desktop
[09:37] <seb128> I can reboot and have a look if you want
[09:37] <seb128> morning mvo
[09:37] <Hobbsee> mvo: :)
[09:37] <pitti> mvo, seb128: I prepared new dapper langpacks (complete refreshment of -base, too) for dapper.2 and need some initial testers
[09:37] <StevenK> Oooooh, dapper.2
[09:37] <StevenK> I like the sound of that.
[09:37] <mvo> morning seb128
[09:38] <seb128> pitti: URL?
[09:38] <pitti> still scp'ing
[09:38] <mvo> pitti: let me know what needs to be tested, I have booted it now
[09:39] <pitti> seb128, mvo: basically, install the German and French langpacks (the current dapper ones) for now
[09:39] <pitti> then, "deb http://people.ubuntu.com/~pitti/tmp/dapper-langpack/ ./" and dist-upgrade, when I give the mark (still scp'ing)
[09:42] <pitti> seb128, mvo: ok, deb source is ready
[09:56] <pitti> soren: ebox-openvpn has this in the postinst:
[09:56] <pitti> +               update-rc.d -f quagga remove
[09:56] <pitti> soren: that's nasty and a no-no
[09:57] <pitti> soren: (1) it doesn't even restore the symlinks again on removal, (2) it won't help, since the next install/upgrade of quagga will create them again, and (3) it destroys user configuration
[09:59] <soren> pitti: Alright.
[09:59] <pitti> soren: ah, good mornign
[09:59] <soren> pitti: Yes, that too. :)
[10:00] <pitti> (I just mailed you, for the records)
[10:00] <infinity> Ooo, mail me too!  I feel left out.
[10:00] <pitti> infinity: aren't you on u-archive@? :)
[10:01] <infinity> Oh, then I guess you did mail me too. :P
[10:01] <pitti> yep
[10:01] <infinity> Though not really in that "I was thinking of you" sort of way.
[10:01] <soren> pitti: If it restored the symlinks on removal, would it be fine?
[10:02] <infinity> soren: Touching configuration for other packages is never fine.
[10:02] <infinity> soren: Why does it need to do that?
[10:02] <pitti> soren: no, see points 2 and 3
[10:02] <infinity> soren: (Also, removing all the links means update-rc.d will restore them the next time quagga is upgraded)
[10:02] <pitti> ^ (point 2)
[10:02] <soren> infinity: You're asking why a system management framework would want to manage the system?
[10:02] <pitti> soren: that doesn't exclude each other from what I can see?
[10:03] <pitti> soren: if quagga does bad things in the default install, we should fix that
[10:03] <soren> I think - for now - I'll just try and yank out the quagga stuff.
[10:04] <pitti> soren: what's the particular reason you want to do that in the first place?
[10:05] <infinity> This is how entire continents get routed through random people's laptops by accident.
[10:05] <pitti> 'BGP' (sorry for outing me as a routing noob)
[10:05] <infinity> (True story, witnessed when I worked at PSInet, a UUnet engineer made a bit of an oops)
[10:05] <pitti> ?
[10:05] <soren> pitti: I'm not entirely sure. It seems even more weird that it's in the openvpn module rather than the network module.
[10:06] <infinity> pitti: Border Gateway Protocol, used to advertise routes to peers.
[10:06] <infinity> pitti: Large carriers tend to trust their peers implicitely... Until they do something really stupid.
[10:08] <soren> Ah... It's because it supports advertising new routes to the vpn clients.
[10:08] <mvo> pitti: install looks good, anything paricular you want to see tested?
[10:08] <infinity> (We were by-handing our routing to UUnet for a week after that incident, until they assured us the engineer in question had been appropriately flogged)
[10:08] <pitti> mvo: I tested the German ones here, too
[10:08] <pitti> mvo: oh, just general 'oops, this app isn't translated any more' oddities
[10:15] <infinity> pitti: Don't you debdiff the dapper.1 and dapper.2 debs to make sure they don't drop any po files?
[10:16] <infinity> pitti: (re: 'oops, this app isn't translated any more' oddities)
[10:16] <soren> infinity: Since you seem to know a bit about this.. In order for the new route advertisement to the clients to be useful at all, the clients will need to be running quagga too, won't they? (or another ripd)
[10:16] <pitti> infinity: the old -base and -updates ones are merged into new -base and empty -update, so it's not that simple, but I'll still do it for some languages
[10:17] <infinity> soren: Yeah.
[10:17] <infinity> soren: Most little home DSL routers and such support RIP for that very reason, I believe.
[10:18] <soren> infinity: Huh? I can push new routes to people's DSL routers?
[10:19] <infinity> soren: It's also possible we're talking about PPP style VPN, which might be using quagga in more interestingly bizarre ways, I don't really know.
[10:19] <infinity> soren: You can if they have it enabled with lousy blacklisting, sure.
[10:19] <soren> blimey
[10:19] <infinity> soren: (By default, those home routers won't accept routing updates over the public interface)
[10:21] <soren> infinity: So they implemented rip in them, so average home users can send new routes to the it via rip?
[10:21] <soren> infinity: That sounds like something that people are going to use a lot... er, no wait..
[10:21] <infinity> soren: So home users can get RIP updates over VPN tunnels.
[10:22] <infinity> soren: It's also handy if you have two or more of the little home routers, and just set-and-forget RIP on all of them.  Then you can set up your routing table once, and it Just Works.  In theory.
[10:22] <soren> infinity: The RIP updates would be inside the vpn tunnel, surely? Why does the router need to worry about that?
[10:22] <infinity> soren: I'm referring to routers that support VPNs, in this case, so the whole network has VPN access, not a single tunneled host.
[10:23] <soren> "10:17 < infinity> soren: Most little home DSL routers and such support RIP for that very  reason, I believe.
[10:23] <soren> I find that most litte home DSL routers don't know how to terminate a VPN connection.
[10:23] <infinity> Yeah, "that reason" being "because they also support VPNs" :)
[10:23] <infinity> All of mine do.
[10:23] <soren> What sort of vpn can they terminate?
[10:23] <infinity> But, yeah, the "multiple crap routers in a home" argument is the other reason they support RIP.
[10:24] <infinity> Oh, hah, the one I'm using right now can't.  Bah.
[10:24] <infinity> The one in the corner that's not on does PPTP and some random IPsec type things.
[10:25] <infinity> (Using this one instead because it does VoIP)
[10:25] <StevenK> Most home/SoHo type routers speak a subset of IPSec
[10:25] <infinity> Also, I have too many of these devices...
[10:26] <StevenK> Most won't handle special things like DPD (Dead Peer Detection), or NAT-T (NAT Traversal)
[10:26] <soren> I don't remember seeing a single on that does that. If it does it's packed away in an impossible to find spot in the config ui.
[10:27] <infinity> Note that different countries see wildly different types of these devices.
[10:27] <infinity> Australia seems to have a host of needlessly complex ADSL routers.
[10:27] <soren> Sure, my wrt54g does it, but that's because I'm running openwrt on it.
[10:27] <infinity> Heck, I never even owned such a device before I moved here.
[10:28] <StevenK> I ought to set up QoS one of these days.
[10:28] <infinity> Yeah, which is the setup I prefer, and how I did it in Canada.
[10:28] <infinity> But finding dumb modems here is harder than just getting cheap routers.
[10:29] <StevenK> Most cheap routers can be configured into bridge mode.
[10:29] <infinity> So I have a stack of routers. :)
[10:29] <infinity> Yeah, but if you're buying the thing anyway, may as well use it, I guess.
[10:29] <StevenK> If it's bridges, you're still using it. :-)
[10:30] <StevenK> Er, s/it's/it/
[10:30] <infinity> I think the only time I've ever bridged mine was when the ISP told me my unsupported hardware was clearly the cause of their inability to terminate PPPoA correctly.
[10:30] <infinity> So I bridged it, terminated it on my laptop, said "see, still doesn't work", and that was that.
[10:30] <StevenK> Hah
[10:31] <infinity> Still, I look forward to returning to the land of "PPPoWhat?" some day soon.
[10:32] <infinity> Never had to deal with DSL/Cable auth until I moved here either.
[10:33] <infinity> "Why do I need a username and password?  Are you afraid someone else is tapping my copper?"
[10:34] <StevenK> infinity: Depending on the situation, ADSL gets terminated by Hellstra and hands off authentication to different ISPs via realms so they can account traffic usage.
[10:34] <infinity> pitti: Oh, hah. Funny story.  I'm not on ubuntu-archive anymore got bounced off.  Hilarious, since I'm one of the admins.
[10:34] <infinity> I love mailman.
[10:35] <StevenK> infinity: Since Telstra has basically told the Government, "You can have the local-loop when you pry it out of our backrupt fingers."
[10:35] <StevenK> bankrupt, sigh
[10:36] <infinity> StevenK: Yeah, I know why it happens, it's just annoying.
[10:36] <infinity> StevenK: But iiNet has no such excsuse, either.  They own the DSLAM and bloody well know it's my port, so using PPPoX is just force of habit, and wasted overhead.
[10:36] <infinity> StevenK: Which irks me.
[10:37] <StevenK> Heh, yes.
[10:37] <infinity> StevenK: Works well enough for me.  *shrug*
[10:38] <infinity> StevenK: Better than the resold Telstra lines I've had in the past.
[10:39] <seb128> pitti: looks like the update removes some translations
[10:39] <seb128> -gconf-editor.mo
[10:39] <seb128> -gdebi.mo
[10:39] <seb128> -gnome-cups-manager.mo
[10:39] <seb128> -gnome-desktop-2.0.mo
[10:39] <seb128> -gnome-keyring.mo
[10:39] <seb128> -gnome-menus.mo
[10:39] <infinity> I had Telstra just randomly decide to cut my line and give it to someone else.  That was the last straw for me.
[10:39] <seb128> -gnome-nettool.mo
[10:39] <StevenK> I'm seriously considering jumping to Exetel's ADSL2+, but they're non-telephone line is rented from Powertel, and they're on the brink of getting bought out ...
[10:39] <seb128> -gnome-system-monitor.mo
[10:39] <seb128> -gnome-system-tools.mo
[10:39] <infinity> The usual "But it didn't have a dialtone!" idiocy.
[10:39] <seb128> -gnome-volume-manager.mo
[10:39] <seb128> pitti: my script might be buggy though
[10:39] <Burgundavia> get a real country with real internet you two ;P
[10:39] <infinity> Burgundavia: I come from one.  Yours, even.
[10:40] <infinity> Burgundavia: I grew up in Calgary, home of "we've had cable since 1995", feel my pain.
[10:40] <StevenK> infinity: Hah. At my last job, I was a sysadmin for a small ISP. They cut all 60 of our ISDN lines due to that excuse.
[10:40] <Hobbsee> Burgundavia: give us tickets out, and we'll come...
[10:40] <pitti> seb128: NB that the update packages are empty now, everything should be in -basea
[10:40] <pitti> seb128: s/a$//
[10:40] <Burgundavia> Hobbsee: infinity left us
[10:40] <StevenK> infinity: "They're ISDN, they aren't *supposed* to have a dial tone, you berk."
[10:41] <Hobbsee> Burgundavia: well, us born in au, anyway
[10:43] <StevenK> infinity: They dared to touch our 2Mbit frame relay. Once. That months bill was somehow waived. :-)
[10:45] <infinity> 2Mbit.  How cute!
[10:46] <infinity> We lived in an apartment building two blocks over and just kinda.  Uhm.  *cough*... Pulled Cat-5 with repeaters.
[10:48] <Amaranth> Come to the US, you get fast internet and no caps in exchange for AT&T snooping all your traffic
[10:48] <infinity> It was one of those "boy, we're glad management isn't smart enough to ask why there's a 4-port switch hanging off a port on the Juniper" moments.
[10:49] <StevenK> infinity: Bwahaha
[10:50] <StevenK> infinity: 2Mbit supporting about 3,000 customers. Not all at once, of course
[10:50] <infinity> Ouch.
[10:51] <StevenK> ... dial up customers. :-)
[10:52] <infinity> I don't understand your terminology, and I refuse to acknowlege your statement.
[10:52] <StevenK> Muahah
[10:52] <infinity> Seriously, I've not had dialup since 1995...
[10:52] <StevenK> infinity: In other news, any about openssl and friends?
[10:52] <infinity> Oh, and about a week in Cairns.
[10:53] <infinity> That was not a good week.
[10:53] <StevenK> Of course not, you were in Cairns.
[10:53] <infinity> Sort of landed, said "what, you don't have DSL?  This won't do" and fixed that in a hurry.
[10:54] <infinity> StevenK: No news is good news, I hear.
[10:55] <StevenK> Apparently. I remain unconvinced.
[10:56] <StevenK> And damn it, pdftk, you better have built sucessfully by the time I get back!
[10:59] <saispo> hi all
[10:59] <saispo> anyone maintain packages.ubuntu.com here ?
[11:17] <soren> I'm having a problem with some gconfd-2 processes that won't die... If I strace it and send it a SIGTERM, strace doesn't even show that the process receives the signal. What could possibly cause this?
[11:18] <soren> Even if the signal handler is SIG_IGN, strace still shows that the process receives it..
[11:18] <soren> Ah, if it's masked, perhaps..
[11:25] <seb128> Riddell: libcaptury-dev has no .so, any reason or that's an error?
[11:25] <Riddell> seb128: sounds like an error
[11:26] <seb128> I've accepted the binaries, please change it though ;)
[11:26] <Riddell> seb128: thanks
[11:27] <infinity> seb128: I prefer to reject broken lib-dev packages on the grounds that other packages may be dep-waiting on them, and then we'll get a bunch of build failures and give-backs cascading from the accepted broken binaries.
[11:27] <seb128> infinity: rejecting binary upload is weird though, you get the source in the archive but no binary
[11:28] <infinity> (dep-waits are autocleared when the packages get published to the archive)
[11:28] <infinity> seb128: Nothing wrong with source and no binary.  *shrug*
[11:28] <seb128> but you have a point
[11:30] <infinity> seb128: Anyhow, since you and pitti seem to be doing most of the ftpmaster grunt work these days, I won't presume to tell you how to do your job.
[11:30] <infinity> seb128: Just a friendly "this is what I do" thing. :)
[11:30] <seb128> infinity: thanks ;)
[11:31] <infinity> Mithrandir: Do you have enough screen sessions idling on drescher? :P
[11:53] <tepsipakki> when will flashplugin-nonfree get released to feisty-security?
[11:53] <tepsipakki> it's been in -proposed for over two weeks now
[11:53] <pitti> tepsipakki: it's in updates already, isn't it?
[11:54] <tepsipakki> doesn't appear to be
[11:54] <pitti> flashplugin-nonfree | 9.0.48.0.0ubuntu1~7.04.1 | feisty-updates/multiverse | source, i386
[11:54] <tepsipakki> right
[11:55] <tepsipakki> that's not added on installation
[11:55] <pitti> that would be a bug
[11:55] <tepsipakki> same for universe
[11:56] <tepsipakki> hmm, I'll check a more recent installation..
[11:57] <tepsipakki> yep, same there
[12:00] <tepsipakki> if gutsy has it too, I'll fix it there
[12:00] <pitti> tepsipakki: but -security is enabled for universe/multiverse?
[12:00] <tepsipakki> yes
[12:02] <pitti> hm, so we should copy that to -security, too, I think
[12:02] <pitti> tepsipakki: done
[12:02] <tepsipakki> pitti: whoa, thanks
[12:03] <pitti> tepsipakki: but please file a grave bug against, erm, the installer? about -updates for universe/multiverse
[12:03] <tepsipakki> I'll add an entry for the -updates locally (in sources.list.d)
[12:03] <tepsipakki> yes, it's in apt-setup
[12:03] <tepsipakki> deb $protocol://$hostname$directory $codename-updates $dists
[12:03] <tepsipakki> dists="$dists restricted"
[12:04] <tepsipakki> is universe/multiverse now always enabled?
[12:04] <pitti> tepsipakki: I don't think so, but there should be a comment for it
[12:04] <tepsipakki> hmm, I'll take this to #ubuntu-install :)
[12:04] <pitti> tepsipakki: i. e. when someone uncomments universe, he should immediately stumble upon uncommenting -updates/-security for it, too
[12:06] <tepsipakki> seems that universe/multiverse are indeed enabled since feisty
[12:07] <tepsipakki> I can only blame myself, since I added the support for u/m -security, should've done -updates too :)
[12:07] <pitti> ah, heh :)
[12:07] <tepsipakki> shame on me
[12:10] <pitti> hey tkamppeter
[12:10] <tkamppeter> hi pitti
[12:10] <pitti> tkamppeter: I had an idea this morning
[12:10] <pitti> tkamppeter: I'm currently working on an apparmor profile for cups, and I got pretty far already
[12:10] <pitti> tkamppeter: if we get that working and shipped by default, I'm fine with dropping the derooting patches
[12:10] <tkamppeter> pitti, do you mean replacing non-root mode of CUPS by AppArmor protection?
[12:11] <pitti> I currently have a cupsd running as root, yes
[12:11] <pitti> profile more or less works, I'm currently fine-tuning it
[12:11] <tkamppeter> A 1.3.x cupsd?
[12:11] <pitti> tkamppeter: no, the current 1.2.12 one
[12:12] <tkamppeter> pitti, which kind of protection actions AppArmor does exactly apply to CUPS with your profile?
[12:13] <pitti> tkamppeter: unfortunately it is much less protection than what we currently have with the unprivileged system user, but it's still fairly good
[12:13] <pitti> tkamppeter: http://people.ubuntu.com/~pitti/tmp/usr.sbin.cupsd  my current version
[12:14] <pitti> tkamppeter: removing some important capabilities like NET_ADMIN or SYS_ADMIN, and FCHMOD/FSUID is already helping a lot
[12:14] <pitti> tkamppeter: and confining fs access to the minimum
[12:14] <tkamppeter> pitti, important is also not to over-protect, as on the CUPS mailing list one saw a lot of complaints from Red Hat users as Red Hat introduced SELinux and most were caused by the SELinux protection.
[12:14] <pitti> tkamppeter: I'm sure that the current profile breaks some stuff, like cups-pdf
[12:15] <pitti> tkamppeter: those backends need separate profiles with elevated privileges, like writing into user's homes
[12:15] <pitti> tkamppeter: but *shrug*, it's easy to fix stuff like that with a profile
[12:15] <pitti> tkamppeter: if upstream stays so absolutely unwilling to even recognize the need to confine it, that's the best we can do, I'm afraid
[12:17] <tkamppeter> I see your profile now and is seems that it simply gives certain file access permissions to /usr/bin/cupsd
[12:17] <pitti> tkamppeter: that, permissions to subprocesses, and capability confinement
[12:18] <tkamppeter> What do the letters m and i in the permissions mean? rwx is clear for me.
[12:18] <pitti> tkamppeter: 'm' -> mmap (in plain English: load a shared library, mostly)
[12:18] <pitti> tkamppeter: 'ix' -> allow execution and inherit parent process privileges
[12:19] <pitti> tkamppeter: there's also 'px' (allow execution and use a separate profile for the proces), and 'ux' (unconfined execution)
[12:19] <tkamppeter> and "rm"? Is CUPS allowed to "rm /etc/group"?
[12:20] <pitti> tkamppeter: no, that's 'r'ead and 'm'map
[12:20] <pitti> mmap is probably not required for those files, but it doesn't hurt either
[12:20] <tkamppeter> But why m for /etc/group? /etc/group is not a shared library.
[12:20] <pitti> see my previous sentence
[12:21] <pitti> I'll remove it, for cleanliness
[12:23] <tkamppeter> Will AppArmor block actions not explicitly permitted by the profile or can you choose between blocking and warning, like you can do with Red Hat's SELinux?
[12:23] <pitti> tkamppeter: you can choose
[12:23] <pitti> tkamppeter: I developed the profile in 'complain' mode
[12:23] <pitti> tkamppeter: my initial upload will be 'complain' and call for testing (and sending me the logs)
[12:23] <pitti> tkamppeter: a bit later, when I got more testing, I'll flip the default to enforce, I think
[12:24] <pitti> I do not plan to regress the default install security that much
[12:24] <pitti> tkamppeter: so, WDYT about the plan?
[12:26] <tkamppeter> pitti, I think this is great. The new CUPS has so many new authentication and network features which make the non-root patches arbitrarily complicated. And with AppArmor one drops the patches and the admin can easily configure the extra security by the profile.
[12:27] <tkamppeter> And if a user complains that something goes wrong one does not open the CUPS completely but only changes a line in the profile and the problem gets fixed.
[12:27] <pitti> (or flip the profile to complain)
[12:28] <TheInfinity> hello ... i have a strange thing here which might be a bug ... upstart mixes the mount order - nfs volumes are mountet after local volumes altough it is the other way round in fstab
[12:29] <TheInfinity> is it really a bug or is there somehow a reason for this?
[12:31] <pitti> tkamppeter: "sudo aa-complain cupsd" btw
[12:32] <pitti> tkamppeter: and 'aa-enforce cupsd' to enable it again
[12:32] <cjwatson> TheInfinity: nothing to do with upstart - there are separate init scripts to mount local and network filesystems and they're explicitly ordered that way
[12:32] <cjwatson> TheInfinity: this is necessary because local filesystems (e.g. /usr) might well be needed to bring up networking
[12:33] <cjwatson> TheInfinity: we're not in a position yet (perhaps upstart will eventually let us be in such a position) to have the kind of flexibility to mount some network filesystems first if the network is available
[12:33] <cjwatson> TheInfinity: I suggest not attempting to rely on having network filesystems mounted first
[12:33] <TheInfinity> argh sorry wrong description ... first the nfs filesystem is mountet, then the /home FS
[12:33] <TheInfinity> and thats my problem.
[12:33] <cjwatson> that IS odd
[12:35] <TheInfinity> http://www.ubuntuusers.de/paste/13354/?format=txt <-- this is the order
[12:36] <TheInfinity> and i dont know why. it seems that /home is in rc5 "misc mounts" - which is quite strange
[12:36] <TheInfinity> because if i mount with rc.local it works
[12:38] <TheInfinity> should i report it as bug? or any suggestions where this problem comes from?
[12:40] <cjwatson> TheInfinity: (rc5 isn't used by default; our default runlevel is 2)
[12:41] <cjwatson> I have no scripts that call mount in rc2 here
[12:41] <cjwatson> bizarre that you have /var/run and /var/lock mounted multiple times
[12:41] <cjwatson> do you have any custom init scripts?
[12:41] <TheInfinity> no
[12:42] <TheInfinity> its a default 6.10 installation dist-upgraded to 7.04
[12:42] <tkamppeter> pitti, nice, so we can perhaps have these two called by buttons in some admin GUI tool.
[12:44] <cjwatson> TheInfinity: /home should be mounted from /etc/rcS.d/S35mountall.sh
[12:45] <cjwatson> also is the ordering as visible in /proc/mounts actually causing a problem?
[12:45] <TheInfinity> i use kubuntu as clients - so theres nothing i changed except installation of a few user apps and using somehow network data
[12:45] <TheInfinity> yes because i want to mount the nfs volume in /home
[12:46] <TheInfinity> and that does not work because /home is mountet after the nfs volume
[12:49] <TheInfinity> hmm. strange at all ...
[01:15] <pitti> tkamppeter: yay, it actually works reasonably now, and it just took two tiny patches to make cups work without DAC_OVERRIDE
[01:22] <tkamppeter_> pitti, What is DAC_OVERRIDE?
[01:23] <pitti> tkamppeter: man capabilities; in short, it allows a process to ignore any fs permissions
[01:23] <pitti> tkamppeter_: i. e. read and write any file in the system
[01:23] <pitti> tkamppeter_: i. e. as root you can edit a file which is  till:lpadmin 644
[01:24] <pitti> tkamppeter_: this capability gives you full root power, so for any sensible privilege reduction this must be forbidden
[01:34] <seb128> iwj: did you upload a gdm built with consolekit? There is no sign of it, maybe it did conflict with the new version which has been uploaded this week?
[01:41] <cjwatson> seb128: looks like it clashed, yes
[01:41] <cjwatson> 20:15:09 DEBUG   gdm_2.19.4-0ubuntu4.dsc: Version older than that in the archive. 2.19.4-0ubuntu4 <= 2.19.5-0ubuntu1
[01:41] <seb128> cjwatson: ah, thanks. What log has upload errors?
[01:42] <iwj> seb128: Ah, yes, I have a mail about a reject.
[01:42] <iwj> I'll fix it up,.
[01:42] <seb128> iwj: thanks
[01:42] <seb128> I would have done it but I'm not sure if you just changed the configure option or if you did also some other changes
[01:46] <cjwatson> seb128: /var/mail/lp_archive
[01:46] <cjwatson> "log"
[01:46] <iwj> There are other changes too.  I'll merge them.
[01:47] <seb128> cjwatson: ok ;)
[01:56] <StevenK> pitti: I have bent pdftk to my will, and uploaded it. Leaving openoffice.org on ppc as the last remaining rdepends on libgcj7
[01:56] <pitti> StevenK: yay, thanks
[02:00] <Tonio_> Mithrandir: I saw you uploaded bluez-libs last version, will you upload bluez-utils soon ?
[02:14] <pygi> hey Hobbsee
[02:15] <Hobbsee> hiya pygi
[02:17] <geser> Hey Hobbsee
[02:17] <Hobbsee> greetings, geser :)
[02:18] <Kmos> https://wiki.ubuntu.com/UbuntuBugDay/20070801 -> this still valid for action? =)
[02:19] <seb128> Kmos: bugs can be triaged any day
[02:19] <Kmos> bug 127203
[02:19] <ubotu> Launchpad bug 127203 in Ubuntu "After installation AVG anti-virus problems with louding up-dates" [Undecided,New]  https://launchpad.net/bugs/127203
[02:19] <Kmos> we don't support AVG, so it must be invalid ?
[02:22] <seb128> Kmos: I would use the standard reply for "not enough details"
[02:23] <Kmos> seb128: ok
[02:23] <seb128> like from where he installed AVG, what update issues he has, etc
[02:23] <seb128> if that doesn't come from ubuntu the bug can be marked Invalid
[02:24] <Kmos> yep
[02:24] <pygi> seb128, I don't think we have avg in ubuntu repos?
[02:24] <Kmos> i asked now if it's reproducible and the steps to get there
[02:24] <Kmos> pygi: no, we don't
[02:24] <seb128> pygi: I don't know what AVG is and what the guy is speaking about
[02:24] <pygi> seb128, antivirus
[02:24] <seb128> pygi: if you know that's something we don't ship feel free to close the bug
[02:25] <pygi> seb128, ok, will do
[02:25] <Seveas> isn't it in -commercial?
[02:25] <Kmos> Seveas: nop
[02:25] <Kmos> http://archive.canonical.com/pool/main/a/
[02:25] <Kmos> only arkeia
[02:25] <Kmos> :)
[02:26] <pygi> Seveas, nop, isn't there
[02:27] <pygi> Kmos, I'll close the bug as invalid
[02:27] <Kmos> pygi: ok
[02:29] <pygi> done
[02:29] <stgraber> hi
[02:29] <pygi> hey stgraber :)
[02:33] <Kmos> can I request sync of treil ? http://packages.qa.debian.org/t/treil.html
[02:35] <pygi> Kmos, sure, but would you be willing to learn a procedure how to request sync?
[02:36] <Kmos> pygi: i already know that :)
[02:36] <Kmos> requestsync is my friend also
[02:37] <Kmos> i'm building it on pbuilder first :)
[02:37] <pygi> Kmos, ok, so you know that you have  to check changelog of both ubuntu and debian package, see if ubuntu has any changes from debian, evaluate if they can be dropped, and all the other procedures mentioned at https://wiki.ubuntu.com/SyncRequestProcess ?
[02:38] <Kmos> pygi: yep
[02:38] <Kmos> treil has the first sync for gutsy
[02:38] <Kmos> but it's out-of-date
[02:38] <pygi> if you follow all procedures, you should be fine ;)
[02:38] <TheMuso> Also be careful to ensure that the MD5Sum of both orig tarballs are the same, fi they are both the same upstream versino.
[02:38] <Kmos> TheMuso: oki =)
[02:39] <Kmos> it compiles fine on pbuilder for gutsy
[02:39] <cjwatson> the other point is to check up on why it's needed
[02:39] <pygi> cjwatson, +1
[02:40] <geser> Kmos: re bug #129572: is it worth to sync powertop just to remove someone from uploaders?
[02:40] <ubotu> Launchpad bug 129572 in powertop "Please sync powertop (universe) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/129572
[02:40] <cjwatson> "is newer" isn't usually sufficient reason to spend the time bothering; there should be something useful in it
[02:40] <pygi> i.e. bugfixes
[02:40] <cjwatson> note that we will mass-sync everything after gutsy+1 opens; we've stopped the auto-sync so that things can settle down a bit
[02:40] <cjwatson> pygi: we're before upstream version freeze, so interesting features are fine too
[02:41] <Kmos> cjwatson: new upstream release ? and some bugs fixed.. like in ruby/triel.rb
[02:41] <pygi> cjwatson, got it, but this is a game =)
[02:41] <seb128> Does anybody know if there is a naming convention for package shipping pam modules? The new gnome-keyring has one, I'm wondering if the package should name gnome-keyring-pam or libpam-gnome-keyring
[02:41] <cjwatson> Kmos: that seems to be the case for treil, but not powertop
[02:41] <soren> seb128: libpam-foo
[02:41] <cjwatson> so my point is just that it's something you should think about
[02:41] <cjwatson> if we wanted to mass-sync everything from Debian that was newer, we could still do so :-)
[02:41] <Kmos> cjwatson: ah powertop.. i understand now :)
[02:41] <cjwatson> (without needing somebody to go through them all laboriously by hand)
[02:42] <seb128> soren: thanks
[02:42] <soren> seb128: np
[02:43] <xxxxx1> hey Hobbsee :)
[02:44] <Hobbsee> hiya xxxxx1
[02:46] <Kmos> cjwatson: u're right :) i've invalid it myself with comment
[02:46] <Kmos> bug 129547
[02:46] <ubotu> Launchpad bug 129547 in workman "Please sync workman (universe) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/129547
[02:46] <Kmos> this one can be invalided too.. only changed to the new menu system
[02:46] <Kmos> that will be auto-synced in gutsy+1
[02:47] <Kmos> right?
[02:48] <geser> everything without Ubuntu changes will be auto-synced at the begin of the next dev cycle
[02:49] <Hobbsee> geser: are you busy now?
[02:50] <geser> it depends :) what work want you to delegate to me?
[02:50] <coNP> Kmos: I guess this bug does not requires instant decision. There is a sync bug filed, someone will take care of it.
[02:51] <Hobbsee> geser: reduce https://bugs.launchpad.net/~ubuntu-universe-sponsors
[02:51] <geser> Hobbsee: already started looking on it
[02:51] <Hobbsee> geser: i'm presuming one can ignore all of Kmos' bugs that are incomplete.  or at least, be very careful with them.
[02:51] <Hobbsee> geser: great :)
[02:52] <Kmos> Hobbsee: they all build fine :)
[02:52] <Hobbsee> Kmos: yes, i'm more wondering over the "is there any point to them" question - like the drop in uploaders, or the standards change, etc.
[02:52] <TheMuso> Kmos: But as previously discussed, its more than just making sure they build. I just pointed out that you should test build them as a first check point before filing a sync request.
[02:53] <Kmos> TheMuso: yep..
[02:53] <Kmos> Hobbsee: i'm killing the ones that are pointless.
[02:53] <Tonio_> Hobbsee: did you notice than nspluginviewer crashes for a few weeks now ?
[02:53] <Hobbsee> Tonio_: have not tried it.  but i've seen teh bugs
[02:54] <Hobbsee> Kmos: great
[02:54] <geser> should accepted sync request still be set to "confirmed" or now to "Triaged"?
[02:55] <StevenK> geser: Former
[02:55] <Hobbsee> geser: TheMuso ScottK StevenK and anyone else who works on these, if you could mention that you're locking the merges in here (or -motu i guess), so we dont try to upload the same things while we're all working on the queue, that'd be good
[02:58] <cjwatson> Kmos: it's definitely best not to do a half-hearted job of switching to the new menu layout, and given that it doesn't actually much matter for Ubuntu (we use .desktop files instead), I don't propose to spend any time converting main
[02:59] <Kmos> cjwatson: yeah, that's why i killed powertop and workman sync requests
[02:59] <Kmos> -2 to check :)
[03:01] <Hobbsee> woo!
[03:02] <Kmos> bug 129544
[03:02] <Kmos> i think this one can be killed too. but not 100% sure
[03:02] <Kmos> [14:02]  <ubotu> Error: Could not parse data returned by Launchpad: The read operation timed out
[03:03] <Kmos> bug 129544
[03:03] <ubotu> Launchpad bug 129544 in xmms-midi "Please sync xmms-midi (universe) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/129544
[03:03] <Kmos> ah :)
[03:04] <Hobbsee> Kmos: clean target might be the only vaguely useful thing there.  unsure too
[03:05] <Kmos> yeah.. i see only that one
[03:05] <Kmos> others are pointless
[03:07] <Kmos> any preview of updated langpacks for gutsy ?
[03:10] <pygi> Kmos, here:
[03:10] <pygi> http://people.ubuntu.com/~pitti/langpacks/
[03:11] <Kmos> thx
[03:12] <pitti> pygi: that's obsolete
[03:13] <pitti> pygi: updated gutsy langpacks are uploaded straight to gutsy itself
[03:13] <pygi> pitti, my apologies then.
[03:23] <pitti> Riddell: just curious, what's wrong with qt 3.3.8?
[03:31] <Zapek> when one fixes a (non reported) bug through bzr push sftp. do I have to create a launchpad bug entry about it or it will be seen?
[03:33] <cjwatson> it won't typically be seen automatically
[03:33] <cjwatson> report it
[03:35] <Riddell> pitti: it broke chinese and other complex characters
[03:36] <Riddell> pitti: not sure why though, other distros seem to be ok, it's something I need to look more at
[03:46] <iwj> seb128: My gdm test build worked so I've uploaded.  Hopefully it won't clash again.
[03:46] <seb128> iwj: could thanks, should be fine this time I didn't touch gdm since tuesday
[03:47] <seb128> s/could/cool
[03:48] <iwj> *snort*
[03:48] <iwj> You're too dynamic :-).
[03:48] <seb128> ;)
[03:50] <Kmos> pitti: requestsync when has apt working (locked) says it doesn't have the package on gutsy =)
[03:50] <Kmos> to use -n :)
[03:51] <pitti> Kmos: hm, it uses rmadison, so that would be curious
[03:51] <pitti> Kmos: it doesn't touch apt at all
[03:52] <StevenK> Right, I fixed that.
[03:52] <Kmos> pitti: apt-get rmadison =)
[03:52] <Kmos> still apt
[03:52] <Kmos> right ?
[03:52] <coNP> Kmos: apt-cache rmadison
[03:53] <Kmos> :)
[03:53] <Kmos> i've only apt-get running with update-manager
[03:53] <Kmos> and it says that
[03:53] <Kmos> after i do apt-get update
[03:53] <Kmos> and it's when I see it's locked
[03:53] <pitti> kylem: is it actually necessary to update the kernel and both X video drivers for bug 123879? I just copied mesa to -updates
[03:53] <ubotu> Launchpad bug 123879 in xserver-xorg-video-intel "[SRU]  feisty missing support for intel graphics hardware" [High,Fix released]  https://launchpad.net/bugs/123879
[03:53] <pitti> Kmos: no, not apt. rmadison
[03:53] <kylem> pitti, yes, the kernel bits are already done though.
[03:54] <pitti> Kmos: seems like you are on feisty?
[03:54] <pitti> hi mathiaz
[03:54] <Kmos> pitti: i tested that on my laptop with gutsy
[03:54] <pitti> coNP: apt-cache madison != rmadison
[03:54] <mathiaz> hi pitti
[03:54] <coNP> oh, I am sorry
[03:54] <pitti> coNP: rmadison queries a CGI script on somewhere.ubuntu.com
[03:54] <pitti> coNP: NP :)
[03:54] <StevenK> Kmos, coNP: Actually, no. It's 'apt-get madison' which uses your local cache, requestsync uses rmadison which queries a script on people.ubuntu.com
[03:54] <Kmos> :-)
[03:54] <pitti> mathiaz: today I learned to love apparmor :) (see my cups mail)
[03:55] <Kmos> StevenK: *g*
[03:55] <mathiaz> pitti: great... more love comes to apparmor every day :)
[03:55] <coNP> -EINVALIDOPERATION
[03:55] <pitti> mathiaz: the profile probably needs some love, though, and I found a bug in the standard perl #include
[03:55] <coNP> Oh I overlooked the last part.
[03:56] <pitti> kylem: ok, so I'll remove the verification-done tag again for the other tasks
[03:56] <kylem> ok.
[03:56] <StevenK> pitti: In other news, it looks like I've run out of NBS stuff to do ... :-)
[03:56] <pitti> \o/
[03:57] <StevenK> pitti: python-xen-3.1 is handled, libsilc-1.0-2 is due to silky using the old API and I don't care enough to fix it, and all of libatlas-cpp-0.6-0c2a, libcal3d11c2a and liberis-1.3-11 are waiting on a new sear.
[03:57] <Hobbsee> was anyone dealing with mail-notification?  i remember hearing talk about it
[03:59] <Kmos> Hobbsee: how about to ask to remove package rt2400 on gutsy? now it's included in the kernel..
[03:59] <Kmos> so after gutsy, no more rt2400
[03:59] <Kmos> and less confusion with debian sync..
[03:59] <Hobbsee> Kmos: no idea about kernel stuff.  i try to avoid it
[03:59] <Kmos> zul says it's included now in kernel
[03:59] <Kmos> in gutsy
[04:00] <Hobbsee> then it should be fine to remove.
[04:00] <StevenK> Kmos: Perhaps the rt2400 package contains a newer version than the one in the kernel?
[04:00] <Hobbsee> pitti: when we ask for removals, do you auto-blacklist, or do we need to ask for blacklisting as well?
[04:00] <zul> StevenK: if you can send me the fix for python-xen3.1 that would be cool
[04:00] <StevenK> Kmos: So please check that first.
[04:00] <Kmos> StevenK: so that's a question for kernel team
[04:00] <pitti> Hobbsee: I'll check and blacklist if necessary
[04:01] <StevenK> Kmos: Right. Ask them before dealing with the removal bug.
[04:01] <Kmos> StevenK: ok
[04:01] <Hobbsee> pitti: ah, great.  i dont suppose you could approve phpunit into feisty-proposed?  it's been sitting there since sunday
[04:02] <Hobbsee> StevenK: zul is a kernel guy, btw...
[04:02] <StevenK> zul: Did you also want me to deal with pitti's grievances?
[04:02] <pitti> Hobbsee: tomorrow, when I'll have my next regular SRU shift
[04:02] <zul> StevenK: I got half of them done so far
[04:02] <StevenK> Hobbsee: Didn't know that.
[04:02] <Hobbsee> pitti: ah great, that works.
[04:02] <Hobbsee> soren: ^
[04:02] <Hobbsee> StevenK: he's one of the xen guys
[04:02] <pitti> I'd rather get those #$(*#$ dapper langpacks fixed now
[04:02] <soren> Hobbsee: Saw it :)
[04:02] <StevenK> zul: I can deal with the rest as well as python-xen-3.1 if you wish.
[04:02] <Hobbsee> pitti: good luck with them :)
[04:03] <StevenK> Hobbsee: Knew that, didn't know he was kernel
[04:03] <zul> StevenK: no thats ok I been working on it for a while now I just need help with the python bits
[04:03] <ogra> doko, did you have a look at jintys schooltool packages already ?
[04:03] <Hobbsee> StevenK: well, i'm assuming xen and stuff is kernel too
[04:03] <StevenK> Hobbsee: Xen is both.
[04:03] <StevenK> Xen has userspace bits hanging out, too
[04:03] <ogra> doko, i testbuilt them but apparently they still want python 2.4
[04:04] <StevenK> zul: Is your packaging in bzr?
[04:04] <ogra> no matter what version i set in debian/control
[04:04] <Hobbsee> StevenK: there you go then.  enough of kernel to qualify as a kernel guy :)
[04:04] <StevenK> Hobbsee: :-)
[04:04] <zul> StevenK:  it hasnt been updated in a bit I can put the latest debian/ directory up somewhere
[04:04] <doko> ogra: go ahead and upload
[04:05] <ogra> doko, i need them in main ... 2.4 is in universe. no ?
[04:05] <doko> ogra: no, and you should just use the default python version. and please fix all bugs you'll inroduce with zope 3.4alpha
[04:06] <StevenK> zul: I'm happy to branch your bzr off and make my own and point you at it.
[04:07] <zul> StevenK: Im at work right now and the bzr stuff is out of date right now
[04:07] <StevenK> zul: Well, happy to send you a diff, if you like.
[04:07] <zul> StevenK: please
[04:11] <pitti> carlos: urgent ping
[04:11] <pitti> carlos: the dapper rosetta export is incomplete
[04:11] <carlos> pitti: urgent pong!
[04:11] <carlos> is it?
[04:11] <StevenK> infinity: I'm guessing the time for libnss-db and openssl came and went all by itself?
[04:11] <pitti> carlos: most of the German files seem to be ok, but french is missing 20 files
[04:11] <pitti> carlos: http://people.ubuntu.com/~seb128/language
[04:11] <carlos> pitti: are we talking about the full export?
[04:11] <pitti> carlos: yes
[04:12] <carlos> hmm, how's that possible?...
[04:12] <pitti> carlos: I just tar tzf'ed the original tarball, they are not there (so not a problem with my scripts)
[04:12] <pitti> carlos: search for the French gdebi.po as an example
[04:12] <carlos> ok
[04:13] <pitti> carlos: thanks
[04:19] <carlos> pitti: confirmed, there are some files missing...
[04:21] <carlos> pitti: oh, found the problem
[04:22] <carlos> pitti: do you have time for a new full export?
[04:22] <pitti> carlos: yes, that's ok (and anything else would be too hackish)
[04:22] <seb128> carlos: what is the problem? just curious
[04:22] <pitti> carlos: if you could start it by this evening, so that I'll have a tarball tomorrow morning, we should be good
[04:23] <carlos> seb128: a bug in our export code related to launchpad accounts deactivated
[04:23] <carlos> seb128: they don't have an email address anymore, and thus, the export fail
[04:23] <seb128> ah ok
[04:23] <seb128> good that we caught the issue before upload
[04:23] <carlos> seb128: indeed
[04:24] <carlos> pitti: I need to wait for the gutsy export finish
[04:25] <carlos> after that, I will do the dapper one (although I'm not sure whether i will have time before the db refresh starts...
[04:29] <geser> mvo: can you fix bug #123131 in your next compizconfig-settings-manager upload? it's the missing python-gtk2 dependency.
[04:29] <pitti> carlos: ok, thanks; do you think that's manageable by tomorrow?
[04:29] <Amaranth> uh oh, ubotu lag
[04:30] <Hobbsee> ubotu: ping
[04:30] <carlos> pitti: I think so, let me see how gutsy export goes...
[04:30] <carlos> pitti: It only exported 1/4  of the .po files for gutsy...
[04:30] <ubotu> Launchpad bug 123131 in compizconfig-settings-manager "ccsm crashed with ImportError in <module>()" [Medium,Triaged]  https://launchpad.net/bugs/123131
[04:31] <carlos> pitti: let's see how it goes later tonight
[04:31] <ubotu> pong
[04:31] <pitti> carlos: ok; I can probably do some bits on Saturday morning, too, if needed
[04:32] <carlos> pitti: well, in worse case, you would get it Friday evening
[04:33] <pitti> carlos: ah, ok; that sounds good
[04:33] <mvo> geser: thanks, doing that now in my bzr repo
[04:36] <pitti> mathiaz: why does aa-unconfinded have so many duplicate lines? does that have any meaning?
[04:40] <Hobbsee> seb128: being a desktop person, could you look at https://bugs.launchpad.net/ubuntu/+source/gnome-art/+bug/60258 at some point?  i dont have the expertise to figure the best solution.
[04:40] <ubotu> Launchpad bug 60258 in gnome-art "Ruby crashes while using gnome-art-manager" [Medium,Incomplete] 
[04:41] <seb128> Hobbsee: hum, why do you think it's a priority?
[04:41] <Hobbsee> seb128: i tried to use a "at some point" - i'm not sure what you want done to request a "can you look at this at some point?"  it's not a priority
[04:42] <seb128> Hobbsee: or rather "any reason you ping me on IRC about a bug assigned to me where I commented less than a week ago"? ;)
[04:42] <Hobbsee> seb128: bugger, i didnt read the dates on there.  apologies :(
[04:43] <seb128> Hobbsee: no problem, I was just wondering if there was  special reason for the ping, it's on my list but after some other things I want to get done for next tribe ;
[04:43] <seb128> ;)
[04:43] <desrt> seb128; i filed this bug 1 day and 12 seconds ago about the latest versions of gnome not being packaged and they're STILL not packaged!
[04:43] <ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
[04:43] <Hobbsee> seb128: ah, no problem.  it was a general ping about it.  i thought your comments were from months ago, as there were many comments after.
[04:43] <StevenK> Hah
[04:43] <seb128> desrt: lying, take a penalty card
[04:43] <StevenK> Go, ubotu go
[04:43] <seb128> desrt: it is packaged ;)
[04:43] <desrt> win :)
[04:45] <mathiaz> pitti: it seems that it's to support different cases.
[04:45] <Hobbsee> desrt: we could just mark you with the invalid stick, or something :P
[04:45] <mathiaz> pitti: but I agree that it needs to cleaned up.
[04:46] <mathiaz> pitti: It's not the latest version from upstream.
[04:46] <pitti> 6411 /usr/sbin/avahi-daemon not confined
[04:46] <pitti> 6411 /usr/sbin/avahi-daemon not confined
[04:46] <pitti> 6501 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (enforce)'
[04:46] <pitti> 6501 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (enforce)'
[04:46] <seb128> desrt: do you use anything from the stock GNOME anyway?
[04:46] <pitti> mathiaz: ^ I don't see any difference there
[04:46] <desrt> seb128; almost all of it
[04:46] <pitti> mathiaz: avahi has two threads (the other one is pid 6412), so that could be it
[04:46] <mathiaz> pitti: well - it's says if it's confined or not.
[04:46] <pitti> mathiaz: but cupsd is only one thread
[04:46] <seb128> desrt: because between your gdm hacked for smooth transition, your new panel and applet, dconf, etc ... ;)
[04:46] <pitti> mathiaz: right, but why twice?
[04:46] <seb128> desrt: we should name GNOME 3 DNOME
[04:47] <desrt> seb128; i'm a l33t platform hax0r now.  git masters (or svn trunk) of glib, cairo, pango, dvalue, dconf, gtk :p
[04:47] <mathiaz> pitti: ah. hum - don't know.
[04:47] <pitti> mathiaz: just cosmetical anyway, I was just curious what it means
[04:47] <mathiaz> pitti: the script is a bit old - it may be fixed upstream.
[04:47] <desrt> seb128; all my apps are more or less stock
[04:47] <Riddell> Mithrandir: could you give back libcaptury in feisty-backports?
[04:48] <desrt> seb128; btw: gnome 3 is proceeding as planned :)
[04:48] <pitti> mathiaz: ok, thanks
[04:48] <StevenK> Riddell: I think Mithrandir is on VAC
[04:49] <seb128> desrt: well, one looking at your screen could have the feeling that you don't use many desktop applications
[04:49] <pitti> mathiaz: http://people.ubuntu.com/~pitti/tmp/usr.sbin.cupsd is my first profile, btw \o/ I hope I didn't screw it up too much (it still needs some love, though)
[04:49] <desrt> seb128; i'm a big gnome-terminal user.....
[04:49] <seb128> desrt: you usually have some form of small panel, an IM client and a command line
[04:49] <seb128> ha ha
[04:49] <desrt> gnome 3 = telepathy, gvfs, dconf, all the love gtk has been getting recently, etc
[04:50] <mathiaz> pitti: I'll have a look at it.
[04:50] <mathiaz> pitti: did you put the profile in the cups package ?
[04:51] <pitti> mathiaz: yes, see https://lists.ubuntu.com/archives/ubuntu-devel/2007-August/024027.html
[04:51] <pitti> mathiaz: why, do you rather want to keep it in -profiles?
[04:52] <pitti> mathiaz: my plan is to ship gutsy with an enforced profile, so with -profiles in universe that would be kind of hard
[04:52] <mathiaz> pitti: the current plan is to ship profiles in -profiles
[04:52] <pitti> mathiaz: that's why I put it there
[04:53] <mathiaz> pitti: but if the package maintainer wants to ship a profile in the package that's fine also
[04:53] <mathiaz> pitti: that's what suse is doing.
[04:53] <tepsipakki> desrt: dconf? can't find anything on that
[04:53] <pitti> mathiaz: ah, ok; should it be any problem for you, then we can still change it
[04:53] <mathiaz> pitti: they were shipping all profiles in -profiles and they've moved the profiles into each package.
[04:53] <desrt> tepsipakki; it's this secret project being hacked on by some madman
[04:53] <mathiaz> pitti: it just requires more work from the maintainer.
[04:54] <pitti> mathiaz: eventually this shuold happen in Debian/Ubuntu, too, but while the profiles are still under heavy development, it's easier to group them
[04:54] <tepsipakki> desrt: sounds promising :P
[04:54] <mathiaz> pitti: but shipping in the profile is fine by me.
[04:54] <mathiaz> pitti: we support both scenario.
[04:54] <pitti> mathiaz: ok, great
[04:54] <mathiaz> pitti: I guess it'll be on a per-package basis.
[04:55] <mathiaz> pitti: may be we could ship profiles that have been well tested in the package.
[04:56] <mathiaz> pitti: and others in -profiles.
[04:56] <pitti> mathiaz: I agree
[05:07] <mathiaz> pitti: if I want to add a general hook in apport, does it have to be a python script ?
[05:09] <pitti> mathiaz: yes, it has to ATM
[05:11] <mathiaz> pitti: ok. Thanks.
[05:11] <mathiaz> pitti: I'm trying to run apport-cli on a server - and it fails with :" No module named xdg.DesktopEntry"
[05:12] <mathiaz> pitti: I guess that apport.ui needs more tweaking for a server environment.
[05:12] <pitti> mathiaz: ah, can you please file a bug about this?
[05:12] <pitti> mathiaz: I don't want to depend on the xdg python module, it should quietly forego those tests instead
[05:13] <pitti> anyway, time to leave for today (grandma's bday)
[05:13] <pitti> cu tomorrow!
[05:13] <mathiaz> pitti: yes. I will.
[05:30] <Riddell> infinity: could you give back libcaptury in feisty-backports?
[05:30] <Riddell> oh actually it's needs building, so that should be fine
[05:31] <infinity> Riddell: If it's being auto-given-back, that could be problematic...
[05:32] <infinity> Oh, no, it's never failed in the first place.
[05:32] <infinity> What made you think it needed giving back? :)
[05:32] <Riddell> impatience problably, ignore me :)
[06:20] <Kmos> asac: backport of thunderbird from gutsy to feisty not possible, right ?
[06:20] <Kmos> bug 129968
[06:20] <ubotu> Launchpad bug 129968 in thunderbird "Outdated Mozilla Thunderbird in Add Programs" [Undecided,New]  https://launchpad.net/bugs/129968
[06:21] <infinity> That's not a bug, it's a feature.
[06:21] <seb128> doko: can you give a retry to gcin on powerpc i386 sparc?
[06:21] <seb128> or infinity ;)
[06:22] <infinity> seb128: I'll do it.
[06:22] <ScottK> Kmos: There's already a backports request in for it.  More testing needs to be done.
[06:22] <ScottK> See you all later.
[06:22] <seb128> infinity: thanks
[06:22] <Kmos> i've marked it as duplicate
[06:23] <Kmos> infinity: hehe
[06:23] <asac> Kmos: well ... not possible is not right
[06:24] <asac> Kmos: but not trivial either
[06:25] <Kmos> asac: yeah
[06:25] <Kmos> i've duplicated the bug, because already there is one
[06:26] <asac> Kmos: if there is someone interested in backporting tbird, I would be happy to help :) ... in fact i think we already have a feisty backport in mozillateam archive.
[06:27] <Kmos> it was done by gnomefreak ?
[06:27] <asac> yes
[06:27] <Kmos> :-)
[06:50] <mikmorg> Is there a bug report for Feisty's Ubiquity auto-mounting when partitioning?
[07:10] <mikmorg> cjwatson: Hello there
[07:39] <johanbr> seb128: Could I ask you a quick question? Is the evince version in gutsy supposed to support fillable PDF forms? I got that impression from the evince mailing list, but it doesn't seem to work.
[07:41] <coNP> johanbr: it is sure that this not listed in the evince changelog
[07:42] <johanbr> coNP: Okay, thanks. I just got that impression from http://mail.gnome.org/archives/evince-list/2007-July/msg00011.html , but maybe that part of the announcement doesn't actually apply to evince 0.9.2.
[07:43] <coNP> !info evince gutsy| johanbr
[07:43] <ubotu> johanbr: evince: Document (postscript, pdf) viewer. In component main, is optional. Version 0.9.3-0ubuntu1 (gutsy), package size 1130 kB, installed size 5888 kB
[07:44] <johanbr> That information doesn't seem to have much bearing on my question.
[07:44] <coNP> Sorry, form support comes from libpoppler as the mail also says. It should be in.
[07:44] <coNP> Okay, I was just not sure if we have 0.9.2 or 0.9.3 in gutsy.
[07:45] <johanbr> So you mean it should work? I couldn't get it to work and nor could someone else I asked to try out. Have you tried it?
[07:45] <Seveas> "Currently it requires poppler HEAD, but let's hope we'll see a new
[07:45] <Seveas> release of poppler."
[07:46] <coNP> Yes, that is what I am investigatint
[07:46] <Seveas> so unless ubuntu compiled evince against bleeding edge poppler, no forms support
[07:46] <Seveas> !search libpoppler gutsy
[07:46] <ubotu> Found: gibbon, gutsy, newqueue, pidgin, ubuntu+1, gusty
[07:46] <Seveas> meh
[07:46] <coNP> !info poppler gutsy
[07:46] <ubotu> Package poppler does not exist in gutsy
[07:46] <elmo> popplar
[07:46] <coNP> !info libpoppler gutsy
[07:46] <ubotu> Package libpoppler does not exist in gutsy
[07:46] <johanbr> !info libpoppler1 gutsy
[07:46] <ubotu> libpoppler1: PDF rendering library. In component main, is optional. Version 0.5.9-0ubuntu1 (gutsy), package size 635 kB, installed size 1720 kB
[07:46] <seb128> johanbr: need poppler CVS version
[07:47] <johanbr> seb128: Ahhh, okay. Thank you. Is there any chance of a poppler with forms support going into gutsy?
[07:48] <seb128> johanbr: depending of upstream
[07:48] <seb128> if it's ready yes
[07:48] <seb128> if it's not, no
[07:48] <seb128> I can't speak for them
[07:48] <johanbr> Where "ready" means "0.6 release", I'm guessing?
[07:48] <coNP> We have 0.5.9 in gutsy now that is development version. Relased in May, though.
[07:50] <johanbr> Seems like the release is being delayed due to ISP trouble: http://tsdgeos.blogspot.com/
[07:51] <seb128> johanbr: no, when "ready" means "ready", like working correctly
[07:51] <johanbr> Okay. Thank you.
[07:52] <seb128> you're welcome
[07:52] <seb128> sorry to not have extra details
[07:52] <seb128> as said it's mainly a matter to see if upstream consider it stable enough to be distributed
[07:52] <seb128> which also mean waiting for them to roll a new tarball
[07:52] <seb128> and then we can see if they break ABI again and that sort of things
[07:53] <seb128> if they roll a new one I'll try to get it in gutsy though
[07:53] <LaserJock> cjwatson: poke :-)
[07:55] <iwj> I don't believe this.  dpkg has no standard sll and dll manipulation macros.  What was I thinking ??
[07:55] <Mertiki> does somedody have a laptop with a synaptic touchpad that can help me in confirming a bug in launchpad?
[07:57] <maxb> Would anyone be able to point me toward the software that actually creates the distribution .iso images? I'd like to learn about it.
[07:57] <BenC> what's easiest way to test a webcam?
[07:58] <LaserJock> maxb: you might want to look at https://launchpad.net/ubuntu-cdimage
[08:03] <maxb> Thanks!
[08:04] <LaserJock> maxb: in particular, also look at configs/devel in the bzr branch for ubuntu-cdimage as it has links to other branches that are important
[08:05] <maxb> I guess I should get around to learning bzr
[08:12] <geser> is it possible to sync NEW packages from Debian after UVF and before NewPackagesUniverseFreeze?
[08:17] <LaserJock> geser: I'm pretty sure that's what it means
[08:19] <geser> ok, because I had the choice to sync now and file later an UVF exception for the next version or wait for the next version and sync later
[08:20] <LaserJock> if you know it'll be there before the New Package freeze then that seems ok
[08:22] <geser> upstream will try to get the new version out and into debian before end of the month
[08:22] <Zero_> Hi, i'm fixing a bug on the installation of Ubuntu Alternate, and i wanna know if the Automatic Network Detection detected correctly the DNS
[08:25] <doko> asac, seb128: how do I convince firefox/thunderbird to use normal sized fonts again? changing prefs in the applications itself doesn't change anyting
[08:25] <Zero_> i know
[08:26] <Zero_> go in preferences and change the font
[08:27] <Zero_> it need be by prefs in the applications
[08:27] <Zero_> but you need click in a botton in right to change
[08:29] <tkamppeter> Yesterday I asked you all for testing CUPS 1.3.0-RC2. Now there is a better version, with nonroot stuff removed from the packaging more cleanly and the AppArmor protection introduced by pitti. Get the new packages (0ubuntu2) here:
[08:29] <tkamppeter> http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/cupsys13/
[08:31] <mattwalston> Where is a roadmap or schedule for the next release?
[08:32] <geser> !gutsy
[08:32] <ubotu> Gutsy Gibbon is the code name for the next release of Ubuntu (7.10). See https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000276.html and https://wiki.ubuntu.com/GutsyReleaseSchedule - Roadmap and specifications: https://blueprints.launchpad.net/ubuntu/gutsy - Support in #ubuntu+1
[08:52] <hggdh> Mertiki: what bug? I do have a laptop on Gutsy
[09:15] <asac> doko: did you find a solution?
[09:58] <theCore> mjg59:  ping
[09:59] <mjg59> theCore: Hello
[09:59] <theCore> mjg59: hi, I heard you are reviewing Automatix for the TechBoard, is that true?
[10:01] <theCore> mjg59: I started since yesterday I fairly intensive review myself
[10:01] <mjg59> theCore: Ok, that's good
[10:01] <theCore> mjg59: so, maybe what I have found could help you
[10:01] <mjg59> Sure
[10:02] <theCore> would you like to read my working draft?
[10:02] <mjg59> Sounds good
[10:04] <theCore> honestly, I am not sure yet if I will publish it, even though I did put a lot of effort
[10:06] <theCore> I will certainly have to smooth the tone of article, even if I tried to be neutral
[10:07] <mjg59> theCore: It ties pretty much in with what I'd noted
[10:07] <doko> asac: no
[10:08] <asac> doko: so did you zoom your fonts or what?
[10:08] <theCore> mjg59: do you plan to review EasyUbuntu too?
[10:08] <mjg59> theCore: We hadn't been asked to, but it might be worth it
[10:10] <seb128> what do you review automatix for? do you want to get it uploaded to Ubuntu?
[10:10] <theCore> at least, there isn't major security concerns in it
[10:11] <mjg59> seb128: No, the tech board were asked to provide feedback on the technical quality of it
[10:12] <ogra>  did you find any ?
[10:12] <seb128> well, the concern with it would rather be what it install and how that breaks installations
[10:12] <seb128> rather than the technical quality of the thing
[10:12] <mjg59> seb128: Not really, no
[10:12] <mjg59> It's perfectly able to break your system all on its own
[10:13] <seb128> we should just make clear to users they should not install it
[10:13] <TheInfinity> seems to be impossible to get information about mounting local FS ... why does ubuntu mount local FS after network file systems (and any other FS)?
[10:13] <seb128> I think pitti already made apport stop sending bugs if it has been installed
[10:14] <mathiaz> seb128: yop
[10:14] <ogra> seb128, did you ever read their faq ?
[10:16] <seb128> ogra: no
[10:16] <ogra> http://www.getautomatix.com/wiki/index.php?title=FAQ
[10:16] <mvo> seb128: I think it is better to have it in the archive than outside of it
[10:16] <theCore> ogra: that FAQ is certainly misleading
[10:16] <mvo> same for envy, I think if it comes into the archive, we can work on it better and improve pthings
[10:16] <ogra>  Does Automatix2 break Ubuntu upgrades? - "The chances of Automatix being behind the breaking of a Ubuntu upgrade is as high as the packages which Ubuntu releases for that release and the subsequent one. Most of what Automatix installs comes directly from the Ubuntu repositories and is installed using apt-get (just like in synaptic and Add/Remove). It is more likely that an upgrade problem lies upstream in the Ubuntu repositories."
[10:16] <ogra> yay, its our fault
[10:16] <mvo> ogra: I have seen my share of upgrade issues :)
[10:16] <ogra> the next two sentences are pretty rude ...
[10:16] <ogra> In fact Ubuntu has been notorious for breaking xserver packages several times on stable releases in the past. They have also been extremely notorious for passing on the blame to Automatix for their own failings (which they still haven't stopped doing).
[10:16] <seb128> I read something about not listening to people who recommend not installing it
[10:17] <theCore> that? --- Is Automatix2 safe? Folks in #ubuntu on IRC keep telling me it isn't.   * Yes, it is perfectly safe. Thousands of users worldwide use Automatix2 every day without any issues. If you think you have run into any issues related to Automatix, please report to our forums to get quick and high quality support.
[10:17] <mjg59> Worrying about what people write is fairly uninteresting
[10:18] <theCore> One thing is sure, though, Automatix is truly bloated
[10:18] <ogra> i'm not worried, i'm sad ... with some guidance the guys putting work inot it might be good MOTUs
[10:19] <Nafallo> ogra: the first thing they need to be teached is to dput _source.changes.
[10:19] <ogra> heh
[10:21] <theCore> I wonder such tools are so popular
[10:21] <theCore> wonder why*
[10:22] <Nafallo> cause people are fucking lazy. that's why.
[10:22] <stdin> becuae people are too lazy to read what the proper way is
[10:23] <theCore> stdin: that is a weak argument
[10:23] <Nafallo> I'm glad my ex-gf won't do it again anyway. she received a massive lecturing for about 20 minutes.
[10:23] <stdin> it's true tho, they just don't read the wiki
[10:24] <stdin> or even ask
[10:24] <minghua> theCore: I think because automatix generally have does a good job with installing stuff those people want, and as long as upgrade is not involved, it doesn't cause much problems.
[10:24] <Nafallo> stdin: not even that in many cases. they need to TRY to play an mp3 and get the nice coded-installer.
[10:24] <Nafallo> codec even
[10:26] <theCore> minghua: then, perhaps it would be a good time to start providing meta-packages for these peoples
[10:26] <fdoving> i've noticed many reviewers mention they use automatix to get this and that.
[10:27] <minghua> theCore: Not impossible for many packages.  Examples I know are Adobe acroread, Windows codecs, Real player.
[10:27] <stdin> there is (k)ubuntu-restricted-extras for instance
[10:27] <stdin> (for things in the repos anyway)
[10:27] <mneptok> minghua: Automatix is a problem whether you dist-upgrade or not.
[10:28] <minghua> theCore: We can probably try providing some installer-like package like msttfcorefonts, though.
[10:28] <mc44> minghua: you mean like ubuntu-restricted-extras? :)
[10:28] <minghua> mneptok: I don't use it.  I just read that many people are happy with it.
[10:28] <mneptok> minghua: try the view from my chair ;)
[10:28] <stdin> many people use windows, doesn't make them right :p
[10:28] <theCore> minghua: hmm, the msttcorefonts package isn't enough?
[10:29] <minghua> mc44: I don't exactly know what ubuntu-restricted-extras does.
[10:29] <mc44> " Installing this package will pull in support for MP3 playback and decoding,
[10:29] <mc44>  support for various other audio formats (gstreamer plugins), Microsoft fonts, Java runtime environment, Flash plugin, LAME (to create compressed audio files), and DVD playback."
[10:29] <minghua> theCore: enough for those fonts, sure.  But not enough for people who need Adobe acroread, Real player, etc.
[10:30] <theCore> realplayer is in the commercial component, no?
[10:31] <minghua> Oh, that reminds me, Opera is a frequently requested package, too.
[10:31] <minghua> The thing is, automatix is just convenient for many people.  And we probably should advocate/advertise ubuntu-restricted-extras more.
[10:32] <stdin> opera and realplayer are in commercial
[10:33] <theCore> minghua: well... I am not sure if advocating restricted plugins is a good thing
[10:33] <seb128> doko: looks like no GNOME package needs to be change for lpia from a quick greping
[10:33] <dobey> it's hard enough trying to get the fluendo mp3 codec package. the "you need additional non-free codecs" thing wants to install the gstreamer-ugly package. i had to go command-line apt-get install the fluendo package
[10:33] <doko> seb128: please send a list to infinity
[10:33] <seb128> doko: "no"
[10:33] <Nafallo> dobey: sounds like a bug to me.
[10:33] <doko> and mark them on the wiki
[10:34] <minghua> theCore: Neither am I sure.  But a lot of people still see it essential.  If we turn them down, they all seek help from other places, like automatix.
[10:34] <doko> seb128: ?
[10:34] <dobey> Nafallo: bug or not, it's relevant to the issue at hand :)
[10:34] <seb128> doko: there is no package that need to be changed, what do you want in the list?
[10:34] <mvo> dobey: please remind me about it (fluendo mp3)
[10:35] <doko> seb128: infinity needs a list of packages for manual bootstrap. that shouldn't be that difficult ...
[10:35] <doko> seb128: and at least glib had to be updated
[10:36] <seb128> doko: there is no DEB_HOST_ARCH or DEB_HOST_GNU_CPU to it
[10:36] <seb128> so I've not looked for everything
[10:36] <DaSkreech> Hello Has anyone been approached about Smolt?
[10:36] <theCore> hmm... what happened to acroread in feisty?
[10:36] <theCore> issues with Adobe?
[10:37] <doko> seb128: still infinity needs a list, "all of gnome" is not enough
[10:37] <seb128> doko: ok, will do that
[10:37] <doko> thanks
[10:38] <seb128> you're welcome
[10:38] <seb128> DaSkreech: is that the hardware database thing?
[10:38] <DaSkreech> Yes
[10:38] <DaSkreech> They invited other Distro to join in so that it would be a Linux effort rather than a Fedora effort
[10:38] <minghua> theCore: Removed.  Because it's not redistributable according to the new license terms.
[10:39] <DaSkreech>  I'd assume that Ubuntu was one of those given consideration
[10:39] <seb128> DaSkreech: not sure, maybe ask to pitti when he's around tomorrow or to mvo
[10:39] <theCore> minghua: ah, I remember now
[10:39] <theCore> minghua: thanks
[10:39] <seb128> DaSkreech: I don't know about it
[10:39] <DaSkreech> mvo: Ping
[10:40] <theCore> maybe after all, the best thing to do would simply be to ignore Automatix / EasyUbuntu
[10:40] <dobey> mvo: remind you?
[10:41] <ogra> seb128, cr3 does the hwdb stuff now ... dunno who else
[10:41] <Nafallo> dobey: about fluendo-mp3
[10:41] <ogra> DaSkreech, ^^^^
[10:41] <DaSkreech> ogra: ah thanks cr3 isn't around now?
[10:42] <ogra> he's not regulary in -devel
[10:42] <dobey> Nafallo: yes, i saw that. the question was what he means by "remind me"
[10:42] <seb128> ogra: there was some specs during the Sevilla UDS where mvo and pitti spoke about it I think
[10:42] <ogra> DaSkreech, i pinged him ... not sure he's around
[10:42] <mvo> hello DaSkreech
[10:42] <DaSkreech> ogra: Well he's online but not in any chans is that an indication that he's not AK ?
[10:42] <Nafallo> dobey: to poke him about it tomorrow probably so he can fix that bug :-)
[10:42] <seb128> or open a bug
[10:42] <DaSkreech> mvo: Hi I was asking if you had heard of anything about smolt ?
[10:42] <mvo> dobey: remind me to fix that fluendo-mp3 is not listed in the codec installer
[10:43] <dobey> ok
[10:43] <seb128> mvo: I think you discussed it with pitti during the Sevilla UDS so I directed him to you
[10:43] <mvo> ogra: hwdb? yes, I talked about this with cr3 and pitti, there is some LP work going on there too
[10:44] <ogra> mvo, any idea who is the head for it now ?
[10:44] <mvo> DaSkreech: I did and I like it. the client was easy to sport to ubuntu IIRC
[10:44] <mjg59> seb128: My panel seems to have stopped grouping multiple applications. Any idea if that's deliberate?
[10:44] <mvo> ogra: not really, lets talk about it after the meeting
[10:44] <DaSkreech> mvo: So we are interested?
[10:45] <DaSkreech> What about the HWDB that Ubuntu currently has will that be moved into this new initiative?
[10:45] <DaSkreech> Or is this all too early to ask? :-)
[10:45] <ogra> that will rather be rewritten from scratch some day
[10:46] <mvo> DaSkreech: I guess its a bit early, but I definitely feel that something better is required. and smolt looks quite good so I think we should not re-invent the wheel if we can help it
[10:46] <DaSkreech> mvo: Wonderful thanks a lot
[10:47] <seb128> mjg59: it used to group windows without a class and that has been fixed, otherwise it should still group application in the same class
[10:47] <seb128> (libwnck change)
[10:47] <mjg59> seb128: I've got a large number of gnome-terminal windows all showing up separately
[10:47] <mjg59> Though I'm running panel from about a month ago
[10:48] <seb128> mjg59: if you open the task lists properties, what mode is selected?
[10:48] <mjg59> Ah - never group windows
[10:48] <mjg59> I'm sure I didn't change that myself
[10:48] <mjg59> Given I didn't know that window existed :)
[10:49] <seb128> mjg59: maybe vuntz changed the default choice ;)
[10:49] <mjg59> seb128: I haven't deleted my gconf settings...
[10:50] <mjg59> Oh, so yeah, if I've never touched it the default would change
[10:50] <seb128> mjg59: if you have never touched the option you use the system schemas value
[10:50] <seb128> right
[10:51] <theCore> how could I recognize a package build with checkinstall?
[10:52] <theCore> ah, know. nevermind
[10:58] <Kmos> http://packages.debian.org/changelogs/pool/main/g/gambas2/current/changelog
[10:58] <Kmos> can I resquest a sync for gambas2 ? it has some bugs fixed
[11:04] <theCore> mjg59: thanks for you feedback, btw
[11:04] <theCore> your*
[11:05] <mjg59> theCore: I'm just tidying up what I've got - I'll show you in a few minutes
[11:05] <cr3> DaSkreech: hi, ogra tells me you want to talk about the hardware database?
[11:05] <theCore> mjg59: ah, ok
[11:05] <DaSkreech> cr3: hi Yes
[11:06] <DaSkreech> Quick lil guy ins't he?
[11:06] <DaSkreech> Ah he's back
[11:06] <DaSkreech> cr3: hi Yes
[11:06] <su-hoens`rZ> anyone know why the kubuntu alt cd installer doesn't locate 3 of my 4 sata drives even though the bios and the main cd find them fine? :(
[11:06] <DaSkreech> cr3: Fedora invited Ubuntu to use Smolt?
[11:09] <cr3> DaSkreech: sounds like a good idea, how is the HAL data transmitted to smolt?
[11:09] <DaSkreech> cr3: Not sure I just hit the Linux.com article and decided to ask in #kubuntu-devel they hadn't heard of anythign so I asked in here
[11:10] <DaSkreech> I'm for the move to having one HWDB for all Linuces as long as we can give in the data that Ubuntu has collected before
[11:11] <DaSkreech> cr3: I'm just naively guessing that lshw should be good enough :)
[11:12] <cr3> DaSkreech: I was asking more specifically about the data format used to transmit, but that's implementation detail I can gather from the source
[11:13] <cr3> DaSkreech: I agree that information should be gathered in a single location, but that is difficult to enforce as can be seen with bugtracking for example: some projects use bugzilla for example, but launchpad tries to integrate that
[11:14] <cr3> DaSkreech: in a similar respect, different hardware database may have different objectives so I think it's a reality that there will have to be duplicate information in order to meet each of these objectives
[11:14] <cr3> DaSkreech: for example, the hardware database does not aim to strictly report hardware but also report status of the hardware by running tests. it's one thing to know you have a wireless controller, it's another to know that it works
[11:15] <cr3> DaSkreech: in that sense, I see the hardware database exporting data to smolt or, the other way around, allowing smolt to query the hardware database
[11:16] <DaSkreech> cr3: What would be the basis of having an aggregate database that knows wether someone's specific card is working?
[11:16] <cr3> DaSkreech: let me ask you a question: have you ever wanted to buy a computer and know beforehand if the hardware worked?
[11:16] <DaSkreech> I think that having a dual layer would be useful though
[11:16] <DaSkreech> cr3: Yeah
[11:16] <DaSkreech> That's what Live Cds are for :)
[11:17] <cr3> DaSkreech: I see you've never bought online...
[11:17] <DaSkreech> cr3: Yes I have but only with machines I've tested with Live CDs ....
[11:17] <cr3> DaSkreech: anyways, that is ultimately the question that the hardware database will attempt to answer rather than just gathering metrics
[11:17] <DaSkreech> cr3: I know I understand
[11:18] <DaSkreech>  It will also give good stats to show case to hardware \vendors to show that they should provide support
[11:18] <cr3> Nafallo: you could eventually buy stuff *others* know works :)
[11:18] <ogra> Nafallo, hard to do with laptops
[11:18] <Nafallo> cr3: yes. google, ubuntu wikis, maintainers etc... :-)
[11:19] <Nafallo> ogra: Dell Latitude D630. only problem is sound, and that has a patch floating round.
[11:19] <Nafallo> s/rou/arou/
[11:19] <DaSkreech> Course there is already a KDE app that does this :(
[11:20] <cr3> Nafallo: been there, done that, it's a clunky approach. for example, you might find a wiki posting about one graphics controller working on one release of ubuntu and a wireless controller on another release. it's hard to find unified information about hardware.
[11:20] <Nafallo> ogra: to bad the damn Dell wanted to deliver 22nd and I'll move to England 16th :-P
[11:20] <Nafallo> cr3: that's why it takes weeks indeed :-)
[11:20] <cr3> Nafallo: heh, well put :)
[11:21] <cr3> Nafallo: I'm dedicated to saving you and others those weeks of painful sleuthing
[11:22] <Nafallo> cr3: sounds to good to be true ;-)
[11:23] <cr3> Nafallo: there's a reason why such a service exists already: it's a difficult problem to solve
[11:23] <DaSkreech> cr3: Woah. this will keep version info as well?
[11:23] <cr3> err, doesn't exist already :)
[11:23] <cr3> DaSkreech: that's critical indeed
[11:23] <Nafallo> cr3: yes, I know :-)
[11:24] <DaSkreech> cr3: Versions of products? Like hal or X or versions of distros ?
[11:24] <cr3> DaSkreech and Nafallo: would you guys like me to contact you in case we need help, like beta testing and so forth?
[11:24] <DaSkreech> cr3: Yes
[11:25] <Nafallo> cr3: just put it in Ubuntu and I'll see the new package and betatest it when/if there is time :-)
[11:25] <cr3> DaSkreech: release version but also package versions, which is also important to detect regressions
[11:27] <cr3> DaSkreech: thanks for having taken the initiative of mentionning smolt in this channel and expressing your interesting in consolidating hardware information!
[11:27] <Nafallo> cr3: is there a wikipage or something with your project? :-9
[11:27] <Nafallo> :-)
[11:28] <ogra> Nafallo, you could recycle the old HardwareDatabase page ;)
[11:28] <cr3> Nafallo: there are a few blueprints on launchpad, let me check...
[11:28] <Nafallo> ogra: not me! :-P
[11:28] <Nafallo> cr3: thanks :-)
[11:28] <DaSkreech> cr3: I've been loking for somethign like this since Knoware
[11:29] <ogra> DaSkreech, well the first implementation of the hwdb client in ubuntu was in hoary
[11:29] <DaSkreech> I know :)
[11:29] <DaSkreech> It's just much more useful to have a LInux DB rather than an Ubuntu DB
[11:29] <DaSkreech> http://developer.kde.org/summerofcode/knoware.html
[11:29] <ogra> indeed it is
[11:29] <cr3> Nafallo: this search will return most of the relevant blueprints: https://blueprints.launchpad.net/?searchtext=hwdb
[11:29] <cr3> Nafallo: I am currently most active in developing the client for the release of gutsy
[11:31] <DaSkreech> See if we could have smolt have a CLI core with an X front end a GTK front end and Qt front end it would easily implementable by all Distros
[11:31] <DaSkreech> It could also have multiple layers with the core info going to >the< database
[11:32] <Nafallo> cr3: I'll read that then. you will be using the existing package I guess?
[11:32] <DaSkreech> other info that individual distros want to collect can be kept by them
[11:32] <cr3> Nafallo: it's being rewritten, please don't look at the current state of the code :)
[11:32] <DaSkreech> Ubuntu can still have it's Users hardware Webpage :)
[11:33] <Nafallo> cr3: will not. was more about getting notification of testing in apt-listchanges ;-)
[11:34] <cr3> Nafallo: oh, so I indeed intend to use the same package, but that's not confirmed yet
[11:35] <Nafallo> cr3: you might want to ping me anyway then ;-)
[11:37] <cr3> Nafallo: will do
[11:40] <DaSkreech> Fedora is complaining that it's only used by GUI users
[11:40] <DaSkreech> cr3: Watch the Smolt page?
[11:43] <BenC> 21:24:44 ERROR   Exception while accepting:
[11:43] <BenC>  Unable to find source package linux-source-2.6.22/2.6.22-9.22 in gutsy
[11:43] <BenC>  -> http://launchpadlibrarian.net/8671171/pm6r6EGyiU4s02vU7yLeyYqsyyw.txt (Unable to find source package linux-source-2.6.22/2.6.22-9.22 in gutsy)
[11:43] <BenC> anyone aware of that problem?
[11:43] <su-hoens`rZ> anyone know why the kubuntu alt cd installer doesn't locate 3 of my 4 sata drives even though the bios and the main cd find them fine? :(
[11:43] <cr3> DaSkreech: why is it only used by GUI users?
[11:43] <Nafallo> cr3: baah. I'm not allowed to see the spec.
[11:43] <DaSkreech> cr3: Thats what they are implying
[11:44] <cr3> Nafallo: sorry about that :(
[11:46] <Nafallo> will just need to see the client then ;-)
[11:47] <cr3> Nafallo: feature freeze is in a couple weeks, so it shouldn't take too long
[11:47] <Nafallo> :-)
[11:48] <DaSkreech> I'll take a look at it this weekend are they still taking suggestions on framework or is that locked?
[11:50] <superm1> cjwatson, i saw you assigned bug 129038 to yourself, out of curiosity, what were you planning on it?
[11:50] <ubotu> Launchpad bug 129038 in lirc "lirc overwrote my lircd.conf" [Undecided,Confirmed]  https://launchpad.net/bugs/129038