[00:00] <bdmurray> okay, I was / am considering a bug pattern
[00:21] <bdmurray> slangasek: I noticed there is no update-manager apport hook in Lucid and thought the best way to get it in there would be an SRU of update-manager.  However, I'm confused about how far behind the lucid bzr branch for update-manager is.
[00:22] <bdmurray> ah, its me
[00:22] <slangasek> mmk
[00:49] <psusi> wait... when a package is synced from debian, it's just the source right, the binaries are still rebuilt for ubuntu right?
[00:50] <micahg> psusi: correct
[01:36] <YokoZar> slangasek: What do you think of apt automatically transitioning users of amd64 packages to i386 packages on dist-upgrade if 1) the i386 is higher version, and 2) the currently used architecture is not available in any pool ?
[01:37] <YokoZar> I'm thinking of issues where we, say, delete zsnes:amd64 from the archive and the amd64 lucid user needs to be migrated to zsnes:i386.
[01:40]  * micahg debates taking an axe to zsnes
[02:02] <slangasek> YokoZar: I reserve judgement; we'd have to have a good long think about whether this is always the right thing to do
[02:04] <slangasek> YokoZar: btw, are you planning to complete the work item from https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default that you accepted at UDS? (announce intentions to move to 64-bit by default)
[02:06] <infinity> YokoZar: That would fail pretty spectacularly if Packages-amd64.gz got corrupted in transit or something, leaving you with "no amd64 packages in the pool".
[02:06] <YokoZar> slangasek: infinity: Yeah I suspect we'll run into questions about manually installed debs and what if we can't figure out the "available pool" properly and so on
[02:07] <YokoZar> slangasek: ~ work items, thank you for reminding me.  I was trying to check on the work items I might have missed and for some reason I wasn't coming up in the work item tracker
[02:07] <infinity> YokoZar: I think the saner (for some value of "sane") option for now is to take it case-by-case and provide cross-arch transitional packages.
[02:08] <slangasek> YokoZar: tracker> ah, that'll be my fault for not getting the blueprint shoved along to "approved" state
[02:08] <slangasek> infinity: but you can't have a transitional package depending of a foreign package of a *specific* architecture presently, so each one of those would require a package name change
[02:08] <slangasek> which isn't pleasant
[02:08] <YokoZar> infinity: but we can't have specific arch dependencies, so the transitional package would have to be a different name than the existing package....
[02:08] <infinity> YokoZar: Not that I find the cross-arch deps particularly elegant, but they're much more fool-proof.  And the corner cases surrounding how dpkg and apt determine "availability" are many.
[02:09] <YokoZar> The uglier solution is just a big manual hard-coded list in update-manager :/
[02:09] <infinity> YokoZar: Well, the transitional package would be the old name, and it would depend on zsnes-i386, I guess?
[02:09] <YokoZar> (which doesn't work for dist-upgrade, which is why I suggested modifying the apt resolver)
[02:09] <YokoZar> infinity: right, and then we'd have to rename zsnes to zsnes-i386 :/
[02:10] <infinity> Yup.
[02:10] <infinity> I did note that it fails the elegance test.
[02:10] <infinity> But it's at least easy to spot-check for correctness.
[02:10] <YokoZar> infinity: you can look at the new wine1.4 package for a similar setup
[02:10] <infinity> The proposed apt change is immediately incorrect in several corner cases, without looking for weirder ones.
[02:10] <micahg> YokoZar: alternatively, you can fix the amd64 build so that it builds the arch specific parts if there are any
[02:11] <YokoZar> micahg: but there aren't any, zsnes is a good example because it's an i386 only package that we had a fake ia32-libs solution for in the past
[02:11] <infinity> (Out of curiosity, why would this be done to zsnes?  Does the 64-bit build not work?)
[02:11] <infinity> Oh, there isn't a 64-bit build, I see.  That seems odd, given that it's an emulator. :P
[02:11] <YokoZar> infinity: zsnes does not and will not build on amd64 ever, I think it's full of assembly code or some such.
[02:12] <infinity> Fair enough.
[02:12] <micahg> YokoZar: you can do what we did with flash, if you can get it to compile again :)
[02:12] <infinity> Still sounds like it should just be dealt with the same way flash is.
[02:12] <infinity> The same way we did flash in oneiric, that is.
[02:12] <infinity> Before we had a 64-bit one.
[02:12] <ScottK> Burn it with fire/
[02:12] <ScottK> ?
[02:13] <ScottK> Oh, that's not what you meant.
[02:13] <micahg> zsnes:amd64 depends zsnes-i386 (i386 only) which depends on zsnes:i386
[02:13] <infinity> micahg: Makes the packaging a bit more complex, since zsnes.install differs on the two arches.
[02:14] <infinity> micahg: I don't see the point in the last dependency.  Just put the binaries in zsnes-i386 and have it replace zsnes (<< pre-split-version).
[02:14] <YokoZar> micahg: yeah that would work, I suppose, but then we're left carrying two dummy packages for an indeterminate amount of time.  Especially because there's no way for zsnes:i386 to declare that it replaces and obsoletes zsnes:amd64 (and indeed apt will try to keep them in sync at the same version and complain about any change that removes empty zsnes:amd64)
[02:15] <micahg> infinity: that works too, but I hate the idea of having a zsnes-i386 package in perpetuity
[02:15] <YokoZar> infinity's solution is a bit better but leaves us with dumb names forever
[02:15] <infinity> micahg: Who cares?  Package names are often weird.
[02:15] <micahg> it's a diff from Debian
[02:15] <infinity> So, convince the Debian maintainer to do the same thing.
[02:15] <infinity> But it's not actually a large diff.
[02:15] <YokoZar> OR, we could implement specific arch relationships in control fields...
[02:16] <micahg> well, now that Debian will soon have a multiarch capable dpkg, that might be possible :)
[02:17] <YokoZar> By the way I didn't really appreciate how far ahead we were with multiarch than Debian until now.  I had been waiting for multiarch for a long time to make a proper wine64 package, and it finally got accepted today :)
[02:18] <infinity> There's a certain advantage in not having individual package maintainers, yes.
[02:18] <infinity> Downside: Lots of universe bugs go ignored.  Upside: When we want to move on something, we MOVE.
[02:25] <ScottK> infinity: Lots of Main bugs go ignored too.
[02:29] <justgord> Any ubuntu dev working groups focussed on tablets and/or wayland  ?
[05:02] <nidsub> hola, i hope there someone out there who could help me :)
[05:02] <nidsub> im sorry ,but im really new to irc
[05:02] <nidsub> should i just post my problem here?
[05:03] <nidsub> im trying to build linux kernel
[05:03] <nidsub> here is the error i get,please  point out what did i do wrong
[05:04] <nidsub> -VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ make ARCH=arm
[05:04] <nidsub> mkdir: cannot create directory `include/generated': Permission denied
[05:04] <nidsub> make[2]: *** [silentoldconfig] Error 1
[05:04] <nidsub> make[1]: *** [silentoldconfig] Error 2
[05:04] <nidsub> make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'.  Stop.
[05:04] <nidsub> nidhal@nidhal-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ sudo make ARCH=arm
[05:04] <nidsub> scripts/kconfig/conf --silentoldconfig Kconfig
[05:04] <nidsub>   CHK     include/linux/version.h
[05:04] <nidsub>   UPD     include/linux/version.h
[05:04] <nidsub>   CHK     include/generated/utsrelease.h
[05:04] <nidsub>   UPD     include/generated/utsrelease.h
[05:04] <nidsub>   Generating include/generated/mach-types.h
[05:04] <nidsub>   CC      kernel/bounds.s
[05:04] <nidsub> cc1: error: unrecognized command line option ‘-mlittle-endian’
[05:04] <nidsub> cc1: error: unrecognized command line option ‘-mno-thumb-interwork’
[05:04] <nidsub> kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch
[05:04] <nidsub> kernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch
[05:04] <nidsub> make[1]: *** [kernel/bounds.s] Error 1
[05:04] <nidsub> make: *** [prepare0] Error 2
[05:04] <nidsub> please :(
[05:05] <micahg> nidsub: first error is you didn't use a pastebin for that
[05:06] <micahg> as for the rest, is this on an arm system or are you cross compiling
[05:06] <nidsub> thank you :),yerp im trying to cross compile
[05:07] <nidsub> is on arm qemu
[05:08] <nidsub> here the detail on the step i took ..from this webpage
[05:09] <nidsub> http://wiki.xilinx.com/zynq-linux
[05:12] <micahg> well, this isn't a general support channel, #ubuntu-arm might be better suited
[05:12] <micahg> #ubuntu would be for general support, but I don't see this working out too well in there
[05:15] <nidsub> Thanks you so much for the tips
[07:10] <goddard> I'm trying to use debuilder but it doesn't seem to be creating my deb file although i get no errors
[07:32] <pitti> Good morning
[07:40] <Sweetshark> Morning everyone!
[07:44] <Sweetshark> http://twitter.com/#!/gregkh/status/166644258831478784 <- yay, gregkh -- of kernel fame -- contributing to LibreOffice ...
[10:00] <pitti> Daviey: mariadb> as it is 100% binary compatible, I think there is some good grounds for a FFE on this one
[10:00] <pitti> Daviey: my bigger concern there would be how much commercial backing mariadb has, i. e. whether there are stakeholders which we can believe are still active in 5 years
[10:01] <Daviey> pitti: need to discuss this in a bit. :)
[10:13] <seb128> - /usr/lib/debug/usr/lib/i386-linux-gnu/libsoup-2.4.so.1.5.0
[10:13] <seb128> + /usr/lib/debug/.build-id/5e/d483e11d8dbaff9929c94ad6b9b05a174c7685.debug
[10:13] <pitti> I noticed the new /usr/lib/debug/.build-id/ gibberish recently, too
[10:13] <seb128> is that something which changed in our toolchain (it's libsoup2.4-dbg new version)
[10:14] <pitti> I have no idea what changed there
[10:15] <seb128> hum, k
[10:15] <seb128> well I will assume it's not a bug on my side then ;-)
[10:17] <debfx> seb128: it's a new debhelper 9 behavior
[10:17] <seb128> debfx, ok, thanks
[10:18] <seb128>   * dh_strip: In v9, pass --compress-debug-sections to objcopy.
[10:18] <seb128> I guess
[10:18] <seb128> that source is v9
[10:18] <pitti> so this stuff is actually valid?
[10:18] <seb128> debian bug 631985
[10:18] <pitti> it seems a ridiculously bad design to put this in a hidden  directory
[10:19] <seb128> with useless names...
[12:06] <pitti> cking: FYI, I'm currently working on https://launchpad.net/fatrace
[12:06] <pitti> cking: as powertop seems to do a rather bad job at catching disk events (and even reports them wrongly, too)
[12:06] <pitti> cking: once it's ready and in the archive, I'll update https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues accordingly
[12:06] <cking> pitti, wow, this is excellent!
[12:07] <pitti> cking: fanotify is quite nice for this :)
[12:08] <pitti> cking: if you are interested in trying, it's in lp:fatrace; make && sudo ./fatrace
[12:08] <cking> yep, this is an excellent tool to track down these offending wakeups!
[12:08] <pitti> it has --time and --output options, and I'm going to add some filtering, too
[12:08] <pitti> cking: well, it's not process wakeups (that's powertop), just disk events
[12:09] <pitti> "f"ile "a"ccess trace
[12:09] <pitti> cking: if you want it to do something more (new option, etc.), please let me know
[12:12] <cking> pitti, does the -o option interfere with the results - i.e. it could write the output to disk and hence change the stats
[12:13] <pitti> cking: no, it ignores its own events
[12:13] <cking> sweet
[12:13] <pitti> cking: without -o, gnome-terminal touches a tempfile in /tmp/ with every output, and thus generates a feedback loop
[12:14] <pitti> -o avoids this, but I'm trying to add something more clever
[12:14] <cking> yep, I saw that and wonder what was happening
[12:14] <pitti> well /tmp tmpfs definitively helps
[12:14] <pitti> but we don't have that by default
[12:14] <pitti> cking: --ignore-pid could work
[12:15] <pitti> --ignore-path /tmp/ sounds a bit pointless
[12:15] <pitti> (but might make sense for other contexts)
[12:15] <pitti> by default it watches all "real" mounts
[12:15] <pitti> it could grow an option to only watch the mount of current cwd
[12:16] <cking> perhaps adding a timestamp to the output so we can figure out if events occur periodically may help
[12:16] <seb128> pitti, bug #928212 hate gzip hate
[12:17] <pitti> argh
[12:18] <pitti> cking: ah, good idea
[12:19] <cking> pitti, it does generate quite a bit of data on a busy machine - perhaps producing a summary sorted on the worse behaving process could be handy too
[12:20] <pitti> cking: it's not supposed to be the preferred frontend
[12:20] <pitti> cking: I have another WI to write a script that calls powertop, fatrace, and generate a report out of it
[12:20] <pitti> with worst offenders, sorted, etc.
[12:20] <cking> pitti, ah, I understand - good idea!
[12:21] <pitti> cking: I really don't want to do all this in plain C :)
[12:28] <cking> pitti, if we are going to use tools like powertop perhaps we need to ensure they work correctly - anecdotal evidence seems to tell me that some of the data may not be trustworthy
[12:28] <pitti> cking: yes, like the file accesses
[12:28] <pitti> wakeups seem to be quite reliable, though?
[12:28] <cking> and battery power consumption too
[12:29] <cking> wakeups work well as it does cater for a wide range - I looked at a specific case of wakeups and wrote eventstat to do the more focused monitoring for my testing
[12:31] <pitti> cking: pushed --current-mount option; might be useful for some finer-grained debugging
[12:32] <pitti> cking: I'll add timestamps and an --ignore-pid option still to avoid this gnome-terminal loop, but I think the rest of the filtering/reporting should happen with higher level tools
[12:33]  * cking nods - yep, makes sense
[12:34] <MacSlow> seb128, hey there... I think you'll be happier with https://code.launchpad.net/~macslow/notify-osd/fix.810325-2/+merge/91807 regarding the avg. color-tinting of the notification-bubbles
[12:34] <seb128> MacSlow, hey, let me have a look
[12:34] <MacSlow> seb128, it checks at runtime for the schema and key... if they are missing, it just falls back to the old behaviour/color
[12:35] <seb128> MacSlow, that sounds good
[12:35] <seb128> MacSlow, hum, launchpad gives and empty diff?
[12:35] <MacSlow> seb128, I'd be happy if you could review it
[12:35] <MacSlow> seb128, yeah... hold on a minute... I accidentally pushed to trunk instead of the correct branch *cough*
[12:36] <MacSlow> seb128, fixed/reverted it in trunk already... but needs some time to pick that up
[12:36] <seb128> MacSlow, ok
[12:43] <lamont> Processing triggers for libc-bin ...
[12:43] <lamont> ldconfig deferred processing now taking place
[12:43] <lamont> sh: 1: /usr/bin/gdbus: not found
[12:43] <lamont> neat
[13:00] <pitti> cking: ok, timestamps available now; -t is now -s
[13:02] <cking> pitti, \o/
[13:03] <jacekmigacz> how to prevent lightdm respawning Xorg session?
[13:03] <jacekmigacz> i'd like X once killed, stay killed
[13:07] <jacekmigacz> other words I'd like to kill,remove seat.
[13:12] <jacekmigacz> lightdm has SeatRemoved signal but no Remove seat method
[14:23] <pitti> cking: it's quite unbelievable how much disk activity chatter even my bash prompt uses..
[14:23] <cking> bashing the oxide off the platter..
[14:23] <pitti> well, my fault mostly, of course; it calls git, sed, and whatnot
[14:24] <cking> this is where we find most of the disk events are due to our tools
[14:25] <pitti> cking: I added an --ignore-pid option now, so gnome-terminal can be silenced
[14:25] <pitti> cking: from my POV this should be good enough for a first release; do you still see something major missing?
[14:25] <pitti> oh, I should document theh flags in the manpage
[14:26] <cking> pitti, lemme have one more look
[14:30] <cking> pitti, perhaps it should check it needs to be run with suitable root privilege rather than just failing with "fanotify_init: Operation not permitted"
[14:30] <pitti> I'm not actually sure which capability that is
[14:30] <pitti> CAP_SYS_ADMIN?
[14:31] <pitti> cking: doing that properly is a bit nontrivial, so I didn't so far
[14:31] <pitti> cking: uid==0 is not quite sufficient, I think
[14:31] <pitti> apparmor might restrict it, and other systems might allow it even to non-root processes
[14:31] <cking> ah, true
[14:34] <cking> pitti, its surprising how much unity-panel-service is doing really
[14:35] <pitti> cking: I'll rename 'M' to 'W' and 'A' to 'R'; that's a bit clearer IMHO
[14:35] <cking> pitti, heh, I can't valgrind the fanotify_* calls
[14:35] <pitti> valgrind?
[14:36] <cking> yeah, I run valgrind on all apps to see if they are leaky
[14:36] <pitti> I don't use any dynamic memory allocation
[14:36] <pitti> in small C programs I try not to, both to guard against leaks and also because it's more efficient
[14:37] <pitti> (not copying stuff around, etc.)
[14:37] <pitti> well, there's one strdup() for the --output argument
[14:37] <pitti> that could be freed, but it's only a single allocation
[14:37] <cking> ..just me being anal ;-)
[14:37] <pitti> but I like my global variables to be valid all the time
[14:37] <pitti> cking: right, appreciated :)
[14:38] <pitti> cking: so, valgrind doesn't know about fanotify?
[14:38] <cking> so, as for features and functionality it looks most excellent
[14:38] <cking> pitti, well, valgrind on my precise box didn't like the fanotify_init()
[14:40] <cking> goodness knows how that's implemented
[14:46] <pitti> cking: manpage updated as well now
[14:50] <jamespage> micahg, OK if I merge maven-repo-helper? a couple of bug fixes only...
[15:01] <cking> pitti, looks all good to me
[15:01] <pitti> Cannot initialize fanotify: Operation not permitted
[15:01] <pitti> You need to run this program as root.
[15:01] <pitti> cking: ^ slightly more friendly now
[15:02] <cking> pitti, yay
[15:02] <pitti> cking: ok, thanks; off to a 0.1, and packaging :)
[15:04] <pitti> cking: https://launchpad.net/fatrace -> gotta love how LP says that I released the 0.1 tarball 15 hours ago :)
[15:05] <cking> pitti, LP now a time machine too?
[15:09] <smoser> superm1, around ? i've some questions about dkms.
[15:23] <dholbach> if a new binary package gets added, do the existing packages get published after the new upload or do they all wait until the binary new package is processed?
[15:23] <pitti> dholbach: they all wait
[15:23] <dholbach> (I'm asking because of fcitx)
[15:23] <dholbach> ah ok
[15:24] <smoser> superm1, never mind. i think i got it sorted.
[15:24] <pitti> otherwise we'd end up with broken dependencies very often
[15:24] <dholbach> yeah, I guess
[15:24] <dholbach> stupid question, but I just wanted to be sure ;-)
[15:24] <pitti> cking: uploaded; now I need to bribe an archive admin to process it :)
[15:25] <dholbach> pitti, have you bribed yourself before? ;-)
[15:25] <pitti> I can't review my own stuff :)
[15:26]  * dholbach can totally see pitti go back and forth between "ok, how about I have some beer later after reviewing this stuff?", "yeah, beer would make the pain go away", "yeah, why not", "ok, deal" himself
[15:26] <pitti> dholbach: nice "sponsorship Friday" idea
[15:26]  * dholbach hugs pitti
[15:27]  * dholbach just dealt with a bunch of sync requests - we were up to 80+ earlier :)
[15:27]  * pitti hugs dholbach
[15:27] <dholbach> that's also why I asked about the fcitx one :)
[15:37]  * Sweetshark should lurk more, to be able to make grow the casual hugs into grouphugs ....
[15:46] <dholbach> seb128, Laney: to move forward with the glom story, I just uploaded a new goocanvasmm-2.0 package to https://launchpad.net/~dholbach/+archive/ppa - if you could take a look and just sponsor if it's good enough for you, I'd appreciate it :)
[15:47] <Laney> are these parallel installable?
[15:47] <seb128> dholbach, thanks!
[15:47] <Laney> also NICE
[15:47] <seb128> dholbach, will you do gdamm5 as well? ;-)
[15:50] <dholbach> seb128, on it
[15:50] <seb128> dholbach, you rock, you make me want to spend some time on the sponsoring queue ;-)
[15:50] <dholbach> seb128, uploading it right now
[15:51] <dholbach> there's something funny with a devhelp file
[15:51] <seb128> dholbach, I will not wait friday though, I'm concerned that too many people hitting on it together will lead to duplication ;-)
[15:51] <dholbach> but I think it's more important we get glom up and running and fix the other stuff later
[15:51] <Laney> has the sover changed? shver is still the same
[15:51] <dholbach> seb128, if you want to do a bit of sponsoring before - do it :)
[15:52] <dholbach> Laney, hm? it seems like no goocanvasmm-2.0 is available right now at all?
[15:52] <seb128> dholbach, right
[15:54] <Laney> well, indeed, but I think it probably wants to be 1.90
[15:54] <Laney> anyway I will have a proper look later
[15:54] <Laney> glom depends on this version now?
[15:54] <dholbach> yes
[15:54] <Laney> grand
[15:55] <dholbach> it's all in the openismus ppa
[15:55] <dholbach> I just had to make a few very very small changes
[15:55] <Laney> this neatly steps around jsogo
[15:55] <Laney> would anyone be interested in maintaining?
[15:56] <dholbach> seb128, and I are in discussions with the openismus people
[15:56] <dholbach> they maintain it in their ppa already
[15:56] <dholbach> and some time further down the line, it'd be nice if they could maintain the whole stack in ubuntu
[15:57]  * Laney will sponsor to Debian if they want it (and would consider DM at some point)
[16:25] <kelemengabor> mvo: hi, do you have time a slightly offtopic question? How does one submit a translation for upstream apt?
[16:26] <kelemengabor> I tried the BTS, without much success: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655238
[16:28] <mvo> kelemengabor: sure, always! the debian bts is the right place, if noone has merged it  yet I can do that
[16:29] <mvo> kelemengabor: fwiw, its in debians bzr already
[16:29] <mvo> kelemengabor: just not released or taged in the bug
[16:29] <slangasek> pitti: fatrace> very nice :)
[16:30] <mvo> kelemengabor: sorry for that, there should be anohter upload to stable I guess
[16:30] <pitti> slangasek: I have a half-written blog post about it, will finish after our meeting
[16:30] <pitti> slangasek: thanks :)
[16:30] <slangasek> pitti: as far as a tool to collect the information and report it, I think 1 minute is a little too short... for me the goal is to have the disk to wake up no more than once per 10 minutes when idle
[16:30] <pitti> slangasek: it's indeed quite surprising what enormous disk chatter we have during a normal session
[16:30] <pitti> slangasek: 10 mins sounds fine
[16:30] <slangasek> well, it doesn't surprise me :/
[16:30] <slangasek> because we know we have a longstanding bug about parking cycles destroying disks
[16:31] <kelemengabor> mvo: oh, that's nice. I should read bzr logs more :). Thanks!
[16:33] <mvo> kelemengabor: well, someone should have simply told you :) so no worries
[16:37] <pitti> directhex: hey! do you know thhe status of the banshee gtk3 port?
[16:38] <directhex> pitti, i saw it demonstrated at fosdem this weekend. i'm not sure what release blockers there are, if any
[16:40] <tkamppeter> pitti, hi
[16:41] <tkamppeter> pitti, I will push CUPS 1.5.2 in some minutes, can you upload it then? Forgot to update the debian/patches/series file and so the new patches are not applied.
[16:43] <pitti> directhex: ah, thanks; nice to hear that there's good progress
[16:54] <micahg> jamespage: sure, wasn't sure if we needed it
[16:56] <tjaalton> slomo: more quiet here, so http://paste.ubuntu.com/832840/
[16:57] <tkamppeter> pitti, I have pushed up CUPS 1.5.2-2 now, can you upload it to Debian and Ubuntu? Thanks.
[16:57] <pitti> tkamppeter: ok, thanks
[17:03] <bdmurray> pitti: with regards to bug 856975 that traceback shows up in almost all ubiquity syslog files
[17:03] <pitti> it seems dbus is not running in that environment
[17:04] <pitti> I think we need to fix that
[17:06] <slangasek> pitti: seems more likely to me that this would be some sort of /run transition issue... not sure how we would've gotten that far with dbus not being started
[17:06] <pitti> anyway, I'll have a closer look in the live session (and ubiquity-only)
[17:06] <pitti> put on my todo list
[17:07] <bdmurray> thanks
[17:08] <cr3> hi folks, if I have a project mostly in Python with some C++, is it reasonable to have setup.py call make? or, should I use a Makefile instead that calls setup.py?
[17:11] <slangasek> cr3: no autoconf?
[17:11] <pitti> tkamppeter: uploaded
[17:12] <slangasek> cr3: I'm not sure one way is better than the other, anyway; both will have rough spots
[17:14] <cr3> slangasek: no autoconf, there's very little C++ and it's actually Qt code so the process is qmake + make in a small subdirectory
[17:14]  * slangasek nods
[17:18] <tkamppeter> pitti, thanks.
[17:24] <jamespage> micahg, ta
[17:52] <micahg> do I have to worry about an upgrade from a non-release version of a package in oneiric to precise?  I'm looking at ca-certificates and the only possible thing left is the conflicts on the pre-release ca-certificates-java
[18:29] <SpamapS> @pilot in
[18:35] <slangasek> micahg: I wouldn't keep transitional code from release-1-ε, no
[18:36] <micahg> slangasek: well, the rest of the code said drop after oneiric, that's part of why I'm asking
[18:36] <slangasek> not if there's a question of being in sync or something - if it's cheap to keep then meh, but in general users shouldn't expect things to work if they don't at least upgrade to the release first
[18:36] <micahg> the other part is, do we assume upgrade to release packages before upgrading to the next release
[18:36] <slangasek> *I* certainly assume that :)
[18:36] <micahg> ok, yeah, it's the only diff
[18:39] <micahg> mvo: BTW, synaptic still FTBFS in Ubuntu
[19:38] <mvo> micahg: meh, thanks! let me look
[19:39] <micahg> mvo: it seems weird, the patch applied in Debian, but not Ubunut
[19:39] <micahg> *Ubuntu
[19:40] <mvo> micahg: I also wonder why I did not get the ftbfs mail :/
[19:43] <mvo> micahg: at least I can reproduce it here, I work on it now
[19:59] <doko> micahg, did you already care about all gnat related packages?
[20:12] <SpamapS> smoser: just reviewed your patch for bug 915215
[20:13] <TiMiDo> man this sucks,
[20:15] <slangasek> SpamapS, smoser: eew?  this is rc.local, it's *supposed* to be edited by the admin
[20:15] <slangasek> packages should *never* be adding anything to it
[20:15] <SpamapS> slangasek: welcome to the world of automation
[20:16] <slangasek> why would you use *that* interface for automating anything?
[20:16] <SpamapS> slangasek: if not rc.local.d , something with a .d makes sense so users can comfortably put things there without worrying about conflicting w/ system level startup scripts.
[20:19] <SpamapS> slangasek: people use rc.local all the time in automation because it is reliable and simple to implement.
[20:19] <slangasek> SpamapS: so why not just *clobber* /etc/rc.local?
[20:19] <slangasek> it's rc.local
[20:20] <slangasek> why worry about its default contents at all?
[20:21] <slangasek> also, why is using /etc/init.d + /etc/rcN.d, or /etc/init, a practical concern?  dpkg won't overwrite any local files in these directories on package install without prompting, so even if someone does mistakenly install a package that overlaps something local, it shouldn't blow up?
[20:21] <jtaylor> doko: do you have an opinion on getting numpy 1.6 into precise before the feature freeze?
[20:22] <jtaylor> it is backward compatible with 1.5, and only 18 packages that need rebuild
[20:22] <jtaylor> debian is going to transition very soon too but probably after feature freeze
[20:22] <doko> jtaylor, no. do you want to prepare packages?
[20:23] <jtaylor> doko: I'm currently just looking for helpers and getting an overview, if people approve I'll prepare packages
[20:23] <slangasek> hallyn: bug #928432 says spice should only be enabled on 64-bit builds; can you confirm?
[20:24] <doko> jtaylor, I don't see a reason not to do that. so if you have packages for numpy, scipy, and maybe others, let me know
[20:27] <jtaylor> doko: great, I'll let you know on the progress
[20:29] <smoser> SpamapS, thank you. i dont mind it being upstart.
[20:29] <smoser> i actually went looking for you one day to read the suggested upstart script htat i put int he bug
[20:29] <micahg> doko: well, I think I've got the ada related failures fixed/sync'd, gnat is still and issue on armhf, but I was going to look at the diffs with Debian at some point
[20:29] <SpamapS> slangasek: clobbering rc.local makes sense if you have one thing influencing rc.local, but not if you have multiple things that you want to start late in the boot...
[20:29] <smoser> i backed away as it was just more intrusive.
[20:30] <smoser> i agree with SpamapS .
[20:30] <SpamapS> slangasek: and its still simpler than using /etc/init.d + update-rc.d or upstart (though upstart *does* help a lot)
[20:30] <slangasek> SpamapS: rc.local is not defined as "late in boot", it's defined as "last thing run via sysvinit" which is no longer the same thing ;)
[20:30] <hallyn> slangasek:  hm,  http://spice-space.org/faq.html
[20:30] <hallyn>  says only server isnt supported on 32bit, client is
[20:30] <smoser> slangasek, well, rc.local is back to being "relatively" late in boot
[20:31] <smoser> wel...
[20:31] <hallyn> slangasek: d'oh, so yeah
[20:31] <smoser> err.. anyway i think that is a separate issue entirely.
[20:31] <SpamapS> but the 'start on stopped rc RUNLEVEL=[2345]' is still a lot more obscure than 'echo /usr/local/sbin/dbdaemon' > /etc/rc.local.d/dbdaemon && chmod +x /etc/rc.local.d/dbdaemon
[20:31] <micahg> doko: also, wanted to ask you about the icedtea-plugin situation, it seems that there should be a breaks/replaces instead of a conflict/replaces there, just wanted to know if you did that on purpose or not
[20:32] <SpamapS> slangasek: most people define it as late in boot.. evidence that we have not documented its new place in the boot very effectively. :-/
[20:32] <smoser> well, if its not "late in boot", then really, thats a bug.
[20:32] <smoser> we re-defined it
[20:33] <smoser> (yes, i realize we did, but currenlty its *so* much better than it was in 10.04)
[20:33] <doko> micahg, there are no diffs, just a bootstrap is needed
[20:35] <micahg> doko: ah, Debian has a patch in 4.4 that lets it bootstrap from 4.6 which is built now
[20:35] <smoser> so anyway, i only proposed it and didn't upload it because i wanted to give people like slangasek the opportunity to say "yuck, no way"
[20:35] <smoser> i only decided to try it because i came across a need/desicre to run something late in boot without screwing up someone's changs to rc.local.
[20:36] <doko> micahg, neither 4.4 nor 4.6 are built on armhf
[20:36] <micahg>       gnat | 4.6ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc
[20:36] <micahg> ah, it's empty :)
[20:36] <micahg> doko: ok, I don't know how to bootstrap that offhand
[20:40] <broder> SpamapS, smoser: i always thought people liked rc.local because it was cross-distro. that wouldn't be the case with rc.local.d, no? it'd be ubuntu-specific? or are other distros picking it up too?
[20:40] <smoser> broder, no. unless by coincidence
[20:43] <SpamapS> broder: I'm sure thats one reason people use it, because it is ubiquitous, elminating the need for chkconfig users to learn update-rc.d
[21:03] <smoser> SpamapS, wel... commented on post there.
[21:04] <slangasek> smoser: udev redefined it; we just made that redefinition manifest :)
[21:04] <slangasek> hallyn: I don't know which end of spice is the client or server ;)  Does that mean we need to not be building qemu-spice on 32-bit archs?
[21:05] <slangasek> SpamapS, smoser: so fundamentally, I think that having an rc.local /framework/ is something that's not the sysvinit package's job to solve
[21:06] <slangasek> rc.local is "the admin can edit it"
[21:06] <smoser> admins dont edit things any more
[21:06] <slangasek> and that editing could very well include dropping in a copy of some template that looks at /etc/rc.local.d
[21:07] <slangasek> the admin can edit it in as automated a fashion as they wish, but either way, it's not the package's problem :)
[21:07] <smoser> if rc.local.d is not the packages problem, then really, rc.local is not either. they are the same problem.
[21:07] <smoser> one is just older.
[21:07] <slangasek> yes, rc.local is an interface from the package
[21:08] <smoser> i really think that it adds a large usefulness at the cost of 2 forks in the boot
[21:08] <slangasek> any interfaces beyond that, such as a hypothetical rc.local.d, are not the problem of sysvinit
[21:08] <smoser> with, extremely low mantainence issues.
[21:08] <hallyn> slangasek: yeah i confused myself at first too :)  but yes qemu is the server, spicec or spicy is the client, so qemu-kvm-spice should not be built for 32-bit
[21:12] <smoser> slangasek, so is that a definitive "NO" ?
[21:12] <smoser> i'm willing to accept that it is.
[21:12] <slangasek> smoser: nothing is ever settled and I don't have the last word; but my opinion is firm :)
[21:13] <slangasek> this is something that's easy to design and implement without ever touching the sysvinit package
[21:13] <slangasek> because *by definition* the package won't mess with whatever changes you make to rc.local - including tweaking it to use rc.local.d
[21:14] <smoser> right. and thats fine.
[21:14] <smoser> so its easy to add
[21:14] <smoser> but its not easy to determine if modifying rc.local is going to stomp on someone else's already modified rc.local
[21:14] <smoser> so you have to assume that youc an't do that if you're trying to be a good tenant.
[21:15] <slangasek> mkdir /etc/rc.local.d; mv /etc/rc.local /etc/rc.local.d/reallylocal; echo > /etc/rc.local <<EOF.. :)
[21:15] <slangasek> and besides, I thought admins didn't edit files anymore, so why would there be anything in /etc/rc.local to preserve ;)
[21:16] <mbiebl> slangasek: /etc/rc.local.d, really? Isn't that what /etc/init.d is for...
[21:16] <hallyn> slangasek: i'm not sure offhand what the best place is to tell the pkg not to build for 32-bit...
[21:16] <slangasek> mbiebl: not my idea :-)
[21:16] <mbiebl> (I probably miss the context, so feel free to ignore me)
[21:16] <hallyn> (and i frankly find it disturbing...)
[21:16] <slangasek> hallyn: debian/control + debian/rules - build-dependencies, architecture fields, and the target can all be annotated by architecture
[21:17] <smoser> "I just want to run something late in boot". we've all come across that. mbiebl . wanting to deal with upstart or sysv init scripts and symlinks and run levels is something entierly different.
[21:17] <mbiebl> from a package pov or sysadmin?
[21:18] <mbiebl> and no, I don't think it's a good idea, fwiw
[21:19] <SpamapS> slangasek: admins don't modify files.. but they do work collaboratively on automation .. and having to first agree on the framework for rc.local.d is a barrier to system usage. If we called it '/etc/lateboot.d' and just made it a convenience dir, would that make more sense?
[21:21] <slangasek> mbiebl: /etc/rc.local.d obviously wouldn't belong in a package
[21:21] <slangasek> since it extends /etc/rc.local, which is not for packages
[21:22] <slangasek> SpamapS: again, how late is late
[21:22] <slangasek> I think this is underspecified at the moment
[21:23] <smoser> slangasek, i dont think that arguing "rc.local is unknown" is really relevant.
[21:24] <slangasek> hmm?
[21:24] <slangasek> if you want to define something that extends rc.local with rc.local.d, then obviously you'll get the same semantics
[21:25] <smoser> you stated that the time frame in which rc.local runs is unknown, which is true. but implying that something that runs right after that is therefore less valuable is i think not relevant.
[21:25] <slangasek> but I don't think rc.local is actually defined with a guarantee that it happens "at the end of boot", and if it is defined that way, the definition itself is broken thanks to event-based systems
[21:25] <slangasek> smoser: I'm saying that we shouldn't create something called "/etc/lateboot.d" without first definining what we actually mean by "late boot" and ensuring we can deliver
[21:25] <hallyn> slangasek: ok thanks, i'll try and get a fix for qemu-linaro
[21:25] <smoser> slangasek, then we should use rc.local.d because that invents nothing new.
[21:26] <smoser> it re-uses a broken definition with the same definition
[21:26] <smoser> :)
[21:26] <slangasek> smoser: if you wish :)  I'm not opposed to /etc/lateboot.d, I just think it has a prereq
[21:27] <slangasek> hallyn: I'm already elbow-deep in the package - I can take care of it if you want
[21:27] <SpamapS> Or fix rc.local to be truly "after runlevel 2 is fully started" by trying to define an event which is emitted after all things started by the transition to runlevel 2 have either changed goals back to stop or emitted 'started'
[21:28] <SpamapS> But really, I think thats orthogonal to the desire to make it easier to have non-conflicting rc.local modifications by putting in a .d directory.
[21:29] <smoser> SpamapS, i agree with that (bug so is the transition to upstart ;)
[21:29] <SpamapS> Though I have to agree that the *right* way is to have an upstart job that is start on stopped rc RUNLEVEL=[2345] .. user education on that may be harder than "look at shiny new /etc/rc.local.d"
[21:30] <mbiebl> SpamapS: the rc.local concept is broken (especially with an event based init), so I don't get why you want to extend a broken concept.
[21:31] <mbiebl> but I better just shut up now...
[21:31]  * micahg is syncing ca-certificates and crossing his fingers
[21:33] <mbiebl> SpamapS: that is rc.boot all over again...
[21:34] <hallyn> slangasek: oh, missed that - that'd be terrific, and i'll look at how you did it and learn :)  thanks
[21:35] <SpamapS> mbiebl: its crap. I agree. But its not going away. rc.local *is not* going away, ever.. busy admins without time to learn the intricate event interactions will always want to run something "late".
[21:37] <slangasek> SpamapS, mbiebl: we could certainly do away with /etc/init.d/rc.local in favor of an /etc/init/rc.local that's 'start on stopped rc [...]', in any case
[21:37] <slangasek> but that's not actually a material difference from what we currently do
[21:38] <mbiebl> SpamapS: that's the crux, what exactly is "late"? imho that just makes it easier for admins to shoot themselves in the foot
[21:43] <slangasek> mbiebl, SpamapS: right; as more jobs move to upstart, rc.local is likely to be running *before* most services have started
[21:43] <SpamapS> slangasek: indeed, thats basically a wait() call later. ;)
[21:45] <SpamapS> slangasek: so how do we simplify their life. Could we have a job which lists all of the expected events a system will receive and have that be the sync point..
[21:46] <SpamapS> actually.. hm
[21:46] <SpamapS> this is where the 'network-services' job comes in handy
[21:46] <SpamapS> if we make all things follow that, instead of runlevel 2, then we can say when it transitions to 'started', all normal network services are ready.
[21:47] <SpamapS> something to think about for 12.10 (assuming the systemd flying monkies don't carry us away)
[21:47] <slangasek> SpamapS: so jobs would be 'start on starting network-services', and rc.local would be 'start on started network-services'?
[21:50] <SpamapS> slangasek: and stopped rc RUNLEVEL=[2345]
[21:51]  * slangasek nods
[22:18] <quadrispro> eh-ehy! hi all!
[22:23] <soren> Is there anything about the (PPA) buildd's that might prevent me from readlink()ing /proc/<PID>/exe ?
[22:24] <soren> infinity: You'd probably know? ^
[22:38] <hallyn> SpamapS: perhaps i could get you to pick a good start on for libvirt?  bc i've not followed this whole conversation
[22:39] <SpamapS> start on (runlevel [2345] and stopped networking RESULT=ok)
[22:39] <SpamapS> hallyn: thats a bit explicit given 11.10+'s guarantee that all of /etc/network/interfaces will be up
[22:40] <SpamapS> hallyn: until we have the network-services job in place, runlevel [2345] is good
[22:40] <hallyn> SpamapS: so to be clear, you're saying make it jsut "start on runlevel [2345]" ?
[22:41] <SpamapS> hallyn: yes if all it requires is all network interfaces and filesystems to be up and mounted.
[22:41] <hallyn> SpamapS: thanks, put that in my "to do on next push" list
[22:51] <infinity> soren: Nope, should work fine.
[22:52] <bdmurray> um, how do you start an ssh server?
[22:52] <StevenK> sudo start ssh ?
[22:52] <infinity> (after installing it)
[22:53] <bdmurray> right and I'm still seeing 'Unknown job: ssh'
[22:53] <bdmurray> on a precise live cd
[22:53] <infinity> bdmurray: It's not on the livecd.
[22:53] <infinity> bdmurray: apt-get install ssh
[22:53] <infinity> (or openssh-server, which ssh depends on)
[22:54] <bdmurray> yes when I said right I meant I've installed openssh-server
[22:54] <bdmurray> and I see ssh in /etc/init.d/
[22:54] <infinity> So start it from init.d
[22:54] <soren> infinity: Ok, cool. Thanks.
[22:55] <infinity> Though installing it should have started it.
[22:55] <infinity> Unless you had/have no interfaces up.
[22:55] <bdmurray> how could I have installed it then?
[22:55] <infinity> Fair point. :P
[22:56] <StevenK> Via a USB key and dpkg -i :-P
[22:57] <bdmurray> with /etc/init.d/ssh start I see use service and then 'start: Unknown job: ssh' again
[22:57] <broder> "service ssh start"
[22:57] <broder> oh, on lucid you still needed to do "initctl reload-configuration"
[22:57] <broder> whenever something changed /etc/init
[22:57] <bdmurray> this is just a precise live cd
[22:58] <broder> yes, you've installed the server, but because /etc/init/ssh.conf wasn't there at bootup, upstart doesn't know about it
[22:58] <broder> so run "initctl reload-configuration" to pick up the changes
[22:58] <infinity> ... really?
[22:58] <broder> that was definitely the case with upstart for some number of releases
[22:58] <infinity> Oh, wait, does upstart rely on inotify to scan for new services?
[22:59] <RAOF> I'm *pretty* sure upstart watches /etc/init with inotify.
[22:59] <bdmurray> broder: okay that worked thanks
[22:59] <infinity> If so, overlayfs's lack of inotify support would break that.
[22:59] <broder> infinity: hahaha. yes, yes it does
[22:59] <bdmurray> great
[22:59] <bdmurray> does anybody know of a bug about that being reported yet?
[23:00] <infinity> apw: Say, have we ever escalated the important of inotify in overlayfs? :P
[23:00] <infinity> bdmurray: I think Andy has a bug, no idea what sort of movement it has.
[23:00] <infinity> apw: s/important/importance/
[23:01] <bdmurray> bug 882147 right?
[23:02] <infinity> bdmurray: Should do.
[23:39] <slangasek> hallyn: pushed my qemu-linaro changes to the UDD branch, if you want to have a gander
[23:40] <hallyn> slangasek: fetching
[23:57] <hallyn> slangasek: so will simply not building a new i386 package DTRT?  ( I was expecting to have to create an empty package to invalidate the last one)
[23:57] <hallyn> (or does it just not matter bc we're still in alpha)
[23:59] <slangasek> hallyn: oh, I would never do a transitional package for a case where the package was never meant to exist on an arch and can't be used
[23:59] <slangasek> so this DTRT in the sense that once it's published, I'll yank the i386 binary out of the archive with my AA hat on
[23:59] <hallyn> slangasek: cool :)  thanks