| genii | Getting repeated W: Failed to fetch gzip:/var/lib/apt/lists/partial/ddebs.ubuntu.com_dists_saucy_main_binary-amd64_Packages Hash Sum mismatch all today. | 02:13 |
|---|---|---|
| * genii grabs a coffee and heads out again | 02:17 | |
| infinity | genii: Just tested that it works here. Broken transparent proxy in the way? | 02:17 |
| sarnold | d'oh.. | 02:17 |
| infinity | Tiiiiming. | 02:17 |
| sarnold | infinity: hrm, I just manually downloaded the Release, Release.gpg, and main/binary-amd64/Packages.gz file and I also get hash mis-matches. | 02:20 |
| infinity | sarnold: Curious that apt didn't complain at me... | 02:21 |
| sarnold | infinity: is there a better way to do this than hand or adding them to apt sources.list? (apt already takes long enough, hehe :) | 02:21 |
| infinity | sources.list and apt is the "better way". | 02:21 |
| sarnold | darn :) hehe | 02:22 |
| infinity | roaksoax: Want to make sure there's a bug subscriber for djorm-ext-pgarray, so I can promote it? | 02:23 |
| roaksoax | infinity: argh... i though someone had already subscribed maas-maintainers to it | 02:26 |
| roaksoax | let me check | 02:26 |
| roaksoax | infinity: it is already | 02:27 |
| infinity | Hrm, does that post-date mterry's comment? | 02:28 |
| infinity | Possibly. | 02:28 |
| infinity | Anyhow, cool. | 02:28 |
| infinity | Can you do the same for curtin too, so we don't have to ask later? :) | 02:28 |
| roaksoax | infinity: sure | 02:29 |
| sarnold | infinity: apt agrees with me: W: Failed to fetch gzip:/var/lib/apt/lists/partial/ddebs.ubuntu.com_dists_saucy_main_binary-amd64_Packages Hash Sum mismatch | 02:32 |
| infinity | sarnold: apt here disagreed with you. Weird. Let me try again. | 02:33 |
| sarnold | infinity: so hooray / darn :) -- no transparent proxy going on here, at least none that I know of. (comcast might be doing something silly of course but that seems unlikely) | 02:33 |
| sarnold | infinity: I -do- have apt-cacher-ng going, but the other 303 sources fetch just fine. | 02:34 |
| infinity | http://paste.ubuntu.com/6212028/ | 02:34 |
| sarnold | infinity: does the public key error mean the hash check won't be performed? | 02:35 |
| sarnold | infinity: or would apt report both in that case? | 02:35 |
| infinity | No, they should be performed regardless. | 02:35 |
| infinity | But I can import the key and try again. | 02:35 |
| infinity | sarnold: Huh. No, you're right. With the key added, it fails. | 02:38 |
| infinity | Oh, because my chroots don't ignore auth failures, so it ignores that entire Release file. | 02:39 |
| infinity | Silly me. | 02:39 |
| infinity | pitti: ddebs are all hashsum mismatchy, please fiz. | 02:39 |
| infinity | pitti: Or fix. | 02:39 |
| sarnold | infinity: I'm surprised apt didn't report "E: .." rather than "W: ".. | 02:41 |
| infinity | Indeed, that should be an E with strict checking, and a W without. | 02:42 |
| infinity | Though, at least the behaviour appears to be correct, just not the message. | 02:42 |
| sarnold | aha | 02:43 |
| sarnold | thanks :) | 02:43 |
| === statik_ is now known as statik | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === plars_ is now known as plars | ||
| === Maple__ is now known as Guest58172 | ||
| pitti | doko_: p-9.1> ah, that needs a dh_autoreconf? | 04:10 |
| pitti | infinity: erk, more of that? the ddeb-retriever is stuck anyway, I'll have a look | 04:17 |
| infinity | pitti: I'd go to --with autotools-dev for psql, personally, but up to you. | 04:18 |
| infinity | s/to/for/ | 04:18 |
| pitti | infinity: ah, I don't know; if that works, sure | 04:18 |
| pitti | it just needs to be backportable all the way to lucid | 04:19 |
| pitti | (and squeeze) | 04:19 |
| infinity | pitti: lucid? srsly? | 04:19 |
| pitti | yes | 04:19 |
| infinity | pitti: Then you might want to fake what dh_autootools-dev_* do and manually find-and-replace all config.{sub,guess} :P | 04:20 |
| infinity | Cause the dh commands definitely weren't there in lucid. | 04:20 |
| pitti | ack | 04:21 |
| infinity | pitti: (Or just ship config.{sub,guess} updates as a patch/diff, but then it doesn't magically work for the next new port) | 04:22 |
| pitti | infinity: I'll just ship a patch | 04:22 |
| infinity | pitti: Make sure you get 'em all, if there's more than one. | 04:22 |
| pitti | 9.3 has a newer config.{guess,sub}, and we'll get that from the next release on | 04:23 |
| pitti | just checked, there's just one | 04:23 |
| infinity | pitti: 9.3's might not be new enough still, depending on how new newer is. | 04:23 |
| infinity | pitti: (ppc64el was added quite recently) | 04:23 |
| pitti | timestamp='2013-04-24' | 04:23 |
| pitti | ppc64:Linux:*:*) | 04:24 |
| pitti | echo powerpc64-unknown-linux-gnu | 04:24 |
| pitti | that's not enough? | 04:24 |
| infinity | Nope. | 04:24 |
| infinity | That's big-endian. | 04:24 |
| pitti | ok, so I'll update both | 04:25 |
| pitti | infinity: is ppc64el something we'll (soon) care about in D/U? | 04:55 |
| infinity | pitti: Yep. | 04:56 |
| infinity | pitti: Debian for sure, Ubuntu possibly. | 04:56 |
| pitti | thanks (some fodder for the changelog) | 04:56 |
| infinity | pitti: I've just been using generig changelogs along the lines of "Do blah blah to config.sub" ... "to enable new ports." | 04:57 |
| infinity | pitti: Cause, well, if you do it in a fashion that automated at build time (instead of in a patch), it's good for all new ports. :P | 04:57 |
| pitti | right, but we automate all the backports, and so everything needs to work on old releases | 04:58 |
| infinity | pitti: Sure, you could just manually copy config.foo at build time, as some packages do. | 04:58 |
| infinity | slangasek: Why the moutall fakesync instead of a real sync? | 05:00 |
| pitti | infinity: well, my suspicion is that new ports will need some manual care anyway, as they need the corresponding asm for fast mutexes | 05:00 |
| infinity | slangasek: And with different sources, no less... | 05:01 |
| * infinity reuploads with the same source as Debian... | 05:03 | |
| pitti | infinity: if you are reviewing syncs in the queue, I left some explanations about upower in #u-release | 05:17 |
| === stub` is now known as stub | ||
| slangasek | infinity: oh, I suppose that did regenerate the sources; well, the contents were the same, so yeah. But anyway, how do you do a real sync from incoming? | 05:47 |
| infinity | slangasek: I unpack the debian sources, dpkg-genchanges -S > ../foo_source.changes, change the target to saucy, sign the .changes (but not resign the .dsc) and upload. | 05:58 |
| infinity | slangasek: Pretty sure syncpackage or something has an option that tries to do that automagically, but I dunno. I've been doing it manually for 9 years. | 05:58 |
| slangasek | infinity: right, that was actually what I meant to do, I just goofed by regenerating the .dsc along the way | 05:58 |
| slangasek | but I hear some people still don't consider that a "real" sync :) | 05:59 |
| infinity | slangasek: It won't report in the UI and mailing lists quite the same, but if the dsc/diff/orig are byte-identical and retain the original sig, I don't care. :P | 05:59 |
| * slangasek nods | 06:00 | |
| === Maple__ is now known as Guest60728 | ||
| === jasoncwarner_ is now known as jasoncwarner | ||
| dholbach | good morning | 07:25 |
| diwic | pitti, hi | 08:11 |
| pitti | hello diwic | 08:12 |
| diwic | pitti, hi! It looks like you're the author of dh_modaliases | 08:12 |
| pitti | yes, indeed | 08:12 |
| diwic | pitti, I have a question about it finding module aliases directly in the .ko file | 08:12 |
| diwic | pitti, are there any naming conventions w r t the package name and the .ko file? | 08:13 |
| diwic | pitti, or how would dh_modaliases know which .ko files to scan for aliases? | 08:13 |
| pitti | diwic: no naming conventions really; it's usually <upstream-source-name>-dkms | 08:14 |
| pitti | diwic: it just scans the entire binary package for *.ko files and adds all their modaliases | 08:14 |
| === iahmad is now known as iahmad|afk | ||
| pitti | if that doesn't work (like for nvidia, which has completely broken modaliases), you need a manual list | 08:14 |
| === freeflying_away is now known as freeflying | ||
| diwic | pitti, okay, thanks | 08:15 |
| diwic | shawnwang, <pitti> diwic: it just scans the entire binary package for *.ko files and adds all their modaliases | 08:17 |
| diwic | shawnwang, just trying to understand why you don't think that would work for us? | 08:17 |
| diwic | shawnwang, i e I don't think we need to manually generate debian/modaliases | 08:18 |
| diwic | shawnwang, dh_modaliases would just do the right thing if it does not find such a file. | 08:19 |
| shawnwang | diwic, but if I don't put the modaliases, it won't generate oem-audio-hda-daily-dkms.substvars | 08:19 |
| diwic | pitti, ^ do you know how to troubleshoot that? | 08:21 |
| shawnwang | diwic, it shows "Can't stat debian/oem-audio-hda-daily-dkms: No such file or directory" | 08:22 |
| pitti | addsubstvar() is called in both cases, and both update that map | 08:23 |
| pitti | that sounds like you might be calling it too early? | 08:23 |
| pitti | i. e. before dh_install etc? | 08:23 |
| pitti | of course it can only scan the binary package if it already exists | 08:23 |
| diwic | pitti, does it have to be done as part of the dkms build here? | 08:24 |
| pitti | if you use dh, then "dh --with modaliases" should DTRT | 08:24 |
| pitti | diwic: what do you mean? I thought dkms was used to build the actual *.ko files from the source (which is shipped in the foo-dkms.deb) | 08:25 |
| diwic | pitti, sorry, you always have to think twice with the double packaging that comes with autobuilding dkms packages on launchpad | 08:25 |
| pitti | yeah | 08:26 |
| pitti | if all that your ubuntu source pacakge does is to copy around the source C files, then dh-modalises won't work | 08:26 |
| diwic | pitti, ah...you're right | 08:26 |
| pitti | you'd need to build it once, scan for the modalises, and stick them into debian/foo.modalises | 08:26 |
| pitti | (i. e. the static variant) | 08:26 |
| diwic | pitti, yeah, and that's exactly what shawnwang's trying to do | 08:26 |
| shawnwang | pitti, add dh_install, It works now. | 08:27 |
| diwic | shawnwang, you're right and I'm wrong. We need to do it your way, because we shouldn't ship the .ko files, just the source | 08:27 |
| pitti | I believe I once wrote some "debian/rules update-modaliases" stanza for some driver which does that | 08:29 |
| diwic | shawnwang, hmm, so we could run dh_install just to make dh_modaliases happy, and then throw away whatever dh_install installs? | 08:29 |
| pitti | if only I could remember which one | 08:30 |
| shawnwang | diwic, ok, I will do some test about dh_install and dh_modaliases | 08:30 |
| pitti | well, if running dh_install installs something which you don't want, you have a bug in your debian/*.instlal files | 08:30 |
| pitti | (but that's entirely unrelated to dh_modaliases) | 08:30 |
| diwic | shawnwang, ok, thanks. If you don't come to a conclusion I | 08:30 |
| diwic | shawnwang, ok, thanks. If you don't come to a conclusion I'll merge it as it is | 08:31 |
| shawnwang | diwic, ok... cool | 08:32 |
| diwic | pitti, thanks for explaining it to me | 08:32 |
| shawnwang | pitti, thank you | 08:32 |
| pitti | no worries; sorry, dh_modaliases scanning doesn't really work with dkms | 08:33 |
| pitti | if you have an idea how to generalize that, I'm all ears | 08:33 |
| pitti | seems in nvidia, bcmwl, etc. we just ship static modalises | 08:33 |
| diwic | pitti, dh_modaliases --files-to-scan=path/to/*.ko ? | 08:34 |
| pitti | i. e. debian/foo.modaliases | 08:34 |
| pitti | but would you actually have *.ko files in a dkms package? all it does is to install a few *.c files from the orig.tar.gz? | 08:34 |
| diwic | pitti, that way you could to a test build, call dh_modaliases on that, and then throw away the .ko files | 08:34 |
| pitti | ah, for manual operation | 08:34 |
| diwic | pitti, the test build could be done as part of the build even if it is thrown away | 08:35 |
| diwic | pitti, it is a good test case, to see if your c files actually compile, too :-) | 08:35 |
| pitti | diwic: indeed; if you debian/rules calls dkms build into a tmpdir | 08:36 |
| dholbach | can somebody from the release team have a look at 1235737? | 08:36 |
| seb128 | dholbach, try #ubuntu-release and bonus point if you use "bug <nnn>" so the bot gets the title and url ;-) | 08:37 |
| dholbach | hey seb128 :) | 08:37 |
| seb128 | dholbach, hey ;-) | 08:38 |
| seb128 | hum, did anyone got a conffile prompt when upgrading evince? | 08:38 |
| dholbach | seb128, not me | 08:39 |
| pitti | I upgraded this morning, no conffile prompts | 08:42 |
| pitti | (nor did I get any in the past few weeks) | 08:42 |
| Laney | same | 08:42 |
| Laney | what was the diff? | 08:42 |
| pitti | doko_, infinity: postgresql-9.1 updated; I'll do the sid upload/saucy sync tomorrow, then 9.1.10 will get announced upstream | 08:48 |
| pitti | (bug 1237248) | 08:48 |
| ubottu | bug 1237248 in postgresql-9.1 (Ubuntu Raring) "New upstream microreleases 9.1.10, 8.4.18" [Undecided,New] https://launchpad.net/bugs/1237248 | 08:48 |
| pitti | (the sid upload contains the config.* update) | 08:48 |
| seb128 | Laney, https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1237281 | 08:49 |
| ubottu | Ubuntu bug 1237281 in evince (Ubuntu) "usr.bin.evince conffile diff prompt on upgrade" [Undecided,New] | 08:49 |
| Laney | seb128: that flags=complain stuff wasn't in the distro package | 08:51 |
| seb128 | Laney, I probably used aa-complain usr.bin.evince at some point I guess | 08:52 |
| seb128 | I never edited that file manually though | 08:52 |
| Laney | how can dpkg tell that? | 08:52 |
| Laney | a tool editing is still editing | 08:52 |
| seb128 | well, we should provide tools that create conffile diffs | 08:52 |
| seb128 | or those files shouldn't be conffiles | 08:53 |
| seb128 | Laney, but thanks for pointing that out, I had forgotten about the aa-complain | 08:53 |
| seb128 | but I guess that's due to it | 08:53 |
| seb128 | we *shouldn't* provide tools... | 08:53 |
| seb128 | (rather) | 08:53 |
| Laney | I think people who know enough to muck about with apparmor profiles like that can handle the prompt | 08:54 |
| seb128 | Laney, ok, fair enough, thanks for the hint, as said I had no idea I ever touched that config | 08:55 |
| Laney | sure, np | 08:55 |
| Laney | :-) | 08:55 |
| seb128 | Laney, I guess my issue is https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/117852 | 09:00 |
| ubottu | Ubuntu bug 117852 in apparmor (Ubuntu) "Conflict in profiles in complain mode when upgrading apparmor-profiles" [Wishlist,Won't fix] | 09:00 |
| Laney | sounds like it | 09:00 |
| Laney | old bug! | 09:00 |
| seb128 | yeah | 09:00 |
| seb128 | so it seems like I had my profile in complain mode for ages, I didn't know | 09:01 |
| Laney | i guess it's likely not updated very often | 09:01 |
| seb128 | I tried to turn it off once to test a bug and to see if it was an apparmor thing | 09:01 |
| seb128 | I probably screwed up and did a config change | 09:01 |
| * seb128 has not a lot of clue about apparmor | 09:01 | |
| Noskcaj | pitti, Do we want symbols for pygobject or is there a reason they've not been generated? | 09:04 |
| infinity | pitti: How fresh are our langpacks? Do we need another export for release? | 09:04 |
| pitti | infinity: I think we do; we advertise LanguagePackTranslationDeadline for Oct 10, so I guess we should build fresh ones on Oct 11 | 09:17 |
| pitti | Noskcaj: we do want them; they should be in python{,3}-gobject-dbg | 09:17 |
| pitti | Noskcaj: err, python{,-3}-gi-dbbg | 09:17 |
| FourDollars | pitti: Do you have any plan to patch or backport upower to Ubuntu 12.04,12.10,13.04? | 09:18 |
| Noskcaj | pitti, ok. I've just made some of the ones for the standard package, i'll finish them tomorrow | 09:18 |
| pitti | FourDollars: not from my side; there are some quite intrusive patches in there | 09:19 |
| pitti | FourDollars: if someone wants to backport individual fixes, I'm happy to assist/review, though | 09:19 |
| FourDollars | pitti: I see. | 09:20 |
| FourDollars | pitti: Actually I have https://code.launchpad.net/~fourdollars/ubuntu/precise/upower/fix-lp-bug-1153488 that needs someone to review it. Could you help me? | 09:20 |
| pitti | FourDollars: we definitively don't need stuff like 05-stop-calling-deprecated-g_type_init.patch in SRUs | 09:22 |
| pitti | FourDollars: and we need Launchpad bugs (with SRU information) for all changes | 09:22 |
| infinity | pitti: Alright, can you make sure that happens, so I can not care about chasing it up? :) | 09:22 |
| pitti | infinity: yes, that's on my TODO list | 09:23 |
| FourDollars | pitti: I will cherrypick it is because without it there will be some merge conflict. | 09:23 |
| infinity | pitti: My hero. | 09:23 |
| FourDollars | pitti: OK. I will go to see what information I should add on it. | 09:24 |
| === iahmad|afk is now known as iahmad | ||
| pitti | infinity: according to https://translations.launchpad.net/ubuntu/saucy/+language-packs we ought to get a fresh -base export on Oct 10 or 11 now, so that'll fit | 09:24 |
| pitti | FourDollars: not sure whether the locale fixes are important enough for SRU; they are not "obviously safe" and don't fix critical bugs, so TBH I'd rather leave them out | 09:25 |
| pitti | i. e. if it suddenly starts exposing UTF-8 names to clients, these might crash in turn as they haven't seen/expected non-ASCII data so far | 09:26 |
| FourDollars | pitti: I thought there are all relative to that bug. | 09:26 |
| pitti | FourDollars: likewise, I'd treat detection of bluetooth input devices as a new feature, not truly a major bug in precise (but if you want/need that for some OEM stuff, it's probably ok) | 09:26 |
| pitti | but only for precise, not for non-LTS | 09:27 |
| FourDollars | pitti: OEM reports lots of Bluetooth device issues. That is why I am working on it. | 09:28 |
| xnox | FourDollars: usually one has multiple issues fixed in a single upload, hence multiple entries/comments in the changelog, multiple patches etc. For SRU, one has to decide which is the _least_ amount of changes that need to be cherrypicked to solve a particular bug in a stable release. | 09:28 |
| === doko_ is now known as doko | ||
| FourDollars | xnox: Regarding to Bug 1153488, there are some Bluetooth keyboards not showing in the power indicator, or there is some Bluetooth mouses showing in the power indicator but with the wrong type. | 09:33 |
| ubottu | bug 1153488 in upower (Ubuntu Precise) "Treats bluetooth input device batteries as batteries" [Undecided,New] https://launchpad.net/bugs/1153488 | 09:33 |
| FourDollars | xnox: The merge proposal I provided is to correct the type and the name of Bluetooth devices. | 09:34 |
| lool | pitti: So | 09:35 |
| lool | pitti: we use this ubuntu-unity/daily-build PPA to stage CI-ed touch uploads | 09:35 |
| lool | pitti: these get copied to -proposed once they pass automatic or currently manual testing | 09:35 |
| pitti | lool: packages can ship a hook which either always redirects bug reports to an LP project, or only if the package isn't an Ubuntu one (so that you can share the hook with Ubunut) | 09:35 |
| lool | pitti: when we test these, we're getting crash files but apport wont let us them send them to launchpad because binaries come from PPA | 09:35 |
| xnox | FourDollars: no, you made a merge proposal that copies all changes from the upload that happens to fix the bug you care about. But it also has 3 or 4 other unrelated patches. | 09:36 |
| FourDollars | xnox: So I think that is the least amount of changes I need. | 09:36 |
| xnox | FourDollars: no, it is not. | 09:36 |
| pitti | lool: unity already does that (/usr/share/apport/package-hookssource_unity.py) | 09:36 |
| pitti | lool: | 09:36 |
| pitti | if not apport.packaging.is_distro_package(report['Package'].split()[0]): | 09:36 |
| pitti | report['CrashDB'] = 'unity' | 09:36 |
| FourDollars | xnox: So I need to open other bug report. Right? | 09:37 |
| xnox | FourDollars: no, you need less changes in your merge proposal. | 09:37 |
| lool | pitti: so it's not my archive | 09:37 |
| lool | pitti: problem is we'd need to drop the hook when copying to distro | 09:37 |
| seb128 | no you don't | 09:37 |
| pitti | lool: why? | 09:37 |
| seb128 | apport.packaging.is_distro_package | 09:38 |
| lool | pitti: so perhaps we can test for PPA build in CurrentlyBUilding and set the hook when it's PPA | 09:38 |
| pitti | lool: that's what the first line does | 09:38 |
| xnox | FourDollars: please modify the bug report description with test case, how to reproduce the original bug and verify that the proposed branch fixes it. I've asked you to do that before. | 09:38 |
| pitti | lool: i. e. "redirect to project ONLY if it is not an ubuntu packag | 09:38 |
| lool | pitti: well what if you have other PPA enabled and you get that hook? | 09:38 |
| xnox | FourDollars: at the point you can see that e.g. dropping extra patches still resolves the bug you care about. | 09:38 |
| lool | pitti: I dont want to get reports from people with random PPAs | 09:38 |
| FourDollars | xnox: I see. | 09:38 |
| lool | pitti: that's why I wanted a cmdline flag to override W | 09:38 |
| lool | TW | 09:38 |
| pitti | lool: ah, then you can check the origin flag in the Package field | 09:38 |
| lool | *BTW* | 09:38 |
| xnox | FourDollars: Remember our conversation when I pointed you to: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template ? | 09:38 |
| pitti | lool: no, no, no | 09:38 |
| FourDollars | xnox: Yes. | 09:39 |
| lool | pitti: even if it's very secret | 09:39 |
| lool | pitti: or let's protect it by cryptography | 09:39 |
| lool | or we hide it with steganography in the source | 09:39 |
| pitti | lool: you can always vi the .crash report and re-send it through ubuntu-bug | 09:39 |
| pitti | (and drop UnreportableReason) | 09:39 |
| lool | if you have this combination of newlines in your email email address, it can be sent | 09:39 |
| pitti | so there's already a way | 09:39 |
| lool | pitti: ah perfect | 09:39 |
| lool | pitti: thanks! | 09:39 |
| pitti | but it shouldn't be an officially blessed CLI | 09:39 |
| lool | technical means, social abuses | 09:40 |
| pitti | lool: but as I said, you can also do stuff in the hook like "if Package field contains "[origin: PPA-unity-daily-build" then send it to LP | 09:40 |
| pitti | to match your use case | 09:40 |
| pitti | lool: look at your Package field, what does it say? | 09:40 |
| lool | pitti: sorry dont have one handy | 09:41 |
| lool | pitti: will check when I have one | 09:41 |
| lool | pitti: this is for a class of packages rather than one specific one | 09:41 |
| pitti | lool: if we limit the match to that specific PPA, we can also add that logic to /usr/share/apport/general-hooks/ubuntu.py | 09:43 |
| pitti | lool: i. e. "anything from that PPA", or matching by name/regexp etc. | 09:44 |
| lool | pitti: ok | 09:46 |
| ritz | hi , does upstart emit event for suspend/resume ? | 10:07 |
| xnox | ritz: yes. | 10:09 |
| ritz | xnox thanks, I am unable to see this in cook book, from a quick grep http://upstart.ubuntu.com/cookbook/ | 10:10 |
| FourDollars | xnox: pitti: I have updated the description of https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1153488 . | 10:10 |
| ubottu | Ubuntu bug 1153488 in upower (Ubuntu Precise) "Treats bluetooth input device batteries as batteries" [Undecided,New] | 10:10 |
| xnox | ritz: actually looking at $ man 7 upstart-events | 10:10 |
| xnox | ritz: I don't see it. | 10:10 |
| ritz | aah | 10:10 |
| ritz | thanks | 10:10 |
| xnox | ritz: why would you want a suspend/resume events anyway? =) | 10:11 |
| xnox | ritz: everything should get back as it is. | 10:11 |
| ritz | https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1184262 | 10:11 |
| ubottu | Ubuntu bug 1184262 in network-manager (Ubuntu) "network-manager has decided that networking is disabled, cannot be re-enabled from lightdm" [High,Confirmed] | 10:11 |
| pitti | FourDollars: you'll need a separate for the unicode ones (or drop these patches), and drop teh g_type_init() one (as that's really not releavant for SRU) | 10:12 |
| ritz | xnox quick hackish workaround | 10:12 |
| FourDollars | pitti: OK. | 10:12 |
| xnox | ritz: right, so pm-utils package has direcotries with scripts that are executed on suspend/resume, hibernate/thaw. | 10:13 |
| ritz | aah | 10:13 |
| ritz | thanks | 10:13 |
| xnox | ritz: so network-manager or user should just add scripts there. | 10:13 |
| xnox | ritz: see /usr/share/doc/pm-utils/README and /usr/share/doc/pm-utils/HOWTO.hooks.gz and etc. | 10:15 |
| xnox | ritz: you can ship things in /usr/lib/pm-utils/sleep.d/ (for packages) or in /etc/pm/sleep.d (for administrator). | 10:15 |
| xnox | I think. | 10:15 |
| xnox | ritz: yeap, see $ man 8 pm-suspend. | 10:15 |
| ritz | xnox++ thanks | 10:18 |
| === wcchandl1r is now known as wcchandler | ||
| FourDollars | pitti: I opened https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1237329 and I am going to revise my merge proposal. | 10:24 |
| ubottu | Ubuntu bug 1237329 in upower (Ubuntu) "Apple Wireless Keyboard/Mouse are not listed as its original name. It stripped non-ascii characters (UTF-8 valid)." [Undecided,New] | 10:25 |
| xnox | FourDollars: right i see, then you can have multiple bugs in the SRU, but then the whole SRU will wait on all bugs to be verified before it gets accepted. | 10:26 |
| xnox | FourDollars: so i guess that bug is for the utf-8 patch? | 10:26 |
| FourDollars | xnox: yes. | 10:27 |
| xnox | FourDollars: cool. | 10:27 |
| FourDollars | xnox: pitti: https://code.launchpad.net/~fourdollars/ubuntu/precise/upower/fix-bluetooth-1153488-1237329/+merge/190086 | 10:43 |
| doko | seb128, could you forward the two unity-* ftbfs to somebody? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130917-saucy.html | 10:44 |
| FourDollars | xnox: pitti: Is there anything needed to improve? | 10:44 |
| doko | these still ftbfs, all others did succeed when given back | 10:45 |
| === d1b_ is now known as d1b | ||
| seb128 | sil2100, Mirv: ^ unity-lens-music and unity-scope-github ftbfsing is known? | 10:48 |
| seb128 | doko, ^ | 10:48 |
| sil2100 | seb128, doko: looking, but 17 hours ago the unity stack built fine, hm | 10:52 |
| pitti | FourDollars: looks fine now, thanks; I adjusted the tasks for the new bug | 11:03 |
| FourDollars | pitti: Thank you. | 11:04 |
| seb128 | sil2100, those are rebuilt of what is currently in saucy, not from trunk | 11:07 |
| seb128 | sil2100, we didn't get an upload of unity-lens-music since 2013-06-21 ... is that normal? | 11:08 |
| seb128 | sil2100, https://launchpad.net/ubuntu/+source/unity-lens-music | 11:08 |
| Mirv | there haven't been commits to trunk since June | 11:09 |
| seb128 | Mirv, weird that the daily build is working then? or is it not rebuilding if there are no change? | 11:10 |
| Mirv | seb128: exactly, it only rebuilds if there's a change | 11:10 |
| seb128 | Mirv, so I guess it's why there is no issue in the stack | 11:11 |
| doko | Mirv, I'm retrying now, but I already did on Oct 1 | 11:11 |
| === MacSlow is now known as MacSlow|lunch | ||
| doko | Mirv, unity-scope-github still ftbfs | 11:14 |
| seb128 | doko, the music lens one is being worked on, should be fixed today | 11:16 |
| doko | seb128, do you want to care about gtk2-engines and gmime? | 11:21 |
| seb128 | doko, not especially, I've already and endless todo | 11:21 |
| === Guest60728 is now known as Maple[] | ||
| seb128 | doko, the unity-lens-music issue has been fixed in their trunk, now we just need a landing of the unity stack to happen | 11:54 |
| doko | seb128, thanks! | 11:54 |
| seb128 | yw | 11:54 |
| OrokuSaki | Hi! When I run surface flinger, I get a screen, but I get a EGL_BAD_CONTEXT when running unity8. My screen initializes, but my OpenGL Renderer does not. My device is an HP Touchpad.. and its using a custom graphics.c, do you think the graphics.c could be the an issue? | 12:05 |
| OrokuSaki | So I cannot watch 720p or 1080p videos... | 12:06 |
| OrokuSaki | And since an update to the mediaservice.. I cannot watch 480p | 12:06 |
| OrokuSaki | When I switch to Mir, I get an error that seems to be related to the graphics.c | 12:06 |
| OrokuSaki | I do not develop, so I can't argue. =) | 12:07 |
| OrokuSaki | still playing with udev rules | 12:07 |
| OrokuSaki | Lastly, I would like to try cm-10.2 sources.. but.. I guess there is no way to switch Ubuntu Touch to 10.2? | 12:08 |
| xnox | OrokuSaki: i think you want #ubuntu-touch channel. | 12:09 |
| === MacSlow|lunch is now known as MacSlow | ||
| === _salem is now known as salem_ | ||
| PaowZ_ | Hi there ! I'm trying to control the way udev populates /dev for a special device. I mean, I have a barcode reader which appears as a HID appliance in /dev. The thing is an event handler is attached to this device and every inputs are seen as keyboard inputs which, of course, I don't want.. | 12:49 |
| PaowZ_ | any clue ?? | 12:49 |
| === caribou_ is now known as caribou | ||
| xnox | PaowZ_: barcode readers are usually, simply keyboards. | 12:59 |
| xnox | PaowZ_: you scan a barcode yet, it acts as a keyboard that simply "types out" the barcode's digits/numbers. | 12:59 |
| PaowZ_ | xnox: Indeed, this is what I noticed. But this behavior doesn't suit me.. | 13:01 |
| PaowZ_ | I need to "mute" barcode redirection towards text fields.. | 13:01 |
| PaowZ_ | I can already get a file descripteur on /dev/hidraw* to read barcode inputs, but I don't need the content to be typed into any text field.. | 13:03 |
| === vila is now known as vila-laaaate-lun | ||
| jdstrand | hallyn: hey, I only just now noticed bug #1227937 needed a response from me. I've done that though I doubt I am much help. I think stgraber needs to get involved | 13:13 |
| ubottu | bug 1227937 in lxc (Ubuntu) "lxc-start is unconfined but has a profile defined" [High,New] https://launchpad.net/bugs/1227937 | 13:13 |
| jdstrand | hallyn: please see my comment though (comment #2) | 13:13 |
| === vila-laaaate-lun is now known as vila-late-lunch | ||
| hallyn | doesn't ring a bell, checking | 13:23 |
| hallyn | jdstrand: i don't understand. if the lxc-container-default poilcy is defined, then it's defined... if the container could enter it, it's defined. no? | 13:25 |
| hallyn | hm, screen is wonky. one sec | 13:25 |
| hallyn | jdstrand: does the ubuntu touch install run a normal upstart setup at boot, and normal lxc packages? who is starting that container, and when/how? | 13:27 |
| xnox | hallyn: see lxc-android-config package. | 13:28 |
| xnox | hallyn: there is an upstart job, which well in the end does "lxc-start -n android" | 13:28 |
| xnox | hallyn: so it's started as root. | 13:28 |
| xnox | jdstrand: maybe /etc/init/lxc-android-config.conf need to specify with apparmor profile to use? | 13:29 |
| hallyn | xnox: jdstrand: yeah that's a but in lxc-android-config | 13:30 |
| hallyn | it needs to wait started lxc | 13:30 |
| hallyn | /etc/init/lxc.conf is the one which loads the apparmor profiles | 13:30 |
| hallyn | i'll comment in the bug - thanks guys | 13:30 |
| xnox | ogra_: ^ looks like we will be starting android lxc container later in the boot process. | 13:31 |
| xnox | ogra_: unless we override lxc start on condition. | 13:31 |
| ogra_ | xnox, we cant really | 13:31 |
| ogra_ | we dont use the normal lxc jobs at all i think | 13:32 |
| hallyn | then you can manually load the profiles as the lxc.conf does | 13:32 |
| xnox | ogra_: right, then we should load the apparmor profiles. | 13:32 |
| hallyn | or we could create an lxc-apparmor upstart jbo which does the loading, which everyoen can wait on | 13:33 |
| hallyn | but it's too late probably to get that into saucy | 13:33 |
| hallyn | it's the nicest way to handle it long term | 13:33 |
| ogra_ | i thought we had our special apparmor handling since months | 13:33 |
| ogra_ | please talk to jdstrand, i know he added some stuff for our container a while ago | 13:33 |
| === vila-late-lunch is now known as vila | ||
| xnox | ogra_: jdstrand is the one saying there is lxc-start running un-confined. with or without special profiles, if we don't load it, we don't get it =/ | 13:34 |
| xnox | (unless i don't understand bug #12279) | 13:34 |
| ubottu | bug 12279 in gnome-control-center (Ubuntu) "no way to emulate a 3 button mouse?" [Low,Fix released] https://launchpad.net/bugs/12279 | 13:34 |
| xnox | (unless i don't understand bug #1227937) | 13:34 |
| ubottu | bug 1227937 in lxc (Ubuntu) "lxc-start is unconfined but has a profile defined" [High,Confirmed] https://launchpad.net/bugs/1227937 | 13:34 |
| ogra_ | xnox, well, whatever is set up atm, was planned to be kept for this version | 13:35 |
| ogra_ | afaik | 13:35 |
| === arges_ is now known as arges | ||
| jdstrand | actually, I have never touched the lxc/apparmor configuration on touch | 13:38 |
| jdstrand | honestly, I know little about it | 13:38 |
| pitti | linux-signed-image-3.11.0-12-generic (3.11.0-12.18) wird eingerichtet ... | 13:38 |
| pitti | warning: file-aligned section .text extends beyond end of file | 13:38 |
| pitti | warning: checksum areas are greater than image size. Invalid section table? | 13:38 |
| ogra_ | jdstrand, hmm, who did that then, mdeslaur ? | 13:39 |
| pitti | apw, xnox ^ just cosmetical, or something to worry about? | 13:39 |
| jdstrand | I filed that bug last month cause I noticed the profile was loaded but the process unconfined | 13:39 |
| ogra_ | jdstrand, right,, and iirc on purpose | 13:39 |
| jdstrand | I have made changes to the system writable paths for apparmor in lxc-android-config | 13:39 |
| ogra_ | because there was no way to fix it at that time | 13:39 |
| xnox | pitti: i think that's ok, let me upgrade my laptop and let you know. | 13:40 |
| jdstrand | ogra_: no one responded in the bug that it was intentional | 13:40 |
| ogra_ | jdstrand, i dont remember who did that change anymore ... and i didnt know about that bug at all | 13:40 |
| jdstrand | ogra_: but vila today saw a denial that I thought was because the profile was actually in effect | 13:40 |
| jdstrand | he saw it in ci, but on intel of all things, so I don't really know what is going on | 13:41 |
| hallyn | jdstrand: no one would respond in that bug bc it was against lxc, and noone at lxc knows about that assumption... | 13:41 |
| jdstrand | maybe that is an unrelated bug that should be filed | 13:41 |
| xnox | jdstrand: well if lxc-android-config is stopped, and started, the second invocation will be now confined as the lxc-start profile is loaded. | 13:42 |
| hallyn | if you want it to be unconfined, then is lxc.aa_profile set to unconfined in the container config? | 13:42 |
| xnox | jdstrand: as by that time lxc job has run and loaded the profile. | 13:42 |
| ogra_ | xnox, ugh | 13:42 |
| hallyn | but just hoping that you run before lxc.conf runs, yeah that's racy | 13:43 |
| stgraber | xnox: the LXC container for Ubuntu touch runs with lxc.aa_profile=unconfined | 13:43 |
| ogra_ | xnox, lxc-android-config is not designed to ever be stopped ... | 13:43 |
| jdstrand | xnox: sure. I filed the bug cause I saw what seemed like a race condition-- it is quite unusual (and dangerous) to have a profile that is loaded but not applied to the process because of what you just described. you end up with all kinds of weird bugs | 13:43 |
| ogra_ | xnox, your devices would vanish underneath you | 13:43 |
| hallyn | stgraber: have you seen bug 1227937 happen? | 13:43 |
| ubottu | bug 1227937 in lxc (Ubuntu) "lxc-start is unconfined but has a profile defined" [High,Confirmed] https://launchpad.net/bugs/1227937 | 13:43 |
| jdstrand | either don't apply the policy at all, or fix it so it is always applied | 13:43 |
| xnox | ogra_: oh, i see. | 13:43 |
| vila | jdstrand: does that mean my issue is completely different and I should investigate further while you discuss yours ? | 13:44 |
| jdstrand | ogra_: right, that is what I was afraid of, so I didn't try to stop the container :) | 13:44 |
| ogra_ | yeah, dont :) | 13:44 |
| stgraber | hallyn: I didn't see that bug but I don't know why we care since we explicity set the container as lxc.aa_profile = unconfined to begin with | 13:44 |
| ogra_ | we only stop it on shutdown | 13:44 |
| jdstrand | vila: your issue is definitely different. the lxc policy needs some missing rules | 13:44 |
| hallyn | stgraber: that wasn't clear to me until just now | 13:45 |
| jdstrand | vila: but your issue was possibly never seen because of the issue we're discussing | 13:45 |
| vila | jdstrand: haaaa, now we're talking business ;) So the change Mirv pointed you at may have uncover "my" issue ? | 13:45 |
| jdstrand | vila: well, there was in the uploads yetsterday that should have caused that | 13:46 |
| jdstrand | was nothing* | 13:46 |
| jdstrand | vila: you should have been seeing that issue all along (dbus mediation has been in effect since august) | 13:46 |
| xnox | pitti: mostly harmless | 13:46 |
| hallyn | vila: ok i'll wait for more info from you in the bug | 13:46 |
| jdstrand | vila: I should clarify-- nothing in the apparmor related uploads | 13:46 |
| stgraber | jdstrand: so I agree we've got a race there but the race shouldn't matter since the container runs unconfined anyway | 13:47 |
| pitti | xnox: ack, thanks | 13:47 |
| jdstrand | stgraber: ok, can you comment on that in the bug? | 13:47 |
| vila | hallyn: meh, I'm confused, are you saying I should use that bug to track my issue ? | 13:47 |
| jdstrand | vila: can you file a new bug with your denial? | 13:47 |
| hallyn | uh, or, if you don't want to, mark it invalid | 13:47 |
| vila | jdstrand: will do | 13:47 |
| hallyn | vila: ok, nm :) | 13:48 |
| jdstrand | stgraber: perhaps you can look at vila's bug when he files it? there is a system bus apparmor denial when lxc-container-default is in effect | 13:48 |
| vila | hallyn: I'll file a new bug once I have a better idea on what is going on (it may well be that the problem is elsewhere) | 13:48 |
| hallyn | jdstrand: so shall i mark bug 1227937 invalid? | 13:49 |
| ubottu | bug 1227937 in lxc (Ubuntu) "lxc-start is unconfined but has a profile defined" [High,Confirmed] https://launchpad.net/bugs/1227937 | 13:49 |
| * hallyn confused | 13:49 | |
| jdstrand | hallyn: I'm not sure it is invalid-- I think it is not high priority. eg, what would happen if lxc-start did have its profile in effect sometime in the future when it did matter? | 13:50 |
| vila | jdstrand: what's lxc-container-default ? | 13:50 |
| hallyn | jdstrand: if you have lxc.aa_profile = unconfined, then nothing would change | 13:50 |
| jdstrand | I don't know-- how all the lxc apparmor containers work together | 13:50 |
| hallyn | jdstrand: lxc-start will see that it is unconfined, and do nothing. | 13:51 |
| jdstrand | hallyn: yes, what I am saying is if someone did 'lxc.aa_profile = somethingelse' | 13:51 |
| hallyn | jdstrand: if it becomes confined, then it will switch the profiles. (so, if kernel relabels it, as it should) | 13:51 |
| jdstrand | hallyn: all of a sudden this bug is potentially important | 13:51 |
| hallyn | jdstrand: then the caller had a bug for not waitint on lxc | 13:51 |
| hallyn | but it's not a bug | 13:51 |
| hallyn | it's a mis-use | 13:51 |
| hallyn | the only inconvenience is that aa gets loaded later bc it's tied in with setting up networking | 13:52 |
| stgraber | jdstrand: then lxc-android-config should wait for lxc to finish, but that's not currently required and would possibly slow down the boot process on the phon | 13:52 |
| jdstrand | hallyn: so the fact the lxc-start has a profile defined for enforce mode, but starts before that is in effect is not a bug? how is that possible? | 13:52 |
| jdstrand | it is a bug waiting to bite someone | 13:53 |
| hallyn | stgraber: for s+1 I think we should split up lxc.conf to have a separate loading of aa policy earlier than lxc-net runs | 13:53 |
| stgraber | lxc-start should fail if the profile isn't ready for use | 13:53 |
| jdstrand | note, I'm not saying it is important for saucy for the reasons mentioned. I am only saying I don't think the bug is invalid | 13:53 |
| jdstrand | (and perhaps the bug isn't against lxc) | 13:54 |
| hallyn | hm. | 13:54 |
| hallyn | from ubuntu pov you're right. but upstream lxc can't say "if no profile don't run" | 13:54 |
| stgraber | root@castiana:~# lxc-start -n tpl-saucy-amd64 -s lxc.aa_profile=blah | 13:55 |
| stgraber | lxc-start: Permission denied - failed to change apparmor profile to blah | 13:55 |
| stgraber | so the upstream behaviour is already correct | 13:55 |
| hallyn | then ubuntu behavior should also be correct | 13:55 |
| stgraber | (ENOPERM is a bit odd though ;)) | 13:55 |
| jdstrand | stgraber: can you answer vila's question about lxc-container-default? | 13:55 |
| jdstrand | (or hallyn) | 13:56 |
| hallyn | thoug i'm quite certain there is going to be a race in there depending on exactly when the running lxc-start gets re-labeled | 13:56 |
| stgraber | vila: that's the apparmor profile applied to a standard container on Ubuntu which prevents the container from causing harm to the host | 13:56 |
| vila | jdstrand: found it, it's in apparmor, I thought it may have been the default config since otto (my main suspect here doesn't use the default lxc config) | 13:56 |
| vila | stgraber: thanks | 13:56 |
| jdstrand | vila: well, it is an apparmor profile, yes (I didn't know that was your question). however the package that ships that policy is lxc (ie, lxc may need to be updated to address your apparmor denial) | 13:57 |
| stgraber | jdstrand: so is your dbus stuff allowed by default in apparmor or does any confined job now has to allow it? | 13:57 |
| * stgraber tries dbus in a saucy container | 13:58 | |
| vila | jdstrand: yeah, thanks, that's where I found it (searching lxc for all installed files) | 13:58 |
| jdstrand | vila: and what I didn't know is that policy is in effect and how | 13:58 |
| vila | jdstrand: but I still don't know what is denied, the only apparent symptom in the end is that we can't start the X server | 13:59 |
| hallyn | probably dbus | 13:59 |
| hallyn | grumble :) | 13:59 |
| jdstrand | stgraber: any confined process needs to have dbus rules if it uses dbus. the apparmor dbus abstractions allow wide access | 13:59 |
| jdstrand | stgraber: eg: cat /etc/apaprmor.d/abstraction/dbus | 14:00 |
| jdstrand | /{,var/}run/dbus/system_bus_socket rw, | 14:00 |
| jdstrand | dbus bus=system, | 14:00 |
| stgraber | jdstrand: that's going to suck for LXC... | 14:00 |
| jdstrand | stgraber: so if you don't want fine-grained access, just add #include <abstractions/dbus> to the profile | 14:00 |
| stgraber | jdstrand: because we do verbatim backport down to precise | 14:00 |
| jdstrand | stgraber: the dbus abstraction exists on precise | 14:00 |
| jdstrand | stgraber: as does dbus-session | 14:01 |
| jdstrand | stgraber: so you can safely add those to the profile and it will all work | 14:01 |
| jdstrand | the only potential gotcha is that saucy introduced the dbus-accessibility abstraction which doesn't exist on precise | 14:02 |
| jdstrand | but if you don't need it, don't add it to the lxc apparmor policy | 14:02 |
| stgraber | jdstrand: we need any dbus traffic alloewd by default as we have no clue what our users may do in their container | 14:04 |
| stgraber | since dbus isn't considered harmful for ths host, it should just be alloewd in there... | 14:04 |
| stgraber | jdstrand: so it sounds like we want just "dbus," added to the policy, but I guess that'll only work on saucy and higher, right? | 14:05 |
| jdstrand | stgraber: then I suggest on saucy and higher you use 'dbus,' in the profile and omit that in raring and lower | 14:05 |
| jdstrand | stgraber: yes | 14:05 |
| stgraber | ok, time for some debhelper magic then | 14:06 |
| stgraber | jdstrand: and will that also blow up in our users' face if they run saucy on an older kernel? | 14:06 |
| jdstrand | we've had to deal with that in firefox for some time | 14:06 |
| jdstrand | saucy userspace on an old kernel is fine | 14:07 |
| stgraber | cool | 14:07 |
| jdstrand | the problem is new policy on old userspace | 14:07 |
| === barry` is now known as barry | ||
| jtaylor | is it too late to revert vim back to 7.3? :/ | 14:13 |
| jtaylor | its new "faster" regexp engine is attrociously slow for the common use case of syntax highlighting | 14:13 |
| jtaylor | its basically unusable | 14:13 |
| jtaylor | in saucy | 14:14 |
| pitti | jtaylor: oh? I'm using vim all the time for everything, haven't noticed yet | 14:15 |
| pitti | jtaylor: what kind of files do you see this on? | 14:15 |
| jtaylor | pitti: are you using easytag? | 14:16 |
| pitti | no | 14:16 |
| pitti | jtaylor: well, I use the application for changing music tags, but I guess that's not what you mean | 14:16 |
| jtaylor | not that one :) | 14:16 |
| jtaylor | vim-easytag allows to use ctags data for highlighting | 14:17 |
| jtaylor | very useful, but with 40k tags and vim 7.4 you now have 0.5s lag on scrolling and permantently 100% cpu uage of vim :/ | 14:17 |
| jtaylor | and 40k tags is not much | 14:18 |
| jtaylor | mh debians slightly newer vim version is crap too | 14:19 |
| jtaylor | I'll check with upstream, but looking at the new engine its probably not easy to fix ... | 14:20 |
| Laney | get it filed and we can SRU when possible | 14:20 |
| Laney | final freeze is tomorrow, reverting probably wouldn't be so wise | 14:20 |
| cjwatson | I haven't found current vim in saucy to be unusable at all and I use it (with syntax highlighting) all the time | 14:21 |
| Laney | Me neither, but I don't use easytag | 14:21 |
| cjwatson | but indeed not with easytag | 14:21 |
| jtaylor | how do you get highlighting of function names? | 14:21 |
| cjwatson | sounds like a good candidate for a release note though | 14:21 |
| cjwatson | I don't find I need highlighting of function names ... | 14:22 |
| jtaylor | easytag uses a vim regex with lots of |, which seems to be the cause of the slowness | 14:22 |
| jtaylor | each | pattern causes lots of copies and page faults | 14:22 |
| === mlankhor1t is now known as mlankhorst | ||
| psusi | is anyone able to merge my fix for bug #1237169 before the final freeze? it's a fairly simple cherry picked upstream commit | 15:08 |
| ubottu | bug 1237169 in Sound Juicer "CD Drive widget does not show selected drive" [Medium,New] https://launchpad.net/bugs/1237169 | 15:08 |
| xnox | slangasek: so upstart-socket-bridge doesn't seem to work as I thought. Whilst "start on socket" causes the socket to be created, the UPSTART_FDS is not set, when doing "start myjob". Ideally, i'd like the job to be instantly started, and not wait for something to connect. | 15:16 |
| dobey | is there a way to see who accepted an upload to the archive? the reject e-mail says who rejected, but accept e-mails don't say who accepted | 15:21 |
| xnox | dobey: no. I don't think so, you can ask in #ubuntu-release. | 15:22 |
| mdeslaur | psusi: sure, one sec | 15:22 |
| xnox | dobey: is it actually anything recent, or just binary accept? | 15:22 |
| dobey | xnox: it's recent as in uploads i made yesterday afternoon | 15:24 |
| crass | not sure if this should be in app-devel, but doing "backportpackage -s saucy -w openvpn openvpn" is dying on an exception... could anyone help with this? | 15:25 |
| mdeslaur | psusi: looks good, building now and will upload it in a few minutes | 15:26 |
| psusi | mdeslaur: thanks | 15:26 |
| mdeslaur | psusi: uploaded | 15:40 |
| slangasek | xnox: well, I refer you to the DebConf discussions about the socket bridge API :) | 15:54 |
| xnox | slangasek: hm... please remind me. I had a couple. | 15:54 |
| * xnox ponders to disable console service in android container. | 15:55 | |
| slangasek | xnox: oh, just that the upstart way is incompatible with systemd and not useful in current form :) | 15:55 |
| === tkamppeter_ is now known as tkamppeter | ||
| xnox | slangasek: gotch. | 15:55 |
| xnox | slangasek: i'm always thinking to do on file event /dev/socket/qemud, socat /dev/socket/qemud to get it emitted =) | 15:56 |
| xnox | s/always/almost/ | 15:56 |
| doko | pitti, would you mind enabling a verbose build for systemd? | 16:00 |
| === PaowZ_ is now known as PaowZ_afk | ||
| vila | hallyn, stgraber: -C option for lxc-ubuntu-cloud is gone in saucy ? Sucks for me :-( | 17:22 |
| vila | hallyn, stgraber: hmm, may be not, surely not even, but it's not recognized by lxc-create anymore, what's the new trick to provide userdata to a container ? | 17:23 |
| hallyn | vila: make sure you pass it after '--' | 17:25 |
| smoser | vila, its better now! | 17:25 |
| hallyn | the option is for the template, not for lxc-create | 17:25 |
| smoser | http://ubuntu-smoser.blogspot.com/2013/08/lxc-with-fast-cloning-via-overlayfs-and.html | 17:26 |
| smoser | but it should be passable to create also | 17:26 |
| smoser | actually. | 17:26 |
| smoser | should be backwards compat | 17:26 |
| hallyn | smoser: I think vila is doing 'lxc-create -t ubuntu-cloud -C' instead of '-- -C' | 17:26 |
| vila | yeah | 17:26 |
| smoser | did that work previously? | 17:26 |
| vila | yes | 17:26 |
| smoser | no. | 17:27 |
| smoser | really? | 17:27 |
| vila | I was doing: sudo lxc-create -n lxc-precise-server-pristine -t ubuntu-cloud -- -r precise -a amd64 -C | 17:27 |
| vila | on raring for sure and probably early days of saucy | 17:27 |
| smoser | and that does not work now ? | 17:27 |
| hallyn | that should work. it's still in the code | 17:27 |
| smoser | i intended to make that work | 17:27 |
| vila | smoser: nope, and the error message is cryptic: lxc-create: container creation template for lxc-precise-server-pristine failed | 17:28 |
| vila | hallyn: can't find it anymore in lxc-ubuntu-cloud | 17:28 |
| hallyn | vila: it's done through the hook now | 17:28 |
| hallyn | vila: saucy? | 17:29 |
| vila | hallyn: but looking at the sources... it may be via ubuntu-clloud-prep also I don't know the syntax... yeah | 17:29 |
| vila | so, how does that work ? | 17:29 |
| vila | hallyn: yes saucy | 17:29 |
| hallyn | pixe dust | 17:29 |
| vila | hallyn: if that was an answer, it went way above my head ;) | 17:30 |
| vila | hallyn: oh ! pixie dust as in Peter Pan ? | 17:30 |
| hallyn | right. smoser is peter pan. | 17:31 |
| hallyn | ok so i'm on the ubuntu-lxc ppa, but lemme try that command | 17:31 |
| smoser | $ lxc | 17:32 |
| smoser | The program 'lxc' is currently not installed. You can install it by typing: | 17:32 |
| smoser | sudo apt-get install lxc | 17:32 |
| hallyn | vila: oh, you might have the bug i introduced (bad untar option) | 17:33 |
| hallyn | but no, i'm seeing the same thing without that bad code | 17:33 |
| vila | fresh saucy updated hmm, already ~11 hours ago damn, what a day | 17:34 |
| vila | hold on, the option is still in the script, something else is wrong indeed (too long day, probably looked in the bad place), | 17:37 |
| vila | anyway, if I don't use the option lxc-create succeed so there is still an issue when using it | 17:37 |
| smoser | vila, hallyn | 17:42 |
| smoser | http://paste.ubuntu.com/6214719/ | 17:42 |
| smoser | bugger | 17:42 |
| vila | ha, running with -d (and adding -x in ubuntu-cloud-prep) I get: well, smoser beat me to it and probably knows what the issue is | 17:43 |
| sarnold | my kingdom, my kingdom, my kingdom for a ' 0'. | 17:44 |
| smoser | yeah. | 17:44 |
| smoser | vila, i'm wondering, though, why do you use -C ? | 17:44 |
| vila | smoser: works far better with that ;) | 17:44 |
| vila | smoser: because I customize the lxc by parameterizing cloud-init | 17:44 |
| vila | smoser: so after the lxc-create, I mount some userdata for lxc-start | 17:45 |
| smoser | ah. i see. well, now we have clone hooks for that. | 17:45 |
| smoser | and it does just what you want. | 17:46 |
| vila | smoser: i.e. mount some userdata ? | 17:46 |
| smoser | yeah. | 17:46 |
| smoser | reaad my blog post. | 17:46 |
| smoser | create a source, clone with '--userdata', start. | 17:46 |
| vila | AAAAAARGH | 17:47 |
| vila | I'm even subscribed to that blog but that .... reader marked the article as read ! | 17:48 |
| smoser | the clone hooks are really neat. | 17:48 |
| smoser | they were added exactly to do what i think you're doing. | 17:48 |
| hallyn | smoser: are you sending a patch or should I just push it? | 17:49 |
| vila | hallyn: push it, I tested it and morally approve it ;) | 17:50 |
| hallyn | vila: yeah i'm only asking for credit reasons :) | 17:50 |
| smoser | hallyn, typing bug. | 17:51 |
| smoser | you can do the patch/fix if you want | 17:51 |
| hallyn | ok, i'll just push it without an email to the list then. ths | 17:51 |
| hallyn | thx | 17:51 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1237543 | 17:53 |
| ubottu | Ubuntu bug 1237543 in lxc (Ubuntu) "lxc-create (or clone) of cloud template with '--cloud' exits failure" [Undecided,New] | 17:53 |
| vila | will that land in time for saucy or should I carry that fix ? | 17:53 |
| smoser | i think it will land. relase team will ack it | 17:55 |
| vila | cool | 17:56 |
| vila | just reading ubuntu-cloud-prep a bit slower, indeed, just provide the *file* and boom ! no need to juggle with mount myself, great | 17:57 |
| vila | smoser: I should send you my code ;) I was handling a cache for kvm, no need for lxc ! Already provided ! I was mounting /var/lib/cloud/seed/nocloud-net, not needed anymore ! | 18:00 |
| vila | thanks guy, you made my evening ;) Will EOD in peace now | 18:01 |
| smoser | handling a cache for kvm ? | 18:02 |
| smoser | vila, | 18:02 |
| vila | smoser: for the images | 18:02 |
| smoser | ah. so 'uvtool' is rbasak's work on that | 18:02 |
| smoser | iuvtool goal is magic just like lxc-create. we're working on it. | 18:03 |
| * hallyn adjusts the tablecloth strategically keeping vmbuilder out of sight... | 18:04 | |
| hallyn | all right, lunch. bbl | 18:04 |
| vila | smoser: good to know will track that | 18:04 |
| stgraber | hallyn: we uploaded lxc at the same time with a different change :) I just rejected both our uploads and I'm doing one with both changes now. | 18:05 |
| vila | hallyn: but... I was told vmbuilder was dead so I build a... simple thing around cloud-init as I care only about ubuntu | 18:05 |
| hallyn | stgraber: cool, thanks :) | 18:05 |
| hallyn | vila: yes. +1 | 18:05 |
| vila | hallyn: ha, pfew, you scared me | 18:07 |
| brainwash | it looks like the updata-manager does not support restarting via logind yet -> bug 1232363 | 18:25 |
| ubottu | bug 1232363 in update-manager (Ubuntu) "Update Manager Restart button fails on xubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1232363 | 18:25 |
| slangasek | sabdfl: quorum> lol | 19:04 |
| === beuno_ is now known as bueno | ||
| slangasek | xnox: bug #1237556 looks like a regression from your cryptsetup change | 19:21 |
| ubottu | bug 1237556 in cryptsetup (Ubuntu) "cryptsetup removed from initrd.img on upgrade to 13.10" [Undecided,New] https://launchpad.net/bugs/1237556 | 19:21 |
| slangasek | xnox: seems that cryptsetup isn't being completely excised from the initramfs? | 19:21 |
| brainwash | slangasek: hey, got a minute or so to take a look at update-manager and add support for restarting via logind? bug 1232363 | 20:16 |
| ubottu | bug 1232363 in update-manager (Ubuntu) "Update Manager Restart button fails on xubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1232363 | 20:16 |
| slangasek | brainwash: by "add support" do you mean "write support", or "apply a patch"? I don't see any patches linked from that bug | 20:19 |
| brainwash | slangasek: I assume it's basically copy and pasting the consolekit definition and changing the dbus call, like http://lpaste.net/94086 | 20:22 |
| slangasek | brainwash: well, I have no idea; if you have a patch that's been tested, confirmed to fix xubuntu, and not regress ubuntu, I'd be happy to sponsor it | 20:22 |
| slangasek | but whereas sponsoring only takes a minute, I don't have the time to develop / test the fix | 20:23 |
| brainwash | slangasek: ok, we'll test it and report back, thanks :) | 20:23 |
| === salem_ is now known as _salem | ||
| sarnold | is there a better person to poke for broken us-east-1 ec2 broken package repository than IS RT? | 22:11 |
| slangasek | zyga: haven't heard from you in a bit; did the new mountall turn your machine into a kumquat? | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!