[00:41] <infinity> Daviey: It's on my TODO.
[01:08]  * infinity wonders what the new mesa broke in EGL that makes qt4 unhappy.
[01:11] <broder> slangasek: ok. just uploaded the insserv SRUs; apologies for the stalling
[01:13] <maco> cyphermox: woooooah, somebody's actually looking at that bug
[01:13] <maco> i forgot about it
[01:20] <RAOF> infinity: Oh, what's happening?
[01:21] <infinity> RAOF: qt4-x11 no buildy on arm{el,hf}, whining about GLES not functioning.
[01:22] <RAOF> Hm.  Got a buildlog url handy to save me the trouble?
[01:22] <infinity> RAOF: I haven't looked into it yet, in the (perhaps misguided) hope that the folks who uploaded the shiny new mesa upstream may either be (A) aware of it, or (B) prepared to take responsibility and dig deeper.
[01:22] <cyphermox> maco: yeah, at it would take the best of 50 seconds to implement ;)
[01:22] <infinity> RAOF:
[01:22] <infinity> https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.0-1ubuntu8
[01:22]  * RAOF would be one of the people responsible for mesa, so…
[01:23] <infinity> RAOF: Same failure pattern on armel and armhf, so pick randomly.
[01:24] <RAOF> Huh.  Cannot find -lEGL on armel and armhf, but not i386 or amd64?  Oddness.
[01:24] <infinity> RAOF: Not odd in the least, x86 links against OpenGL, arm links against OpenGLES.
[01:25] <infinity> RAOF: So, EGL is /probably/ broken on all platforms, but it's only showing up on ARM because QT4 uses GLES on ARM.
[01:25] <RAOF> Right.
[01:26] <JontheEchidna> fwiw, the latest updates (dist-upgrade) wants to remove the egl stack from my computer.
[01:28] <RAOF> JontheEchidna: You're probably seeing multiarch archive skew.
[01:29] <JontheEchidna> yes, I did notice some 386 packages involved
[01:29] <JontheEchidna> ah, yeah. looks like the ia32libs update is causing the issues
[01:31] <RAOF> EGL doesn't *seem* to be broken on amd64.
[01:35] <infinity> RAOF: Hrmph.  So the breakage was tailor-made just for ARM?  How kind. :P
[01:35] <RAOF> Hm, no.
[01:35] <RAOF> Aha.  There it is.
[01:36] <smoser> hey...i shoved a 'ps w' into initramfs, and see http://paste.ubuntu.com/854829/
[01:36] <smoser> does that seem right?
[01:36] <smoser> bah. first one missing some. second
[01:36] <smoser> http://paste.ubuntu.com/854831/
[01:36] <infinity> smoser: Could be a tiny bit excessive.
[01:37] <RAOF> infinity: Ah, yeah.  We dropped a symlink on the floor.
[01:37] <infinity> smoser: Is it actually eating CPU time, or is it just a ton of idle chilren spawned during the initial event storm on boot?
[01:37] <infinity> RAOF: Glad it's something that simple.
[01:38] <smoser> well, its not the cpu time i'm concerned about.
[01:38] <smoser> i was debugging bug 937352
[01:38] <RAOF> infinity: Presumably you'd like that to make B1? :)
[01:38] <infinity> RAOF: If you could be so kind.
[01:39] <smoser> and trying to find out what might cause 'BLKRRPART: Device or resource busy'
[01:39] <smoser> i'm not sure that any of the processes in that output have an open handle (as this run didn't fail to resize)
[01:43] <smoser> infinity, you think each of those udevadm processes is handling an event ?
[01:43] <infinity> s/adm/d/
[01:43] <infinity> smoser: No, they're probably all idle.
[01:43] <infinity> smoser: But on a massive event storm (such as initial boot), a ton of children can spawn to handle them.
[01:44] <smoser> ah.
[01:44] <infinity> smoser: In theory, they get reaped.
[01:44] <infinity> smoser: (And on the pivot to real root, I think udev gets restarted, which effectively reaps them anyway)
[01:45] <infinity> slangasek: Can explain it all better than I, but I'm assured that it's basically like a ghetto implementation of apache's prefork child model, and "nothing to be concerned about" (as long as they're not spinning your CPU to death)
[01:45] <infinity> Err, s/://
[01:46] <smoser> yeah.. i'm not too concerned about it.
[01:46] <smoser> but basically, for that bug, i'm trying to figure out what it is that had a open handle on /dev/vda
[01:46] <smoser> to see what was keeping it busy
[01:48] <infinity> I don't suppose your growroot code shares any common ancenstry with jasper_growroot?
[01:48] <smoser> the current suspicion is that there are some udev processes (like blkid) around at that time, and in racey conditions, i'm hitting sfdisk failure.
[01:48] <infinity> Cause I remember fixing a few races in that last cycle.
[01:48] <smoser> if that is the case, then udevadm settle would fix it
[01:48] <smoser> no relation to jasper_growroot.
[01:49] <smoser> i dont know which came first
[01:49] <infinity> Hrm.  Maybe they should consider mating.
[01:49] <smoser> but i only learned of jasper_growroot a while ago.
[01:49] <smoser> yeah.
[01:49] <infinity> Duplicate code offends me. ;)
[01:50] <smoser> link to jasper growroot source?
[01:50] <infinity> But given that we do the same basic thing on SD cards (which, due to their horrible speed, are WAY more racy than anything you're writing to), maybe it's just an ordering thing, or something.
[01:51] <smoser> well... you might be surprised at disk speed.
[01:51] <infinity> I might be. :)
[01:51] <smoser> this particular case is qcow disk backed by a file on a filesystem.
[01:51] <infinity> Still not sure that beats SD.
[01:52] <smoser> so even reads are going read -> qcow-delta -> qcow-backing file -> filesystem file -> disk
[01:52] <infinity> Anyhow, lp:ubuntu/jasper-initramfs is the source.
[01:52] <infinity> It's hackish (your is probably prettier, though I haven't looked, it's a fair assumption), and makes assumptions about device names, but the general step-by-step resizing bit is solid and doesn't seem to break no matter how we stress it.
[01:53] <smoser> the next big move is to ditch the initramfs code all together.
[01:53] <smoser> as psusi (probably spelling name wrong) says that new kernel features allow us to resize a partition that is mounted
[01:53] <maco> cyphermox: i know you're an ubuntu member. does lwn.net say you are or arent a subscriber?
[01:54] <infinity> smoser: Yup.  Moving jasper-initramfs resize into partman in d-i is on my agenda.
[01:54] <infinity> smoser: At which point, I might be able to reach some magical fairytale land of being able to do preinstalled/copy installed to/from the same media!
[01:55] <smoser> well, in my case it doesn't have to be in initramfs or installer (cloud images)
[01:55] <smoser> it would just run on first boot
[01:55] <smoser> (or every boot, and do nothing if not needed)
[01:55] <infinity> smoser: (ie: use "normal" live media to both do a live install to another disk, or to just resize itself)
[01:56] <smoser> you maybe shoudl look at 'growpart' which is the primary code in 'growroot'
[01:56] <smoser> (growroot just calls growpart)
[01:56] <smoser> and it may be prettier, i dont know.
[01:56] <smoser> same basic idea, using sfdisk.
[01:56] <infinity> I didn't write jasper, and if asked, Oliver will admit that it's hideous. ;)
[01:57] <infinity> But yeah, when the "move it all to d-i" thing happens, I'll rewrite, and look at other implementations.
[01:57] <smoser> growpart is in cloud-utils. it has a dry-run, so you can test it out.
[01:59] <cyphermox> maco: I think I didn't have an account. I may be able to respond tomorrow, assuming their system updates regularly for this stuff
[01:59] <maco> cyphermox: oh ok. nvm then
[02:00] <infinity> RAOF: If you fix mesa for me, be sure to poke me, so I can massage it through the queue.
[02:01] <RAOF> I'm fixing now.  I'll prod you once I've uploaded.
[02:01] <infinity> RAOF: My hero. ;)
[02:04] <infinity> Sweetshark: Does libreoffice-voikko need some massaging to build with the new LibO upstream?
[02:04] <infinity> Sweetshark: https://launchpadlibrarian.net/94071457/buildlog_ubuntu-precise-armhf.libreoffice-voikko_3.2-2_FAILEDTOBUILD.txt.gz
[02:04] <infinity> Sweetshark: (Or perhaps the new LibO is missing some SDK bits?)
[02:08] <micahg> infinity: new version in sid, don't know if that'll fix it
[02:09] <infinity> micahg: Hard to say, since it built against LibO 3.4.5 in sid.
[02:10] <micahg> one way to find out, /me kicks off a build
[02:16] <micahg> infinity: nope, doesn't work
[02:19] <micahg> infinity: would you be willing to process removals from Ubuntu that happened in Debian?  /me wants to fix FTBFS over the weekend, but figures quite a few are in that category
[03:27] <RAOF> infinity: Sitting in the queue now.
[03:29] <slangasek> broder: insserv> yay, thanks
[03:37] <scientes> where is KMOD?
[05:55] <pitti> Good morning
[05:59] <nigelb> Morning pitti
[06:05] <scientes> where is the ubuntu kmod?
[06:07] <pitti> scientes: we don't have it yet; it's a bit too young to put into an LTS at this time, we'll get it next cycle
[06:07] <broder> pitti: did we not at least get it into universe?
[06:07] <pitti> seems not; we don't need it anywhere yet, and it will quickly get outdated, so backports etc. sound better for this
[06:08] <micahg> pitti: I see some upgrade failures because cups can't be configured, can you take a look (bug 939977 and bug 939979)
[06:10] <pitti> micahg: yes, in a sec
[06:11] <micahg> sure, no rush
[06:42] <pitti> infinity: linux-meta-armadaxp builds a linux-tools-armadaxp which depends on a nonexisting linux-armadaxp-tools-3.0.0-1500
[06:42] <pitti> infinity: is that supposed to exist, or copy&paste error when creating the -meta?
[07:27] <infinity> pitti: The tools build is turned off in the kernel temporarily because it was broken and getting a kernel uploaded was more important than fixing the tools, AIUI.
[07:27] <pitti> infinity: ack; so it's supposed to be there and will come back then?
[07:27] <pitti> erk, I just got another wubi build failure due to ext4
[07:28] <infinity> pitti: In theory, the tools will come back, yeah.  If not, we'll drop them from the meta.
[07:28] <infinity> pitti: And, err.  ext4 failures shouldn't happen anym--... Unless I forgot to pull my branch on nusakan.
[07:28] <infinity> Which I did. >:(
[07:29] <infinity> pitti: Fixed now.
[07:29] <pitti> infinity: cheers
[07:35] <dholbach> good morning
[07:37] <micahg> janimo`: did libreoffice-voikko build for you?  it failed for me earlier this evening
[07:40] <infinity> micahg: And just failed on all the buildds.
[07:40] <micahg> infinity: we had this conversation 6 hours ago ;)
[07:40] <infinity> micahg: But at least the sync has the advantage of hilighting that it's not an arch-specific problem, so someone will perhaps fix it. :P
[07:40] <micahg> infinity: the archive rebuild did that :P
[07:41] <infinity> micahg: People pay less attention to rebuilds than I'd like. :/
[07:41] <infinity> (We need to figure out how to fix THAT)
[07:41] <micahg> we've fixed >100 since the last rebuild happened
[07:42] <micahg> ~270 failures superseded
[08:14]  * nixternal remembers when micahg used to be in bed at like 9pm here in chicago
[08:14] <nixternal> grr, that was supposed to be in a totally difference channel. hit enter instead of alt+p to get to our chicago chan. sorry
[08:15] <micahg> heh
[08:15] <slangasek> now we know about your secret backchannel
[08:16] <slangasek> you'll all have to move to Wisconsin
[08:16] <micahg> or Portlandia :)
[08:18] <nixternal> Wisconsin? that place still exists?
[08:19] <micahg> it's Dellicious :)
[08:19] <slangasek> is that the new catch phrase?
[08:19] <nixternal> didn't the government go on strike there? though I shouldn't joke about that, since our government here in Illinois & Chicago is constantly going to prison
[08:36] <infinity> micahg: So, voikko upstream claims 3.3 works with LibO 3.5 (in fact, is has 3.5-specific features), so I suspect the failure is in our LibO packaging breaking the SDK.
[08:36] <micahg> ok, so that means Sweetshark^^ :)
[08:38] <RAOF> Hm.  How hard is it to create a C++ function that takes a unary function and returns a nullary function?
[08:38] <infinity> micahg: (I have no hard evidence to back up my assertion, mind you) :P
[08:41] <Sweetshark> infinity, micahg: oh, great. I will have a look.
[08:42] <infinity> Sweetshark: Thanks.
[08:43] <micahg> Sweetshark: Mirv is the Debian maintainer, so it shouldn't be too hard to coordinate :)
[08:43] <pitti> RAOF: creating functions on the fly in C++?
[08:43] <pitti> RAOF: or just returning a pointer to one out of N existing functions?
[08:44] <RAOF> Creating functions on the fly.
[08:45] <RAOF> Now that I *say* this, I know it's possible, but that I'll be overloading operator ().
[08:45] <pitti> RAOF: in C++? (or any compiled language for that matter..)
[08:46] <RAOF> pitti: Well, it's more: take a function f(x) taking a single parameter, and a parameter z, and return a function which evaluates to f(z)
[08:46] <pitti> RAOF: haskell FTW
[08:46] <pitti> RAOF: so just "return f(z)" is too simple, I guess
[08:47] <ion> Haskell ♥
[08:47] <RAOF> Right.  I need a nullary function :)
[08:47] <pitti> i. e. you really want f o z, and want to call it yourself
[08:47] <Sweetshark> RAOF: 'on the fly' as in 'not known at compiletest' => impossible. of course you could write an interpreter *mumble* every language becomes a dialect of lisp at some point in time.
[08:48] <slangasek> RAOF: is the function type fixed?
[08:48] <RAOF> Sweetshark: Well, the underlying function f is known at compile time; I basically want to specialise a closure.
[08:48] <slangasek> or do you have to cope with arbitrary function signatures? :P
[08:48] <Sweetshark> ROAF: functors/function objects are your friend then
[08:48] <Sweetshark> RAOF: for variable meanings of friend
[08:48] <RAOF> slangasek: Indeed it is fixed.  Now that I've said this out loud I know I (a) can do it, (b) can get the outcome I want without all this faffing around.
[08:49] <slangasek> ok :)
[08:50] <Sweetshark> RAOF: http://www.boost.org/doc/libs/1_48_0/doc/html/lambda/le_in_details.html#lambda.bind_expressions <- if you want to get nifty
[08:51] <RAOF> Yeah, I think I'll keep my niftiness for features rather than arcane language extensions :)
[08:57] <Sweetshark> RAOF: yes, that kind of niftiness caused a coworker of mine preaching to gcc, MSVC and SunStudio compilers from his Bjarne-C++-Standardbook, because once he had it so that MSVC wouldnt complain anymore, SunStudio would barf at him -- with both implementations being valid C++ by the book.
[08:57] <RAOF> Ah, Mr Undefined Behaviour!
[08:58] <Sweetshark> RAOF: it not so much an issue with one compiler.
[08:58] <Sweetshark> RAOF: No, it was defined behaviour, but MSVC and SunStudios brains were to small for the insanities of the C++ standard.
[08:59] <RAOF> Ah.  Right, that other form of C++ fun.
[08:59] <ion> Some quotes from a #haskell bot. :-) <lambdabot> mikeash says: you may have noticed that templates being turing complete theoretically allows you to add any language capability to C++.... so did the boost guys.   <lambdabot> kmc_ says: you should take a look at Boost, they implement things like Maybe and tuples in only a few thousand lines of C++
[08:59] <Sweetshark> (and did spit out template errormessages pagewise)
[09:01] <ion> Also, http://pikersden.eu/~eclipser/err.txt
[09:01] <Sweetshark> ion: what to have a fibonacci sequence, but you dont have execution rights on your /home? use templates as an interpreted language: http://blog.emptycrate.com/node/271
[09:02] <ion> heh
[09:02] <Sweetshark> ion: boost::spirit is its own kind of insanity.
[09:03] <Sweetshark> ion: also boost is just a implementation of greenspuns 10th rule of programming
[09:06] <broder> RAOF: C++11 has lambdas
[09:08] <broder> though i'm not sure if you can represent a function type in pure C++ or if you need to pull in boost::function
[09:09] <broder> i guess you can just use a function pointer? the memory management there isn't really clear
[09:16] <Sweetshark> broder: http://ask.slashdot.org/comments.pl?sid=2659339&cid=38964635
[09:18] <broder> i think as long as i capture by value i can do what RAOF wants
[09:19] <broder> http://paste.ubuntu.com/855140/
[09:19] <broder> (build with g++ -std=c++0x)
[09:20] <RAOF> Turns out I can do it just as easily with a static class funtior.
[09:21] <RAOF> Although I forgot how crazy initialising a static member in C++ is.
[09:29] <Sweetshark> infinity, micahg: openclipart and voikko soon fixed upstream at debian it seems.
[09:29] <Sweetshark> (kudos to _rene_)
[09:30] <infinity> Sweetshark: Kay.  So, not a LibO packaging goof?  I just heard the buildds breathe a sigh of relief.
[09:32] <Sweetshark> infinity: no. from 3.5 on the basis-link stuff has changed and that needs to be adjusted in packages relying on it.
[09:32] <infinity> Sweetshark: Fair enough/
[09:32] <Sweetshark> infinity: I have enough fun for the buildds in the pipe still :/
[09:33] <Sweetshark> infinity: btw I made the disc usage of the package quite a bit smaller by using hardlinks/symlinks in the build and testinstall ...
[09:33] <infinity> Sweetshark: *cups his hands over the Pandas' ears*
[09:34]  * Sweetshark pads pandas on the heads.
[09:34] <Sweetshark> They do a good job. Much faster than the old buildds.
[09:35] <infinity> Yup.  We have much faster hardware in the pipe, we just need to get some vendors to admit it exists and, like ship it.
[09:46] <dholbach> Happy Fix It Friday!
[09:52] <sladen> dholbach: https://wiki.ubuntu.com/Membership/LWN  is that ACLed?
[09:52] <sladen> dholbach: I'm trying to update it to add the details about expiry
[09:53] <dholbach> sladen, unless I'm VIP, no
[09:53] <sladen> dholbach: you were the last person to edit it (in 2009)
[09:54] <Guest43539> Hi, I joined ubuntu-mobile yesterday however that channel now seems closed. I am interested in the Ubuntu for Android project and well helping in contributing towards it's development. Can anyone direct me to the right place?
[09:54] <dholbach> sladen, are you logged in?
[09:54] <sladen> dholbach: yes
[09:55] <dholbach> does logging in/out fix it? I wouldn't know how to unACL it or where to check if it is
[09:55] <ajmitch> dholbach: if it's an ACL, it should be at the top of the raw text
[09:55] <ajmitch> (iirc)
[09:56] <dholbach> ajmitch, no, there's nothing there :/
[09:56]  * ajmitch can edit the page, so it doesn't look to be locked
[09:59] <janimo`> micahg, no it does not build. I just synced form Debian so we get it FTBFS on all arches and it does not look like an armhf specific thing which may lead people down the wrong paths
[10:00] <janimo`> was that a bad thing to do?
[10:02] <infinity> janimo`: It's all good, _rene_ is all over fixing it in Debian and filing bugs.
[10:02] <janimo`> infinity, yes, noticed just a few mionutes ago in the LibO-dev channel
[10:02] <infinity> janimo`: But the sync was probably unnecessary, people were aware it wasn't arm-specific.
[10:03] <ajmitch> sladen: manage to edit it?
[10:03] <janimo`> infinity, I was not, and maybe other arm ftbfs hunters were in the same boat
[10:03] <janimo`> I automatically skip all-red rows in the table whereas arm column only jump out :)
[10:03] <infinity> sladen: My usual advice for wiki ACL issues is "hit Ctrl-R harder".
[10:04] <janimo`> I then saw there was an i386 bug filed on voikko, from the autobuilds
[10:04] <infinity> sladen: (It has no ACL that I can see)
[10:13] <apw> ev, i just got a package installation error and when the crash detect stuff fired, it said 'This report is damaged and cannnot be processed.", reporting an IOError(13, 'Permission denied')
[10:18] <sladen> infinity: dholbach: ajmitch: ta.  Eventually managed it using a separate 'lynx' sessions running in a terminal
[10:18] <dholbach> wow
[10:19] <ajmitch> that's pretty special
[10:20] <ajmitch> useful to know about the expiry time though
[10:20] <sladen> the crash reporting process about the crash crashed, so we've fired up a crash reporting process to report the crash that was being reported when it crashed
[10:21] <infinity> drwatson used to have that bug...
[10:21] <infinity> Infinite watsons on early NT4 was no end of fun.
[10:26] <ogra_> hmpf, why are the sound settings so screwed up since yesterdays upgrade
[10:27] <ogra_> the hardware tab is gone, so i cant select the mode my BT headset uses anymore
[10:27] <pitti> that hardware tab was really confusing
[10:27] <pitti> ogra_: the mode is in the output tab now
[10:28] <ogra_> pitti, well, its the only way for me to make my BT headset not run in hifi mode (e.g. as an actual headset to use the mic)
[10:28] <exco> what package do I file bugs in carl9170 against?
[10:28] <pitti> ogra_: hm, that seems to work fine here
[10:28] <ogra_> its greyed out (as it always was ... apart from the HW tab i could set it nowhere)
[10:29] <pitti> ogra_: oh, indeed; same here
[10:30] <ogra_> pitti, i could imagine that settings that can only apply globally (in *and* output) become greyed out
[10:30] <pitti> diwic: ^ who worked on that again?
[10:30] <ogra_> i can select output for the builtin speaker vs the plugged headset
[10:31] <ogra_> but cant change a thing for settings that need to apply for both, in and out at the same time anymore
[10:31] <diwic> pitti, me and ronoc
[10:31] <pitti> ogra_: in the past I didn't even have to -- my headset just used the low-quality bidir mode in mumble and friends
[10:31]  * ogra_ wonders if there is a cmdline way to tell his BT headset to not use hifi mode
[10:32] <diwic> ogra_, there is
[10:32] <diwic> ogra_, want me to tell you? :-p
[10:32] <ogra_> diwic, that would be awesome :)
[10:33] <diwic> ogra_, anyway the easiest workaround is to install pavucontrol which is an alternative GUI
[10:33] <ogra_> ok
[10:33]  * ogra_ does so
[10:33] <diwic> ogra_, you should be able to set profile from the "configuration" tab in that application
[10:34] <ogra_> ok
[10:34] <diwic> ogra_, but also file a bug against the gnome-control-center package, please
[10:34] <ogra_> will do
[10:35] <diwic> ogra_, out of interest, what profiles can you select between?
[10:36] <ogra_> HSP/HFP and A2DP
[10:36] <diwic> ah, same as here then
[10:36] <diwic> I should be able to reproduce it
[10:43] <ogra_> hmpf, the mumble setup wizard just hangs after i selected the device :(
[11:35] <Sweetshark> that would mean rolling back the sacjava, libbase MIRs as they are only needed for reportbuilder and (no libloader=no reportbuilder). meh.
[11:35]  * Sweetshark needs to take a walk.
[11:40] <pitti> Sweetshark: don't worry about the rollback; they will semi-automatically fall out of main again as soon as you drop the b-deps
[11:40] <jibel> slangasek, re upgrade of main - no idea why apt-term.log shows only removals. It looks like a bug in update-manager.
[11:41] <jibel> slangasek, the only log file I found which shows which packages have been upgraded is dpkg.log. It is attached to the test results
[11:42] <jibel> slangasek, I saved the VM if any one want to look into this.
[12:27] <infinity> Sweetshark: Are you already aware of the need for a !armhf fix for the libreoffice-report-builder-bin depdency in the libreoffice metapackage?
[12:28] <infinity> Sweetshark: (Or, alternately, building it for armhf, I guess, but it's not currently)
[12:30] <Sweetshark> infinity: unfortunately the solution is dropping it, as reportbuilder pull in a huge java mess called maven in.
[12:30] <infinity> Sweetshark: Actually, I'm confused now.  Is it built anywhere anymore?
[12:30] <infinity> Sweetshark: The version in the archive on other arches seems to be stale.
[12:31] <infinity> Sweetshark: So, that dep should just be dropped from the metapackage entirely, for all arches...?
[12:33] <TLE> pitti: hallo
[12:34] <Sweetshark> infinity: yes, I enabled building it in the last upload, but it turned out it would require MIRs we cannot fullfill. So I am not building it anymore, and drop the dep in the metapackage.
[12:34] <infinity> Sweetshark: And I should clean the old NBS libreoffice-report-builder-bin binaries from the archive, so this stops looking like an arm-specific issue.
[12:39] <TLE> pitti: I was wondering what the status is of the natty lang pack export
[12:40] <infinity> Sweetshark: Alright, the stale binaries are removed.  When do we see the upload with the fixed meta deps? :P
[12:40] <Sweetshark> infinity: source package is building
[12:56] <Sweetshark> infinity, pitti: libreoffice_3.5.0-1ubuntu4 in /home/bjoern on chinstrap
[12:56] <infinity> Sweetshark: Poking it with a stick.
[12:56] <Sweetshark> infinity: it hisses
[12:57] <Sweetshark> pitti: so only now only the libexttextcat automake1.7 dep remains right?
[13:03]  * infinity watches debdiff cripple his laptop.
[13:03] <infinity> La la la.
[13:04] <pitti> Sweetshark: ah, you dropped the extra build deps?
[13:04] <pitti> infinity: oh, are you sponsoring already?
[13:04] <infinity> pitti: Yeah.
[13:04] <pitti> TLE: sorry, I didn't deal with that yet, too much stuff going on
[13:06] <infinity> pitti: Well, if this command ever returns, I'm reviewing and sponsoring. ;)
[13:06]  * infinity goes to find a coffee and cigarette.
[13:08] <Sweetshark> infinity: argh, that one it buggy still
[13:08] <infinity> Sweetshark: Oh.  Then I'll wait for another. ;)
[13:08] <Sweetshark> (additional comma at the end of the deps)
[13:08] <infinity> Oops.
[13:09] <infinity> Sweetshark: I'll go find that coffee, ping me when the shiny new one's up.
[13:09] <Sweetshark> infinity: well, I removed the last dep in the list :/
[13:23] <TLE> pitti: no problem, let me know when you find the time
[13:24] <doko_> jamespage, maven wants to promote again ...
[13:24]  * jamespage sighs
[13:24] <Daviey> jamespage / doko_ : For 12.10, should we look at allowing maven in main?
[13:25] <doko_> Daviey, if it's maven3, maybe
[13:25] <doko_> jamespage, ahh, scroll up, it's libreoffice reportbuilder
[13:26] <jamespage> doko_, I was just gazing at this - http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[13:27] <doko> jamespage, Sweetshark: and libloader ...
[13:28] <jamespage> doko, Sweetshark: if that is what is pulling it in it might be possible to drop maven by disabling testing in libbtm-java
[13:29] <jamespage> Daviey, we could but the star chart is impressive - http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[13:32] <Daviey> jamespage: happy, happy, joy joy
[13:32] <jamespage> doko, Sweetshark: or demote libehcache-java to Suggests? I'm not familiar with libloader
[13:33] <pitti> it's being handled Sweetshark already has a new version prepped
[13:33] <pitti> (image a comma there)
[13:34] <pitti> argh TGIF -- "imagine"
[13:34]  * jamespage stands down
[13:34] <pitti> jamespage: it's not just the recommends, it's also build deps
[13:34] <pitti> I guess c-m gets a bit confused with so many packages
[13:34] <jamespage> pitti, looks like it - I see
[13:35] <jamespage> pitti, Sweetshark - what fix are you going for?
[13:35] <pitti> Sweetshark | pitti: so only now only the libexttextcat
[13:35] <pitti> jamespage: so I guess he dropped the new build deps again
[13:36] <pitti> LibO has some stripped down internal libraries, I guess he's using those
[13:36] <pitti> in sum they'd probably take much less space like this, too
[13:36] <pitti> libexttextcat can be fixed to use automake instead of -1.7
[14:39] <Sweetshark> infinity, pitti: 3.5.0-1ubuntu4 FIXED on chinstrap.
[14:42] <vanhoof> herton: hi
[14:42] <herton> vanhoof, hi
[14:44] <vanhoof> herton: dont think we're going to get the ack on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/906832 from the original reporter
[14:44] <vanhoof> we (hwe) got involved with that one since it's quite similar to two others (different device ids) in this current SRU
[14:45] <vanhoof> but we don't have that specific chip in house yet to verify on our own
[14:45] <vanhoof> have even emailed the guy directly a few times.
[14:45] <vanhoof> assuming the deadline is COB today?
[14:46] <herton> vanhoof, yes, looks like the guy isn't going to test it. We can wait until monday, since this is verification week.
[14:46] <vanhoof> herton: ack ok
[14:46] <vanhoof> herton: if i hear back in email I'll let you know
[14:47] <vanhoof> herton: and post to the bug :)
[14:47] <herton> vanhoof, ok, thanks
[14:52] <jibel> slangasek, the problem with upgrade test of main seems to be a bad interaction with the way we capture debconf prompts
[14:53] <didrocks> cnd: ping me when you are around, some remarks on xorg-tests package
[14:53] <cnd> didrocks, pong
[14:53] <didrocks> oh, already? :)
[14:53] <jibel> slangasek, I disabled debconf prompt capture, re-ran the test and it seems to proceed with the upgrade. result in 4 hours
[14:53] <didrocks> let's switch to pm to not annoy people :)
[15:29] <jibel> slangasek, it was faster than expected. Now main upgrade failed but for a good reason :)
[15:31] <pitti> Sweetshark: roger, uploading
[15:35] <pitti> Sweetshark: so this is the good one for b1? or does anything else need to be sorted out?
[15:35] <pitti> Sweetshark: it basically reverts to ubuntu2, right?
[15:36] <Sweetshark> pitti: it revert parts, but not all. some MIRs went well, so lets keep them.
[15:36] <pitti> Sweetshark: ah, good
[15:37] <Sweetshark> now, if I am not mistaken we only need to drop the automake1.7 dep in libexttextcat.
[15:37]  * Sweetshark has a source package already.
[15:37] <pitti> yes
[15:37] <pitti> Sweetshark: toss it over? It's a good thing to fix either way
[15:37]  * Sweetshark fuddles it out of the virtualbox
[15:39] <pitti> Sweetshark: ubuntu4 uploaded (CC: infinity)
[15:43] <Sweetshark> pitti: tweaked libexttextcat in on chinstrap
[15:44] <pitti> Sweetshark: can you please upload libexttextcat_3.2.0-1ubuntu1.dsc?
[15:44] <pitti> Sweetshark: (you uploaded libexttextcat_3.2.0-1.dsc)
[15:44] <Sweetshark> pitti: ugh
[15:45] <Sweetshark> pitti: done
[15:46] <pitti> Sweetshark: uploaded; would be nice if you could send this to Debian, too
[16:08] <bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/precise/ubuntu-wallpapers/fix-for-296538/+merge/92592
[16:31] <pitti> bkerensa: ^ lots of conflicts
[16:31] <pitti> bkerensa: also, it needs to be called .png for backwards compat reasons
[16:49] <pitti> barry: how much would you hate me when we switch lsb-release back to py2.7 and drop python3 from the CDs again? we are a bit despearate on size now
[16:50] <pitti> barry: and we only carry it for the tiny lsb-release script
[16:50] <pitti> barry: from next cycle on we'll have bigger images and can keep it, promised
[16:51] <pitti> barry: (already talked to stgraber, doko, ScottK, and skaet)
[16:51] <barry> pitti: i will hate you forever
[16:51] <barry> pitti: kidding :)  do what you have to do
[16:52] <pitti> barry: thanks, taking the bullets *sob*
[16:52] <barry> pitti: i'm very happy with the progress we made, and i'm confident we'll see py2 relegated to universe for 14.04!
[16:53] <pitti> sounds like a plan
[16:53] <pitti> barry: and indeed, lots of new py3 modules in precise, including py3-dbus which was a major blocker indeed
[16:53] <pitti> barry: now we just need launchpadlib
[16:54] <barry> pitti: yep, we'll get there
[16:56] <pitti> Sweetshark: now, that's much better: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[16:56] <Sweetshark> pitti: nifty!
[16:57] <pitti> Sweetshark: promoting textcat now
[16:57] <pitti> Sweetshark: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has the demotions now, doing them as well
[16:58] <Sweetshark> pitti: although its a bit boring. It invokes the same urge in me as precise did in chrisccoulson (according to the quotes page): "Can I break it?!"
[17:00] <slangasek> jibel: oh, you mean it wasn't doing the upgrade at all? :(
[17:01] <pitti> Riddell: will calligra drop the recommends: lyx? (http://people.canonical.com/~ubuntu-archive/component-mismatches.svg)
[17:01] <pitti> Daviey: ^ on the same page, do you know the status of the keystone MIR?
[17:01] <pitti> this has been there for months
[17:01] <slangasek> jibel: thanks for identifying the problem, though
[17:01] <Riddell> pitti: I don't know, wasn't aware of it, but I expect it can yes
[17:01] <jibel> slangasek, it was doing the upgrade, but not completely
[17:02] <jibel> slangasek, there is a bug in apt or update-manager here any way
[17:02] <Daviey> pitti: yes.. it's blocked
[17:02] <Daviey> pitti: The underlying code is being changed next week
[17:02] <Daviey> (rewrite from scratch)
[17:03] <Daviey> Once that is introduced into the platform, jstrand's team will need to re-do the audi.. sadly.
[17:28] <pitti> Daviey: new nova needs new MIRs: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[17:28] <pitti> Riddell: ^ FYI
[17:29] <pitti> will depwait, so no immediate archive breakage
[17:29]  * pitti waves good bye, have a nice weekend everyone
[17:29] <dholbach> pitti, you too
[17:42] <slangasek> jibel: where did you see that the upgrade was incomplete then?
[17:48] <m_3> cjohnston: hi.. how many django app servers are typically used in a single summit deployment?
[17:49] <cjohnston> m_3: just 1
[17:49] <m_3> cjohnston: gracias!
[17:50] <cjohnston> :-)
[18:40] <chrysn> once again, i'd need some help finding out why my ppa builds don't work:
[18:41] <chrysn> in the chrysn/openscad ppa, i'm trying to build opencsg-1.3.2-2lucid1, for which i've collected some backports in the same repository
[18:41] <chrysn> i've previously made the experience that the builder uses the ppa itself to satisfy build-depends.
[18:43] <chrysn> but now, it complains about missing build dependencies "libglew-dev (>= 1.5.4)" -- but the build dependency says "libglew-dev (>= 1.5.4) | libglew1.6-dev | libglew1.5-dev (>= 1.5.4)", and i provide libglew1.6-dev in the ppa
[18:45] <chrysn> admittedly, libglew-dev is (in that ubuntu version) also a virtual package whose version can't be satisfied, but it shouldn't bee too uncommon to have alternative build-depends whereof the first is virtual
[18:50] <Ampelbein> chrysn: I think the sbuild version LP uses doesn't support resolving alternate dependencies.
[18:50] <arand> chrysn: I'm not sure, but the log seems to indicate that you should not use the metapackage?
[18:51] <micahg> it doesn't support alternatives where the one is versioned
[18:52] <micahg> bug 594916
[18:54] <chrysn> thanks you all. i guess i'll work around it by building an explicitly depending pakcage for the moment
[18:55] <chrysn> arand, the reason i'm using the "metapackage" is that the newest version (1.7) doesn't build a libglew1.7-dev but a generic libglew-dev
[18:57] <adam_g> anyone have any knowledge of the squid -> squid3 transition? are there blueprints from last cycles around, or mailing list discussion anywhere to get some context around the decision?
[19:09] <ansgar> Hi, I was wondering if Ubuntu might want to sync libquvi and cclive from experimental.  It not really usable right now (#874554).
[19:14] <ansgar> For your entertainment this would also include a soname change, but libquvi only has two reverse dependencies (cclive and one other).
[19:15] <micahg> ansgar: I count 3 reverse dependencies in the archive, but feel free to file the request if it's broke (requestsync -e -d experimental), by the way, what's keeping them from being uploaded to unstable?
[19:16] <micahg> it'll still need release team approva
[19:16] <micahg> *approval
[19:16] <ansgar> micahg: Waiting for Debian's release team to ack the upload to unstable.
[19:16] <micahg> ah, ok
[20:31] <maco> >_>   <_<   new vm wants to use nano when i type "dch -i" setting EDITOR=/usr/bin/vim in bashrc and sourcing it didn't change this. where does dch keep its notion that i want nano?
[20:35] <cody-somerville> maco, try running select-editor
[20:35] <maco> ooh didnt know that existed
[20:35] <maco> thanks cody-somerville
[20:35] <maco> my next guess was going to involve ln -s
[20:35] <cody-somerville> maco, dch uses sensible-editor which will look at VISUAL and then EDITOR
[20:36] <maco> cody-somerville: its been a while since ive doen this. whats that thing for making pbuilders real easy, and what package is it in?
[20:38] <cody-somerville> maco, There are a number of different things out there - but the only thing that I know of that is packaged is pbuilder-dist in ubuntu-dev-tools
[20:39] <cody-somerville> maco, I personally just use a .pbuilderc file and environmental variables: http://pastebin.ubuntu.com/855806/
[20:39] <maco> pbuilder-dist is what i was thinking of. thanks!
[20:40] <cody-somerville> maco, You're most welcome :)
[20:41] <cody-somerville> If you have any further questions, don't hesitate to ping me.
[20:43] <slangasek> stgraber: should the values on dns-nameservers lines always be numeric?
[20:43] <slangasek> stgraber: to be precise: does [0-9.]+ cover it as a regexp?
[20:43] <slangasek> (thinking specifically of ipv6 here)
[20:43] <stgraber> slangasek: if you extend your definition of numeric to contain ":" then we should be fine, yes
[20:44] <slangasek> ok
[20:44]  * stgraber is quickly checking on a system using dns-nameservers with ipv6
[20:44] <slangasek> some things like to put ipv6 addresses in brackets, didn't know if this was one
[20:45] <stgraber> slangasek: at least resolv.conf doesn't use brackets but I'll quickly check for resolvconf
[20:45] <slangasek> stgraber: also, I believe we have to remember that a-f are numbers for this purpose? :)
[20:45] <slangasek> does netcfg give us upper or lower case?
[20:46] <stgraber> good questions, it's probably taking them as-is from the RA so I'd say lowercase
[20:46] <slangasek> the RA is text?! :)
[20:48] <beuno> so, switching workspaces is broken, right?
[20:50] <bryceh> beuno, try <super><shift><arrow> ?
[20:50] <stgraber> slangasek: netcfg doesn't deal with RDNSS directly at the moment, it uses rdnssd if around which returns the IP in lowercase
[20:51] <slangasek> stgraber: ok
[20:51] <stgraber> slangasek: I'm checking what's dhclient's behaviour for dhcpv6 now
[20:54] <stgraber> slangasek: actually, netcfg doesn't write these to /etc/network/interfaces, it'll just mark the interface "iface ethX inet6 auto" or "inet6 dhcp"
[20:54] <beuno> bryceh, nope, not working either
[20:54] <slangasek> stgraber: so we only have ipv4 to worry about?
[20:54] <beuno> tried it, it's what the overlay says now
[20:54] <stgraber> slangasek: so the only case where dns-nameservers contains an IPv6 value as a result of an install is when installing with static
[20:54] <stgraber> slangasek: and in static, it's whatever the user entered
[20:55] <slangasek> stgraber: ok, so upper+lower case are valid
[20:55] <stgraber> yep
[20:55] <bryceh> beuno, dunno then.  does the icon switcher thingee work?
[20:56] <beuno> bryceh, it does
[20:56] <beuno> I'll file a bug
[20:56] <beuno> thanks bryceh
[20:56] <slangasek> stgraber: how's this look to you? ;)
[20:57] <slangasek> grep -Eq '^[[:space:]]*(iface[[:space:]]+.*[[:space:]]+inet[[:space:]]+dhcp|dns-nameserver[[:space:]]+[0-9A-Fa-f.:]+[[:space:]]*(#.*)?$)' /etc/network/interfaces
[20:58] <barry> slangasek: can you sanity check something for me?  try to apt-get the oneiric source for kexec-tools and build the source package w/debuild -S.  does it work or fail for you?
[20:58] <stgraber> I think we could extend to cover "inet6 dhcp" too but it's not going to be a common use case ;)
[20:59] <stgraber> it needs to be "dns-nameservers" (plural)
[20:59] <stgraber> and can be dns_nameservers
[20:59] <slangasek> barry: build it on what environment? oneiric, precise?
[21:00] <stgraber> other than these, it looks good (though my brain's regexp parser is far from perfect ;))
[21:00] <slangasek> yeah, I fed it a couple of examples here
[21:00] <slangasek> but of course I missed the variable name misspelling
[21:00] <slangasek> thanks
[21:06] <slangasek> stgraber: resolvconf uploaded, then
[21:06] <slangasek> stgraber: I'll have a look at ifupdown a little bit later
[21:06] <stgraber> slangasek: thanks!
[21:07] <stgraber> slangasek: btw, blog post published, will see how many people complain about it in the comments ;)
[21:09]  * infinity starts trolling stgraber's blog.
[21:10] <slangasek> stgraber: just block everything from quagga_fan_in_calgary
[21:10] <infinity> >:(
[21:10]  * broder resists the urge to make canada jokes
[21:11] <stgraber> slangasek: I'll just add a new static route to my quagga to route quagga_fan_in_calgary to a blackhole ;)
[21:15] <barry> slangasek: i'm just trying to get a source package built :/
[21:15] <slangasek> barry: yes, but which environment are you trying to build it in :)
[21:16] <barry> slangasek: i've tried on precise, but also in an oneiric chroot.  i've tried from apt-get source and from the udd branch, all fail in the same way
[21:17] <infinity> barry: With the build-deps installed?
[21:17] <barry> infinity: doesn't even get that far.  `debian/rules clean` fails because it can't unpatch
[21:17] <slangasek> barry: ok, having a look
[21:17] <infinity> barry: But, I dunno, if you're just patching the pristine source, and thus don't need a clean, cheat and debuild -S -nc :P
[21:17] <infinity> barry: Yes, but unpatch may rely on the build-deps being installed.
[21:17] <barry> infinity: yeah, may have to do that ;)
[21:18] <slangasek> barry: right, 'debian/rules clean' isn't guaranteed to work without the build-depends installed
[21:18] <slangasek> debian/rules:12: /usr/share/dpatch/dpatch.make: No such file or directory
[21:18] <slangasek> make: *** No rule to make target `/usr/share/dpatch/dpatch.make'.  Stop.
[21:18] <slangasek> like so
[21:18]  * infinity nods.
[21:18] <barry> gotcha, okay, thanks
[21:18] <infinity> You could just install dpatch.
[21:18] <infinity> But if you're sure you're doing things cleanly, -nc is fine.
[21:18] <slangasek> in a chroot in a container in a vm in a pocket universe
[21:18] <slangasek> where it won't contaminate anything
[21:18] <barry> i actually thought i had it installed but apparently not ;)
[21:18] <infinity> Just double-check your debdiff after an -nc build to make sure you didn't introduce cruft.
[21:20] <barry> slangasek, infinity actually, no.  on precise i *do* have dpatch installed.  installing build-deps in an oneiric chroot does pull in dpatch, but `dpatch deapply-all` still fails
[21:20] <barry> so i will try -nc, but this seems like a problem with the package
[21:21] <infinity> Or a problem with how you fiddled with patches in your upload?
[21:21] <infinity> After you do that -nc build, dpkg-sourc -x it to a new directory and make sure it builds. :P
[21:21] <barry> infinity: i haven't uploaded anything yet, just apt-get source && debuild -S
[21:21] <infinity> Oh.
[21:22] <infinity> Though it may now be dirty from previous sadness.
[21:22] <infinity> That would be a bug, mind you. :P
[21:22] <infinity> clean making things unclean isn't, sadly, uncommon.
[21:22] <barry> infinity: that's what i was looking for :)
[21:22] <barry> :(
[21:23] <infinity> (That said, we expect build-deps to be installed for all steps, so if it works correctly from a fresh download with build-deps installed, the rest is a wash)
[21:23] <barry> cool, infinity, slangasek thanks for the confirmation
[21:23] <barry> infinity: right, but it doesn't so i'll file a bug
[21:23] <barry> actually, i should check the precise version.  it's not worth an sru
[21:24] <slangasek> but you're doing an SRU anyway? :)
[21:24] <slangasek> so it might be worth fixing the build system along the way
[21:25] <barry> slangasek: think so?  i thought it was generally frowned on to mishmash fixes.  but if not, and it's an easy-ish fix, it would be wroth it
[21:25] <barry> worth it even
[21:26] <barry> slangasek, infinity yep, precise is happy
[21:26] <infinity> I'm curious how the original source package was built if it is, indeed, broken.
[21:26] <barry> infinity: my question too!
[21:26] <micahg> well, it's using dpatch, that's strike 1 :)
[21:26] <barry> yes :)
[21:26] <slangasek> it's frowned upon to include low-priority fixes in an SRU; but fixing things like "the build system is fubar" warrant coming along for the ride
[21:27] <infinity> Indeed.
[21:27] <infinity> Let me double-check this.
[21:27] <barry> fair enough, yep, and thanks
[21:34] <infinity> barry: I hate to be the bearer of confusing news for you, but in an oneiric chroot, with build-deps installed (all build-deps, mind you), a freshly-unpacked kexec-tools source builds itself just fine.
[21:35] <infinity> Even several times in a row.
[21:35] <barry> infinity: dang, but okay that's very interesting and makes me more optimistic.  thanks for the confirmation
[21:36] <infinity> barry: I suspect you're working in a dirty source tree from previous no-build-deps-installed clean failures, or sometihng.
[21:36] <infinity> barry: So, a fresh download, a fresh unpack, and making sure ALL the build-deps are installed before you build your source should do it.
[21:37] <barry> infinity: trying that...
[21:37] <infinity> (The kicker being that it not only needs dpatch to build the source, but also autoconf/automake)
[21:37] <infinity> But just check with dpkg-checkbuilddeps before you build. :P
[21:51] <barry> infinity: the combination of building in the distroseries chroot + installing build-deps before debuild -S seems to solve the problem
[21:54] <infinity> barry: Good deal.
[23:10] <slangasek> adam_g, zul: is this new upstream version of glance needed/wanted/expected for beta-1?  (currently sitting in the freeze queue)
[23:11] <slangasek> and should it have a FFe for the new upstream version?
[23:26] <adam_g> slangasek: hmm, im not sure? the other parts of openstack were uploaded at the same time
[23:27] <adam_g> slangasek: that new upload does have a new dependency that is not in main, though
[23:27] <slangasek> adam_g: well, that new dep is already on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt due to nova
[23:27] <slangasek> so that wouldn't seem to be a blocker IMHO
[23:39] <adam_g> slangasek: hm then im not sure, the new version is expected to be uploaded with the rest of openstack every week, not sure why it'd need a FFE in this case
[23:40] <slangasek> adam_g: n/m, there's a standing FFe that I wasn't aware of
[23:40] <slangasek> so that's good to go in
[23:40] <slangasek> but someone probably needs to fix those new deps on universe
[23:43] <adam_g> slangasek: what is the policy on new MIRs for such things this late?
[23:44] <slangasek> adam_g: MIRs aren't subject to the freeze
[23:44] <slangasek> it's the changes to the packages already in main that are usually dubious :)
[23:44] <slangasek> (in this case it's fine, and someone needs to follow through on the MIR)
[23:45] <adam_g> slangasek: gotcha