[00:00] okay, I was / am considering a bug pattern [00:21] 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] ah, its me [00:22] mmk [00:49] wait... when a package is synced from debian, it's just the source right, the binaries are still rebuilt for ubuntu right? [00:50] psusi: correct === cyphermox_ is now known as cyphermox [01:36] 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] 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] 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] 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] 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] 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] 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] 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] YokoZar: tracker> ah, that'll be my fault for not getting the blueprint shoved along to "approved" state [02:08] 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] which isn't pleasant [02:08] 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] 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] The uglier solution is just a big manual hard-coded list in update-manager :/ [02:09] YokoZar: Well, the transitional package would be the old name, and it would depend on zsnes-i386, I guess? [02:09] (which doesn't work for dist-upgrade, which is why I suggested modifying the apt resolver) [02:09] infinity: right, and then we'd have to rename zsnes to zsnes-i386 :/ [02:10] Yup. [02:10] I did note that it fails the elegance test. [02:10] But it's at least easy to spot-check for correctness. [02:10] infinity: you can look at the new wine1.4 package for a similar setup [02:10] The proposed apt change is immediately incorrect in several corner cases, without looking for weirder ones. [02:10] YokoZar: alternatively, you can fix the amd64 build so that it builds the arch specific parts if there are any [02:11] 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] (Out of curiosity, why would this be done to zsnes? Does the 64-bit build not work?) [02:11] Oh, there isn't a 64-bit build, I see. That seems odd, given that it's an emulator. :P [02:11] infinity: zsnes does not and will not build on amd64 ever, I think it's full of assembly code or some such. [02:12] Fair enough. [02:12] YokoZar: you can do what we did with flash, if you can get it to compile again :) [02:12] Still sounds like it should just be dealt with the same way flash is. [02:12] The same way we did flash in oneiric, that is. [02:12] Before we had a 64-bit one. [02:12] Burn it with fire/ [02:12] ? [02:13] Oh, that's not what you meant. [02:13] zsnes:amd64 depends zsnes-i386 (i386 only) which depends on zsnes:i386 [02:13] micahg: Makes the packaging a bit more complex, since zsnes.install differs on the two arches. [02:14] 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] 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] infinity: that works too, but I hate the idea of having a zsnes-i386 package in perpetuity [02:15] infinity's solution is a bit better but leaves us with dumb names forever [02:15] micahg: Who cares? Package names are often weird. [02:15] it's a diff from Debian [02:15] So, convince the Debian maintainer to do the same thing. [02:15] But it's not actually a large diff. [02:15] OR, we could implement specific arch relationships in control fields... [02:16] well, now that Debian will soon have a multiarch capable dpkg, that might be possible :) [02:17] 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] There's a certain advantage in not having individual package maintainers, yes. [02:18] Downside: Lots of universe bugs go ignored. Upside: When we want to move on something, we MOVE. [02:25] infinity: Lots of Main bugs go ignored too. [02:29] Any ubuntu dev working groups focussed on tablets and/or wayland ? [05:02] hola, i hope there someone out there who could help me :) [05:02] im sorry ,but im really new to irc [05:02] should i just post my problem here? [05:03] im trying to build linux kernel [05:03] here is the error i get,please point out what did i do wrong [05:04] -VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ make ARCH=arm [05:04] mkdir: cannot create directory `include/generated': Permission denied [05:04] make[2]: *** [silentoldconfig] Error 1 [05:04] make[1]: *** [silentoldconfig] Error 2 [05:04] make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. [05:04] nidhal@nidhal-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ sudo make ARCH=arm [05:04] scripts/kconfig/conf --silentoldconfig Kconfig [05:04] CHK include/linux/version.h [05:04] UPD include/linux/version.h [05:04] CHK include/generated/utsrelease.h [05:04] UPD include/generated/utsrelease.h [05:04] Generating include/generated/mach-types.h [05:04] CC kernel/bounds.s [05:04] cc1: error: unrecognized command line option ‘-mlittle-endian’ [05:04] cc1: error: unrecognized command line option ‘-mno-thumb-interwork’ [05:04] kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch [05:04] kernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch [05:04] make[1]: *** [kernel/bounds.s] Error 1 [05:04] make: *** [prepare0] Error 2 [05:04] please :( [05:05] nidsub: first error is you didn't use a pastebin for that [05:06] as for the rest, is this on an arm system or are you cross compiling [05:06] thank you :),yerp im trying to cross compile [05:07] is on arm qemu [05:08] here the detail on the step i took ..from this webpage [05:09] http://wiki.xilinx.com/zynq-linux [05:12] well, this isn't a general support channel, #ubuntu-arm might be better suited [05:12] #ubuntu would be for general support, but I don't see this working out too well in there [05:15] Thanks you so much for the tips === yofel_ is now known as yofel === tkamppeter_ is now known as tkamppeter === ts2 is now known as tsimpson [07:10] I'm trying to use debuilder but it doesn't seem to be creating my deb file although i get no errors [07:32] Good morning [07:40] Morning everyone! [07:44] http://twitter.com/#!/gregkh/status/166644258831478784 <- yay, gregkh -- of kernel fame -- contributing to LibreOffice ... === smb` is now known as smb === jodh is now known as jhunt` === jhunt` is now known as jhunt_ [10:00] Daviey: mariadb> as it is 100% binary compatible, I think there is some good grounds for a FFE on this one [10:00] 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] pitti: need to discuss this in a bit. :) [10:13] - /usr/lib/debug/usr/lib/i386-linux-gnu/libsoup-2.4.so.1.5.0 [10:13] + /usr/lib/debug/.build-id/5e/d483e11d8dbaff9929c94ad6b9b05a174c7685.debug [10:13] I noticed the new /usr/lib/debug/.build-id/ gibberish recently, too [10:13] is that something which changed in our toolchain (it's libsoup2.4-dbg new version) [10:14] I have no idea what changed there [10:15] hum, k [10:15] well I will assume it's not a bug on my side then ;-) [10:17] seb128: it's a new debhelper 9 behavior [10:17] debfx, ok, thanks [10:18] * dh_strip: In v9, pass --compress-debug-sections to objcopy. [10:18] I guess [10:18] that source is v9 [10:18] so this stuff is actually valid? [10:18] debian bug 631985 [10:18] Debian bug 631985 in debhelper "dh_strip: add a possibility to compress debug sections" [Wishlist,Fixed] http://bugs.debian.org/631985 [10:18] it seems a ridiculously bad design to put this in a hidden directory [10:19] with useless names... === _salem is now known as salem_ === Chipzz is now known as Chipzz_ === Chipzz_ is now known as Chipzz [12:06] cking: FYI, I'm currently working on https://launchpad.net/fatrace [12:06] cking: as powertop seems to do a rather bad job at catching disk events (and even reports them wrongly, too) [12:06] cking: once it's ready and in the archive, I'll update https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues accordingly [12:06] pitti, wow, this is excellent! [12:07] cking: fanotify is quite nice for this :) [12:08] cking: if you are interested in trying, it's in lp:fatrace; make && sudo ./fatrace [12:08] yep, this is an excellent tool to track down these offending wakeups! [12:08] it has --time and --output options, and I'm going to add some filtering, too [12:08] cking: well, it's not process wakeups (that's powertop), just disk events [12:09] "f"ile "a"ccess trace [12:09] cking: if you want it to do something more (new option, etc.), please let me know [12:12] 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] cking: no, it ignores its own events [12:13] sweet [12:13] cking: without -o, gnome-terminal touches a tempfile in /tmp/ with every output, and thus generates a feedback loop [12:14] -o avoids this, but I'm trying to add something more clever [12:14] yep, I saw that and wonder what was happening [12:14] well /tmp tmpfs definitively helps [12:14] but we don't have that by default [12:14] cking: --ignore-pid could work [12:15] --ignore-path /tmp/ sounds a bit pointless [12:15] (but might make sense for other contexts) [12:15] by default it watches all "real" mounts [12:15] it could grow an option to only watch the mount of current cwd [12:16] perhaps adding a timestamp to the output so we can figure out if events occur periodically may help [12:16] pitti, bug #928212 hate gzip hate [12:16] Launchpad bug 928212 in gtk+2.0 (Ubuntu) "Cannot install ia32-libs due to libgtk2.0-0_2.24.10-0ubuntu1_i386.deb conflicts with libgtk2.0-0_2.24.10-0ubuntu1_amd64.deb" [Undecided,New] https://launchpad.net/bugs/928212 [12:17] argh [12:18] cking: ah, good idea [12:19] 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] cking: it's not supposed to be the preferred frontend [12:20] cking: I have another WI to write a script that calls powertop, fatrace, and generate a report out of it [12:20] with worst offenders, sorted, etc. [12:20] pitti, ah, I understand - good idea! [12:21] cking: I really don't want to do all this in plain C :) === zyga_ is now known as zyga [12:28] 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] cking: yes, like the file accesses [12:28] wakeups seem to be quite reliable, though? [12:28] and battery power consumption too [12:29] 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] cking: pushed --current-mount option; might be useful for some finer-grained debugging [12:32] 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] 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] MacSlow, hey, let me have a look [12:34] 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] MacSlow, that sounds good [12:35] MacSlow, hum, launchpad gives and empty diff? [12:35] seb128, I'd be happy if you could review it [12:35] seb128, yeah... hold on a minute... I accidentally pushed to trunk instead of the correct branch *cough* [12:36] seb128, fixed/reverted it in trunk already... but needs some time to pick that up [12:36] MacSlow, ok === MacSlow is now known as MacSlow|lunch [12:43] Processing triggers for libc-bin ... [12:43] ldconfig deferred processing now taking place [12:43] sh: 1: /usr/bin/gdbus: not found [12:43] neat [13:00] cking: ok, timestamps available now; -t is now -s [13:02] pitti, \o/ [13:03] how to prevent lightdm respawning Xorg session? [13:03] i'd like X once killed, stay killed === Quintasan_ is now known as Quintasan [13:07] other words I'd like to kill,remove seat. [13:12] lightdm has SeatRemoved signal but no Remove seat method === dendro-afk is now known as dendrobates === MacSlow|lunch is now known as MacSlow === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dduffey_afk is now known as dduffey [14:23] cking: it's quite unbelievable how much disk activity chatter even my bash prompt uses.. [14:23] bashing the oxide off the platter.. [14:23] well, my fault mostly, of course; it calls git, sed, and whatnot [14:24] this is where we find most of the disk events are due to our tools [14:25] cking: I added an --ignore-pid option now, so gnome-terminal can be silenced [14:25] cking: from my POV this should be good enough for a first release; do you still see something major missing? [14:25] oh, I should document theh flags in the manpage [14:26] pitti, lemme have one more look [14:30] 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] I'm not actually sure which capability that is [14:30] CAP_SYS_ADMIN? [14:31] cking: doing that properly is a bit nontrivial, so I didn't so far [14:31] cking: uid==0 is not quite sufficient, I think [14:31] apparmor might restrict it, and other systems might allow it even to non-root processes [14:31] ah, true [14:34] pitti, its surprising how much unity-panel-service is doing really [14:35] cking: I'll rename 'M' to 'W' and 'A' to 'R'; that's a bit clearer IMHO [14:35] pitti, heh, I can't valgrind the fanotify_* calls [14:35] valgrind? [14:36] yeah, I run valgrind on all apps to see if they are leaky [14:36] I don't use any dynamic memory allocation [14:36] in small C programs I try not to, both to guard against leaks and also because it's more efficient [14:37] (not copying stuff around, etc.) [14:37] well, there's one strdup() for the --output argument [14:37] that could be freed, but it's only a single allocation [14:37] ..just me being anal ;-) [14:37] but I like my global variables to be valid all the time [14:37] cking: right, appreciated :) [14:38] cking: so, valgrind doesn't know about fanotify? [14:38] so, as for features and functionality it looks most excellent [14:38] pitti, well, valgrind on my precise box didn't like the fanotify_init() [14:40] goodness knows how that's implemented [14:46] cking: manpage updated as well now [14:50] micahg, OK if I merge maven-repo-helper? a couple of bug fixes only... [15:01] pitti, looks all good to me [15:01] Cannot initialize fanotify: Operation not permitted [15:01] You need to run this program as root. [15:01] cking: ^ slightly more friendly now [15:02] pitti, yay [15:02] cking: ok, thanks; off to a 0.1, and packaging :) [15:04] cking: https://launchpad.net/fatrace -> gotta love how LP says that I released the 0.1 tarball 15 hours ago :) [15:05] pitti, LP now a time machine too? [15:09] superm1, around ? i've some questions about dkms. [15:23] 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] dholbach: they all wait [15:23] (I'm asking because of fcitx) [15:23] ah ok [15:24] superm1, never mind. i think i got it sorted. [15:24] otherwise we'd end up with broken dependencies very often [15:24] yeah, I guess === dendrobates is now known as dendro-afk [15:24] stupid question, but I just wanted to be sure ;-) [15:24] cking: uploaded; now I need to bribe an archive admin to process it :) [15:25] pitti, have you bribed yourself before? ;-) [15:25] 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] 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] that's also why I asked about the fcitx one :) === sergio_ is now known as Guest33596 [15:37] * Sweetshark should lurk more, to be able to make grow the casual hugs into grouphugs .... [15:46] 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] are these parallel installable? [15:47] dholbach, thanks! [15:47] also NICE [15:47] dholbach, will you do gdamm5 as well? ;-) === dendro-afk is now known as dendrobates [15:50] seb128, on it [15:50] dholbach, you rock, you make me want to spend some time on the sponsoring queue ;-) [15:50] seb128, uploading it right now [15:51] there's something funny with a devhelp file [15:51] dholbach, I will not wait friday though, I'm concerned that too many people hitting on it together will lead to duplication ;-) [15:51] but I think it's more important we get glom up and running and fix the other stuff later [15:51] has the sover changed? shver is still the same [15:51] seb128, if you want to do a bit of sponsoring before - do it :) [15:52] Laney, hm? it seems like no goocanvasmm-2.0 is available right now at all? [15:52] dholbach, right [15:54] well, indeed, but I think it probably wants to be 1.90 [15:54] anyway I will have a proper look later [15:54] glom depends on this version now? [15:54] yes [15:54] grand [15:55] it's all in the openismus ppa [15:55] I just had to make a few very very small changes [15:55] this neatly steps around jsogo [15:55] would anyone be interested in maintaining? [15:56] seb128, and I are in discussions with the openismus people [15:56] they maintain it in their ppa already [15:56] 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] mvo: hi, do you have time a slightly offtopic question? How does one submit a translation for upstream apt? [16:26] I tried the BTS, without much success: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655238 [16:26] Debian bug 655238 in apt "[INTL:hu] Updated Hungarian translation for apt" [Wishlist,Open] [16:28] kelemengabor: sure, always! the debian bts is the right place, if noone has merged it yet I can do that [16:29] kelemengabor: fwiw, its in debians bzr already [16:29] kelemengabor: just not released or taged in the bug [16:29] pitti: fatrace> very nice :) [16:30] kelemengabor: sorry for that, there should be anohter upload to stable I guess [16:30] slangasek: I have a half-written blog post about it, will finish after our meeting [16:30] slangasek: thanks :) [16:30] 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] slangasek: it's indeed quite surprising what enormous disk chatter we have during a normal session [16:30] slangasek: 10 mins sounds fine [16:30] well, it doesn't surprise me :/ [16:30] because we know we have a longstanding bug about parking cycles destroying disks [16:31] mvo: oh, that's nice. I should read bzr logs more :). Thanks! [16:33] kelemengabor: well, someone should have simply told you :) so no worries === shadeslayer is now known as shadeslayer_ === shadeslayer_ is now known as shadeslayer [16:37] directhex: hey! do you know thhe status of the banshee gtk3 port? [16:38] pitti, i saw it demonstrated at fosdem this weekend. i'm not sure what release blockers there are, if any [16:40] pitti, hi [16:41] 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] directhex: ah, thanks; nice to hear that there's good progress === kentb_ is now known as kentb_dell [16:54] jamespage: sure, wasn't sure if we needed it [16:56] slomo: more quiet here, so http://paste.ubuntu.com/832840/ [16:57] pitti, I have pushed up CUPS 1.5.2-2 now, can you upload it to Debian and Ubuntu? Thanks. [16:57] tkamppeter: ok, thanks [17:03] pitti: with regards to bug 856975 that traceback shows up in almost all ubiquity syslog files [17:03] Launchpad bug 856975 in language-selector (Ubuntu) "fontconfig-voodoo crashed with DBusException in __new__(): org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory" [Low,Confirmed] https://launchpad.net/bugs/856975 [17:03] it seems dbus is not running in that environment [17:04] I think we need to fix that [17:06] 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] anyway, I'll have a closer look in the live session (and ubiquity-only) [17:06] put on my todo list [17:07] thanks [17:08] 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] cr3: no autoconf? [17:11] tkamppeter: uploaded [17:12] cr3: I'm not sure one way is better than the other, anyway; both will have rough spots [17:14] 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] pitti, thanks. [17:24] micahg, ta [17:52] 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] @pilot in === udevbot changed the topic of #ubuntu-devel to: Alpha 2 released! Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS [18:35] micahg: I wouldn't keep transitional code from release-1-ε, no [18:36] slangasek: well, the rest of the code said drop after oneiric, that's part of why I'm asking [18:36] 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] the other part is, do we assume upgrade to release packages before upgrading to the next release [18:36] *I* certainly assume that :) [18:36] ok, yeah, it's the only diff [18:39] mvo: BTW, synaptic still FTBFS in Ubuntu === joshua__ is now known as tobin [19:38] micahg: meh, thanks! let me look [19:39] mvo: it seems weird, the patch applied in Debian, but not Ubunut [19:39] *Ubuntu [19:40] micahg: I also wonder why I did not get the ftbfs mail :/ [19:43] micahg: at least I can reproduce it here, I work on it now [19:59] micahg, did you already care about all gnat related packages? [20:12] smoser: just reviewed your patch for bug 915215 [20:12] Launchpad bug 915215 in sysvinit (Ubuntu) "rc.local should support a runparts of rc.local.d" [Low,In progress] https://launchpad.net/bugs/915215 [20:13] man this sucks, [20:15] SpamapS, smoser: eew? this is rc.local, it's *supposed* to be edited by the admin [20:15] packages should *never* be adding anything to it [20:15] slangasek: welcome to the world of automation [20:16] why would you use *that* interface for automating anything? [20:16] 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] slangasek: people use rc.local all the time in automation because it is reliable and simple to implement. === salem_ is now known as _salem [20:19] SpamapS: so why not just *clobber* /etc/rc.local? [20:19] it's rc.local [20:20] why worry about its default contents at all? [20:21] 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] doko: do you have an opinion on getting numpy 1.6 into precise before the feature freeze? [20:22] it is backward compatible with 1.5, and only 18 packages that need rebuild [20:22] debian is going to transition very soon too but probably after feature freeze [20:22] jtaylor, no. do you want to prepare packages? [20:23] doko: I'm currently just looking for helpers and getting an overview, if people approve I'll prepare packages [20:23] hallyn: bug #928432 says spice should only be enabled on 64-bit builds; can you confirm? [20:23] Launchpad bug 928432 in Linaro QEMU "spice backend fails to build on i386 with -Werror" [Undecided,New] https://launchpad.net/bugs/928432 [20:24] 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] doko: great, I'll let you know on the progress [20:29] SpamapS, thank you. i dont mind it being upstart. [20:29] i actually went looking for you one day to read the suggested upstart script htat i put int he bug [20:29] 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] 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] i backed away as it was just more intrusive. [20:30] i agree with SpamapS . [20:30] slangasek: and its still simpler than using /etc/init.d + update-rc.d or upstart (though upstart *does* help a lot) [20:30] 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] slangasek: hm, http://spice-space.org/faq.html [20:30] says only server isnt supported on 32bit, client is [20:30] slangasek, well, rc.local is back to being "relatively" late in boot [20:31] wel... [20:31] slangasek: d'oh, so yeah [20:31] err.. anyway i think that is a separate issue entirely. [20:31] 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] 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] 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] well, if its not "late in boot", then really, thats a bug. [20:32] we re-defined it [20:33] (yes, i realize we did, but currenlty its *so* much better than it was in 10.04) [20:33] micahg, there are no diffs, just a bootstrap is needed [20:35] doko: ah, Debian has a patch in 4.4 that lets it bootstrap from 4.6 which is built now [20:35] 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] 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] micahg, neither 4.4 nor 4.6 are built on armhf [20:36] gnat | 4.6ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc [20:36] ah, it's empty :) [20:36] doko: ok, I don't know how to bootstrap that offhand [20:40] 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] broder, no. unless by coincidence [20:43] 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] SpamapS, wel... commented on post there. [21:04] smoser: udev redefined it; we just made that redefinition manifest :) [21:04] 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] 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] rc.local is "the admin can edit it" [21:06] admins dont edit things any more [21:06] and that editing could very well include dropping in a copy of some template that looks at /etc/rc.local.d [21:07] 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] if rc.local.d is not the packages problem, then really, rc.local is not either. they are the same problem. [21:07] one is just older. [21:07] yes, rc.local is an interface from the package [21:08] i really think that it adds a large usefulness at the cost of 2 forks in the boot [21:08] any interfaces beyond that, such as a hypothetical rc.local.d, are not the problem of sysvinit [21:08] with, extremely low mantainence issues. [21:08] 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] slangasek, so is that a definitive "NO" ? [21:12] i'm willing to accept that it is. [21:12] smoser: nothing is ever settled and I don't have the last word; but my opinion is firm :) [21:13] this is something that's easy to design and implement without ever touching the sysvinit package [21:13] 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] right. and thats fine. [21:14] so its easy to add [21:14] but its not easy to determine if modifying rc.local is going to stomp on someone else's already modified rc.local [21:14] so you have to assume that youc an't do that if you're trying to be a good tenant. [21:15] mkdir /etc/rc.local.d; mv /etc/rc.local /etc/rc.local.d/reallylocal; echo > /etc/rc.local < and besides, I thought admins didn't edit files anymore, so why would there be anything in /etc/rc.local to preserve ;) [21:16] slangasek: /etc/rc.local.d, really? Isn't that what /etc/init.d is for... [21:16] slangasek: i'm not sure offhand what the best place is to tell the pkg not to build for 32-bit... [21:16] mbiebl: not my idea :-) [21:16] (I probably miss the context, so feel free to ignore me) [21:16] (and i frankly find it disturbing...) [21:16]