[00:17] <savvas> cjwatson: sorry about bug 316579 - I didn't know it was under copyright :)
[00:22] <ScottK> savvas: As a general rule anything not explicitly not copyrighted is copyrighted.  So unless you KNOW it's not ....
[00:54] <Mavericks> ScottK: were you being sarcastic?
[00:55] <Hobbsee> Mavericks: no?  That's standard practice, actually
[00:55] <Mavericks> never mind understood - it took a while to wrap my head around that statement of ScottK
[00:55] <Mavericks> thanks Hobbsee for the response
[00:57] <JanC> actually, in many countries it's not possible or very difficult to make something "not-copyrighted"
[00:57]  * directhex copyrights Hobbsee 
[00:57]  * StevenK claims prior art and sues directhex 
[00:58] <Hobbsee> heh
[00:58]  * Hobbsee attacks directhex with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™
[00:59] <directhex> StevenK, prior art? you're thinking of patents ;)
[00:59]  * directhex patents StevenK 
[00:59] <StevenK> Meh
[00:59] <JanC> to make something public domain you would obviously have to be the author, and an author can't put something in the PD in many countries  ;)
[01:14] <maco> i believe the US is one where public domain only occurs after copyright expires or when it's a work of the government
[01:16] <crdlb> copyright never expires :>
[02:36] <nixternal> kees: pingalicious
[02:37] <nixternal> hrmm, I guess if you were from mexico or such, that might sound a little bit off :)
[02:38] <nixternal> if you don't respond in the next 4 hours, you can ignore that one
[03:33] <kees> nixternal: sup?
[04:48] <nixternal> damn, now I probably missed you kees...was just wondering if I could get added to the Core Dev Sponsors team
[04:50] <StevenK> nixternal: As in u-m-s?
[04:51] <nixternal> ya, that's the one
[05:38] <tjaalton> jdong: you disabled vblank from the compiz configuration?
[05:38] <tjaalton> the default is off, but you can break it by enabling it there
[05:40] <jdong> tjaalton: I had to manually disable vblank from gconf in an alpha 6 install
[05:40] <jdong> is the default vblank off supposed to be the case as of alpha-6?
[05:59] <maco> StevenK: do you know who handles moderation for ubuntu-devel mailing list?
[05:59] <StevenK> maco: According to https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel ; cjwatson
[06:00] <maco> figures, just needed to scroll further down.
[06:00] <maco> thanks
[06:11] <Hobbsee> maco: anything in particular you were wanting?
[06:11] <maco> to be whitelisted
[06:12] <maco> i think i fit in the white rectangle on https://wiki.ubuntu.com/UbuntuDevelopers so i'd like to get whitelisted instead of always going through message moderation
[06:13] <Hobbsee> ahhh
[06:15] <Hobbsee> People who consistently post sensible, on-topic material should be added to the whitelist. To edit the whitelist, use the administrative interface (with the moderator password) and navigate to Privacy options... -> Sender filters -> accept_these_nonmembers. Please be careful when editing this field to avoid accidents of the select-all type that might lose the previous list contents; if you suffer such an accident, don't save your changes!
[06:15] <Hobbsee> yeah, you fit that. cool
[06:16] <Hobbsee> maco: fixed.
[06:16] <maco> Hobbsee: awesome! you rock!
[06:16] <Hobbsee> maco: :)
[06:24] <tjaalton> jdong: yes, but I'm not sure if the compiz configuration enables it
[06:25] <tjaalton> but the dri driver default is off
[07:46] <pitti> Good morning
[07:47] <Hobbsee> heya pitti!
[07:57] <slangasek> hmm, why does nm-applet believe that NM is notrunning
[07:58] <slangasek> ** (nm-applet:19035): WARNING **: nm_client_get_devices: error getting devices: The name org.freedesktop.NetworkManager was not provided by any .service files
[07:58] <slangasek> \o/
[08:04] <Lure> transition to python 2.6: this just needs no-change upload, right?
[08:06] <mvo> Lure: sometimes the setup.py install line needs to be modified
[08:07] <mvo> to include --install-layout=deb
[08:07] <mvo> and sometimes the debian/*.install (or rules) because "site-packages" chagned to "dist-packages"
[08:07] <Lure> mvo: ok, thanks for hints
[08:26] <slangasek> directhex: hrm, mono seems to have transitioned from having separate /usr/share/doc directories to having symlinks pointing to mono-common?  but the -cil packages all think they still own the files under /usr/share/doc, so if you remove one of them your copyright file disappears
[08:26] <savvas> As a general rule anything not explicitly not copyrighted is copyrighted.  So unless you KNOW it's not .... < ScottK: Noted! thanks for the tip :)
[08:40] <directhex> slangasek, the reverse is the case - the ubuntu's mono has historically had a buggy docdir symlink thing going on, the current package has individual docdirs
[08:40] <directhex> apparently there's a policy issue w/ symlinking, which is why it's not done in debian
[08:42] <slangasek> directhex: then the transition to separate docdirs was not managed correctly
[08:42] <slangasek> because they're not separate dirs on my system
[08:42] <slangasek> dpkg will not automatically switch between a directory and a symlink on upgrade; this is documented in Debian policy
[08:43] <directhex> blarg
[08:46] <directhex> i'll have a word with meebey when he's about, then
[09:02] <pitti> thekorn: wow, you are really into the guts of launchpadlib
[09:14] <thekorn> pitti, I do my best, hopefully it makes sense ;)
[09:16] <pitti> thekorn: btw, do you happen to know whether the remaining usages of p-lp-bugs (ubuntu-qa-tools, ubuntu-dev-tools, python-bughelper) are going to be transitioned in jaunty?
[09:18] <thekorn> pitti, I'm sure bughelper won't make it until jaunty, ubuntu-dev-tools is using launchpadlib, I think py-lp-bugs is optional
[09:19] <thekorn> not sure about u-qa-tools
[09:19] <pitti> thekorn: u-dev-tools still Depends: on it, though
[09:19] <pitti> $ dpkg -L ubuntu-dev-tools|xargs grep launchpadbugs
[09:19] <pitti> /usr/share/pyshared/ubuntutools/ppaput.py:    import launchpadbugs.connector as Connector
[09:20] <pitti> hm, that shouldn't be hard to change, just one file left
[09:21] <thekorn> looks like I missed it when I did the transition ;)
[09:22] <seb128> sjoerd: hey, what is the issue with telepathy-glib?
[09:22] <sjoerd> seb128: build-depends on python, but used python2.5
[09:22] <sjoerd> *uses
[09:22] <seb128> ok, so it's a package bug
[09:23] <sjoerd> yeah and a slight upstream one as well
[09:23] <seb128> bigon was saying it's a buildd bug apparently
[09:23] <seb128> bigon: ^
[09:23] <sjoerd> for debian it's fine as python is still 2.5 or lower
[09:23] <sjoerd> we'll fix upstream so it can use 2.6 as well, but the ubuntu package should b-d on python2.5 for now
[09:25] <seb128> sjoerd: ok, we are on sync with debian so it would be nice to fix it there since debian will have the issue sooner or later too anyway
[09:25] <seb128> but we can add an ubuntu diff for now I guess
[09:26] <sjoerd> sure
[09:26] <sjoerd> i wouldn't mind putting python2.5 in the debian packaging as a build-dep for now
[09:27] <seb128> would be nice, thanks!
[09:28] <sjoerd> is telepathy in main now btw or still universe ?
[09:29] <seb128> universe
[09:36] <savvas> pitti: ignore bug 332120 - it's a bit outdated, I was "educated" to rebuild them - I forgot to set it as invalid :)
[09:36] <pitti> savvas: ah, okay
[09:36] <pitti> savvas: unsub'ing sponsors then
[09:37] <savvas> pitti: thanks :)
[09:40] <TheMuso> seb128: There appears to be some sort of race condition with GNOME session startup, gnome-session and at-spi-registryd. On the live CD, logout dialogs are accessible, whereas on an installed system they are not. Starting at-spi-registryd-helper from a file in /etc/X11/Xsession.d proves that things are not starting in the right order.
[09:40] <TheMuso> seb128: I'm wondering whether you may have any suggestions as to how this could possibly be fixed.
[09:41] <TheMuso> seb128: I could start at-spi-registryd from /etc/X11/Xsession.d, but I think it would be better to sort the problem out relating to the GNOME session itself.
[09:42] <seb128> TheMuso: no suggestion but open a gnome-session bug upstream I would say
[09:42] <TheMuso> seb128: ok sounds reasonable.
[09:45] <YokoZar> Does 5-a-day ever work? I've gotten bazaar internal errors the last month when I've tried to use it (with 5-a-day --add)
[10:00] <pitti> asac: please pull lp:~pitti/mobile-broadband-provider-info/mobile-broadband-provider-info.20090309 into lp:~network-manager/mobile-broadband-provider-info/mobile-broadband-provider-info.ubuntu/ (or make ubuntu-core-dev a member of ~network-manager)
[10:01] <pitti> asac: I just uploaded the new upstream release to jaunty
[10:01] <yao_ziyuan> can i run update-notifier (not update-notifier-kde) at kde startup for update notification?
[10:02] <ttx> asac: ping
[10:09] <pitti> evand: hey; I hope you don't mind, I fixed usb-creator FTBFS and did an upload yesterday, since it didn't work at all with persistency
[10:09] <evand> pitti: no problem at all.  Thanks a bunch!
[10:11] <pitti> cjwatson, bdmurray: heh, did you notice that the numbers on http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html actually go *down*?
[10:14] <asac> pitti: hmm. ok thanks. thought actually we were waiting for something
[10:14] <asac> pitti: but that was only libmbca0 i guess
[10:15] <pitti> asac: waiting> all bugs mentioned in the sponsoring bugs were fixed upstream
[10:15] <pitti> asac: that's what you was waiting for before
[10:15] <cjwatson> joaopinto: just make sure that /etc/default/console-setup is set up properly in the chroot before you install console-setup there
[10:15] <cjwatson> pitti: blink, so they do. that's odd ...
[10:16] <cjwatson> pitti: perhaps a change of rules in how sponsored uploads are counted?
[10:16] <pitti> cjwatson: maybe, I don't know
[10:17] <seb128> pitti: what is the question?
[10:17] <joaopinto> cjwatson, thanks, meanwhile I was able to install with DEBIAN_FRONTEND set to noninteractive, I just needed to bind mount /proc first, otherwise the console-setup start script fails (without providing a meaningful reason)
[10:17]  * slangasek tries restarting NM to see if that lets nm-applet find it again; if I go quiet, you'll know I broke my network
[10:18] <ttx> asac: I'm looking into the n-m/wpasupplicant shutdown mess... Apparently wpasupplicant has support for sendsigs omission in its ifup/down scripts, but they aren't called when used from n-m ? I'm still a little confused as to what in that behavior is by design and what is a bug.
[10:19] <asac> ttx: NM wpasupp is started through dbus activation
[10:20] <asac> ttx: could be that it dies when dbus goes down
[10:20] <ttx> asac: imho it dies when killed by sendsigs... since there is nothing in sendsigs.omit.d created to avoid that fate
[10:21] <ttx> asac: the omit things are normally created in the ifup scripts
[10:21] <ttx> but n-m must bypass that iirc
[10:22] <asac> ttx: so have you tried to not kill nm nor wpasupp? what happened?
[10:23] <ttx> if I run my N-M branch /and/ manually add the pid for wpa_supplicant in /lib/init/rw/sendsigs.omit.d then the network fs get properly unmounted
[10:23] <ttx> asac: supposing you run in "network connection available for all users" mdoe
[10:24] <ttx> mode, even
[10:24] <slangasek> well, that's fun.  nm-applet can see NM again as soon as I restart it; but I can't connect to my home wireless anymore, only to the neighbor's open AP. :P
[10:24] <ttx> asac: it still fails when run in "my connection, MINE !" mode.
[10:25] <asac> slangasek: you dont see your wireless in applet? or association just fails?
[10:25] <ttx> asac: but I don't see any way out of that... mounting network filesystems and running per-Gnome-session network is obviously not compatible.
[10:26] <slangasek> asac: clicking on my home network fails to get it to associate. Mar 16 03:25:45 dario NetworkManager: <WARN>  get_secrets_cb(): Couldn't get connection secrets: Rejected send message, 5 matched rules; type="method_call", sender=":1.1383" (uid=0 pid=29469 comm="/usr/sbin/NetworkManager --pid-file /var/run/Netwo") interface="org.freedesktop.NetworkManagerSettings.Connection.Secrets" member="GetSecrets" error name="(unset)" requested_reply=0 ...
[10:26] <slangasek> ... destination="org.freedesktop.NetworkManagerUserSettings" (uid=1000 pid=30394 comm="nm-applet ")).
[10:28] <seb128> pitti, slangasek: is one of you doing syncs?
[10:28] <pitti> seb128: no
[10:29] <slangasek> asac: any thoughts?
[10:29] <asac> slangasek: sounds like dbus
[10:29] <asac> slangasek: what kind of system is that? jaunty?
[10:32] <asac> slangasek: the /etc/dbus/system.d/ policy files got updated in one of the recent uploads (security).
[10:33] <slangasek> asac: not sure which of my messages made it through; did you get the get_secrets_cb() error I quoted?
[10:33] <asac> slangasek: yes
[10:33] <asac> thats the last one
[10:33] <asac> 11:26 < slangasek> ... destination="org.freedesktop.NetworkManagerUserSettings" (uid=1000 pid=30394 comm="nm-applet ")).
[10:34] <slangasek> wow, the neighbors' ISP sucks. ;)
[10:34] <asac> 1:29 < asac> slangasek: what kind of system is that? jaunty?
[10:34] <asac> 11:32 < asac> slangasek: the /etc/dbus/system.d/ policy files got updated in one of the recent uploads (security).
[10:36] <asac> ttx: i would think that user mounted nfs is not really supported by our Desktop. last week i searched for UI to setup a nfs mount in gnome and didnt find any.
[10:37] <asac> ttx: so yeah. lets fix the system connection case ... and keep the other issue open
[10:38] <slangasek> asac: jaunty, yes
[10:40] <slangasek> asac: suggestions on how to fix this?  (and which package updated those files?  this breakage is not correlated with an upgrade of network-manager for me)
[10:40] <asac> slangasek: when did this start?
[10:40] <slangasek> asac: this part of the problem started a couple hours ago, when I restarted NetworkManager because nm-applet couldn't see it
[10:41] <asac> slangasek: have you restarted your system afterwards?
[10:41] <slangasek> that error was: ** (nm-applet:19035): WARNING **: nm_client_get_devices: error getting devices: The name org.freedesktop.NetworkManager was not provided by any .service files
[10:41] <slangasek> asac: no?
[10:42] <asac> slangasek: check that you dont have modified dbus policy files. if that doesnt help restart dbus and see if that helps
[10:42] <slangasek> I don't have modified dbus policy files
[10:42] <slangasek> at least, not modified by me
[10:43] <asac> slangasek: heh
[10:43] <slangasek> let me do a conffile check
[10:43] <asac> slangasek: yeah. you never know; mine is: http://paste.ubuntu.com/131887/ (/etc/dbus-1/system.d/nm-applet.conf)
[10:44] <slangasek> yeah, no modified conffiles under /etc/dbus-1
[10:45] <asac> good.
[10:45] <slangasek>                 <!-- Only root can get secrets -->
[10:45] <slangasek> ok... isn't that the problem? :)
[10:45] <joaopinto> cjwatson, I noted that some other scripts already check for /proc availability, does it make sense to file a bug against console-setup ?
[10:46] <cjwatson> joaopinto: feel free to file a bug
[10:46] <asac> slangasek: well. there is no reason for anyone else to get the secrets
[10:46] <asac> slangasek: or are you running NM daemon as a special user;)?
[10:46] <asac> slangasek: also you have: sender=":1.1383" (uid=0 pid=29469
[10:46] <asac> which seems to be ok
[10:47] <slangasek> asac: it's running as root.  The error message in my log is precisely about querying secrets.
[10:47] <asac> slangasek: right. but root is allowed to get secrets. thats why i think your dbus needs a restart or something
[10:48] <slangasek> asac: except that file is older than my last reboot
[10:49] <slangasek> ugh, ok, now I can't even see my AP; hang on, let me troubleshoot that
[10:50]  * asac running out to buy some coffee-food; few minutes ...
[10:53] <slangasek> asac: restarting dbus crashed X. :P
[10:53] <slangasek> it also caused nm-applet to again be unable to see NM
[10:54] <slangasek> so I restarted NM; now things are working, but I had to reenter my WEP key
[10:54] <slangasek> (which is supposed to be stored as part of a system connection profile, but of course that still doesn't work properly anyway...)
[10:59] <doko> slangasek: did you rebuild gcc-4.3 for #328035, or do you need a package?
[11:00] <slangasek> doko: rebuild it?  I was just going to roll back to the earlier version of the package that was used to build -1ubuntu1
[11:00] <doko> ahh, ok
[11:08] <slangasek> seb128: well, haven't seen bug #332342 again, but apparently gnome-keyring-daemon is unhappy if dbus disappears. :)
[11:10] <asac> slangasek: thats strange. i run wpa psk secret system connection on my laptop without applet ... no problems with secrets
[11:10] <slangasek> do you use it as a system connection?
[11:12] <asac> slangasek: yes. "all userse"
[11:16] <slangasek> asac: ok, well, as I've said before, the system connection here has never worked properly as a system connection
[11:17] <slangasek> I expect that it'll keep track of my WEP key again now that I've re-entered it, but that it will continue to fail to bring up the connection prior to login
[11:17] <slytherin> seb128: Have some free time? Need to discuss broken DVD playback in jaunty. I have the solution but I am not able to understand root cause.
[11:17] <seb128> slytherin: shoot
[11:18] <asac> slangasek: for system connections the secrets have to be entered int he "connection editor"
[11:19] <seb128> slangasek: hey, is that you doing syncs?
[11:19] <asac> if you see a popup asking for passphrase its not a system connection
[11:19] <seb128> slytherin: so...?
[11:19] <slytherin> seb128: DVD playback is broken with latest libdvdread. The solution I have found is to use old configure script instead of current configure2/Makefile combo being used. But I have no idea why one works while other doesn't.
[11:19] <seb128> slytherin: configure for what?
[11:20] <slangasek> asac: frankly, suggestions that this is an error on my part are only going to piss me off, because I have clicked *every* *possible* *button* in nm-applet, repeatedly, to try to get it to do something sensible with a system connection
[11:20] <slytherin> seb128: for build. Upstream ships a configure2 script and using autogen.sh creates another configure script.
[11:20] <slangasek> asac: so if I've failed, it's because the UI is braindamaged
[11:20] <seb128> slangasek: what pakage are you speaking about? libdvdread?
[11:21] <seb128> ups
[11:21] <slangasek> seb128: I'm doing syncs today, yes
[11:21] <seb128> slytherin: ^
[11:22] <slangasek> asac: I have a profile under /etc/NetworkManager/system-connections.  It contains the secret.  The connection is only ever brought up when I log in and nm-applet starts.
[11:22] <asac> slangasek: i dont say that its your fault. its just odd. i will check whether i can see similar things with WEP
[11:22] <slytherin> seb128: yes
[11:22] <seb128> slangasek: ok, I will need to do some GNOME syncs later when you are done
[11:23] <asac> slangasek: do you see whether NM at least tries to connect for you?
[11:23] <asac> before login?
[11:23] <seb128> slytherin: weird, I tried to use libdvdread3 which is still installed on my jaunty box some days ago and it didn't work better
[11:23] <slytherin> seb128: Now it is libdvdread4
[11:23] <slytherin> seb128: will be back in 10 minutes
[11:23] <seb128> slytherin: right, but libdvdread3 should still be working
[11:24] <seb128> slytherin: if that was a libdvdread bug, since that's the intrepid version and that was working in intrepid
[11:24] <seb128> slytherin: later
[11:24] <seb128> brb trying an another round of updates
[11:25] <slangasek> asac: hmm, I think we're repeating a conversation we've had in the past about this. :)  I think I should just make sure I have a bug filed about the problem...
[11:26] <slangasek> seb128: I'm already done with the syncs, go ahead
[11:26] <seb128> slangasek: thanks
[11:26] <asac> slangasek: ok got your bug now
[11:27] <slangasek> asac: bug #321442?
[11:28] <asac> slangasek: yeah
[11:48] <slytherin> seb128: I am back. Actually all the applications have migrated to libdvdread4 now.
[11:48] <seb128> slytherin: what do you call migrated there?
[11:49] <slytherin> seb128: I mean linked against libdvdread4. mplayer, VLC, gstreamer plugins etc.
[11:51] <seb128> slytherin: right, I just did try totem using libdvdread3 to see if that was due to the new libdvdread4 and that didn't work better here
[11:51] <seb128> slytherin: what change do you do to get it working? I will give it a try and have a look
[11:52] <slytherin> seb128: Just a minute
[11:52] <seb128> Hobbsee: why did you confirm bug #342890 as being a totem issue if it happens on all dvd players?
[11:53] <Hobbsee> seb128: because i've not moved it yet
[11:54] <slytherin> seb128: I rebuild libdvdread using this in debian/rules file - ./autogen.sh, ./configure --prefix=/usr -DHAVE_DLFCN_H (note the currently used script is configure2). I had to add libtool, autoconf and automake to build-depends.
[11:54] <slytherin> seb128: one more thing, configure.ac needs patching to change DVDREAD_LT_REVISION=2 to DVDREAD_LT_REVISION=3
[11:54] <seb128> slytherin: why?
[11:55] <seb128> slytherin: I will have a look to that after lunch
[11:55] <slytherin> seb128: sure, take your time.
[11:55]  * seb128 is away for lunch now, bbl
[11:57] <slytherin> Hobbsee: I am changing the package for that bug to libdvdread.
[11:58] <Hobbsee> slytherin: cool, thanks
[12:00] <asac_> slangasek: ok. after playing around i could now reproduce; it gets revealed because of managed=false in nm-system-settings.conf and having eth0 configured in ifupdown; managed=true should workaround this for now
[12:01] <slangasek> asac_: won't that also cause NM to try to manage eth0, then?
[12:02] <asac_> slangasek: yes. if you have a not supported setup you have to wait for the fix
[12:02] <slangasek> "not supported"?
[12:03] <asac_> slangasek: not supported by the ifupdown system settings plugin that is
[12:03] <asac_> e.g. if you use managed=true, nm ifupdown plugin will parse your ENI and manage that as a system connection
[12:03] <slangasek> ah
[12:03] <asac_> instead of keyfile
[12:03] <slangasek> well, I'll turn it on and see; having it twiddle with eth0 is certainly going to be a lesser evil
[12:03] <slangasek> since eth0 is never plugged in :)
[12:05]  * asac_ sets AP back to WPA
[12:32] <slangasek> mvo: gksu is dep-wait on sng?
[12:37] <mvo> slangasek: oh, let me check
[12:44] <seb128> pitti: http://launchpadlibrarian.net/23910885/buildlog_ubuntu-jaunty-i386.glib2.0_2.20.0-1_FAILEDTOBUILD.txt.gz
[12:45] <seb128> pitti: "pkgstriptranslations: tarball already exists" is that a warning or an error?
[12:45] <seb128> the build failed but I'm not sure to understand why
[12:49] <pitti> seb128: no, it's just logging
[12:49] <seb128> ok
[12:49] <pitti> seb128: it happens if a source builds multiple binaries and thus it's called several times
[12:49] <seb128> weird build log
[12:49] <pitti> seb128: if it exists, it updates the existing one
[12:49] <seb128> I see nothing wrong there
[12:49] <pitti> seb128: urgh, glib again?
[12:49] <seb128> yes
[12:49] <pitti> seb128: previous builds failed because the buildds run builds in parallel
[12:49] <pitti> (AARGH! to whoever enabled that in that way)
[12:50] <pitti> seb128: but I thought I fixed that in pkgstriptranslations
[12:50] <cody-somerville> md5sum: usr/share/locale/da/LC_MESSAGES/glib20.mo: No such file or directory
[12:50] <cody-somerville> md5sum: usr/share/locale/de/LC_MESSAGES/glib20.mo: No such file or directory
[12:50] <cody-somerville> dh_md5sums: command returned error code
[12:50] <cody-somerville> make: *** [binary-indep] Error 1
[12:51] <mvo> slangasek: I put a uudecoded version into the gksu source for now. is there a reaosn to keep sng out of main? or is just a MIR report required for it?
[12:51] <pitti> cody-somerville: indeed, that's further up
[12:51] <pitti> cody-somerville: it seems that one pkgstriptranslations runs in parallel with another dpkg-deb
[12:51]  * cody-somerville nods.
[12:51] <cody-somerville> Indeed.
[12:51] <cody-somerville> The next line after that error is "make: *** Waiting for unfinished jobs...."
[12:51] <pitti> seb128: bah, fixing parallel dh_* runs properly is utterly hard
[12:52] <slangasek> mvo: MIR would be required; not my department, I'm just reviewing the out-of-dates list :)
[12:52] <seb128> pitti: what do you suggest doing? retrying the build? ;-)
[12:52] <pitti> seb128: we can do
[12:52] <seb128> let me retry
[12:52] <pitti> seb128: but ideally glib would just stop doing parallel debhelper
[12:52] <pitti> it's a gamble like this
[12:52] <seb128> it doesn't do anything special that I know about
[13:04] <slangasek> asac: edited nm-system-settings.conf to set [ifupdown] managed to true; restarted NM; network still doesn't come up without nm-applet
[13:19] <doko> mvo: how do you suggest to handle bugs like bug 320745 and bug 322739 ?
[13:23] <mvo> doko: the ones I have seen that look like this are file system corruptions, I have a closer look
[13:26] <seb128> mvo: there is several bugs with the same error on dpkg
[13:27] <seb128> mvo: I tend to reassign the ones we get for desktop packages there since the short read seemed to be a dpkg issue
[13:28] <seb128> slytherin: ok, I don't know why because I don't think I changed anything special since friday but dvd playing work on my jaunty laptop today
[13:29] <seb128> so either one of the GNOME 2.26 updates fixed it which would be weird
[13:29] <seb128> or it's murphy law in action
[13:29] <mvo> doko: I commented
[13:31] <asac> slangasek: sudo killall nm-system-settings to apply your .conf changes
[13:31] <slangasek> asac: right, ok
[13:31] <slytherin> seb128: That is weird. I was having problem till yesterday. Currently I am in office. SO I will let you know if it works for me when I go home.
[13:31] <asac> (yes, we will do that in init script)
[13:31] <slytherin> seb128: In what timezone are you usually available?
[13:32] <seb128> slytherin: european work hours and often after dinner too
[13:32] <seb128> slytherin: if I'm on IRC I'm available that's easy ;-)
[13:32] <slytherin> seb128: ok. :-)
[13:32] <asac> a bit odd: on my desktop with usb wifi thing i cannot reproduce "nm not activating system connection" bug ... no matter what. seems i have to do the debugging on the laptop then.
[13:32] <slangasek> asac: hmm, still the same problem
[13:32] <asac> darn
[13:33] <slytherin> seb128: you have latest updates installed right?
[13:33] <seb128> slytherin: I did upgrade on friday and I've been doing GNOME updates since this morning
[13:34] <asac> slangasek: as a last attempt you could try to remove eth0 lines from ENI and killall nm-system-settings, restart NM and everything.
[13:34] <seb128> slytherin: trying to play protected dvds was not working on friday, I did try a no change libdvdread rebuild after lunch today and now that works
[13:34] <seb128> slytherin: I did try to reinstall the jaunty version and that works too
[13:34] <asac> slangasek: anyway, i could reproduce something similar on my laptop so i will just debug that and hope that this fixes your issue too
[13:34] <seb128> slytherin: I did reinstall the libdvdcss too and that's still working
[13:34] <slytherin> seb128: Ok. The only thing in gstreamer stack that has changed since Friday is -ugly. So I am really clueless.
[13:34] <slangasek> asac: ok :)
[13:35] <seb128> slytherin: so either it's murphy's law or the glib update or something fixed it, but I doubt GNOME updates would impact on libdvdread
[13:35] <seb128> slytherin: I didn't install this update yet
[13:35] <seb128> and I was having the issue in totem-xine too
[13:35] <seb128> which is working fine now
[13:35] <Amaranth> mvo: have you seen any problems with compiz on intel with UXA?
[13:36] <slytherin> seb128: I didn't have any issues with any xine players. Anyway, going offline now. Will login later.
[13:36] <seb128> slytherin: ok
[13:37] <seb128> slytherin: xine-ui was not working for me on friday I think
[13:37] <seb128> neither was totem-xine
[13:39] <Lure> pitti: thanks for approving exiv2 FFe
[13:40] <Lure> pitti: does universe approval need 2 ACKs and main only one
[13:40]  * Lure read this in FFeProcess
[13:42] <jdong> tjaalton: well from my experience, compiz DOES enable vblank syncing by default and that makes UXA very unhappy to render the screen more than once every 5 seconds :D
[13:44] <Amaranth> jdong: we don't enable vsync by default
[13:44] <Amaranth> ack, we do, when did that change?
[13:46] <Amaranth> sure enough, that was the problem
[13:46] <Amaranth> I thought we disabled vsync because it caused problems with nvidia
[13:49] <jdong> yeah, maybe we should turn that off...
[13:54] <mvo> Amaranth, jdong: uxa> yes its pretty slow currently. if its the sync_to_vblank, then I will chnage the default
[13:55] <Amaranth> mvo: it is, I just turned that option off and it flies again
[13:55] <Amaranth> I was getting sick of the metacity compositor, so slow and limited
[13:55] <jdong> mvo: likewise; with UXA and vblank OFF, the speed is more or less acceptable (I don't feel Compiz any slower than Intrepid)
[13:55] <jdong> but with vblank on, all hell breaks loose :)
[13:56] <mvo> thanks guys, I prepare a fix
[13:56] <mvo> "fix
[13:56] <mvo> "
[13:56] <jdong> thanks!
[13:56] <mvo> hm, this should be set to false already
[13:56]  * mvo looks a bit deeper
[13:57] <Amaranth> mvo: that's what I said too :P
[13:57] <ogra> for me ebaling UXA makes X crash randomly
[13:57] <Amaranth> afaik nvidia still falls over on it because they use refresh rate to store configuration information
[13:57] <ogra> *enabling
[13:58] <mvo> Amaranth: yeah, the changelog says it causes issues with suspend
[13:58] <Amaranth> yep, that too
[13:58] <Amaranth> we really need a way to make sure certain options are on/off per video card/driver
[14:02] <mvo> Amaranth: heh :) core.xml.in is now core.xml.in.in
[14:02] <Amaranth> *headdesk*
[14:24] <soren> Keybuk: Hey. You dropped ndb-client's modprobe option to set max_part to 15, claiming the default was already 16. This is not the case (you've probably mistaken nbds_max for max_part). Since you broke it, would you mind taking care of fixing it in the kernel? I mean, how much difference will one patch make in your anti-modprobe-options crusade? :)
[14:33] <Keybuk> soren: ?
[14:34] <Keybuk> drivers/block/Makefile:obj-$(CONFIG_BLK_DEV_NBD)	+= nbd.o
[14:34] <Keybuk> oh, no, wait, you're right ;)
[14:34] <Keybuk> I did confuse the two
[14:34] <ogra> i think he means devices != partitions
[14:37] <ogra> Keybuk, btw, i get a "file not found" error if i use an empty modules.dep ... i know its just cosmetic, but would be nice if it wouldnt moan
[14:39] <Keybuk> ogra: you can't get an empty modules.dep
[14:39] <ogra> sure
[14:40] <ogra> if i run depmod -a without having any modules under /lib/modules/$(uname -r)
[14:40] <Keybuk> it should still generate the empty file
[14:40] <ogra> that creates an empty file /lib/modules/$(uname -r)/modules.dep
[14:40] <Keybuk> not to mention an empty binary bindex
[14:40] <Keybuk> oh, no, it shouldn't
[14:40] <Keybuk> it generates a file with lots of "filename:" lines
[14:41] <ogra> on boot i get a file not found: /lib/modules/$(uname -r)/modules.dep
[14:41] <Keybuk> hmm
[14:42] <Keybuk> that sounds more like a bug somewhere else
[14:42] <ogra> i used it like that on my early ARM kernels
[14:42] <Keybuk> what is outputting that error?
[14:42] <ogra> to get an initramfs even though i have no kernel modules
[14:42] <ogra> i think there is been a "modprobe:" at the start of the lines
[14:42] <ogra> i have no such system around atm
[14:43] <Keybuk> modprobe doesn't *use* modules.dep ;)
[14:43] <ogra> it was pretty close tro something like: "modprobe: /lib/modules/$(uname -r)/modules.dep: not such file or directory"
[14:43] <Keybuk> which is odd, because you're saying there is such a file, it's just empty <g>
[14:44] <ogra> right
[14:44] <ogra> it might refer to the content ... if i have it again i'll note down the exact message
[14:45] <ogra> my assumption was that some script in module-init-tools tries to parse the file and ends up with an empty var where it shouldnt
[14:45] <ogra> trying to open a file it would read from /lib/modules/$(uname -r)/modules.dep normally
[14:48] <soren> Keybuk: modprobe doesn't use it? What does, then?
[15:00] <Keybuk> soren: nothing
[15:01] <Keybuk> it's generated because if it wasn't, some people would get hysterical
[15:02] <Keybuk> soren: got a bug# about the nbd thing?
[15:09] <soren> Keybuk: https://launchpad.net/bugs/342563
[15:10] <soren> Keybuk: How are module dependencies handled nowadays, then?
[15:10] <ogra> by the modules themselves
[15:10] <soren> Oh, symbo... Right, ok.
[15:11] <soren> ogra: Erm.. No, I don't get that  :)
[15:11] <calc> doko: have you seen my follow up to bug 329903 yet?
[15:11] <ogra> ogra@osiris:~$ modinfo mcs7830|grep depends
[15:11] <ogra> depends:        usbnet,mii
[15:12] <soren> ogra: I see. So how does that get mapped to filenames?
[15:12] <ogra> by assumptions?
[15:13] <ogra> no idea
[15:14] <soren> I see modprobe opens modules.dep.bin for something.
[15:16] <soren> "modprobe  expects an up-to-date modules.dep file, as generated by depmod (see depmod(8))." from modprobe(8)
[15:24] <bdmurray> pitti: How do you figure?
[15:25] <pitti> bdmurray: last time I looked at the page (a week ago perhaps) I had some 159 fixes, and now it's 140something
[15:25] <rtg> cjwatson: hey mr. debootstrap. I'm having some issues with a Jaunty lpia chroot on a Jaunty server. '/usr/lib/gcc/i686-linux-gnulp/4.3.3/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory'. Does that look familiar? I've re-installed from scratch, but no joy. Seems to work fine on an Intrepid host.
[15:25] <Keybuk> soren: it lies
[15:25] <Keybuk> modprobe uses modules.dep.bin now
[15:26] <bdmurray> pitti: its possible the bug is no longer Fix Releaed but that does seem excessive
[15:26] <soren> Keybuk: Which holds the same information, but in a different formaT?
[15:26] <Keybuk> soren: right
[15:26] <soren> Keybuk: Ok. So the "depends info" from modinfo is only informational?
[15:26] <tjaalton> jdong, Amaranth, mvo: DRI2 (which is used when UXA is) doesn't support sync-to-vblank, so maybe compiz tries to do something weird to compensate, which makes it slow
[15:26] <soren> Err.. "depends" info, I mean.
[15:26] <cjwatson> rtg: can you give me a quick recipe to reproduce this?
[15:26] <pitti> bdmurray: maybe you changed some rules wrt. sponsoring?
[15:27] <mvo> tjaalton: the default should be fixed now
[15:27] <cjwatson> rtg: sounds like a broken runtime linker path or something
[15:27] <mvo> (in compiz)
[15:27] <Keybuk> soren: the depends info from modinfo is the hints in the .ko that depmod reads and turns into modules.dep{,.bin}
[15:27] <Keybuk> likewise the alias info from modinfo is what depmod turns into modules.alias{,bin}
[15:27] <tjaalton> mvo: oh, it used to cause problems with nvidia? maybe that's why mine is freezing a lot when changing the user or crashes on resume/thaw
[15:27] <rtg> cjwatson: I'm just running debuild on the Jaunty kernel tree in an LPIA chroot
[15:27] <tjaalton> mvo: great :)
[15:28] <cjwatson> so any invocation of gcc I guess
[15:28] <rtg> cjwatson: 64 bit Jaunty server, LPIA chroot.
[15:28] <soren> Keybuk: Now I'm confused :) I just strace'd modinfo and it opens modules.dep (not .bin)... Any idea what it might be using that for?
[15:29] <cjwatson> rtg: I don't have a 64-bit machine handy, but let me build a test chroot here and I'll get back to you
[15:29] <Keybuk> soren: mailed the patch for you to kernel-team and the bug
[15:29] <cjwatson> rtg: in the meantime an strace of the failing compile command wouldn't hurt
[15:29] <soren> Keybuk: How about lkml?
[15:29] <rtg> cjwatson: Thanks. I'll see what I can figure out
[15:29] <Keybuk> soren: not appropriate for that?
[15:29] <soren> Keybuk: You sent all the similar ones further upstream, didn't you?
[15:30] <Keybuk> soren: not the options ones
[15:30] <soren> Keybuk: I noticed the one on the linux-bridge mailing list, so I assumed that was your general approach.
[15:30] <soren> Keybuk: Oh, only aliases? I see.
[15:30] <slangasek> rtg: is the libmpfr1ldbl package installed in this chroot?
[15:30] <rtg> slangasek: libmpfr1ldbl                      2.4.0-1ubuntu3
[15:31] <rtg> slangasek: hang on, lemme get inti the chroot
[15:31] <Keybuk> soren: options are our own hacks, usually
[15:31] <Keybuk> ie. ignoring HBA
[15:31] <rtg> slangasek: indeed, it is not.
[15:31] <cjwatson> bdmurray: my number dropped from 122 to 109, so I can confirm pitti's comment
[15:32] <slangasek> rtg: ok - so either your chroot is broken, or something that's supposed to have a dep on that package is missing it
[15:32] <cjwatson> hence why I was wondering if it was something to do with sponsored changes, for which that would seem about right
[15:32] <soren> Keybuk: Right, good point.
[15:32] <rtg> cjwatson, slangasek: that fixed it.
[15:33] <slangasek> rtg: but it looks like there's a real bug here, that should also be fixed :)
[15:33] <Keybuk> soren: if the nbd upstream think this option is the right default, they are the upstream for that kernel subsystem too :p
[15:33] <bdmurray> I'll look into it then, thanks
[15:33] <rtg> slangasek: I vote for the missing dep
[15:33] <rtg> slangasek: is that a gcc package bug?
[15:33] <soren> Keybuk: That's true :)
[15:34] <slangasek> rtg: I'm not sure, because Contents-lpia.gz says that /usr/lib/gcc/i686-linux-gnulp/4.3.3/cc1 doesn't exist at all
[15:34] <slangasek> ah, 4.3.3 -> 4.3
[15:35] <slangasek> rtg: yeah, it's a bug in gcc-4.3
[15:35] <slangasek> the cpp-4.3 binary is supposed to have this dep
[15:35] <rtg> slangasek: so, I can annoy doko with it?
[15:35] <slangasek> sure :)
[15:35] <rtg> will do
[15:36] <rtg> slangasek: why doesn't this fail in other chroots?
[15:36] <slangasek> you mean other than lpia?
[15:36] <rtg> yeah
[15:36] <slangasek> apparently they have the right dep
[15:37] <rtg> on the other hand, I also have not reinstalled other chroots from scratch recently
[15:37] <slangasek> no, I just checked and i386's cpp-4.3 does have the dep
[15:37] <rtg> why is lpia special?
[15:37] <slangasek> I don't know
[15:41] <Keybuk> soren: modinfo? no idea
[15:42] <Keybuk> soren: ahh, yes I do
[15:43] <Keybuk> modules.dep also happens to serve as a handy file that lists the full names of modules
[15:43] <Keybuk> if you did "modinfo foo" it has to turn foo into the filename of a .ko
[15:44] <cjwatson> slangasek: thanks for sorting it out before my debootstrap had finished ;-)
[15:44] <highvoltage> heh
[15:44] <slangasek> :-)
[15:45] <soren> Keybuk: Ah, makes sense. Thanks.
[15:45] <Keybuk> though why it uses that and not the .bin is probably just a mistake
[15:45] <soren> Keybuk: It seems every time I think I've sorted out how all of that works, it changes completely.
[15:45] <Keybuk> it doesn't change much ;)
[15:45] <Keybuk> it's actually been pretty stable for a couple of years
[15:45] <Keybuk> kernel source Makefiles import config and define what's built-in and what's a module
[15:45] <soren> And I was *just* about to get it :)
[15:46] <Keybuk> modules declare their parameters which are just static variables
[15:46] <Keybuk> modules also declare tables of devices that they support
[15:46] <Keybuk> this information ends up specially marked in the .ko
[15:46] <Keybuk> so things like modinfo can pick it up
[15:46] <Keybuk> depmod reads this information and turns it into the index files in /lib/modules/$(uname -r)
[15:47] <Keybuk> previously this was all those modules.*map things
[15:47] <Keybuk> then we got modules.alias
[15:47] <Keybuk> now we use binary indexes
[15:47] <Keybuk> the device tables are strings with wildcards in them
[15:47] <Keybuk> pci:vXXXXdXXXX... and so on
[15:47] <Keybuk> with any bits the module supports "any" of as a "*"
[15:48] <Keybuk> devices themselves have the same style strings with all the bits filled in
[15:48] <Keybuk> therefore loading the right module for a device is simply a matter of calling "modprobe $MODALIAS" (from the device)
[15:48] <Keybuk> and letting modprobe do the fnmatch() against the wildcarded aliases it has in its list
[15:48] <Keybuk> it sorts those based on modules.order (the file from the kernel tree that lists the official order), then expands deps
[15:49] <Keybuk> module loads
[15:49] <Keybuk> and the kernel does basically the same thing again to bind the driver in the module to the device
[15:49] <Keybuk> that's all there is to it ;)
[15:50] <soren> What calls modprobe? udev?
[15:50] <Keybuk> right
[15:50] <Keybuk> devices have kobjects associated with them when their subsystem discovers/detects/adds them
[15:50] <Keybuk> the add of the kobject makes it show up in /sys
[15:50] <Keybuk> and triggers a uevent (netlink message to userspace) informing it of the new entry in /sys
[15:51] <soren> Aha!
[15:51] <Keybuk> udev picks that up, and one of the rules tells it that any entry in /sys with a MODALIAS has modprobe called
[15:51] <soren> I knew about the kobject->sysfs mapping, but didn't know about the link to udev and from there to modprobe. That's clever.
[15:52] <Keybuk> udev also gets messages from the kernel when any object in /sys is removed
[15:52] <soren> You realise, of course, that now that I'm at the brink of understanding all of this, it will inevitably change completely, right?
[15:52] <soren> I'm just saying.
[15:52] <Keybuk> and "change" messages when the subsystem feels that the object has changed significantly enough for userspace to care
[15:52] <Keybuk> as well as loading modules if there's a MODALIAS
[15:52] <Keybuk> udev also creates nodes in /dev if there's a MAJOR/MINOR pair
[15:52] <Keybuk> (and removes them again on remove)
[15:53] <Keybuk> as well as all sorts of other interesting and fun things
[15:53] <Keybuk> the latest bit of udev fun (which davmor2 *adores*) is that udev creates inotify watches on block devices it makes
[15:53] <Keybuk> ie. /dev/sda1, /dev/md0, /dev/mapper/root, etc.
[15:53] <soren> Why?
[15:54] <Keybuk> if something opens the block device for writing, then when it closes it again, udev triggers a "change" event on the sysfs object
[15:54] <Keybuk> (and thus reacts to it itself)
[15:54] <soren> Oh. That sounds potentially useful.
[15:54] <Keybuk> ls -l /dev/disk/by-uuid
[15:54] <davmor2> soren: because it hates me being able to run one test after another :)
[15:54] <Keybuk> 1234-5678 -> /dev/sda1
[15:54] <Keybuk> mkfs /dev/sda1
[15:54] <Keybuk> ls -l /dev/disk/by-uuid
[15:54] <Keybuk> dead-beef -> /dev/sda1
[15:55] <soren> Keybuk: Cool. This is a recent change, isn't it?
[15:55] <Keybuk> ie. udev runs vol_id on block devices to find out what's in them
[15:55] <soren> Keybuk: Right.
[15:55] <Keybuk> if you write to the raw block device, it'll run vol_id again to see what you changed
[15:55] <Keybuk> and update things like it's symlinks
[15:55] <Keybuk> this means /dev/disk/by-* now automatically update
[15:55] <soren> Keybuk: I'm rather sure I've mkfs'ed something before and had to poke udev before the symlinks were updated.
[15:56] <superm1> Keybuk, so if you say write a new mbr  to a device, you wouldnt need to use sfdisk to re-read the partition table again?
[15:56] <soren> I might have been a while, though. Like a year or so.
[15:56] <Keybuk> and will mean that the Emergency-HAL-Hologram will be always up to date ;)
[15:56] <soren> superm1: You've always been able to do that with blkdev.
[15:56] <Keybuk> superm1: if you change the partition table, you still need to tell the kernel you've done it
[15:56] <soren> superm1: Err... blockdev, I mean.
[15:56] <Keybuk> udev doesn't do that
[15:57] <superm1> Keybuk, okay that's what I was thinking.
[15:57] <Keybuk> soren: easier with partprobe ;)
[15:57] <Keybuk> soren: right
[15:57] <Keybuk> this is very new stuff
[15:58] <Keybuk> ie. the last three upstream releases of udev or so
[15:58] <soren> Keybuk: So post-intrepid for us.
[15:58] <soren> Ok, that explains. Cool stuff, though.
[15:58]  * soren needs to run for a while...
[16:20] <doko> calc: does it fail on i386?
[16:21] <doko> rtg: current package in jaunty?
[16:22] <rtg> doko: which package? gcc-4.3.3 ?
[16:24] <doko> rtg: I don't know, you did raise the issue ...
[16:24] <rtg> doko: https://bugs.edge.launchpad.net/ubuntu/+source/gcc-4.3/+bug/343724
[16:25] <rtg> dunno if my analysis is correct
[16:25] <calc> doko: only fails on i386 it works on amd64
[16:25] <doko> calc: so no buildd problem?
[16:25] <calc> doko: fails seemingly every time on i386 and passes every time on amd64
[16:25] <calc> doko: buildd fails since it is i386
[16:26] <calc> doko: also fails for me in testing on i386 (to be clear)
[16:29] <doko> dh_shlibdeps -pgcc-4.3
[16:29] <doko>  /etc/magic, 4: Warning: using regular magic file `/build/buildd/file-4.26/debian/tmp/usr/share/file/magic'
[16:29] <doko> dh_gencontrol -pgcc-4.3 -- -v4.3.3-5ubuntu3 '-Vgcc:Version=4.3.3-5ubuntu3' '-Vgcc:EpochVersion=1:4.3.3-5ubuntu3' '-Vgcc:SoftVersion=4.3.3-1' '-Vgpc:Version=' '-Vgdc:Version=' '-Vgcj:Version=4.3.3-5ubuntu3' '-Vgcj:SoftVersion=4.3.3-1' '-Vgcj:BaseVersion=4.3' '-Vgnat:Version=4.3.3-5ubuntu3' '-Vbinutils:Version=2.19.1' '-Vdep:libgcc=libgcc1 (>= 1:4.3.3-5ubuntu3)' '-Vdep:libgccbiarch=' '-Vdep:libcdev=libc6-dev (>= 2.5)' '-Vdep:libcb
[16:29] <doko> iarch=' '-Vdep:libcbiarchdev=' '-Vdep:libunwinddev=' '-Vdep:libcxxbiarch=' '-Vdep:libcxxbiarchdbg=' '-Vdep:libgnat=' '-Vdep:ecj=libecj-java (>= 3.3.0-2)' '-Vdep:libgomp=libgomp1 (>= ${gcc:Version})' '-Vdep:gcj=gcc-4.3 (>= 4.3.3-1)'
[16:29] <doko> dpkg-gencontrol: warning: unknown substitution variable ${dep:libssp}
[16:29] <doko> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
[16:29] <doko> dpkg-gencontrol: warning: unknown substitution variable ${gcc:multilib}
[16:29] <doko> so there seems to be a problem with dh_shlibdeps
[16:29] <doko> rtg: ^^^
[16:30] <doko> no package has the shlibs:Depends information
[16:30] <doko> see http://launchpadlibrarian.net/23822107/buildlog_ubuntu-jaunty-lpia.gcc-4.3_4.3.3-5ubuntu3_FULLYBUILT.txt.gz
[16:33] <rtg> doko: thats quite a bit outside of my skill set. shall I just assign the bug to you?
[16:35] <doko> rtg: yes, please do. will make a no change upload to the PPA first to see if this is a buildd issue
[16:37] <rtg> doko: done. feel free to change the bug subject if I've not gotten it correct.
[16:47] <rtg> kirkland: why do my chroots annoy me with ecryptfs cruft after exiting the session: 'keyctl_search: Required key not available. Perhaps try the interactive 'ecryptfs-mount-private'
[16:47] <rtg> intrepid host, jaunty chroot
[16:50] <bryce_> morning rtg
[16:51] <rtg> bryce_: no update from Alex yet this morning
[16:52] <bryce_> I see he put out 6.12.0 over the weekend, so I'll be merging that in today
[16:52] <rtg> bryce_: thats an xorg driver?
[16:52] <bryce_> yes
[16:55] <doko> slangasek: any update on #328035 ?
[17:01] <doko> rtg, slangasek, infinity: lpia is broken, no recently built package has the shlib:Depends substituted
[17:09] <pitti> eww!
[17:16] <Riddell> bryce_: pitti mentioned there were new intel drivers that needed testing, do you know where I'd find them?
[17:16] <doko> first broken upload is network-manager_0.7.1~rc3-0ubuntu1
[17:16] <doko> just after the file upload
[17:57] <NCommander> ScottK, ping?
[17:57] <ScottK> NCommander: Pong.
[17:58] <NCommander> ScottK, feel like considering a feature freeze exception? I need a new package to go into the archive (well, two).
[17:59] <NCommander> (I also need a second +1 on REVU)
[17:59] <ogra> NCommander, i think our mobile-team delegate is StevenK
[17:59] <ScottK> Probably not, but I assume you wouldn't ask unless it was important ....
[17:59] <ogra> (though i'm sure ScottK can overrule)
[17:59] <ogra> ScottK, it is
[17:59] <NCommander> ogra, I thought for delegations only applied for existing packages; they need the team support for new
[17:59] <ScottK> If it's for Mobile, then I'd say talk to your delegate first.
[17:59] <NCommander> (I may be wrong)
[17:59] <ScottK> NCommander: Nope.
[17:59] <NCommander> Oh
[17:59] <NCommander> Well
[17:59] <NCommander> ScottK, can you +1 my package?
[18:00] <ScottK> Particularly if it's StevenK then he can also agree to New them and not impact anyone else ....
[18:00] <ScottK> NCommander: Not right now.  Maybe tonight.
[18:00] <NCommander> ScottK, thanks
[18:01] <ogra> ScottK, would be really appreciated by the ARM branch of our team :)
[18:01] <ScottK> NCommander: What package?
[18:01] <NCommander> ScottK, ecosconfig-imx
[18:01] <ogra> http://revu.ubuntuwire.com/p/ecosconfig-imx
[18:01] <NCommander> ScottK, http://revu.ubuntuwire.com/p/ecosconfig-imx
[18:01] <ScottK> Thanks.
[18:01] <NCommander> Ooh, ogra beat me to it
[18:01] <ogra> :)
[18:02] <NCommander> thanks ogra (BTW, you still haven't plused 1 it :-P_
[18:02] <pitti> Riddell: Do you figure I can remove the X-KDE-SubstituteUID=true from jockey-kde's .desktop, now that there's a working policykit-kde?
[18:02] <ogra> NCommander, ??
[18:02] <NCommander> ogra, on REVU
[18:03] <ogra> NCommander, i checked the "advocate this upload" box
[18:03] <ogra> what else do i need to do nowadays ?
[18:03] <NCommander> Oh, you did?
[18:03]  * NCommander just didn't refresh in the last 30 seconds
[18:03] <NCommander> :-)
[18:03] <ogra> heh
[18:05] <NCommander> wow, nifty
[18:05] <NCommander> on needs-packaging bugs, if you have a *package*/ubuntu branch, it auto assiocates the branch.
[18:06] <ScottK> NCommander: I don't suppose you'd be able to look at kdeaccessibility on armel?  FTBFS due to what looks like your speciality.
[18:06] <Riddell> pitti: good question.  just needs testing I guess.  remind me again how I'd test it?
[18:06] <NCommander> ScottK, sure, I've been meaning to look at it, but things have been a little crazy.
[18:07] <ScottK> OK.  Good.
[18:07] <ScottK> NCommander: Amarok too if you feel motivated (it finally built on power pc).
[18:07] <NCommander> ScottK, I'm going to make one final pass of the main ARM FTBFS (and any obvious fix universe ones) just before beta freeze
[18:08] <ScottK> OK.
[18:08] <NCommander> Riddell, you got five minutes? I need a +1 on REVU
[18:10] <ScottK> Riddell: Make him fix kdeaccessibilty and amarok on arm first.
[18:10] <ScottK> ;-)
[18:10] <pitti> Riddell: just remove the X-KDE-SubstituteUID=true from the .desktop, or call "jockey-kde" as user from a terminal, and try to install a driver
[18:10] <pitti> Riddell: if you don't have nvidia/ati, I can toss you a test driver
[18:12]  * cjwatson attempts to think of a sane way to detect UTF-8 strings that are not also ASCII strings using only the facilities in busybox
[18:12] <cjwatson> (so no iconv, which would make it easy)
[18:12] <pitti> Riddell: you can drop http://people.ubuntu.com/~pitti/tmp/pkg.py into /usr/share/jockey/handlers/, sudo killall jockey-backend, and try to install that handler
[18:12] <cjwatson> really I suppose all I need is a bytewise check for top-bit-set bytes
[18:12] <pitti> Riddell: it'll just install pmount
[18:12] <NCommander> cjwatson, I thought busybox had an iconv module (although if we compile it in is another story)
[18:13] <pitti> cjwatson: I had that problem a while ago and eventually just resorted to perl :(
[18:13] <cjwatson> NCommander: it does not
[18:14] <cjwatson> maybe LC_ALL=C tr '\0-\177' '' and check for equality
[18:15] <cjwatson> hmm I mean tr -d '\0-\177' obviously, although that doesn't seem to work
[18:16] <Riddell> pitti: doesn't seem to work with or without sudo :(
[18:16] <Riddell> pitti: if I click Activate the list item is greyed out and nothing else happens
[18:17] <pitti> Riddell: uuh; I guess I'll take a close look at jockey-kde tomorrow morning on my box
[18:18] <ogra> cjwatson, dd and stty magic ?
[18:18] <ogra> i assume there is a reciepe for conversion somewhere
[18:19] <ogra> but it will be a slow bloated parser script
[18:19] <cjwatson> tr -cd '\000-\177' works in coreutils tr but not busybox. hmm.
[18:20] <cjwatson> ogra: I certainly don't want to do full-blown conversion by hand
[18:20] <ogra> yeah, its painful
[18:30] <estan> hm. i've built my own linux-ubuntu-modules package, is there a way to forcefully replace the one i have installed with my own using dpkg? sorry i'm a bit new to debian stuff.
[18:32] <estan> trying to remotely help a friend get his webcam working on his old hardy laptop, i'm suspecting the camera is in fact supported by the gspca module, just that the model id is not recognized, so i'm patching the driver and rebuilding a linux-ubuntu-modules package for him to test.
[18:33] <Stskeeps> dpkg -i file.deb? :P
[18:33] <estan> and also, why is there no Ubuntu-2.6.24-23.48 tag in linux-ubuntu-modules ? (e.g. git tag | grep Ubuntu*)
[18:33] <estan> Stskeeps: uhm. that easy huh? ;)
[18:34] <Stskeeps> if i understand you correctly :P
[18:34] <estan> indeed it seems it's working.. man his laptop is a slow piece of crap, heh.
[18:35] <estan> ok. i haven't actually done the modification yet, just want to see that i can build a deb first.. so after i do the modification, and then build it again, i can just install it with dpkg -i again, or will it complain that it's already installed?
[18:36] <estan> (i'm building the deb with `debian/rules binary-debs`)
[18:36] <estan> err i mean: fakeroot debian/rules binary-debs flavours="generic"
[18:42] <cjwatson> estan: dpkg -i will upgrade if it's already installed, yes. (also, #ubuntu ...)
[18:42] <estan> cjwatson: alright. thanks.
[18:44] <mpt> Can anyone tell me what the process is for getting something into Ubuntu's release notes?
[18:45] <estan> cjwatson: hm. do you know how i can kick it into building the modules again after i made a modification? just running fakeroot debian/rules binary-debs flavours="generic" again it doesn't seem to pick up that there's been modifications (i.e. it's not running make again).
[18:48] <doko> ohh, all ppa buildds used by mozilla ...
[18:50] <cjwatson> estan: you may have to remove a stamp file. Look at debian/rules.d/2-binary-arch.mk or whatever it is to see what file the relevant target touches.
[18:50] <estan> ah figured it out, just removed debian/stamps/stamp-build-generic.
[18:50] <cjwatson> mpt: open a bug task on the ubuntu-release-notes project, preferably with suggested text although it isn't mandatory. It's best if it's a task on some existing bug that documents the problem so that it's all right there for us
[18:52] <mpt> thanks cjwatson
[19:40] <kees> doko: so if I figure out how to fix 3 regressions (out of 3900 tests) you'll enable fortify for openjdk-6 again?
[19:40] <Riddell> tjaalton: do you know about the new intel driver that needs testing?
[19:41] <doko> kees: sure. maybe I should do the same with gcc-4.3 so you fix these regressions as wel ;p
[19:41] <doko> I don't mind jdi regressions if there are any.
[19:43] <kees> doko: gcc> please don't.  :P
[19:50] <kees> ct
[19:50] <kees> erk
[19:50] <kees> cjwatson: any update on how to move forward with the compiler mismatch in hardy?
[19:56] <cjwatson> kees: given security team signoff (which I have, right?), I think it's in my queue to Just Do
[19:59] <ryu> hi
[20:00] <cjwatson> kees: do I need to give you a couple of hours' warning or something for a USN?
[20:01] <slytherin> can any of the core developers please give back update-manager on powerpc? the build failure looks to be some archive problem.
[20:03] <cjwatson> kees: and intrepid is affected according to the most recent mails on the bug. I don't get it - that wasn't a major version bump
[20:04] <cjwatson> slytherin: looks more like some kind of chroot breakage to me? I think the python-distutils-extra package should be checked on powerpc before give-back to make sure there isn't anything else wrong with it
[20:06] <slytherin> cjwatson: I am currently building the package just to make sure.
[20:07] <slytherin> cjwatson: build failed with totally different error :-(
[20:07] <slytherin>  - make[1]: Leaving directory `/tmp/buildd/update-manager-0.101.0/po'
[20:07] <slytherin> cp: cannot stat `/usr/share/jockey/modaliases/nvidia-*': No such file or directory
[20:07] <slytherin> make: *** [binary-indep] Error 1
[20:10] <kees> cjwatson: just let us know when it's been copied.  it's going to be a rather weird USN anyway.
[20:13] <cjwatson> kees: done, for hardy-security
[20:15]  * kees holds onto his hat
[20:26] <jturek> exit
[20:45] <ion_> Is jaunty going to use Firefox 3.1 by default? 3.1 is already in beta and gutsy was released with 3.0 *alpha*.
[20:46] <ion_> Oh, sorry. It seems i remembered incorrectly. Gutsy didn’t use 3.0 by default after all.
[20:50] <ScottK> ion_: Hardy was released with 3.0 beta but only because 2.0 support wouldn't be long enough for an LTS.
[20:50] <ion_> Ok
[20:53] <cjwatson> also firefox 3.0 beta in hardy got negative feedback in practically every single review of Ubuntu. (I still think it was the right thing to do, and have defended it in a number of places; but all the same we'd need a good reason)
[21:20] <tjaalton> Riddell: no, but I think bryce has one in his ppa
[21:21] <bryce> heya tjaalton
[21:22] <bryce> tjaalton: what's that in reference to?  I've just put -ati 6.12.0 into ubuntu.
[21:22] <bryce> tjaalton: if it's in reference to -intel 2.6.3, no that won't build until we get some kernel changes in
[21:24] <tjaalton> bryce: hey, yeah he asked about -intel
[21:25] <Riddell> tjaalton, bryce: I'm getting funny corruption on qt apps, which I don't think anyone else is getting and wondered if it was down to something in X
[21:26] <bryce> Riddell: seems likely
[21:27] <bryce> Riddell: if you're using EXA, try UXA.  If using UXA, try EXA.
[21:27] <bryce> a lot of corruption issues go away when moving to UXA
[21:27] <bryce> unfortunately, it brings its own set of issues, so isn't something we can just upgrade to safely
[21:28] <Lure> Riddell: something like bug 279727 - I have this too
[21:30] <Riddell> Lure: that could be it, although he has it much worse than I do
[21:31] <Lure> Riddell: I get this from time to time and also a bit less than the screenshot
[21:37] <directhex> slangasek, do you have any packages you can suggest as examples for coping with symlink->dir transition properly?
[21:41] <cjwatson> directhex: symlink->dir not dir->symlink?
[21:41] <directhex> cjwatson, aye. symlinked docdirs in mono packages in past ubuntu releases are apparently a big debian policy nono, and moving to unsymlinked is causing problems on upgrades
[21:42] <cjwatson> directhex: just check if it's a symlink in the preinst and rm it
[21:43] <directhex> preinst? gotcha
[21:48] <cjwatson> directhex: right, then dpkg-deb unpacks the tarball after the preinst has run, and it sees "aha, nothing there, I shall unpack the new directory"
[21:48] <cjwatson> directhex: oh, hmm, one other thing for correctness
[21:48] <cjwatson> two other things actually :-)
[21:49] <cjwatson> directhex: firstly, you'll be doing this in preinst install|upgrade, but add a dpkg --compare-versions guard too
[21:49] <cjwatson> directhex: secondly, you should reverse the action in postrm abort-install|abort-upgrade, with the same version guard
[21:50] <directhex> cjwatson, meebey's currently spouting version comparisons at me in #debian-mono
[21:50] <directhex> ;)
[21:50] <directhex> okay, ta for tips
[21:50] <cjwatson> presumably 'if dpkg --compare-versions "$2" lt-nl "version you made this change in"'
[22:00] <cjwatson> bigon: infinity has resolved my RT ticket about removing python2.5-minimal from chroots
[22:13] <Laney> any inside info on the broken i386 buildds?
[22:14] <soren> Laney: They're not b0rken. fontconfig is, apparantly.
[22:14] <seb128> hey, asac broke fontconfig apparently
[22:14] <seb128> not only i386
[22:14] <seb128> all builds are failing on all arches ...
[22:15] <Laney> heh
[22:15] <Laney> alright
[22:15] <Laney> I've just had failure mails for i386 so far
[22:15] <Laney> oh, others are more backed up is all
[22:15] <seb128> I just got 17 build failure emails
[22:15] <seb128> asac 1 - 0 soyuz
[22:15] <Laney> awesome
[22:21] <JanC> eh, does that mean the currently available fontconfig packages are broken or fixed again?  :P
[22:33] <asac> JanC: upgrades seem to be not the issue .. rather fresh installs on the buildds
[22:33] <JanC> ah, okay, just wondering if installing those was a good idea  ツ
[22:33] <asac> JanC: which version are you running?
[22:34] <JanC> 2.6.0-1ubuntu5, but 2.6.0-1ubuntu7 is available now
[22:36] <slangasek> doko: no, 328035 will take me a while to find time for
[22:37] <slangasek> directhex: not offhand.  But the rune is preinst: rm -f $symlink
[22:41] <petski> bdmurray: your last change to https://wiki.ubuntu.com/Bugs is incorrect
[22:42] <bdmurray> petski: I see, fixing
[22:43] <petski> bdmurray: ok :) thanks
[22:49] <directhex> slangasek, cjwatson, it's the edge cases like abort-install that concern me. "just an rm" is easy, but also a little unlikely to fly
[22:52] <cjwatson> directhex: I'm pretty sure what I described is complete
[22:54] <directhex> cjwatson, at least i have one cheat up my sleeve - the test for "affected" versions is reasonably simple, as only XubuntuY packages below 2.0 are affected, i can use that in the test
[22:54] <cjwatson> I can't find any examples that get rollback right
[22:55] <cjwatson> which is a bit sad
[22:56] <directhex> i'm not 100% sure how to deal with rollback cleanly
[22:56] <slangasek> directhex: every version up to the current version is affected...
[22:56] <cjwatson> directhex: just as I described above?
[22:56] <directhex> slangasek, you're right, i wasn't considering full semantics properly
[22:56] <cjwatson> 21:49 <cjwatson> directhex: secondly, you should reverse the action in postrm abort-install|abort-upgrade, with the same version guard
[22:56] <calc> does the lpia build problem mean we need to upload all those source packages again, or does Ubuntu have the concept of a binNMU for cases like this?
[22:56] <cjwatson> i.e. ln -s there
[22:57] <cjwatson> maybe ln -nsf || true for safety
[22:57] <slangasek> calc: they'll have to be reuploaded
[22:57] <calc> fun... new OOo needed then
[22:57] <calc> is there a reason we don't support binNMUs?
[22:59] <infinity> calc: Because the times when they might be useful don't outweigh the annoyance of source<->binary mismatches, when we don't actually have issues with architectures that can't keep up.
[22:59] <infinity> calc: (And the more entertaining side-note is that you usually want binNMUs on the slow arches ANYWAY, so it's not saving them much)
[23:00] <directhex> so i need 90 new preinsts...
[23:02] <calc> infinity: ok
[23:03] <calc> unless someone decides they want to upload OOo i'll leave it until I do a new upload sometime in the next week
[23:03]  * calc is sure the buildds could use some rest from the multiple rebuilds of OOo lately
[23:03] <calc> esp arm ;-)
[23:47] <bigon> cjwatson: ok thx :)