[12:35] <seb128> cjwatson: new desktop CD doesn't hang without network but it displays a message saying that security sources will be added but not active, is that expected?
[12:39] <cjwatson> seb128: yeah
[12:39] <cjwatson> I'm not sure why it wasn't shown before
[12:40] <cjwatson> oh, same bug I guess
[12:40] <seb128> k
[12:40] <cjwatson> I think I agree with the intent of the message; if security updates won't be used, you should know about it
[12:40] <seb128> right
[12:41] <seb128> I was rather thinking that I still want the security, I just didn't have the network connected during the installation
[12:41] <seb128> but there is no way to know if that's the case or if the box has no internet access
[12:42] <seb128> so commenting the sources and showing the message is probably fair ;)
[12:54] <Keybuk> Ubuntu DVD amd64 [20071009] : https://iso.qa.stgraber.org/qatracker/info/1013
[12:54] <Keybuk>  ... a short amount of time passes ...
[12:55] <Keybuk> Ubuntu DVD amd64 [20071010.2] : https://iso.qa.stgraber.org/qatracker/info/1030
[12:55] <Keybuk> aaiiiiieeee
[12:55] <Keybuk> there should be a law about rebuilding DVD images more than twice a week
[12:55] <Keybuk> they take that long to download!
[12:56] <cjwatson> rsync, man
[12:56] <Keybuk> I do rsync
[12:56] <Keybuk> but I'm on ADSL
[12:56] <Keybuk> so while I can download as fast as I'd like ...
[12:56] <Keybuk> I can't ACK
[12:56] <cjwatson> do you keep a local mirror?
[12:56] <Keybuk> yes
[12:56] <cjwatson> jigdo, then?
[12:56] <Keybuk> oh, mirror of cdimage
[12:56] <cjwatson> possibly based on the live CD
[12:56] <Keybuk> I don't have a mirror of the actual packages
[12:57] <cjwatson> ah, not so useful
[12:57] <cjwatson> if you're grabbing the alternate and desktop as well ...
[12:57] <Keybuk> it actually takes about 8-9 hours to rsync the cd images
[12:57] <Keybuk> yeah
[12:57] <cjwatson> I suspect that if you cat new-alternate + new-desktop + old-dvd together, and then rsync new-dvd over that, it'll be faster
[12:57] <cjwatson> since the livefs is the same
[12:57] <Keybuk> heh
[12:57] <cjwatson> assuming you have the disk space to do that, that is
[12:58] <Keybuk> rsync copes with chunks going missing?
[12:58] <cjwatson> sure
[12:58] <cjwatson> rsync is magic
[12:58] <Keybuk> heh
[12:58] <Keybuk> I might try that
[12:59] <cjwatson> or at least sufficiently advanced technology
[01:03] <soren> Do any of you use wmware workstation?
[01:03] <Keybuk> aye
[01:03] <soren> Could you check which NIC it emulates?
[01:03] <soren> eth0 is not the right answer.
[01:04] <Keybuk> pcnet32
[01:04] <soren> Figures.
[01:04] <soren> What about SCSI controller?
[01:04] <Keybuk> mpt
[01:04] <soren> Mkay.. Thanks.
[01:05] <Keybuk> ens1371 sound card :)
[01:05] <soren> Dear kernel team. In your efforts to slim down the -virtual kernel image, please don't remove my nic and scsi drivers. Love, Soren.
[01:07] <mpt> Keybuk, you rang?
[01:07] <mpt> Or are you referring to the driver that is the bane of my existence?
[01:08] <Keybuk> mpt: you are not a SCSI card :p
[01:09] <soren> Who's good a spotting why stuff breaks on buildd's but not in sbuild  and is also actually around these days?
[01:09] <Keybuk> Ian is pretty good at that kind of thing
[01:09] <soren> http://launchpadlibrarian.net/9898594/buildlog_ubuntu-gutsy-i386.linux-ubuntu-modules-2.6.22_2.6.22-14.35_FULLYBUILT.txt.gz  <--- the vmnet module fails to build.
[01:10] <Riddell> bryce: I've raised the priority of bug 151311, it's pretty nasty
[01:10] <ubotu> Launchpad bug 151311 in xserver-xorg-video-intel "DPI in kubuntu incorrect on xorg-video-driver-intel" [High,Confirmed]  https://launchpad.net/bugs/151311
[01:11] <soren> Keybuk: I'll try when he's around again then.
[01:11] <mjg59> Yeah, that's a touch broken
[01:12] <mjg59> bryce: Weren't we nailing the dpi to 96 or whatever?
[01:12] <soren> 112x968 dpi? Wow.
[01:12] <Keybuk> whee, lanky fonts
[01:12] <bryce> mjg59: yeah I thought so
[01:13] <bryce> Riddell: sorry, I won't have time to look at it; cjwatson's sending me out for customer support for the rest of the week
[01:15] <bryce> Riddell: that is one bug we split out from 127101, which is the one I'm focusing on currently
[01:15] <Riddell> mjg59: that's gnome only and GDM is still unusable
[01:15] <mjg59> Riddell: ?
[01:15] <mjg59> No, in the server
[01:15] <mjg59> bryce: Erm.
[01:15] <mjg59> -#define DEFAULT_DPI            75
[01:15] <mjg59> +#define DEFAULT_DPI            100
[01:15] <mjg59> That's not going to override the driver.
[01:16] <bryce> mjg59: but iirc seb128 put the 96 hardcode into gnome
[01:16] <Riddell> we're talking about different things then
[01:16] <mjg59> bryce: It has to be done in the server
[01:31] <bryce> mjg59: do you know where at in the server this is done?
[01:32] <bdmurray> The fix for bug 135319 should have made it in yesterday's dailies right?
[01:32] <ubotu> Launchpad bug 135319 in usplash "Usplash progress bar not centered on the monitor" [Medium,Triaged]  https://launchpad.net/bugs/135319
[01:39] <zul> can someone push the xen-3.1 upload through contains a security update for gutsy
[01:39] <zul> thanks btw
[01:40] <keescook> zul: I think that'll get snagged after RC unfreezes.
[01:40] <zul> ah yes i forgot about that
[01:40] <mjg59> bryce: hw/xfree86/common/xf86Helper.c
[01:46] <bryce> thanks.  I also noticed something calculating dpi's in the xrandr code
[01:47] <mjg59> Hm. Yeah, it might be the xrandr-side code that's tripping us up
[01:50] <bryce> I'm making a patch for each, so folks can try either or both
[01:50] <slangasek> zul: in the meantime, is there a public report about the bug it addresses?
[01:50] <slangasek> zul: if so, please flag it with the ubuntu-7.10 milestone so that it's on the release team's radar
[01:57] <bryce> mjg59: does this look sane? http://people.ubuntu.com/~bryce/Testing/xorg-server-dpi/xorg-server_1.3.0.0.dfsg-12ubuntu9.debdiff
[01:58] <ion_> Seeing such a patch is painful. :-(
[01:59] <mjg59> Dunno, does it work? :)
[01:59] <bryce> no clue
[01:59] <mjg59> Easiest way is just to build and do an xrandr query in the new server
[02:00] <ion_> Whatever is done, the DPI should *not* be overridden if the user has set DisplaySize manually in xorg.conf.
[02:05] <mjg59> ion_: Why not? It is already in the desktop environment.
[02:07] <bryce> mjg59: I'd appreciate it if you'd take a quick look at this backtrace:  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/127101/comments/65
[02:07] <ubotu> Launchpad bug 127101 in xserver-xorg-video-intel "laptop hangs when switching video mode" [Unknown,In progress] 
[02:07] <bryce> mjg59: we're looking for any ideas for further gdb work or other things to test
[02:09] <mjg59> bryce: Uhm. It hit the breakpoint. There's not a lot else I can say from there
[02:12] <bryce> well, the system locks up right after that point.
[02:21] <mjg59> bryce: Need to keep stepping at that point until hitting the instruction where it actually hangs
[02:22] <bryce> https://bugs.freedesktop.org/attachment.cgi?id=11964&action=view
[02:23] <bryce> looks like its around line 1959 of i830_driver.c - a loop doing something with PALETTE_A
[02:23] <bryce>    for(i = 0; i < 256; i++) {
[02:23] <bryce>       OUTREG(PALETTE_A + (i << 2), pI830->savePaletteA[i] );
[02:23] <bryce>    }
[02:24] <mjg59> Try putting a usleep in there
[02:25] <bryce> usleep(1) ?
[02:26] <mjg59> Bit longer
[02:26] <mjg59> Try 20 or so
[02:50] <bdmurray> sladen: was bug 135319 supposed to have been fixed?
[02:50] <ubotu> Launchpad bug 135319 in usplash "Usplash progress bar not centered on the monitor" [Medium,Triaged]  https://launchpad.net/bugs/135319
[03:07] <jojo4u> so ... is the release candidate on it's way?
[03:09] <slangasek> it is imminent
[03:12] <jojo4u> nice. btw. are there any automated tests done on each daily? I only found https://wiki.ubuntu.com/UbuntuAutomatedTesting and the qatracker in the topic
[03:21] <bryce> mjg59: btw, here's an strace:  http://launchpadlibrarian.net/9943161/127101-strace.txt
[03:23] <mjg59> bryce: I don't think that really helps
[03:45] <mekius> hi, in Ubuntu gutsy, it creates an /etc/fstab with a /media/cdrom entry in it
[03:46] <mekius> this is unecessary when hal is available and actually causes hal to return an error
[03:46] <mekius> anyone know how this is being added to the /etc/fstab?
[03:58] <cjwatson> mekius: partman-target does it; it's needed to make apt work right (I believe both in the installer and outside)
[03:59] <cjwatson> it's too delicate to change for gutsy
[03:59] <mekius> damn :/
[03:59] <mekius> this causes issues with some stuff we have since we are trying to use HAL exclusively and not attempting to parse /etc/fstab at all
[04:00] <mekius> anyway to make hal not care about /etc/fstab that you know of?
[04:02] <mekius> any way*
[04:02] <cjwatson> mekius: no idea, sorry, I don't know much about hal
[04:02] <mekius> alright
[04:03] <mekius> wish hal would parse /etc/fstab and use the mount point or something
[04:03] <mekius> seems goofy for it to just give up and fail :/
[04:03] <mekius> anyway, thx for the help
[04:03] <mekius> guess i can't change the way ubuntu works wrt to this
[04:03] <mekius> might just have to cut the line
[04:13] <bryce> mjg59: adding the usleep() had no effect; still crashed with gray block lockup
[04:14] <mjg59> bryce: Ok, so probably not a timing issue. If you skip that block entirely, does it work?
[04:14] <bryce> I'll give it a shot
[04:35] <bryce> mjg59: after disabling that block (and the one after) I've been unable to reproduce the issue
[04:49] <mekius> bryce: hey, not your realm i'm sure, but hal refuses to mount any device listed in /etc/fstab, someone mentioned that this is necessary on the livecd for the install, is it possible to add something in ubiquity to remove the cdrom device from /etc/fstab before copying it to the installed system?
[04:50] <mekius> bryce: or will we have to do this ourselves, it seems like a pain in the ass :/
[04:50] <bryce> that I don't know
[04:50] <bryce> sorry
[04:50] <mekius> ok
[04:50] <mekius> that's fine, i figured you might not :)
[04:52] <mekius> hmm, how to fix this, probably gonna just have to cut the file during boot
[04:52] <mekius> or comment the line might be simpler
[05:13] <cjwatson> mekius: no, it's necessary post-install as well in order for apt to be able to retrieve files from the CD (AFAIK)
[05:14] <cjwatson> mekius: we're not going to change ubiquity for this in gutsy (not that it would be appropriate specifically in ubiquity anyway); we may revisit this in hardy though
[05:15] <cjwatson> mekius: post-install> for example, the Edubuntu add-on CD, though there are other cases where it's useful for people to use apt with the CD
[05:17] <mekius> cjwatson: hmm, i see, well we don't care much about the CD after install, but i think i'll just hack it out for now
[05:17] <mekius> it breaks things
[05:21] <jshriver> Greetings everyone
[05:22] <cjwatson> mekius: I understand that you don't, but some people do; just explaining why *we* can't just hack it out of the installer :)
[05:22] <cjwatson> mekius: btw, /etc/fstab isn't copied to the installer system, it's created right there in the first place
[05:22] <jshriver> hrm so linux development questions are inappropriate here? recommend a channel?
[05:23] <mekius> cjwatson: created where, on the live cd?
[05:23] <cjwatson> mekius: /lib/partman/finish.d/50fstab_removable_media_entries is the script in question
[05:23] <mekius> hmm, k
[05:23] <mekius> cjwatson: so this is only used for special install discs?
[05:24] <cjwatson> in some circumstances ubiquity does rely on being able to install some packages from the CD
[05:24] <mekius> ah
[05:24] <mekius> are these special circumstances, or could this happen on any install?
[05:24] <cjwatson> you could maybe arrange to call something just before ubiquity exits that seds /target/etc/fstab
[05:25] <mekius> yeah, that is what i was thinking of doing
[05:25] <mekius> but even later then that
[05:25] <cjwatson> mekius: moderately special but I'm not willing to enumerate the possibilities :)
[05:25] <mekius> :)
[05:25] <cjwatson> any install on Intel Macs will install mouseemu from the CD, for one
[05:26] <cjwatson> there are some other cases
[05:26] <mekius> gotcha, alright
[05:26] <cjwatson> mekius: can't be a whole lot later since ubiquity unmounts /target just before it exists
[05:26] <cjwatson> exits
[05:26] <mekius> i've got a place to do the sed that shouldn't intefere with all this stuff
[05:27] <cjwatson> jshriver: "Linux development" is an extremely broad topic. Narrow it down a bit for yourself and pick a channel based on that; you'll probably find most of them are quite obviously named.
[05:29] <jshriver> looking for a C library that lets me capture data from the soundcards line-in for analysis
[05:34] <cjwatson> jshriver: I'm not an expert in this, but I'd start by searching for "alsa capture library" or some such
[05:39] <bdmurray> cjwatson: What performs the mounting of crypto partitions when booting up now?
[05:40] <bdmurray> Or rather presents the dailog for entering your password to have the partition mounted?
[05:49] <cjwatson> bdmurray: cryptsetup
[05:49] <bdmurray> 'kay thanks
[07:03] <nikosapi> Is RC1 still planned to be released today (Thursday)?
[07:09] <Hobbsee> probably
[07:11] <nikosapi> ok, thanks.
[07:31] <frostburn> there's a bug in the nvidia module introduced after 100.14.09 for certain users, is there a way to get that into the repo as an alternative?
[07:34] <RAOF> frostburn: Proabably not at this point.  We *already* have 3 different nvidia drivers in there!
[07:34] <frostburn> yeah i see new and legacy
[07:34] <frostburn> and glx
[07:34] <StevenK> I thought 100.14.09 was already in there as -new
[07:34] <RAOF> And nvidia-glx being the third.
[07:34] <RAOF> StevenK: No, that's 100.14.11 or something
[07:34] <frostburn> StevenK, it's 100.14.19
[07:35] <RAOF> StevenK: The idea is that drivers newer than .09 have a particular regression.
[07:35] <RAOF> frostburn: Can you not use nvidia-glx?
[07:35] <frostburn> RAOF, no direct rendering
[07:36] <RAOF> frostburn: What card?
[07:36] <frostburn> geforce go 7600
[07:36] <RAOF> Also, no direct rendering seems more likely to be an artifact of Xgl than poor drivers.
[07:36] <RAOF> Heh, same card as me :)
[07:36] <frostburn> 64bit system?
[07:36] <RAOF> Yup
[07:36] <frostburn> i'm on a hp9000t
[07:37] <RAOF> Colour me not seeing whatever bug you're seeing with nvidia-glx-new, though.
[07:37] <frostburn> http://www.nvnews.net/vbulletin/showthread.php?t=92339   nearly the same as this.
[07:37] <RAOF> It's an X lockup with some specific integraded cards, right_?
[07:38] <RAOF> frostburn: You'll notice that was due to hardware problems? :P
[07:38] <frostburn> it doesn't lock up, the screen flickers, videos can't be played, and continues to flicker randomly
[07:38] <frostburn> RAOF, keep reading
[07:39] <frostburn> link at the end says they eliminated all hardware problems
[07:39] <frostburn> sec, let me find the other article
[07:40] <RAOF> frostburn: So, "screen flickers with compiz every now and then" *is* something I'm seeing, because of fun refresh-rate issues.
[07:40] <RAOF> (I believe)
[07:40] <frostburn> http://www.nvnews.net/vbulletin/showthread.php?t=99426     it isn't  try the .09 ones and it wont flicker any more
[07:47] <RAOF> frostburn: So anyway, my (doesn't count for anything) opinion is: (1) the .19 driver probably fixes more than it breaks, and hense should probably not be revertet, and (2) there's absolutely no way that a 4th nvidia driver is getting added to the archives.
[07:48] <frostburn> yeah, the next best thing i could do is write a howto in the forums for others if they have the same problem
[07:49] <RAOF> frostburn: Again, does nvidia-glx not work?  (It's possible that you'd see a bug where /lib/linux-restricted-modules/.nvidia_new_installed is left behind and breaks nvidia-glx)
[07:49] <frostburn> RAOF, i'll give it another whirl, perhaps tomorrow
[07:55] <superm1> bryce, i managed to test a few cases today that BulletProofX would need to kick in upon the first boot (such as the user choosing the wrong proprietary driver during install).  and it's working as expected now with the ubiquity and xorg changes :)
[08:05] <bryce> superm1: ah excellent
[08:13] <dholbach> good morning
[08:13] <Hobbsee> morning dholbach!
[08:14] <dholbach> heya Hobbsee
[08:19] <maikmerten> hmmm... anybody else having experienced that the error message dialog "The composite extension is not available" in the Visual Effects preferences just won't close hitting the OK button?
[08:20] <maikmerten> (it does close using the close window decoration)
[08:22] <pitti> Good morning
[08:23] <StevenK> Morning pitti
[08:24] <Hobbsee> pitti!
[08:25] <superm1> out of curiosity, does anyone know why usbfs was turned off by default in gutsy?  Just found out via http://www.virtualbox.org/ticket/747
[08:35] <mdke> from some of the recent comments to bug 115616 it sounds like evms isn't getting removed automatically even with upgrades from update-manager; will a developer be taking a look at this before release? It's a serious one
[08:35] <ubotu> Launchpad bug 115616 in evms "Device-mapper errors: dm-linear, lookup failed" [High,Fix released]  https://launchpad.net/bugs/115616
[08:35] <mjg59> superm1: udev provides the same functionality already
[08:36] <superm1> mjg59, ah i see
[08:36] <mjg59> I suspect that virtualbox is expecting it to be in /proc/bus/usb, which is going to break in other situations
[08:36] <superm1> yeah
[08:36] <superm1> well that wasn't the case i was seeing broke actually
[08:36] <superm1> it was for a firmware loader for a usb tv tuner
[08:36] <superm1> that expected things in /proc/bus/usb
[08:37] <mjg59> But udev lets us handle doing things like setting permissions as the device node is created
[08:37] <superm1> but google pointed me at virtualbox
[08:37] <mjg59> Rather than it being racy
[08:37] <mjg59> (racey? Maybe that's better)
[08:37] <AlexC_> Hey,
[08:38] <AlexC_> Will the RC be out later today, or will it be pushed backed a bit?
[08:38] <mjg59> It should be out later today
[08:38] <superm1> so for cases like this tv tuner that something in /proc/bus/usb is expected, is there a particular way that things should be reconfigured nicely to work with udev?  Where else will the equivalent nodes be made then?
[08:38] <mjg59> But, as usual, it might end up late
[08:39] <mjg59> superm1: Either mount --bind /dev/bus/usb /proc/bus/usb or get the software fixed
[08:39] <mjg59> Anything that uses libusb will already work fine
[08:39] <liw> mjg59, do you know off-hand why a laptop suspend and hibernate would work in testing (10+ times in a row) but fail when used for real, overnight?
[08:39] <mjg59> liw: No
[08:39] <superm1> mjg59, okay i'll bug the upstream author then.  Thanks :)
[08:39] <mjg59> liw: I've heard other people hitting that, but never been able to reproduce it
[08:40] <liw> mjg59, I seem to have a 100% repeatable case, go me
[08:40] <AlexC_> great, thanks mjg59
[08:48] <liw> https://wiki.ubuntu.com/DebuggingKernelSuspend seems like a clear set of instructions for me to test this... except it only works for suspends up to about three minutes, it says
[08:53] <frostburn> RAOF, well .09 doesn't work either lol
[09:09] <kagou> good morning
[09:09] <dholbach> hi kagou
[09:10] <kagou> what's up dholbach
[09:10] <dholbach> kagou: doing great - how are you?
[09:10] <kagou> fine
[10:30] <dholbach> mdke: you might want to refer to the motu team, not the ubuntu-dev team
[10:30] <dholbach> (in your blog post)
[10:31] <seb128> pitti: do you accept new packages again? pidgin and gnome-power-manager might be worth considering
[10:32] <pitti> seb128: I'll rather wait for slangasek on those; he didn't accept them over night, and I don't want to disrupt his stragegy now
[10:32] <seb128> k
[10:32] <seb128> I though you were the one who accepted the packages this morning
[12:13] <doko> is detection of 1920x1200 screens supposed to work?
[12:15] <tepsipakki> doko: what panel?
[12:15] <tepsipakki> at least dell panels have some issues
[12:17] <doko> tepsipakki: new iMac 24"
[12:20] <popey> my dell works
[12:20] <popey> out of the box
[12:20] <tepsipakki> doko: does the X server get it right without xorg.conf?
[12:21] <tepsipakki> popey: what model?
[12:23] <popey> tepsipakki: I would need to boot it to check again, i have not done so for a few weeks
[12:23] <popey> it's a dell inspiron xps gen 2, with an nvidia 6800Go
[12:24] <tepsipakki> popey: ah, so a laptop.. I meant that some desktop panels (like 2007WFP) reports bogus edid-data
[12:24] <tepsipakki> or at least xresprobe fails there
[12:25] <popey> ah, sorry
[12:34] <jono> digg people - http://digg.com/linux_unix/Ubuntu_Open_Week_Announced
[12:46] <popey> woot
[12:47] <pitti> gpocentek: hello; do you have some time to test the Xubuntu RC images, or know some people who would?
[12:50] <liw> pitti, I'm in the middle of an upgrade test, but after it's done, I could test an RC image
[12:51] <liw> ogra?
[12:51] <pitti> liw: well, I'd rather like you to help with edubuntu and kubuntu testing TBH
[12:51] <ogra> pitti, my HW is freaking out again, i couldnt do a server install on real HW yet
[12:51] <pitti> hardware sucks
[12:51] <ogra> stgraber apparently had a successfull virtuqalbox install thoiugh
[12:51] <liw> pitti, sure, I'm here to test anything that needs testing
[12:52] <pitti> liw: can you please coordinate with ogra for edubuntu testing?
[12:52] <pitti> and with heno?
[12:52] <pitti> DVDs are undertested, too
[12:52] <ogra> liw, edubuntu-server i386 or amd64 would be appreciated
[12:52] <ogra> phew ... DVDs ...
[12:52] <ogra> huge downloads
[12:52] <liw> pitti, sure, I'm on #ubuntu-testing for heno
[12:52] <gpocentek> pitti: sorry I really don't have time
[12:53] <liw> eek, hugging
[12:53] <pitti> gpocentek: no problem; but do you know some other Xubuntu devs who could?
[12:53] <StevenK> liw: Point him at the debconf wiki page. :-)
[12:53] <pitti> liw: you better get used to it :)
[12:53] <ogra> liw, we're the hugging company
[12:53] <liw> StevenK, http://wiki.debian.org/HugAFinn that one? not specific to debconfs
[12:54] <gpocentek> pitti: well Lionel can't, and I wonder if Jani really cares... so I can't think of anybody else :/
[12:54] <StevenK> liw: Yes, that one. It was the simplest way to get you to remember without spoiling it
[12:54] <gpocentek> pitti: when should this be done? I might find some time tonight
[12:55] <liw> StevenK, you devious one :)
[12:55] <pitti> gpocentek: yesterday, ideally :/
[12:55] <ogra> gpocentek, Rc was scheduled for today
[12:55] <pitti> gpocentek: RC will happen in a few hours
[12:55] <pitti> l
[12:55] <ogra> l?
[12:55] <pitti> EFOCUS, sorry
[12:55] <gpocentek> then sorry but I can't :/
[12:56] <pitti> hm, maybe we should not announce the Xubuntu RC images then
[12:56] <gpocentek> if they are not tested that's certainly the better choice
[12:57] <pitti> would be embarassing if they had some grave bugs and we'd announce them, yes
[12:57] <gpocentek> but I'm not in the Xubuntu team anymore so my POV doesn't really matters
[01:14] <StevenK> mvo: Do you have a sec for several dorky apt questions?
[01:17] <Keybuk> oops, haven't got quite used to the fact that xchat-gnome sits there asking you for the server you want to join yet
[01:19] <seb128> Keybuk: ?
[01:19] <seb128> Keybuk: in the preferences you can select to autoconnect to the servers and chans you want
[01:22] <Keybuk> seb128: err, oh yeah :)
[01:23] <Keybuk> I was looking for a Server List dialog
[01:23] <Keybuk> like X-Chat ordinary has
[01:27] <cjwatson> Riddell: on bug 145226, do you think it's possible that I just need to wait a bit to give dcopserver a chance to start up?
[01:27] <ubotu> Launchpad bug 145226 in oem-config "Kubuntu OEM DCOP error" [High,Confirmed]  https://launchpad.net/bugs/145226
[01:27] <cjwatson> I'm sure I tested this and it worked for me
[01:35] <DktrKranz> could a buildd-admin give back aolserver4-nsopenssl on amd64? it should be ok now
[01:35] <mvo> StevenK: yes (just came back from lunch)
[01:36] <StevenK> mvo: I see something strange using sbuild on amd64
[01:36] <StevenK> mvo: When it comes time to unpack the .debs, it's done in all caps
[01:36] <Mithrandir> DktrKranz: given-back.
[01:37] <DktrKranz> Mithrandir, thanks
[01:39] <mvo> StevenK: I heard about this a couple of days ago too . does it only happen with sbuild? or pbuilder as well?
[01:39] <StevenK> mvo: I've not seen it with pbuilder, only sbuild, and only when building for amd64
[01:43] <StevenK> As has soren and RAOF
[01:47] <mvo> StevenK: is there a bug filed about this already?
[01:47] <StevenK> mvo: Hm. I'm not sure.
[01:50] <Riddell> cjwatson: what is dcop being used for?
[01:53] <doko> ogra: installing from the edubuntu dvd live session using ubiquity doesn't install the client chroot, correct?
[01:53] <sivang> anyone has an idea for the phone numbers in the montreal office ?
[01:55] <cjwatson> Riddell: KDE whines if it's not there. See the original bug 145226
[01:55] <ubotu> Launchpad bug 145226 in oem-config "Kubuntu OEM DCOP error" [High,Confirmed]  https://launchpad.net/bugs/145226
[01:56] <ogra> doko, correct
[01:59] <Riddell> cjwatson: but KDE isn't running, the oem-config app is qt only
[01:59] <Riddell> or is kdesu used?
[02:00] <dendrobates> Has anyone done a successful cdrom install of Gutsy on a Sun T2000?
[02:07] <cjwatson> Riddell: kdesu isn't used at that point, only in oem-config-prepare
[02:28] <seb128> jamiemcc: hi, should random png icons be indexed by tracker?
[02:30] <ion_> How should it decide not to index some images?
[02:31] <lool> seb128: I've uploaded a workaround for RB in my newly created PPA and called for testing; perhaps it would be a good idea to start talking to the release team about pushing it, and even upload it so that they can review it and let it enter the archive soon after we hear from someone?
[02:31] <seb128> lool: if you are confident that the patch will work correctly and not create a regression yes
[02:31] <seb128> lool: maybe ask slangasek about it?
[02:32] <lool> seb128: Ok
[02:32] <lool> seb128: The patch looks really innocent
[02:34] <lool> slangasek: w00t, around?
[02:35] <lool> slangasek: Could you check the debdiff I attached to #116990?
[02:35] <lool> I don't know whether it properly works around the problem, but at least it causes no regression here
[02:36] <seb128> lool: the patch looks fine to me but I'm not really a gstreamer guy so I'm not sure of what side effect the volume element can have there
[02:39] <seb128> lool: maybe attach the patch on bugzilla also for upstream input?
[02:39] <lool> seb128: Ah right
[02:40] <lool> Anyway it's meant to be a workaround, not a fix
[02:41] <seb128> lool: right but upstream might want to also consider it for the time being
[02:41] <seb128> though they should probably not, that's rather the distro job to apply workarounds for users
[02:41] <seb128> at least they will know we apply a workaround if we do ;)
[02:42] <lool> (sent)
[02:57] <jamiemcc> seb128: random pngs?
[02:58] <seb128> jamiemcc: I did apt-get source nautilus
[02:58] <seb128> and I was wondering if that's normal that tracker doesn't list any of the png in the source directory
[02:58] <seb128> nor source files
[02:58] <seb128> it's idle and tracker-stats indicates "Images: 0"
[02:59] <jamiemcc> seb128: will check...
[02:59] <seb128> I was just doing some random testing on a gutsy RC install and tried to figure a way to test tracker easily
[03:00] <seb128> I though that unpacking a source would make the sources and images being indexed
[03:00] <seb128> but that's not the case
[03:00] <jamiemcc> seb128: should do
[03:01] <seb128> the .xsession-errors has "CRITICAL **: tracker_indexer_get_hits: assertion `query->words` failed" lines, dunno if that's revelant
[03:01] <jamiemcc> seb128: that means you are searching on a stopword
[03:01] <jamiemcc> seb128: will have that tideid up
[03:03] <kagou> seb128, same problem here
[03:03] <iwj> dholbach: It looks like the API of python-distutils-extra has changed incompatibly and now human-theme FTBFS.  Bug 135299.  I had a quick look but it's not obvious to me what to do and the python-distutils-extra documentation is a bit scant.  Do you know anything about it ?
[03:03] <ubotu> Launchpad bug 135299 in human-theme "autopkgtest gutsy human-theme: erroneous package!" [High,Confirmed]  https://launchpad.net/bugs/135299
[03:04] <jamiemcc> seb128: seems to work here fine although Im on soon to be released 0.6.4 version
[03:04] <dholbach> iwj: yes, I can fix it
[03:04] <iwj> dholbach: Or just tell me what to do.  I think bug 135315 looks like the same thing.
[03:04] <seb128> jamiemcc: it's too late to get a new version in gutsy now, RC is today
[03:04] <ubotu> Launchpad bug 135315 in feisty-gdm-themes "autopkgtest gutsy feisty-gdm-themes: erroneous package!" [Undecided,New]  https://launchpad.net/bugs/135315
[03:05] <jamiemcc> seb128: I know but it contains some critical fixes, memory leaks and crash fixes
[03:05] <seb128> jamiemcc: well, right, might be considered for a stable update after gutsy but that will not be on the CD
[03:06] <jamiemcc> seb128: ok
[03:07] <kagou> seb128, have you created a bug for this problem ?
[03:07] <seb128> jamiemcc: is there any SVN patch I can try that would fix the "no source, no image gets indexed"?
[03:07] <seb128> kagou: no, I'm talking to upstream on IRC right now :p
[03:07] <seb128> kagou: I'll file a bug when I know what is going on
[03:07] <lool> seb128: Should I look into the new gcalctool, push it into sid and then propose an UVF for it in Ubuntu?
[03:07] <kagou> ok
[03:08] <jamiemcc> seb128: Im not sure whta the problem is there  - can I send patches for some critical issues with 0.6.3?
[03:08] <seb128> lool: we will not get new versions now but will package GNOME 2.20.1 in gutsy-updates
[03:09] <TheInfinity> hello ... is there any chance to get more current madwifi drivers in ubuntu with guty? or will it be the same version all 7.10 release?
[03:09] <seb128> lool: feel free to package it for Debian but that's of not real use, we will want to keep the changes to a minimal now (we will do merges with Debian in hardy) and we can't sync because of lpi anyway
[03:09] <lool> seb128: Okay; so that would be just after release?
[03:09] <seb128> lool: yes
[03:09] <seb128> jamiemcc: if the bug are in launchpad can you attach the patches there and give the bug numbers?
[03:10] <jamiemcc> seb128: sure
[03:10] <lool> Err does anybody else have tracker /twice/ in the deskbar-applet preferences?
[03:10] <seb128> jamiemcc: thanks
[03:10] <lool> I have it one time in French one time in English
[03:10] <lool> "Recherche Tracker" and at the bottom, disabled, "Tracker Live Search"
[03:11] <jamiemcc> lool: there are two options for deskbar search with tracker
[03:11] <seb128> lool: yes, that's expected, one is to run the tracker search tools, the other one is supposed to list results directly in deskbar
[03:11] <dholbach> iwj: I uploaded a pseudo-diff to http://daniel.holba.ch/temp/pseudo-diff - if you need more help with that, let me know
[03:12] <lool> seb128: I see; any reason the selection was this way around?  The other way around would be more similar to Spotlight or Google Desktop Search
[03:12] <TheInfinity> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/125919 <-- or better saidf - will this bug be solved till release?
[03:12] <ubotu> Launchpad bug 125919 in linux-source-2.6.22 "[Gutsy Tribe 2]  Wireless adapter not detected on MacBook Pro rev.3 (santa rosa)" [High,Triaged] 
[03:12] <iwj> dholbach: I'll give that a go and let you know :-).
[03:12] <iwj> Thanks.
[03:12] <dholbach> anytime :)
[03:13] <lool> seb128: Ok, got the reason, it's completely broken haha
[03:15] <seb128> we need a bug fix cycle :/
[03:15] <lool> In fact tracker is completely broken for me; it keeps indexing stuff it's not supposed to index, it's running all the time when I'm in front of the computer and not when I'm not; stracing it sometimes reveals it's loading the system immensely to update it's database, but doesn't look at any new file
[03:15] <seb128> lool: do you have 0.6.3?
[03:15] <lool> Yes
[03:16] <jamiemcc> lool: whats it indexing that it should not?
[03:16] <lool> jamiemcc: Dirs I told it not to index, such as pbuilder, ccache and the like
[03:17] <jamiemcc> lool: you need to restart trackerd after changing options
[03:17] <jamiemcc> killall trackerd
[03:17] <lool> jamiemcc: I rebooted in the mean time...
[03:18] <jamiemcc> lool: sre those dirs in the no watch option?
[03:18] <lool> Is it supposed to index shell scripts?
[03:18] <jamiemcc> yes
[03:18] <seb128> jamiemcc: ok, I've some debug information, the log has a "ERROR: execution of prepared query InsertWatch failed due to constraint failed with return code 19"
[03:18] <lool> Bah it really can't find words in documents I have from day one on this host
[03:19] <seb128> "pausing indexing while client requests or external disk I/O take place"
[03:19] <seb128> and then several "CRITICAL **: scan_directory: assertion `tracker_is_directory (uri)' failed"
[03:19] <jamiemcc> seb128: thats caused by having overlapping watch dirs in tracker-preferences
[03:19] <jamiemcc> its fixed in svn
[03:19] <seb128> jamiemcc: that's a stock gutsy RC install with nothing changed
[03:20] <seb128> ok, do you know if there is a bug on launchpad about that already? ;)
[03:20] <jamiemcc> bug 148520
[03:20] <ubotu> Launchpad bug 148520 in tracker "Trackerd starts but shows a lot of errors while indexing directories." [Medium,Fix committed]  https://launchpad.net/bugs/148520
[03:21] <lool> It seems tracker segfaults before indexing; might explain why it's always running while I'm in front of the computer and why it didn't index some files
[03:22] <jamiemcc> lool: anything in ~/.local/share/tracker log file?
[03:22] <lool> jamiemcc: I'm uploading an apport crash report; I guess it'll be merged with the pile of strstr() crashes
[03:22] <seb128> jamiemcc: .config/tracker/tracker.cfg has no overlaping directories not, it has only the user one listed
[03:23] <lool> jamiemcc: no log file there, no
[03:23] <jamiemcc> lool: there should be a tracker.log file in there
[03:23] <lool> ls .local/share/tracker
[03:23] <lool> data  lool_tracker_lock
[03:24] <lool> And data has a common.db, and that's all
[03:30] <seb128> jamiemcc: looks like tracker doesn't like the directory rename
[03:30] <seb128> jamiemcc: like mv nautilus nautiluscopy it doesn't notice the new one
[03:30] <iwj> dholbach: The file ubuntu-wallpapers.xml.in doesn't appear in the source package.
[03:31] <iwj> dholbach: And your setup.cfg change seems to expect it.
[03:31] <dholbach> iwj: sorry... I guess you can leave the file names as they are
[03:31] <seb128> jamiemcc: does it try to be smart and no reindex in this case? What happen if it didn't index it yet?
[03:31] <dholbach> iwj: I just diffed a branch where I had made it work again and a broken one (and forgot to update the file names to make more sense for you)
[03:31] <iwj> OIC
[03:32] <jamiemcc> seb128: do you still get errors on rename in log?
[03:32] <soren> Hm. I'm about to put the Jeos generation magic stuff onto Launchpad. Wouldn't it be most sensible to make the code branch owned by core-dev?
[03:33] <jamiemcc> seb128: if it gets that error then it wont be watching it
[03:33] <seb128> jamiemcc: no, when I mv it there is nothing in the log
[03:34] <seb128> jamiemcc: ok, so it just ignore it for a reason, I've no overlapping watch dirs in the config
[03:34] <iwj> dholbach: Well, I've tried various random permutations and it's still not working.  Best error message I can get is a syntax error running    intltool-merge -x po index.theme.in build/share/gnome-background-properties/index.theme
[03:34] <seb128> jamiemcc: that's reliable with apt-get source, doing a copy of the source dir works correctly with tracker though
[03:34] <jamiemcc> seb128: dunno - it stores the db for whatit watches in /tmp/tracker-pid
[03:34] <jamiemcc> seb128: if a dupicate is detected you get that error from the db
[03:35] <iwj> I changed merge_desktop_files= to xml_files= because it doesn't recognise the former any more but I do wonder if that's just wrong.
[03:35] <mvo> does anyone object if I add a conflict for nvidia-settings against nvidia-glx and nvidia-glx-new? the later two have their own /usr/bin/nvidia-settings
[03:36] <Amaranth> mvo: wow, that never got fixed?
[03:36] <dholbach> did you also change the imports, the [build_i18n]  thing and cmdclass entries?
[03:36] <iwj> dholbach: Yes.
[03:36] <iwj> That part works.
[03:36] <iwj> Or seems to anyway.
[03:36] <mvo> Amaranth: apparently not :)
[03:36] <dholbach> hang on... index.theme is not an xml file
[03:37] <iwj> Indeed.
[03:37] <dholbach> let me find out what distutils-extras expects there
[03:37] <iwj> OK, thanks.
[03:37] <dholbach> desktop_files= maybe?
[03:38] <seb128> jamiemcc: the log has a "orig not found in DB" error before the "InsertWatch failed due to constraint" error
[03:38] <jamiemcc> seb128: can you file bugs and I will get patches for your stuff - it could be while doing its indexing its getting messed up - I will delay indexing of new stuff until after initial indexing is comploeted
[03:38] <iwj> dholbach: That worked.
[03:38] <dholbach> iwj: great
[03:38] <seb128> jamiemcc: orig = nautilus-2.2.0.orig, which is the name used on unpack before the renaming
[03:39] <seb128> jamiemcc: ok, I'll open a bug
[03:39] <dholbach> glatzor is the main python-distutils-extra person
[03:40] <iwj> dholbach: The resulting .deb has some things in usr/share/locale/ which weren't there before.
[03:41] <pochu> thekorn, mjg59: mind trying liferea 1.4.4-0ubuntu2 from http://ppa.launchpad.net/pochu/ubuntu/pool/main/l/liferea/ ? It fixes your issues (crash when adding local feed, and data loss upon forced termination, and a couple of fixes). If it works fine for you (it does for me) I'll ask for an exception.
[03:41] <iwj> glatzor: Would you be able to help me out with porting some of our packages to the current gutsy python-distutils-extra ?
[03:41] <dholbach> iwj: translations that were stripped and put into the language packs?
[03:41] <iwj> dholbach: Ah, of course.
[03:41] <iwj> Which means I don't need to care.
[03:42] <dholbach> yooohoo :)
[03:42] <iwj> Let me just actually diff the actual files.
[03:42] <glatzor> for sure, iwj. but I thought that I already provided diffs for all corresponding packages after the api break
[03:42] <glatzor> iwj: which one is affected?
[03:44] <mvo> hey glatzor!
[03:44] <glatzor> hello mvo
[03:44] <iwj> glatzor: I'm fixing up human-theme right now.  I think in fact I've managed to fix it properly.
[03:45] <seb128> jamiemcc: bug #151584
[03:45] <ubotu> Launchpad bug 151584 in tracker "doesn't index apt-get source directories" [Undecided,New]  https://launchpad.net/bugs/151584
[03:46] <mvo> glatzor: I did a displayconfig-gtk upload with a small fix today
[03:47] <thekorn> pochu, wow thanks, will test this version in a minute
[03:50] <glatzor> mvo: fine
[03:51] <glatzor> when will the langauge pack freeze be in place?
[03:51] <thekorn> pochu, this fixes bug 151217 for me, thanks
[03:51] <ubotu> Launchpad bug 151217 in liferea "[gutsy]  liferea-bin crashed with SIGSEGV while trying to a new feed" [Medium,Confirmed]  https://launchpad.net/bugs/151217
[03:53] <pochu> thekorn: so does for me :) thanks for testing.
[03:54] <cjwatson> Riddell: oem-config is almost happy now that I've switched dcopserver and kwin around, but there's a strange partial grey background: http://people.ubuntu.com/~cjwatson/tmp/oem-config.png
[03:55] <cjwatson> Riddell: is there something else I should be calling?
[03:56] <Riddell> err, ouch
[03:56] <Riddell> no idea what could cause that
[04:01] <bddebian> Heya
[04:13] <pitti_> meh, who has stolen my nick
[04:14] <pitti> Hobbsee: don't worry, I just killed pitti and reinstated myself :)
[04:16] <Hobbsee> :)
[04:18] <tkamppeter> pitti, ping
[04:18] <pitti> hi tkamppeter
[04:19] <tkamppeter> pitti, today I got a bug report (bug 151510) which breaks the "printing just works" experience and the usability of system-config-printer (and also the web interface) severely:
[04:19] <ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Critical,Fix committed]  https://launchpad.net/bugs/151510
[04:19] <lool> pitti: Not sure who gets the subscription notifications exactly, but I subscribed the release team to #151351 and pinged slangasek on IRC (but he was probably not yet online)
[04:20] <tkamppeter> pitti, if you go into system-config-printer, go to the server settings, and there mark that you want to see shared remote printers nothing happens.
[04:22] <pitti> tkamppeter: hm, it does work for me; cups switches to "Port 631" and listens on all ifaces
[04:22] <Hobbsee> lool: kylem, didnt you update -intel to fix the G33 -14 kernel problem?  i'm sure i ack'd that fix.
[04:22] <tkamppeter> pitti, it is because CUPS changes all the "Brows..." settings in cupsd.conf correctly but does not change the "Listen localhost:631" to "Port 631", so that it actually listens to the broadcasts of the remote CUPS servers.
[04:22] <Hobbsee> kylem: if so, why has lool reported 151351?
[04:22] <lool> Hobbsee: It's since that revert that I get the problem personally
[04:23] <lool> Hobbsee: I don't get the problem with -13
[04:23] <tkamppeter> pitti, have you really ONLY marked the option to listen to broadcasts and NOT the option to share your local printers?
[04:23] <Hobbsee> lool: it wasnt a revert.
[04:23] <pitti> tkamppeter: I just tried that, and it does for me
[04:23] <pitti> tkamppeter: oh, no; I always enable both
[04:23] <lool> Hobbsee: Ah, I see what you mean, I have the latest intel
[04:23] <Hobbsee> lool: what is your latest version fo xserver-xorg-video-intel?
[04:23] <Hobbsee> lool: ubuntu6?
[04:23] <lool> Hobbsee: I got that intel is broken in -13 too
[04:23] <lool> Hobbsee: Yes, as stated in the bug report
[04:23] <lool> Hobbsee: I'm fully up to date gutsy
[04:23] <Hobbsee> oh, my bad.
[04:24] <pitti> lool: thanks
[04:24] <tkamppeter> pitti, and for your tests stop CUPS, delete /var/cache/cups/remote.cache and start CUPS, otherwise you see the remote printers from the cache.
[04:24] <pochu> Keybuk: re: bug 151570, I think pitti intentionally disabled it for beta because it was eating IO and CPU, but maybe we should re-enable it now?
[04:24] <ubotu> Launchpad bug 151570 in tracker "No tracker index in LiveCD session" [Wishlist,New]  https://launchpad.net/bugs/151570
[04:25] <pitti> tkamppeter: but shuoldn't enabling cups only open the UDP port to the general wild, and not the TCP one, too?
[04:25] <pitti> pochu: no, it was intentionally disabled in general on the live system
[04:25] <pitti> pochu: it kills performance and isn't that useful
[04:25] <tkamppeter> pitti, what doi you mean with "enabling cups"?
[04:26] <Keybuk> pochu: I mean that there should be an index on the CD *already*
[04:26] <Keybuk> ie. a pre-generated one
[04:26] <pochu> Keybuk: oh, misunderstood the report then.
[04:26] <tkamppeter> pitti, I have simply made the patch as small and simple and as close to upstream as possible to avoid regressions. I did not try to add a new security feature.
[04:26] <pitti> tkamppeter: erm, s/enabling cups/enabling browsing/, sorry
[04:26] <pitti> tkamppeter: right, I just wonder why it does it that way in the first place
[04:27] <pitti> tkamppeter: when I only enable browsing, I get
[04:27] <pitti> tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     4816/cupsd
[04:27] <pitti> udp        0      0 0.0.0.0:631             0.0.0.0:*                          4816/cu
[04:27] <pitti> ...psd
[04:28] <pitti> which looks just right to me; hmm
[04:28] <tkamppeter> pitti, then post a feature request/security bug report upstream so that CUPS gets corrected after the Gutsy release (and perhaps in Gutsy also as security fix).
[04:29] <pitti> tkamppeter: sorry, but I won't accept that patch
[04:29] <pitti> tkamppeter: it would mean that users would implicitly share their printers even if they only enabled browsing and left sharing disabled in the UI
[04:29] <pitti> that's both wrong and, even worse, we don't even tell them
[04:29] <pitti> tkamppeter: since printers are shared by default, and only the "localhost only" default keeps them from being actually shared
[04:30] <pitti> tkamppeter: there was a recent bug about that, remember?
[04:30] <tkamppeter> pitti, No there is no BrowseAddress set and also the <Location /> allows only access from localhost. So no one can print on your local printers while you are listening to remote broadcasts.
[04:32] <pitti> tkamppeter: ah, so it additionally changes "Allow localhost" to "Allow @LOCAL" when you enable sharing
[04:33] <pitti> that's new in 1.3, too
[04:33] <pitti> man, upstream really deserves a good beating, they regress their architecture with every release
[04:34] <iwj> doko: I'm looking at bug 135515.  While investigating that, I discovered bug 151596.  There seem to be many of these dict-* packages.  Were they autogenerated somehow ?  There seem to be systematic problems.
[04:34] <ubotu> Launchpad bug 135515 in dict-af "autopkgtest gutsy dict-af: erroneous package!" [High,New]  https://launchpad.net/bugs/135515
[04:34] <ubotu> Launchpad bug 151596 in dict-af "executables in binary package, not rebuilt during build" [High,Confirmed]  https://launchpad.net/bugs/151596
[04:35] <pitti> tkamppeter: anyway, not your fault
[04:36] <pitti> tkamppeter: I'll commit the patch and get it uploaded
[04:37] <pitti> tkamppeter: is that a fix from upstream?
[04:43] <tkamppeter> pitti, no, but I loggen in already on the upstream tracker to report the bug and post the fix.
[04:43] <tkamppeter> kagou, are you here?
[04:43] <pitti> tkamppeter: ah, thanks
[04:44] <Hobbsee> oy, LaserJock.
[04:44] <nicolai__> hi
[04:44] <Hobbsee> LaserJock: i hope you're going to do your ritual post-release awards.
[04:45] <StevenK> Maybe I'll even get one this release
[04:45] <tkamppeter> pitti, Canonical should let you go to the next Printing Summit, so that you can talk with Mike Sweet directly ...
[04:45] <pitti> tkamppeter: uploaded
[04:47] <tkamppeter> pitti, thanks. Waiting for your upstream bug report about CUPS' security policy ...
[04:47] <pitti> tkamppeter: I'll file one about this particular bit
[04:47] <pitti> better to do it step by step
[04:48] <doko> iwj: ouch. how important is this for gutsy (given that we build arch-indep packages on i386)?
[04:48] <doko> not autogenerated, just packaged at the same time
[04:48] <iwj> Err, well, they're FTBFS due to missing build-depends too.
[04:48] <iwj> Seems to be a lot of identical stuff in them.
[04:48] <doko> iwj: which missing b-d?
[04:48] <iwj> libmyspell-dev
[04:49] <iwj> Now should be myspell-tools
[04:50] <iwj> At least that's what I assume.  It's not entirely clear to me yet but ifrench-gut just needed its B-D fixing up.
[04:50] <iwj> So I suppose the same is probably true for dict-af.
[04:50] <pitti> seb128: wow, the apport retracers actually seem to behave now
[04:51] <seb128> pitti: indeed, but we stopped apport notification so we less bugs now
[04:52] <pitti> seb128: heh, that could be it, too
[04:52] <seb128> get
[04:53] <pitti> BenC: poor kernel team, the gutsy bugs just don't let you go... :/
[04:54] <BenC> pitti: I meant to ask you, are all the right hooks for apport in upstream kernel now?
[04:54] <zul> pitti: no difference than other release ;)
[04:55] <pitti> BenC: last time I checked only in -mm
[04:55] <doko> iwj: ok, so the right fix seems to be a b-d on hunspell-tools
[04:55] <iwj> Not myspell-tools ?
[04:55] <pitti> BenC: I doubt that they made it to -22; you would have noticed, there should have been merge conflicts
[04:55] <iwj> And of course fixing the clean target.
[05:00] <doko> iwj: do you have a list of all these failures?
[05:02] <iwj> doko: https://edge.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=datecreated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=ian%2Bubuntu-autopkgtest&field.omit_dupes=&field.has_patch=&field.has_no_package=
[05:02] <iwj> (sorry)
[05:02] <iwj> And then search for dict, I suppose.
[05:02] <iwj> I'm happy to take care of it but I do need to be sure we know what we're doing first :-).
[05:03] <doko> iwj: I'm taking care of the dict-* packages
[05:03] <iwj> doko: You said hunspell-tools rather than myspell-tools.  Is there a significant difference ?
[05:03] <iwj> OK
[05:04] <doko> iwj: yes, hunspell is the newer myspell
[05:04] <iwj> doko: Since I have this fix to ifrench-gut too and if one of hunspell and ispell is being removed or something then I should make the right fix.
[05:04] <iwj> Ah.
[05:04] <iwj> So b-d on hunspell is better ?
[05:04] <iwj> Assuming it works.
[05:04] <ogra> iwj, meeting ?
[05:04] <Keybuk> fontconfig is stupid
[05:04] <iwj> ogra: 1600Z wasn't it ?
[05:04] <Keybuk> it has that silly /etc/fonts/conf.avail directory of config files
[05:05] <Keybuk> and then you make symlinks in /ets/fonts/conf.d to select which ones you want
[05:05] <ogra> iwj, well, its running :)
[05:05] <cjwatson> iwj: 1500Z
[05:05] <iwj> ogra: OK, thanks :-).
[05:05] <doko>   * build myspell-tools with myspells (un)much and the perl scripts
[05:05] <doko>     for people who either cannot use hunspells (un)munch or need either
[05:05] <doko>     /usr/bin/i2myspell or /usr/bin/is2my-spell.pl. ispellaff2myspell
[05:05] <doko>     is in both and remains here, too
[05:05] <Keybuk> a moronic scheme that seems to have started somewhere near apache, and infected other packages (including Debian's udev :p)
[05:05] <iwj> I can only get one timezone right in any 24h period.
[05:05] <Keybuk> except fontconfig goes one better, by *shipping* the symlinks in its own package
[05:05] <doko> iwj: ^^^ so if it can be built with hunspell, it should be built
[05:05] <Keybuk> so it actually prevents you from being able to disable the conffiles after all
[05:05] <Keybuk> d'oh
[05:06] <iwj> doko: OK, will look after the meeting.
[05:09] <lool> pitti, Hobbsee: (this is urgent) turns out 151351 is caused by the combination of xserver-xorg-video-intel not being reverted and kernel being reverted; kylem thought you didn't approve the kernel for RC and would have pushed xorg-intel later to go with the kernel in the archive
[05:09] <lool> pitti, Hobbsee: this means G33 support is currently broken in the RC CD; is there time to review xserver-xorg-video-intel with a patch disabeld and rebuild the CDN
[05:09] <lool> s/CDN/CD?
[05:09] <MrMazda> anyone know why kernels have CONFIG_FRAMEBUFFER_CONSOLE=m instead of =y?
[05:10] <BenC> pitti: I mean for 8.04
[05:10] <pitti> lool: hm, that was a misunderstanding then; we were asked to let it in
[05:10] <Hobbsee> lool: why did the kernel get reverted?  i dont reclal ever discussing the kernel for the RC.
[05:10] <pitti> BenC: let's hope so; I'll check it soon
[05:10] <BenC> wonder if it made it into 2.6.23
[05:10] <Hobbsee> excluding some stuff with lamont
[05:11] <seb128> bug #151351
[05:11] <ubotu> Launchpad bug 151351 in linux-source-2.6.22 "Corrupted screen on G33 with -14 kernel; regression from -13" [High,New]  https://launchpad.net/bugs/151351
[05:11] <lool> pitti, Hobbsee: I can't explain the misunderstanding, but my tests and the clarifications I just had with kyle made it clear that it's clearly broken right now
[05:11] <Hobbsee> lool: fair enough.
[05:12] <lool> I'm going to reboot to test the proposed fix
[05:15] <cjwatson> pitti: (#ubuntu-meeting) kubuntu oem is nothing to do with permissions, it's switching the order of dcopserver and kwin startup
[05:15] <pitti> ah, I see
[05:16] <cjwatson> pitti: I'm just trying to figure out why doing that also causes some visual corruption; I think I need to run kdesktop or some such too
[05:16] <pitti> so it seems I got it totally wrong then: the impact is not too bad, but the solution is non-trivial
[05:16] <Riddell> I don't know how oem-config does its background
[05:16] <Riddell> possibly it's doing something weird and not drawing a background, but I wouldn't think so
[05:16] <cjwatson> lool: rebuilding the CDs at this point involves delaying the RC
[05:17] <cjwatson> pitti: I don't think it's all that hard, just needs another half-hour or so of my time
[05:17] <cjwatson> should be about three lines in total
[05:17] <Kmos> cjwatson: I think one day of delay to have something better isn't a problem..
[05:17] <cjwatson> Kmos: http://wiki.ubuntu.com/TimeBasedReleases
[05:17] <Kmos> for me ofcours, as a Ubuntu user
[05:17] <cjwatson> then it's another day for something else
[05:17] <cjwatson> and another day for something else
[05:18] <pitti> not to mention breaking the schedule of stuff after it (final, UDS, etc.)
[05:18] <cjwatson> and then something breaks in the thing that you tried to fix and you need to spend another few days sorting that out
[05:18] <Kmos> cjwatson: yes.. but if there are really important things, else people will test the RC and report a lot of bugs that are already fixed.. but they can be updated after the release
[05:18] <Kmos> so isn't a problem
[05:18] <Hobbsee> cjwatson: and at this point, risks delaying the final.
[05:19] <Hobbsee> Kmos: dude, no.
[05:19] <Kmos> so i think it should be released in time
[05:19] <Hobbsee> Kmos: they should be reading the release notes, which highlights these bugs.
[05:19] <jojo4u> ... speaking of the RC, I am eagerly avaiting it. is there some news on it?
[05:19] <Kmos> Hobbsee: yeah, that too
[05:19] <cjwatson> jojo4u: it's not the end of the day yet
[05:19] <cjwatson> jojo4u: it will be announced on mailing lists when it is released
[05:20] <lool> Hobbsee, pitti: fix confirmed to be working
[05:20] <pitti> lool: \o/
[05:20] <jojo4u> which lists? ubuntu-devel-announce?
[05:20] <pitti> lool: so, please get it uploaded soon, so that it gets into the archive quickly after RC
[05:20] <pitti> lool: thank you
[05:20] <slangasek> lool: bug #116990: I'm certainly a bit nervous about side-effects from such a change, but I don't see how those can be avoided and still fix this bug; please upload ASAP so we have maximum opportunity to detect regressions before final
[05:20] <ubotu> Launchpad bug 116990 in rhythmbox "Rhythmbox sound problems (clicking/snapping/crackling) when not using crossfading backend" [High,In progress]  https://launchpad.net/bugs/116990
[05:20] <slangasek> pitti: also, care to give a second opinion on 116990?
[05:20] <lool> Could someone please sponsor http://people.ubuntu.com/~lool/packages/xserver-xorg-video-intel/2:2.1.1-0ubuntu7/sid/
[05:20] <pitti> slangasek: will do after meeting
[05:21] <Keybuk> mdke: https://wiki.ubuntu.com/Evms
[05:21] <cjwatson> jojo4u: yes
[05:21] <cjwatson> or ubuntu-announce, both are low-traffic
[05:21] <jojo4u> ok, thank you very much *subscribing*
[05:21] <lool> pitti, Hobbsee: so any change to get this in for RC?
[05:22] <lool> Ah it was uploaded by Kyle already
[05:22] <pitti> lool: no, post-RC
[05:22] <pitti> lool: it would delay the release by at least a day or so
[05:22] <lool> Ok
[05:25] <Keybuk> wow, dapper had wobbly windows!
[05:26] <ogra> yeah, that was an early version :)
[05:26] <ogra> the screensaver used it too
[05:26] <ogra> (even without removong packages :) )
[05:29] <highvoltage> Anyone know whether Gobuntu will also be released on the 18th? There's been questions about it on the gobuntu-devel mailint list, but no answers yet.
[05:31] <cjwatson> highvoltage: the answer is yes
[05:31] <highvoltage> cjwatson: great, thanks.
[05:31] <cjwatson> evand: ^-- could you open the lines of communication with gobuntu-devel a bit? :)
[05:32] <pitti> evand: btw, did anyone test http://cdimage.ubuntu.com/gobuntu/daily/20071010/ ?
[05:32] <pitti> IOW, should we include it into the announcement?
[05:32] <evand> cjwatson: will do
[05:32] <lool> slangasek: seb128 is sponsoring the rhythmbox upload
[05:32] <seb128> lool: already uploaded and listed on #ubuntu-release ;)
[05:33] <lool> Ah, I'm not on -release
[05:34] <lool> (I am now)
[05:34] <evand> pitti: I tested it, yes
[05:35] <evand> pitti: I think it would be appropriate to include in the announcement, but do I have time for testing i386 as well (I just tested amd64)?
[05:36] <cjwatson> evand: start now :)
[05:37] <pitti> evand: please; I doubt that the various partitioning schemes etc. differ, but at least one default test should be made
[05:39] <evand> ok, pulling down the image no
[05:39] <evand> w
[05:42] <pitti> slangasek, evand: can you two please coordinate the inclusion of Gobuntu into the announcement?
[05:42] <evand> sure
[05:43] <AlinuxOS> pitti, hello, where can I download RC for testing ?
[05:43] <pitti> AlinuxOS: see topic
[05:43] <AlinuxOS> pitti, :D
[05:43] <AlinuxOS> ah thanks.
[05:43] <pitti> AlinuxOS: it links to instructions and the images
[05:44] <slangasek> evand: draft is https://wiki.ubuntu.com/GutsyGibbon/RCAnnouncement, fyi
[05:45] <evand> do you mind if I edit that straight, or would you prefer I pastebin the changes for gobuntu?
[05:46] <slangasek> straight editing is fine, I assume that I won't need to revert /all/ your changes ;)
[05:47] <evand> heh
[05:47] <Hobbsee> nixternal: did you write teh kubuntu section of that?
[05:47] <Hobbsee> someone has, and they dont know KDE - or they've only read what the marketing is.
[05:48] <slangasek> evand: off the top of my head, I guess we should have a highlights section for Gobuntu saying "this is the first release of Gobuntu, $short_description_here"?
[05:48] <Hobbsee> besides, strigi is off by default now.
[05:48] <Riddell> strigi is still installed by default
[05:48] <slangasek> Hobbsee: it's inherited from the info from past milestones
[05:49] <Riddell> Hobbsee: it reads fine to me
[05:49] <evand> slangasek: indeed, I was thinking something along the lines of "this is the first release of Gobuntu, a version of Ubuntu that follows the 7(?) freedoms outlined by the FSF."
[05:49] <Hobbsee> Riddell: one would assume that people would look to find strigi running, not whether it's installed or not
[05:49] <evand> actually, there might be some text on w.c.c to steal, I'll check in a moment
[05:49] <Hobbsee> slangasek: that doesnt mean it doesnt suck :P
[05:49] <Riddell> Hobbsee: one might look for it in the menus :)
[05:49] <pitti> lool: please manually close the -intel bug, there is no LP: #1234 in the changelog
[05:49] <Hobbsee> Riddell: pillars of KDE sounds like KDE4 marketing - with no particular mention of what it is, or hwo to use it.
[05:49] <Hobbsee> Riddell: one might.  if one uses menus.
[05:50] <lool> pitti: Ok
[05:50] <Riddell> it's konqueror's default search item too
[05:50] <pitti> lool: thanks
[05:50] <Riddell> those are only summaries, more information is in the link below
[05:51] <lool> pitti: It's already "fix released"
[05:51] <ogra> yay
[05:51] <slangasek> Hobbsee: I think my point might be that if things that were treated as key talking points in earlier milestones go away, someone needs to speak up (as you're doing now) :)
[05:51] <ogra> finally one install i got through without anyy HW dying
[05:51] <slangasek> evand: hmm, hopefully something without a question mark in the middle? :)
[05:51] <Hobbsee> slangasek: :)
[05:52] <evand> haha, we'll see
[05:52] <cjwatson> evand: classically, there are four freedoms outlined by the FSF
[05:52] <evand> cjwatson: thanks
[05:55] <LaserJock> Hobbsee: indeed I shall ;-)
[05:56] <Hobbsee> LaserJock: :D
[06:00] <ogra> seb128, did you hear about any scrollkeeper-update eats 100% CPU bugs ? seems LaserJock got hit by it with a fresh gutsy install
[06:01] <seb128> ogra: no, or nothing new recently, scrollkeeper crash or behave badly every now and then, we get a few bugs every cycle, that's random
[06:02] <LaserJock> so it's just my luck?
[06:02] <seb128> ogra: we started switching to rarian and we will probably demote scrollkeeper to universe next cycle
[06:02] <seb128> LaserJock: probably yes
[06:02] <seb128> LaserJock: for how long is it using CPU?
[06:02] <seb128> scrollkeeper-update is not the faster command in the world, it can take some time
[06:02] <LaserJock> until I kill it
[06:02] <seb128> ok, so no luck for you ;)
[06:02] <slangasek> ogra: are we a go for RC on Edubuntu?
[06:03] <slangasek> Riddell: ^^ ditto Kubuntu?
[06:03] <LaserJock> it was starting up multiple copies too
[06:03] <ogra> slangasek, looks good to me ...
[06:03] <Riddell> slangasek: I'm happy
[06:03] <ogra> addon i386 could need a test and amd64 dvd is missing ...
[06:03] <LaserJock> seb128: and I don't know if it's your area but my panel doesn't show up until I click the desktop
[06:03] <ogra> but since the amd64 variant of the addon was tested good i'm not sorried here
[06:03] <LaserJock> seb128: ogra said that it was an nvidia thing maybe, but I've got ATI
[06:04] <ogra> *worried
[06:04] <LaserJock> ogra: I did i386 addon
[06:04] <ogra> ah
[06:04] <ogra> cool
[06:04] <seb128> LaserJock: that's a compiz thing
[06:04] <LaserJock> k
[06:04] <ogra> slangasek, i'm fine then ...
[06:04] <seb128> LaserJock: should be fixed with the new compiz which is not on the CD but has been accepted
[06:04] <slangasek> ogra, Riddell: sweet, thanks
[06:04] <LaserJock> compiz was a disaster for me anyway
[06:04] <LaserJock> so I had to get rid of it
[06:05] <LaserJock> it kept shadding Firefox everytime it loaded a new page
[06:05] <LaserJock> shading
[06:05] <ogra> weird
[06:06] <LaserJock> it's like it put Firefox in the background while it was loading the page
[06:06] <cjwatson> ogra: amd64 dvd missing as in untested?
[06:06] <cjwatson> it seems to be present, at least
[06:06] <LaserJock> and then when it was done it'd bring it forward
[06:07] <ogra> cjwatson, as in unteasted, yes
[06:07] <ogra> gah
[06:07] <ogra> untested
[06:07] <pitti> untoasted?
[06:07] <doko> cjwatson: I just ran the live session, testing the installer after the meeting
[06:07] <cjwatson> doko: which, edubuntu amd64 dvd?
[06:07] <ogra> cjwatson, but i'm fine for RC with it ... i know the CDs are fine
[06:07] <doko> yes
[06:08] <cjwatson> ok, cool
[06:08] <mertiki> Hi everyone, I worked on a bug in libqt3-mt and found the problem, and uploaded a debdiff to fix this into launchpad. This would be important that this bug is fixed before Gutsy hit stable, does someone can look at this?
[06:08] <mertiki> 145709
[06:08] <ogra> oh, wow
[06:08] <ogra> doko, you rock
[06:12] <mertiki> doko : I sended you a mail about this, you were one of the last person who worked on that package
[06:13] <doko> mertiki: Riddell is your man
[06:13] <mertiki> doko : thanks, is Riddell here sometime?
[06:14] <slangasek> evand: how goes the edit?
[06:14] <jojo4u> mertiki: he is loggin in
[06:14] <ubudev> who can tell me how to send my program using launchpad???
[06:14] <mertiki> jojo4v : thanks :)
[06:16] <evand> slangasek: slowly, I'm trying to type an announcement to gobuntu-devel and test the i386 image at the same time. I'll focus on this though.
[06:16] <Hobbsee> ubudev: you probably want #launchpad
[06:17] <Kmos> kmos@bash:~$ totem
[06:17] <Kmos> Error: Failed to send command: 500 command not parseable
[06:17] <cjwatson> ubudev: https://help.launchpad.net/ has documentation
[06:17] <slangasek> evand: ok, thanks
[06:17] <Kmos> when I click on more inforation about plugins
[06:17] <ubudev> thanks
[06:17] <Kmos> i got that error
[06:17] <Hobbsee> Kmos: and this is not a support channel, as you well know.
[06:18] <Hobbsee> has anyone else filed a bug about it, or is it a local problem?
[06:18] <Kmos> Hobbsee: i'll check
[06:18] <mertiki> Riddell : When you'll be there, can you take a look at bug #145709 ( there's 2 debdiff, make sure you take the good one )
[06:18] <ubotu> Launchpad bug 145709 in qt-x11-free "7.10: Qt3 ~/.qt owner root and missing qtrc result result in ugly appearance" [Undecided,In progress]  https://launchpad.net/bugs/145709
[06:18] <Kmos> and report it if there isn't any report yet
[06:24] <iwj> cjwatson: So I'm looking at this package and AFAICT it's completely barking.  There are these random decimal numbers in usplash-theme-ubuntu.c for the text colour.  Do they correspond to anything anywhere ?  They don't appear to be indices into the pixel tables in (say) usplash_1024_768.png.c.
[06:24] <mekius> bryce: btw, I got the autodetection working for the X video driver.  I had added the entries in the discover data files, but apparently I updated the files for version 2 of discover and only version 1 of the library was installed.  I installed version 2 and it uninstalled version 1, but I then reinstalled version 1 without any conflict, very strange.
[06:25] <mekius> iwj: they should be grabbing colors from the background image
[06:25] <mjg59> iwj: The images should be palletised
[06:25] <iwj> mjg59: Yes.
[06:25] <mjg59> My recollection is that the colours should just be palette entries
[06:25] <iwj> I mean, the numbers in usplash-theme-ubuntu.c don't seem to be indices into eg usplash_1024_768_palette.
[06:25] <mjg59> How odd.
[06:26] <mjg59> The theming stuff was all done by someone other than me, so I'm afraid I can't help there...
[06:26] <iwj> Everyone agrees that it comes up as darkish blue, right ?  The usplash text box for (eg) you should remove the CD now or please type in your boot passphrase.
[06:26] <cjwatson> it's been a while since I looked at it
[06:26] <cjwatson> I see it as darkish blue in vmware, yes
[06:27] <mjg59> Yes
[06:28] <iwj> I'm looking at  .text_{background,foreground,success,failure}   which are all various shades between orange and green.
[06:28] <iwj> Err, except background which is black.
[06:28] <iwj> If you look them up in what is allegedly the palette, that is.
[06:29] <pitti> iwj: darkish blue> yes, for CD checksum tests, passphrase input, and "take out CD"
[06:29] <mantiena-baltix> glatzor, hi
[06:29] <mantiena-baltix> mjg59, hi
[06:30] <mjg59> mantiena-baltix: Hi
[06:30] <glatzor> evening mantiena-baltix
[06:31] <iwj> svgalib/gl/grlib.c contains a gl_setpixel and a gl_setpixelrgb of which latter uses gl_rgbcolor which does some bitfield munging depending on the depth.  But that doesn't seem to be what's going on either.
[06:31] <cjwatson> that's what's called ...
[06:31] <mantiena-baltix> glatzor, ready to talk about displayconfig-gtk crashes ? ;)
[06:31] <cjwatson> usplash_text does gl_setpixel
[06:31] <iwj> cjwatson: Right.  gl_setpixelrgb is just gl_rgbcolor followed by gl_setpixel on the result.
[06:32] <cjwatson> what calls usplash_set_palette?
[06:32] <iwj> Which suggests that the pixel value is a set of bitfields.
[06:32] <mantiena-baltix> mjg59, why your virtual-screen patch still not included into official Ubuntu packages?
[06:32] <mjg59> Is it also blue if using framebuffer?
[06:32] <mjg59> mantiena-baltix: It's uploaded, but we're frozen right now
[06:32] <iwj> cjwatson: usplash_setup
[06:32] <sladen> iwj: (I specifically refused to touch usplash until a month ago, and I'm regretting it already).  The "decimal numbers" are palette entries to reuse for other things.  the RGB triplets are fetched from the image file
[06:33] <cjwatson> (usplash desperately needs an active maintainer)
[06:33] <iwj> sladen: But they're not, or at least not in the obvious way.
[06:33] <mantiena-baltix> mjg59, oh, so, we should wait until release candidate will be released ?
[06:34] <mjg59> Yes
[06:34] <iwj> sladen: Something is dark blue and the relevant entries aren't even nearly dark blue.
[06:34] <glatzor> mantiena-baltix: could you point me to the corresponding bug reports? we could also switch to the #ubuntu-desktop channel since it is more calm
[06:34] <pitti> hm, how does one test this thing? I tried "sleep 5; sudo usplash_write TEXT_URGENT hello" on VT1 and "sudo usplash" on VT2"
[06:34] <pitti> sladen: ^ any idea?
[06:35] <pitti> erk, s/_/-/ might help
[06:35] <cjwatson> no, it's usplash_write
[06:35] <iwj> Of course it could be that gl_setpixelrgb just doesn't work.  Nothing seems to call it.
[06:36] <mjg59> iwj: Does the same issue occur if using a framebuffer?
[06:36] <iwj> mjg59: I have no idea.
[06:36] <pitti> no, that didn't help
[06:36] <cjwatson> pitti: usplash_write's argument parsing is crackful, IIRC
[06:36] <cjwatson> pitti: try usplash_write 'TEXT-URGENT hello'
[06:36] <pitti> cjwatson: I meant, it's TEXT-URGENT, not TEXT_URGENT
[06:36] <cjwatson> oh, and yes it is TEXT-URGENT rather than TEXT_URGENT, I misunderstood you
[06:37] <sladen> pitti: sudo usplash -c & sleep 1 ; sudo usplash_write PULSATE
[06:37] <pitti> cjwatson: yes, that helped
[06:37] <pitti> thank you
[06:38] <pitti> so, except that my usplash screen is now distorted since I reinstalled gutsy two hours ago, and I cannot read the font at all, it works
[06:39] <Riddell> mertiki: how does adding /etc to qt's packaging help it?
[06:39] <sladen> pitti: "distorted?"
[06:40] <Riddell>  /etc should already exist long before qt is installed anywhere
[06:40] <pitti> slangasek: looks like pixels get shifted within an 8x8 block or so
[06:40] <sladen> cjwatson: it is one of the most embarassying bits of code mjg59 has ever written, yes.
[06:40] <iwj> mjg59: Can I tell it to use a framebuffer on the boot command line ?
[06:41] <mjg59> iwj: vga=791 should work
[06:41] <mjg59> But people have been complaining it doesn't
[06:43] <sladen> mjg59: is there a way to /not/ get usplash to use the theme and instead to use the testcard?
[06:44] <nixternal> Hobbsee: https://wiki.kubuntu.org/GutsyGibbon/RC/Kubuntu
[06:44] <mjg59> sladen: No
[06:44] <Whoopie> mjg59: didn't follow the whole discussion, but on my laptop, usplash verbose output is blue if I don't use framebuffer, but it's orange with framebuffer.
[06:45] <cjwatson> wouldn't building the initramfs without the theme do it?
[06:45] <cjwatson> Whoopie: oh dear, that suggests that the svga and bogl drivers behave differently
[06:45] <cjwatson> Again
[06:45] <Hobbsee> nixternal: looks nice - you may want to touch up the mailout, though
[06:46] <sladen> there are two sets of images that can be used, to two sets of backends
[06:46] <Whoopie> cjwatson: do we still use bogl? I thought everything is done with svga now.
[06:47] <cjwatson> Whoopie: framebuffer => bogl
[06:47] <cjwatson> or maybe it's the other way round
[06:47] <iwj> Bah!  Foiled by the broken mirror _again_.
[06:47] <nixternal> Hobbsee: roger that
[06:47] <mjg59> Whoopie: Ok, that sounds like it's an svgalib issue
[06:47] <mjg59> Whoopie: No, framebuffers are all bogl
[06:48] <cjwatson>         fd = open("/dev/fb0", O_RDWR);
[06:48] <cjwatson>         if (fd < 0) {
[06:48] <cjwatson>                 usplash_operations = &usplash_svga_funcs;
[06:48] <cjwatson>                 return;
[06:48] <cjwatson>         }
[06:48] <cjwatson> so yeah, svga only used if framebuffer not present
[06:48] <cjwatson> iwj: still want the i386 DVD? it'll be finished burning here in about 10 minutes
[06:48] <sladen> but the livecd always loads a vga16fb ?
[06:49] <sladen> (or in theory, always does?)
[06:49] <pitti> mdz, evand, cjwatson: should gobuntu go on releases.u.c.?
[06:49] <pitti> slangasek: CC: ^
[06:49] <cjwatson> pitti: I think it's a matter of whether the mirrors have space for it at this point
[06:50] <iwj> cjwatson: Bring it to the pub.
[06:50] <cjwatson> pitti: somebody should ask IS whether they can accommodate the size increase with/without it
[06:50] <pitti> cjwatson: assuming they have, isn't it a question of official support?
[06:50] <iwj> I'll have to run your amd64 one across tomorrow.
[06:50] <cjwatson> iwj: not sure yet whether I'll be there tonight
[06:50] <sladen> it would be politically ideal if gobuntu /did/
[06:50] <cjwatson> but I can at least stop down with the DVD, I guess
[06:50] <pitti> right
[06:50] <iwj> cjwatson: No, I can come round tomorrow to exchange.
[06:51] <cjwatson> pitti: I think it would be correct for Gobuntu to go on releases.u.c, if there's room
[06:51] <mjg59> sladen: No
[06:51] <mjg59> sladen: Alternative loads a vga16fb
[06:51] <mjg59> But only just before starting the installer
[06:51] <cjwatson> (and doesn't use usplash at that point anyway)
[06:52] <sladen> mjg59: ...does that mean that there isn't a fb on the livecd then, and the svgalib gets used?
[06:52] <mjg59> Yes
[06:52] <mjg59> That's why it's in more than 16 colours
[06:53] <sladen> mjg59: what what is /normally/ getting used on the install, vesafb or svgalib aswell?
[06:53] <mjg59> sladen: svgalib
[06:53] <mdz> pitti: no, not worth the risk
[06:53] <sladen> mjg59: ls -l /dev/fb* || echo svgalib  ... hmmm
[06:53] <cjwatson> mdz: which risk?
[06:53] <mdz> pitti: there is not enough of a need for mirroring to justify risking filling up mirrors
[06:53] <cjwatson> ah
[06:53] <cjwatson> we can still link it clearly from releases.u.c
[06:54] <cjwatson> as we do with xubuntu
[06:54] <pitti> mdz: ok, I see
[06:54] <cjwatson> mdz: btw, what do you think about punting edgy to old-releases.u.c, even though it's still supported?
[06:54] <cjwatson> I think that would help
[06:55] <sladen> mdz: in that case, spin it "to preserve the true freedom of gobuntu", we request mirrors to mirror gobuntu separately so they can be fully aware of the difference, and perhaps even choose their own even-freeier-hosting for Gobuntu"
[06:55] <mdz> cjwatson: no objections at all
[06:55] <mdz> cjwatson: I don't think the URL makes a big statement about whether something is supported or official
[06:55] <mdz> cdimage.ubuntu.com is just as official as releases.ubuntu.com
[06:56] <mdz> hell, that's where the official release DVDs live
[06:56] <mdz> for exactly the same reason (mirror space)
[06:56] <cjwatson> I should probably start on that now then
[06:58] <doko> iwj: all dict-* packages fixed; had a look at the packages which fail in gcj. How much memory does your autobuilder have?
[06:59] <iwj> doko: 1Gby
[06:59] <iwj> doko: dict-*>  Thanks a lot.
[07:00] <doko> iwj: could you recheck with 2GB? I know that gcj is a memory hog on amd64
[07:00] <iwj> doko: Blimey.
[07:00] <iwj> doko: I'll see what I can do.
[07:01] <doko> iwj: just one package (ant for example)
[07:02] <iwj> doko: Right, I'll get back to you.
[07:06] <doko> iwj: looking at the other dictionaries now (if you didn't start yet)
[07:06] <iwj> I'm on ifrench-gut.
[07:06] <evand> pitti: gobuntu i386 works, though for some reason usplash didn't start
[07:06] <iwj> Are there others that are broken ?
[07:08] <pitti> evand: hm, not start at all? or time out due to vmware slowness?
[07:08] <evand> maybe vmware slowness
[07:09] <sladen> evand: if you can start it without quiet, do any messages popup before usplash bombs out?
[07:10] <doko> iwj: myspell-lv myspell-sl ispell-czech
[07:10] <pitti> iwj, cjwatson: ok, I got the cryptsetup initramfs hook to just make the password prompt disappear when it was successful; that avoids even more untranslatable text, etc, and IMHO is a good enough feedback; WDYT?
[07:11] <pitti> iwj, cjwatson: the alternative is a single [OK]  on the screen (the input text and response disappears in any case; we cannot write it below the prompt)
[07:11] <iwj> pitti: Oh, absolutely.
[07:11] <iwj> Having it disappear is just fine.
[07:11] <pitti> but i'd prefer a clean screen again
[07:11] <pitti> iwj: ok, thanks; doing that then
[07:11] <iwj> Excellent.
[07:12] <iwj> doko: Ah.  Err, OK, well, I'll finish ifrench-gut and leave those to you then, unless you'd prefer me to take them on ?
[07:12] <pitti> "Enter password for sda5_crypt" is intimidating enough with out the trailing "(/dev/disk/by-uuid/yayayada1234)"
[07:12] <iwj> pitti: Oh, it might have some security value.
[07:12] <iwj> Err, I think.
[07:12] <doko> iwj: I will do these, most likely just requesting syncs
[07:12] <iwj> I agree it's a bit horrid but let's not make unnecessary changes at this stage.
[07:13] <evand> sladen: it moves way too quickly for me to read.  Is this logged somewhere specific?  syslog?
[07:13] <pitti> iwj: well, I'd keep the sda5_crypt, but the UUID?
[07:14] <pitti> iwj: assuming that the machine doesn't even get that far if the UUID is wrong (I'll check that), it is a little too much IMHO
[07:14] <iwj> pitti: That might have some value in stopping you being tricked somehow.  Err.  I haven't thought clearly about this
[07:14] <iwj> I'm trying to avoid having to think clearly about it IYSWIM :-).
[07:15] <iwj> Hmm.
[07:15] <iwj> If you recognise the UUID then you can avoid typing the passphrase into things which don't know it.  But all such things are either (a) the right place to type it or (b) some different hardware which you ought to notice or (c) trojanned code on your hardware somehow which can read the uuid anyway.
[07:16] <iwj> So I think it's fine to remove it.
[07:17] <slangasek> Riddell: wrt your latest change to the RCAnnouncement, this is wording that's been present in multiple previous announcements and signed off (at least implicitly) by a number of people; could you please not make changes of that sort without discussion?
[07:17] <iwj> pitti: Would you please reject my ifrench-gut upload ?  It's the wrong one.
[07:18] <pitti> iwj: so, it reads the value from the initramfs configuration file
[07:18] <iwj> Yes, but you can find the value on the hard disk too.
[07:18] <pitti> iwj: so, if someone can modify your initramfs, then it doesn't matter any more
[07:18] <iwj> Right.
[07:18] <Riddell> slangasek: ok, but I've noticed people being confused by it
[07:18] <iwj> Well, I was thinking a malicious USB stick.
[07:18] <pitti> iwj: and if someone modifies the UUID, the device won't be found (since it's hardcoded in initramfs) and the thing just blows
[07:18] <iwj> But if you don't notice the stick you've lost anyway since the stick can find the uuid out of your hard disk or initramfs
[07:19] <pitti> iwj: but wouldn't that scenario be "untrusted stick, trusted initramfs"?
[07:19] <slangasek> Riddell: then I think discussion is definitely in order, I just don't want to go around changing wording after it's already passed by ubuntu-doc in its previous form :)
[07:19] <iwj> pitti: If the BIOS boots from the stick then you lose.
[07:19] <slangasek> Riddell: in this case, could you shoot a quick note to ubuntu-doc && mdz about the change?
[07:19] <pitti> iwj: ifrench-gut> rejected
[07:20] <iwj> The question is just does the uuid in the prompt help, and it doesn't in this case.
[07:20] <iwj> pitti: Thanks.  ubuntu2 is on its way.
[07:20] <mdz> slangasek: happy to ack it quickly here
[07:20] <mdz> I'll have a look
[07:20] <pitti> iwj: right, that's what I mean
[07:20] <iwj> pitti: Then we are in agreement.
[07:20] <pitti> since it reads that very information from the thing (initramfs) you have to trust anyway
[07:20] <pitti> iwj: splendid; I'll remove it then for eye-friendlyness
[07:23] <mdz> slangasek: I think 'and' is more correct than 'or', but I agree with s/our/a/
[07:24] <slangasek> ok, thanks
[07:24] <mdz> slangasek: now that I read it, and since you're there, "distinction" would be better than "separation"
[07:25] <iwj> cjwatson: Did you want me to suggest a wording for the partman-crypto passphrase setup page ?
[07:25] <slangasek> mdz: ack, changed
[07:25] <tkamppeter> I tried out displayconfig-gtk on my laptop with Intel i915 because before I never could get the display content onto a projector on the external VGA port.
[07:26] <cjwatson> iwj: I hadn't got that far yet, was going to look tomorrow
[07:27] <iwj> cjwatson: OK, well, let me know if you do.
[07:27] <tkamppeter> But after configuring a 1024x768 flat panel as the second screen, mirroring the first screen I got only a demo of Bulletproof X. Then reconfiguring from the tool started under the VESA fallback I got back to normal but with the external monitor not configured.
[07:27] <doko> pitti: subscribed you to bug 137260
[07:27] <ubotu> Launchpad bug 137260 in language-support-he "autopkgtest gutsy language-support-he amd64: erroneous package!" [High,New]  https://launchpad.net/bugs/137260
[07:28] <cjwatson> iwj: thanks, will do. I was planning to scratch my head and see if there was a way to preserve at least some of the existing translations.
[07:28] <pitti> doko: thanks
[07:29] <iwj> cjwatson: Mmm.
[07:29] <iwj> cjwatson: I think that translation damage is just a consequence of adding features like this to the base set at a late stage.
[07:29] <cjwatson> iwj: po-debconf translates paragraph by paragraph, so that property would be satisfied by making sure new text is added as a new paragraph
[07:30] <cjwatson> if that turns out to be possible
[07:30] <cjwatson> yes, but I think if we're concerning ourselves with making text more comprehensible then we should try to preserve what translations we can as part of that, otherwise it may be self-defeating
[07:31] <iwj> cjwatson: paragraphs> Ah, yes, that makes sense.
[07:35] <doko> iwj: bug 150052, looks like util-linux is not installed (getopt), but util-linux is priority required
[07:35] <ubotu> Launchpad bug 150052 in mbr "autopkgtest gutsy mbr: erroneous package!" [High,New]  https://launchpad.net/bugs/150052
[07:38] <glatzor> bryce: urgent ping
[07:39] <cjwatson> doko: mbr build-deps linux32 which util-linux conflicts/replaces/provides; I wonder if that's causing a problem?
[07:40] <cjwatson> (but surely the provides ought to be sufficient)
[07:42] <doko> Investigating util-linux
[07:42] <doko> Package util-linux has broken dep on linux32
[07:42] <doko>   Considering linux32 9998 as a solution to util-linux 5108
[07:42] <doko>     Reinst Failed because of protected linux32
[07:42] <doko>   Removing util-linux rather than change linux32
[07:42] <doko> cjwatson: ^^^, ok leaving this to iwj, seems to be a problem with the test builder
[07:43] <Mithrandir> "removing util-linux" doesn't really look like a great idea.
[07:43] <mjg59> glatzor: What's up?
[07:44] <glatzor> mjg59: I fixed three major bugs in displayconfig-gtk
[07:44] <glatzor> mjg59: And I need somebody to upload
[07:44] <glatzor> and confirm
[07:44] <Whoopie> mjg59: albert23 from #ubuntu-motu tested my usplash patch for uswsusp. two things: 1) his /etc/uswsusp.conf had the UUID for resume device (mine had /dev/sdaX), 2) it also hangs for him at 100% progress bar on resume.
[07:45] <Whoopie> mjg59: do you have time to look into it?
[07:46] <mjg59> Whoopie: Nope
[07:46] <mjg59> glatzor: Diff?
[07:46] <glatzor> mjg59: would you like to upload?
[07:46] <Mithrandir> Whoopie: hanging on 100% is known, alt-sysrq-k fixes it.
[07:46] <Mithrandir> "fixes"
[07:46] <doko> iwj: the auto builder doesn't run debian/rules clean before starting the build. is this intended?
[07:46] <Mithrandir> works around it at least.
[07:46] <glatzor> mjg59: I committed the changes to the official branch of displayconfig
[07:46] <Whoopie> Mithrandir: known for usplash?
[07:46] <mjg59> glatzor: Which is where?
[07:47] <glatzor> mjg59: https://code.edge.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu
[07:48] <Mithrandir> Whoopie: uswsusp+usplash, yes.
[07:49] <glatzor> mjg59: quite awkward bugs :/ why is there no stealth mode for changelogs :)
[07:49] <iwj> doko: Yes.
[07:49] <mjg59> glatzor: Ok. It's not getting in before rc, so you should speak to the release team
[07:49] <iwj> doko: That is, it's intended and IMO correct.
[07:49] <iwj> doko: I understand why pbuilder does it but it's not supposed to be needed.
[07:50] <doko> iwj: ok, fixing scim-pinyin
[07:50] <iwj> doko: Oh, thanks.
[07:50] <glatzor> mjg59: sorry, but I am not familiar with post-rc uploads, could you name me a person to contact?
[07:50] <Whoopie> Mithrandir: nice, worked indeed.
[07:50] <mjg59> glatzor: slangasek is probably sensible at this time of day
[07:51] <Whoopie> Mithrandir: do you know the reason for the hang? anybody tried to debug?
[07:52] <Mithrandir> Whoopie: I've talked on and off with the kernel team about it for eight months or so
[07:52] <Whoopie> Mithrandir: so it just happens on some laptops or PCs?
[07:54] <Mithrandir> Whoopie: I only use uswsusp on my laptop
[07:54] <slangasek> mjg59: why should I be any more sensible this time of day than at others?
[07:55] <mjg59> slangasek: You're unlikely to have started drinking at this stage
[07:56] <slangasek> hmm, unfortunate but true
[07:56] <doko> iwj: your list shows duplicates as well
[07:57] <iwj> doko: Yes.
[07:58] <iwj> doko: autopkgtest bugs are sometimes dupes of other bugs but if you eliminate dupes they don't show up at all.
[07:58] <doko> iwj: ok, even those whith fixed reports =)
[07:58] <iwj> That's a bug in LP.
[07:58] <iwj> Bug 147754
[07:58] <ubotu> Launchpad bug 147754 in malone "searching including duplicates uses wrong status" [Undecided,New]  https://launchpad.net/bugs/147754
[07:58] <iwj> (I can't believe it's still Undecided FFS)
[07:59] <iwj> doko: The only way to fix it is to unduplicate the autopkgtest report, manually set the status, and reduplicate it.
[07:59] <iwj> bdmurray: AYT?
[07:59] <iwj> bdmurray: Any progress on your LP DB access ?
[08:02] <Whoopie> Mithrandir: is there a bug report for this issue?
[08:02] <Mithrandir> Whoopie: unsure.  I think I filed one, but it's ages ago
[08:08] <doko> iwj: Dependency is not satisfiable: c++abi2-dev  -> dependency on a virtual package; do you want to have this fixed for gutsy?
[08:11] <slangasek> evand: "for a certain user type" - what type is that? :)
[08:12] <slangasek> evand: perhaps this can be written as: "For experienced Linux enthusiasts, Gobuntu will act as the test bed for developing a user-friendly operating system with no compromise in terms of the open source philosophy."?
[08:13] <evand> wfm
[08:13] <pitti> tkamppeter: did you see Mike's response to http://www.cups.org/str.php?L2557 ?
[08:13] <ubotu> CUPS bug 2557 in Core CUPS Software "CUPS daemon is not set to listen on port 631 in the whole network when user wants CUPS to show printers" [Priority moderate,Closed w/o resolution] 
[08:13] <pitti> tkamppeter: I think I'll reject the cupsys upload for now
[08:13] <iwj> doko: No, I think we should punt on those.
[08:14] <iwj> doko: There's also automaken and err at least one other.
[08:14] <iwj> doko: I don't want to just update all of the packages to say `automake1.9' or whatever because that's making a rod for our own back.
[08:14] <doko> ok
[08:14] <slangasek> evand: just to make sure I understand this the right way around: does gobuntu include artwork for usplash?
[08:14] <iwj> doko: We really want a coherent way of centrally determining the correct thing to use.
[08:16] <doko> iwj: ok, setting these to confirmed.
[08:16] <evand> slangasek: yes, but it's currently not working on i386
[08:16] <evand> it worked last I checked (last night) on amd64
[08:16] <iwj> doko: Thanks.
[08:16] <iwj> doko: Thanks for your help btw :-).
[08:16] <evand> the usplash artwork, that is
[08:17] <slangasek> evand: ok; just wanted to make sure that the "and" in that sentence wasn't meant as an "or"
[08:17] <Amaranth> does gobuntu have the patched kernel and such that gnusense has?
[08:17] <doko> iwj: heh, just while doing test installs ...
[08:19] <evand> Amaranth: it's just ubuntu - restricted at the moment
[08:19] <Amaranth> ah
[08:19] <iwj> doko: Lucky you.  Whenever I do test installs I spend the whole day writing bug reports :-).
[08:19] <evand> but the goal is to get the restricted bits of the kernel into restricted
[08:19] <evand> much has already been done there, iirc
[08:19] <Amaranth> i know ompaul told me gnusense had a bunch of files patches out of the kernel because they were basically closed firmware pretending to be code
[08:19] <Amaranth> patched*
[08:19] <iwj> Not that I _mind_ writing bug reports but it doesn't leave much time for thinking about coding too.
[08:20] <evand> Amaranth: I do recall that as well, but I *believe* there may have been some false positives there as well.
[08:20] <doko> well, it's just two dvds I'm currently testing
[08:22] <pitti> lool: re bug 116990: wouldn't it be safer to reduce the default volume to 90% to avoid the clipping?
[08:22] <ubotu> Launchpad bug 116990 in rhythmbox "Rhythmbox sound problems (clicking/snapping/crackling) when not using crossfading backend" [High,In progress]  https://launchpad.net/bugs/116990
[08:23] <pitti> lool: that helps on my machine, the machine of a friend of mine, etc.
[08:25] <sladen> who the hello made these themes, the progress bar overlaps the text area, so gets scrolled up
[08:27] <evand> which themes?
[08:34] <doko> asac: how do I fix this "unknown network interface "eth0=eth0" thing?
[08:38] <sladen> okay, nailed the edubuntu off-centered ness
[08:38] <sladen> did somebody say it's still there on xubuntu?
[08:42] <geser> pitti: is the list of packages which aren't build on a architecture available somewhere?
[08:45] <cjwatson> Amaranth: Gobuntu shares the same archive, so it's unlikely to be practical to make that kind of invasive kernel change; packages that need bits removed for them for Gobuntu need to be split up
[08:45] <cjwatson> Amaranth: (which should hopefully mean there's a little more quality control on what gets removed, since it's more effort)
[08:49] <sladen> ubuntu has overlapping text box too?
[08:52] <lool> pitti: Yes, some submitter confirmed that reducing the sound level work, on the other hand you don't want people to get crackling sound when they pump up the volume :)
[08:53] <lool> pitti: Also, all workarounds so far only hide the real problem which seems to be alsa related (we should build an alsa test suite or an utility that people can run to test the sound output at various sample sizes)
[08:53] <lool> pitti: So I'm not sure of the benefits we would get from lowering the default volume instead of forcing a 16bits sample size
[08:54] <sladen> pitti: how much churn do you want, several of the themes have text-box areas that overlap with the progress-bar region.  Hence the progress-bar will get "scrolled" during integrity check or verbose boot
[08:56] <sladen> pitti: (I'd prefer not to fix it, since it's not the common-case)
[09:04] <tkamppeter> pitti, so bug 151510 is perhaps a false alarm? Or can it be that the behaviour is caused by AppArmor and opening the tCP port surrounds the problem?
[09:04] <ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Medium,New]  https://launchpad.net/bugs/151510
[09:09] <bdmurray> I think people do use the check cd boot off the CD a fair bit and it is something we ask reporters to do as a part of the triaging process.
[09:09] <lool> pitti: I'm adding an alsa test case to the bug report
[09:15] <lool> Did someone get hangs during the gutsy install under virtualbox?
[09:16] <lool> Mine hung at "Detecting file systems" (15%) and is stuck since an hour or so
[09:17] <crbrocket> #ubuntu-server
[09:17] <crbrocket> oops sorry
[09:18] <Pici> tsk tsk
[09:19] <sladen> lool: report in launchpad
[09:19] <sladen> lool: the question is not whether anyone else got hangs.  If *you* got hangs, then that is a bug
[09:20] <sladen> bdmurray: noted;  in that case we might want to consider fixing the text-box overlap for the others themes aswell
[09:21] <sladen> bdmurray: can you make that point in the bug report if you want me to 'sell' it to pitti
[09:30] <lool> sladen: I diagnosed it a little, and it's specific to xfs
[09:30] <lool> Err reiserfs, sorry
[09:31] <sladen> lool: just. say. no.
[09:32] <sladen> lool: anyone who runs it should be locked up
[09:32] <sladen> lool: however, sadly, that doesn't mean it's not still a bug
[09:34] <popey> it's 750G of madness in a box
[09:34] <mertiki> Riddell : The libqt3-mt package doesn't create config files in the /etc/qt3 folder. This result in ugly huge fonts. When applying the debdiff, the package now create the config files
[09:37] <mertiki> Riddell : adding "/etc" in the libqt3-mt.install file in the source package fix the problem in that way. The problem seems to be just about missing config files in /etc/qt3 folder as you can read in the bug report
[09:40] <lool> If anyone succeeded or failed with reiserfs in another environment than virtualbox, would be nice to comment in
[09:40] <lool> bug #151670
[09:40] <ubotu> Launchpad bug 151670 in partman-partitioning "Crashes when creating reiserfs filesystem" [High,New]  https://launchpad.net/bugs/151670
[09:42] <gnomefreak> have we released RC yet?
[09:42] <lool> Don't think so
[09:42] <gnomefreak> i didnt either but the http://releases.ubuntu.com/releases/7.10/ looks like it
[09:42] <mertiki> Riddell : You can look by yourself by installing the actual libqt3-mt package and use Qt3 programs like hplip or virtualbox, the fonts will be huge. The /etc/qt3 folder has too restrictive permissions and doesn't contain the config file "qtrc".
[09:43] <slangasek> gnomefreak: it's en route
[09:43] <gnomefreak> slangasek: ty
[09:43] <jpatrick> mertiki: Riddell's out for tonight (last time I saw), so it may take a while to respond
[09:43] <mertiki> jpatrick : thanks
[09:44] <gnomefreak> slangasek: u.d.a ML will have it right? so i know when to add it to /topic in #ubuntu+1
[09:44] <slangasek> by u.d.a you mean ubuntu-devel-announce?
[09:44] <gnomefreak> yes
[09:44] <slangasek> the announcement actually goes to ubuntu-announce
[09:44] <gnomefreak> ah ok
[09:44] <gnomefreak> i think im there too if not i will be :)
[09:57] <pochu> slangasek: re: liferea - thekorn and I have tested it, and it works fine (I've been running it for ~ 8 hours). Ok to upload so you can review it?
[09:59] <slangasek> pochu: yes
[10:01] <davmor2> bryce: ping
[10:03] <pochu> Any core-dev around to upload liferea for me? Please please :-) ---> http://emilio.pozuelo.org/~deb/
[10:15] <pwnguin> liferea fix?
[10:15] <pwnguin> i hope it fixes google search rss's
[10:20] <pochu> pwnguin: what's up with that?
[10:21] <pitti> tkamppeter_: no, apparmor doesn't control network connections
[10:22] <pitti> geser: list of non-built packages> yes, http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_outdate.txt
[10:23] <pitti> sladen: hm, hard to say without seeing a patch; but I trust your common sense to decide about intrusiveness :)
[10:23] <pitti> tkamppeter_: I didn't reproduce it yet, since I don't have remote printers ATM; I could fake some on my laptop, of course
[10:23] <geser> pitti: I'm trying to find out why imaze doesn't get build on amd64
[10:24] <geser> pitti: I guess it's listed in P-a-s
[10:24] <pitti> geser: yeah, probably
[10:24] <geser> pitti: is P-a-s visible somewhere for mere mortals?
[10:25] <pitti> geser: not on people.u.c. apparently; let me check
[10:25] <pwnguin> pochu: https://answers.edge.launchpad.net/ubuntu/+question/14715
[10:26] <Mithrandir> geser: http://cvs.debian.org/srcdep/Packages-arch-specific?root=dak&view=markup
[10:26] <pitti> geser: imaze-xview: !ia64 !amd64
[10:26] <geser> Mithrandir: does the Ubuntu buildds use the same list as Debian?
[10:26] <pitti> geser: that's the only one
[10:26] <geser> pitti: thanks
[10:26] <pitti> geser: yes
[10:27] <Mithrandir> geser: yes
[10:27] <Mithrandir> as you can see, lpia is in that list.  lpia doesn't exist in Debian.
[10:27] <sladen> pitti: http://www.paul.sladen.org/ubuntu/upload/edubuntu-artwork-usplash_0.1.0-52sladen1.debdiff  etc
[10:28] <pitti> sladen: yay hardcoded values :)
[10:33] <geser> Mithrandir: if I understand the P-a-s list correctly, it's lists binary packages (unless prefixed with %). What happens when one binary from a multi-binary package is listed there?
[10:33] <geser> does it get build on that arch at all?
[10:34] <pochu> pwnguin: looks like *that* search doesn't have any results... and that's why it doesn't have any items ;) Try this one, for example: http://video.google.com/videofeed?type=search&q=linux&so=0&num=20&output=rss
[10:35] <tkamppeter_> pitti, I am downdating CUPS now to the unpatched version and try to reproduce the bug 151510 ...
[10:35] <ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Medium,New]  https://launchpad.net/bugs/151510
[10:36] <pitti> tkamppeter_: thanks
[10:36] <pwnguin> pochu: i promise it has results
[10:38] <smurf> Any good idea what to do about bug 126499? "Some machines with RAID will not boot after upgrading to gutsy" is something we might want to avoid ...
[10:38] <ubotu> Launchpad bug 126499 in mdadm ""No devices listed in conf file were found" due to mdadm RAID1 array UUID different from actual UUID reported by vol_id" [Undecided,New]  https://launchpad.net/bugs/126499
[10:40] <pwnguin> pochu: it's derived from http://video.google.com/videosearch?q=label%3AengEDU . mozilla has an rss icon in the url box, and renders the listings decently
[10:42] <Keybuk> how embarassing
[10:42] <Keybuk> I was doing an upgrade chain run in vmware
[10:42] <Keybuk> and forgot how far I'd got
[10:42] <Keybuk> I had to check About Ubuntu to see which release it had been upgraded to :-)
[10:44] <tkamppeter_> pitti, I have retested now and it works correctly also with the old version. So kagou's and my observations on bug 151510 are a bad coincidence.
[10:44] <ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Medium,New]  https://launchpad.net/bugs/151510
[10:45] <pitti> tkamppeter: ah, good; so rejecting the cups upload was warranted
[10:46] <Keybuk> ENOMVO :-(
[10:46] <tkamppeter> pitti, CUPS is indeed listening to the broadcasts, even with "Listen localhost:631".
[10:47] <pitti> tkamppeter: *phew* that relieves me somewhat
[10:47] <tkamppeter> pitti, seems that I can mark bug 151510 invalid
[10:47] <ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Medium,New]  https://launchpad.net/bugs/151510
[10:48] <tkamppeter> And perhaps report an upstream bug on documentation. Somehow it must be told to the user that the Listen/Port directives do not need to be opened only for capturing broadcasts.
[10:51] <pitti> tkamppeter: so I wonder what kagou's problem was then
[10:54] <Kopfgeldjaeger> n8
[10:55] <pitti> doko: bug 91848 ack'ed
[10:55] <ubotu> Launchpad bug 91848 in subversion "segfault when importing libsvn.wc in python 2.4 on feisty/amd64" [Medium,In progress]  https://launchpad.net/bugs/91848
[10:58] <tkamppeter> pitti. I am wondering, too. Both config files look OK for me.
[11:03] <stgraber> mathiaz: postgresql and mail server testcases are now on the tracker
[11:04] <mathiaz> stgraber: thanks !
[11:07] <pochu> pwnguin: I see, I'll report it upstream.
[11:07] <pwnguin> pochu: thanks
[11:17] <pochu> pwnguin: http://sourceforge.net/tracker/index.php?func=detail&aid=1811856&group_id=87005&atid=581684 , in case you want to follow up.
[11:17] <ubotu> Gaim bug 1811856 "Liferea doesn&#039;t properly work with google search feeds" [Pri: 5,Open] 
[11:17] <pochu> Gaim?
[11:18] <pwnguin> what?
[11:18] <pochu> the bug report ^ look at the link
[11:18] <pwnguin> oh, it probably decided sf was the gaim bugtracker
[11:18] <pwnguin> instead of 50 billion project's bugtracker
[11:19] <pochu> hehe, right.
[11:19] <pwnguin> im not sure what i'd follow up on that bug report
[11:20] <pwnguin> does LP track sf?
[11:20] <pochu> Not yet, although you can link a bug report to it.
[11:20] <pochu> But the status isn't scanned.
[11:25] <calc> slangasek: wanted to double check that lifrea-1.4.4-0ubuntu2 that pochu has prepared is ok for upload by you, he mentioned he got your approval
[11:25] <calc> slangasek: i was going to sponsor the upload if it is ok
[11:25] <slangasek> calc: even if he hadn't, there's nothing that prohibits uploading
[11:25] <calc> slangasek: ok :)
[11:26] <calc> pochu: i'll upload it once my current transfer is done, it will probably be 20-30m
[11:26] <pochu> calc: sure, ty :)
[11:37] <pitti> \o/ RC
[11:37] <pitti> congrats, everyone
[11:37] <ion_> Ditto