[00:01] <jtaylor> works for me too 11.10
[00:01] <stgraber> it doesn't seem true for /proc/1/cmdline here though (not null terminated)
[00:03] <tumbleweed> 1 is rather special...
[00:03] <tumbleweed> on Debian, it's very null-terminated :P http://paste.ubuntu.com/830783/
[00:04] <stgraber> ;)
[00:16] <cargo23_> http://paste.ubuntu.com/830791/
[00:16] <cargo23_> from man proc:   The command-line arguments appear in this file as a set of strings separated by null bytes ('\0')
[00:17] <cargo23_> Is there a better forum for this question?
[00:17] <cargo23_> I'm new to working with the procfs, for sure.
[00:21] <cargo23_> It is supposed to contain nulls, not just end with them?
[00:29] <tumbleweed> I assume that's the result of chrome modifying argv itself for cosmetic reasons, and not null-terminating, but that's a whild guess
[00:47] <stgraber> cargo23_: http://paste.ubuntu.com/830815/ is an example of how to mess with cmdline taken from rdesktop's code, this specific example only overwrites the value passed after -p but you can certainly mess with the whole cmdline if you want
[00:48] <stgraber> oh, ignore that printf, was there for debugging purpose ;)
[03:56] <cjohnston> the lpupdate was
[04:58] <pitti> Good morning
[05:39] <slangasek> doko: well, this is why MIR bugs are supposed to be left open until an archive admin reconciles it against component-mismatches :)
[07:53] <dholbach> good morning
[08:31] <fishor> hallo devs! are there any way to have this patch included with precises xserver?  https://bugs.freedesktop.org/show_bug.cgi?id=41115
[08:56] <RAOF> fishor: Maybe.  Can you please file a launchpad bug to track that?
[08:57] <fishor> RAOF, there is one long standing bug report here: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/589485
[08:57] <RAOF> Oh, yeah.  That's right.
[08:57] <RAOF> Sorry.
[08:58] <fishor> no problem. i can thest the patch with precise xorg, but i wont te be sure it will be added to the package
[08:59] <fishor> i never had problems with my old lcd screen, but with new laptop it is really bad
[08:59] <RAOF> What's actually looking at that DPI value, anyway?
[08:59] <RAOF> (IIRC both GNOME and KDE ignore it, as does Firefox)
[09:01] <fishor> RAOF, it is probably just part of the problem. i just started to digg in  issue. first i found is xorg and xdpyinfo show different sizes.
[09:02] <RAOF> You can make GNOME use the right DPI in gnome-tweak-tool (fonts).
[09:03] <RAOF> As you go up the stack, you'll continue to hit the same reasons that Xorg has - physical DPI isn't actually the number that you're after; you actually want a number based on physical DPI and the distance you are from the screen.
[09:04] <fishor> how about other issue. for example libreoffice show page in 100% size double as small as it should be
[09:05] <RAOF> If libreoffice wants to show at the correct size it should be getting the per-output numbers (which are, and have always been, correct and available through xrandr).
[09:06] <RAOF> Because otherwise it'll break in not-too-uncommon circumstances anyway, like having two monitors.
[09:06]  * RAOF -
[09:06]  * RAOF → dinner
[09:07] <fishor> yea... i have two monitores .. the external has physical dpi ~96, the internal is about 138dpi
[09:07] <fishor> i should probably give this laptop to some dev who argumenting against it :) he should burn his eyes
[09:13] <pitti> jibel: thanks for the apt verification in lucid! I'm not quite sure whether that tested the release-upgrader-apt "special" package or the general apt
[09:19] <cjwatson> pitti: jenkins tests the release-upgrader-* packages, effectively
[09:20] <pitti> cjwatson: thanks, what I thought; for apt itself we'd need to check apt-get dist-upgrade supposedly?
[09:20] <pitti> cjwatson: I'm fine with moving r-u-apt to -updates now, unless you want to wait for the full 7 days
[09:25] <cjwatson> yes, and makes sense
[09:25] <pitti> jibel: nice to see that the post-upgrade conf tests all succeed nwo
[09:25] <pitti> now
[09:25] <dholbach> blueyed, Happy Birthday! :)
[09:56] <pitti> Riddell, ScottK, debfx: okular was removed in Debian, "superseeded by kdegraphics/experimental"; should we follow suit?
[09:57] <Riddell> umm no
[09:57] <Riddell> tsdgeos: ^^ eh?
[09:57] <tsdgeos> lol
[09:57] <tsdgeos> kdegraphics/experimental?
[09:57]  * pitti keeps gwenview as well, got repackaged in Debian
[09:57] <tsdgeos> what's that?
[09:58] <tsdgeos> we don't even have a proper kdegraphics package anymore
[09:58] <Riddell> pitti: got a bug number or other reference?
[09:59] <pitti> debian bug 515827
[09:59] <pitti> I figure we just have a different packaging
[09:59] <pitti> it's nothing urgent at all, it just came up in process-removals
[09:59] <tsdgeos> 2009 ?
[09:59] <Riddell> pitti: "Date: Tue, 17 Feb 2009 21:22:59 +0100"
[10:00] <Riddell> it will have reappeared in process-removals because "okular" source package reappeared
[10:00] <Riddell> blacklist it from process-removals
[10:00] <pitti> I'll just ignore it then, together with the other KDEish packages
[10:00] <pitti> seems it's all right then
[10:03] <jibel> pitti, the conf test is still failing for desktop but hidden. Currently the upgrade testing system doesn't have the granularity to run a test with different settings depending on the profile.
[10:03] <jibel> but I'll find a way to fix that
[10:04] <pitti> jibel: oh? I looked at the lucid->precise desktop upgrade log, and they all succeeded
[10:05] <jibel> pitti, they do but this prompt https://jenkins.qa.ubuntu.com/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/18/artifact/lts-ubuntu-amd64/debconf.log shouldn't be there
[10:06] <pitti> jibel: aah
[10:06] <pitti> jibel: so it's not the lts-{user,system}.py stuff that's failing, but a debconf question
[10:06] <jibel> pitti, right
[10:07] <jibel> what is the expected behavior of the upgrader when a package is upgraded from lucid/main to precise/universe ? keep at the same version, upgrade, something else ?
[10:07] <jibel> mvo, ^
[10:09] <pitti> mvo: if you have universe enabled, upgrade
[10:09] <pitti> if not, the package will behave as it disappeared entirely, so it shuold be kept
[10:09] <pitti> but usually we should keep the transitional packages in main
[10:09] <pitti> we often don't
[10:09] <pitti> we need to seed them explicitly, otherwise they fall out
[10:09] <pitti> I guess we'd need an upgrade test with not enabling universe in lucid, and then dist-upgrading
[10:11] <tjaalton> TREllis: \o/ thanks for replying to the ESR thread :)
[10:13] <tjaalton> now how do I force-enable enigmail..
[10:13] <TREllis> tjaalton: no problem, not sure if there is an issue shipping it in universe
[10:14] <TREllis> tjaalton: 12.04 thunderbird update knocked out your plugins?
[10:14] <tjaalton> TREllis: yep, enigmail, lightning and mail redirect
[10:15] <TREllis> tjaalton: same story for me :)
[10:25] <tjaalton> TREllis: "disable compatibility check" addon
[10:26] <TREllis> tjaalton: ah-ha!
[10:26] <tjaalton> I saw that enigmail should work with 11 just fine
[10:39] <Sweetshark> infinity: ping?
[10:40] <Sweetshark> infinity: https://launchpadlibrarian.net/90605123/buildlog_ubuntu-precise-amd64.libreoffice_1%3A3.5.0~rc1-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz <- I need more discspace on PPA builders for LibreOffice, please.
[10:41] <tjaalton> TREllis: meh, doesn't seem to work
[10:41] <tjaalton> enigmail 1.3.5 that is
[10:45] <TREllis> tjaalton: yeah fails for me too on lightning, I can probably grab the latest builds manually, but slightly annoying
[10:48] <tjaalton> TREllis: trying enigmail nightly, something weird with that also
[10:48] <tjaalton> doesn't find /usr/bin/gpg for starters
[10:50] <tjaalton> and lightning fails too yes
[10:50] <tjaalton> was nice using them for a week or two :)
[10:53] <tjaalton> oh nice, I have tbird 10 packages on the hd
[10:53]  * tjaalton downgrades
[11:15] <pitti> slangasek: openssl098 was removed in Debian, and I guess for LTS we want the same; the only rdepends is ia32-libs-multiarch, I figure we can drop it there?
[11:16] <cjwatson> pitti: hmm
[11:17] <cjwatson> pitti: I thought it would be a good idea to keep it as it's a common thing found in linkage of third-party binaries
[11:17] <cjwatson> seems like a likely audience for ia32-libs too ...
[11:18] <pitti> it's in universe, so by the letter we aren't committed to security support
[11:18] <pitti> but in practice I guess we'll have to anyway
[11:18] <pitti> if programs are actually using it still
[11:18] <cjwatson> I don't know that for sure, but given the sheer number of things we had to port to 1.0.0 in Debian/Ubuntu proper, I'd be surprised if there were none outside
[11:19] <cjwatson> http://people.canonical.com/~ubuntu-archive/transitions/openssl.html
[11:23] <diwic> dholbach, hi!
[11:23] <dholbach> hi diwic
[11:24] <diwic> dholbach, the wiki page https://help.ubuntu.com/community/SoundTroubleshootingProcedure is completely crazy and you're more likely to destroy your sound stack than to fix it if you use the instructions.
[11:24] <diwic> dholbach, yet someone seems to maintain it
[11:24] <diwic> dholbach, what is the suggested course of action?
[11:24] <dholbach> diwic, it might be worth talking to the folks in #ubuntu-doc
[11:25] <dholbach> AFAIK they take care of help.u.c
[11:26] <diwic> dholbach, hmm, I'll try asking the same question there
[11:27] <jibel> pitti, I think dist-upgrader in Precise must be updated to the right version of libapt-inst and libapt-pkg in Lucid
[11:28] <pitti> mvo: ^ ?
[11:28] <cjwatson> jibel: hmm?
[11:29] <jibel> when I run a do-release-upgrade in lucid I get
[11:29] <jibel> ImportError: libapt-pkg.so.4.12: cannot open shared object file: No such file or directory
[11:29] <cjwatson> uh, I don't
[11:29] <cjwatson> isn't that what we just promoted to lucid-updates?
[11:30] <cjwatson> unless you mean
[11:30] <cjwatson> DistUpgrade/DistUpgrade.cfg.lucid:Packages=libapt-pkg4.11,libapt-inst1.3,release-upgrader-python-apt
[11:30] <cjwatson> I don't know how much difference that makes since release-upgrader-python-apt should pull in the right versions by dependencies anyway
[11:31] <cjwatson> hm, it does make a difference for the CD though, at least - I'll update that
[11:33] <jibel> maybe that's just a matter of waiting. I'll retry in a bit.
[11:35] <mvo> jibel: hello, it should pick out the latest version of the release-upgrader-backport packages, but I missed some context so I'm not sure if that is a reasonable answer
[11:37] <mvo> jibel: I will read scrollback, on my way to lunch
[11:47] <TREllis> tjaalton: hmmm yeah, after a fresh restart the plugins would start but issues all over the place with them... so leaving disabled for now
[11:49] <tjaalton> TREllis: you can grab the old one here https://launchpad.net/ubuntu/+source/thunderbird/10.0+build1-0ubuntu1
[11:50] <TREllis> tjaalton: ty
[11:56] <TREllis> tjaalton: yep, that worked like a charm. I wish we could link the thunderbird builds to the xul plugins :)
[12:03] <cjwatson> jibel: well, I've uploaded a new u-m now which will hopefully help
[12:17] <infinity> Sweetshark: Not my area anymore, you want lamont.
[12:19] <Sweetshark> lamont: https://launchpadlibrarian.net/90605123/buildlog_ubuntu-precise-amd64.libreoffice_1%3A3.5.0~rc1-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz <- I need more discspace on PPA builders for LibreOffice, please.
[12:21] <gnuoy> Sweetshark, whats the ppa ?
[12:22] <Sweetshark> gnuoy: https://launchpad.net/~libreoffice/+archive/ppa
[12:23] <gnuoy> Sweetshark, how much additional space are you after?
[12:24] <Sweetshark> gnuoy: dunno :( -- enough to build LO.
[12:24] <ogra_> 3TB ?
[12:24] <ogra_> :)
[12:25] <Sweetshark> gnuoy: it is failing rather late, so it shouldnt be too much additional space.
[12:25] <geser> wow, 26 GB aren't enough to build LO?
[12:26]  * ogra_ hopes geser gets that he wasnt serious :)
[12:26] <ogra_> you need 3TB RAM though :P
[12:27] <geser> now I know why disk space steadily increases and cpus get faster: to keep be able to build LO
[12:27] <gnuoy> Sweetshark, I've increased the limit from 10Gb to 15Gb
[12:28] <geser> gnuoy: I doubt he meant the PPA space but the buildd disk space used by PPA builders
[12:29] <ogra_> most likely (if lamont is involved)
[12:29] <geser> but that would probably still be needed soon
[12:29] <gnuoy> geser, ah, ok
[12:29] <mvo> jibel: oh, its a new ABI - in this case this needs updating, but I saw that colin did it already (thanks for that)
[12:30] <geser> gnuoy: from the build log: "Build needed 09:28:17, 25995940k disk space" and it died with "IO error: write error during copy : No space left on device"
[12:32] <infinity> gnuoy: Yeah, this one requires the actual PPA Xen images being rebootstrapped.  It might actually be a Spads thing, not a lamont thing, but I've lost track of who does what since I left IS.
[12:32] <infinity> (Well, it's possible one could fudge it by just expanding the image on a few machines)
[12:32] <gnuoy> infinity, ok, let me find out
[12:32] <lamont> increasing that disk space is going to be somewhat problematic, I suspect.  When the kernel smacked into it a while back, they taught their build to remove intermediate copies of things
[12:33] <infinity> lamont: Do we actually still have PPAs with disks that small?  Seems unlikely.  I imagine the airlock could just have the limit bumped.
[12:33] <lamont> 72GB drive yields about 26GB of usable space for the ppa builder
[12:33] <infinity> And we still have some 72G ones?  Fair enough.
[12:33] <lamont> many
[12:33] <infinity> Shame.
[12:34] <infinity> Oh, wait.  But the airlock didn't use set sizes, did it, it did percentages?
[12:34] <infinity> So, one could manually throw LibO at a machine with more disk.
[12:34] <infinity> Pain in the butt, but doable.
[12:34]  * lamont notes that allspice, one of the newest in the fleet, has a 72GB drive
[12:53] <cjwatson> mvo: have you had any further thoughts on https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034694.html ?  Would you like me to try to construct a non-ABI-breaking backport?  (Not sure I know how immediately, but ...)
[12:58] <herton> pitti, hi, can you or other archive admin copy linux-meta 2.6.35.32.42 and linux-backports-modules-3.0.0 3.0.0-16.9 from ckt-ppa to -proposed? We detected 2 bugs which we would like to address in current SRU cycle.
[13:01] <Sweetshark> gnuoy: thx, retriggering the builds
[13:05] <mvo> cjwatson: sorry, on the phone right now
[13:08] <jibel> cjohnston, u-m update fixed the problem. thanks
[13:12] <cjwatson> jibel: excellent
[13:21] <mvo> jibel: the ordering bug from last week?
[13:22] <mvo> cjwatson: I will attack that right after the call
[13:32] <pitti> herton: done
[13:34] <herton> pitti, thanks
[13:40] <cjwatson> mvo: great, thanks
[13:54] <pitti> jibel: hm, I can't find a bug report for the qdbus <-> libqt4-dbus cyclic dependency; does that ring a bell for you (i. e. I'm too dense to search), or shall I report it?
[13:54] <pitti> jibel: (lucid->precise universe upgrade failure)
[14:03] <jibel> pitti, I didn't file a bug for this issue and haven't found one on LP
[14:04] <pitti> jibel: thanks; doing now
[14:05] <jibel> pitti, lucid -> precise main is interesting, the test passes but actually the system is not really upgraded
[14:05] <jibel> pitti, most packages are removed or kept at the same version
[14:05] <jibel> https://jenkins.qa.ubuntu.com/job/precise-upgrade-lucid-main/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/13/artifact/lts-main-all-amd64/main.log
[14:10] <pitti> jibel: eww -- that might be an apt regression?
[14:10] <pitti> mvo: ^ did you ever see this?
[14:15] <jdstrand_> cjwatson: is http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ still the most up to date version of the ubuntu policy manual?
[14:16] <jdstrand> cjwatson: hello btw :)
[14:23] <pitti> Riddell, debfx: are you ok with me doing an upload for bug 927637?
[14:23] <pitti> i. e. dropping libqt4-dbus' Depends: qdbus
[14:24] <pitti> ... turning it into a recommends, I mean
[14:26] <pitti> jibel: FYI, filed as bug 927637 (if you want to apply some extra magic tags)
[14:27] <Riddell> pitti: hang on
[14:27] <Riddell> pitti: I have another change, can you commit somewhere and I'll do the other bit?
[14:27] <pitti> Riddell: sure; I pushed it into the packaging branch
[14:28] <Riddell> pitti: ta, I'll get onto it in a bit
[14:28] <pitti> Riddell: it's certainly not _that_ urgent, but would be good if we can get this in in the next days to get to the next failure :)
[14:28] <pitti> Riddell: ok, cheers!
[14:28] <pitti> Riddell: nice that the branch ownership is set so that core-devs can commit
[14:42] <cjwatson> jdstrand: yes, it needs me to get round to merging from debian-policy really
[14:43] <jdstrand> cjwatson: ok. I noticed that 5.6.21 was different which prompted me to check
[14:46] <cjwatson> jibel: hm, are you sure?  It spends 40 minutes (between 20:14:33 and 20:54:44) apparently at least trying to upgrade a lot of stuff, although I agree that there's no hint of it in apt-term.log
[14:47] <cjwatson> jibel: but I wonder if this is just a logging bug ...
[14:48] <cjwatson> jibel: it's a shame we don't save dpkg.log
[14:50] <tedg> I have something I want to express in my packaging that I'm not sure how to do: This module isn't required, but if it is installed I need it to be a version greater than X.
[14:50] <tedg> Is there a way to do that?
[14:51] <cjwatson> tedg: Breaks: packagename (<< X)
[14:52] <jibel> cjwatson, main.log says packages are upgraded but apt-term only show removals. and after the upgrade the new kernel is not installed.
[14:52] <jibel> cjwatson, I'll add dpkg.log
[14:52] <tedg> cjwatson, Ah, okay.  I thought that meant "I break them" but that can also mean "I break if" ... cool, thanks!
[14:52] <cjwatson> jibel: mm, the kernel might be a special case, I wonder about something simple listed in the toupgrade list
[14:54] <cjwatson> tedg: well, that's the prose description in policy, but the formal semantics are "may not be unpacked while package (<< X) is configured"
[14:55] <tedg> cjwatson, Thanks again, that makes it much more clear.
[15:09] <mvo> pitti, jibel: yet another call, but I have a look now at the upgrade log
[15:14] <barry> cjwatson: hi
[15:14] <mvo> jibel, pitti: the apt resolver log for this is 245mb big, that is in itself pretty scary
[15:45] <lifeless> bug 915253
[16:00] <mvo> cjwatson: I put a first stab of the backport work to lp:~mvo/apt/oneiric-dpkgpm-backport
[16:05] <mvo> cjwatson: I will need to carefully go over that, but I think its good, it does not include your algorithm.cc fixes yet, but that should be straightforward
[16:06] <cjwatson> I put the algorithm.cc fixes in oneiric-proposed already
[16:10] <mvo> awsome, thanks a bunch
[16:27] <slangasek> pitti: no, openssl098 is here specifically *for* ia32-libs-multiarch
[16:27] <pitti> slangasek: ack; cjwatson already explained
[16:27] <slangasek> ok :)
[16:27] <pitti> slangasek: I was a little worried of it being a security burden, but seems we need to keep it
[16:27] <pitti> *shrug* universe
[16:43] <jibel> pitti, do you know why bug 882030 is in the list of pending SRUs? this is a security update.
[16:44] <jdstrand> jibel: I can answer that-- it is a security update, but mdeslaur wanted wider testing
[16:44] <jdstrand> we do that from time to time
[16:45] <lifeless> pitti: around still ?
[16:46] <pitti> lifeless: yes, for another 10 mins
[16:46] <lifeless> pitti: cool. Is there a separate library for backtrace/core signature generation? If not, how would you feel about having one? I want to make a clean interface for generating signatures, for reuse/plugability.
[16:47] <pitti> lifeless: it's in python-apport; does it need to be "more" separate?
[16:47] <lifeless> pitti: with a medium term goal of being able to have a webservice that takes an oops dict | apport dict and returns a signature
[16:47] <pitti> it doesn't do anything by itself, so it should be quite harmless to install
[16:48] <lifeless> pitti: yeah, it needs to be abstract - I don't want to be changing python-apport to change the logic for signature generation in launchpad, or SSO, or <...>
[16:48] <pitti> and it has the full API
[16:48] <lifeless> I'll have a refresher look at the python-apport code
[16:52] <mdeslaur> jibel, jdstrand, pitti: sorry, I'll update the bug to make it clear it's not an SRU
[16:55] <jibel> jdstrand, mdeslaur , ta
[17:03] <SpamapS> Wow.. RPM still doesn't have Requires: x | y
[17:07] <lifeless> SpamapS: and you are surprised ? :P
[17:08] <lifeless> ev: hey there
[17:08] <ev> lifeless: hiya!
[17:08] <lifeless> ev: we should have another touch-base I think; I landed your patch, but I'm sure there is more :)
[17:08] <ev> absolutely
[17:08] <ev> when works for you?
[17:09] <lifeless> is your google calendar reasonably accurate? I will poke at it..
[17:10] <ev> lifeless: reasonably so
[17:15] <SpamapS> lifeless: I keep a CentOS box around just to keep an eye on what the other people are doing..
[17:16] <SpamapS> lifeless: I just finished packaging up byobu 5.7 for it as an exercise in curiosity. Can't say Requires: screen | tmux .. have to have a virtual provides on both of them.
[17:16] <SpamapS> amazing
[17:23] <kirkland> SpamapS: curious, I thought byobu was in the CentOS repos?
[17:23] <kirkland> SpamapS: just not a new enough version?
[17:24] <lifeless> SpamapS: different mindset for solving the problems
[17:25] <lifeless> tedg: lennart?
[17:26] <SpamapS> kirkland: yeah, its 4.something
[17:26] <SpamapS> kirkland: and it wasn't in my yum automatically with CentOS 6.2
[17:27] <SpamapS> kirkland: its in Fedora for sure, but doesn't seem to have found its way into EPEL 6
[17:27] <SpamapS> kirkland: I'll submit the 5.7 packaging updates I did to Fedora if I find some time next weekend. :)
[17:28] <SpamapS> kirkland: btw, Ctrl-A A doesn't send Ctrl-A in tmux mode in this one for some reason (works fine on the Ubuntu version)
[17:33]  * micahg wonders where doko is
[17:34] <Sweetshark> micahg: lost on the way back from FOSDEM?
[17:37] <kirkland> SpamapS: ah, interesting;  okay, cool, thanks for the update
[17:37] <micahg> Sweetshark: could be
[17:37] <kirkland> SpamapS: btw, I stumbled on your juju byobu-classroom multi branch
[17:38] <kirkland> SpamapS: I didn't look closely at it, but what's the goal?
[17:40] <tedg> lifeless, Heh, no GSettings is my issue right now.  But that's a good one too.
[17:42] <SpamapS> kirkland: infinite scalability for a single ajaxterm session :)
[17:42] <kirkland> SpamapS: oh?  yeah, I found ajaxterm kinda sucky, in reality :-(
[17:42] <kirkland> SpamapS: is it working well?
[17:42] <SpamapS> kirkland: its just heavy on CPU because it has a high polling interval.. can't get around that on the web
[17:42] <SpamapS> kirkland: I had it working in PoC .. very simple really
[17:43] <kirkland> SpamapS: neat
[17:43] <SpamapS> kirkland: just ssh's to the "main" node instead of locally
[17:43] <kirkland> SpamapS: I used a cc2_8xlarge for my dev week session last week :-)
[17:43] <kirkland> SpamapS: 32x cpus :-)
[17:43] <SpamapS> kirkland: yeah thats the simple choice. I want to see if we can do a big class on 8 m1.smalls
[17:44] <kirkland> SpamapS: neat
[17:44] <SpamapS> kirkland: have to setup haproxy to do session persistence too.. but thats fairly easy
[17:47] <m4n1sh> mvo: there?
[17:48] <kirkland> SpamapS: neat, really glad to see you thinking about this
[18:08] <micahg> mvo: are you open to using dh_autoreconf in synaptic?
[18:11] <mvo> micahg: absolutely
[18:11] <mvo> micahg: let me quickly check if that isn't in trunk already
[18:12] <mvo> micahg: (lp:synaptic)
[18:12] <micahg> ok, because it FTBFS in precise
[18:12] <mvo> micahg: aha, ok. I will upload a new version to debian that we can sync than
[18:12] <micahg> mvo: ok, do you need a patch or do you have it already or not need it?
[18:13] <mvo> micahg: in trunk its using dh-autoreconf already, I did that last weekend
[18:13] <micahg> cool, thanks
[18:14] <mvo> micahg: thank you for raising it, slipped my attention :/
[18:21] <bdmurray> pitti: What do you think about having the retracer not remove dependencies.txt?
[18:28] <mvo> micahg: I uploaded to experimental now that should hopefully fix the issue (once its there and be be synced)
[18:28] <micahg> mvo: be be synced?  did you want me to do that?
[18:29] <mvo> micahg: well, I can do it too, no problem
[18:29] <micahg> ok, thanks, was just wondering if I need to do anything here :)
[18:30] <mvo> micahg: :) all good, I made a note to sync it when I get up tomorrow morning
[18:30] <micahg> mvo: thank you :)
[18:36] <tyhicks> seb128: Hi - did the automake distdir.test fail on the buildds without eCryptfs?
[18:36] <tyhicks> seb128: or does it only fail inside of eCryptfs mounts?
[18:37] <seb128> tyhicks: hi
[18:37] <seb128> tyhicks: the buildd fail on another test later on, I hit that one when trying to debug the issue locally
[18:37] <seb128> tyhicks: the same test works fine on the buildd on in a directory out of ecryptfs there
[18:38] <tyhicks> seb128: Ok, that's all I needed to know
[18:38] <tyhicks> seb128: I'm trying to get it triaged
[18:38] <tyhicks> seb128: thanks!
[18:38] <seb128> tyhicks: thank you for looking to the issue!
[18:38] <tyhicks> np
[19:14] <micahg> stgraber: should ltsp-client migrate to using fonts-nanum instead of ttf-unfonts-core?
[19:15] <stgraber> micahg: probably
[19:15] <micahg> want a bug?
[19:15] <micahg> or an upload :)
[19:16] <stgraber> micahg: nope, added to my todo, I'm doing PPA builds of the new LTSP anyway, so will just include the change in there
[19:16] <micahg> thanks
[19:32] <SpamapS> slangasek: So, I was thinking I'd add a 'nowait' class to /etc/network/interfaces which is used to subtract interfaces from the ones waited on. Thoughts?
[19:32] <SpamapS> stgraber: ^^ you too
[19:33] <SpamapS> slangasek: there seem to be a number of users who are willing to RTFM and figure out how to do what used to be easy, which is, have interfaces brought up at boot time that are not waited for.
[19:33] <slangasek> SpamapS: how is that different from the existing 'hotplug' class except in name?
[19:33] <SpamapS> oh there is already one like that?
[19:33] <slangasek> yes
[19:33] <slangasek> as for "what used to be easy" - it was only ever easy because of bugs, AFAICS
[19:34] <SpamapS> hotplug isn't mentioned in /etc/init/network-interface.conf or /etc/init/networking.conf ...
[19:34] <slangasek> SpamapS: yes, but it's mentioned at the top of interfaces(5) as an example, and it's a class that Debian has historically implemented - if we need to reintroduce it, we should use the same name
[19:35] <SpamapS> slangasek: seems like a good idea.. though its kind of hard to resolve, logically, the difference between 'auto' and 'hotplug' in my head.
[19:35] <slangasek> yes :)
[19:36] <slangasek> y'know, I'd really like it if /etc/init/networking's ifup -a were going away this cycle
[19:36] <infinity> You could always alias nowait to hotplug, just to the lulz. :P
[19:36] <infinity> s/to the/for the/
[19:36] <SpamapS> slangasek: we all would :)
[19:37] <slangasek> infinity: how can you alias ifupdown "allow" classes?
[19:37] <SpamapS> slangasek: at this point, what network interface appears w/o a net-device-added event ?
[19:37] <infinity> slangasek: I meant in the code.  As in, make them mean the same thing.
[19:37] <slangasek> infinity: yuck :P
[19:37] <infinity> slangasek: ;)
[19:38] <slangasek> SpamapS: well, if stgraber caught all the bugs, /etc/init/networking.conf is at best a redundant no-op now, and at worst tries to bring up interfaces before they're ready :)
[19:38] <slangasek> stgraber: ^^ have you tried pulling /etc/init/networking.conf off your test systems to confirm that it's no longer needed?
[19:39] <stgraber> slangasek: well, there are interfaces that will never be brought up by events
[19:39] <slangasek> still?
[19:39] <stgraber> tunnel interfaces, bridges with no physical interface in them, loopback device in containers, ...
[19:39] <slangasek> ah
[19:39]  * slangasek shakes his fist
[19:39] <stgraber> anything that's not linked to a physical device won't be brought up by the udev magic
[19:39] <slangasek> yep
[19:39] <infinity> I'll note that I have several such interfaces on my machine. :P
[19:39] <slangasek> which means, unfortunately, that /etc/init/networking.conf continues to risk bringing devices up out of order
[19:39] <infinity> Please no break.
[19:40] <SpamapS> slangasek: perhaps we should instrument this... if we have ifup -a log every interface that it thinks should be up, and have net-device-added events recorded.. we could have development-minded folks feed that data back to us and we'd get a picture of what is still missing net-device-added events
[19:40] <stgraber> well, I hope I've added enough "please wait for a minute" code in the pre-up scripts to prevent much of the damage that ifup -a would cause but yeah, it's still a risk
[19:40] <infinity> SpamapS: Some devices just plain can't ever have those events.
[19:41] <SpamapS> Couldn't we, in theory, fire net-device-added events for soft-controlled interfaces?
[19:41] <slangasek> why would we do that?
[19:41] <slangasek> that's unnecessary indirection
[19:41] <infinity> SpamapS: Chicken and egg, surely, since you want that event to bring up an if...
[19:41] <SpamapS> Probably
[19:41] <slangasek> synthesizing an event for your configured soft interfaces just so you can bring up those interfaces
[19:42] <infinity> We could extend interfaces(5) to allow defining triggering events.
[19:42] <infinity> (ie: bring up tun0 if eth0 up)
[19:42] <SpamapS> so perhaps what would be better would be an enhancement to ifup to only bring up software interfaces .. ifup -a --soft-only
[19:42] <slangasek> I would like it if networking.conf were explicitly *only* used for known soft interfaces... but that again would require another class
[19:42] <slangasek> and would then require admins to migrate to its use
[19:42] <slangasek> so this just dropped several notches on my priority list
[19:43] <SpamapS> slangasek: unless ifupdown could detect whether or not an interface is hardware or software... much like mountall decides whether or not a filesystem is local or remote
[19:43] <slangasek> it can't and shouldn't
[19:44] <slangasek> making ifupdown introspect bridge devices to decide whether they have physical interfaces or not would just be wrong
[19:45]  * SpamapS ponders
[19:49]  * infinity curses at rhythmbox-ubuntuone's uninstallability.
[19:52] <micahg> hmm, that should've have been allowed in the archive yet without gir1.2-ubuntuont-3.0, I wonder who let that in :P
[19:52] <micahg> s/should've/shouldn've/
[19:52] <micahg> gah, can't type today
[19:53] <micahg> in any event, dobey should fix ^^
[19:53] <infinity> micahg: I think it's just a typo/thinko?
[19:54] <infinity> micahg: The gir package was renamed to ubuntuoneui to match the library.
[19:54] <micahg> yeah
[19:54] <micahg> looks like it
[19:54] <apregier> I have a question about dpkg.  I am looking for a way to share a list of executable files between rules/postinst/prerm.
[19:56] <dobey> doh
[19:56] <dobey> micahg, infinity: is there a bug # filed?
[19:56] <infinity> dobey: I just noticed it right now while doing livefs builds, so no.
[19:57]  * SpamapS wonders if he has somehow failed his Plus1 maintenance duties by not noticing this earlier
[19:57] <infinity> SpamapS: Yes. :P
[19:57] <dobey> infinity: ok
[19:57] <infinity> SpamapS: It's been broken for days, I assume.
[19:57] <SpamapS> I was searching for the list of tasks this morning.. and got distracted. :p
[19:57] <micahg> nah, was just uploaded
[19:57] <infinity> SpamapS: (At least, based on when these uploads were made)
[19:57] <SpamapS> Yeah since Friday
[19:57] <SpamapS> oh, changelog says Friday
[19:57] <infinity> Build logs say Friday too.
[19:57] <dobey> pitti approved it today
[19:57] <micahg> accepted 3 hours ago :)
[19:57] <infinity> The libubuntuone change, that is.
[19:58] <micahg> oh, yeah, that was last week :)
[19:58] <infinity> I guess it's rhtyhmbox-ubuntuone that's broken, though,.
[19:58] <infinity> So, okay.  3 hours.
[19:58] <infinity> Grr.
[19:58] <dobey> yes; anyway, i'm fixing it right now
[19:58] <infinity> I missed my window for a hassle-free live build. ;)
[19:58] <dobey> just wanted to make sure if there was a bug # i need to put in changelog
[19:59] <SpamapS> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[19:59] <SpamapS> Listed indeed.. :-P
[20:00]  * micahg wanted to discuss the icedtea-web one with doko
[20:02] <SpamapS> hm
[20:02] <SpamapS> its working fine for me
[20:03] <SpamapS> I can install icedtea-6-plugin .. it removes icedtea-plugin as I'd expect it to
[20:03] <micahg> SpamapS: it shouldn't do that as icedtea-plugin is a transitional package and it makes upgrades more complicated
[20:04] <rbasak> Can a package be in main in some architectures but universe in others?
[20:05] <micahg> rbasak: why would you want to do such a thing?
[20:05] <SpamapS> micahg: so perhaps it should just not have the Conflicts ?
[20:05] <micahg> SpamapS: should be a breaks/replaces for moved files instead of conflicts/replaces, but I wanted to check with doko if he did that on purpose for some reason
[20:06] <infinity> rbasak: Yes, but we don't because it gets confusing fast.
[20:07] <SpamapS> micahg: yeah, Conflicts+Replaces seems like an odd combo
[20:07] <rbasak> I think that u-boot-linaro-omap4-panda-splusb should be available on x86. But that would involve build-depending on gcc-4.5-arm-linux-gnueabihf, which is in universe.
[20:09] <slangasek> rbasak: any package whose source is in main must have its build dependencies in main, for all archs.
[20:09] <slangasek> why do you need this available on x86?
[20:09] <infinity> rbasak: It builds out of u-boot-linaro sources.  You're asking for the impossible.
[20:09] <rbasak> I should be able to usb boot a pandaboard from an x86 machine
[20:10] <infinity> rbasak: But we have a long-standing history of people wanting different-arch bootloaders, and the answer is always "download it and unpack it".
[20:10] <infinity> (Except in the case of palo, and you don't want to know what was done there)
[20:10] <infinity> (It was very, very, very wrong)
[20:10] <slangasek> infinity: wronger than what was done with aboot? :)
[20:10] <soren> stgraber, kees, cjwatson, sabdfl, stgraber, mdz: Friendly reminder: TB meeting in 50 minutes.
[20:10] <rbasak> This involves the u-boot (arm) blob being on an x86 machine. Currently I'd have to apt-get install it on a panda and copy it over, which seems to go against the whole concept of packaging it.
[20:10] <rbasak> thanks infinity
[20:10] <dobey> infinity, micahg: fix uploaded. sorry about that.
[20:10] <rbasak> I guess that's my answer
[20:11] <stgraber> soren: thanks
[20:11] <infinity> slangasek: It builds it in the clean target if arch=hppa, then includes the binary in the source package, and the build then makes an arch:all deb.
[20:11] <soren> cjwatson: I did see your apologies, but they didn't sound very definitive, hence the reminder anyway.
[20:11] <infinity> slangasek: Can it get worse?
[20:11] <micahg> dobey: thanks for the quick action
[20:11] <slangasek> infinity: ah - yes, that's worse than aboot. ;)
[20:12] <slangasek> rbasak: and why do you want only the uboot blob on the x86 machine?  Don't you want an entire bootable system on the x86 machine?
[20:13] <slangasek> and at that point, I think it's clear that "installing the package on the x86 host" is the wrong model
[20:13] <rbasak> slangasek: I just want to set off a netboot.
[20:13] <slangasek> hmm
[20:14] <rbasak> I'd like to package this because then setting up a machine that can bootstrap pandas would be very easy
[20:14] <rbasak> (as easy as cobbler makes this for traditional machines)
[20:14] <slangasek> I don't think that's something we want to support
[20:15] <SpamapS> slangasek: PXE booting lots of ARM servers from x86 servers? That seems like exactly what we want to support.... or am I over simplifying the task?
[20:15] <slangasek> build-depending on a cross-compiler in order to build binary packages of one arch containing binaries of another arch - fail
[20:15] <slangasek> SpamapS: sure we want to support that.  We don't want to support what rbasak is proposing with the build-dependencies
[20:16]  * SpamapS read "bootstrap" as PXE boot, and now realizes his error.
[20:16] <slangasek> there are three options here you could reasonably use
[20:16] <slangasek> - grab the arm package and manually unpack it
[20:16] <infinity> rbasak: It's not really rocket science to grab the latest _armhf.deb from a mirror and unpack and extract the binary you need, is it?
[20:16] <infinity> rbasak: This is what, for instance, debian-cd does to grab bootloaders to jam onto CDs.
[20:16] <rbasak> infinity: no, but it is really ugly to automate it
[20:16] <micahg> ports has mirrors?
[20:17] <infinity> micahg: It has one. :P
[20:17] <rbasak> infinity: it does not work when you consider configuration management
[20:17] <slangasek> - make the uboot package binary blob bits arch: all so that they can be installed anywhere (except that this again requires the cross-compiler build-dep since arch: all packages are always built on i386 -ohwell)
[20:17] <infinity> micahg: (In that ports != ftpmaster)
[20:17] <slangasek> - use multiarch to cross-install the package
[20:17] <SpamapS> I don't think that would be too ugly to automate. We can have armhf as a foreign arch in apt and use apt-get download directly, can't we?
[20:17] <infinity> slangasek: Or it requires fixing the longstanding wishlist to have arch:all affinity have source package granularity.
[20:18] <slangasek> infinity: or that, yes
[20:18] <infinity> slangasek: (In LP)
[20:18] <infinity> It's not actually hard to do.  It's just another set of round tuits someone needs to find.
[20:18] <micahg> infinity beat me to it :)
[20:18] <slangasek> added debian/patches/CVS/Entries
[20:18] <slangasek> hate
[20:19] <micahg> that's at least 2 reasons to cry
[20:23] <slangasek> barry: hum, just had a weird experience doing a 'bzr pull' on a Debian UDD branch...
[20:23] <slangasek> Unapplying quilt patches to prevent spurious conflicts
[20:31] <dobey> infinity, micahg: i also just proposed https://code.launchpad.net/~dobey/ubuntu/precise/banshee/drop-u1ms/+merge/91713 which drops the extension from the banshee builds, so it won't FTBFS in the future.
[20:39] <barry> slangasek: what package?
[20:40] <slangasek> barry: nfs-utils debian testing branch... I expect it's generally reproducible with any bzr pull that pulls new revisions however, based on the behavior seen here
[20:40] <slangasek> and unapplying seems like it should only be done on a merge, not a pull?
[20:40] <barry> slangasek: agreed
[20:41] <barry> slangasek: so you branched, and then later pulled, and the latter tried to unapply the patches?
[20:42] <barry> slangasek: definitely file a bug on the udd project
[20:43] <slangasek> yep, that's what happened
[20:44] <barry> verified that if nothing needs to be pulled, the patches are not unapplied
[20:44] <slangasek> barry: bug #927878
[20:45] <barry> ack
[20:45] <micahg> dobey: thanks, I'd let the cli-team take a look at that (laney, hyperair)
[20:48] <sabdfl> soren, ack, thanks
[20:53] <pitti> bdmurray: fine for me; I just thought they wouldn't be that useful
[20:54] <pitti> bdmurray: I'll merge your branch
[20:55] <pitti> infinity: why does it break live-build? I didn't upload u-meta with the seed change yet
[20:55] <infinity> pitti: Because rhythmbox-ubuntuone had a dep on a nonexistant package.
[20:55] <infinity> pitti: All fixed now.
[20:55] <pitti> fair enough, but what pulls in rb-u1?
[20:56] <pitti> AFAIK I merely seeded it?
[20:56] <infinity> No idea.  Didn't check.
[20:56] <pitti> ok, thanks
[20:56] <pitti> sorry, didn't spot the missing dep during binNEW
[20:56] <infinity> (Sorry, in meetings, a bit terse)
[20:56]  * pitti too
[20:56] <bdmurray> pitti: thanks
[21:00] <soren> pitti: tb meeting
[22:01] <micahg> Bug #927917  looks bad
[22:03] <bkerensa> slangasek: Did you by any chance take care of the multiarch patches that blkperl messed up on? He asked me to transition the packages he did because apparently they were not transitioned properly  #651008 #651009 #651010 on BTS
[22:03] <bkerensa> I dont wanna re-do them if you or someone else already did
[22:48] <slangasek> bkerensa: all the libraries that were on our list at the localjam have been followed through on by now :)
[23:22] <bkerensa> slangasek: Ok thanks :D
[23:54] <bdmurray> slangasek: bug 911436 will appear in a lot of packages correct?
[23:56] <slangasek> bdmurray: it can happen during the upgrade of any package; or are you asking if it affects other packages besides apt?
[23:57] <bdmurray> bug 927317 has a similar stacktrace but is about cups and lpstat
[23:59] <slangasek> right - it can affect anything that uses libp11-kit0... which is anything that uses gnutls, basically
[23:59] <slangasek> so yes, rather a lot of packages may be affected