=== Ursinha-afk is now known as Ursinha [03:41] slangasek: Drat. Remember when I said your mountall magicall fixes my "/tmp not ready yet" bug? [03:41] slangasek: I must have just had a few lucky reboots in a row, cause it's back. [03:42] slangasek: Which indicates it's a race of some sort, but I'm not sure why there's a race to find a filesystem for something without a mountpoint in the first place. :P [04:27] infinity: very good question === jk-- is now known as jk- [04:58] Hello [04:58] I need confirm new distro template to apt-add-repository [04:59] I changed lsb_release [05:25] Good morning [06:23] pitti: Could you help to review https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595 ? Thanks. [06:24] FourDollars: yes, can do today [06:24] pitti: Thanks. [06:24] pitti: Could you also help https://bugs.launchpad.net/precise-backports/+bug/1076901 ? [06:24] Launchpad bug 1076901 in Precise Backports "Please backport ubuntu-online-tour 0.11-0ubuntu4 (universe) from raring to precise" [Undecided,New] [06:25] I'm not a backporter, sorry [06:27] pitti: Do you know who can help or what should I do next? [06:27] AFAIUI the backporter team regularly reviews pending requests [06:29] pitti: I see. Thanks. [06:50] hey, can anyone reject https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 please? [06:51] didrocks: fini [06:51] pitti: thanks :) [07:39] jibel: so, cjwatson and I didn't talk about britney integration of adt yet; however, I spent quite some time to fix two handfuls of failing adt tests [07:47] pitti, ok. I thought about it last week, and I think I'll have to split the job that triggers the tests in 2 parts, one part which identifies packages to test and the other part will deal with jenkins. [07:47] good morning [07:48] pitti, this way, britney can start the jobs without any dependency on lab's specific bits, and will know which tests have been started. === smb` is now known as smb [08:50] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti === jk__ is now known as jk- [09:07] Isn't there a ubuntu sys admin channel here somehwere? [09:24] zequence: #canonical-sysadmins perhaps ? [09:40] $ bzr merge lp:~obounaim/ubuntu/raring/virtualbox/debian-merge [09:40] Unapplying quilt patches to prevent spurious conflicts [09:40] bzr: ERROR: Unable to unapply quilt patches for 'other' tree: rmdir: failed to remove `.pc/cve-2012-3221.patch': No such file or directory [09:40] Unspecified vulnerability in the Oracle VM Virtual Box component in Oracle Virtualization 3.2, 4.0, and 4.1 allows local users to affect availability via unknown vectors related to VirtualBox Core. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3221) [09:40] did anyone happen to run into this before and knows how to fix/workaround? [09:42] pitti: yes. [09:43] do i recall correctly that build essential in raring is now 'correct' that we have less extraneous things in the chroots by default [09:43] pitti: in the ~/.bazaar/builddeb.conf set "quilt-smart-merge=False" [09:43] pitti: and then unapply patches yourself in the old branch & the new branch. Commit in both, then merge. [09:43] pitti: re-push quilt series. [09:44] what could be easier... [09:44] so I need to check out two full virtualbox branches, fun [09:44] probably the package is in 1.0 source package and builddeb got it wrong..... [09:44] * pitti screws it, downloads the diff, applies manually and lets the package importer sort it out [09:44] pitti: bzr init-repo virtualbox; cd virtualbox [09:44] win 23 [09:45] then it's only half the download =) [09:45] pitti: i tend to always upload and let the package importer sort it out. But I do use bzr for auto-merging most of the stuff for me. [09:45] xnox: pre-applied patches and I have a deep hate for each other [09:46] heh [09:46] I yet have to find a person who gets along with those without sacrificing chicken and screwing it up from time to time [09:49] I do :) [09:49] Not that I think the importer's approach is ideal, but [09:52] doko_: the reason for python-imaging and python-reportlab is hplip [09:53] on the cd, that is. [10:14] cjwatson, i think you were working with benc on linux-ppc, i see it ftbfs and (if you arn't already) was planning on trying to fix that to release linux [10:15] apw: I was just processing it through the archive [10:15] apw: Be my guest, though I see he has his own git branch for it [10:15] lifeless: That's the one. Thanks [10:16] cjwatson, i have his branch indeed, will use that as a base and send it back to him === mcclurmc is now known as mcclurmc_away [11:08] . o O { sponsoring merges as Ubuntu MPs is about as far away from "fun and efficient" as it could be } [11:08] Sponsoring merges is hopeless [11:09] One of the reasons I discourage people from doing that until they can upload directly [11:09] a nice and clean "current debian - merged ubuntu" debdiff attached to a bug is fine IMHO [11:09] but hopping through all that "checkout ubuntu, merge, fight with teh quilt patches, etc." until you get to that debdiff is a pain [11:13] huh?! if you are sponsoring you checkout the sponsoree branch and diff against the tags within that branch. [11:14] unless it's a horrible mess with forgotten $ bzr add .pc [11:14] xnox: ah, I guess you could do that if you don't push it back to the official branch anyway [11:15] pitti: yeap. and you can do $ bzr bd -S to get a source package out of the sponsoree branch. If that doesn't work, throw it back. [11:15] pitti, I found the launchpad diff mostly useful for those, it's the ubuntu->ubuntu diff basically, so you see "ok, few revisions from debian added, looks good" [11:16] and there you have your source package with the pristine-tarball regenerated. [11:16] you just need to filter you the quilt noise when debian added new patches [11:16] seb128: yeah, but I do want to verify the d->u debdiff, as that's the one which we should minimize [11:16] pitti: $ bzr diff -rtag:1.0-2 [11:16] pitti, then you are going over sponsoring in fixing it yourself mode ;-) [11:16] xnox: right, thanks [11:16] pitti, well I usually read the changelog summary to see the diff [11:17] "diff", e.g what changes we carry [11:17] seb128: not necessarily fixing, but I don't want to sponsor merges which have obsolete stuff in them [11:17] right, I found that the changelog was enough to check the changesets and their validity usually [11:17] but maybe I check less into details than you do [11:18] pitti: clean debdiff> It depends what you're checking. That's still a royal pain if the merge is at all complex and you're trying to check whether the merged debdiff actually matches what used to be in the Ubuntu delta [11:18] pitti: I've had too many instances of well-intentioned newcomers dropping patches they don't understand to skip that kind of verification, and it ends up being significantly more work than doing the merge myself [11:19] cjwatson: I look at both, but the more interesting one is the d->u one for me usually [11:20] so I guess I go with xnox's approach to only checkout the proposed branch, check the diffs against the tags, and never push it back [11:20] did that with one branch now, and it's a lot easier indeed [11:23] pitti, what tag do you check against? the vcs from contributor doesn't have the current debian versions right? e.g no way to do "current debian to proposed update" from the vcs? [11:23] well. to address cjwatson's concern and pitti's usability I do this. Checkout proposed branch. generate the new d->u diff and u->u diff. But also pull the old d->u diff (with pull-lp/debian-source & debdiff). and then review old d->u & new d->u. [11:23] seb128: they do have the current Debian version [11:23] seb128: I guess because the creator of the branch actually used "bzr merge lp:debian/foo" [11:23] that imports all the tags etc. [11:24] oh ok, nice [11:24] quite some don't [11:24] with the last step, I catch a few "overzealous" preservations: double application of the same patch due to fuzz, and keeping the changelog entries for "actually merged in debian long time ago". [11:24] seb128: if there is no debian tag, throw the branch a way. It was not a bzr merge, I will not trust it. [11:24] seb128: e. g. I check out lp:~logan/ubuntu/raring/desktop-base/debian-merge, and "bzr diff -r tag:7.0.0ubuntu2" gives me u→ u, and "bzr diff -r tag:7.0.3" gives me d→ u [11:25] pitti, xnox: nice tip, thanks [11:25] (e.g. if the importer is lagging, atleast bzr import-dsc should have been done) [11:25] why do you need to pull-*-source if you have the old tags in vcs too? [11:25] I usually end up dgetting the ubuntu and debian versions and doing debdiffs locally [11:25] that's what I did before, and download the diff from the MP, clean it, and apply it locally [11:25] when the merge is not trivial, when it's trivial (like most of those from "logan" I usually can ack it from the launchpad diff) [11:26] seb128: dgetting or pull-[lp|debian]-source $pkg [version|release] ? =) [11:26] (clean: throw away the "applied patches" portions) === _salem is now known as salem_ [11:26] xnox: I'm too old school, dunno about those pull tools :p [11:26] * seb128 notes to try those [11:26] I also do ` | filterdiff -x '*.pc*' [11:27] pitti, oh, I usually bzr branch the vcs from the submitter and bzr bd --source it [11:27] pitti, then work from the source package, dput that [11:27] seb128: yeah, that's what xnox told me as well; I initially tried "bzr merge" and tried to push that back, but that's too brittle [11:27] take from the discussion: everybody is working using a different workflow [11:28] pitti: the problem with $ bzr merge, is that it always try to do "merge from debian" e.g. auto-unappy quilt patches. Which doesn't make sence when merging a proposed to-be-sponsored branch. [11:29] pitti: with those, if they are actually clean. I push them to lp:ubuntu/$pkg. Or do pull/merge with quilt-automerging turned off. === mcclurmc_away is now known as mcclurmc [11:32] seb128: Heh, even as an old-schooler, pull-{lp,debian}-source are the best things ever [11:33] cjwatson, no doubt, I just didn't know about them ;-) [11:34] too many scripts and I don't keep up with everything which is available there [11:34] seems like I should ;-) [11:34] +1 on pull-*-source [11:34] generally, if the utility is shipped in ubuntu-dev-tools it generally means that "all of your aliases and scripts suck compared to this shiny command line toy" [11:35] Heh [11:36] I go through dpkg -L ubuntu-dev-tools every 6 months or so, and so far it never failed to surprise me with at least one new cool thing :) [11:36] xnox: or it's too ugly for ubuntu-dev-tools ;) [11:39] pitti: what's the rationale for autopkgtest/dep8 to treat a zero exit status but output to stderr as a failure? Eg. wget prints progress to stderr, so script that calls wget is treated as a failure by default. I guess we could wrap it, but is there a more general answer? [11:39] rbasak: currently implementation. [11:40] as in, that's what the currently implementation does from historic reasons dating back to 2007 [11:40] rbasak: I'm not quite sure TBH; it's nice to detect new warnings that weren't there before, but of course it's a bit pointless if your tests are expecting to write stuff to stderr [11:40] e.g. for desktop apps, launching and having output on stderr is bad, means some errors are present. [11:41] How about a "writes-stderr" "restriction"? [11:41] rbasak: for Python unitest I usually use "unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, verbosity=2))" [11:41] to fix python's unfortunate default of writing the regular output to stderr [11:41] Or wrap in a script that does 2>/dev/null if you know you never care [11:41] yeah, a lot of tests do that, too [11:42] The thing is if the test does fail, then the output that went to stderr may be useful [11:42] rbasak: writes-stderr> not sure whether upstream likes that, but seems fine to me [11:42] rbasak: oh, we do keep that; if stderr is nonempty, you see it as an artifact in jenkins [11:42] Yes, but if the workaround is to >/dev/null, then it won't be :) [11:43] rbasak: 2>&1 is better really [11:43] stderrfile="$(mktemp)"; cleanup () { rm -f "$stderrfile"; } trap cleanup EXIT HUP INT QUIT TERM; run-tests 2>"$stderrfile" || cat "$stderrfile" >&2 [11:43] wget has --quiet option [11:43] Or something [11:43] But yeah, it's often less effort to silence the spurious errors in the first place ... [11:43] xnox: yes, but the script that we're calling doesn't (currently) have a --quiet option, so it won't pass through to wget. We're not testing wget - we're testing a script that calls wget [11:43] if I get along with fixing the output fd of unittest, I usually prefer that; for others, debian/tests/foo doing 2>&1 seems the next best approach [11:43] rbasak: I see. ok. [11:44] cjwatson: that's exactly what I'm suggesting that a "writes-stderr" restriction might do :) [11:45] I did patch guilt package test-suite to be sensitive on $ADTTMP, which means roughly - we are in autopkgtest environment, use system install, don't do silly things on stderr, but do fail on stderr. [11:47] OK, thanks all === salem_ is now known as _salem === _salem is now known as salem_ [12:02] thinking about the hash-sum missmatch from apt (which I just had on my laptop) - shouldn't apt be smart about those & requeue and try updating that repo again (with custom delta-t & #-retries) before giving up? [12:04] It's pretty awkward to fix that within apt [12:04] I'm hoping to fix it for good with the by-hash stuff this cycle === cpg is now known as cpg|away [12:08] rbasak: explain why it's awkward to fix that within apt? does it return a different error code on hash-sum missmatch? if it does a wrapper script around apt-get update installed with dpkg-divert, which loops around apt-get update should do it. [12:09] rbasak: although by-hash stuff is nice, I feel cautious that not all mirrors will support it any time soon. [12:09] xnox: inside apt, the code that manages the downloads is extremely twisted and laden with more tech debt than any other project I've ever seen [12:10] 8) ok.... scary [12:10] xnox: an outside wrapper would definitely be far easier. I'm not sure if apt returns a unique return code, but that probably wouldn't be too hard to do (or to parse the stderr) [12:10] parse the stderr sounds dirty =)) but why not ;-) [12:11] Yeah mirrors might take a while to pick it up. Including our own. But the nice thing is that if you care you can implement your own by-hash mirror without upstream support :) [12:11] (admittedly that still doesn't solve the problem in the general case) === Tonio_ is now known as Tonio_aw === attente_zzz is now known as attente [12:25] rbasak: where/how are the cloud images generated? I'd like to tinker with a few settings to improve performance and reduce size those. [12:25] xnox: utlemming and smoser manage those [12:25] rbasak: thanks. [12:26] I think the scripts that generate them are in LP somewhere [12:26] * xnox wishes lp had "show all activity bzr/revisions/pushes for a person", cause I bet the branch has team owner. === MacSlow is now known as MacSlow|lunch [12:34] rbasak: https://code.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds [12:34] looks about right?! it's referenced in the build-logs of the cloud-images available for download. [12:34] xnox: seems likely. smoser can confirm when he comes online [12:35] rbasak: yeap, it is right. Referenced in https://help.ubuntu.com/community/UEC/Images === Tonio_aw is now known as Tonio_ === MacSlow|lunch is now known as MacSlow [13:40] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [13:58] xnox, that is not correct any more. unfortunately that document is out of date. [13:59] https://wiki.ubuntu.com/UbuntuCloud/Images/Publishing is *better*, but still out of date. [13:59] smoser: hm.. ok. where is _the_ source? [14:00] well, that url above references just about everything except for reference to live-build branch that we use [14:00] lp:~ubuntu-on-ec2/live-build/cloud-images [14:01] ok... [14:01] thanks [14:01] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/misc/ec2-build-on-ec2 does much of it. [14:01] what were you looking to fix/change? [14:01] default apt & dpkg settings. [14:02] as in? [14:02] maybe it should be in cloud-init instead, I am not sure. [14:02] do not download description translations, disable i386 multiarch on amd64 images. [14:02] possibly set lang to C and purge all translations. [14:03] unless all of this is already done on the recent images. [14:03] cut's down apt-get update time by more than a half. [14:03] weell.. [14:03] maybe, not the lang bit =) [14:04] - translations: i dont know enough about how they work to decide if its ok or not. i'm not opposed to it, but it would be a regression for some users i'm sure (being uncultured american, it "works for me") [14:04] well the fact is that currently you are downloading normal package list & then the en_US translation of the same package list. [14:04] why dont run the cloud builds oem-config on first login ? [14:05] doubling your package list. [14:05] ogra_: no oem-config. ever on cloud. [14:05] xnox, right, but why ? [14:05] ogra_: we don't want to manually configure 100 instances I spin up for my haddoop. ever. [14:05] oh, just have a default preseed [14:05] - i386 on amd64 images: i think i've actually tried to do this unsuccessfully. in the maas ephemeral image (http://bazaar.launchpad.net/~smoser/maas/maas.ubuntu.com.images-ephemeral/view/head:/maas-cloudimg2ephemeral line 251) [14:06] only if you dont use that preseed you can manually configure [14:06] ogra_: well, think of cloud images more as if they are pre-installed for automated usage. [14:06] yes, i do [14:06] ogra_, cloud-init does what you want it to do. [14:06] ogra_: there is cloud-init which allows you to change settings on first boot. [14:06] You don't download a separate package list for translations, only files containing the different descriptions. [14:06] (point of information) [14:06] well, oem-config uses a statndardized way also the installer uses so you get changes automatically [14:07] - setting lang to C: i'm probably not opposed to that, setting it as a default. cloud-init will change it to en_US on first boot though. [14:07] unless we also change that. [14:08] cjwatson, the translation downloads are annoying, though if not needed. especially with S3 mirrors, where the serial small file requests are quite painful. [14:09] cjwatson: true. but it's a lot of queries to see if they are updated for each component/pocket, isn't it? plus they are useless waste on auto-spinned up instances... [14:09] I don't really care either way. I was just taking issue with the description. [14:09] rbasak, was/is going to make apt able to do parallel there, which will allow us to blast S3 very unfriendly-like. [14:09] smoser: that a separate thing that I hope to do this cycle to. apt happens to have the logic in there that should make this change easy [14:10] that's a separate thing that I hope to do this cycle too. [14:10] i hope so too [14:10] :) [14:10] * rbasak learns to speak English [14:11] for the reader, each http connection to S3 has a large overhead (on the S3 side). as a result, the average download time across some large get like 'apt-get --download-only install ubuntu-desktop' tops out at like 8M/s (maybe 12). [14:11] but if we parallelize that (with apt-fast), we can saturate a gigabit link. [14:12] and if S3 doesn't stand up, thats their fault. (especially since amazon explicitly told us that S3 was not designed for lots of little files like apt is doing... after they told us to put mirrors in S3 and ignored my complaints about speed). [14:13] (and for the record pipelining there has just about zero affect) [14:13] xnox, so in general, i'm not opposed to any of your changes, but i'm careful in all changes. [14:15] smoser: I understand. I want to play around with these settings and see if I can still generate images and launch them & check the performance differences. [14:15] speed of 'apt-get update' is a pretty important thing in my opinion [14:16] and i'd love for the images to not use i386 on amd64. [14:18] ack. [14:20] ogra_, fwiw, you can feed debconf preseed to cloud-init just like you would the installer. [14:21] cloud-init does not recondifgure anything alreadyy installed (arguably a bug), but new packages installed would then get those preseeds. [14:21] does it use the udebs ? [14:21] no =))))) [14:21] link ubiquity/oem-config does [14:21] aha [14:21] that was actually my point :) [14:22] so you dont have to re-implement all these bits all the time when something changes [14:22] i'm probably just being ignorant, but i have no idea why i would want to use udebs. [14:22] example of change? [14:22] the sudo group [14:23] hmm... oem-config is meant to be run with tty, where as cloud-init is always unattended. [14:23] the point is, by using the udebs you dont have to care for the backend stuff at all, whatever the distro changes will happen there and you just inherit [14:24] not sure it would be wise to mix the two. [14:24] i'm not opposed to getting "free stuff" [14:24] oem-config runs fine on serial tty's etc and you can preseed it as well as you can any other bit [14:24] in which case it wont need a tty [14:24] amazon cloud does not give you serial tty =) [14:25] well, you dont need one if you prseed [14:25] but if you can have one and dont preseed you would get a proper fist login configuration [14:25] and everything for free without having to poke at backend code ;) [14:26] anyway, just wondering ... its not my work area :) [14:26] i'm not opposed to it in principle, but not convinced of the merrit. the sudo group change sucked, but generally we have very few such things "baked in". [14:26] ogra_: well.. the "first login" is the problem that cloud-init solves. By default you can't login into ec2 image. You have ssh, but then your ssh key needs to be in the user-account pre-setup. [14:27] xnox, right, but where doies the functionality of cloud-init differ from what a reseeded oem-config does ? [14:27] and clound-init does that funny grub booting as well. [14:27] i dont think it does [14:27] (differ i mean) ... [14:30] the way the first user is done and the hostname is different, and apart from locale choice nothing else is common between the two. [14:30] can someone please have a look at #1077938, please? maybe that's something for an SRU, too. [14:31] such that, sure cloud-init can use oem-config, but it would still require to calculate all the values & preseed them to the oem-config which then hopefully will succeed in setting them. [14:31] it already does the calculation bit, and simply sets them straight away, instead of generating pressed & feeding it to the oem-config. [14:31] so oem-config would be an extra (un-necessary) layer. [14:33] well, it seems just like a lot less work to rely on oem-config/ubiquity/d-i [14:33] (which are the same backend wise) [14:34] but d-i is not used at all on cloud images. [14:34] so why _add_ it? [14:34] ? [14:34] i didnt say you shoudl add d-i [14:34] just that the backend functions of d-i and oem-config or ubiquity are identical [14:35] its all coming out of the same usebs, so you would get distro code changes for free [14:35] instead of chacing a rabbit and trying to keep up with what the distro does [14:35] less error potential [14:36] *chasing [14:36] i am not aware of any distro changes that are being chased. [14:36] well, bits like dropping groups from the default set and the matching transitions for example [14:38] smoser: did ^^^^ need manual intervention on cloud-init side to handle? [14:39] to be consistent you simply need to know exactly what changed in distro plumbing to have it in your code as well [14:40] we were affected (and had to realize) the sudo group. it didn't really affect anything though. [14:40] but there is very little *distro plumbing* baked in to the images, and anything that is, is probably specifically done with intent. [14:40] the group thing sucked. but creation of that default user is now moved to cloud-init. [14:40] the images themselves actually have no local user now. [14:40] smoser: none of which is needed nor wanted in the oem-config. [14:41] smoser: ok. that's what I was thinking that if $ adduser is used, no need to hard-code the default groups..... === dmart_ is now known as dmart [14:41] xnox, well, its configurable. it has a default list [14:42] and the default groups come from the deboostrap [14:42] hmm.. [14:43] i dont really remember. we did (and do) have a hard coded list of groups that the default user is present in. and we were making the 'sudo' group. [14:43] i forget. [14:47] ogra_: maybe there is point to dig into cloud-init and see how much stuff can be refactored. [14:47] xnox, well, i'm not really after oem-config in cloud setups ... but more after the functionality that ubiquity uses to make use of the udebs [14:47] i.e. if you look at the user-setup udeb you wil find it dfoes a lot more than just aclling adduser [14:48] *calling [14:48] or rather user-setup-allpy which does the actual user creation [14:48] *apply [14:52] jodh: hey James, how are you? [14:52] pitti: good thanks - you? [14:52] jodh: fine, thanks! [14:53] jodh: you said in bug 1075976 that eatmydata was a red herring, so do you still need the --no-eat option? [14:53] Launchpad bug 1075976 in upstart (Ubuntu) "test-suite fails in autopkgtest environment" [Undecided,New] https://launchpad.net/bugs/1075976 [14:53] xnox, wrt default groups ... http://paste.ubuntu.com/1353260/ [14:53] jodh: I'll take the typo fixes in any case of course, thanks! [14:53] ogra_: well on cloud, we have: ubuntu:ubuntu with password ubuntu, no auto-login, no encryption, system groups + inject ssh key fingerprint into ~/.ssh/authorized_keys. [14:53] pitti: I think not, so feel free to ignore that MP (sorry - forgot to cancel it) [14:53] jodh: I like "Lauchpach"! [14:54] xnox, right, does printing work ? :) [14:54] pitti: :) [14:54] jodh: I'll use it for the typos then; thanks! [14:54] pitti: thanks! [14:54] ogra_: the bits about the groups, yes are correct. but creating lpadmin & sambashare is very "desktop" like [14:54] ogra_: and these are done by those packages anyway. [14:54] xnox, right, but the udeb would inherit that stuff even from debian, you would have to care if i.e. debian decides to rename lpadmin to lpadmins [14:54] ogra_: so the only useful bit in the whole script (from cloud perspective) is the passwd/user-default-groups [14:55] -*wouldnt [14:55] which notice, it does not create the user-default-groups first (unless I missed something) [14:55] xnox, i'm talking about maintenance overheard [14:55] someone would have to knwo debian renamed the group [14:55] and would have to change the cloud-init code manually for it [14:55] instead of just inheriting the change [14:55] the maintainence overhead of keeping the rest of the script working in the cloud image, which doesn't have apt-install and the rest of it. [14:56] is what I think will be more. [14:56] k [14:56] but we don't know for sure, unless we try =/ [14:57] Yeah, I think the duplication is justifiable in this case. [14:57] It doesn't seem worth all the effort of reengineering that, to me. [15:21] pitti, can you look at bug 1077938? [15:21] Launchpad bug 1077938 in ubuntu-release-upgrader (Ubuntu) "Can not upgrade to development release" [Undecided,New] https://launchpad.net/bugs/1077938 [15:23] toabctl: deferring to mvo, who is our upgrade master [15:23] pitti, thx === attente is now known as attente_zzz [15:56] bdrung: hey Benjamin, how are you? [15:56] bdrung: I have a question for you in bug 1073390 [15:56] Launchpad bug 1073390 in libarchive (Ubuntu) "libarchive-dev needs a compile/link/run test" [Undecided,Fix committed] https://launchpad.net/bugs/1073390 [16:12] xnox, any news for bug 1037588 ? [16:12] Launchpad bug 1037588 in icu (Ubuntu Raring) "Provide pkg-config pc files" [Wishlist,Triaged] https://launchpad.net/bugs/1037588 [16:14] toabctl: no news, it is ok for this be sponsored in debian-experimental + sync into raring, or upload into raring. [16:15] heck, it's one liner. can be done. [16:18] xnox, seems that the debian maintainer wants to wait until wheezy is released. so we can fix it in ubuntu. [16:18] right? [16:19] toabctl: or in experimental [16:20] OdyX, sure. === fisted_ is now known as fisted [17:01] pitti: ask. [17:17] hum, I managed to screw my apt/dpkg dunno how [17:17] $ LC_ALL=C sudo apt-get install linux-firmware [17:17] dpkg: error processing linux-firmware (--configure): [17:17] package linux-firmware is not ready for configuration [17:17] cannot configure (current status `half-installed') [17:17] [17:17] does anyone know how to get out of that state? [17:18] seb128: $ sudo dpkg --configure -a [17:18] ? [17:18] xnox, tried that, no luck [17:18] =( [17:18] that returns without doing anything [17:18] $ sudo apt-get install --reinstall linux-firmware [17:18] ? [17:18] find the .deb for linux-firmware, dpkg --unpack it, continue [17:19] xnox, oh, that worked, thanks! [17:19] (check disk space on the various partitions inbetween [17:19] OdyX, did that before ;-) [17:19] seb128: it's a slightly fancy way of doing what cjwatson suggested ;-) [17:19] OdyX, I stopped an upgrade my-unpacking by close the wrong win [17:19] xnox, cjwatson: thanks [17:23] apw: looks like that linux-ppc upload still fails? === attente_zzz is now known as attente [17:35] cjwatson, yeah benc is on the case === DNS` is now known as DNS [17:36] cjwatson, apw: Since it only takes me about 30 minutes, I'm doing a full binary-arch build to make sure this one works (my mistake for messing with d-i related things without testing that on the .3 upload) [17:37] * cjwatson nods [17:37] BenC, thanks === deryck is now known as deryck[lunch] === mcclurmc is now known as mcclurmc_away === pcarrier_ is now known as pcarrier [18:31] slangasek, the consensus seems to be we need to prompt the user with the written license statement when installing nexus7 wifi/bt firmware. Is something better than debconf note to do that? === deryck[lunch] is now known as deryck [18:57] chrisccoulson: got a moment? [18:58] chrisccoulson: I wanted to talk about ubufox [19:56] pitti, kees, stgraber, cjwatson, mdz: TB meeting in a couple of minutes, right? Wiki says 2000 UTC. [19:58] soren: ah yeah, dst change. I'll be there === cpg|away is now known as cpg [20:02] soren: available whenever anyone else shows up :) === attente is now known as attente_zzz === cpg is now known as cpg|away [20:46] janimo: if it's an after-install package install, a debconf note is the right way to do it [20:47] janimo: not a 'note' actually, but a debconf (boolean) question === cpg|away is now known as cpg [20:53] anyone know a good javascript CLI like OSX's "jsc"? [20:55] something doesn't feel right about that sentence [20:55] agreed [20:56] I guess it makes sense that at one point js replaces bash.. [20:56] I was just watching https://www.destroyallsoftware.com/talks/wat again and wanted to see the javascript bits myself [20:56] kees, nodejs? Not sure what you mean by good though :) [20:56] just stuff where I can type {} + [] and laugh [20:56] kees: I guess you've seen http://bellard.org/jslinux/ already :) [20:57] that one was so amusing and scary to run for the first time.. [20:57] highvoltage: heh yeah === salem_ is now known as _salem [21:00] bdrung: I asked on the bug [21:00] soren: here now [21:00] janimo: yeah, nodejs does the trick! [21:01] soren, kees, stgraber, cjwatson, mdz: but it's winter time again, so 2100 UTC? [21:01] I'm still at Taekwondo an hour before [21:01] pitti: not sure. I'm fine to move it later [21:01] 2100 UTC works fine for me too [21:02] perhaps we should define it as 21:00 London time [21:02] yay, my day is complete: [21:02] > Array(16).join("wat" - 1) + " Batman!" [21:02] 'NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman!' [21:03] kees: the WAT talk ? [21:03] kees: ah yes, classic [21:03] lifeless: yeah, I watch it every few weeks. I got curious about what I could use on Ubuntu that was like "jsc" on OSX [21:03] kees: question for you - the bug that the libguestfs FAQ points at about -r mode'd kernels [21:03] though it looks like v8 is less "fun"^W^Wmore consisten [21:03] t [21:04] kees: he claims you can read the live kernel, but I wanted to verify - that requires root already, right ? [21:04] yup [21:05] lifeless: if he's got a way to real kernel addresses on a default ubuntu install NOT as the root user, I would consider it a bug. [21:05] s/real/read/ [21:05] kees: I wonder if we should mark libguestfs as bad somehow then, since installing it lessens security. [21:06] / undoes your hard work [21:06] hrm? [21:07] kees: heh, people were criticizing that talk in CPH on the grounds that the examples don't work in nodejs [21:07] slangasek: haha [21:07] kees: installing it alters the settings you documented, making vmlinuz world readable [21:07] slangasek: it's clearly undefined behavior manifesting as humor. [21:07] lifeless: O_O [21:07] lifeless: bug #? [21:07]