[00:00] (and has to, because /etc/init/networking always races /etc/init/network-interface) [00:01] ok, so the problem is the second interface trying to join the bond before it's done being brought up by the ifup triggered by the first interface (when both eth0 and eth1 appear at the exact same time) [00:08] stgraber: yeah, that's probably one of the problems, at least === dendrobates is now known as dendro-afk [00:15] So do all new packages in Debian get automatically attempted to be added to universe in ubuntu, or do they need to be requested to be synced? It was a little foggy on the matter on the ubuntu wiki. [00:17] haakon_n: They don't need to be requested, but they do need manual review by the archive-admins. If they are lagging on the review, or it's urgent, they can be poked, or a sync can be requsted. [00:18] so they do automatically get reviewed just from being in debian? [00:18] if they make it to testing (because it's an LTS, so we are syncing from testing), yes [00:18] get to be reviewd, that is [00:18] ok [00:19] So is there a public page where you can follow the current state of pending packages, etc? [00:21] No, unless it's been synced by a developer, in which case it shows up in the NEW queue [00:21] ok :) [00:26] pitti: why did udev move to /lib/udev? [00:39] stgraber: so now that I've isolated a udev upgrade bug here (udevd not actually running), I do get udev events when bond0 is brought up [00:39] s/brought up/created/ [00:41] slangasek: ok, so I guess we could do 'echo +bond0 > /sys/class/net/bonding_masters' which should create the bond and trigger udev [00:44] stgraber: yep [00:54] slangasek: I'm putting forth a plan to drop mysql 5.1 entirely as soon as we've transitioned to libmysqlclient18 entirely.. do I need to even bother uploading a new mysql-5.1 that does not build libmysqlclient-dev (and the other bits) ? === dendro-afk is now known as dendrobates [01:00] SpamapS: I wouldn't bother unless you think you're going to need to upload it in the meantime for other reasons [01:00] the package would simply not be uploadable without that change, which isn't a major problem if you're not uploading it :) [01:00] slangasek: right, thats what I was thinking. I've got a branch with it on deck if the need arrises. [01:02] slangasek: so current plan sounds like: http://paste.ubuntu.com/738823/ [01:03] slangasek: should be doable with only limited changes to the current scripts so we don't divert too much from Debian [01:04] stgraber: "wait for" - that implies polling... [01:04] if you have to poll, you might as well just call ifup instead [01:05] but you might be able to have the slave added from the pre-up master when triggered? [01:07] well, I'd have to call ifup + poll anyway as in my tests, the second NIC comes up before ifup is done loading the kernel module and preparing bond0 [01:07] I'd rather not have a different code path for the first interface and for the second, trying to keep things simple :) [01:13] stgraber: wouldn't both slaves end up waiting for ifup in that case? [01:15] slangasek: yes, whichever gets to the ifup part first actually starts it (the second one will just fail doing so), then they both wait for /sys/class/net/bond0 to appear and then add themselves to the list of slaves (that part shouldn't be racy, so it's fine having both doing it at the same time) [01:15] ah, I didn't think it would fail, I thought it would wait for the lock [01:15] you've tested this? [01:17] I'm getting a: === dendrobates is now known as dendro-afk [01:17] ifup: interface br0 already configured [01:17] (tested with a bridge instead of bond because I'm on my laptop :)) [01:17] that's while another ifup br0 is running waiting for 10s (sleep in the pre-up script) [01:19] stgraber: ah, that's pretty conclusive then :) === dendro-afk is now known as dendrobates [02:30] SpamapS, so to fix my bad upload of libvirt that ftbfs for lucid-proposed; should i push fix with incremented version # ? Or can I just as well push with same version # since it failed to build anyway? [02:31] hallyn: new version number needed, launchpad already knows about that source version [02:36] slangasek, thanks [02:37] slangasek, one more q though :) [02:37] shoot [02:37] does that mean that I should do -v ? [02:37] so that if/when it goes to -updates, launchpad catches the '(LP: #xxxxxx)' from the previous commit msg? [02:37] hallyn: preferably, yes [02:37] cool, thanks === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [05:19] good morning [05:20] cjwatson: haskell-dummy> whoa, I'll have a look at that one [05:23] cjwatson: rather, it should just operate on the current binary, as it's called through dpkg-deb; there used to be a reason why it does that double interation, though [05:23] slangasek: I'm not sure, upstream decision; but I figure they wanted to have the daemon out of $PATH [05:24] pitti: upstreams frequently get the FHS wrong; I would suggest we put it back in sbin [05:24] (udev upstream in particular is clue-impaired where the FHS is concerned ;) [05:25] pitti: I noticed this because of bug #889226, fwiw [05:25] oh, does it say that daemons should be in $PATH? [05:25] Launchpad bug 889226 in udev (Ubuntu Precise) "X fails to correctly find my USB input devices" [High,Triaged] https://launchpad.net/bugs/889226 [05:26] pitti: sbin is "system binaries", which certainly covers udev [05:27] so, I don't mind much where it lives; we can just revert the commit that changed the path and change the .install [05:27] but AFAICS bug 889226 needs to be fixed anyway [05:27] Launchpad bug 889226 in udev (Ubuntu Precise) "X fails to correctly find my USB input devices" [High,Triaged] https://launchpad.net/bugs/889226 [05:27] agreed on both counts [05:28] okay, will do today [05:28] pitti: ok, cheers :) [06:16] can i get an archive admin to run the backport-helper script? we've had a bunch of pending backports for a little while now [06:59] slangasek: I'm not actually sure why Keybuk added "restart udev || true", i. e. whether it was expected to fail sometimes; but I guess it really shouldn't fail [07:00] and why it's using --no-start with dh_installinit [07:00] pitti: probably to work around the behavior when trying to call 'restart' in a chroot [07:00] (but this is the wrong solution; chroots that shouldn't have services started inside of them should have a policy-rc.d, or a diversion) [07:01] *nod* [07:02] slangasek: so invoke-rc.d is still the right thing to call, despite it's verbose "this is not the script you are looking for" warning? [07:02] that warning isn't from invoke-rc.d itself, and yes it is the right thing to call :) [07:03] (the warning is from /lib/upstart-job, and is explicitly suppressed when called from maintainer scripts) [07:03] /lib/init/upstart-job, even [07:05] slangasek: something like http://paste.ubuntu.com/738960/ ? [07:05] pitti: no [07:05] lose the conditional [07:05] invoke-rc.d is always present, and is always the right interface [07:05] . o O { checking for -x invoke-rc.d really seems antique, but is still common pracice in Debian } [07:06] slangasek: okay (also, s/rsync/udev/ of course) [07:06] heh, right :) [07:07] as for it being common practice in Debian, I'm pretty sure I chased that out of policy and debhelper a little while ago ; [07:07] ) [07:07] yeah, February of this year, Debian bug #610340 [07:07] :) [07:07] Debian bug 610340 in debhelper "dh_installinit should not call init scripts directly, even as a fallback" [Minor,Fixed] http://bugs.debian.org/610340 [07:07] ah, so the existing scripts like rsync's just haven't been rebuilt since then [07:08] slangasek: thanks; building/testing now, will upload in a bit [07:09] pitti: yay, thanks :) [08:02] good morning [09:12] cjwatson: I filed the "too many iterations" part as bug 890595 [09:12] Launchpad bug 890595 in pkgbinarymangler (Ubuntu) "pkgstriptranslations loops over all binary packages instead of just the current one" [Low,Triaged] https://launchpad.net/bugs/890595 [09:17] and the FTBFS part as bug 890596 [09:17] Launchpad bug 890596 in pkgbinarymangler (Ubuntu Precise) "causes haskell-dummy FTBFS" [High,Triaged] https://launchpad.net/bugs/890596 [09:17] Laney: ^ FYI, if you got spammed with the haskell-dummy FTBFS log; I'll fix this in pkgbinarymangler and retry [09:26] pitti: I started out saying "it should just operate on the current binary" but I assumed that it was operating on all of them because it wanted to produce a single tarball [09:27] cjwatson: right, it should merge them together if it already exists; it already does that with the _translations_static.tar.gz stuff [09:27] ok, if you think that'd be reasonably performant :) [09:27] but anyway, it's producing a lot of output, but that's not what's breaking the build, and if the translations tarball already exists it doesn't do much [09:27] (that's why I set it as "low") === dholbach_ is now known as dholbach [09:45] anyone know how to make python look in a particular location for a module before looking in /usr/lib/python2.x/dist-packages ? [09:45] sys.path.insert(0, ...) [09:47] ah, yeah - i saw that somewhere before. thanks [09:47] Alternatively, try virtualenv if the package is available in PyPI. [09:49] brendand: or call the program with $PYTHONPATH if it's temporary and you don't want to modify the source [09:50] Although I'm currently converting a package from using private modules to using public modules, because it's more useful that way. [09:50] pitti - so if a module is on the PYTHONPATH it should be taken from there first? [09:50] yes [09:51] brendand: cjwatson's suggestion is the right one if you want to use private modules in your project [09:51] $PYTHONPATH is right if you want to test somethign with a local version of a system module [09:52] I often do things like "PYTHONPATH=. ./gtk/apport-gtk" to test the apport modules from trunk [09:53] pitti - my problem is solved now. but it seemed like my script was using the system version of lazr.restfulclient even though i had a local version in the PYTHONPATH. [09:54] which i thought was strange [10:00] pitti: ah, hadn't noticed — actually, how can I subscribe to build failure notifications? I only know how to get bug mail. [10:01] Laney: usually it mails the uploader and the Maintainer:, but perhaps not for Debian syncs [10:01] maintainer will be the team [10:01] (and I've never seen a mail like that for a sync, indeed) [10:05] there's a bug about that I think [10:05] or even a manual upload (to the maintainer), I don't think? [10:05] I suppose the lists swallow them though [10:07] https://bugs.launchpad.net/launchpad/+bug/876594 is basically the same [10:07] Launchpad bug 876594 in Launchpad itself "rejected builds for synced packages send mail to Debian maintainer" [Critical,In progress] [10:07] I definitely get notifications for failed builds that I've uploaded ordinarily [10:08] as /uploader/, yes [10:08] but I do not think I have ever seen anything as Maintainer except from MoM [10:08] generally it's complicated by the need to avoid spamming Debian developers with Ubuntu build failures [10:09] right, it is probably the right thing to do. I was after a way to explicitly subscribe to build failures :-) === smb` is now known as smb === _salem is now known as salem_ [12:10] cjwatson: argh, xubuntu failed to build, sorry about that; I'll fix the seeds to drop gnome-codec-installer (same like ubuntu) [12:11] cjwatson: oh, seems you beat me to it, thanks [12:12] pitti: yep, already done, also ubuntustudio === MacSlow is now known as MacSlow|lunch === azeem_ is now known as azeem === dendro-afk is now known as dendrobates === MacSlow|lunch is now known as MacSlow === dendrobates is now known as dendro-afk === alkisg_kubuntu is now known as alkisg === zyga is now known as zyga-afk [13:38] slangasek: do you have old-powertop in a PPA somewhere? === ion_ is now known as ion [13:52] perl busted on amd64, my fault, I'm working on it as top priority === zyga-afk is now known as zyga === alkisg_kubuntu is now known as alkisg === dendro-afk is now known as dendrobates [14:45] mvo: ping [14:47] kirkland: pong [14:48] mvo: howdy! mtaylor just noticed a really nasty new behavior with apt-add-repository [14:48] bug 890708 [14:48] Launchpad bug 890708 in software-properties (Ubuntu) "add-apt-repository: confirmation question is a CLI UI regression, breaking scripts" [Undecided,New] https://launchpad.net/bugs/890708 [14:48] mvo: it appears to always require an interactive confirmation [14:48] mvo: it's breaking all automated scripts and utilities that test from a PPA [14:49] it seems that -y isn't silently ignored pre-oneiric. [14:49] mvo: is this just a benign regression, or some new behavior we're going to have to work around? [14:50] kirkland: hm, so it does check is sys.stdin.isatty() - in what env do the scripts run? [14:51] Daviey: indeed, the fact that the old scripts do not have it is pretty nasty [14:52] mvo: well that depends... juju runs in a tty env, i think :-( [14:52] kirkland: hey. I'm here === mordred_ is now known as mtaylor-xchat [14:53] mtaylor-xchat: howdy :-) [14:53] mtaylor-xchat: what env did you notice this in? juju? or something else? [14:53] * mtaylor-xchat punches smuxi [14:53] mvo: I think the following should be expected to work: [14:53] #!/bin/sh [14:53] add-apt-repository ppa:davewalker/ifupdown [14:53] :) [14:53] yes [14:53] that's kindof how I noticed it. [14:53] for instance: [14:53] http://www.yorba.org/shotwell/install/ [14:54] shows how to get the latest shotwell [14:54] if you cut and paste those commands as a sequence, it won't work (ok, bad example - there are $'s there) ... I could find another example though [14:55] mtaylor-xchat: well, I think its fine that it asks you in a interactive scenario, we do want to ensure that people have a vague idea what they are adding and that they thing about it. I do agree that in a script env this is bad though [14:56] mvo: it's the script env I'm most concerned about, tbh [14:56] mtaylor-xchat: but I personally find the interactive prompt quite intrusive and would love a systemic config way to disable it [14:57] wow. I'm bad with tab completion :) [14:57] mvo: I'm open to and will be happy with anything that solves Daviey's use-case above though :) [14:57] mvo: I suggested perhaps have an env variable to have the old behaviour? [14:58] ok, let me think about it for a second, if a env var works fine, then I'm happy to add it [14:59] mvo: I could live with env var ... I'd personally LOVE something in a config file that could be driven by debconf questions so it could be preseeded [15:00] mvo: and would be happy to help do some of that work if we could get it landed in updates [15:02] hm, help2man is unintallable on (my) precise (schroot) because of perl-base version mismatches? [15:02] liblocale-gettext-perl : PreDepends: perl-base (>= 5.14.2-3) but 5.12.4-6 is to be installed [15:04] hallyn: yes, working on it [15:04] I tried to avoid this but got something wrong [15:04] cjwatson, cool, thanks. just making sure i didn't mess something up [15:04] I bet you're on amd64? [15:04] yup [15:04] woudl it work on i386? [15:04] yes [15:05] cool, that might tide me over, thanks [15:05] although some other things might break, it's a big transition and it wasn't practical to stage it all [15:05] precise/amd64 will be very broken for about the next hour [15:07] cjwatson, thanks for the info [15:18] mtaylor-xchat: http://bazaar.launchpad.net/~ubuntu-core-dev/software-properties/oneiric/revision/729 <- this is what I can offer right away, let me ponder a bit about Daviey example, it would be ideal if the a-a-r would detect that its run inside a script [15:19] mvo: hah, linaro are disucssing the same issue right now, bug 886209 [15:19] Launchpad bug 886209 in LAVA Dispatcher ""Add apt repository" action broken on oneiric images" [High,Triaged] https://launchpad.net/bugs/886209 [15:28] mvo: awesome === yofel_ is now known as yofel [15:30] Daviey: :/ but their mvo: Well the mtaylor-xchat use-case is using the same script on pre-oneiric and oneiric, and it seems adding -y breaks pre-Oneiric [15:34] Daviey: yeah, so the force environment or < /dev/null will both fix the problem. I'm sorry for the trouble this change is causing, we did it because it seems like the recommended way in a lot of blogs and we want people to be aware what its doing [15:35] slangasek, Daviey: Updated patch for ifenslave, works great on my system here: http://paste.ubuntu.com/739257/ [15:35] mvo: Oh, don't be sorry - i thought it was a logical change. [15:35] so that should work even if some slaves don't come up or come up really late in the boot sequence [15:35] it also properly removes the bond interface when running ifdown (for some reason the older code didn't do that at all, basically leaving unused interfaces...) [15:36] stgraber: More stuff had to be migrated to the function fired earlier? [15:37] stgraber: TREllis would be happy to validate an SRU for Oneiric btw. [15:37] Daviey: nope, I actually moved a big chunk of code to a function that's called after enslavement [15:37] oh! [15:38] the old code expected all the slaves to be ready before setting up the master, we can't guarantee that with our event based system [15:38] so instead I moved that code to a function that's fired every time we add a slave [15:38] also, there was a race condition where slaves would be added before all the sysctl were done running on the master [15:39] caused by ifupdown not tracking "starting to configure" and "done configuring" separately [15:39] so I had to add a /run/network/ifenslave.* file for each bond, that I can check before trying to add a slave [15:39] (that "race condition" was basically happening every time I was booting my server here, with the kernel deciding to just block all the trafic on the bond :)) [15:40] stgraber: Is that a local server, or the one you were on yesterday? [15:40] local server [15:40] DELL 750 (dual intel gigabit) and a cisco switch with a 802.3ad setup [15:42] I'll just wait for slangasek to have a look and test in his VM setup (using some non-802.3ad bonding), if that works there too, I'll push to precise first, then look into SRUing for >= lucid (anything that uses the event-based interface setup jobs) [15:42] groovy [15:43] I was hoping ifstate would actually save the state of the interface, but apparently it's just storing the interface name as soon as it's done anything [15:43] so I had to implement an ugly "touch" to track when it's actually done configuring the interface... [16:04] jcastro: old-powertop is in a precise somewhere; powertop-1.13 [16:04] ta [16:04] Riddell, heyo. Would you mind processing precise NEW a bit? trying to fix some FTBFS that are waiting on packages (notably libbison-dev and python-scikits.statsmodels) [16:13] slangasek: hi [16:14] jelmer: heya [16:14] slangasek: I was wondering if you'd seen my comment on bug 890529 ? [16:14] Launchpad bug 890529 in bzr-svn (Ubuntu) "bzr crashed with AssertionError in add(): adding busy connection in pool" [Low,New] https://launchpad.net/bugs/890529 [16:14] jelmer: hmm, I replied, didn't I? [16:14] jelmer: it's an issue with the repository perms [16:14] so we just don't get a very friendly error message when that happens [16:14] slangasek: you adjusted the importance to low, but didn't reply to my comment with a traceback [16:15] slangasek: which is what I'm after mostly :) [16:15] jelmer: oh, well, I can provide the traceback if you still need that, I just thought "server perms screwed" would be sufficient :) [16:17] slangasek: if you can, that would be useful. I'm curious about the code path - we should already be handling permission dnied errors [16:20] jelmer: no traceback now, just an error message - posted to the bug [16:23] slangasek: thanks [16:30] slangasek: did you have a chance to look at the diff I posted earlier? [16:32] stgraber: not yet, sorry [16:32] it's still pre-coffee-AM here :) [16:33] hehe [16:35] mr_pouit: have you seen the xubuntu build failures? sessioninstaller now conflicts/replaces/provides gnome-codec-install, so gnome-codec-install will need unseeded [16:37] http://paste.ubuntu.com/739317/ build failure make sense to anyone ? [16:40] hm.. i guess we need a newer libc6 maybe for perl-base which provides perlapi. [16:42] smoser: that should be fixed once the archive mirrors [16:42] smoser: don't worry about the build failures, I'll fix them all up in bulk [16:42] slangasek,mr_pouit: I fixed that this morning [16:42] oh, not a live-build failure I won't ... [16:42] cjwatson, no problem. just wanted to let someone know if it was the first report. [16:42] it'll get sorted out once you sort out packages. [16:42] smoser: we're in the middle of the perl transition, see ubuntu-devel. I'll let you know once it's a bit further along for you [16:43] cjwatson, nightly will just keep trying and succeed at some point [16:43] :) [16:43] we don't need a newer libc6, that was my screwup while staging the first step of the transition [16:44] cjwatson: yep, I saw the change, thanks :) [16:52] ah, seems packages gradually get installable again, thanks cjwatson [16:52] * pitti re-retries pkgbinarymangler [16:57] has anyone seen this type of error when attempting to build a deb package? http://dpaste.com/656897/ [16:57] stokachu: See the file it points you to. [16:58] on reporting the bug? [16:59] infinity, ^ [16:59] stokachu: Yes. [16:59] ok i did that and it's not a common error with gcc [17:00] stokachu: Unless you feel the urge to diagnose and fix the segfault yourself, in which case, thanks. ;) [17:00] not exactly , didnt know if anyone has run into this issue before [17:01] stokachu: "this issue" is a segfault in the compiler. There are many. [17:01] ok so no you haven't run into this issue [17:01] thanks [17:01] stokachu: On the other hand, you're using gcc-4.4, it may well be fixed in 4.6. [17:02] im building for 10.04 [17:02] stokachu: I run into GCC ICEs all the time. I don't know if I've seen yours. :P [17:02] stokachu: What you can do to perhaps work around your specific issue is try different optimisation levels (-O1 or -O0, assuming you were building with -O2 before) [17:03] ok ill try that [17:05] wgrant, hello! do you know where the source for the ftbfs page is? [17:05] vanhoof, im staring through your window, put some pants back on === beuno is now known as beuno-lunch [17:12] pitti: yeah, making decent progress now [17:15] bdmurray, can you look at bug 459730? i just had a user bug me about it [17:15] Launchpad bug 459730 in rsyslog (Ubuntu) "rsyslog doesn't create /dev/xconsole " [Undecided,Confirmed] https://launchpad.net/bugs/459730 [17:17] mterry: yes [17:17] bdmurray, thanks! [17:20] mterry, does someone actually want xconsole entry ? [17:20] or are they just annoyed at the warning [17:21] smoser, they seem to actually want it? [17:21] speaking about rsyslog: https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/841085 [17:21] Launchpad bug 841085 in gnome-utils (Ubuntu Precise) "log viewer lists not log by default (incompatible with rsyslog)" [High,Triaged] [17:21] if anyone feels like working on that ;-) [17:21] seb128, if it builds, I don't care about it this month ;) [17:22] seb128, find a way to break the build such that I'd have to display the logs to fix it [17:22] mterry, I can break the build for you if that helps :p [17:22] ok [17:22] mterry, yes sir! ;-) [17:22] seb128, this team isn't having the effect we'd hoped ;) [17:22] hehe [17:22] mterry, you exercice other people creativity toward bug fixing, that's good as well ;-) [17:23] mterry, I've a new theory "given time any bug can be turned into a build issue", I need to verify if it's true ;-) [17:24] hehe [17:24] stokachu: :) [17:25] I've noticed a problem on the packages.ubuntu.com site. Someone on #ubuntu-website suggested I ask here. The problem is that package descriptions are not provided for the Oneiric (or Precise) packages. For instance, compare http://packages.ubuntu.com/oneiric/coreutils against http://packages.ubuntu.com/natty/coreutils and the omission is immediately obvious. [17:26] gmargo: yes, this is because we now ship package descriptions in separate files on the server; please see the contact link on packages.ubuntu.com [17:27] (I don't know if this has been reported to the maintainer of that site yet at all; I know the issue is being discussed for packages.debian.org) [17:29] I have tried to contact frank@lichtenheld.de (listed address on packages.ubuntu.com) a few weeks back but no reply. And I don't know about packaging the descriptions - it just simply doesn't make any sense to _not_ describe a package on that package's page. [17:31] gmargo: yes, it's a bug not by design [17:31] contact> good to know; let me see what I can figure out [17:34] is the perl brokenness in P fixed up now? [17:35] dobey: it's going to take some time before it's fully fixed, because it's a rolling rebuild [17:35] it's fixed to the point that the autobuilders can continue making progress, at least [17:36] slangasek: ok; i uploaded an ubuntuone-client this morning, apparently right as it broke, and it failed to build. was wondering if i could tell it to rebuild, but i don't see how to do that on LP [17:36] there's also the ubuntu-build utility in ubuntu-dev-tools [17:36] I presume there'll be a mass-giveback for packages having ftbfs during the critical window, but let me have a look [17:37] micahg: what's that? [17:37] you can give back builds with it [17:37] micahg: presumably only if you also have access to do so from the website, dunno if dobey has that and if that's why he's not seeing the button [17:37] well, it should work as long as you can upload it [17:37] if it doesn't, that's a bug [17:38] dobey: intltool is known to still be broken AIUI [17:38] same for th eretry button [17:38] *retry [17:38] slangasek: ah, ok [17:38] though I've entirely lost the reference to this [17:38] micahg: i don't have the retry button; i also have issues with edit buttons not appearing next to upstream series links on packages [17:38] ah no, found now [17:38] dobey: you don't have the retry button here? https://launchpad.net/ubuntu/+source/ubuntuone-client/2.0.0-0ubuntu3/+build/2927706 [17:39] dobey: but you do have upload rights? [17:39] yes [17:39] dobey: bug in launchpad, please file [17:39] oh [17:39] on each arch there is a retry button [17:39] ah, yes :) [17:40] right, since each arch is a separate build [17:40] there isn't one to rebuild on all archs though :( [17:40] dobey: ubuntu-build from ubuntu-dev-tools :) [17:40] micahg: ok, i'll try that [17:40] but i guess i still have to wait for intltool to be fixed [17:40] dobey: oh, it looks like intltool is fixed now after all, so I think you should go ahead and give them back for building [17:40] oh ok [17:41] (tested in a chroot, apt says I can install intltool+perl; that cjwatson works fast) [17:42] ok, so what bloated my /usr by 200MB in the last week in precise? [17:42] probably something that's not good for the CDs [17:43] you didn't install the webkit debug lib did you? :) [17:43] pitti: ^^ do you happen to know of any major package size increases? I did see some printing-related package upgrades in the run that ate the space [17:44] cups, ghostscript, PPD updates [17:45] dobey: webkit debug> heh, certainly not === bregma_ is now known as bregma === beuno-lunch is now known as beuno === Quintasan_ is now known as Quintasan [18:21] yay, u1client built [18:24] slangasek: can you accept ubuntuone-client into oneiric-proposed? :) [18:28] dobey: I will be doing mass-retries once I get far enough, yes [18:29] cjwatson: ubuntuone-client is built successfully in precise now. i already retried it. but thanks, and thanks for fixing the breakage :) [18:33] dobey: looking [18:34] dobey: no, not possible, you need a different version number for the upload to oneiric-proposed than was used for precise; rejecting instead [18:34] slangasek: oh really? [18:34] dobey: please reupload as ubuntuone-client 2.0.0-0ubuntu2.1 === deryck is now known as deryck[lunch] [18:34] yes, each upload accepted into the archive has to have a unique version number [18:34] bugger. ok, 2.1 it is [18:36] slangasek: 2.1 uploaded [18:36] ok [18:39] bryceh, doko: surely someone else can reproduce bug #863761 without me having to use my primary laptop for it? ;) From what I can see, it should be reproducible on any system with a sufficiently recent processor and an intel graphics chip [18:39] Launchpad bug 863761 in eglibc (Ubuntu) "X crashed with SIGBUS in __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:820" [High,Confirmed] https://launchpad.net/bugs/863761 [18:43] slangasek: so, I was looking at but 440179 .. and thinking that there is a simple solutoin. [18:43] solution even [18:44] SpamapS: if we want the semantics of 'service $foo restart' to be the same as 'invoke-rc.d $foo restart' wrt job start/stop, I'm ok with that [18:45] though it seems low priority to me, since 'service' is a user interface rather than a programmatic one [18:45] slangasek: I think that would help quiet a lot of the "WTF" we see from automated systems. [18:45] and users can well do "service $foo stop; service $foo start" [18:45] slangasek: that was going to be my next question. Should we be making 'invoke-rc.d' the recommended automation tool? [18:46] slangasek: many users seem unsatisfied with the "just use stop ; start" answer. [18:46] which has been my default as well [18:46] there are times when invoke-rc.d should be used and times that it shouldn't [18:46] so [18:46] we need to have one place to recommend that an automated system use [18:46] /etc/init.d/xxx was that place before [18:47] I think you need to clarify what you mean by "automated system" [18:47] maintainer scripts are automated; they must use invoke-rc.d [18:47] puppet, chef, cfengine, my wonky bash scripts [18:47] AFAIK; invoke-rc.d blocks scripts from being run in the chroot, the others don't [18:47] /etc/logrotate.d is automated, and must not use invoke-rc.d [18:47] juliank: invoke-rc.d doesn't block chroot execution unless you've set it up to do so [18:48] slangasek: Yes, you can set it up like this. You can't do the same for the rest, right? [18:48] standard chroot setup should involve creating /usr/sbin/policy-rc.d that returns 101, and diverting initctl and start-stop-daemon [18:48] there's no reason you can't reroute all of these interfaces [18:48] can we ignore chroots for now? [18:48] but in general there's nothing running in your chroot that will try to use any of them besides invoke-rc.d *anyway*, so that's sufficient [18:49] SpamapS: definitely [18:49] There was a time where puppet could reliably expect that a service named "foo" would be controlled only by /etc/init.d/foo [18:49] slangasek: With "can" I mean in normal cases. You can obviously do it, but that's not the expected way to do it. [18:50] yes it is ;) [18:50] And in turn, that /etc/init.d/foo restart would lead to a service that had just been started (whether by stop/start or by just failing to stop, then starting) [18:50] That is still true for anything carrying the /etc/init.d/foo symlink to upstart-job [18:50] others expectations may be flawed in various ways, but if you expect services to be guaranteed not to start in your chroot, you should touch all three of those points [18:51] I had hoped that the service command would be suitable as a place to focus all future service control around.. automated or user-driven. [18:51] With the exception of maintainer scripts which are special. [18:51] SpamapS: I think it's right to make /etc/init.d an implementation detail and move this up to the 'service' abstraction [18:52] SpamapS: so please go ahead :) [18:52] alright, cool. :) [18:52] I think I'll do some man page tweaking too. [18:52] service runs a System V init script in as predictable environment as possible, removing most envi‐ [18:52] thats not exactly true. :) [18:55] how does a deb package build without placing any files in the packages even though they were defined in their respective install files? [18:55] slangasek: assuming we'll skip the merges with Debian for now since they're all related to kfreebsd? [18:55] so it sees the files or it would've errored saying so [18:57] doko, mind if I grab ocaml merge? [19:06] slangasek, I'll give it a try once I get a couple of my intel systems on precise. got a few other things to take care of first [19:17] SpamapS: merges of what? sysvinit? [19:17] SpamapS: I'm deferring sysvinit merges until I finish my own NMU of it (upstart support in Debian) [19:17] SpamapS: you're still on point for the lvm merge, right? [19:17] bryceh: ok, no hurry from my side :) [19:29] slangasek: yes, still assigned. :) [19:31] SpamapS: ok. I'm sitting on my hands, but would really like a version of lvm that doesn't complain about /proc/misc on every invocation :) [19:35] slangasek: I'll push the lvm merge up a bit on the stack then. :) [19:35] ta :) === deryck[lunch] is now known as deryck === dendrobates is now known as dendro-afk [20:31] cjwatson, pitti, it seems that some of our kernel binaries are in universe again, at least 2.6.38-13.52 for amd64 and i386 [20:37] apw: should all the binaries from that version (all flavors, all archs) go to main? [20:37] if you don't know, I can work it out [20:38] slangasek, from linux yes all are the same currently [20:38] apw: fixing [20:39] slangasek, i am a little confused as i thought rmadison listed /universe aginst things in the wrong place, yet they are in the wrong place in the pool === dendro-afk is now known as dendrobates [20:39] apw: I can't speak to rmadison's behavior here [20:41] rmadison will reflect what's in dists/ [20:41] (by definition; that's its data source) [20:41]