[00:13] <donkeyinspace> hello, i tried to compile only once and it went wrong can someone help me?
[00:13] <lynxman> smoser: thanks for the pointer to that bug
[00:13] <soreau> Hey guys, is there anywhere I can find the source for ubuntu's gdm? I'm trying to figure out what happens (or what's supposed to happen) when switching sessions.
[00:14] <soreau> Selecting classic ubuntu worked the first time I tried it but since switching to ubuntu and back to classic, both load unity regardless no matter what I do
[00:15] <cjwatson> soreau: apt-get source gdm
[00:18] <soreau> cjwatson: thanks
[00:21] <donkeyinspace> have 1 cd with ubuntu 11.04 alpha and 3 cds with ubuntu 11.04. the alpha one was burned in windows and i could be able to install it one or two times, know it crash . about the 3 ubuntu 11.04 two were burned using brasero and one was burned under windows the one burned in windows is the one that reaches far in the installation
[00:22] <donkeyinspace> what can i do knw?
[00:22] <donkeyinspace> *know
[00:23] <donkeyinspace> my hard drive is not very well but  can install 10.10 whenever needed
[00:27] <holstein> donkeyinspace: come to #ubuntu-beginners
[00:43] <soreau> I have to say, Natty is by far the most incoherent version of ubuntu I've ever seen and I've been using this distribution since Hoary
[00:43] <soreau> Ubuntu has let me down and I am very disappointed
[06:03] <pitti> Good morning
[06:08] <Captainkrtek> hello
[06:09] <mfilipe> hello guys! I'm using linux-image with generic-pae but I want compile the same kernel with a patch applied. I installed linux-source-2.6.38, copied config-2.6.38-8-generic-pae to .config in linux-source dir and compiled with kernel-package. My problem is that I get kernel panic without patch applied. Anyone knows what is wrong?
[06:10] <mfilipe> here is the best channel for support that?
[06:16] <pitti> hmm, a lot of armel builds fail with  "apt-cache exit status 11"; what the heck?
[06:30] <abhinav-> pitti: in Gdk 2.0 there seem to be another case of missing annotation. I am not able to find the method Gdk.get_default_root_window() , although the C API documents it for GDK 2.0
[06:48] <pitti> hey abhinav-
[06:48] <pitti> abhinav-: checking
[06:48] <abhinav-> hi pitti , thanks :)
[06:48] <pitti> abhinav-: right, see /usr/share/gir-1.0/Gdk-2.0.gir:
[06:48] <pitti>     <function name="get_default_root_window"
[06:48] <pitti>               introspectable="0">
[06:49] <pitti> abhinav-: the .gir is the human readable API description
[06:49] <pitti> abhinav-: introspectable="0" means that it isn't possible to safely bind this function for some reason
[06:49] <pitti> presumably missing transfer annotation, /me looks
[06:50] <pitti> abhinav-: it does work in Gdk-3.0, though; I thought you are using that anyway?
[06:50] <abhinav-> pitti: yes I was trying for Gdk 3.0 but then I am not able to find the relevant functions in Cairo API
[06:51] <abhinav-> I asked on their mailing list but didn't get any reponse
[06:51] <pitti> ah, too bad
[06:51] <pitti> we have to use gtk3 in oneiric
[06:51] <abhinav-> yes I understand, using Gtk 3 is better
[06:52] <abhinav-> maybe I should ask on #gtk+
[06:52] <abhinav-> about cairo
[06:53] <pitti> abhinav-: sorry for being a guinea pig for all this..
[06:55] <abhinav-> pitti: no problem, I get to learn a lot from these problems. if I don't face problems there is no learning :)
[06:55] <pitti> and they help to improve GTK, too :)
[06:55] <abhinav-> yes :)
[06:55] <pitti> GI is still fairly new, and thus we still uncover a lot of bugs along the way
[06:57] <ScottK> pitti: Bug #774175 (re the armel failures)
[06:57] <abhinav-> yes, like yesterday I tried converting my script for Gtk3 directly using the pygi-convert.sh script, but it missed a few things in the conversion
[06:57] <pitti> ScottK: ah, thanks; I suppose there will be a mass give-back after that, so we don't need to track the build failures individually
[06:57] <ScottK> I certainly hope so.
[06:57] <pitti> abhinav-: oh, do you still know which? I'm happy to add stuff to it
[06:58] <abhinav-> pitti: yes, I know, I had to do that manually :)
[06:58] <abhinav-> I will paste it on pastebin and give you in a moment
[07:00] <abhinav-> pitti: python-cairo and pycairo are the same libraries ?
[07:01] <pitti> abhinav-: pycairo is the source package/upstream project name, python-cairo is the binary package built from it
[07:02] <abhinav-> ah ok.
[07:02] <pitti> abhinav-: but actually I think that you should use python-gobject-cairo instead
[07:02] <pitti> I'm not sure, maybe ask in #python?
[07:02] <pitti> that's the one built by pygobject
[07:02] <pitti> I have no idea about the difference
[07:02] <abhinav-> hm ok
[07:08] <abhinav-> heh I didn't know there was a #python channel on freenode as well. asked the question there now :)
[07:08] <pitti> abhinav-: bad time of the day, of course (still too early for Europeans, and Americans are asleep)
[07:09] <abhinav-> hm yeah :-/
[07:15] <lucidfox> Why have armel builds been failing lately?
[07:17] <pitti> lucidfox: bug 774175
[07:20] <abhinav-> pitti: I was wrong, there was only one thing that I had to change manually in converting from Gtk2 to Gtk3 http://paste.ubuntu.com/603120/
[07:20] <lucidfox> danke
[07:31] <pitti> abhinav-: hm, that should already happen, hang on
[07:32] <abhinav-> pitti: this was my script: https://bugs.launchpad.net/apport/+bug/772336/+attachment/2092936/+files/select_window.py
[07:33] <pitti> abhinav-: ah,, got it
[07:36] <pitti> abhinav-: fixed in upstream trunk
[07:36] <abhinav-> pitti: thanks :)
[08:47] <jussi> a) is anyone aware of a workaround for this bug? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/700910
[08:47] <jussi> b) can anyone help me give descriptive information to help solve the bug?
[08:48] <cjwatson> jussi: the simplest workaround is to reinstall GRUB using a chroot: https://help.ubuntu.com/community/Grub2#METHOD%203%20-%20CHROOT
[08:48] <cjwatson> jussi: I was planning to have another go at reproducing that bug shortly
[08:49] <jussi> cjwatson: ok, Im happy to provide any info you like to ask for - Im just not sure what you want
[08:49] <jussi> hang on, let me join from the other PC
[08:50] <cjwatson> I don't think it needs further information
[08:50] <cjwatson> I just hadn't initially realised that trying to reinstall GRUB from a live CD without chrooting was how to trigger it
[08:51] <jussio1> ok >(
[08:52] <jussio1> cjwatson: could you pass that link again ?
[08:53] <cjwatson> https://help.ubuntu.com/community/Grub2#METHOD%203%20-%20CHROOT
[08:53] <jussio1> cjwatson: ahh, just saw your other comment. no probs. if theres anything you need let me know.  :) And thank you for the workaround.
[08:57] <jussio1> hrm, grub recheck gives me a warning. Is it related?
[08:57] <jussio1> /usr/sbin/grub-setup: warn: Sector 33 is already in use by FlexNet; avoiding it.  This software may cause boot or other problems in future.  Please ask its authors not to store data in the boot track.
[08:59] <cjwatson> dupondje: please check with the person listed as touched-it-last on merges.ubuntu.com before proposing merges/syncs
[09:00] <cjwatson> dupondje: that's the protocol to avoid duplicated effort
[09:11] <dupondje> cjwatson: I forgot indeed :( my excuses.
[09:57] <lucidfox> http://revu.ubuntuwire.com/p/gringo <-- Is "package name is an ethnic slur" a valid reason for rejection? :)
[09:57] <pitti> cjwatson: ok for me to do a new-source sync round, or are you going to?
[09:59] <cjwatson> pitti: go ahead, but perhaps wait until LP comes out of read-only mode
[09:59] <pitti> oh, is it still? I have done archive admin stuff for some 10 minutes now
[10:00] <pitti> (NEW and NBS cleanup mainly)
[10:00] <cjwatson> topic still says it is; personally I wouldn't want to try inserting stuff into queues in RO mode
[10:00] <pitti> sure, I'll wait then; not urgent at all
[10:01] <Laney> seems it's RW again; at least the banner is gone and I can push
[10:01] <seb128> the ui doesn't have the readonly warning and people do bug updates, I just got a bunch of emails
[10:01] <cjwatson> ah, ok
[10:02] <cjwatson> pitti: go ahead then :)
[10:04] <cjwatson> @pilot in
[10:04] <pitti> "udevbot"? nice :)
[10:10] <doko> jhunt_, SpamapS: please could you take care of the libnih merge?
[10:11] <doko> SpamapS: same for sysvinit
[10:18] <jhunt_> doko: I'll discuss with SpamapS, but don't think I have the relevant "super-powers" yet.
[10:18] <cjwatson> you would need sponsorship, but you can prepare the merge as you would prepare an upload
[10:19] <cjwatson> if it needs a merge rather than a verbatim sync, that is
[10:19] <cjwatson> hopefully we don't have much in the way of Ubuntu-specific changes to libnih?
[10:20] <kzmdmzk> Hi, is anyone able to comment on the status of https://wiki.ubuntu.com/NotifyOSD#Treatment%20of%20hardware%20device%20detection ? Specifically if it's being worked on/completed/etc.
[10:21] <jhunt_> cjwatson: merges.u.c is just showing a conflict in debian/control.
[10:23] <cjwatson> the first thing to figure out is whether there are any Ubuntu-specific changes we need to keep, or whether we can just take the package from Debian
[10:23] <cjwatson> if the latter, https://wiki.ubuntu.com/SyncRequestProcess
[10:23] <jhunt_> right, thx.
[10:23] <cjwatson> requestsync --lp can do most of the work for you there
[10:28]  * pitti does a process-removals run during the new-source sync/fail/fix iterations
[10:55] <doko> tkamppeter_: please could you take care of the ghostscript merge?
[11:00] <pitti> dpm: FYI, reenabled maverick-updates cron job and added natty-updates
[11:20] <abhinav-> pitti: I asked the question on #Gtk+ about using pycairo , I think we struck a dead end here. http://paste.ubuntu.com/603204/
[11:21] <dpm> thanks pitti, I'll have to have a look at any changes necessary to the exports schedule. I'll try to get it done before UDS.
[11:27] <pitti> abhinav-: erk, that sounds like "fun" :/
[11:27] <abhinav-> :-/
[11:48] <abhinav-> pitti: where can I find the gir-1.2 files ? /usr/share/gir-1.0 has all gir1.0 versions
[11:49] <pitti> abhinav-: those are the correct files; unfortunately the binary packages are misnamed
[11:49] <abhinav-> oh
[11:49] <pitti> abhinav-: the binary packages should be called typelib-1.2-foo, not gir-1.2-*
[11:49] <pitti> since they neither ship the gir files (these are in -dev) nor are related to the gir format specification 1.0
[11:49] <pitti> 1.2 is the binary ABI of the typelibis
[11:50] <abhinav-> ah alright. /me looks
[11:51] <doko> slangasek: doing the perl merge now
[11:51] <pitti> abhinav-: i. e. *.gir files are mostly for human inspection, *.typelibs are a compiled form of them which are actually used by pygobject, seed, vala, etc.
[11:52] <abhinav-> pitti: yes, so I wanted to look at Gdk-3.0.gir , but /usr/share/gir-1.0/ has Gdk-2.0.gir instead
[11:53] <pitti> abhinav-: you need libgtk3-dev
[11:53] <pitti> which ships the gtk 3 gir
[11:53] <abhinav-> oh
[11:53]  * abhinav- installs
[11:53] <pitti> abhinav-: the typelibs are needed at runtime, but the .gir isn't, so we ship that in the -dev package
[11:53] <abhinav-> pitti: that makes sense. thanks :)
[12:51] <BlackZ> cjwatson: re curl: yes, I will file a bug for the MIR
[12:55] <cjwatson> BlackZ: thanks
[13:07] <lamont> more ppa builders are in bound (installing as of a few min ago)
[13:10]  * soren hugs lamont
[13:13] <lamont> and sometime this morning, I expect that I'll be putting the armel builders on manual for a bit while I play with gcc-4.6 rebuild
[13:13] <ScottK> This is the fix for the apt problem?
[13:13] <cjwatson> oh good
[13:13] <lamont> ScottK: the gcc-4.6 problem, yes.
[13:14] <ScottK> Great.
[13:14] <soren> lamont: How many build servers are you adding back?
[13:14] <lamont> soren: all the ones we stole for the release
[13:15] <soren> lamont: W00t!
[13:21] <lamont> then once I get that mess built, I get to mass giveback the failures on oneiric/arm after rebuilding chroot tarballs for everything
[13:23] <abhinav-> pitti: it looks depressingly hopeless to do in Python. next best options are to use 1) xwd and xwud , 2) add this code in gnome-screenshot
[13:24] <pitti> abhinav-: I forgot, what was the problem with using xprop?
[13:25] <pitti> abhinav-: _NET_WM_PID seems to give you the pid
[13:25] <abhinav-> pitti: xprop doesn't provide screenshot related features ?
[13:25] <pitti> abhinav-: ah, right
[13:26] <abhinav-> pitti: xwd does capture the screenshot but in some other format that can be viewed by xwud
[13:37] <pitti> hmm, new-source run done; should I really spam oneiric-changes with 865 packages?
[13:37] <pitti> cjwatson: ^ what did you use to do in the past?
[13:38] <cjwatson> I think I considered those mass syncs and used NOMAILS=-M
[13:38] <cjwatson> (NOMAILS=-M flush-syncs)
[13:38] <pitti> I agree; I just seem to remember a time when these got announced
[13:39] <soren> I'm not sure I understand why you'd filter them.
[13:40] <soren> Yes, it's a lot of info, but why is that a problem?
[13:40] <pitti> hm, it seems someone actually deleted my older syncs from a few hours ago
[13:41] <pitti> Riddell, jdstrand: ^ any idea what happened to them? I only have the new syncs starting with 's' left
[13:41] <cjwatson> that's very careless of somebody!
[13:41] <cjwatson> if the syncs directory has content, LEAVE IT ALONE
[13:42] <cjwatson> soren: *shrug* caused complaints in the past - so the probably-unwritten policy is now that we send announcements for manually-requested syncs
[13:42] <pitti> it took some two hours to get it to that state..
[13:42] <cjwatson> pitti: they might be in ~lp_queue/sync-queue/ somewhere?
[13:42] <cjwatson> if somebody deleted it more permanently than that, make them spend two hours redoing the state :-P
[13:42] <pitti> well, it wasn't human hours, but still
[13:43] <ScottK> Hand them a pencil and paper and tell them to get to work.
[13:44] <pitti> ./rejected/pitti-20110504-123857/ looks a bit weird, but far from complete
[13:44]  * pitti shrugs and runs it again; at least I have the list of the successful ones now, so should be much quicker
[13:47] <Riddell> not me, I'm not doing archive admin this cycle
[13:47] <seb128> not me either
[13:49] <pitti> ah, seems someone actually flushed them, instead of delete
[13:50] <cjwatson> that's bad form too - since some sync runs require -M and some don't
[13:50] <cjwatson> I don't see them on oneiric-changes though
[13:50] <pitti> at least NEW is full of them, and I mostly emptied them this morning
[13:50] <pitti> but it still doesn't have everything
[13:50] <pitti> very confusing
[13:51] <pitti> anyway, at this point it's easiest to flush what we have and re-run it tomorrow
[13:51] <lamont> doko: 4.6 building on actinidiaceae
[13:52] <cjwatson> pitti: let me know when you're done - I'd like to do a regular sync run
[13:52] <pitti> q -M -e accept $(</tmp/pitti/newdone)
[13:52] <pitti> running that, then it's cleared for you; I'll ping you
[13:52] <cjwatson> ta
[13:56] <seb128> cjwatson, pitti: syncs done without a -b don't email the list I think
[13:56] <pitti> ah, that'd make sense; I explicitly specified -M to be sure
[13:58] <jdstrand> pitti: I have not been on cocoplum today
[14:00] <Laney> pitti: is 'ghc' one of the packages you are syncing?
[14:00]  * Laney trembles
[14:01] <pitti> Laney: it failed because it overlaps with our ghc6 source
[14:01] <pitti> Laney: so far I only synced packages which don't conflict
[14:01] <Laney> oh, ok
[14:01] <pitti> we have to wade through the others step by step
[14:01] <Laney> that's intentional
[14:01] <pitti> I haven't checked yet, but presunably we need to remove ghc6 and sync ghc
[14:01] <Laney> no, ghc needs ghc6 to bootstrap
[14:02] <Laney> might need some manual hackery though if debian already switched the BDs
[14:04] <Laney> yeah i'll need to add ghc6, never mind
[14:05] <cjwatson> BlackZ: thanks for fixing the rsyslog issues.  Could you tell me what testing you've done with this merge?  It didn't look like the original patch had been tested.
[14:06] <pitti> oh, someone works on rsyslog?
[14:06] <pitti> I just tested my merge, and it's completely broken
[14:06] <cjwatson> pitti: bug 775703
[14:06] <pitti> ah, I didn't check bugs, as I was TIL
[14:07] <cjwatson> BlackZ: why didn't you ask the touched-it-last person before starting?
[14:07] <pitti> anyway, the only kind of log output that I get with that version is "imklog 5.8.0, log source = /proc/kmsg started." and a complaint about /dev/xconsole, over and over again
[14:07] <pitti> but no real messages
[14:09] <pitti> it's not the priv dropping, and the blurb about xconsole in the configuratino is also harmless
[14:17] <dupondje> cjwatson: thanks for the info :)
[14:17] <BlackZ> cjwatson: I didn't do an extensive test; also, I'm the last person who merged it so I thought nobody was merging it. Is it broke for you, btw?
[14:19] <cjwatson> BlackZ: the protocol is that the last person who *uploaded* it should be assumed to be dealing with the merge unless you check
[14:19] <cjwatson> this is at the top of https://merges.ubuntu.com/main.html
[14:19] <cjwatson> "If you are not the previous uploader, ask the previous uploader before doing the merge. This prevents two people from doing the same work."
[14:19] <cjwatson> that was Martin, not you, in this case
[14:20] <cjwatson> BlackZ: the reason I'm concerned isn't because I've tested it myself, but because (a) the first posted debdiff was broken (b) the last time you merged rsyslog, in natty, it completely broke logging (c) rsyslog is kind of important.  I hope you understand my caution :-)
[14:21] <cjwatson> also, you actually weren't the last person to merge it, I was
[14:22] <cjwatson> if pitti's having problems, it seems reasonable to find out whether there's something different between your merge and his; if both are broken, we should try to resolve it before uploading
[14:24] <cjwatson> dupondje: BTW, I have no problem with people taking some of the installer merge workload off my shoulders; if it's done with our existing bzr branches, though, it means that it could decrease my workload rather than increasing it :-)
[14:24] <cjwatson> (I don't mind a temporary increase in the cause of training folks)
[14:26] <BlackZ> cjwatson: right, you're the last person who merged it; sorry, I assumed I was. Yeah, I should have contacted the T.I.L person before merging it. I will be happy to work with pitti if he has problem with the rsyslog merge (in case the debdiffs are the same)
[14:26] <BlackZ> cjwatson: and yeah, I understand your caution ;)
[14:27] <cjwatson> I think pitti is wrestling with why it's broken now - I'll hand over to him
[14:27] <cjwatson> @pilot out
[14:27] <BlackZ> cjwatson: thanks for your reviewing ;)
[14:28] <jcastro> jjohansen: Reminder: your apparmor session is on for 1700UTC today
[14:29] <jjohansen> jcastro: okay thanks
[14:31] <cjwatson> pitti: syncs is empty now - are you finished?
[14:32] <pitti> cjwatson: ah, it's done (sorry, left it in the background
[14:32] <cjwatson> np
[14:36] <lynxman> hey guys, anybody knows in which conditions does a preinst script triggers?
[14:36] <lynxman> I have a metapackage that points to another metapackage (with the preinst script) and script doesn't run
[14:40] <cjwatson> lynxman: it's always called immediately before unpacking a package.  I think I might be able to answer you better if I saw an example
[14:40] <lynxman> cjwatson: sure! it's a bit of a chain effect, kinda related to what we were talking yesterday :)
[14:41] <lynxman> I'm deploying a machine in UEC, it starts with no hostname in /etc/hosts
[14:41] <lynxman> just to test a small preinst check I did
[14:41] <lynxman> so I install the metapackage that depends on a bunch of real packages
[14:41] <lynxman> and I add a preinst script to the metapackage to check that the hostname is in /etc/hosts if not add it and point to 127.0.1.1
[14:42] <lynxman> I just tried the package now and it doesn't do it
[14:42] <cjwatson> adding non-trivial code to a metapackage makes it technically not really a metapackage any more; but anyway, that's incidental
[14:42] <cjwatson> can you provide a pointer to the package, or post the preinst on paste.ubuntu.com, or something?
[14:42] <dob1> hi, i have installed sun jdk on 11.04, now i want to install groovy but ubuntu want to install openjdk and it doesn't use sun-jdk that is just installed, this is a bug?
[14:43] <lynxman> cjwatson: yes, was doing that right now :)
[14:44] <lynxman> cjwatson: http://pastebin.ubuntu.com/603277/
[14:45] <cjwatson> lynxman: hm, any chance of just putting a copy of the whole source package somewhere?
[14:45] <lynxman> cjwatson: it's actually in a ppa, let me get you the link
[14:45] <cjwatson> that's the sort of thing one would normally do in postinst rather than preinst, BTW - there doesn't seem any particular need to run it before unpacking files
[14:45] <cjwatson> (but again, that's sort of incidental)
[14:46] <cjwatson> rule of thumb - only use preinst or pre-depends if you absolutely have to and know why :-)
[14:46] <lynxman> cjwatson: the thing is that it's needed for a package to deploy properly, otherwise I get a "package couldn't install properly" and the whole process falls off
[14:47] <lynxman> cjwatson: I've been devoring the packaging guide lately :)
[14:48] <cjwatson> that suggests a different problem.  deployment should not require using preinst for this AFAICS.
[14:49] <cjwatson> unless it's required by one of the dependencies of this metapackage, in which case this code should be in that dependency, not in the metapackage
[14:49] <lynxman> cjwatson: yeah completely agreed, it's just a temporary stopgap measure
[14:49] <cjwatson> generally, if the user decides to install all the dependencies of a metapackage manually and not the metapackage itself, the system should work the same way (except for later upgrade resolution)
[14:50] <mdeslaur> slangasek: could #776030 be multiarch related?
[14:50] <lynxman> cjwatson: yeah
[14:50] <lynxman> cjwatson: I've submitted a bug already for the affected packages
[14:51] <lynxman> cjwatson: rabbitmq-server and collectd
[14:52] <lynxman> cjwatson: source in https://launchpad.net/~orchestra/+archive/ppa/+packages
[14:52] <stgraber> slangasek: mind if I take the ucf merge (you are the last uploader for a multiarch fix) ?
[14:53] <cjwatson> lynxman: which source package am I looking at here?  orchestra?
[14:53] <lynxman> cjwatson: yes
[14:55] <cjwatson> lynxman: looks fine - try putting 'set -x' on the second line of the preinst, which should give you a trace when you install it
[14:55] <lynxman> cjwatson: cool, will try that, thanks :)
[14:56] <cjwatson> lynxman: incidentally, replace  grep -qs "127.0.1.1\W"  with  grep -qs "127\.0\.1\.1\W"  for greater accuracy
[14:57] <lynxman> cjwatson: ooh excellent, thanks :)
[14:58] <cjwatson> lamont: https://launchpad.net/ubuntu/+source/rootskel/1.95ubuntu1/+buildjob/2518416 "i386 build" ... "Successfully built on zirconium (lpia)"
[14:58] <cjwatson> lamont: do the buildds need manual relabelling?
[14:58] <lamont> bah
[14:58] <lamont> thar
[14:58] <stgraber> ScottK: for bug 436936 I see that the kdebase-workspace that was in proposed has now been copied to -updates so I'm going to upload the upstart fix to natty-proposed. Same fix will be in Oneiric with the next kdebase-workspace upload (as it's in the bzr branch).
[14:59] <lamont> cjwatson: we repurposed zirconium because we hatez the lpia
[14:59] <lamont> or something like that
[14:59] <ScottK> stgraber: Great.  Thanks.
[14:59] <lamont> hardy is the only release left that has lpia, so we gave it one biulder, instead of 2
[14:59] <lamont> zirconium's description corrected
[14:59] <cjwatson> ta
[15:00] <cjwatson> I'm all in favour of lpia->i386 builder movement, certainly
[15:00] <cjwatson> wow, somebody was brave enough to merge perl?
[15:01]  * cjwatson applauds doko.  Hopefully we can get through the perl transition quickly ...
[15:02] <Laney> 5.12?
[15:02] <pitti> this currently causes quite some "fun" in unstable indeed
[15:02]  * Laney is scared
[15:02] <cjwatson> yes
[15:02] <cjwatson> ah well, plenty of time
[15:02] <Laney> the binNMUs appear to be going through and making stuff work again
[15:02] <Laney> but we don't have such luxury
[15:02] <pitti> we have some scripts to do no-change mass source uploads, though
[15:02] <Laney> yeah, almost as nice
[15:08] <ScottK> pitti: Here's the Debian binNMU list: http://release.debian.org/~jcristau/perl5.12-wb-commands.txt
[15:08] <ScottK> (for the perl transition)
[15:10]  * Laney thinks an Ubuntu ben instance would be nice
[15:11] <geser> who/what is "ben"?
[15:11] <Laney> debian's transition tracker
[15:11] <Laney> http://release.debian.org/transitions/html/perl.html
[15:22]  * cjwatson changes MoM to try to run every half an hour rather than every hour - its runtime is still substantial (so many runs will fail to acquire the lock), but hopefully that'll make it slightly more responsive
[15:26] <psusi> cjwatson: is there a grub command you can use to hex dump a given sector?
[15:28] <cjwatson> psusi: hexdump
[15:28] <cjwatson> so e.g. hexdump -s 1024 -n 512 (hd0)  # dump third sector of (hd0)
[15:38] <doko> Laney, pitti, cjwatson: please wait with "binNMU"s until armel is usable again (should be tonight/tomorrow)
[15:38] <Laney> doko: usable how?
[15:38] <psusi> cjwatson: this is odd... the two sectors it is reading, one from hd0, and one from hd0,msdos1, are aliases of each other... offset by the 2048 starting sector of the partition... what's the dprintf format code for grub_uint_64_t?
[15:38] <doko> Laney: apt fails
[15:38] <Laney> oh, still that?
[15:38] <Laney> ack
[15:39] <psusi> or better yet, a command to print what grub thinks the size of the disk and partition are?
[15:39] <doko> gnahh, and perl ftbfs on amd64, although it did build locally :-/
[15:40] <cjwatson> psusi: PRIxGRUB_UINT64_T
[15:40] <cjwatson> (or PRIu...)
[15:40] <cjwatson> (er, hopefully it's clear, but that's a macro - use token-pasting)
[15:45] <psusi> cjwatson: I think grub may have the wrong size for the disk... it seems to think that the partition does indeed end at the end of the disk
[15:46] <psusi> i.e. partition start + partition size = disk size when looking at ls -l
[15:46] <cjwatson> you're probably stuck with decoding the partition table by hand and digging into the partition table code
[15:46] <cjwatson> partition tables are pretty simple to decode though; a bug there would surprise me
[15:48] <psusi> aye
[15:48] <slangasek> stgraber: ucf> be my guest, thanks :)
[15:50] <slangasek> mdeslaur: 776030> hmm, looks like debsums needs updating for multiarch
[15:51] <mdeslaur> slangasek: are you updating the bug, or shall I?
[15:52] <slangasek> mdeslaur: I will
[15:52] <mdeslaur> slangasek: cool, thanks
[16:06] <psusi> cjwatson: yea, something is wrong with the hd size detection... ls -l in grub lists it as 488396800 sectors, but fdisk says it is 488397168.. that shorter size aliases the end of the partition with the end of the disk
[16:06] <psusi> cjwatson: think of anything that changed since maverick that could have caused that?
[16:06] <cjwatson> you're the lucky one who gets to debug :-)
[16:06] <cjwatson> nope
[16:07] <psusi> le sigh
[16:07] <cjwatson> lots of code churn since maverick in general
[16:07]  * psusi starts reading over the disk code
[16:08] <Chipzz> ugh
[16:08] <Chipzz> am I the only one who feels like handing out a gigantic punch in the face to Lennaert?
[16:08] <Chipzz> http://lwn.net/Articles/441328/rss
[16:10] <ohsix> yes?
[16:11] <ohsix> he's been very clear about proper session/seat support
[16:12] <Chipzz> ohsix: "how they intend to expand systemd to take over many of the functions currently handled by ConsoleKit.". This means if your distro has apps using CK, all of a sudden systemd becomes mandatory. And given the amount of effort canonical has put into upstart...
[16:13] <ohsix> eh
[16:13] <ohsix> define use
[16:14] <ohsix> cuz you can ask it when a seat changes ownership and which is the current user, that can be done with a simple wrapper; the other stuff it does when seats switch is something else
[16:15] <ohsix> theres a lot more it will subsume than consolekit
[16:17] <lynxman> negronjl o/
[16:17] <negronjl> o/ lynxman
[16:18] <Chipzz> ohsix: and you think that is a good thing?
[16:19] <ohsix> since i take it you think it's not i'll be keeping to myself
[16:19] <Chipzz> init turning into the kitchen sink and being locked down to one choice does not look like something to be enthusiastic about...
[16:20] <ohsix> it staying the way it is an not being able to do anything with it is also great
[16:20] <ohsix> it's not like the other init systems are going away
[16:21] <ohsix> you could make the same argument against upstart btw
[16:25] <Chipzz> no you couldn't
[16:25] <ohsix> yea you could, why mess with sysvinit it works!11111
[16:25] <Chipzz> no you couldn't
[16:25] <Chipzz> because that's not my argument
[16:25] <ohsix> the actual "init" part is small, the part as pid 1 is small
[16:25] <ohsix> it's the only thing you could be arguing, because it's not turning into a kitchen sink
[16:25] <Chipzz> and upstart still performs the same functions as the initial init
[16:26] <Chipzz> starting/stopping processes
[16:26] <ohsix> correction, init doesn't start or stop processes, it runs jobs
[16:26] <ohsix> jobs may or may not start or stop processes
[16:27] <ohsix> this is pretty OT but i dont' mind discussing it elsewhere until i have to leave :] (40 minutes or so)
[16:27] <Chipzz> OT? you think?
[16:28] <ohsix> yea, this is -devel
[16:28] <Chipzz> the way I read it, systemd replaces CK and becomes non-optional. since you can only have one init, upstart has to go. Canonical has invested largely in upstart. I don't see how this is OT here?
[16:29] <ohsix> systemd can replace ck, doesn't mean it has to
[16:29] <Chipzz> incorrect
[16:29] <ohsix> and that part isn't part of the "init", you can use systemd for init and everything else for what it does already, you can't have 2 things be pid 1 however
[16:29] <Chipzz> read again
[16:29] <Chipzz> http://lwn.net/Articles/441328/rss
[16:30] <ohsix> read the documentation
[16:30] <Chipzz> On the way want to fix multi-seat support properly and running services outside of a session, and we will get rid of CK.
[16:30] <cjwatson> that doesn't say that somebody is going to come and destroy all copies of consolekit with fire
[16:30] <ohsix> theres nothing saying ck has to change seat permissions either, it just does right now
[16:30] <Chipzz> cjwatson: might as well
[16:30] <cjwatson> if it's still necessary, we could continue maintaining it
[16:30] <ohsix> ck doesn't do a lot but let listeners know when seats change and list current users with respect to multiseat
[16:31] <Chipzz> cjwatson: I'm actually quite surprised I'm the only one talking about this here
[16:31] <cjwatson> (I'm not going to make technical decisions on the basis of a news article, however competent, but the option is clearly there)
[16:31] <ohsix> just like upower and udisks dont' do a ton, but they sharded off and do one thing well
[16:31] <ohsix> Chipzz: it's not a threat or anything
[16:31] <Chipzz> ohsix: and that's sth systemd doesn't do: do one thing well
[16:31] <ohsix> Chipzz: i didn't mean to imply it did, i was talking about consolekit and what happened after hal
[16:32] <cjwatson> Chipzz: it seems clear to me that there is no cause for panic, and that phrasing it as "systemd [...] becomes non-optional" is alarmism
[16:33] <ohsix> but that notwitshtanding as long as systemd can give you the output of the ck-* tools and the subscription for seat changes, does ck really go anywhere? it might not need to present it in that form in the end and even ck can change to suit; that's just how it looks now
[16:34] <ohsix> same goes for anything it'd purport to "replace", theres a lot of things it could subsume and use data it already has to do it better and with less resources but it doesn't mean an all or nothing gambit
[16:35] <ohsix> and it doesn't mean you have to use systemd at all in the end; it'll just look increasingly more like the better choice as time goes on
[16:36] <ohsix> lennart thinks and has written as much that there should be one arbiter for seats/sessions, even replacing user level session services like the scripts that start a gnome session, all in the name of managing resources where they're best utilized
[16:37] <ohsix> you can't put everyone in their own cgroup's cleanly with consolekit for example, but if your user session is started with systemd then all it's resource control tools with respect to cgroups are in effect, and they have autogenerated rule templates for handling that stuff
[16:39] <ohsix> even if upstart was my personal baby i'd bin it in a minute if it started looking deprecated, not to suggest what anyone else should do; if you're that firm on it you're more on the ideology of something than the fit-for-purposeness when there are better options
[16:44] <Chipzz> ohsix: what bothers me most is Lennaerts attitude... going from "I know better than all of you, and I have no interest whatsoever in cooperating with anyone" to "My way or the highway" now
[16:44] <directhex> Chipzz, that's hardly new or unexpected, surely?
[16:44] <Chipzz> that may be a slight exaggeration, but not by much I think
[16:45] <slangasek> ohsix: Lennart is not in a position to deprecate upstart, however :)
[16:46] <Chipzz> directhex: given Lennaerts past arrogant attitude, I wouldn't say it's unexpected, no
[16:47] <cjwatson> it would be appropriate to at least spell his name correctly
[16:49] <Chipzz> ohsix: and no, I don't buy the technical superiority argument either... I haven't tried systemd yet, but from what I have read about it it appears to be non-trivial to grasp
[16:49] <Chipzz> s/Lennaert/Lennart/ :)
[16:53] <cjwatson> barry: sponsored that python2.7 maverick change
[16:53] <barry> cjwatson: awesome, thanks.  i'll test it as soon as it lands in -proposed
[16:54] <Chipzz> I'm not sure if exposing cgroups is valuable at this point for example; it's a relatively new feature, and while I can see the value in it, I think lots of ppl are not yet familiar with it, and I think it has the potential to confuse a lot of ppl (what are cgroups and why should I care?)
[16:54] <Sweetshark> cjwatson, Chipzz, directhex, slangasek: http://www.youtube.com/watch?v=ZTdUmlGxVo0 <- flame on.
[16:56] <Sweetshark> Lennart kills/hijacks the talk in approx. 15 minutes.
[16:59]  * psusi still doesn't get what ConsoleKit *IS*.. the description on the web site and initial email announcement just aren't conveying it to me
[17:02] <cjwatson> hah, first thing that happens when you boot a maverick desktop CD is a prompt offering an upgrade to natty
[17:02] <cjwatson> I thought we'd disabled that on the live CD ...
[17:02] <stgraber> kees: were you planning on oding the rdesktop merge or can I take it ?
[17:03] <Sweetshark> psusi: AFAIK it is the stuff that lets you multiplex for example audio between your X11 session and a VT (e.g. you get the audio in the VT if and only if you are logged in as the same user as the running X11 session)
[17:04] <cjwatson> we also use it in conjunction with policykit to find out about the user currently at the console
[17:04] <kees> stgraber: go for it! :)
[17:04] <Chipzz> Sweetshark: tbh the speaker does seem unprepared and does seem to get facts wrong
[17:04] <cjwatson> and grant them appropriate permissions
[17:05] <psusi> cjwatson: yea, I was annoyed by that last night...
[17:07] <Sweetshark> Chipzz: yes he does, Lennart is right on most of the points as discussed.
[17:09] <stgraber> cjwatson: Is there any way to teach merge-o-matic that a package has a diffferent packaging in Debian and Ubuntu ? ltsp and ldm have completely different packaging so there isn't much point in them appearing in the list.
[17:09] <stgraber> I'm working with Vagrant to try to reduce the delta when possible but we really aren't quite there yet (as LTSP is extremely distro dependent)
[17:10] <Sweetshark> Chipzz: Interestingly enough, I still learned quite a lot in that talk. (The most important one: dont ever start a flamewar with Lennart unprepared.)
[17:11] <Chipzz> Sweetshark: you were the speaker?
[17:12] <Sweetshark> Chipzz: no, god beware! it hurt enough to watch that.
[17:17] <cjwatson> stgraber: ltsp has been blacklisted for ages and that merges.u.c entry dates from 2009, so I've nuked it (should disappear from the index at the next run)
[17:17] <cjwatson> stgraber: for ldm, the appropriate thing to do would probably be to add it to the sync blacklist, which also means that it should never get autosynced.  does that sound right?
[17:17] <ogra_> stgraber, wow, kudos for attacking that
[17:18] <stgraber> cjwatson: yep
[17:19] <stgraber> ogra_: yeah, I try to at least look at it once every cycle :) I still need to work on changing the source format and switching to dh7. Should be easier merging vagrant's packaging after that.
[17:19] <cjwatson> stgraber: done, then - again, will disappear at the next sync
[17:19] <cjwatson> er, next run
[17:19] <stgraber> cjwatson: thanks
[17:20] <pmatulis> hi, what happened to the libpam-heimdal package for releases > 10.04 ?
[17:20] <cjwatson> https://launchpad.net/ubuntu/+source/libpam-heimdal/+publishinghistory and click the first expander triangle
[17:21] <pmatulis> cjwatson: hmm, thx
[17:22] <cjwatson> that's kind of opaque, what actually happened is that it's now generated by the libpam-krb5 source package
[17:23] <cjwatson> oho, which was sync-blacklisted because it overwrote libpam-heimdal and we needed to figure out what to do ...
[17:23]  * cjwatson removes that blacklist entry and tries again
[17:24] <cjwatson> pmatulis: thanks for bringing that up - it should return to oneiric shortly
[17:24] <pmatulis> cjwatson: i'm looking at bug #663319
[17:24] <pmatulis> gee, someone should edit that title
[17:24] <cjwatson> I don't know whether we can do anything for stable releases, since a substantial upgrade of libpam-krb5 would likely cause trouble
[17:26] <pmatulis> rats
[17:27] <slangasek> mind you, heimdal is also in universe
[17:27] <cjwatson> libpam-krb5 isn't ...
[17:27] <slangasek> so building libpam-krb5 and libpam-heimdal from the same source in SRU wouldn't work
[17:28] <cjwatson> yes, something will have to be done in order to actually build new libpam-krb5 in oneiric
[17:28] <cjwatson> since it now build-depends on heimdal-multidev
[17:28] <cjwatson> maybe we should just promote heimdal?  I'm not familiar with the arguments there
[17:29] <slangasek> well, it's a second implementation of a large and security sensitive software suite
[17:51] <ohsix> Chipzz: that's not his attitude
[17:51] <ohsix> Chipzz: and he's not speaking from an unreasoned position either, he's spent a lot of time thinking about the problems and how to do it better
[17:52] <ohsix> he's not arrogant, he just knows what he's talking about and has a lot of detractors that don't even know the first thing about what they apparently disagree with
[17:54] <ohsix> also you don't need to be sold on cgroups, if you don't care that much you probably shouldn't care at all; read stuff from Documentation/ as it's added or forget about it, nobody is going to keep coming around trying to convince you
[17:54] <psusi> Sweetshark: how so?
[17:58] <Sweetshark> psusi: how so what? It hurt to watch that as it is just quite embarrasing for the speaker.
[18:00] <psusi> Sweetshark: oh yes, that.. how so CK/PulseAudio/authorization
[18:02] <ohsix> Sweetshark: i lol'd when i saw that session when it was posted to the website
[18:03] <ohsix> Sweetshark: you didn't even really need to see the video to know how it  had gone down, lennart was the only thing that made it worthwhile
[18:03] <ohsix> and he was affable, even if he did sort of hijack the guy; can't let that stuff fly if you personally know better
[18:04] <psusi> I didn't watch that whole video because it became too painful, but I couldn't quite figure out what the speaker was complaining about... he seemed to be meandering around aimlessly... the major theme I could identify was that he doesn't like the new plug and play world we live in because his config files broke... or something...
[18:04] <Sweetshark> ohsix: well, I saw the submitted paper and thought: That could be very good or very bad. It turned out to be both in a way.
[18:05] <ohsix> his brief signalled that he really didn't know anything about what he was going to talk about, aside from him not liking them
[18:06] <ohsix> reminded me a lot of the people that like OSS because they've convinced themselves that it sounds better, or something as equally silly to cover their rather embarassing attachment
[18:06] <psusi> and what was with the complaints about gdm starting a "full" gnome session?  what else would you expect the gnome session manager to do?
[18:06] <ohsix> psusi: it used to not do that
[18:07] <psusi> the gnome session manager did not used to manage a gnome session?
[18:07] <ohsix> gdm before 1.28 was a separate application that tried to do accessibility a little, extra login options a little; etc
[18:08] <Sweetshark> psusi: http://fedoraproject.org/wiki/Desktop/FastUserSwitching#Device_Ownership and http://fedoraproject.org/wiki/Desktop/FastUserSwitching#Refuse_Service_To_Inactive_Sessions render some good things CK intends to do.
[18:08] <ohsix> no, gdm still started sessions back then, but it wasn't accessible and it was its own huge code base that basically just caused more problems for them every time something was added; it doubled security coverage and it really had to draw a lot of attention by itself
[18:08] <psusi> and now?
[18:08] <ohsix> accessible = on screen keyboard & screen readers, the new gdm can have applets for connecting to wifi and stuff on there too; if you need it
[18:09] <ohsix> now it's a full session and you canput anything on the login screen you need to, without adding code to do it to gdm
[18:09] <ohsix> gdm was essentially a reimplimentation of half the stuff the desktop proper already had to be supported & do
[18:10] <ohsix> so they binned it for the code that got more attention & was already reviewed for security and stuff instead of special handling it all in gdm with code that's not used anywhere near as much as the stuff in the live session
[18:10] <psusi> ohh... so it used to be an application that mainly handled login and did a few other things before starting the session, and now it actually is a session, just one more lightly configured than the one yuo get when you login?
[18:10] <ohsix> well it's not a session like the other things are sessions, but yea
[18:11] <ohsix> gdm used to duplicate the accessibility stuff and other things already in the desktop session with a bunch of stuff that just existed in gdm
[18:11] <Sweetshark> i think this is a classical admin/coder conflict in a way: The admin feared any package updated could break not only some session details, but the login, rendering his infra dead, while the coder worries more about the code duplication.
[18:12] <ohsix> that guy admitted he was adminning gentoo machines though
[18:12] <Sweetshark> keep in mind the guy was using gentoo for some bigger university rollout.
[18:12] <ohsix> which means he's wasting a lot of someones time, effort and money
[18:12] <psusi> so what?  there is a list of programs to run when at the login screen, and once you login, there is another list of programs that get run depending on which desktop you chose?  is the first set still running when the second is?  how are they kept separate?
[18:12] <ohsix> being paid to play around has its merits though
[18:14] <psusi> I was going to say... admining an entire network of gentoo machines?  going around to each of hundreds of computers and compiling every new package?  wtf?
[18:14] <ohsix> psusi: i can't remember if it switches servers or the user session subsumes the login one
[18:14] <Sweetshark> ohsix: I think when it came up, gentoo actually brought a lot of stability to all distro by finding and triaging some weird gcc-bugs etc ...
[18:14] <ohsix> Sweetshark: shrug, ffmpeg thought they were a major gcc driver, but they really hate on it when it "breaks"
[18:15] <ohsix> every strange thing that happens it's the first thing to blame and they don't always get around to ruling it out
[18:15] <Sweetshark> psusi: nah, you would compile on one machine and distribute only binaries.
[18:16] <ohsix> psusi: i think the person that logged in takes over the spawned server, and during fast user switching a new one is spawned with the login window, and if someone logs in to an existing session it switches to the existing server
[18:16] <psusi> so basically gdm reimplented all of this functionality and had its own weird config file this guy had set up the way he wanted, and all that went out the window in favor of running the proper applications to handle these various tasks, and he was butthurt that his old gdm config file was no good anymore?
[18:17] <ohsix> last time i actually looked though it spawned a new server for each thing, but this was also on gentoo :[ so who knows if it was ideal or just good enough
[18:17] <ohsix> psusi: basically
[18:17]  * psusi shakes his head
[18:17] <ohsix> psusi: oddly enough the new one is much more configurable
[18:17] <ohsix> psusi: it's driven entirely by .desktop files like the proper sessions are, you can put whatever you want on the login screen
[18:18] <ohsix> which is far more flexible, but harder to theme than the original
[18:18] <ohsix> just about every gripe i've seen had to do with theming, there was a list of things you could toggle, like xdmcp; whcih afaik nobody bothered to reimpliment, and could be a problem for that guy
[18:19] <psusi> makes sense... I remember some problems caused by a similar situation with the WinNT login... if yuo wanted to add anytyhing to it, like being able to connect to a network, you had to write a pita plugin dll for it...
[18:19] <ohsix> that guy can't even think those terms though; if he could he would have just said what he misses about the software he prefers, and something could possibly be done about it, but it's just a chronic know nothing complainer
[18:19] <ohsix> yea, GINA
[18:20] <psusi> yea, that's it... heh, I almost had forgotten that stuff
[18:20] <ohsix> gdm was sort of like that, this was in the fast user switching era too; i don't know what the tipping point was but it could have been that, someone eventually just said they weren't going to add new thing X because of the testing impact and stuff
[18:22] <Sweetshark> ohsix: still he managed to get rather good introduction on the topics by Lennart in the classical http://bash.org/?152037 way
[18:23] <ohsix> yea that guy had one thing goinf or him, he didn't go completely nuts when what he was saying was being challenged
[18:24] <ohsix> re: that quote, people that really can answer anything less trivial than that will just be highly annoyed by that behaviour
[18:28] <Sweetshark> ohsix: well, that mostly depends on the community of the project in question
[18:30] <ohsix> i strive to fall on the side of not wasting peoples time, especially if i have a highly specific question with that special sort of rarified answer, those people are busy too :]
[18:36] <stgraber> cjwatson: is merges.ubuntu.com having issues refreshing ? ltsp and ldm are still on there and so are the merges and syncs I did/requested today (ucf, nbd, libssh and rdesktop)
[18:47] <cjwatson> stgraber: looks like a few things in sequence - firstly, it looks like archive.ubuntu.com isn't updating consistently at the moment, so it sometimes fails to update its pool
[18:47] <cjwatson> stgraber: the most recent one is yet another unpack failure though
[18:48] <cjwatson> er, apparently because there's a .dsc without its .debian.tar.gz, WTF
[18:49] <maco> O_o
[18:49] <cjwatson> it's fine on archive.u.c
[18:49] <cjwatson> looks like another case of archive skew actually
[18:50] <cjwatson> it should sort itself out eventually
[19:33] <jdstrand> @pilot in
[20:04] <Daniel0108> hi
[20:23] <jdstrand> cjwatson: hey, so I am looking at https://code.launchpad.net/~3v1n0/ubuntu/natty/ca-certificates/digicert-certificates/+merge/57086. I disapproved this some time ago, but it looks like the merge request is still showing up in reports/sponsoring/ because of ubuntu-branches needing to review
[20:24] <jdstrand> cjwatson: as you are a member of ubuntu-branches, I thought I'd ask you how I would get that off the sponsoring list
[20:46] <pitti> kees, jdstrand: moved linux-source-2.6.15 (dapper) to -u/-s
[20:48] <lamont> cjwatson: walking the archive for consistency
[20:48] <kees> pitti: thanks!
[20:48] <pitti> hopefully the last dapper one?
[20:49] <jdstrand> it better be :P
[20:51] <dupondje> jdstrand: could you check if https://bugs.launchpad.net/ubuntu/+source/toonloop/+bug/775588 is done correctly ? :)
[20:52] <jdstrand> dupondje: sure! (it will be a few minutes however)
[20:52] <dupondje> no prob!
[20:57] <pitti> kees, jdstrand: releasing linux/karmic as well (not sure whether you still want an USN for the EOL release?)
[20:57] <pitti> good night everyone
[20:59] <cjwatson> jdstrand: can you not change the Status to Rejected, at the top?
[21:01] <geser> can someone please give-back "hevea"? thanks
[21:02] <jdstrand> cjwatson: no, there is nothing there I can manipulate
[21:03] <jdstrand> cjwatson: I see 'Status: Needs review', but nothing else. The only yellow pencil I have is for my own review (which is Disapprove)
[21:04] <jdstrand> goodnight pitti
[21:04] <tcole> Hi, I've got a question about how I might go about fixing the python-storm package on Natty -- currently, it's not building extensions for python 2.7
[21:04] <stgraber> geser: building now
[21:04] <tcole> the python version bits in debian/ seem OK
[21:04] <tcole> so I'm wondering what else I should be looking at
[21:12] <RoAkSoAx> barry: ping
[21:12] <barry> RoAkSoAx: hi
[21:13] <RoAkSoAx> barry: howdy!! I was wondering if you could help me with this:
[21:13] <RoAkSoAx> barry: bzr: ERROR: Inconsistency between source format and version: version is native, format is not native.
[21:13] <RoAkSoAx> barry: that's what I get from doing bzr bd -S on a branch which I just switch to source format 3.0 (quilt)
[21:13] <ScottK> tcole: It works fine here.  sudo apt-get install python-storm; python -c "import storm" works.
[21:14] <stgraber> RoAkSoAx: what's your version number ?
[21:14] <tcole> ScottK: it doesn't for me
[21:14] <tcole> ScottK: are you on Natty?
[21:14] <ScottK> I am.
[21:14] <barry> RoAkSoAx: hmm.  i haven't seen that one before.  but it sounds like the version number in the changelog isn't correct.
[21:14] <tcole> hm.
[21:14] <RoAkSoAx> stgraber: barry ah!! Will try that. Thanks for the tip
[21:15] <tcole> ScottK: lemme update/upgrade real quick and see if there's a new version
[21:15] <ScottK> No.  There won't be.
[21:15] <stgraber> barry: it's very likely because as the error says you're using a "native" version number (missing a -0ubuntu1 for Ubuntu or -1 if it's for Debian)
[21:15] <stgraber> doh, RoAkSoAx ^
[21:15] <tcole> ScottK: if you do: dpkg -L python-storm | grep 2.7
[21:15] <tcole> ScottK: do you see anything?
[21:16] <barry> stgraber: right! :)
[21:16] <RoAkSoAx> stgraber: cool, yeah I think that's the thing. Though I was using release-build from kirkland's bikeshed when I stumble accross this error message
[21:16] <RoAkSoAx> but makes sense
[21:16] <ScottK> /usr/lib/python2.7
[21:16] <ScottK> /usr/lib/python2.7/dist-packages
[21:16] <ScottK> /usr/lib/python2.7/dist-packages/storm
[21:16] <ScottK> /usr/lib/python2.7/dist-packages/storm/cextensions.so
[21:16] <kirkland> statik: hmm
[21:16] <ScottK> tcole: ^^^
[21:16] <kirkland> statik: sorry
[21:16] <ScottK> Gotta run.  Back later.
[21:16] <kirkland> RoAkSoAx: okay
[21:16] <tcole> ScottK: interesting, I don't get those :(
[21:17] <RoAkSoAx> stgraber: barry thanks though!
[21:17] <barry> np!
[21:17] <stgraber> np
[21:18] <tcole> ScottK: ohh, I think I see the problem
[21:27] <RoAkSoAx> kirkland: btw.. could you please make the tarball available in LP?
[21:29] <kirkland> RoAkSoAx: oh, yeah
[21:30] <kirkland> RoAkSoAx: powernap you mean?
[21:31] <RoAkSoAx> kirkland: yep
[21:31] <RoAkSoAx> thanks
[21:31] <lamont> cjwatson: archive.u.c should be consistent, though the archive slew is more pronounced each time we trigger
[21:44] <maxb> siretart: Hi. Re those extra bugtasks you opened on bug 681396 - is there any point in having them, since there is no point in fixing them without an installer respin, which doesn't happen for non-LTS ?
[21:56] <cjwatson> jdstrand: I've marked it as rejected now - didn't realise only ubuntu-branches members could do that
[21:56] <cjwatson> lamont: thanks, I suppose it will get better through the cycle?
[22:01] <jdstrand> cjwatson: thanks!
[22:10] <slangasek> cjwatson: ah, so it's tied to ubuntu-branches, then... maybe that's a bug to be fixed, so uploaders can actually reject merge requests instead of perpetually deferring them as 'in progress'? :)
[22:16] <ScottK> slangasek: cough .... postfix.
[22:17] <cjwatson> I've filed bug 777442
[22:18]  * cjwatson once again contemplates creating himself a fake identity and getting some degree of upload privileges for it, so he can see what happens if you don't have demigod Launchpad privileges
[22:20] <doko> cjwatson, slangasek: hmm, I think I was a bit too eager with the perl bits ... see e.g. for a failing build: https://launchpadlibrarian.net/71096166/buildlog_ubuntu-oneiric-i386.liblocale-gettext-perl_1.05-6build1_FAILEDTOBUILD.txt.gz
[22:20] <cjwatson> hm, that'll be fun to unpick
[22:21] <cjwatson> $ change-override.py -c main -y libperl5.12
[22:21] <cjwatson> that might help
[22:21] <cjwatson> (possibly not much)
[22:23] <doko> hmm, thought that q accept -c main would do that ...
[22:23] <cjwatson> nope
[22:23] <ScottK> cjwatson: When you have a moment, I'd appreciate it if you'd do the maverick-backports part of Bug #777143 too.
[22:23] <cjwatson> 'chdist apt-get oneiric-i386 -y -d --print-uris build-dep liblocale-gettext-perl' doesn't suggest any problems though
[22:23] <cjwatson> ScottK: oh, yeah, I had backport-helper running for that one
[22:23] <ScottK> Thanks.
[22:23] <cjwatson> backports for the same package to multiple series have to be done in separate runs, for annoying reasons
[22:24] <cjwatson> doko: at least I don't think it works that way
[22:24] <ScottK> Is that something we can fix in the script or does it need addressing elsewhere?
[22:24] <cjwatson> doko: I think you need queue override (or just the 'main' alias)
[22:24] <cjwatson> ScottK: it's our shonky scripting - never quite been worth fixing
[22:25] <ScottK> OK.
[22:25] <cjwatson> one of those things that falls just below the must-automate threshold
[22:25] <cjwatson> done now
[22:25] <cjwatson> (the backport that is)
[22:25] <doko> ok, will requeue these after it's available in main
[22:26] <cjwatson> doko: I don't think that one has anything to do with libperl5.12; as far as I can see liblocale-gettext-perl's build-deps are satisfiable in main now
[22:26] <cjwatson> though that build log is very recent ...
[22:26] <ScottK> Thanks.
[22:26] <cjwatson> IDGI
[22:27] <doko> well, if perl-dev is not installable, ...
[22:27] <doko> and even perl-base
[22:27] <cjwatson> but liblocale-gettext-perl doesn't build-dep on perl-dev
[22:27] <cjwatson> and perl-base doesn't depend on libperl5.12
[22:28] <doko> ahh, for liblocale-gettext-perl, I added a b-d on perl (>= 5.12), so that perl is built first on armel
[22:29] <cjwatson> I wonder why it held back perl at the start of that upgrade
[22:29] <cjwatson> it's probably something else in the base system that needs it
[22:30] <cjwatson> that versioned build-dep is probably why it's breaking, yes; OTOH, without that, it would build with perl 5.10
[22:31] <cjwatson> hm, yeah, all the debconf dependencies.  I wonder how Debian did this
[22:33] <cjwatson> looks like we need to get  libtext-charwidth-perl liblocale-gettext-perl libtext-iconv-perl  over at a minimum
[22:34] <cjwatson> lamont: ^- any bright ideas?
[22:51] <lamont> cjwatson: reading scrollbac
[22:52] <lamont> cjwatson: by "get $pkglist over" what do you mean?
[22:58] <cjwatson> lamont: built against perl 5.12
[23:02] <lamont> cjwatson: you have SIP up?
[23:04] <doko> I'll requeue the 7 rebuilds in about 40min
[23:04] <lamont> doko: and they should build then?
[23:05] <lamont> gcc-4.6/arm still isn't done
[23:05] <doko> yes, seen. had it built on a dual core
[23:13] <cjwatson> lamont: nope.  have mumble
[23:14]  * infinity misses the "fun" of perl transitions.
[23:15] <cjwatson> doko: hmm, you broke base-files
[23:15] <cjwatson> Setting up base-files (6.3ubuntu1) ...
[23:15] <cjwatson> cp: cannot stat `/usr/share/base-files/networks': No such file or directory
[23:16] <cjwatson> looks like share/networks went missing?
[23:20] <cjwatson> doko: fixing
[23:25] <ohsix> .last -clear
[23:25] <ohsix> er
[23:40] <doko> cjwatson: ta! I assume lamont had to build by hand
[23:41] <cjwatson> nah, base-files sorted itself out
[23:41] <cjwatson> anything that doesn't actually need the new perl should still work
[23:41] <cjwatson> lamont is preparing manual chroots to build the packages I listed above, though
[23:42] <cjwatson> the approved answer (which Debian did too) is to swap out debconf-i18n for debconf-english in the chroots
[23:43] <cjwatson> so we'll do that, get debconf-i18n installable again, then put the chroots back
[23:43] <jdstrand> @pilot out
[23:43] <cjwatson> for values of "we" equal to "lamont" I guess
[23:43] <lamont> cjwatson: heh
[23:44] <doko> which I assume has to wait for armel
[23:44] <lamont> doko: that would be my fantasy, yes
[23:44] <cjwatson> well, the other architectures can go first, given that the build farm has to go onto manual anyway
[23:44] <lamont> alternatively, we leave apt held while we do the perl transition
[23:44] <cjwatson> which would let us bring x86 virtual builders back up faster
[23:45] <cjwatson> so we'd just leave armel on manual until it's caught up enough
[23:46] <doko> lamont: I assume you do not want to use hand-built gcc-4.6 and apt packages for these builds
[23:46] <lamont> doko: so the currently extant gcc-4.6 is known bad?
[23:46] <lamont> as in DO NOT USE EVAR!!? bad?
[23:46]  * lamont bets on "yes"
[23:46] <lamont> and aren't we all happy that it broke apt??
[23:48] <doko> lamont: no, should be fine, see https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/774175/comments/29
[23:50] <lamont> doko: so are you saying that if I hold apt (so that it works), then I can go ahead and do perl in parallel with the apt build?
[23:51] <doko> lamont: we should be safe, if the testsuite doesn't fail
[23:51] <lamont> ok
[23:52] <lamont> set-builder --all --manual
[23:52]  * lamont hugs the api
[23:52] <lamont> cjwatson: all on manual other than the "virtual" armel
[23:53] <cjwatson> why not those?
[23:53] <lamont> they're not building oneiric
[23:53] <cjwatson> ah
[23:53] <doko> but I wouldn't like to use the current gcc for many other builds, and it should be finished in time with the perl build
[23:54] <lamont> doko: not holding gcc-4.6, but I _AM_ afk for a few hours starting in about 20 minutes tops
[23:54] <lamont> wife's birthday today.  MUST NOT MISS
[23:55] <doko> heh, hope you already have a present besides your presence ;p