[12:34] <bryce> heya slangasek, I've got a thrice-confirmed fix for beta bug 137604 that needs release manager approval
[12:34] <ubotu> Launchpad bug 137604 in xorg-server "Black Bar Across Screen with gutsy i810" [High,Fix committed]  https://launchpad.net/bugs/137604
[12:34] <bryce> slangasek: fix is pretty straightforward - just drops an errant patch.
[12:37] <slangasek> bryce: is http://people.ubuntu.com/~bryce/Uploads/xorg-server_1.3.0.0.dfsg-12ubuntu6.debdiff the right debdiff?
[12:37] <bryce> yep
[12:39] <slangasek> bryce: no bugs referenced in the changelog for when the patch was originally added, you're comfortable that reverting won't cause a regression elsewhere?
[12:40] <bryce> correct.  These were cherry-picked from xserver 1.3.99, but this particular patch did not have a LP bug associated with it.
[12:41] <slangasek> ok, go for it
[12:41] <bryce> great, thanks
[12:43] <iwj> pitti: (Not here, but:) libc patch was very straightforward.  Yes, I'll close the bug - sorry.
[12:58] <lamont> slangasek: did sysvinit get held up by the freeze?
[01:10] <slangasek> lamont: er.  I don't think I even know how to find an answer to that question, at the moment
[01:20] <lamont> slangasek: heh
[01:20] <lamont> no worries.
[01:20] <lamont> it'd be nice if it got accepted sometime soonish
[02:23] <alex-weej> alex@flash:/etc/fonts/conf.d$ dpkg -S /etc/fonts/conf.d/53-monospace-lcd-filter.conf
[02:23] <alex-weej> dpkg: /etc/fonts/conf.d/53-monospace-lcd-filter.conf not found.
[02:23] <alex-weej> ?!
[02:40] <mjg59> slangasek: Bah, forgot to mention a bug number in my gnome-control-center upload. It's #140485
[02:47] <alex-weej> mjg59: you're still up
[02:48] <alex-weej> what's this configuration option for enabling the default lcd filter?
[02:48] <alex-weej> i am all up to date on the main archive but i don't seem to be getting the behaviour you and scott are describing in mailing lists etc.
[02:54] <alex-weej> in fact i can't see any of these supposed changes in any of the relevant packages
[02:55] <alex-weej> last changelog entry is basically you saying "reverting all this"
[02:57] <lamont> Waiting for approval::
[02:57] <lamont>  OK: sysvinit_2.86.ds1.orig.tar.gz
[02:57] <lamont>  OK: sysvinit_2.86.ds1-14.1ubuntu28.diff.gz
[02:57] <lamont>  OK: sysvinit_2.86.ds1-14.1ubuntu28.dsc
[03:26] <Vegar> is this the channel to ask questions about the debian/rules script from the kernel source package?
[03:28] <Vegar> oh well, I'll give it a shot
[03:29] <Vegar> I ran debian/rules custom-binary-vegar, which generated a linux-headers-2.6.22-12-vegar_2.6.22-12.36.deb
[03:29] <Vegar> that .deb depends on linux-headers-2.6.22-12. how do I build one of those?
[03:53] <lamont> Vegar: if you build the base package, you'll get that one.
[03:53] <lamont> likewise, once the -12 source is accepted (beta freeze), then it'll get built.
[04:03] <Vegar> lamont: how do I build the base package?
[04:04] <lamont> debuild -b
[04:04] <lamont> it'll, um, take a while
[04:04] <Vegar> does it build images for all the architectures?
[04:04] <lamont> all flavors for whatever arch you're running on, yes.
[04:05] <Vegar> oh dear
[04:05] <lamont> alterntatively, i'd expect that the linux-headers-2.6.22-12 package will be in the archive sometime tomorrow
[04:05] <Vegar> and flavours are read from a file in a debian/*.d directory?
[04:05] <Vegar> oh
[04:05] <Vegar> tomorrow
[04:05] <lamont> I think so
[04:05] <Vegar> now that's interesting
[04:06] <lamont> https://edge.launchpad.net/ubuntu/gutsy/+queue shows it blocked waiting approval
[04:06] <Vegar> hah
[04:06] <Vegar> debian/rules binary-headers is building it
[04:06] <Vegar> wonderful
[07:23] <pitti> Good morning
[07:23] <IntuitiveNipple> morning
[07:24] <pitti> eek, LP offline
[07:24] <IntuitiveNipple> Anyone familiar with LRMI (Linux Real-Mode Interface) know where the latest (0.9?) source is? Sourceforge only seems to have 0.10 and yet I see references to 0.9 in some other packages (e.g. svgalib)
[07:27] <desrt> pitti; crikey.
[07:28] <desrt> what is happening to the world?  yesterday gnome bugzilla and today launchpad
[07:28] <pitti> desrt: rollout apparently
[07:28] <desrt> ahh
[07:28] <StevenK> Morning pitti
[07:38] <ajmitch> morning pitti
[07:40] <pitti> hey ajmitch
[07:42] <pitti> asac: did you see Q-FUNK's regression in bug 139403?
[07:42] <ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [High,Fix released]  https://launchpad.net/bugs/139403
[07:43] <ajmitch> LP back already?
[07:43] <ajmitch> great
[07:46] <evand> pitti: asac I had a similar experience, but it may just be a configuration issue.
[07:46] <evand> I'm assuming that if I comment the device out of interfaces and restart, network-manager should use it, correct?  It currently does not.
[07:46] <pitti> oh, that does look a little different now: https://edge.launchpad.net/ubuntu/+source/compiz
[07:47] <pitti> evand: right
[07:47] <evand> nm-applet does not die on me, though.
[07:53] <tepsipakki> hmm, the latest sysklogd update makes klogd fail to start here..
[07:54] <tepsipakki> but I guess it's not the same for everyone else
[07:58] <pitti> tepsipakki: runs happily here; any details?
[07:59] <tepsipakki> pitti: let me try a fresh install first. I put
[07:59] <tepsipakki> uh
[07:59] <tepsipakki> pitti: ... 'set -x' in the start script, and then it started fine, so I'm not sure what's going on :)
[08:09] <ajmitch> hi LaserJock
[08:12] <LaserJock> hi ajmitch
[08:12] <LaserJock> I'm trying to debug a not-so-nice bug in feisty
[08:13] <LaserJock> after a while when I go to logout/hibernate/shutdown the screen just freezes
[08:13] <LaserJock> or rather it just doesn't do anything
[08:15] <IntuitiveNipple> LaserJock: I solved a similar (if not the same) issue a while back on Feisty, on a local system. I *think* I bug-reported it but I'm not sure; let me have a dig
[08:15] <LaserJock> that'd be helpful, I don't even know quite what to look for
[08:17] <IntuitiveNipple> I remember having to apply it a couple of times after Feisty kernel updates but it was one of those manual things I kept at the back of my mind
[08:18] <IntuitiveNipple> LaserJock: To help jog my memory, is the system using compiz?
[08:18] <LaserJock> nope
[08:22] <IntuitiveNipple> I'm not *positive* (and so far I can't find a bug-report I made on this), but I *think* the solution yo my issue involved disabling compiz sync to vblank
[08:22] <IntuitiveNipple> s/yo/to/
[08:24] <LaserJock> hmm, well I doubt that's my issue
[08:24] <LaserJock> as I don't use compiz
[08:25] <IntuitiveNipple> I've dealt with so many issues this past few months, I really can't remember which one it was - I do recall the fix was trivial once I recalled how to do it :)
[08:25] <LaserJock> heh
[08:25] <IntuitiveNipple> I *think* the solution may be in a forum-post I found, which would explain why I can't find a bug-report
[08:26] <IntuitiveNipple> I'm scanning my bookmarks looking for a likely candidate
[08:30] <LaserJock> it's so weird. If I logout soon after logging in it's fine
[08:31] <LaserJock> if I wait a while it gets stuck
[08:49] <dholbach> good morning
[08:49] <Mithrandir> quadrophonic Daniel
[08:50] <dholbach> :)
[08:50] <tepsipakki> pitti: klogd still fails to start.. I need to boot in su-mode to debug that.. (now where were the passwords again)
[09:06] <\sh> moins
[09:07] <\sh> guys, is it allowed to change files inside debian/ directory during build time?
[09:07] <\sh> especially <package>.dirs is important for me now
[09:10] <pitti> \sh: preferably not
[09:10] <pitti> \sh: but if it's just .dirs, you can certainly create the necessary dirs in debian/rules?
[09:11] <pitti> \sh: ... and a lovely good morning!
[09:13] <LaserJock> grr, this seems to be a gnome-specfic problem :/
[09:14] <LaserJock> something maybe in feisty-updates I guess
[09:14] <pitti> LaserJock: is this video driver or kernel specific?
[09:14] <LaserJock> I have no idea
[09:14] <pitti> LaserJock: you might try with vesa, and with booting the feisty/release kernel?
[09:14] <LaserJock> hmm
[09:15] <pitti> LaserJock: or with logging out of gnome and suspending with gdm? (to rule out gnome-power-manager, compiz, etc.)
[09:15] <LaserJock> well, I can't log out of gnome, that's the problem ;-)
[09:16] <pitti> LaserJock: hm?
[09:17] <LaserJock> my problem is that at some point I can no longer log out of gnome
[09:17] <LaserJock> it doesn't happen in KDE
[09:17] <\sh> pitti: to you too...good morning :)
[09:17] <LaserJock> and it takes a while of being logged in before it does it
[09:18] <pitti> LaserJock: that sounds like a dbus or session initialization problem
[09:18] <pitti> LaserJock: check system -> settings -> session -> current session
[09:18] <\sh> pitti, problem is, that I'm trying to fix wine on amd64 to deploy it's libs into /usr/lib32 ...but the .dirs files needs /usr/lib so I'm trying to find a solution how to install /usr/lib or /usr/lib32 into the package depending on the arch
[09:18] <pitti> LaserJock: anything there that tries to connect to the session, but fails? (a 'plug' icon)
[09:19] <LaserJock> not yet
[09:19] <LaserJock> I do know that it's happened since Feisty's release
[09:19] <LaserJock> I'd guess a month ago or so
[09:19] <pitti> \sh: sounds like you should do it dynamically in debian/rules; I. e. set a $LIBDIR depending on DEB_BUILD_ARCHITECTURE, and use install -D ... $LIBDIR/
[09:20] <pitti> \sh: (or make install DESTDIR=... or whatever the upstream build system provides)
[09:22] <\sh> pitti, this is not the problem :) the problem is that the package itself uses .dirs to move the files into the package...but when I only need /usr/lib32 on amd64 and /usr/lib on i386...how to avoid the usage of debian/<package>.install and debian/<package>.dirs...I woud use dh_install in debian/rules and avoid using the automatic stuff
[09:22] <pitti> \sh: .dirs does not move any files, and in most cases, .dirs files are not necessary at all
[09:22] <\sh> pitti, the upstream build version is autotools...so no problem with DESTDIR
[09:23] <pitti> \sh: autotools -> ah, that has --libdir or so
[09:23] <pitti> \sh: right, dh_install is too dumb for per-arch directories, so you cannot use that
[09:23] <\sh> pitti, yepp..and depending on the build arch i'M setting CONFFLAGS += --libdir=/usr/lib32 on amd64...this is no problem.
[09:24] <pitti> \sh: just use --libdir and DESTDIR=debian/ia32-libs/ ?
[09:24] <pitti> that'll directly install the files into the binary package, isntead of into debian/tmp and using dh_install
[09:25] <LaserJock> pitti: ok, it just did it again
[09:25] <LaserJock> pitti: is there any good debugging I can do while it's frozen?
[09:26] <pitti> LaserJock: hm, no idea
[09:26] <pitti> LaserJock: unless you can ssh into the box and look at dmesg?
[09:26] <LaserJock> I'm on the box
[09:26] <pitti> LaserJock: is only X frozen, or the VTs, too?
[09:26] <\sh> pitti, ok...or DESTDIR=debian/tmp and moving the files to the correct location e.g. debian/<package1>/ or debian/<package2>/
[09:27] <LaserJock> it's actually just that the logout screen is frozen
[09:27] <pitti> \sh: whichever is easier
[09:27] <LaserJock> the mouse works
[09:27] <pitti> LaserJock: oh
[09:27] <\sh> pitti, thx...this helps me a lot :)
[09:27] <pitti> LaserJock: that moves the bug into the higher gtk levels then
[09:28] <LaserJock> if I click on *any* button in the logout dialog it does it
[09:29] <LaserJock> even cancel
[09:33] <LaserJock> pitti: do you know what package is responsible for the logout?
[09:33] <pitti> LaserJock: I'm not entirely sure; dholbach?
[09:33] <pitti> a combination of gdm/gnome-power-manager/gnome-session, I guess
[09:35] <pitti> hey seb128
[09:35] <seb128> hello pitti
[09:35] <seb128> hi MacSlow
[09:36] <gicmo> morning seb128
[09:36] <MacSlow> hi seb128, pitti, gicmo
[09:36] <pitti> hey MacSlow
[09:36] <gicmo> jo MacSlow!
[09:36] <seb128> gicmo: Alter!
[09:36] <LaserJock> hi seb128
[09:36] <seb128> Hi LaserJock
[09:36] <dholbach> seb128, gicmo: ALTER
[09:36] <gicmo> ALTER!
[09:37] <seb128> hey dholbach
[09:37] <MacSlow> dholbach, you should have taught seb128 the whole thing... "Alter Schwede!" not just "Alter!" :)
[09:38] <LaserJock> ok, so when I go back to X the logout area is just white
[09:38] <dholbach> MacSlow: ALTER is enough - I hear that more often than 'Alter Schwede' :)
[09:41] <LaserJock> seb128, dholbach: any idea of what would make the logout dialog box freeze up?
[09:41] <LaserJock> in Feisty that is
[09:41] <seb128> freeze?
[09:41] <seb128> like if you click on an action it doesn't do it and doesn't respond to the click?
[09:42] <dholbach> LaserJock: no idea, I haven't used feisty in a while
[09:43] <LaserJock> seb128: exactly
[09:44] <seb128> LaserJock: never seen that, usually the dialog just doesn't open
[09:44] <seb128> no idea
[09:44] <dholbach> on my amd64-nvidia box, 'desktop effects can not be started' any more; the resolution does not seem to match the 3D map or something
[09:44] <seb128> you are the first to report a such isssue
[09:44] <LaserJock> seb128: after I've been logged in for a while, if I click on *any* button it freezes
[09:44] <LaserJock> the mouse works
[09:44] <LaserJock> but I gotta restart X to log out, which is kinda annoying
[09:45] <LaserJock> it doesn't do it in KDE and I tried a fresh .gconf* .gnome*
[09:45] <IntuitiveNipple> LaserJock: I just remembered - when this happened I couldn't restart GDM with Ctrl+Alt+Backspace but could with Ctrl+Alt+SysRq+K
[09:45] <LaserJock> CtrlAltBackspace definately works here :-)
[09:45] <IntuitiveNipple> LaserJock: strike 2 :p
[09:46] <LaserJock> seb128: it's happened since release so I'm guessing it related to an update
[09:46] <IntuitiveNipple> LaserJock: can you switch to a text console?
[09:46] <LaserJock> yep
[09:46] <seb128> LaserJock: it happened since release so it's not an update, is it?
[09:47] <LaserJock> everything works except it won't log me out
[09:47] <LaserJock> seb128: no, I'm saying it started since after the release
[09:47] <LaserJock> my english wasn't very clear
[09:47] <seb128> do you suspend or hibernate this box? is the lo interface working correctly?
[09:47] <seb128> ok
[09:47] <LaserJock> it started about maybe 1 month ago
[09:47] <LaserJock> I do hibernate
[09:48] <IntuitiveNipple> LaserJock: I wish I could remember how I solved it! It happened on a  dual-CPU Matrox G450 dualhead with no compiz, but unfortunately I recently wiped that one
[09:48] <LaserJock> I think lo is working ok
[09:48] <LaserJock> I've had lots of fits with swap/hibernation/networking but I thought I got them all worked out
[09:49] <LaserJock> I just don't understand why hitting the "cancel" even would cause problems
[09:50] <LaserJock> seb128: it doesn't always do it either, I have to be logged in for some time
[09:50] <LaserJock> I can log in and then immediately log out no problem
[09:50] <IntuitiveNipple> Yes, that was the symptoms I had as well
[09:52] <IntuitiveNipple> LaserJock: what video chipset and driver is in use?
[09:52] <LaserJock> it's an ATI 7000 IGP card
[09:53] <LaserJock> looks like ati driver
[09:54] <IntuitiveNipple> LaserJock: my memory is returning somewhat... I recall it being an issue with the Composite extension, and disabling it in xorg.conf prevented the freeze.
[09:55] <LaserJock> that would do it for Gnome specifically?
[09:56] <LaserJock> gah, I don't even know how to get a xorg.conf in these days of automatic configs
[09:57] <LaserJock> seb128: I gotta run, is it worth a bug report?
[09:57] <seb128> LaserJock: no, a support request
[09:57] <seb128> LaserJock: a bug should describe a technical issue
[09:58] <IntuitiveNipple> bug #138811 might be related
[09:58] <ubotu> Launchpad bug 138811 in gnome-power-manager "Can't access shutdown menu when gnome-power-manager isn't enabled is sessions options" [Undecided,New]  https://launchpad.net/bugs/138811
[09:58] <LaserJock> seb128: ok
[09:58] <LaserJock> IntuitiveNipple: I check for gnome-power-manager already
[10:00] <IntuitiveNipple> LaserJock: this one looks closer: https://bugs.launchpad.net/ubuntu/+bug/38915/comments/54
[10:00] <ubotu> Launchpad bug 38915 in ubuntu "Logout proces hangs" [High,Confirmed] 
[10:04] <asac> pitti: that is not an ifupdown regression, but a network-manager crash
[10:05] <asac> pitti: i have a patch for that.
[10:06] <pitti> asac: you rock
[10:12] <asac> siretart: wpasupplicant ... we need a decision. 0.6.0 is the development version for development of network-manager 0.7, while 0.5 is the supplicant for network-manager 0.6.
[10:13] <pitti> seb128: hm, I guess removing f-spot from desktop is not an option?
[10:13] <seb128> pitti: no it's not
[10:14] <seb128> it's one of the cool applications nowadays
[10:14] <pitti> it'd be 1.8 MB of the 4 I still need to shave off the CDs...
[10:14] <asac> siretart: i think upgrading after beta is better than downgrading, so maybe we should really consider to downgrade now.
[10:14] <seb128> can't we bzip some packages to win those 4meg?
[10:14] <asac> siretart: let me know.
[10:14] <pitti> seb128: we already did so with the most promising ones
[10:15] <seb128> no need of promising ones to win 4meg
[10:15] <pitti> seb128: gnome-user-docs recently grew by 2 MB, due to translations, I guess
[10:15] <pitti> not sure whether we can optimize this a bit, it's a pretty big hog
[10:15] <seb128> can't we remove some fonts?
[10:15] <pitti> seb128: we did so yesterday, that saved us 6 MB
[10:16] <siretart> asac: I've been using the 0.5.9 version for quite some time now. the "timeouts messages" haven't vanished completely, but they are much fewer compared to 0.6
[10:16] <pitti> seb128: and I asked calc for some OO.o changes which will give us another 10 MB
[10:16] <siretart> asac: I currently suspect that network-manager folks develop and test with that version rather than with 0.6
[10:16] <pitti> hi Keybuk
[10:16] <siretart> asac: therefore I agree to you that it seems to be better for our users to ship with 0.5.9
[10:17] <seb128> pitti: do we have a list of what is installed on the CD and the size of each package somewhere?
[10:17] <pitti> seb128: loop-mount the CD and ls -lR :)
[10:17] <pitti> seb128: the list of pacakges is in http://cdimage.ubuntu.com/daily/current/gutsy-alternate-i386.list
[10:17] <pitti> seb128: and in the .manifest files for -live
[10:18] <seb128> where do you need to win 4meg? desktop CD? alternate?
[10:18] <pitti> seb128: alternate is most pressing
[10:18] <pitti> seb128: we don't have *any* langpacks on desktops any more either, so getting some space there would also be cool
[10:18] <seb128> you can remove f-spot from alternate if required I guess
[10:19] <seb128> I don't expect many desktop user using alternate anyway
[10:19] <pitti> seb128: f-spot is in -desktop
[10:19] <pitti> seb128: so we can only remove it from ubuntu-desktop, not just from alternate
[10:19] <seb128> no then
[10:19] <Keybuk> pitti: morning
[10:20] <seb128> /pool/main/v/vim/vim_7.1-056+2ubuntu1_i386.deb
[10:20] <seb128> is vim required on the CD?
[10:20] <seb128> we already have nano
[10:21] <pitti> seb128: right, let's kill that as well, at least for beta
[10:21] <seb128> and why is thunderbird-locale-en-gb_2.0.0.0+1-0ubuntu1_all.deb listed? we don't install thunderbird by default
[10:21] <pitti> or until we get OO.o smaller
[10:21] <pitti> seb128: language-support-en dependency
[10:21] <pitti> seb128: we already removed language-support-en from amd64, though
[10:21] <seb128> shouldn't it be a recommend?
[10:22] <pitti> Keybuk: that'll loose us many testers and downloaders, though
[10:23] <Keybuk> pitti: surely it's better than being unable to add anything new to Ubuntu ever again?
[10:23] <pitti> seb128: ok, vim (6 MB) and nvidia-glx (8 MB on i386) removed
[10:23] <seb128> pitti: do we need wamerican and wbritish? only one of those wouldn't be enough?
[10:24] <asac> siretart: how about the startup delay we see in bug 141233. how many tries do you usually see in 0.5.9 to connect to global control socket?
[10:24] <ubotu> Launchpad bug 141233 in wpasupplicant "MASTER network-manager crashes when wpasupplicant ctrl socket is not available" [Medium,Confirmed]  https://launchpad.net/bugs/141233
[10:24] <pitti> seb128: language-support-en, again
[10:24] <seb128> pitti: well, we can modify language-support-en if required no? ;)
[10:24] <pitti> seb128: we could drop language-support-en from the CDs and only install a subset of its dependencies, of course
[10:26] <siretart> asac: err, I didn't notice that. While grepping through my logs, I do see that message, but the delay is less than a second
[10:27] <pitti> Keybuk: it would encourage us to throw in a lot of stuff without ever cleaning up cruft, though
[10:28] <pitti> ok, this should get down amd64 alternate to 702 MB and i386 alternate to 700 MB
[10:28] <pitti> let's hope we get the new OO.o soon
[10:28] <seb128> I don't think we will manage to keep everything on one CD much longer anyway
[10:29] <pitti> that has always been a strong point of Ubuntu, though *sniff*
[10:30] <Keybuk> true, but increasing numbers of people have DVD writers now
[10:31] <Keybuk> and we don't need to fill the DVD, we could still artificially limit ourselves to <1GB or something
[10:31] <Mithrandir> the main problem with DVDs will be the size of them and downloading taking a while rather than burning them
[10:32] <Mithrandir> <2GB would at least be good, so we don't end up running into funny file system limitations.  *cough, fat*
[10:32] <pitti> right, bandwidth is still an issue in many parts of the world (except Norway, of course :-P)
[10:33] <Mithrandir> I only have 6.5Mbit at home.
[10:33] <Mithrandir> at the office, I'm not sure.
[10:33] <seb128> or we should stop using openoffice, but there is no good GNOME office at the moment :/
[10:33] <Keybuk> seb128: gedit!
[10:34] <Keybuk> epiphany+webkit instead of firefox/gecko?
[10:34] <Keybuk> that seems quite a bit smaller
[10:34] <Mithrandir> only 15Mbit here, it seems.
[10:35] <Keybuk> if ubuntu-devel were Facebook, I would totally be in the "Get rid of OpenOffice.org now" group
[10:44] <cjwatson> from the number of people who have been having problems with oversized CD images of late, I do not think it is yet true to say that most of the Ubuntu testing community have DVD writers
[10:45] <cjwatson> entry-level laptops still frequently come with DVD readers at best - DVD writers are an option
[10:45] <pitti> Keybuk: except that epiphany depends: firefox :)
[10:46] <Mithrandir> pitti: which is why he suggested using the webkit patches, I believe
[10:46] <asac> pitti: Keybuk suggests to switch to webkit ;)
[10:47] <pitti> ah
[10:52] <pkern> Some sites heavily relying on JS (most notably Google Apps like Docs & Spreadsheets) broke with Safari at least. Is this fixed with current Webkit? (I can't think of that as I guess Google blocks incompatible browsers on its own.)
[10:52] <mvo> iwj: thanks for your fix for #137191!
[10:55] <Mithrandir> pkern: try?  apt-get install libwebkitgdk0d ; /usr/lib/WebKit/GdkLauncher
[10:57] <pkern> Mithrandir: I'm waiting for new cd builds to install Ubuntu I'm afraid. But well I guess I could fire up qemu-kvm, but then I will probably first need to download a trackload of new packages.
[11:12] <pkern> Well, I can't even hit "Log in" on Google's Frontpage with it...
[11:14] <pkern> mail.google.com doesn't work for me neither. (Page somehow doesn't load.)
[11:15] <pkern> And clicking on a link on Heise Newsticker first worked fine, but near the end of the loading progress the program just crashed with "Fatal IO error 14 (Bad address) on X server"
[11:16] <pkern> This just doesn't look useable to me \:
[11:20] <pitti> ogra_: FYI, in ubuntu I removed nvidia-glx from ship; I merge this change to edubuntu seeds, since you have quite a size problem, too; please lart me and revert if that isn't desired by you
[11:21] <Hobbsee> asac: oops, you broke it.  or do i blame the kernel upload?
[11:22] <ogra_> pitti, nvidia-glx ?
[11:23] <ogra_> but compiz by default ?????
[11:23] <ogra_> what do our users do with compiz without a driver ?
[11:24] <ogra_> (i'm fine to drop whatever ubuntu drops, just curious why we drop specifically this)
[11:24] <pitti> ogra_: it's just in ship, and we need to free some space
[11:24] <pitti> ogra_: and it's not enabled by default anyway
[11:25] <pitti> ogra_: well, I don't like it either, but we have to drop *something* :/
[11:25] <ogra_> true
[11:25] <ogra_> indeed, dont ntell me
[11:25] <ogra_> i still have a bit more to cut down
[11:25] <pitti> ogra_: that, and the next OO.o will fix Ubuntu's space problem, but it's not even enough for edubuntu
[11:25] <ogra_> ah, well, i'll find something ...
[11:26] <ogra_> drop the kernel or so, i'll put it on the addon CD :P
[11:26] <pkern> pitti: Will you trigger a rebuild of Ubuntu daily alternate later, with the size fixes applied?
[11:26] <Kmos> latest update of gutsy was broken my boot
[11:27] <Kmos> on local.scripts
[11:27] <pitti> pkern: yes, once the new kernel has been settled
[11:27] <Hobbsee> evening sabdfl
[11:28] <sabdfl> howdy Hobbsee
[11:29] <Hobbsee> bug #137441
[11:29] <ubotu> Launchpad bug 137441 in linux-ubuntu-modules-2.6.22 "update iwlwifi drivers and firmware in gutsy >=0.1.14" [Medium,Fix released]  https://launchpad.net/bugs/137441
[11:29] <pkern> What I wondered about: why is build-essential shipped on the CD?
[11:29] <Hobbsee> pkern: for the poor people who have to use ndiswrapper and the like.
[11:29] <ogra_> pitti, oh, the lastest changes i made aer not in yet, i delayed the meta rebiuld for more ubuntu changes ... i dropped samba from -server, that should gain another 5-7M
[11:29] <ogra_> probably thats enough
[11:29] <asac> Hobbsee: network-manager will get a fix for bug 141106 (old bug, but now needed) and bug 141233 (introduced in ubuntu11)
[11:29] <ubotu> Launchpad bug 141106 in network-manager "network manager crashes when /etc/network/interfaces is touched [race] " [High,Fix committed]  https://launchpad.net/bugs/141106
[11:29] <ubotu> Launchpad bug 141233 in wpasupplicant "MASTER network-manager crashes when wpasupplicant ctrl socket is not available" [Medium,Confirmed]  https://launchpad.net/bugs/141233
[11:30] <cjwatson> pkern: pretty much every one of these things is accompanied by a huge argument that you can probably find if you look back in the archives
[11:30] <Hobbsee> asac: i got the new kernel upload last night - my ipw3945 keeps trying to ask for the wpa p/w.
[11:30] <pkern> Hobbsee: packages.ubuntu.com lists no ndiswrapper-source for gutsy, am I missing a rename?
[11:30] <asac> Hobbsee: modinfo ipw3945 | grep ^version
[11:30] <cjwatson> at this point there is almost nothing in the seeds that won't cause somebody problems if removed; which is why we often try to concentrate on shrinking things rather than removing things instead
[11:31] <Hobbsee> asac: version:        1.2.2mp.ubuntu1
[11:31] <asac> Hobbsee: has not been updated then
[11:31] <asac> (unless they didn't bump version info)
[11:31] <Hobbsee> asac: i was using the newer version from you, iirc?
[11:32] <asac> Hobbsee: no that is my version
[11:32] <ogra_> pkern, the general bits for a module build to get HW supported must be always there ... (but thats far from being what build-essential contains)
[11:32] <asac> Hobbsee: no changes ... maybe ask on -kernel if they added another patch or something, but i don't think so
[11:32] <Hobbsee> asac: as in, so they took your version, or their version never ovewrote yours
[11:32] <Hobbsee> right
[11:32] <asac> Hobbsee: he?
[11:33] <asac> Hobbsee: it did ... its just the same module version :)
[11:33] <Hobbsee> s/ovewrote/overwrote/
[11:33] <Hobbsee> asac: ah right.
[11:35] <carlos> pitti: hi, do you plan to do a new full language pack update for Gutsy before beta release?
[11:35] <ogra_> pitti, meh, you dropped vim as well :'-/
[11:36] <Hobbsee> !ping
[11:36] <ubotu> pong
[11:36] <pitti> ogra_: oh, did I? according to the conflict it wasn't there before
[11:36] <ogra_> dunno, i only read the commit message in ubuntu
[11:37] <pitti> ogra_: sorry, if you need it, put it back; (but we have vim-tiny in minimal)
[11:37] <ogra_> no, dont need it
[11:37] <pitti> ogra_: right, in ubuntu, but it wasn't even there before in edubuntu
[11:37] <ogra_> ah, i didnt know ubuntu shipped that differently
[11:37] <pitti> carlos: hm, I didn't plan it actually
[11:37] <ogra_> i dropped the big vim package releases ago :)
[11:38] <pitti> right :)
[11:38] <Hobbsee> pkern: hmm.  seems so
[11:38] <carlos> pitti: there is at least one application that misses translations because was moved from universe to main after latest language pack export
[11:38] <carlos> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/kmplayer/+bug/123544
[11:38] <ubotu> Launchpad bug 123544 in kmplayer "Langpack does not include kmplayer's translations" [Undecided,Confirmed] 
[11:38] <carlos> pitti: a full export would fix it
[11:38] <asac> Hobbsee: is it just that your pass is not remembered or that you can't connect anymore?
[11:38] <pitti> ogra_: no, that would be blasphemy!
[11:38] <laga> hi. is there any ETA for when the linux-ubuntu-modules FTBS will be fixed?
[11:38] <ogra_> pitti, !
[11:39] <pitti> carlos: well, sure, why not
[11:39] <Hobbsee> asac: the latter.
[11:39] <pitti> carlos: it would also downsize the langpacks a bit (which doesn't help much because we don't have any on the CDs, but we might be able to put some back later)
[11:39] <carlos> pitti: ok, thanks
[11:39] <asac> Hobbsee: i need your syslog then
[11:40] <pitti> carlos: thanks to you; will you ping me once the tarball is available?
[11:40] <carlos> sure, I will do it using the new infrastructure on production
[11:40] <iwj> mvo: You're welcome.  Have you seen 137191 before ?
[11:40] <cjwatson> laga: we're working on fixing the publisher at the moment. It's not really a true build failure, just waiting for other stuff to be published
[11:40] <carlos> so we can test that
[11:41] <cjwatson> laga: there was a Soyuz rollout this morning which caused some problems
[11:41] <Hobbsee> asac: FWIW, http://wedontsleep.org/~sarah/syslog
[11:41] <laga> cjwatson: thanks.
[11:42] <mvo> iwj: I'm not sure, maybe in one other report
[11:42] <mvo> iwj: but its not a frequent error
[11:42] <Hobbsee> asac: (i switch to wired in there, adn try the wifi multiple times, hence the FWIW)
[11:44] <amitk> bleh! my panels just resized to 75% of the screen after restarting with the latest updates..
[11:45] <davmor2> Hobbsee:  Is this an intel issue?
[11:45] <Hobbsee> davmor2: ipw3945, yes.
[11:45] <asac> Hobbsee: it asks you for a password?
[11:45] <Hobbsee> asac: yes
[11:46] <davmor2> Mine is working fine....  I don't get asked for a password anymore now it just magically connects.
[11:46] <Hobbsee> asac: i change it, and change it back, hit OK, then it goes back to configuring devices, and spits me another p/w box ~15 seconds later.
[11:46] <Hobbsee> davmor2: mine has been, up till this point.
[11:47] <iwj> mvo: Quite a scary one, when I found it.  It could have done almost anything ...
[11:47] <davmor2> Hobbsee: Hang on I'll grab me lappy
[11:47] <asac> Hobbsee: yes ... you don't get an association event  ... somehow
[11:47] <soren> iwj: Did you get any further with kylem about the modem driver issue?
[11:47] <asac> so it times out and thinks it might be a password issue
[11:48] <Hobbsee> asac: davmor2 damn, sorry.  i'm being called to dinner, and getting yelled at
[11:48] <Hobbsee> (thought i'd have longer)
[11:48] <davmor2> go eat
[11:50] <Hobbsee> hm, it's going to be longer than that, as we're movie watching
[11:50] <davmor2> asac: I might not be around when Hobbsee gets back but everything is working fine here.
[11:50] <asac> Hobbsee: maybe your password was changed? :)
[11:51] <Hobbsee> asac: dad would normally tell me - and it hasnt changed in ages
[11:51] <Hobbsee> but, possibly
[11:51] <iwj> soren: Not yet.  I want to try the new sl-modem-daemon first.
[11:53] <soren> iwj: Alright. Just give me a shout when you need me for testing.
[11:53] <iwj> soren: Willdo.
[11:53] <Hobbsee> asac: he didnt.  or if he did, he's not admitting to it :)
[12:00] <asac> pitti: ubuntu13 of network-manager uploaded and probably waits for a kick :)
[12:00] <pitti> asac: cool, thanks
[12:01] <seb128> pitti: I'm discussing language-pack updates with carlos
[12:01] <seb128> pitti: when do we need them for beta?
[12:01] <pitti> seb128: hm, I'd say Monday at the latest
[12:01] <seb128> pitti: we really should have the 2.20 upstream translations used for those or GNOME guys will be angry at us again
[12:01] <pitti> right, agreed
[12:02] <seb128> carlos: ^ monday looks a possible timeframe for the import?
[12:02] <carlos> pitti: I was planning to schedule language pack exports for Gutsy on Saturday night and Tuesday night, as agreed with you
[12:02] <pitti> carlos: I'm fine with triggering the full langpack build on Sunday
[12:02] <carlos> I could move it to Sunday night though
[12:02] <carlos> ok
[12:02] <carlos> then I will leave it as we agreed
[12:02] <asac> siretart: can you upload your 0.5.9 package with upstream verion 0.6.0+0.5.9 ?
[12:03] <pitti> carlos: is Saturday night enough to get all the gnome 2.20 po files imported?
[12:03] <carlos> that's a day and a half...
[12:03] <carlos> I think it should be enough, at least for anything uploaded before OO.org
[12:03] <pitti> carlos: if it takes until Sunday, that's still manageable
[12:03] <asac> siretart: lets use bug 140763, bug 141233 and maybe bug 138873 to justify that upload :)
[12:03] <ubotu> Launchpad bug 140763 in network-manager "NetworkManager is unreliable after resuming from suspend" [High,Confirmed]  https://launchpad.net/bugs/140763
[12:03] <ubotu> Launchpad bug 141233 in wpasupplicant "MASTER network-manager crashes when wpasupplicant ctrl socket is not available" [Medium,Confirmed]  https://launchpad.net/bugs/141233
[12:03] <ubotu> Launchpad bug 138873 in wpasupplicant ""*** stack smashing detected ***: /sbin/wpa_supplicant terminated" with iwl4965" [Medium,In progress]  https://launchpad.net/bugs/138873
[12:04] <carlos> seb128: did you upload all your packages before oo.org update?
[12:04] <seb128> carlos: has oo.org been uploaded? when?
[12:04] <seb128> oh, on wednesday
[12:04] <carlos>  Wed, 19 Sep 2007 10:28:41 -0500
[12:05] <carlos> yep
[12:05] <carlos> anyway, we can ignore that oo.org upload
[12:05] <carlos> so don't worry
[12:05] <seb128> carlos: 90% has been uploaded before
[12:05] <seb128> almost all the applications
[12:05] <seb128> so that should be alright
[12:05] <carlos> it wasn't a new version, so we don't lose anything ignoring it
[12:10] <pitti> asac: quite some changes :)
[12:13] <asac> pitti: there are two bugs fixed ... and for the one fix i added more safety belts to prevent it. if you want some rational for some hunks let me know
[12:15] <asac> pitti: debian/patches/41v_lp141233-fix-supplicant-cleanup-crashes.patch ... thats one is just one if(...ctrl) ... the rest is just indentation
[12:15] <ogra_> WTF
[12:15] <ogra_> is it wanted that NM commits suicide on upgrades andf blocks all networking if it cant start ?
[12:16] <asac> pitti: debian/patches/20_do_not_take_over_dhcpv4iface_when_v6_is_configured.patch ... this is a old bug introduced ages ago that we now see when you change your network config through network-admin. Its a null-deref crash as you can see from the patch
[12:16] <pitti> asac: right, I understand the race condition of half-written files
[12:17] <pitti> asac: /e/n/i still has an inotify watch, I take it
[12:17] <asac> pitti: yes ... actually i works that way
[12:17] <asac> pitti: network manage will retry some times later ... or maybe its network-admin that touches the file again at the end
[12:18] <asac> pitti: however it just fails now the first time it tries to parse ... then a few seconds later it succeeds
[12:19] <asac> pitti: debian/patches/41t_nm_device_wireless_index_ctrl_sockets_by_run_count.patch this is mostly a belt-and-braces patch ... which fixes the bug that triggered the real crash fixed in 41v_lp141233-fix-supplicant-cleanup-crashes.patch
[12:19] <pitti> asac: yes, I looked at the debdiff, and it's not too scary
[12:19] <asac> ok
[12:20] <asac> thanks
[12:23] <pitti> does anyone fancy taking a look at the pwlib FTBFS on i386?
[12:24] <seb128> pitti: fernando on #ubuntu-desktop has a fixed package yesterday I think
[12:24] <pitti> ah, cool
[12:24] <seb128> pitti: might need sponsoring
[12:24] <pitti> seb128: the FTBFS involved some 'no such file /home/fernando/...' stuff
[12:25] <seb128> pitti: right, it's listed on the desktop team wiki, I'll sponsor it
[12:25] <pitti> awesome, thanks
[12:25] <seb128> no problem ;)
[12:29] <YokoZar_> seb128: hey, you here?
[12:29] <YokoZar_> seb128: I'm trying to figure out a new error with my package.
[12:30] <seb128> YokoZar_: when I was writting on the chan just before I'm likely there
[12:30] <\sh> hmm
[12:30] <YokoZar_> Ooh, \sh is here too, nice
[12:30] <\sh> apt-get source <package> doesn't work for me...anything known? deb-src is in
[12:30] <seb128> YokoZar_: what package, what error?
[12:30] <seb128> \sh: "doesn't work"
[12:30] <YokoZar_> So, I'm trying the lib32 thing, and it compiles everything, but it's failing the package at this step: mkdir /usr/lib32/wine
[12:30] <YokoZar_> mkdir: cannot create directory `/usr/lib32/wine': Permission denied
[12:30] <seb128> do you get any error?
[12:30] <YokoZar_> (my new Wine package)
[12:31] <seb128> YokoZar_: you likely want to mkdir $(DESTDIR)/usr/lib32/wine
[12:31] <YokoZar_> I'll upload it to REVU in a bit, but I'm trying to figure out if this is a totally obvious stupid error on my part
[12:31] <\sh> seb128, E: E: Unable to find a source package for tomcat5.5
[12:31] <\sh> seb128, nothing else...
[12:31] <YokoZar_> seb128: I already put usr/lib32/wine into wine.dirs though
[12:32] <YokoZar_> or, rather, wine.dirs.amd64
[12:32] <\sh> YokoZar_, I talked about this issue with pitti
[12:32] <seb128> \sh: apt-cache showsrc tomcat5.5?
[12:32] <\sh> seb128, doesn't work either
[12:32] <seb128> \sh: do you have an universe deb-src?
[12:33] <\sh> YokoZar_, and then you  DESTDIR= to debian/tmp and move the files manually from debian/tmp to debian/<packagename>
[12:33] <\sh> seb128, sure :) everything :)
[12:33] <\sh> seb128, deb-src http://archive.ubuntu.com/ubuntu gutsy main restricted universe multiverse
[12:33] <ogra_> have you apt-get updated ? :)
[12:33] <\sh> ogra_, PENG ;)
[12:33] <ogra_> ;)
[12:34] <\sh> YokoZar_, so you don't use the .dirs and .install things
[12:34] <seb128> \sh: ask mvo
[12:34] <YokoZar_> \sh: why is .dirs broken here?
[12:34] <YokoZar_> \sh: it seems a lot cleaner to use the .dirs and .install things
[12:35] <\sh> YokoZar_, because it can't select between /usr/lib32 and /usr/lib and you don't want a /usr/lib32 in a package for i386
[12:35] <\sh> mvo, peng
[12:35] <\sh> mvo, aeh ping ;)
[12:35] <YokoZar_> \sh: are you aware you can do wine.install.i386 and wine.install.amd64 ?
[12:35] <mvo> \sh: hello
[12:36] <\sh> mvo, apt-get source <package> doesn't work
[12:36] <\sh> YokoZar_, so we don't need the .dirs, right?
[12:36] <\sh> mvo, the same with apt-cache showsrc <srcpackage>
[12:37] <\sh> mvo, while apt-cache show <package> works
[12:37] <YokoZar_> \sh: errr, what do you mean, I can just eliminate .dirs entirely?
[12:37] <YokoZar_> Actually I'm not exactly sure what .dirs does to begin with
[12:37] <mvo> \sh: could you please pastebin your sources.list? and the content of ls -l /var/lib/apt/lists ?
[12:37] <\sh> mvo, sure...moment
[12:38] <cjwatson> YokoZar_: man dh_installdirs
[12:39] <\sh> mvo, http://paste.ubuntu-nl.org/38103/
[12:39] <cjwatson> YokoZar_: debhelper creates directories automatically - .dirs is only useful when you need to create directories for use by non-debhelper code in debian/rules
[12:39] <YokoZar_> cjwatson: ahh ok
[12:39] <YokoZar_> what bothers me is the error that is being thrown is a permissions error - it's trying to make /usr/lib32/wine rather than (local)/usr/lib32/wine
[12:39] <YokoZar_> I'm gonna try junking the .dirs files and see what happens
[12:39] <cjwatson> then it's not debhelper doing it
[12:39] <cjwatson> removing .dirs will not help that
[12:39] <\sh> YokoZar_, autocrap error
[12:40] <cjwatson> it's more likely to be an upstream makefile
[12:40] <YokoZar_> Yeah it looks like it
[12:40] <cjwatson> perhaps you forgot to set DESTDIR, or perhaps it doesn't honour it
[12:40] <cjwatson> if it's autotools, then more likely the former
[12:41] <YokoZar_> This is my suspicion: 	CONFFLAGS += --libdir=/usr/lib32
[12:41] <YokoZar_> That should be something else I think
[12:41] <YokoZar_> that should be usr/lib32
[12:41] <cjwatson> no
[12:41] <mvo> \sh: and any apt-cache showsrc $pkg gives you a error?
[12:41] <\sh> mvo, no...it doesn't show anyrthing
[12:41] <cjwatson> YokoZar_: when you call 'make install', do you set prefix=?
[12:41] <YokoZar_> $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr
[12:41] <cjwatson> ok, so
[12:41] <cjwatson> usually what you do is:
[12:42] <cjwatson> build:
[12:42] <\sh> YokoZar_, why debian/tmp/usr?
[12:42] <cjwatson>         ./configure --prefix=/usr --libdir=\$${prefix}/lib
[12:42] <cjwatson>         $(MAKE)
[12:42] <cjwatson> install:
[12:42] <cjwatson>         $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr
[12:42] <\sh> YokoZar_, this is wrong
[12:42] <YokoZar_> \sh: I didn't change this, it was in the package before
[12:42] <cjwatson> \sh: it's perfectly reasonable if you're then going to use dh_install
[12:43] <mvo> \sh: aha, it looks like for some reason the authentication failed when apt-get update was run and it does not show untrusted sources. do you get a untrusted warning when trying to install a random package with synaptic or apt-get?
[12:43] <\sh> mvo, nope not today or yesterday...
[12:44] <\sh> YokoZar_, depends what makefile is doing now...I see $(DESTDIR)/$(libdir)
[12:44] <cjwatson> YokoZar_: so then make install expands ${prefix} in libdir differently during install, and it all works fine
[12:44] <cjwatson> but $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp is sometimes more convenient
[12:45] <cjwatson> either should work, just don't set both DESTDIR and prefix
[12:45] <mvo> \sh: but your /v/l/apt/lists does not show a .gpg file, so I strongly suspect that this is the case. have you tested the unauthentication warning thing?
[12:45] <\sh> mvo, strange...after the 10th apt-get update it now works...
[12:45] <\sh> sudo apt-get update I have to say
[12:46] <mvo> \sh: in the runs before, did you got authentication errors/warnings?
[12:46] <\sh> mvo, nope
[12:46] <mvo> *ick*
[12:46] <\sh> mvo, is there any cli switch to show the IP which is used for archive.ubuntu.com?
[12:46] <\sh> mvo, I wonder if it's our proxy or some mirror...
[12:47] <Kopfgeldjaeger> hi
[12:48] <\sh> yuck....
[12:48] <YokoZar_> ok I have ./configure --prefix=/usr but --libdir=/usr/lib32
[12:48] <YokoZar_> Should I switch that for --libdir=\$${prefix}/lib32  ?
[12:48] <\sh> http://security-tracker.debian.net/tracker/source-package/tomcat5.5 much work
[12:50] <mvo> \sh: please try -o Debug::Acquire::http it shows the IP on failure, but if no failure happens, there is no IP dispalyed AFAICS. I could add you a debug mode for this
[12:50] <\sh> pitti, keescook  please have a look at http://security-tracker.debian.net/tracker/source-package/tomcat5.5 and http://tomcat.apache.org/security-5.html, for gutsy, do you think it's better to package the new version or trying to backport the security fixes by cherry picking them?
[12:51] <mvo> \sh: please try -o Debug::Acquire::http it shows the IP on failure, but if no failure happens, there is no IP dispalyed AFAICS. I could add you a debug mode for this
[12:52] <\sh> mvo, doing so
[12:52] <\sh> mvo, I set it now as default in apt.conf
[12:53] <cjwatson> YokoZar_: yes, that sounds correct
[12:54] <cjwatson> YokoZar_: that's what I do everywhere
[12:54] <YokoZar_> cjwatson: cool.  While I'm at it I'm adding a check to change 	dh_shlibdeps -L wine -l debian/wine/usr/lib  to 	dh_shlibdeps -L wine -l debian/wine/usr/lib32  if on amd64
[12:55] <YokoZar_> ok, I'm passing it to pbuilder now...hopefully this time it'll build :)
[12:55] <siretart> asac: good idea! feel free to go ahead!
[12:55] <\sh> YokoZar_, if you are on it, fix the symlinks of the last added two lines.. (you forgot in the revu package the / in the front) and please use a correct ubuntu-version notation, so that a MOTU can upload directly
[12:56] <YokoZar_> \sh: eh, what's wrong with the version notation?
[12:56] <\sh> YokoZar_, you have wine_0.9.45-0ubuntu1-1.orig.tar.gz ;)
[12:56] <\sh> YokoZar_, but wine_0.9.45.orig.tar and debian/changelog should just say 0.9.45-0ubuntu1
[12:57] <YokoZar_> wait I'm confused
[12:57] <YokoZar_> what two lines are symlinks here?
[12:58] <\sh> YokoZar_, usr/lib32/liblcms.so1 and usr/lib/libpng12.so.0
[12:58] <\sh> YokoZar_, in the amd64 section....it needs a leading /
[12:58] <\sh> YokoZar_, speaking of the 0.9.45 package from revu...
[12:59] <YokoZar_> oh, thanks
[12:59] <YokoZar_> good spot
[12:59] <\sh> YokoZar_, and change the version and the orig.tar.gz to match the normal namning....means: wine_0.9.45.orig.tar.gz (think also of the tarball itself, it extracts to wine-0.9.45-0ubuntu1 not wine-0.9.45
[01:00] <YokoZar_> \sh: thanks
[01:01] <ogra_> pitti, can you let my -meta through please ?
[01:01] <\sh> and tries to cherrypick tomcat5.5 fixes
[01:01] <\sh> ogra_, greetings to suse...:)
[01:07] <Mithrandir> ogra_: edubuntu-meta accepted
[01:11] <\sh> YokoZar_, if you are fast we can push wine just before beta freeze...which would be great :)
[01:12] <YokoZar_> \sh: so, it's 4am here...how fast is fast?
[01:13] <\sh> YokoZar_, before 27th ;)
[01:14] <YokoZar_> oh
[01:14] <YokoZar_> so Wine 0.9.46 comes out the day after that ;p
[01:15] <pochu> \sh: aren't we already in beta freeze?
[01:16] <pochu> \sh: 27th is beta release, not beta freeze...
[01:16] <\sh> oh sorry...yeah
[01:16] <YokoZar_> but universe is different for beta freeze anyway
[01:16] <asac> siretart: can you upload? as you already have the sources and all on your disc?
[01:16] <\sh> YokoZar_, wine has a wildcard
[01:21] <YokoZar_> ok, it's building.  I'm going to sleep now.  Although, I forgot to do pbuilder update first...hopefully it wont' die a horrible death.  I should have a new package up on REVU in like 12 hours if it works.
[01:23] <\sh> YokoZar_, can you give me a .dsc,diff.gz and orig.tar.gz I can build it to and test
[01:23] <\sh> s/to/too/
[01:24] <YokoZar_> \sh: or I could just open a new tab and put what I have on REVU now
[01:24] <\sh> YokoZar_, just put it on revu..I'll testbuild etc.
[01:26] <YokoZar_> \sh: willdo
[01:26] <siretart> asac: sorry, I need to leave now. a colluege is having his final exam now and I need to leave now quickly
[01:26] <\sh> YokoZar_, thx :)
[01:27] <siretart> asac: my sources are at http://siretart.tauware.de/upload-queue, I don't have other sources for that version anyway
[01:31] <\sh> wah....cherrypicking patches for tomcat is evil
[01:31] <YokoZar_> \sh: so this REVU upload is taking a long time
[01:32] <\sh> YokoZar_, send me that debian/ dir separatly...the rest I can do here :)
[01:32] <\sh> YokoZar_, sh@sourcecode.de
[01:32] <YokoZar_> akk, now I'm getting this: Error '553 Could not create file.' during ftp transfer of wine_0.9.45-0ubuntu1.dsc
[01:32] <YokoZar_> Note: This problem might be caused by files already existent on the server.
[01:32] <YokoZar_>       For the official Debian upload queues, the dcut(1) utility can be used
[01:32] <YokoZar_>       to remove stale files from unsuccessful uploads.
[01:33] <asac> siretart: ok
[01:34] <iwj> mvo: Did you manually forward my dpkg ubuntu15 changelog entry to bug 137191 ?  I intended to have it done automatically.  Is the syntax specified on the wiki page not right ?
[01:34] <ubotu> Launchpad bug 137191 in dpkg "package update-manager 1:0.69 failed to install/upgrade: failed to fstat previous diversions file" [Undecided,Fix released]  https://launchpad.net/bugs/137191
[01:34] <\sh> YokoZar_, send the debian/ dir as tar.gz and I'll prepare a build...
[01:35] <YokoZar_> \sh: how about the .diff.gz
[01:36] <Kmos> iwj: LP: #number is the syntax
[01:36] <Kmos> it's mentioned in mail of LP 1.1.9
[01:36] <\sh> YokoZar_, are there patches which you applied inline for orig sources?
[01:36] <YokoZar_> yeah I fixed the naming problem too
[01:37] <\sh> YokoZar_, send it too .)
[01:37] <YokoZar_> \sh: oh there are no inline patches (pristine upstream wine 0.9.45)
[01:37] <tepsipakki> pitti: apparently the klogd problem was due to broken ldap.conf :P
[01:37] <\sh> YokoZar_, so diff.gz will be genrated automatically.. just the debian/ dir then
[01:37] <iwj> Kmos: Yes, that's the syntax I used.
[01:37] <iwj> Is it not supposed to be live yet ?
[01:38] <YokoZar_> why should I tar that up when I can send you the entire finished package?
[01:38] <\sh> YokoZar_, send it like you want :) debian/ would be enough :)
[01:38] <YokoZar_> cuz, like, .diff.gz IS the debian dir
[01:38] <\sh> YokoZar_, yepp
[01:39] <Kmos> iwj: yeah.. when it's change status from pending to uploaded, it should set it fix released
[01:39] <Kmos> iwj: better to ask on #launchpad what happened
[01:39] <YokoZar_> I'm reuploading to REVU anyway
[01:40] <YokoZar_> my error went away after 5 mins when it flushed out the failed upload
[01:40] <cjwatson> iwj: it's been working well for me for some time
[01:41] <Kmos> iwj: LP: #137191.) you used a "." in the end of number
[01:41] <iwj> Yes, obviously.
[01:41] <iwj> It's the end of a sentence so it should get a `.'.
[01:41] <Kmos> that's the problem
[01:41] <iwj> WTF
[01:41] <Kmos> the "." should be after ")"
[01:41] <iwj> I'll file a bug.
[01:41] <Kmos> iwj: i think you should :-)
[01:41] <Kmos> against soyuz
[01:43] <cjwatson> heh, I've never had that problem because I do "Description of fix (LP: #nnnnnn)."
[01:44] <cjwatson> iwj: you should not file a bug on Launchpad for this though
[01:44] <cjwatson> iwj: the regex is in dpkg, just like for closes:
[01:45] <cjwatson> iwj: and I don't see anything in that regex supporting Kmos' assertion
[01:45] <cjwatson> while ($f{'Changes'} =~ /lp:\s+\#\d+(?:,\s*\#\d+)*/ig) {
[01:45] <cjwatson>   push(@launchpad_closes, $& =~ /\#?\s?(\d+)/g);
[01:45] <cjwatson> }
[01:45] <iwj> Hmmmm.
[01:45] <iwj> Must be at my end then.
[01:45] <cjwatson> do you have the .changes around?
[01:46] <iwj> Yes.  No Launchpad-Closes field.
[01:46] <cjwatson> (it actually comes out as Launchpad-Bugs-Fixed, but still)
[01:47] <cjwatson> source built with Debian dpkg maybe?
[01:47] <cjwatson> we should get that patch in there
[01:47] <iwj> Oh, I've got some wierd old bits in /usr/local ...
[01:47] <iwj> I must have been doing some testing.
[01:47] <iwj> And forgot to get rid of them.
[01:47] <cjwatson> ah
 bazaar.launchpad.net and codebrowse.launchpad.net are going down for emergency maintenance, ETD is 10 minutes
[02:00] <dholbach> MOTU Meeting in #ubuntu-meeting
[02:05] <elmo> bazaar.launchpad.net and codebrowse.launchpad.net are back
[02:19] <ogra_> seb128, ping
[02:19] <seb128> ogra_: hi
[02:19] <ogra_> http://www.gnome.org/start/2.20/notes/en/index.html#rnusers-login-and-screensaver
[02:19] <ogra_> do you have any indicator how that message feature shold be implemented ?
[02:20] <ogra_> the g-s-s changelog doesnt even remotely mention such a feture
[02:20] <ogra_> "The GNOME Screensaver now allows people to leave you a note while your screen is locked, by clicking the "Leave Message" button. You'll see these messages when you login."
[02:21] <pedro_> in the lock dialog
[02:21] <ogra_> which lick dialog ?
[02:21] <ogra_> if i click lock screen it just locks, there is no dialog
[02:21] <ogra_> *lock
[02:21] <pedro_> system -> logout -> lock screen
[02:22] <ogra_> yes, thats what i'm talking about
[02:22] <pedro_> yep lock dialog, that's the name of the glade file (iirc)
[02:22] <ogra_> beyond that its nothing thats implemented in gnome-screensaver it seems
[02:22] <jdstrand> asac: what are your thoughts on bug 138217 getting fixed for gutsy?
[02:22] <ubotu> Launchpad bug 138217 in network-manager "NetworkManager fills log on start up until dhcdbd has started" [Low,Confirmed]  https://launchpad.net/bugs/138217
[02:23] <ogra_> pedro_, which glade file ?
[02:23] <pedro_> ogra_: the glade file of that dialog
[02:23] <ogra_> pedro_, from which package ?
[02:24] <pedro_> aham, no we are talking about different things
[02:24] <ogra_> you are talking about the logout dialog (where i dont see such a feature at all), right ?
[02:24] <pedro_> yes
[02:24] <ogra_> i'm talking only about gnome-screensaver
[02:24] <jdstrand> asac: logcheck has been churning away for the last 40 minutes (and counting) trying to process the logs
[02:24] <pedro_> we are shipping g-s-s with a theme ?
[02:25] <ogra_> it defaults to the system theme
[02:25] <ogra_> seb128, any idea where exactly that is implemented ?
[02:27] <seb128> ogra_: no, somebody asked yesterday and I never saw that
[02:27] <pedro_> saw a bug about that in b.g.o
[02:28] <pedro_> http://bugzilla.gnome.org/show_bug.cgi?id=384509
[02:28] <ubotu> Gnome bug 384509 in dialog "Allow disabling of leaving notes when screen is locked" [Enhancement,Reopened] 
[02:30] <pedro_> it seems that it needs to be build with libnotify support
[02:31] <seb128> pedro_: yes, it lacks a Build-Depends, I'm fixing it
[02:31] <seb128> ogra: gnome-screensaver lacks a Build-Depends to get the feature
[02:31] <pedro_> seb128: coool
[02:32] <seb128> ogra: I'm fixing it
[02:32] <cjwatson> there's a neat thing in Soyuz now that tells you what's happening with binary uploads
[02:32] <ogra> seb128, ChangelogDoesnt mention it at all
[02:32] <cjwatson> so https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/2.6.22-12.29 has:
[02:32] <cjwatson> #   gutsy lpia   Successfully built  (DONE)
[02:32] <cjwatson> # gutsy ia64 Successfully built (ACCEPTED)
[02:32] <cjwatson> # gutsy i386 Successfully built (DONE)
[02:32] <seb128> ogra: usually diffing the configure.ac between versions is useful
[02:32] <cjwatson> just thought I'd mention it here since people might find it useful
[02:32] <ogra> seb128, indeed, but usually such a massively new feature shows up in the ChangeLog as welll
[02:33] <cjwatson> (works on non-edge too)
[02:33] <ogra> all i find is a mention of the away message for the unlock dialog there ... but nothing for  a feture to leave messages to other users
[02:36] <seb128> ogra: there is this one
[02:36] <seb128> 	(gs_lock_plug_init):
[02:36] <seb128> 	Make note feature and libnotify optional.  Apparently
[02:36] <seb128> 	libnotify isn't an approved dependency.
[02:36] <seb128> and
[02:36] <ogra> gah
[02:36] <seb128> 	(load_theme), (gs_lock_plug_init):
[02:36] <seb128> 	Add ability to leave messages at the locked screen.
[02:36] <seb128> 	Based on patch from Matthias Clasen <mclasen@redhat.com>
[02:36] <seb128> 	Fixes #384509
[02:36] <ogra> thats the one i talked about
[02:36] <ogra> its a sting gconf key for the unlock dialog
[02:36] <seb128> I've uploaded the fix
[02:36] <ogra> thanks
[02:37] <ogra> guess i have to apologize to the bug reporter :)
[02:37] <seb128> pitti: could you approve the GNOME uploads pending (gdm, gnome-screensaver, rhythmbox)
[02:38] <asac> jdstrand: i don't think its critical ... anyway, why do you think that its related to bug 137744?
[02:38] <ubotu> Launchpad bug 137744 in network-manager "network-manager fills logs with nm_policy_device_change_check messages" [Wishlist,Fix released]  https://launchpad.net/bugs/137744
[02:40] <Hobbsee> asac: go figure.  rm'd config files, took it all down, brought it all back up again, played black magic...seems to work.
[02:40] <jdstrand> asac: sudo egrep 'Sep 21 .* NetworkManager' /var/log/daemon.log.0 | wc -l
[02:41] <jdstrand> asac: 134590
[02:41] <jdstrand> asac: and in syslog
[02:42] <jdstrand> asac: that is a *lot* of output.  I just turned the computer on at 7:40am EDT
[02:42] <hunger> jdstrand: Yeap, network-manager is extremely noisy:-(
[02:45] <asac> Hobbsee: which config file did you rm?
[02:46] <Hobbsee> asac: knetworkmanagerrc
[02:46] <asac> ah ok ... no idea about that
[02:46] <jdstrand> asac: it was doing a lot better, then there was the update around the 2007-09-13 and then got lots of output again
[02:46] <Hobbsee> asac: neither.
[02:47] <jdstrand> asac: I know this is marked as 'low', but this a lot of disk IO for my laptop, even without logcheck (which to me is really important)
[03:02] <pitti> seb128: I'll have a look
[03:02] <pitti> tepsipakki: *phew* :)
[03:03] <pitti> ogra: -meta> will do
[03:03] <ogra> pitti, Mithrandir did already, but thanks :)
[03:12] <Keybuk> pitti: do you still have the edgy ddebs?
[03:14] <pitti> Keybuk: no, we don't
[03:15] <pitti> Keybuk: they were incomplete anyway, and there had been some problems with the archive creation tools as well as disk space, so we wiped them
[03:15] <Keybuk> :-(
[03:16] <jdstrand> asac: sorry, just looked at bug 137744 again
[03:16] <ubotu> Launchpad bug 137744 in network-manager "network-manager fills logs with nm_policy_device_change_check messages" [Wishlist,Fix released]  https://launchpad.net/bugs/137744
[03:17] <MacSlow> mvo, where are the default values for compiz-plugins stored again... I mean which package provides them?
[03:20] <jdstrand> asac: I was seeing the output from 137744, then upgraded to 0.6.5-0ubuntu11 and things were fine.  Then had another upgrade (dbus I believe) that caused the output in 138217.
[03:21] <jdstrand> asac: I think the issue is ' NetworkManager: <WARN>  nm_dhcp_manager_begin_transaction(): dhcdbd not running!'
[03:22] <jdstrand> asac: grep 'dhcdbd not running' /var/log/daemon.log.0|wc -l
[03:22] <pitti> asac: I'm confused; there is another n-m 0.6.5-0ubuntu13 in unapproved, but I already accepted that version earlier
[03:22] <jdstrand> asac: 14150
[03:22] <pitti> asac: ah, nevermind me, got it
[03:28] <jdstrand> asac: I updated bug 138217 with these comments
[03:28] <ubotu> Launchpad bug 138217 in network-manager "NetworkManager fills log on start up until dhcdbd has started" [Low,Confirmed]  https://launchpad.net/bugs/138217
[03:29] <Kmos> iwj: you know if bug 28393 is fixed?
[03:29] <ubotu> Launchpad bug 28393 in dpkg "Dutch translation of message for replacement of configuration file wrong" [Medium,Confirmed]  https://launchpad.net/bugs/28393
[03:34] <iwj> Kmos: Not offhand ...
[03:35] <pitti> seb128: rhythmbox> that new dependency python-louie is in universe...
[03:35] <seb128> pitti: it's a Recommends
[03:35] <iwj> Kmos: Looks like it has.
[03:35] <asac> pitti: http://paste.ubuntu.com/346/
[03:35] <pitti> seb128: OTOH it already recommends: gstreamer0.10-plugins-ugly and thus break closure of main
[03:36] <seb128> "closure"?
[03:36] <seb128> we don't install Recommends by default do we?
[03:36] <pitti> seb128: "ogre model"
[03:36] <pitti> seb128: we do
[03:36] <pitti> seb128: all tools except apt-get do it
[03:36] <seb128> since when?
[03:36] <seb128> synaptic do?
[03:36] <seb128> mvo: ^
[03:36] <pitti> hm, edgy or so?
[03:36] <asac> pitti: in addition it probably doesn't have bug 138873
[03:36] <ubotu> Launchpad bug 138873 in wpasupplicant ""*** stack smashing detected ***: /sbin/wpa_supplicant terminated" with iwl4965" [Medium,In progress]  https://launchpad.net/bugs/138873
[03:36] <seb128> I though only aptitude was doing that
[03:37] <seb128> I use apt-get
[03:37] <Hobbsee> seb128: not for non-metapackages, by apt.
[03:37] <seb128> pitti: hum, how come that the rhythmbox Recommends on gstreamer0.10-plugins-ugly doesn't break then?
[03:37] <pitti> asac: eww, 0.6 -> 0.5.8?
[03:37] <seb128> Hobbsee: EPARSE, what apt?
[03:37] <Hobbsee> seb128: aptitude does all the time, apt does for Section: metapackages.
[03:37] <pitti> seb128: it doesn't break, since it's not a strict Depends:, but it's a bit unclean
[03:37] <seb128> Hobbsee: right, which rhythmbox is not
[03:37] <Kmos> iwj: you can handle it? it's assigned to you
[03:37] <asac> pitti: yes
[03:38] <Hobbsee> and synaptic/adept follows apt.
[03:38] <Hobbsee> seb128: correct.
[03:38] <pitti> asac: are you sure what you are doing? :)
[03:38] <seb128> Hobbsee: so you are basically say the same thing as I do
[03:38] <Hobbsee> seb128: debian is also moving to recommends by default - i'm assuming youv'e seen it.
[03:38] <seb128> Hobbsee: we don't install Recommends
[03:38] <asac> pitti: it was an error to have 0.6.0 in the first place ... 0.6.0 is a test-field for network-manager 0.7
[03:38] <Hobbsee> seb128: excluding Section: metapackages.  correct.
[03:38] <iwj> Kmos: As I say, it has been fixed.  I've adjusted the bug state.
[03:38] <seb128> Hobbsee: yesn that's planned for several Ubuntu cycles, we already had the discussion with mvo
[03:38] <Kmos> iwj: ah ok =) thx
[03:38] <asac> pitti: i discussed that with siretart and he finally agreed on his own that we should downgrade
[03:38] <iwj> Any particular reason why you're bring it up now ?  Eg, someone noticed it ...
[03:39] <Hobbsee> seb128: ahh, ok.
[03:39] <seb128> pitti: anyway I can file a MIR for louie if you prefer
[03:39] <pitti> seb128: not a biggie, I let it through, just to raise a small discussion about it
[03:39] <iwj> Kmos: Since if someone thinks it's wrong it may need more attention.
[03:39] <Hobbsee> iwj: $mypetbug, most likely :)
[03:39] <seb128> pitti: well, rhythmbox lists a plugin which doesn't work (upnp) at the moment
[03:39] <pitti> seb128: not sure what it does; if it makes sense, why not
[03:39] <seb128> pitti: python-louie needs to be installed to get that working
[03:39] <seb128> pitti: I assumed that the Recommends would be the quicker way for now
[03:40] <seb128> pitti: I'll do a MIR later, no hurry for that
[03:40] <pitti> right
[03:40] <asac> pitti: if you look at the bugs, there are plenty of failed connect attempts to wpa ctrl socket and TIMEOUT[CLI]  messages ... 0.5.9 doesn't have any of those.
[03:41] <pitti> asac: 0.6cvs was uploaded at start of May, i. e. we have it for almost the entire live of gutsy
[03:42] <pitti> asac: which means that we got essentially no testing *at all* of 0.5.8 in gutsy
[03:42] <asac> pitti: yes, i couldn't prove that 0.6 is buggy until after nm ubuntu11
[03:42] <iwj> Hobbsee: Yes, I thought that but it hardly seemed like a good candidate for a pet bug.  My pet bugs are all +3 dragons of laying waste.
[03:42] <pitti> asac: I guess it by and large worked until now, what changed that?
[03:43] <Hobbsee> iwj: :)
[03:43] <asac> pitti: well before that network manager didn't visualize the timeout issues
[03:43] <asac> pitti: i added that in ubuntu11, so now we see that wpasupplicant fails sooo many times to do anything for us
[03:43] <pitti> asac: ah, a changed debugging output
[03:43] <pitti> ?
[03:44] <pitti> asac: can you please put that version in a ppa and ask bug reporters to test it and give feedback?
[03:44] <pitti> and o u-devel@, can't hurt
[03:44] <asac> pitti: yes ... before that nm just failed ... i finally figured out that its a timeout from wpa backend, so i added the debugging output on client side (TIMEOUT[CLI] 
[03:44] <asac> pitti: well time is not on our side ... i would rather try this in cd testing and if there are new bugs, revert to 0.6.0
[03:45] <pitti> asac: I see; ok, it would be unfortunate to leave it like that, but I want some confirmation that the new version doesn't change things for the worse
[03:45] <pitti> asac: how much testing feedback did you get with 0.5.8 so far?
[03:46] <asac> pitti: siretart uses it ... me uses it ... stgraber used it as well afaik.
[03:46] <asac> pitti: but ok i will upload now
[03:46] <asac> pitti: to ppa and lets see what feedback we get till monday
[03:46] <pitti> asac: yep, we should get some community testing over the weekend
[03:46] <asac> i will ask on forums as well
[03:46] <pitti> asac: Monday is still fine, we still need langpacks and everything
[03:50] <asac> pitti: yes, when does ISO testing start?
[03:50] <pitti> asac: as soon as we get images, I hope I get some this evening
[03:50] <asac> ok
[03:51] <pitti> asac: they won't be 'good' yet, since we'll get another kernel, wpasupplicant, langpacks, etc.
[03:51] <pitti> and OO.o
[03:51] <pitti> but good enough for checking the installer and new kernel, etc.
[03:51] <iwj> Hobbsee: Debian closed #1708 recently but it turns out it's not really fixed; they cloned it and the clone (#439769) is still open.
[03:52] <StevenK> pitti: Who's the RM for the beta?
[03:52] <asac> pitti: right ... thanks that you already put wpasupplicant in that list ;)
[03:53] <pitti> StevenK: officially, slangasek; I'm backup, mentor, and release engineer
[03:53] <asac> StevenK: i think pitti slangasek  dual head ;)
[03:53] <pitti> asac: we'll need to bite that bullet, but I'm not crazy enough to let it through without some testing :/
[03:53] <asac> pitti: i understand that
[03:54] <asac> pitti: wouldn't do it as well ... and honestly i really feel bad about that
[03:54] <asac> pitti: but as i said i had no strong point until recently to revert wpasupplicant :)
[03:54] <mathiaz> pitti: who is responsible for accepting nominated bugs for a serie ?
[03:54] <pitti> asac: did a lot of those bugs have "... but it worked in feisty"?
[03:54] <asac> pitti: (bad feeling - about pushting this at this point of time)
[03:55] <pitti> mathiaz: ~ubuntu-sru for stables, ~ubuntu-release for gutsy
[03:55] <mathiaz> pitti: soren and I are trying to figure out how we can track which samba bugs we'd like to get fixed in dapper for example.
[03:55] <asac> pitti: since the beginning of gutsy we had huge regressions
[03:55] <asac> pitti: i always suspected that its the development version of wpa ... now i do lots of things to workaround, but its still too buggy
[03:55] <pitti> mathiaz: ah, I see
[03:56] <mathiaz> pitti: I don't think that ubuntu-sru should be involved at this stage of the process
[03:56] <pitti> mathiaz: you can milestone them as 'dapper-updates'
[03:56] <pitti> mathiaz: right, I misunderstood you
[03:56] <asac> pitti: anyway, the improvements of NM are good even with old wpasupplicant, because now its pretty rock solid for things like wpasupplicant failures et al ;)
[03:56] <pitti> mathiaz: create a dapper task and set it to 'dapper-updates' milestone
[03:56] <pitti> asac: heh
[03:57] <mathiaz> pitti: create a dapper task == nominate for release ?
[03:58] <pitti> mathiaz: just adding the dapper task is enough probably, there are only 145 bugs with a dapper task
[03:58] <pitti> mathiaz: right
[03:58] <pitti> mathiaz: so something like /ubuntu/dapper/+source/samba/+bugs will give you the list
[03:59] <mathiaz> pitti: but only if ubuntu-sru has accepted them ?
[03:59] <pitti> mathiaz: no, ubuntu-qa should be able to create tasks
[03:59] <pitti> mathiaz: that has been like that for a while, but I hope it has been fixed
[03:59] <pitti> mathiaz: if not, use the workaround (change the url to ubuntu/dapper/... and click the 'needs fixing here' button)
[04:00] <pitti> mathiaz: I'd rather reject one or two tasks that I think are not appropriate than blocking your workflow for every single bug
[04:00] <pitti> in general I trust developers to judge which bugs are worth backporting
[04:06] <mathiaz> soren: another issue I've noticed while going through samba bugs is that some of them are related to nautilius.
[04:07] <mathiaz> soren: do you know if gnome-vfs uses smbclient to implement smb:// access ?
[04:08] <soren> mathiaz: It does.
[04:08] <seb128> mathiaz: it uses libsmbclient
[04:09] <mathiaz> soren seb128: ok. Thanks.
[04:10] <soren> Ah, yes, of course.
[04:13] <\sh> pitti, ping tomcat5.5
[04:13] <\sh> pitti, 5.5.20 has several CVEs attached...up to 5.5.25 which fixes them all...
[04:14] <mathiaz> soren: so for samba bugs related dapper, have you read pitti suggestion ?
[04:14] <pitti> \sh: will look in a minute
[04:14] <soren> mathiaz: Short version: Add a dapper task for the ones we find severe enough?
[04:15] <mathiaz> soren: yes.
[04:15] <mathiaz> soren: I do that with other packages, but I'm not sure it actually works.
[04:15] <soren> mathiaz: Makes perfects sense.
[04:15] <\sh> pitti, FYI, debian has 5.5.23 so a sync is not ok...I'm trying to package 5.5.25 but I don't want to decide from the security PoV if it's better to wait for debian or just update...cherrypicking is difficult
[04:15] <mathiaz> soren: I'm not sure they show up on the dapper list right away.
[04:15] <soren> mathiaz: No, I've also found that marking bugs as targeted for a specific release doesn't magically fix them. That's really annoying :)
[04:16] <mathiaz> soren: I'll make a test bug to check that.
[04:16] <soren> mathiaz: Cool.
[04:18] <mathiaz> soren: bug https://bugs.launchpad.net/ubuntu/+source/samba/+bug/141518
[04:18] <ubotu> Launchpad bug 141518 in samba "Test for dapper task - ignore me :)" [Undecided,Fix released] 
[04:18] <mathiaz> pitti: I've nominated bug 141518 for dapper, but it doesn't show up in dapper list: https://bugs.launchpad.net/ubuntu/dapper/+source/samba
[04:18] <ubotu> Launchpad bug 141518 in samba "Test for dapper task - ignore me :)" [Undecided,Fix released]  https://launchpad.net/bugs/141518
[04:18] <soren> I've got a few bugs I wouldn't mind marking as dupes of that one :)
[04:20] <soren> mathiaz: It's only been nominated. I think it needs to be approved for DApper first.
[04:21] <pitti> mathiaz: I approved the nomination
[04:21] <pitti> mathiaz: seems that bug is still not fixed
[04:21] <pitti> mathiaz: it should appear now
[04:21] <pitti> mathiaz: so better use the workaround with the URL changing
[04:21] <mathiaz> pitti: yes.
[04:21] <mathiaz> pitti: it's the same thing.
[04:21] <mathiaz> pitti: At least last time I've tried it.
[04:21] <pitti> meh
[04:22] <mathiaz> pitti: yes. I've used the url hack for edgy
[04:22] <mathiaz> pitti: it doesn't create an edgy task.
[04:22] <pitti> mathiaz: meh, they fixed it the wrong way around
[04:22] <pitti> mathiaz: it's just nominated for edgy now
[04:23] <pitti> mathiaz: can you set milestones?
[04:23] <mathiaz> pitti: yes.
[04:23] <pitti> \sh: (btw, my default answer is 'yes for the new upstream microrelease based on latest Debian', unless motu-uvf overrules me
[04:23] <ogra> what was the name of the new CD build machine ?
[04:24] <mathiaz> pitti: So we'll have to use milestone instead.
[04:24] <pitti> \sh: s/overrule/explicitly decides this/
[04:24] <pitti> mathiaz: that, or nominate them, and I'll approve them wholesale
[04:24] <ogra> (and why dont i find *any* message about that change in my inbox)
[04:24] <pitti> ogra: antimony
[04:24] <ogra> pitti, ^^^ lithiium doesnt let me in and i forgot the name again
[04:24] <ogra> ah
[04:25] <mathiaz> soren: ok. So I'd suggest that first we milestone bugs for each release they're relevant.
[04:25] <pitti> https://bugs.edge.launchpad.net/ubuntu/dapper/+nominations
[04:25] <ogra> if we wouldnt have these godammned hashed ssh entries now i could just have looked up the last entry easily in known:hosts ...
[04:25] <pitti> mathiaz: ^ ah, cool
[04:25] <pitti> mathiaz: so, nomination is fine as well
[04:25] <StevenK> ogra: ssh has a mode to edit the known_hosts file...
[04:26] <StevenK> There's a command for it, anyway. I can't remember anything else, sorry. :-(
[04:26] <ogra> StevenK, indeed, but i cant just cat the file to remember a hostname now ...
[04:26] <mathiaz> pitti: well. the reason I'd avoid nomination is that we need to clean up samba bugs first
[04:26] <ogra> StevenK, that was what i remembered as well ... but not the name of the command :P
[04:27] <bddebian> Heya
[04:28] <mathiaz> pitti: ok. we'll use nomination then.
[04:28] <StevenK> ogra: ssh-keygen does it
[04:29] <ogra> StevenK, giving out the hostnames in cleartext ?
[04:29] <ogra> (the manpage didnt mention that)
[04:30] <StevenK> ogra: -F
[04:30] <ogra> ah
[04:30] <ogra> ah, crap i read the manpage of keyscan
[04:30] <ogra> not keygen
[04:31] <StevenK> ogra: Reading is a good skill.
[04:31] <StevenK> ogra: :-P
[04:31] <davmor2> asac: Hobbsee: did you manage to sort out the nm issue?
[04:32] <Hobbsee> davmor2: surprisingly, yes.  we'll call it a heisenbug.
[04:32] <ogra> StevenK, writing as well :P
[04:32] <davmor2> Hobbsee: ?
[04:32] <Hobbsee> davmor2: a few manually bringing evertying down, putting them back up, removing config files, etc.
[04:32] <pitti> lamont: seems that util-linux fix wasn't sufficient; http://launchpadlibrarian.net/9439554/buildlog_ubuntu-gutsy-sparc.debian-installer_20070308ubuntu14_FAILEDTOBUILD.txt.gz
[04:32] <Hobbsee> davmor2: seems to work fine.  but as for what was wrong...no idea
[04:32] <pitti> lamont: it still fails with "sparc64: Unrecognized architecture"
[04:33] <davmor2> oh well glad it's fixed :)
[04:33] <StevenK> I thought all NM issues were heisenbugs?
[04:40] <ogra> hmm, that sabayon changelog isnt very informative
[04:45] <\sh> pitti, as I said, debian has still 5.5.23 and this version has a lot of CVEs ... so 5.5.25 is the version for gutsy to go...if I can resolv the build problems
[04:45] <keescook> \sh: the tomcat security issues have been, from what I can tell, mostly bugs in examples or base files, rather than core functionality.  So, to that end, I suspect just patching the fixes would pretty straight-forward work, assuming the patches are easy to find.  On the other hand, getting a newer version would be a good idea too, as tomcat is relatively old in Debian.
[04:46] <\sh> keescook, well, debian has 5.5.23 and we have 5.5.20
[04:47] <keescook> \sh: I think 5.5.23 is still vuln to a mess of stuff.  upstream is 5.5.25
[04:47] <keescook> or, from another perspective, upstream is 6.0.14 :P
[04:47] <pitti> \sh: right, as I said, I'm generally fine with updating to microreleases of universe at this point
[04:48] <keescook> asac: should I just upload a fixed version of wpasupplicant, just to have the issue closed?
[04:53] <pitti> cjwatson, lamont: FYI, I filed bug 141524 about the sparc d-i FTBFS
[04:53] <ubotu> Launchpad bug 141524 in util-linux "sparc64: sparc64: Unrecognized architecture" [Critical,New]  https://launchpad.net/bugs/141524
[04:55] <pkern> BenC: Was there any progress on slub&fglrx regarding Gutsy's release?
[04:55] <BenC> pkern: point me to a bug report?
[04:56] <lamont> pitti: sigh
[04:56] <lamont> ok
[04:56] <pitti> lamont: do you have an idea about that?
[04:56] <lamont> pitti: please approve sysvinit if you haven't already
[04:56] <pitti> lamont: done some hours ago
[04:56] <BenC> pkern: as far as I know, if it's just a zero alloc warning, it's a non-failure
[04:56] <lamont> pitti: yeah. my idea is that I need to look at it this morning. :-(
[04:56] <cjwatson>   sysvinit | 2.86.ds1-14.1ubuntu28 |         gutsy | source, amd64, hppa, i386, ia64, lpia, powerpc, sparc
[04:56] <pkern> BenC: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/121653 as an example. I pointed you to it in one of the last kernel meetings.
[04:56] <ubotu> Launchpad bug 121653 in linux-source-2.6.22 "[gutsy]  Suspend to Ram does not work on Z61m" [Wishlist,Confirmed] 
[04:56] <mjg59> BenC: It seems to break suspend/resume, though given that it's fglrx it probably does that plenty enough already
[04:57] <pkern> mjg59: Well, people confirm that reverting to SLAB fixes it.
[04:57] <pkern> mjg59: And I have proper suspend/resume with fglrx and 2.6.22/SLAB, for what it's worth.
[04:58] <BenC> pkern: I'd rather not revert to slab
[04:59] <BenC> I'd rather ATI take bugs seriously and fix them
[04:59] <pkern> BenC: You told me that you would contact ATI about that.
[04:59] <asac> keescook: hmm, we hopefully can downgrade to 0.5.8 once i received enough feedback on that. Maybe you can take a look if the code does have the same issue?
[04:59] <pkern> BenC: That's why I ask again.
[04:59] <BenC> pkern: ATI has been contacted (not by me)
[04:59] <asac> keescook: http://ppa.launchpad.net/asac/ubuntu/pool/main/w/wpasupplicant/
[04:59] <pkern> Aye.
[05:00] <soren> Grr.r..
[05:00] <pkern> So kernel rebuilds during Gutsy's lifetime to get working suspend, and let's hope for better free drivers. \:
[05:01] <pkern> Hm, maybe I should try out fglrx 8.41.7...
[05:02] <keescook> asac: 0.5.x does not have the issue.
[05:02] <StevenK> BenC: Do you have some time to discuss modules for virtualbox-ose?
[05:02] <BenC> StevenK: we wont include vbox modules again
[05:02] <keescook> asac: does 0.6.0 really have that many problems?
[05:03] <BenC> StevenK: I did that just before feisty release at the request of support center and we had to yank it after release, which is a really screwed up thing to do
[05:03] <BenC> StevenK: it makes no sense for us to include modules in our packages that can and will change API with userspace
[05:03] <asac> keescook: imo its too unstable ... its an early development snapshot of a new branch that is used to implement new features for network-manager 0.7
[05:04] <StevenK> BenC: At this point, we are shipping virtualbox-ose in Gutsy
[05:04] <asac> keescook: for instance just bringing up the wpa_ctrl sockets sometimes takes seconds ... or even fails completely
[05:04] <asac> keescook: lots of commands i send from nm time out
[05:04] <keescook> asac: wow.  :(
[05:04] <asac> keescook: and it doesn't shutdown cleanly
[05:04] <BenC> StevenK: but then I have to worry about our module conflicting with a newer virtualbox program
[05:04] <asac> keescook: all these issues are not in 0.5.8
[05:05] <BenC> StevenK: this has also caused a lot of headache for vmware
[05:05] <keescook> asac: yeah, seems like a downgrade makes sense then.  I have no attachment to 0.6.  :)
[05:05] <StevenK> BenC: Surely then we can say that the module we build is for the version of virtualbox-ose in Gutsy, and no other.
[05:05] <asac> keescook: i couldn't see it until nm ubuntu11, because before that network-manager just silently failed on these problems ... and it just looked like broken randomness
[05:06] <BenC> StevenK: saying it doesn't help users that have the module installed and are having API conflicts with their userspace program
[05:06] <BenC> StevenK: they don't know these things
[05:06] <mjg59> BenC: We ship a distribution. If people deviate from that, it's their problem.
[05:07] <StevenK> BenC: Agreed. But I'd still like to help the 95% of users that will use the version of virtualbox-ose in Gutsy and be happy that it works
[05:07] <mjg59> Part of the point of providing a distribution is that we provide an integrated userspace and kernel
[05:07] <BenC> I'd love to do that, but we've been bitten too many times in the past trying to provide kernel modules for vm's
[05:08] <StevenK> BenC: The virtualbox-ose module source is in Gutsy too, so we need to make both are updated in lockstep, which is easy at the moment, since they are both in the same source package.
[05:08] <StevenK> we need to make sure, even
[05:08] <pkern> pitti: How is the CD part going? Did the kernel settle? (LP looks like it...)
[05:08] <pitti> pkern: on it, lrm will be published soon, then we need -meta
[05:09] <BenC> StevenK: either way, it can't get done for gutsy even ignoring the actual problems
[05:09] <BenC> StevenK: too late to start dropping things in
[05:09] <janimo> asac: I can upload my network-manager-gnome changes (after beta freeze) if you do not have time and it's ok with you
[05:09] <StevenK> I'm happy to make a virtualbox-ose-modules package that builds the modules and have virtualbpx-ose Recommend/Depend on it
[05:10] <BenC> StevenK: maybe at UDS we can have a forum to discuss these things, go over the past problems, and think of ways to make it not break
[05:10] <asac> janimo: what kind of changes?
[05:10] <janimo> asac: xfce
[05:10] <StevenK> BenC: Speaking of, how long is your flight to Boston, like 3 hours? :-)
[05:10] <asac> janimo: they should be in
[05:10] <BenC> people will install applications like this from outside of our distribution, and we can't break those things
[05:11] <BenC> StevenK: this will be the first time I've been able to take a direct flight to any UDS/Sprint...one hop, 2.5 hours :)
[05:11] <janimo> asac: Lionel commented on the autostart desktop bug that it's still not there (the file shoul dbe in /etc/xdg not /usr/share/gnome/)
[05:11] <StevenK> BenC: Hmph. :-)
[05:11] <janimo> asac: also the libgnomectomy patch is not applied either
[05:12] <asac> bug 95064
[05:12] <ubotu> Launchpad bug 95064 in network-manager-applet "add XFCE to OnlyShowIn" [Medium,Confirmed]  https://launchpad.net/bugs/95064
[05:12] <StevenK> BenC, pitti: What do you think of my virtualbox-ose-modules idea?
[05:12] <BenC> StevenK: you should look at the DKMS package and its hooks
[05:13] <asac> janimo: for me its properly installed in /etc/xdg
[05:13] <StevenK> BenC: I'll keep that in mind, thanks
[05:14] <asac> janimo: strange thing is that it has not been updated ... maybe its marked as a conffile?
[05:14] <janimo> asac: yeah it's a conffile I think. When upgrading it may remain in /usr.share
[05:14] <pitti> StevenK: sorry, I didn't read the entire scrollback; you want to make a working virtualbox-ose-modules for module-assistant?
[05:14] <janimo> asac: IIRC there was a similar issue with gnome-power-manager when we moved the files
[05:15] <StevenK> pitti: Nope, I want to make a virtualbox-ose-modules package that builds the module for i386 and amd64
[05:15] <pitti> StevenK: ehm, -source already exists?
[05:15] <StevenK> pitti: Indeed
[05:15] <lamont> pwd; ./sparc64 uname -m; uname -m
[05:15] <lamont> /home/lamont/gutsy/util-linux-2.13/debian/util-linux/usr/bin
[05:15] <lamont> sparc64
[05:15] <lamont> sparc64
[05:15] <pitti> StevenK: I'm not terribly convinced, since that would mean that we would need to keep them up to date with ABI changes in -security, etc.
[05:15] <lamont> pitti: hrm.
[05:16] <pochu> Since when are we installing Recommended packages by default? Gutsy?
[05:16] <lamont> pochu: ISTR feisty or so
[05:16] <lamont> debian plans to do it for lenny, starting next month, fiww
[05:17] <lamont> fwiw, even
[05:17] <janimo> asac: I remove -P the install n-m-g and the file is in /usr/share hmm
[05:17] <StevenK> pitti: I was plotting setting myself as the Maintainer and such like. I'm happy to update it, I just need someone to bug me
[05:17] <ogra> pitti, hmm, any idea why we have myspell-en-za on *all* CDs regardless of the langpacks etc ?
[05:17] <pochu> lamont: thanks
[05:17] <pitti> ogra: language-support-en dependency
[05:17] <ogra> ah
[05:17] <ogra> thanks
[05:18] <elmo> Package glibc-pic is a virtual package provided by: libc6-pic 2.6.1-1ubuntu4
[05:18] <elmo> You should explicitly select one to install.
[05:18] <pitti> hard to choose...
[05:18] <elmo> orly.  can I pick option a or can I pick option a?  maybe option a ...
[05:18] <Hobbsee> elmo: pick b. duh.
[05:19] <pitti> you can install it or you can choose not to :)
[05:19] <elmo> did apt always do this?  I thought it was smarter than that
[05:19] <thom> no, it really is that dumb
[05:20] <elmo> oh, that's a shame
[05:20] <pitti> BenC: for the records, I'll move linux-ubuntu-modules-2.6.22-12-{rt,ume,xen} to universe, since the corresponding linux-image* are, and they are uninstallable ATM; in the long run we should fix this in the default Section:s, though
[05:20] <pitti> BenC: -rt and -ume are quite clear, but I'm not so sure about -xen; isn't this supposed to be in main?
[05:21] <BenC> pitti: it should be, but I don't get enough feedback on it to know it actually works
[05:21] <lamont> that was theoretically going to be in -11.35
[05:21] <pitti> lamont: very soon, I was told
[05:21] <BenC> lamont: kyle has your fixes in, and it will get uploaded soon
[05:21] <lamont> danke
[05:23] <pitti> lamont: sparc64> hm, so it does work in your installed system, but not in the buildd?
[05:23] <lamont> pitti: faure's gutsy chroot.  testing d-i build now
[05:24] <lamont> well, momentarily anyway
[05:26] <LaserJock> mvo: ping regarding g-a-i
[05:27] <mvo> LaserJock: pong
[05:28] <ScottK> pitti: If you are archive admining today, Bug #139037 is available should be feel like stomping something out of the archive.
[05:28] <ubotu> Launchpad bug 139037 in viewcvs "Please remove viewcvs source from Gutsy" [Wishlist,Confirmed]  https://launchpad.net/bugs/139037
[05:29] <pitti> ScottK: oh, erk; normally I would, but I'm in release madness mode
[05:29] <ScottK> Ah.  No rush.
[05:29] <pitti> ScottK: but yeah, removals are always a pleasure :), looking
[05:30] <ogra> WOAH !
[05:30] <ogra> gnome-user-guide is 13M ???
[05:30] <pitti> o_O?
[05:31] <pitti> ogra: yes, that was on my mental list of 'packages to check', too
[05:31] <lamont> ogra: still tiny compared to oo.o :-)
[05:31] <cjwatson> grew by 5MB+ since feisty
[05:31] <pitti> ogra: mainly due to translated screenshots and such
[05:31] <pitti> and by 2 MB since tribe 5
[05:31] <ogra> lamont, well, it would be ~50% of my 30M oversizedness of edubuntu
[05:31] <cjwatson> it's already bzip2ed
[05:31] <pitti> throwing out documentation would be really evil, though
[05:31] <ogra> well, indeed
[05:32] <ogra> does anyone know if it uses pngcrush already ?
[05:32] <ogra> (assuming the schots are png)
[05:32] <ogra> *shots
[05:32] <lamont> I hear mp3 compresses better than bz2. :-)
[05:33] <pitti> ogra: TBH, I'd really consider throwing out f-spot and tomboy, together with the mono stack; that's a relatively unevil slaughter IMHO (but just my 2c)
[05:33] <ogra> lol
[05:33] <jdong> lamont: AAC's where it's at :D
[05:33] <ogra> pitti, ++
[05:33] <ogra> even though i love my f-spot ...
[05:33] <pitti> ogra: f-spot might not be the primary app for schools, and tomboy is something for fans, I guess
[05:33] <StevenK> pitti: You can throw out tomboy? It is a default Gnome app
[05:33] <ogra> but i'm fine using g-a-i :)
[05:33] <pitti> StevenK: in edubuntu, I mean
[05:33] <StevenK> Ah, right
[05:34] <jdong> have you thrown out all the games yet? :D
[05:34] <pitti> ogra: just a suggestion if you need to make space under the gun
[05:34] <ogra> StevenK, we can do what we want :) its opensource .... we can even change the CODE ! :)
[05:34] <StevenK> ogra: Oh, gasp. :-P
[05:34] <cjwatson> I'm off for a while, since the publisher is churning on manual and CDs will build after that; Canonical people have my number if it's urgent
[05:34] <ogra> pitti, yeah, mono would be the best i guess
[05:35] <jdong> do you know that life is ....
[05:35] <jdong> *sigh* my french sucks
[05:35] <seb128> pitti: tomboy is not really "something for fans"
[05:35] <ogra> heh
[05:36] <seb128> pitti: it's a note taker which is fairly common usage
[05:36] <pitti> seb128: well, I would prefer killing tomboy over killing gnome documentation
[05:36] <ogra> erm
[05:37] <ogra> pitti, edubuntu doesnt have any mono apps ... we moved them in feisty to the addon
[05:37] <ogra> :/
[05:38] <ogra> i guess i have to move the remaining edu apps first and see whats left to downsize :/
[05:38] <ogra> will be a pretty spare desktop on the server defautl install
[05:38] <lamont> pitti: scratching my head now...
[05:38] <jdong> out of curiousity, anyone checked how much space would be freed if the LiveCD were lzma'ed?
[05:38] <lamont> debian-installer_20070308ubuntu14_sparc.changes
[05:38] <lamont> debian-installer_20070308ubuntu14_sparc.deb
[05:38] <lamont> in a fresh gutsy chroot on faure
[05:38] <pitti> jdong: yes, IIRC fabbione did that a while ago; it was quite amazing
[05:38] <ogra> ogra@laptop:~/packages/edubuntu-meta-1.44$ /home/ogra2/getpkgsize scribus
[05:38] <pitti> lamont: boggle
[05:38] <ogra> scribus:  8968k
[05:38] <ogra> total: 8M
[05:38] <ogra> aha !
[05:39] <jdong> printk: I would imagine so... but at a great cost to the time invovled to build a livecd
[05:39] <jdong> err... pitti
[05:39] <pitti> ScottK: done
[05:39] <ScottK> pitti: Thanks.
[05:40] <pitti> jdong: that's mostly irrelevant, I think; the runtime penalty matters more
[05:40] <jdong> pitti: it has a runtime penality on modern hardware?
[05:41] <pitti> jdong: I don't have numbers, I just faintly remember some email conversation about that
[05:41] <pitti> jdong: which doesn't mean that it won't happen, it was just mentioned
[05:41] <jdong> I was under the impression lzma decompmressed loads faster than bzip2 and only marginally slower than gzip...
[05:41] <jdong> just compression speed is horrid
[05:41] <slytherin> Does anyone other than me thinks that libtheora 1.0beta (if released today) is worth freeze exception?
[05:41] <highvoltage> there's also a wiki page comparing decompression speeds for ubuntu iso's
[05:42] <jdong> *searches*
[05:42] <pitti> slytherin: it most likely changes ABI/API, which would rule it out solidly
[05:42] <jdong> I agree with pitti... it will have to mess with a whole ffmpeg/mplayer stack too
[05:42] <slytherin> pitti: AFAIK, it doesn't do either, but then I am not very sure.
[05:42] <highvoltage> jdong: it doesn't have lzma on there, but it might be useful: https://wiki.ubuntu.com/Dpkg7Zip
[05:43] <lamont> pitti: I'm tempted to throw it back through the chompers one more time, but I'm 99% certain that'll fail too.
[05:43] <pitti> slytherin: there are tons of rdepends, so only if it keeps soname and API we can even consider it
[05:43] <lamont> OTOH, it only takes 5 min to die.
[05:43] <pitti> lamont: can do, but it already failed similarly yesterday
[05:44] <lamont> exactly
[05:44] <highvoltage> jdong: in the results, bzip2 even uncompresses faster an gzip!
[05:44] <slytherin> pitti: Ok. I will upload packages to my ppa once it is released, do some testing and then file a bug.
[05:44] <pitti> slytherin: thanks
[05:44] <lamont> hence the head scratching
[05:44] <lamont> pitti: don't give it back
[05:45] <slytherin> pitti: According to MikeS on #theora, alpha8 broke soname which they are fixing with beta.
[05:45] <jdong> highvoltage: the results seem a bit oddly inconsistent....
[05:45] <pitti> slytherin: wow, they seem to be really disciplined and distro friendy
[05:45] <jdong> highvoltage: they do not agree with my current experience with LZMA (which I use for all my backups...)
[05:46] <jdong> oh well, that's a gutsy+big_number topic, unimportant and OT now
[05:46] <highvoltage> jdong: hmmm, perhaps you should summarize your findings and post them to ubuntu-devel-discuss
[05:47] <highvoltage> jdong: indeed. I do agree that better compression would be nice for the Ubuntu packages
[05:47] <jdong> highvoltage: look at jace2kv's test near bottom.
[05:48] <jdong> highvoltage: it produces wildly different decomp results, more consistent with my experience
[05:48] <StevenK> jdong: It isn't as predictable as gzip?
[05:48] <jdong> highvoltage: it leads me to question the RAM/CPU limitations of the original tester, which is an important factor to consider though
[05:48] <pitti> calc: just for planning, do you have a realistic ETA for a new OO.o?
[05:48] <jdong> StevenK: it is much more CPU heavy to decompress, and RAM-heavy to compress, and gzip is low-cost both ways
[05:49] <jdong> so yes, depending on system specs the comparative performance is lot less predictable
[05:49] <jdong> but as we move into recommending larger amounts of RAM, LZMA becomes more and more viable
[05:49] <highvoltage> jdong: yes, indeed. how does 7zip's compression compare to LZMA?
[05:49] <jdong> highvoltage: same algorithm....
[05:49] <highvoltage> jdong: aaaaah
[05:50] <jdong> highvoltage: currently p7zip has multithreading over lzma, as lzma's release ver in Ubuntu is outdated
[05:50] <pitti> lamont: would it help to try it on the other buildd?
[05:50] <jdong> highvoltage: creating a tar.7z on an 8-core system is phenomenal!
[05:50] <highvoltage> jdong: I can imagine!
[05:50] <jdong> :)
[05:50] <lamont> pitti: nope.  it's the buildd
[05:50] <lamont> sparc32 sparc64 ls
[05:50] <lamont> sparc64: sparc64: Unrecognized architecture
[05:51] <jdong> highvoltage: 7z allows use of different compressors too; some are better for binaries and others are better for text. it affords more flexibility. 7z is like a container format :)
[05:51] <jdong> highvoltage: its disadvantage is that the default commandset with p7zip is vastly not-gzip/bzip-like....
[05:51] <jdong> which can be fixed easily with wrapper binaries
[05:51] <jdong> that's on my todo list of experimenting
[05:52] <highvoltage> jdong: that's very cool
[05:53] <highvoltage> jdong: perhaps you should post your findings on the whiteboard of https://launchpad.net/distros/ubuntu/+spec/dpkg-7zip too, for when it comes under discussion again in a future UDS
[05:55] <lamont> pitti: developing the fix now
[05:59] <pitti> lamont: you rock
[06:01] <pitti> ogra: I'm going to trigger new CD builds in some 20 minutes; do you still need seed changes?
[06:02] <ogra> pitti, not today anymore. i'll fiddle over the weekend ... build one with the recent -meta so i have a base for tomorrow
[06:02] <pitti> ogra: yep, I will
[06:02] <pochu> pitti: providing it's your archive day, could you take a look at bug 140426? It was already synced, but it failed due to "Unable to find gnome-build_0.2.0.orig.tar.gz in upload or distribution."
[06:02] <ubotu> Launchpad bug 140426 in gnome-build "[UVFe]  Please sync gnome-build (universe) 0.2.0-2 from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/140426
[06:03] <pitti> pochu: I don't think that this bug changed since then, but I'll try
[06:03] <pochu> pitti: thanks. seb128's log said it was downloading from librarian, but I got a message from archive@u.c rejecting it...
[06:04] <pochu> pitti: if you can't do anything, I could do a fakesync :)
[06:05] <pitti>   - <gnome-build_0.2.0.orig.tar.gz: already in distro - downloading from librarian>
[06:05] <pitti> lying!
[06:05] <pochu> That's what seb had, but it didn't seem to work...
[06:05] <pochu> bug?
[06:05] <pitti> pochu: it might be that it is in some ppa
[06:05] <StevenK> pitti: sync-source.py needs a penatly card
[06:05] <pochu> pitti: mine :)
[06:06] <pochu> pitti: no, it isn't in mine.
[06:06] <pitti> elmo: gnome-build is trying to override libgbf-1-dev_0.2.0-1ubuntu1~ppa2 without -f/--force.
[06:06] <pitti> *nnnng*
[06:07] <pitti> pochu: yeah, just do a sync with my script or so
[06:07] <pitti> http://people.ubuntu.com/~pitti/scripts/syncpackage
[06:07] <pochu> isn't it in ubuntu-dev-tools?
[06:07] <pitti> pochu: nope, we shouldn't really use it widely
[06:07] <StevenK> I hope not
[06:08] <pochu> ah
[06:08] <StevenK> It's special, you can only use it when pitti Says So.
[06:08] <bddebian> heh
[06:11] <pochu> Would you like to use the current signature? [Yn] 
[06:11] <Hobbsee> StevenK: that's such a jean-ism....
[06:13] <lamont> sparc32 sparc64 -B ls
[06:13] <lamont> audioctl-1.3  debian  elftoaout-2.3  prtconf-1.3  sparc32-1.1  src
[06:13] <lamont> well.. that was only slightly painful
[06:13] <StevenK> Only slightly?
[06:13] <lamont> the "why does it work there and not here" issue
[06:13] <pochu> pitti: current, or mine? note that I don't have upload rights...
[06:14] <pitti> pochu: current is from the DD, so that won't help you either
[06:14] <pitti> pochu: oh, then you need to find someone who can sync this for you
[06:14] <pitti> lamont: \o/
[06:14] <stgraber> pitti: Any idea when first Beta candidates will be out ?
[06:15] <pitti> stgraber: I'll trigger new CDs in some 15 minutes
[06:15] <pochu> pitti: that should be easy... any volunteer? :-)
[06:15] <pitti> stgraber: these will definitively not be the beta images, but they should be good for some testing
[06:15] <pitti> stgraber: we'll get a new kernel, lrm, ubiquity, and langpacks by Monday, so Monday evening we should have some good CDs
[06:16] <stgraber> pitti: ok, before you add them on the tracker just ping me. I enabled e-mail notification last night and would like to check that everything is going fine
[06:16] <pitti> bdmurray: do we have a CD testing assignment plan?
[06:16] <pitti> stgraber: yessir
[06:16] <pitti> stgraber: do you think we should add the ones from this evening?
[06:17] <Hobbsee> pitti: you should always ask if it's a decent plan.
[06:17] <Hobbsee> not just if a plan exists.
[06:18] <lamont> +   } else if (!strcmp(p,"sparc64") {
[06:18] <lamont> +       options |= ADDR_LIMIT_32BIT;
[06:21] <pitti> Hobbsee: "planning is replacing coincidence with mistake"
[06:21] <Hobbsee> pitti: haha
[06:21] <Keybuk> pitti: I would like to have an SRU approved
[06:21] <stgraber> pitti: if they are bootable + installable why not, it'd at least help debugging the eventual bugs I introduced in the tracker :)
[06:22] <pitti> CD builds triggered \o/
[06:22] <pitti> *phew*, that took long
[06:22] <pitti> Keybuk: sure, #?
[06:22] <evand> hooray
[06:22] <Keybuk> pitti: Bug #141034
[06:22] <ubotu> Launchpad bug 141034 in upstart "upstart turns machines into a scene from 'Dead Rising' " [Critical,Confirmed]  https://launchpad.net/bugs/141034
[06:22] <jdong> good title
[06:22] <kylem> a bit melodramatic
[06:23] <stgraber> pitti: and as Xorg and Compiz should stay the same we can at least still test that
[06:23] <jdong> Upstart Kills Children
[06:23] <pitti> stgraber: right, as well as gnome 2.20, n-m etc.
[06:23] <pitti> jdong: kittens
[06:24] <pitti> Keybuk: I blame upstream!
[06:27] <pitti> Keybuk: bug updated
[06:29] <bryce> morning
[06:30] <seb128> pochu, pitti: that's likely because somebody has the orig in its ppa archive which is soyuz bug #141019
[06:30] <ubotu> Launchpad bug 141019 in soyuz "sync-source should not compare to ppa versions" [High,Confirmed]  https://launchpad.net/bugs/141019
[06:30] <lamont> dear upgrade manager.  if there are nfs mounts extant on the machine, please install nfs-utils prior to upgrading mount, since mount will fail in preinst.  kthxbye
[06:30] <seb128> pochu: you need to do a fake sync for now
[06:31] <lamont> pitti/Mithrandir/slangasek: trying to figure out if we really don't care about that case....
[06:32] <pochu> seb128: and will that bug need to wait for 1 month before being deployed? that sounds scary :)
[06:32] <pochu> at least you won't do too much syncs at this point of the development cycle
[06:33] <calc> pitti: i got the first test build done which primed my ccache, looking into trimming down the depends now
[06:33] <seb128> pochu: fixes can be applied to production and there is not so many ppa conflicting with the archive new versions for syncs at the moment
[06:34] <pitti> calc: thanks! I'll try to get online again tonight when I'm back
[06:34] <pochu> seb128: true that
[06:35] <pitti> stgraber: http://cdimage.ubuntu.com/daily/20070921.1/
[06:35] <seb128> pochu: google is your friend ;)
[06:35] <pitti> stgraber: they are slightly oversized, but if you have a burner and media that cope with that (or use DVDs or vmware) it should do
[06:35] <pitti> stgraber: the lives should fit; for alternates we need to wait for the new OO.o
[06:37] <cjwatson> lamont: dear lamont, I suggest filing a bug as mvo might not notice random complaints on IRC
[06:37] <lamont> cjwatson: will do
[06:37] <lamont> upgrade-manager is the name?
[06:37] <cjwatson> lamont: that sort of thing is eminently handlable in update-manager, AFAIK
[06:37] <cjwatson> update-manager
[06:37] <lamont> update-manager.  check
[06:38] <jdong> stupid question of the day: is amd64 gutsy tickless or not?
[06:38] <stgraber> pitti: ok, I'll make sure testers have a look at the iso size and use DVD (I personally always do)
[06:38] <Keybuk> pitti: uploaded to -proposed
[06:38] <pitti> stgraber: so you'll add the first set of images yourself and test your email notification?
[06:39] <stgraber> pitti: yes
[06:40] <stgraber> pitti: what are the next ones to be built ?
[06:40] <pitti> stgraber: kubuntu should be ready as well
[06:40] <pitti> http://cdimage.ubuntu.com/kubuntu/daily/20070921.1/
[06:41] <pitti> http://cdimage.ubuntu.com/edubuntu/daily/20070921.1/
[06:41] <pitti> ogra: ^ FYI (heavily oversized i386, though)
[06:42] <stgraber> ok, I'll wait till we have all of them (or at least a good part of them) so I can check that users receive only one mail and not one/ISO
[06:42] <pitti> stgraber, ogra: sorry, ignore edubuntu .1; edubuntu will be 21.2
[06:42] <stgraber> ok
[06:43] <pitti> lamont: btw, when you upload this, can you use the magic "LP: #141524" syntax in the changelog?
[06:46] <lamont> pitti: it's in the changelog.  OTOH, it's in the entry for -6, not for -6.1... should I add it there too?
[06:46] <lamont> er, s/6.1/6ubuntu1/
[06:46] <pitti> lamont: as long as you use -v properly (*hint* *hint* :) ), having it in -6 is fine
[06:46] <lamont> does dpkg-buildpackage take -v?
[06:47] <pitti> lamont: yep
[06:49] <Vegar> why doesn't modprobe find the modules in my custom linux-ubuntu-modules package?
[06:49] <lamont>  util-linux (2.13-6) unstable; urgency=low
[06:49] <lamont>  .
[06:49] <lamont>    * sparc-utils 'sparc64' binary sets ADDR_LIMIT_32BIT.  Closes: LP#141524
[06:50] <zul> lamont: (LP: #)
[06:50] <pitti> lamont: not quite, but you can close it manually
[06:50] <pitti> lamont: LP: #1234
[06:50] <pitti> lamont: or you tack it to the ubuntu changelog
[06:50] <lamont> ah, so s/Closes/LP/ in my fingers, and I'm good.
[06:50] <lamont> pitti: that'd mean retagging and everything.. :-(
[06:51] <pitti> lamont: nevermind then
[06:51] <lamont> I'll close it manualy
[06:51] <lamont> and remember the syntax next time
[06:52] <lamont> uploaded, and debian upload in progress
[06:53] <pitti> stgraber, ogra: http://cdimage.ubuntu.com/edubuntu/daily/20070921.2/
[06:54] <mvo> lamont: hu?
[06:55] <lamont> mvo: util-linux 2.13 dropped nfs support (now found in nfs-utils)
[06:55] <lamont> rather than sucking in portmap and adding 5 listening ports to grandma's machine, we kinda ignored the dependency-for-a-release rule and made nfs-utils a Suggestion
[06:55] <mvo> lamont: and the upgrade path is to automatically install nfs-utils if util-linux is installed?
[06:55] <slangasek> iwj: hey now, the part of that bug in PAM is fixed, it's not my fault that shadow upstream /also/ blocks SIGINT :)
[06:56] <slangasek> (and anyway, the log for Debian bug #1708 has gotten horribly mangled by spam over the years...)
[06:56] <ubotu> Debian bug 1708 in libpam0g "`passwd' not interruptible when invoked by `adduser'" [Normal,Fixed]  http://bugs.debian.org/1708
[06:56] <pitti> good morning slangasek
[06:56] <slangasek> pitti: morning
[06:56] <lamont> so, if /proc/mounts exists, and has nfs mounts listed in it, and nfs-utils is not currently installed, mount's preinst fails (intentionally)
[06:56] <slangasek> jdong: no, amd64 gutsy isn't tickless AFAICS; I'd been hoping :)
[06:56] <lamont> so the upgrade path is "if that preinst condition will be met, make sure that nfs-utils is installed prior to the dpkg run that installs mount"
[06:57] <lamont> mvo: ^^
[06:57] <lamont> mvo: and I'll toss all  that in a bug report after lunch.
[06:57] <iwj> slangasek: Well, yes :-).  But I still count it as my oldest open bug ...
[06:57] <lamont> our hand waving excuse was that if you are old enough to use NFS mounts, you're old enough to understand the error message. :-)
[06:58] <mvo> lamont: that can be handled via update-manager
[06:58] <lamont> mvo: hence the bug for me to file against update-manager after lunch. :-)
[06:58] <cjwatson> slangasek: it's not often that I think the Launchpad bug tracking system is better than debbugs, of course ;-), but I have to admit that the ability to have multiple "tasks" on a single bug for different packages is rather useful here
[06:58] <lamont> "mount Pre-Depends: nfs-utils [iff nfs mounts present in /proc/mounts] "
[06:58] <mvo> lamont: heh, ok .) please send me the bugnumber, once you have it
[06:58] <lamont> now we just need a parser that'll handle that. :-)
[06:59] <iwj> IWBNI debbugs's clones at least made links to each other ...
[06:59] <lamont> mvo: will do
[06:59] <cjwatson> they do, but only in the entry summarising the control log
[06:59] <mvo> lamont: but I think the postinst should not fail, but create a debconf notice or something instead, failing maintainer scripts are evil
[06:59] <cjwatson> Bug 1708 cloned as bug 439769. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Mon, 27 Aug 2007 09:57:03 GMT) Full text and rfc822 format available.
[06:59] <ubotu> Launchpad bug 1708 in malone "Malone should know how to create bug reports based on analysis of CVE reports" [Medium,Confirmed]  https://launchpad.net/bugs/1708
[06:59] <cjwatson> like that
[06:59] <cjwatson> sigh, shaddup ubotu
[06:59] <lamont> mvo: removing the ability to mount /usr without letting the user fix it first is also evil
[07:00] <iwj> cjwatson: Yes, but I meant at the top somewhere.
[07:00] <cjwatson> iwj: *nod*
[07:00] <iwj> In a way that made it possible to unlink and relink it I suppose.
[07:00] <pitti> stgraber: http://cdimage.ubuntu.com/daily-live/20070921.1/
[07:00] <lamont> mvo: it's even more special if the machine has nfsroot
[07:00] <cjwatson> just needs entries in .summary for it I guess
[07:01] <pitti> stgraber: barely within the size limit :)
[07:01] <cjwatson> and due care to create and remove them at all the right points ... I think I've been away from debbugs hacking for too long
[07:01] <iwj> TBH I don't think this is very important.  The current situation is liveable unless like me you want to maintain your submitter-of-old-open-bugs kudos :-).
[07:01] <mvo> lamont: presumably /usr is mounted during the upgrade (and / too) - so its more about the next reboot. but its your package, so its your decision :)
[07:02] <iwj> lamont: Are you the person to talk to about hppa ?
[07:02] <lamont> iwj: yep
[07:02] <iwj> glibc FTBFS ...
[07:02] <lamont> yeah.
[07:02] <iwj> Oh, so long as you know about it.
[07:02] <lamont> patch extant, the machine it's on has the breaker off while our glibc hacker hacks electrical wiring.
[07:02] <lamont> that'd be a 2.7 feature that snuck into 2.6.1
[07:03] <lamont> (private futexes)
[07:03] <iwj> I don't want to know.
[07:03] <iwj> glibc is like something out of a Charlie Stross novel.
[07:03] <lamont> we expect to get the patch in the next 36 hours or so.
[07:03] <lamont> and, uh, then we'll be asking for a beta exception...
[07:03] <stgraber> pitti: :)
[07:03] <iwj> I wonder if I should email Charlie Stross and suggest he hint that Drepper is a demon, or something.
[07:04] <pitti> stgraber: server is building, then all the alternates are complete
[07:04] <cjwatson> iwj: you still have the oldest open bug though
[07:04] <lamont> tuckerize drepper... hrm...
[07:04] <cjwatson> (2297)
[07:04] <iwj> Ooh, yes.  That one won't be fixed any time soon.
[07:04] <mvo> pitti, slangasek: could you please review/accept my compiz upload? fixes a bug in the wrapper script that makes it unusable on a lot of nvidia cards
[07:05] <pitti> mvo: already at it
[07:06] <mvo> pitti: rock, thanks!
[07:07] <pitti> stgraber: the other lives are on the way, should all be 21.1 (I just have to leave soon)
[07:07] <mvo> pitti: unfortunately it changes a bunch of indentions too, that is a upstream import, I could git cherry pick the actual fix if you are more comfortable with that
[07:08] <stgraber> pitti: ok, I'll check and as soon as they are on cdimage will add them on the tracker
[07:08] <pitti> stgraber: http://cdimage.ubuntu.com/ubuntu-server/daily/20070921.1/
[07:08] <lamont> where do the uploads-pending-approval (due to freeze) show up?
[07:08] <pitti> lamont: http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/
[07:09] <pitti> lamont: slightly behind reality (only updated every 5 minutes or so)
[07:09] <lamont> not to be confused with https://edge.launchpad.net/ubuntu/gutsy/+queue
[07:09] <pitti> lamont: that works, too
[07:09] <pitti> lamont: that's actually up-to-date, you just can't download the pacakges there
[07:10] <jdong> slangasek: aww that's too bad. it really ticks me off. ;-)
[07:10] <lamont> pitti: I don't see unapproved source there..
[07:11] <pitti> https://edge.launchpad.net/ubuntu/gutsy/+queue?queue_state=1&queue_text=
[07:11] <pitti> lamont: just change state to 'unapproved' and 'update'
[07:11] <pitti> lamont: btw, do you have accept/reject buttons on that +queue page? I do, and they actually work now
[07:11] <lamont> ah. ok. unapproved isn't one of the pulldown options
[07:11] <pitti> lamont: for me it is
[07:12] <pitti> lamont: might be my ~ubuntu-release badge
[07:12] <lamont> https://edge.launchpad.net/ubuntu/gutsy/+queue?queue_state=unapproved&queue_text= gets me to the same page as without that
[07:12] <lamont> state=1 gets me EPERM
[07:12] <lamont> I bet it is your -release badge
[07:14] <slangasek> cjwatson: well, you can assign a debbugs bug to two packages of course, you just only get one closure state ;)
[07:14] <cjwatson> slangasek: yeah, it's the lack of independent state that's a problem
[07:15] <cjwatson> it wouldn't necessarily be that hard to fix nowadays, just tedioius
[07:15] <cjwatson> tedious
[07:15] <cjwatson> lamont: it's his -archive badge
[07:16] <cjwatson> jdong: it doesn't appear that the option even exists; it's not like it's CONFIG_NO_HZ=n, it's just not there
[07:16] <pitti> mvo: the effective diff is just GL_MAX_3D_TEXTURE_SIZE  GL_MAX_TEXTURE_SIZE from what I can see; right?
[07:16] <slangasek> cjwatson: indeed it's not; amd64 tickless isn't merged yet
[07:17] <cjwatson> figures
[07:19] <mvo> pitti: yes, that is the crucial bit
[07:21] <lamont> mvo: #141559
[07:21] <lamont> and I'm going to mark several util-linux bugs as dups of that one...
[07:23] <lamont> mvo: and I'm not sure but what I should remove the "if Debian = $DISTRO" check
[07:24] <lamont> can someone explain bug#131897 to me?
[07:30] <evand> yay, no unionfs issues in the latest daily live cd here
[07:30] <kylem> do you miss them? i can readd them if you'd like
[07:31] <evand> haha, please do not
[07:31] <Keybuk> is that like "please upload more, the CDs are undersized" ?
[07:32] <evand> we need an excuse to go to blu-ray anyway
[07:33] <pitti> Keybuk: alternates are still oversized, but the next OO.o will sort that out
[07:33] <pitti> anyway, really gotta run now
[07:33] <pitti> my part for today is mostly done, things are looking good now
[07:35] <lamont> "fix released" ==> uploaded/in-the-archive, yes?
[07:35] <cjwatson> http://launchpadlibrarian.net/9443097/buildlog_ubuntu-gutsy-ia64.debian-installer_20070308ubuntu14_FAILEDTOBUILD.txt.gz blink
[07:35] <cjwatson> iwj: ^-- above looks like a dpkg segfault? could be transient ...
[07:38] <StevenK> Hmph. Damn it, postfix, the socket exists, stop saying it doesn't!
[07:39] <lamont> heh
[07:39] <lamont> StevenK: but does it exist in the chroot...;)(
[07:39] <StevenK> DOH
[07:40] <iwj> cjwatson: Looking ...
[07:40] <cjwatson> iwj: I note that http://launchpadlibrarian.net/9420533/buildlog_ubuntu-gutsy-ia64.dpkg_1.14.5ubuntu15_FULLYBUILT.txt.gz mentions several warnings (implicit declaration of m_malloc etc.) which look like they could break ia64
[07:40] <StevenK> I keep forgetting exactly how paranoid Weitse *is*.
[07:40] <cjwatson> hard to say much more than that
[07:41] <lamont> StevenK: actually, Wietse says that distros should not ship chroot-by-default
[07:41] <lamont> I differ.
[07:41] <StevenK> Surely changing chroot from - to n for lmtp should fix it
[07:42] <lamont> see http://bugs.debian.org/151692 :)
[07:42] <StevenK> Oops, wrong column
[07:42] <iwj> cjwatson: Oh, ffs.
[07:42] <iwj> cjwatson: I'd forgotten that dpkg has had -Werror removed.  That's almost certainly it.
[07:42] <iwj> But err that would make dpkg 1.14.5ubuntu15 not work _at all_ on any 64bit arch.
[07:43] <StevenK> Yay. Now I get a cyrus error
[07:43] <iwj> cjwatson: Is there any way to get something resembling more information ?
[07:44] <cjwatson> iwj: I don't believe that's true
[07:44] <cjwatson> cjwatson@cittagazze:~ $ cat t.c
[07:44] <cjwatson> #include <stdlib.h>
[07:44] <cjwatson> #include <stdio.h>
[07:44] <cjwatson> int main() { printf("%p\n", malloc(8)); return 0; }
[07:44] <cjwatson> cjwatson@cittagazze:~ $ make t
[07:44] <cjwatson> cc     t.c   -o t
[07:44] <cjwatson> cjwatson@cittagazze:~ $ ./t
[07:44] <cjwatson> 0x601010
[07:44] <lamont> am I allowed to say dpkg --status inside a preinst?
[07:44] <cjwatson> iwj: cittagazze is amd64
[07:45] <iwj> lamont: Yes but most people who think they want that are making a mistake.
[07:45] <lamont> heh.
[07:45] <iwj> lamont: So why do you think you want to ? :-)
[07:45] <cjwatson> iwj: elmo (or somebody else in IS) might be able to help but it depends whether it's reproducible
[07:45] <lamont> I need to know if nfs-common is installed, or will be installed in this run
[07:45] <iwj> lamont: You can't find out the latter at all.
[07:45] <lamont> understood
[07:45] <cjwatson> Mithrandir: would you mind giving back debian-installer on ia64 so that we can see if this is reproducible?
[07:45] <lamont> hence just the former
[07:46] <iwj> Eg,   dpkg -i your.deb nfs-common.deb    and nothing has worked out yet what nfs-common.deb is.
[07:46] <lamont> cjwatson: ia64 is the arch where that will kill you.  amd64/alpha will "kill you sometime later"
[07:46] <iwj> Why do you need to know ?
[07:46] <cjwatson> iwj: did the dpkg code in question change recently?
[07:46] <lamont> iwj: so i can reliably fail in preinst if it's not there
[07:46] <lamont> based on other conditions
[07:46] <iwj> lamont: Go on ...
[07:46] <cjwatson> lamont: yeah, that was my recollection
[07:46] <lamont> iwj: see LP #141559
[07:46] <iwj> cjwatson: Oh, yes.
[07:46] <ubotu> Launchpad bug 141559 in update-manager "update-manager needs to handle mount/nfs-common transition for gutsy" [Undecided,New]  https://launchpad.net/bugs/141559
[07:46] <cjwatson> lamont: "is installed" -> can you not just look for a file it installs?
[07:47] <lamont> and then mix that with debian #443466
[07:47] <ubotu> Debian bug 443466 in mount "mount: upgrade fails if nfs-common is in removed but not purged" [Normal,Open]  http://bugs.debian.org/443466
[07:47] <lamont> cjwatson: I do
[07:47] <lamont> the debian bug is the one that's my current annoyance
[07:47] <iwj> lamont: Do you need nfs-common to be unpacked or installed ?
[07:48] <lamont> cjwatson: wrt int->ptr: ia64 always has non-zero bits in the top 32, alpha/amd64 generally happen to have zeros there for most apps for a long time into the boot.
[07:48] <lamont> iwj: unpacked and installed some time before the end of this dpkg run
[07:48] <iwj> lamont: Of course things you do in your preinst won't arrange for the package to be actually selected for installation so I take it you have something else to do with that ?
[07:48] <lamont> I have no need for the bits, but don't want to leave the machine hosed if it reboots
[07:48] <iwj> lamont: You can't find that out either.
[07:49] <iwj> lamont: ia64> Right.  So if I fail to declare a function returning void* on ia64 it should crash every time ?
[07:49] <lamont> iwj: that's why the preinst is basically saying "if you have nfs mounts in /proc/mounts, and no /sbin/mount.nfs, then die until you do".
[07:50] <lamont> OTOH, no nfs-common in a chroot on a machine with nfs mounts is perfectly fine, and I need to distinguish that case.
[07:50] <iwj> lamont: /sbin/mount.nfs is from nfs-common, right ?
[07:50] <lamont> yes
[07:50] <lamont> iwj: guaranteed.
[07:50] <iwj> lamont: So looking for it will tell you whether it's currently unpacked but it won't tell you much about whether it will end up configured.
[07:50] <iwj> lamont: guaranteed> You mean re my ia64 crash ?
[07:50] <lamont> iwj: that's fine for this round, I think
[07:51] <iwj> lamont: OK, then that's probably the right test.  I'll be a damn sight faster than dpkg --status too.
[07:51] <cjwatson> iwj: lamont has a horrible sbuild hack in Debian that makes anything that does that fail to build on ia64 regardless of -Werror
[07:51] <lamont> re pointers, see http://wiki.debian.org/ImplicitPointerConversions
[07:51] <cjwatson> (by log grepping)
[07:52] <lamont> see the ia64 build log for museek+_0.1.13+svn.20070906.r740-1 on buildd.debian.org, for an example of said hack
[07:52] <lamont> the actual code parsing the log is found on that wiki page
[07:52] <iwj> cjwatson: So presumably this bug can't be in dpkg ubuntu15 then.  And the coredump must be something else.
[07:52] <cjwatson> iwj: it can because this grotty sbuild hack is only in Debian not Ubuntu
[07:52] <lamont> iwj: so how do I tell if a package is removed vs isntalled?
[07:52] <cjwatson> AFAIK it triggers on gcc warnings that dpkg ubuntu15 is emitting
[07:53] <iwj> lamont: You're talking about mount.nfs still ?  If it's removed err it's not there.
[07:53] <lamont> cjwatson: we should put the hack into ubuntu/ia64 as well, IMO
[07:53] <cjwatson> iwj: we might have a job building the fixed dpkg if ubuntu15 segfaults all the time though; might need infinity's help there
[07:53] <cjwatson> lamont: yeah
[07:53] <cjwatson> (but I can't help)
[07:53] <iwj> cjwatson: that failure log shows dpkg ubuntu15 not segfaulting, which is inconsistent with this theory as developed so far.
[07:54] <cjwatson> iwj: OIC. Is there some possibility that it could only segfault in some uses? it only seems to happen when it starts unpacking udebs
[07:54] <iwj> cjwatson: It seems unlikely to me.
[07:55] <cjwatson> hmm. Well hopefully a give-back will tell us if it's reproducible or not and then maybe it can be reproduced on halley
[07:55] <cjwatson> anyway, really dinnertime
[07:55] <lamont> iwj: the three states I need to distinguish for nfs-using systems (for a chroot) are: 1) nfs-common not present, 2) nfs-common present (removed), and 3) /sbin/mount.nfs extant
[07:55] <iwj> I think the right answer is to fix the bug, which is definitely a bug and trivial to fix (missing #include), and then see if d-i builds properly.
[07:55] <lamont> #2 is currently a false positive
[07:55] <lamont> ../../lib/tarfn.c:64: warning: implicit declaration of function 'm_malloc'
[07:55] <lamont> ../../lib/tarfn.c:64: warning: assignment makes pointer from integer without a cast
[07:55] <iwj> If it does we can say "oh, good" and if not we have a reproduceable thing we can investigate.
[07:55] <lamont> fatal guaranteed. every time on ia64
[07:56] <lamont> StoC and TarExtractor  will kill in ...15
[07:56] <iwj> lamont: That log however shows ubuntu15 working.  Which is mysterious.
[07:56] <lamont> which means it didn't call that functino
[07:56] <lamont> or, you didn't use the pointer when it was passed somewhere
[07:56] <ion_> Zomg, audio works in my laptop by default in gutsy. (opl3sa2)
[07:57] <lamont> or you handle SIG{SEGV,BUS} :-)
[07:57] <iwj> lamont: Yes, but those aren't plausible.  So we conclude that we don't understand fully.
[07:57] <lamont> ok
[07:57] <iwj> But we can make the situation more correct by fixing the bug and seeing if the symptoms go away.
[07:57] <ion_> The last time i used this laptop, i was running breezy. For it, i had to pass a bunch of io/irq/dma parameters to the module.
[07:57] <lamont> anyway, expect the sbuild hack to arrive in ia64/ubuntu sometime... for that matter, it really should go on all architectures...
[07:58] <StevenK> Now lmtp gets a BUS error
[07:59] <jdong> why does nautilus-cd-burner stop trying to estimate burn time remaining when the speed changes?
[07:59] <jdong> i.e. it's fine for the first step, but when my burner ramps 8x to 24x, nautilus stops outputting times
[07:59] <iwj> I'm just cleaning a few other warnings while I'm here (ssize_t passed to printf %ld, amongst other things).
[07:59] <jdong> it's pretty normal for high-speed burners to increment their speed piecewise
[08:01] <lamont> iwj: implicit conversions/definitions are bad
[08:02] <lamont> iwj: which log are we talking about?
[08:04] <slangasek> StevenK: lucky for you, lamont has a lot of experience with bus errors
[08:04] <lamont> iwj: re the debian-installer ia64 ftbfs log, where are you saying that dpkg is working in that log?
[08:04] <lamont> slangasek: I make 'em all the time...
[08:04] <StevenK> slangasek: Surely other people are running Cyrus 2.2 on sparc
[08:04] <StevenK> I can't be the only one
[08:05] <slangasek> oh, the bus error is in cyrus, not in postfix? :)
[08:05] <StevenK> Sep 22 03:55:41 enervated cyrus/master[2013] : process 2022 exited, signaled to d
[08:05] <StevenK> eath by 10
[08:06] <lamont> iwj: the version of dpkg installing the build-deps in that log is 1.13.11ubuntu6 (dapper)
[08:06] <lamont> and I don't see dpkg running anywhere else with success in the log...
[08:06] <lamont> (build-deps are installed using the apt/dpkg in the real root, not the chroot)
[08:06] <iwj> lamont: At line 37 it unpacks 1.14.5ubuntu15.  At line 41 you can see "Reading database" again, which means the new dpkg has started up.
[08:07] <lamont> which means that fixing it won't be any big issue...
[08:07] <lamont> yep.  all done by dapper's dpkg
[08:07] <lamont> show me a dpkg instance after the line that reads "debian/rules build"
[08:08] <lamont> or even debian/rules clean :-)
[08:08] <iwj> Oh, you mean the outer bits are all i386 or something ?
[08:08] <iwj> buildlog_ubuntu-gutsy-ia64.debian-installer_20070308ubuntu14_FAILEDTOBUILD.txt.gz
[08:08] <iwj> lamont: Yes, yes, I know they're bad.
[08:09] <lamont> no.  the outer bits are sbuild running the real-root apt-get with a _VERY_ long string of options pointing everything inside the chroot.
[08:09] <iwj> lamont: I'm just trying to make sure we understand how it works at all since from what you're saying (which sounds quite plausible) it ought to break utterly every time.
[08:09] <lamont> the dpkg at the top of the log is 1.13.11ubuntu6 running on a dapper ia64 machine.  The one inside the build is the gutsy version, in the chroot.
[08:09] <iwj> So right at the top of that log it unpacks and installs dpkg_1.14.5ubuntu15_ia64.deb.
[08:09] <lamont> right
[08:10] <jdong> what does unionfs oopsing invalid opcode 0000 mean?
[08:10] <lamont> installs it in the chroot.
[08:10] <iwj> Oh, you mean that that dpkg isn't upgrading itself ?
[08:10] <lamont> nope.
[08:10] <iwj> Ahhhh.
[08:10] <iwj> Right, I follow now.
[08:10] <lamont> dapper's dpkg is upgrading the gutsy chroot, and then we do  a 'chroot .... dpkg-buildpackage ...'
[08:11] <lamont> 99% certain that the dpkg-source -x is done outside the chroot as well
[08:12] <iwj> I really need to beat Guillem Jover over the head a bit more and then I can start to sanitise dpkg's build system upstream a bit.  Then we can have -Werror back and this kind of thing won't happen any more.
[08:12] <iwj> dpkg-source doesn't use dpkg.
[08:12] <lamont> ok.
[08:13] <StevenK> /usr/sbin/cyrreconstruct -r user.steven
[08:13] <StevenK> Bus error
[08:13] <StevenK> Can I kill something *now*
[08:13] <lamont> cjwatson: and re: impl-decl snatching, you saying "make it so" helps quite a bit, thank you. :)
[08:15] <iwj> lamont: How about getting Debian's gcc patched to call that warning an error ? :-)
[08:16] <lamont> iwj: one could hope.  sadly, it's not always actually an error to do that.  At least not until you use it as a pointer.
[08:17] <iwj> dpkg_1.14.5ubuntu16 on the way
[08:20] <iwj> Oh dear, it's stuck in the approval queue of course.
[08:22] <cjwatson> lamont: I do slightly question it after beta; not sure
[08:22] <cjwatson> lamont: but absolutely make it so for hardy, and we can fight about gutsy
[08:23] <cjwatson> iwj: not any more
[08:23] <lamont> cjwatson: makes sense
[08:23] <cjwatson> thanks for that
[08:23] <lamont> cjwatson: do you know if it's possible to have LP send build logs to an email addr automatically>
[08:23] <iwj> cjwatson: Thanks.
[08:23] <lamont> ?
[08:24] <iwj> lamont: Sorry to throw a bug at you and sorry for being confused.  I hope it'll be fixed now.
[08:25] <lamont> iwj: no
[08:25] <lamont> np
[08:25] <lamont> damn keyboard
[08:25] <iwj> we got no no no no no problem
[08:26] <stgraber> Can someone please check what we don't have Xubuntu daily-live yet ?
[08:26] <lamont> heh
[08:26] <cjwatson> lamont: I think it already sends at least some subset of them to a mailing list, but you'd have to ask cprov/bigjools really
[08:27] <cjwatson> stgraber: it's building
[08:27] <stgraber> I'm waiting for it to add all the isos to the tracker
[08:27] <lamont> iwj: so... back to my other question then... how can I tell if nfs-common is removed?
[08:27] <lamont> rather than purged
[08:27] <cjwatson> stgraber: waiting for the amd64 livefs to build
[08:27] <cjwatson> livefs builds take a while
[08:27] <stgraber> ok
[08:28] <cjwatson> only started 17 minutes ago so I wouldn't hold your breath
[08:31] <jdong> all of neptune's forces are against me in installing Ubuntu on this Macbook
[08:31] <bddebian> Gah, torbutton source makes torbutton-icedove and torbutton-iceweasal.. :-(
[08:32] <jdong> yay, usb external keyboard worked
[08:32] <jdong> silly bios emulator not emulating bios.
[08:33] <kylem> jdong, it's actually a race.
[08:33] <kylem> jdong, it thinks the IR port is a keyboard.
[08:33] <jdong> kylem: ah, how interesting
[08:33] <jdong> kylem: are there any known issues with macbook and the livecd unionfs panicking?
[08:33] <kylem> how recent a livecd?
[08:33] <jdong> today's.
[08:34] <jdong> I get an invalid opcode 0000 oops....
[08:34] <evand> jdong: .1?
[08:34] <jdong> evand: there wasn't a .1 build of the livecd 10 minutes ago?
[08:35] <evand> jdong: http://cdimage.ubuntu.com/daily-live/20070921.1/
[08:35] <evand> it was there 10 minutes ago.  Perhaps you were pulling a cached version of the page.
[08:35] <jdong> how confident are you that this build resolves my issue?
[08:37] <agoliveira> Tip: mc (Midnight Commander) can use a patch file as a filesystem so you can move, edit, and copy individual patchs easily as if they were files. Very useful if you have a patch that covers multiple different files.
[08:37] <evand> jdong: quite confident, it resolved the same issue for me
[08:38] <slangasek> it's the build that's explicitly supposed to fix the unionfs issue
[08:38] <jdong> oh, ok :)
[08:38] <jdong> too bad I didn't see it 5 minutes ago
[08:38] <jdong> oh well, alternate's seeming to work fine
[08:40] <iwj> lamont: (back at my keyboard now)
[08:40] <iwj> lamont: Why do you need to distinguish removed vs purged ?
[08:41] <jdong> aah the framebuffer corrupted on me....
[08:41] <jdong> this cannot end well....
[08:44] <iwj> Debian #443466 seems to be to do with something peering at /var/lib/dpkg/nfs-common.list, which is a bizarre thing to do.
[08:44] <ubotu> Debian bug 443466 in mount "mount: upgrade fails if nfs-common is in removed but not purged" [Normal,Open]  http://bugs.debian.org/443466
[08:46] <slangasek> this is lamont we're talking about
[08:47] <evand> Is Launchpad-Bugs-Fixed broken?
[08:48] <lamont> iwj: peering at nfs-common.list was looking to see if nfs-common was installed (to handle the nfs-free chroot on a nfs-using system case)
[08:48] <iwj> But if you look at /sbin/mount.nfs instead then this problem doesn't arise.
[08:48] <iwj> Ie, that file won't be there whether it's removed or purged.
[08:48] <lamont> iwj: older nfs-common doesn't deliver /sbin/mount.nfs
[08:49] <iwj> But don't you need one that does ?
[08:49] <lamont> so the cases are 1) no nfs-common, 2) old nfs-common, and 3) good nfs-common
[08:49] <lamont> I need either 1 or 3
[08:49] <lamont> 2 is bad
[08:49] <iwj> No nfs-common is good even if you have nfs things in your fstab ?
[08:49] <lamont> removed-but-not-purged nfs-common is case 1, the bug points out that I call it case 2
[08:50] <lamont> for that check, yes it's good.
[08:50] <iwj> bug points out> Yes.
[08:50] <lamont> no nfs-common --> we are in a chroot or you've don amazing things to your machine and I don't want to get in your way
[08:50] <iwj> lamont: OIC
[08:50] <jdong> whoo! unionfs ain't blowing up!
[08:50] <jander99> Does anyone currently work on the hardware database?
[08:50] <jdong> I love you all!
[08:50] <iwj> Isn't there some obvious file provided by the old nfs-common ?
[08:50] <slangasek> lamont: wasn't there a consensus at one point that calling dpkg --status from maintainer scripts was permitted, and preferable over inspecting /var/lib/dpkg?
[08:50] <lamont> iwj: hence the need to reliably determine case 2
[08:51] <iwj> slangasek: Yes, that's definitely true.
[08:51] <lamont> slangasek: yes
[08:51] <lamont> I just hadn't gotten around to changing that.
[08:51] <iwj> slangasek: But it's better still to inspect something on the filesystem.
[08:51] <slangasek> iwj: agreed
[08:51] <iwj> (Both faster and more accurate.)
[08:51] <lamont> under the "if it works, why mess with it" theory
[08:51] <iwj> lamont: So what bit of nfs-common does the old util-linux use ?
[08:51] <lamont> nothing
[08:52] <lamont> users of nfs used it
[08:52] <iwj> I'm kind of missing something.
[08:52] <iwj> mount is in util-linux, right ?
[08:52] <iwj> And the reason you need new nfs-common for new util-linux is that the new mount calls mount.nfs from new nfs-common.
[08:52] <lamont> OK.  I think I can go look at what file _does_ get delivered since antiquity by nfs-common, and key off of that file's existance instead of nfs-common.list
[08:53] <lamont> mount is the mount binary from util-linux source, yes.
[08:53] <slangasek> lamont: rpc.statd seems a good choice
[08:53] <iwj> lamont: Just a moment, bear with me a bit more ...
[08:53] <iwj> lamont: So why does having nfs things in your fstab without nfs-common installed mean you've done something amazine ?
[08:53] <iwj> What amazing thing have you done ?
[08:53] <lamont> iwj: properly speaking, one argument would be that mount should Depend: nfs-common for lenny, and then drop the depends at lenny+1.  security folks (myself included) would kill me for that
[08:54] <lamont> iwj: it really just means that /proc/mounts and the rootfs are not from the same world -> chroot
[08:54] <lamont> otherwise you've done something amazingly _special_ and deserve what you get.
[08:55] <iwj> lamont: I don't understand how you can tell this from the lack of nfs-common.
[08:55] <lamont> rpc.statd sounds like a very good choise
[08:55] <iwj> What breaks if you don't have nfs-common, in the old world ?
[08:55] <lamont> if you have nfs mounts on the system, you have nfs-common
[08:55] <iwj> I mean, I have old setup and I put some nfs thing in my fstab and I say mount -av and what happens ?
[08:56] <iwj> lamont: That's an inference, not a causal connection.  What feature of nfs-common is implied ?
[08:56] <slangasek> iwj: the issue is that the old mount would mount nfs directly; the new mount requires nfs-common to mount it
[08:56] <lamont> statd, for example
[08:56] <iwj> slangasek: Yes.
[08:56] <iwj> lamont: But I could mount with -o nolock or whatever ?
[08:57] <lamont> iwj: the check in preinst is making an effort to create the dependency-via-error where it's appropriate, and not where it's not.
[08:57] <iwj> lamont: Yes, I understand that.
[08:57] <iwj> What I don't understand is how you can know that (in non-chroots) nfs in fstab implies nfs-common installed.
[08:57] <lamont> that is a good point
[08:58] <lamont> I suppose I could do the "am I in a chroot" test
[08:58] <iwj> What you really want to know is whether the system you're about to unpack the new /sbin/mount into was/is responsible for doing the mounts.
[08:59] <iwj> Which isn't really quite the same as "are we in a chroot" since sometimes people run mount inside a chroot.
[08:59] <iwj> Mad people maybe, but it WFM when I can't be bothered not to :-).
[08:59] <lamont> he
[08:59] <lamont> heh
[08:59] <lamont> OTOH, I don't care if we screw up your chroot as long as the real root will let you fix it...
[09:00] <iwj> lamont: That's definitely true.
[09:00] <lamont> and I'm not sure we can answer which root is responsible for the mounts
[09:00] <iwj> And a check that fails to stop you screwing chroots in some obscure situation is probably liveable with.
[09:00] <iwj> So you probably just want an "are we in a chroot".
[09:01] <lamont> and it looks like someone fixed the old test
[09:01] <lamont> you see, you're not _SUPPOSED_ to be able to tell that you're in a chroot
[09:02] <iwj> *snort*
[09:02] <iwj> If you've got /proc surely you can tell somehow.
[09:02] <lamont> and I refuse to use the "inode of / != 2" check
[09:02] <lamont> iwj: the old check was to look at /proc/1/exe or such
[09:02] <iwj> /proc/1/fd perhaps.
[09:03] <iwj> In this here chroot /proc/1/fd is EACCESS for root.
[09:03] <lamont> ls -l /proc/1/fd
[09:03] <lamont> total 0
[09:03] <lamont> lrwx------ 1 root root 64 Sep 21 19:03 0 -> /dev/console (deleted)
[09:03] <lamont> all hail gutsy
[09:03] <iwj> (But I'm running a nonstandard kernel)
[09:03] <iwj> root@anarres:~ # ls -ali /proc/1/root
[09:03] <iwj> ls: cannot read symbolic link /proc/1/root: Permission denied
[09:03] <lamont> so, like I said, it appears that they fixed it.
[09:03] <iwj> -root@anarres:~> ls -ali /proc/1/root
[09:03] <iwj> 65543 lrwxrwxrwx 1 root root 0 Sep 21 20:02 /proc/1/root -> //
[09:04] <slangasek> Debian udev postinst has some currently-working magic
[09:04] <iwj> Seems quite straightforward.
[09:04] <lamont> readlink /proc/1/root
[09:04] <iwj> Now someone will make a stunt system where init runs in a chroot :-).
[09:05] <lamont>  /sbin/init is frequently installed in chroots.
[09:05] <lamont> as for running it, that'd be silly
[09:05] <jdong> evand: just got an identical oops from trying to start ubiquity on .1
[09:06] <evand> argh
[09:06] <jdong> EIP: unionfs_setattr
[09:06] <iwj> lamont: No, I mean   init=/strange/script/which/does/chroot/-c/init
[09:06] <iwj> Like an initramfs :-).
[09:07] <evand> jdong: I imagine pkl_ would want to see that.  Bug 138915 is where I'm tracking the issue if you want to add your logs there.
[09:07] <ubotu> Launchpad bug 138915 in linux-source-2.6.22 "unionfs NULL pointer dereference in 2.6.22-11.32" [High,Triaged]  https://launchpad.net/bugs/138915
[09:08] <lamont> slangasek: ROCK
[09:09] <slangasek> lamont: was that re: udev?
[09:09] <lamont> yeah
[09:10] <lamont> and stat is coreutils
[09:10] <jdong> pkl_ / evand bug report updated...
[09:10] <lamont> so... do I remove the Debian = "$DISTRO" check?
[09:11] <ScottK> LaserJock: Edbuntu mentioned: http://www.groklaw.net/article.php?story=20070921112733615
[09:12] <lamont> slangasek: do we care if ubuntu nfs users don't get the error?
[09:13] <slangasek> uh.  I don't know? :)
[09:13] <lamont> the general case is using update-manager, which will DTRT after 141559
[09:13] <slangasek> then I suppose not
[09:14] <mvo_> lamont: what do you change? the check ? and trust update-manager?
[09:15] <lamont> mvo_: right now, the check is no-op on ubuntu
[09:16] <lamont> I'm proposing checking on ubuntu, which means 'apt-get dist-upgrade' will produce errors if the user uses nfs
[09:16] <lamont> however, that .01% of the population is generally of-clue.
[09:18] <mvo_> lamont: it will be more complicated for me to ensure that its a pre-dep of util-linux, so not having the check means I can install nfs-common without caring too much for the odering and that makes my life easier. as for the general apt-get dist-upgrade case, we have release-notes and the release-upgrader (update-manager) that also runs in text-mode
[09:19] <lamont> mvo_: sounds like a vote to not have the check.  works for me.
[09:19] <mvo_> lamont: it is :) thanks!
[09:20] <mvo_> lamont: without the ordering its very easy for me, I will add it right away
[09:21] <mvo_> lamont: would you mind to add a note about it to https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes ?
[09:21] <lamont> mvo_: will do
[09:21] <mvo_> thanks!
[09:28] <MacSlow> mvo_, http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-3.png
[09:28] <MacSlow> mvo_, http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-3.1.png
[09:28] <mvo_> MacSlow: what will "einstellungen" do if no ccsm is installed?
[09:29] <MacSlow> mvo_, it's meant to offer to install it (similar to codecs)
[09:29] <jdong> urgh it happened again
[09:29] <jdong> can anyone think of an alternate install .deb that would cause the screen to be probed?
[09:30] <jdong> because I can 100% reproduce a screen corruption bug with the alternate .1 today
[09:30] <MacSlow> mvo_, and it should be ghosted until the user selects the "Custom Effects" option
[09:30] <jdong> like 20% unto unpacking the main system, the screen goes blank as if probing X, and then when it comes back the installer is totally garbled
[09:32] <mvo_> MacSlow: "This settings means that a modified set of effects is in use" <- what do you think about this text? do you plan to add this install feature for beta? I'm not really about it, I think that either we should install ccsm by default if we thing the user should see it or not show this option by default (or only if it is already installed). the amount of options is a bit overwheelming for the casual user
[09:33] <mvo_> MacSlow: otherwise I like the dialog a lot!
[09:33] <MacSlow> ccsm is heavy indeed, but the only reasonable way to offer a bearable gui (a lot better than gconf-editor :)
[09:34] <MacSlow> mvo_, I would like to redo ccsm's UI but that will keep me too busy and distract me from more pressing bugs which need attention
[09:35] <mvo_> MacSlow: its simply impossible for gutsy to get anything better done. and for hardy something is in the works already
[09:35] <jdong> sorry, nvm, looks like bug 48164
[09:35] <ubotu> Launchpad bug 48164 in xorg "Video corruption at installation of xserver-xorg" [Medium,Confirmed]  https://launchpad.net/bugs/48164
[09:36] <mvo_> MacSlow: my point is that because we do not have a better editor, we should do the best we can with the defaults and not offer to use ccsm by default
[09:36] <mvo_> MacSlow: the people who want it will find it
[09:37] <MacSlow> mvo_, that would not be very "discoverable" and I don't like that.
[09:40] <mvo_> MacSlow: I'm not religous about it and open for discussion. but I feel that our philosphy is to make it "just work" instead of offering a setup tool that let you tweak every possible option in existance. making that too easy discoverable will confuse user. I'm sure that 99% of the people will click on a advanced button if there is one (just because they are curious)
[09:41] <cjwatson> jdong: well-known bug, that - happens on my laptop too
[09:42] <cjwatson> many dups on xresprobe too, I'm not sure where it really belongs
[09:42] <jdong> cjwatson: ah, ok, I guess I'll have to remember to disable fb at boot :)
[09:42] <jdong> cjwatson: what do you think... can I do the rest of the install blindly? :D
[09:42] <cjwatson> jdong: workaround is to boot the installer with a different resolution (select something other than VGA at the boot menu)
[09:42] <MacSlow> mvo_, hm... I got to think about that a bit
[09:42] <cjwatson> (that won't be passed on to the installed system, so suspend/resume will still work)
[09:42] <cjwatson> jdong: yes, wait until disk activity stops and hit Enter
[09:42] <cjwatson> that's another workaround ;)
[09:42] <jdong> cjwatson: lol, I'll try that fist then :D
[09:42] <jdong> err, first.
[09:43] <jdong> fist second.
[09:44] <mvo_> MacSlow: feel free to raise it on the mailinglist if you want a broader discussion about it
[09:44] <mvo_> MacSlow: but I think we shouldn't let it slow down the control-center update, esepcially the "custom option" dection and the "click-on-normal-options-resets active_plugins defaults" changes are very important to have
[10:09] <MacSlow> mvo_, hm... I posted an email to the ubuntu-devel ml and got a bounce informing me that it needs prior moderator-approval since I'm a non-developer (used my ubuntu.com email-address)
[10:11] <Keybuk> MacSlow: approved and fixed so you're in the whitelist
[10:11] <MacSlow> Keybuk, ah... so that was a pending thing anyway... ok thanks
[10:19] <mvo_> MacSlow: thanks
[11:03] <bryce> slangasek: another -beta bug fix that needs your a-ok - bug 141533
[11:03] <ubotu> Launchpad bug 141533 in xserver-xorg-video-ati "Gutsy: Switching workspaces when playing XVideo overlay crashes X" [High,Fix committed]  https://launchpad.net/bugs/141533
[11:20] <okaratas> hello
[11:21] <MacSlow> good night folks
[11:40] <davmor2> devs what is likely to stop ubiquity working on the iso test of xubuntu?  I get no feed back from it at all.  ps aux | grep ubiquity shows it is running but there is no installer at all
[11:41] <Nafallo> !weekend
[11:41] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[11:43] <gnomefreak> bryce: can you please take a look at bug 139726 this looks to have started with bulletproof X enabling and it wont go away no matter what i do except reformat and ive done that twice in last 2 weeks
[11:43] <ubotu> Launchpad bug 139726 in gdm "[Gutsy} GDM is missing menu items" [Low,Incomplete]  https://launchpad.net/bugs/139726
[11:43] <gnomefreak> and no it doesnt have to be right away it can wait til you have time
[11:45] <bryce> gnomefreak: have you tried disabling the failsafeXServer line in your /etc/gdm/gdm.conf?
[11:45] <bryce> that will determine whether it is a bulletproof-x issue or not
[11:45] <bryce> gnomefreak: be sure to attach your gdm.conf, xsession-errors, Xorg.0.log, and xorg.conf to that bug report; currently there's not enough info to troubleshoot
[11:45] <gnomefreak> bryce: no how would i do that (i thought it had # infront of it like the rest of the lines
[11:46] <bryce> yes, putting a # in front of it is enough to disable bulletproof-x
[11:46] <bryce> if it is commented out like that already, then the issue is not a bulletproof-x one
[11:46] <gnomefreak> only thing helpful would be gdm.conf i checked .log1-4 and nothing im not getting errors but ill check that xsession-errors
[11:48] <gnomefreak> change that i dont have an xsession-errors file at all
[11:58] <gnomefreak> bryce: ok ty i added everything i could see and think of when ever you get a free minute its not too imporant more annoying than anything, we determined it wasnt gdm by installing older versions of gdm
[11:58] <gnomefreak> i need to run for the night, night everyone
[12:00] <gnomefreak> mdomsch: add sudo and you have it ;)
[12:00] <mdomsch> oh I was sudo'd
[12:02] <slangasek> bryce: acked; OOI, is there any reason for such fixes to not be uploaded to gutsy/unapproved, and accepted/rejected from there?
[12:09] <davmor2> Riddell: ping
[12:12] <bryce> slangasek: I guess not - if that's a better procedure, I can do that
[12:16] <Amaranth> arg, wtf
[12:16] <Amaranth> launchpad janitor spam
[12:17] <ion_> Thats quick to remove. :-)
[12:17] <ion_> Delete, that is.
[12:20] <slangasek> bryce: they have to be touched again anyway once uploaded, so unless you have doubts yourself that the fix is correct that seems better streamlined :)
[12:30] <lamont> what's the practice for dealing with a bug that is fixed in 6.10, resent in 6.06 (Bug #68967, for example)
[12:30] <ubotu> Launchpad bug 68967 in util-linux "Wrong daylight saving data for CET/CEST" [Undecided,New]  https://launchpad.net/bugs/68967
[12:30] <lamont> because it's fixed in feisty...
[12:30] <lamont> and, of course, belongs to a totally different package than it claims