| maslen | Hey, I'm a new maintainer for aircrack-ng, and want to try 'baking in' support for as many of the hardening features as possible. Right now I'm working on squashing some bugs, but I was thinking about making an option for a 'hardened' build in the makefile and an apparmor profile. Are there any guides on best how to do that? | 00:58 |
|---|---|---|
| sarnold | maslen: the hardening-includes package includes a hardening-check tool that you could use to see if aircrack-ng is already hardened by the toolchain | 01:01 |
| sarnold | maslen: for an apparmor profile, you can use dh_apparmor to help install a profile; I think the mysql-5.6 source package includes an example, probably cups does as well | 01:01 |
| maslen | Is there any standard place to put it? | 01:02 |
| maslen | (or way to name it?) | 01:02 |
| sarnold | the apparmor profile should wind up in e.g. /etc/apparmor.d/usr.bin.aircrack-ng if you're confident that it will work for most users | 01:03 |
| maslen | got it. I wasn't sure if there was some other way to do it, that would take advantage of a custom installpath | 01:03 |
| maslen | just creating a directory called 'apparmor' should be sufficient? | 01:04 |
| sarnold | sorry, I've never added dh_apparmor to a package myself, I'm not sure what the details are | 01:09 |
| cjwatson | barry: Is it a bug that "from lazr.delegates import Passthrough" stopped working as of the Python 3 port you did, even under Python 2? lazr.restful was using that, but apparently now has to use "from lazr.delegates._passthrough import Passthrough" (which seems wrong) or port to something else. I'm wondering if it would make more sense to export that directly from lazr.delegates again. | 01:23 |
| cjwatson | barry: Noticed when finding that "pip install lazr.restful" (don't ask why, I'm multiple levels deep in yak-shaving) gives me a thing I can't import. | 01:24 |
| cjwatson | barry: Or is this internal machinery that lazr.restful has no business meddling in? | 01:25 |
| barry | cjwatson: gosh, i haven't looked at that in a long while. looking at the usage.rst, i'm not sure that l.d.Passthrough was ever considered a public api, though i guess if lazr.restful was using it, that was maybe just an omission. if it was a byproduct of the py3 port, i suppose we should say it's a bug | 01:40 |
| barry | cjwatson: ah | 01:42 |
| cjwatson | I don't really understand this layer well enough to have a strong opinion on which direction the fix should go in, I just know it's busted :) | 01:42 |
| cjwatson | (somewhere) | 01:42 |
| barry | cjwatson: so i think this was a byproduct of lazr.delegates._passthrough.Passthrough being imported by lazr/delegates/delegates.py and l/d/__init__.py doing a `from lazr.delegates._delegates import *` | 01:42 |
| barry | which did get lost in the py3 port | 01:42 |
| barry | so it probably worked accidentally | 01:43 |
| cjwatson | Yes. | 01:43 |
| barry | probably best to just explicitly import it in the __init__.py | 01:43 |
| cjwatson | That was my thought, if you think it's reasonable to effectively make it quasi-public again. | 01:43 |
| barry | i guess if l.restful uses it, we should restore its undocumented queasy, er, quasi nature. can you file a bug? i can probably turn this around and release + upload a new version tomorrow | 01:44 |
| barry | cjwatson: okay if it's just to unstable/wily? or do we need an sru to some earlier release? | 01:45 |
| infinity | barry: How far back was it broken like this? | 01:46 |
| cjwatson | barry: https://bugs.launchpad.net/lazr.delegates/+bug/1472456 | 01:46 |
| ubottu | Ubuntu bug 1472456 in lazr.delegates "lazr.delegates no longer exports Passthrough" [Undecided,New] | 01:46 |
| * barry looks | 01:46 | |
| infinity | If a public interface is going to disappear and reappear, I'd rather it reappear everywhere we support. | 01:47 |
| cjwatson | barry: I hadn't even looked at the packaged version, I was just going from pip | 01:47 |
| cjwatson | barry: lazr.restful isn't packaged so my care factor is limited in that regard | 01:47 |
| cjwatson | oh wait, it is | 01:47 |
| infinity | Of course it is. | 01:48 |
| cjwatson | So I don't personally care because LP deploys it in other ways, but the package is probably broken | 01:48 |
| infinity | And installed on many, many machines. | 01:48 |
| cjwatson | infinity: That's lazr.restfulclient. | 01:48 |
| cjwatson | lazr.restful is the server sied. | 01:48 |
| infinity | Oh. | 01:48 |
| cjwatson | *side | 01:48 |
| infinity | dpkg -l handily cut it off at just the right point to make me look silly. ;) | 01:48 |
| cjwatson | I'm rather surprised it's packaged, and probably nothing uses it, but ... | 01:48 |
| barry | probably broke in upstream version 2.0 (2013-01-10) which introduced the py3 port. and the first debian version is 2.0.1 so it's probably been broken in debian/ubuntu forever | 01:48 |
| cjwatson | Indeed. | 01:48 |
| infinity | barry: Oh, if it was always "broken" in Debian/Ubuntu, then there's no regression. You win! | 01:49 |
| barry | \o/ | 01:49 |
| cjwatson | Well, just Ubuntu. lazr.restful isn't in Debian at all. | 01:49 |
| barry | tbh, i don't really care about much of the lazr stuff, except lazr.smtptest | 01:49 |
| barry | oh, and lazr.config | 01:49 |
| infinity | Err, I'm super confused. | 01:50 |
| infinity | Is lazr.restful in the archive not the same thing? | 01:50 |
| infinity | Cause those versions don't align at all with what you said. :P | 01:51 |
| barry | infinity: above was for lazr.delegates | 01:51 |
| barry | lazr.restful is just a client of that | 01:51 |
| infinity | Oh. | 01:51 |
| infinity | I'm not awake enough to do things like read. | 01:51 |
| barry | where's sinzui when you need him? | 01:51 |
| infinity | barry: Though, you're still wrong about the "first Ubuntu version", then. | 01:52 |
| infinity | lazr.delegates | 1.1.0-0ubuntu2 | precise/universe | source | 01:52 |
| infinity | lazr.delegates | 1.2.0-0ubuntu3 | trusty/universe | source | 01:52 |
| infinity | lazr.delegates | 2.0.1-1 | utopic/universe | source | 01:52 |
| infinity | Which implies this would have regressed in >= utopic. | 01:52 |
| barry | oh hahaha. i was looking at the svn repo for the debian package | 01:52 |
| barry | infinity: do people still use utopic? <wink> | 01:53 |
| infinity | And given that restful is packages all the way back to precise, I assume it regressed in >= U. | 01:53 |
| infinity | Of course, if no one's noticed, that's also telling. | 01:53 |
| barry | indeed | 01:53 |
| barry | i think cjwatson is the only one using it | 01:54 |
| infinity | barry: Dunno, but U and V ship the same version, so SRU to U and I'll copy-with-binaries to V. | 01:54 |
| barry | should be easy enough | 01:54 |
| barry | anyway, eod | 01:55 |
| === BinLi_afk is now known as BinLi | ||
| pitti | Good morning | 04:26 |
| pitti | teward: here now | 04:26 |
| pitti | slangasek: yes, I think we can handle that much more easily with the new code, now that I understand it | 04:27 |
| pitti | slangasek: right now we indeed require that all tests succeed in unstable (in britney terms, i. e. in -proposed) | 04:27 |
| pitti | slangasek: we would mostly need to set up a VM with apt pinning so that when it runs the multipath-tools induced tests with the non-proposed lava-dispatcher | 04:28 |
| pitti | and specify that "version constraint" in the AMQP request and re-run the test after it regressed in proposed | 04:28 |
| pitti | slangasek: still a lot of work, but at least possible | 04:29 |
| infinity | rbasak: Around yet? | 05:45 |
| infinity | pitti: Running test for both testing and unstable would complicate britney a fair bit. | 05:46 |
| infinity | pitti: Since, yes, if we're migrating only A, we don't care if B in unstable is failing, but if we're migrating both, we sure do. | 05:46 |
| pitti | right | 05:46 |
| infinity | pitti: And our test against tests comes before we know what will and won't migrate together. | 05:46 |
| pitti | infinity: it helps that we don't just "run test foo-1", we track that we test foo-1 *for* bar-2 | 05:47 |
| infinity | pitti: Perhaps that's the solution (and has other nice side effects), which is that we should be testing autopkgtest state between the installibility/hint phase and the final SUCCESS/copy. | 05:48 |
| pitti | infinity: so if bar-2 is failing, but bar-1 succeeds, we cuold still promote foo-2 if that succeeds against bar-1, but we'd hold back bar-2 | 05:48 |
| infinity | pitti: That has the nice side effect that a busted test wouldn't hide progress of a transition or a large block hint, like it does today. | 05:48 |
| pitti | infinity: oh, I thought it would already run that after the installable test | 05:48 |
| pitti | at least we don't even trigger tests any more if the package isn't even installable | 05:49 |
| infinity | pitti: autopkgtest happens in the update_exuses stage, which is before all the cool stuff in update_output happens. | 05:49 |
| pitti | ah, this one | 05:49 |
| infinity | pitti: There are two installable checks. :P | 05:49 |
| infinity | pitti: One for individual packages, one for migrated state. | 05:49 |
| infinity | pitti: So, *triggering* the tests when we do is right and shouldn't change, but *checking* state should probably actually happen very last, right before we'd pass/fail on promoting. | 05:50 |
| pitti | so we wouldn't even start running tests until a transition is completed | 05:50 |
| pitti | and only then learn about regressions -- not exactly ideal either | 05:50 |
| pitti | ah, I see | 05:50 |
| infinity | pitti: Nah, re-read. | 05:50 |
| infinity | Yeah. :) | 05:50 |
| infinity | We can still have the output on excuses for nice vivisibility and parsing, but not actually act on it there. | 05:51 |
| infinity | We'd act when we're about to commit a complete run, so we can see what's moving together, and use the right tuples. | 05:51 |
| infinity | foo_1 against bar_4, etc. | 05:52 |
| infinity | But this does mean running every test twice. :/ | 05:52 |
| infinity | And a lot of failures on the "test against testing" test, when a transition is in play. | 05:52 |
| infinity | No ideal. | 05:52 |
| pitti | against testing? that's the bit I didn't get | 05:52 |
| pitti | I thought we'd continue to run everything against unstable | 05:53 |
| pitti | we'd re-trigger reverse depends as usual if you upload another piece of a transition | 05:53 |
| infinity | pitti: Well, no, we'd want to test everything twice, right? | 05:53 |
| pitti | do we? | 05:53 |
| infinity | pitti: Okay, well, look at Steve's complaint. foo_2 and bar_2 both get uploaded. bar_2 doesn't work right, but foo_2 works fine in the context of testing. | 05:54 |
| infinity | pitti: We can only know that if both are tested in isolation against testing, and then testing against full unstable. | 05:54 |
| infinity | s/testing/tested/ | 05:54 |
| pitti | ah, for that | 05:54 |
| infinity | Err, where that belongs. | 05:54 |
| pitti | so that's unrelated to moving the evaluation of results until after the second install check stage | 05:55 |
| infinity | So, yeah. It explodes the test matrix a bit, and makes britney's promotion decision a bit harder. | 05:55 |
| pitti | and it might cause a lot of failed tests due to uninstallablility if you can't install teh new source's binaries in isolation, but that'd be okay | 05:55 |
| infinity | pitti: Well, they relate because once we have both sets of results, the only place we can reliably use them is in the last britney stage. | 05:55 |
| infinity | pitti: Since I don't know which result I care about until I'm there. | 05:55 |
| infinity | ie: if I intend to promote one package, I care how it works with testing, while if I intend to promote 3 packages, I care how they work with each other. | 05:56 |
| infinity | (if they interdepend) | 05:56 |
| infinity | pitti: It makes the bold assumption that if an rdep failure is isolated to unstable, it's the rdep's fault, not the new dep. | 06:00 |
| infinity | pitti: Which is probably 99% true, but not always. | 06:00 |
| infinity | pitti: I dunno. I think it's something we could do better, but I think human intervention is sort of working for now, and this sound painful to do perfectly. | 06:00 |
| pitti | well, in some cases it's part of a transition, and then it's fine to keep it in unstable | 06:01 |
| pitti | infinity: I read a lot of the current britney code recently; mostly the bits that directly interact with autopkgtest, I'm not yet familiar with the installability checks | 06:01 |
| pitti | infinity: anyway, I think I'll be more happy to think about this once we finish simplifying the autopkgtest stuff and moving it to the cloud | 06:02 |
| infinity | pitti: The installability checks are, actually, pretty simple, by necessity, since they're super duper quadratic and can't be complex. :P | 06:02 |
| infinity | pitti: Basically, attempt to promote source package, check if there are more or fewer uninstallable packages in testing as a result, if fewer win, if more, fail. And then the autohinter that tries to match up things with deps on each other to batch attempt, and same check. | 06:03 |
| * pitti currently looks at a first excuses.html that contains both the old and the cloud test results, after a day of running 500 autopkgtests; looks fairly ok | 06:03 | |
| pitti | I'm surprised that the machinery survived these 500 tests without much hiccup :) | 06:03 |
| * pitti pats scalingstack | 06:03 | |
| infinity | Which region? | 06:04 |
| pitti | RegionOne | 06:05 |
| pitti | (lcy01) | 06:05 |
| pitti | I haven't tried lgw01 yet (uh, this is also called "RegionOne") | 06:05 |
| pitti | infinity: how do you usually handle britney merges? https://code.launchpad.net/~pitti/britney/britney2-ubuntu-amqp/+merge/264047 is a followup of the first amqp MP (Steve reviewed/merged that) | 06:09 |
| pitti | infinity: i. e. is it generally okay to push such followup merges myself, or better to do a four-eyes principle? | 06:10 |
| infinity | pitti: To be fair, until very recently, we've never really had merges to handle, so I dunno how we handle them. :P | 06:10 |
| infinity | pitti: Colin and I sort of just committed directly for most of our stuff. | 06:10 |
| pitti | oh? there were a fair bunch for the original adt-britney ones, then boottest, etc. | 06:10 |
| infinity | pitti: If you're willing to babysit the logs and make sure your stuff is happy, direct committing is fine. If you're relying on the infra to fail gracefully and planning to commit and run, then please no. And if you just want a review because you think it's a good idea (or because the change is largeish), a review would be good. | 06:11 |
| infinity | pitti: Yeah, true, there were for adt and boottest, Colin did all of those, and I assume it was all reviewed and merged by him, since the other parties wouldn't have had commit. | 06:11 |
| pitti | infinity: nah, I have a checkout of my branch on snakefruit to run britney there (partial copy of data/), no hit'n'run :) | 06:12 |
| pitti | infinity: so, my gut feeling is that the initial MP was good for four-eyes, I shoudl push these followup fixes directly, and do an MP again for the "get results from swift" bits | 06:12 |
| infinity | pitti: Sure. I have no issues with direct commits if they come with commitment. | 06:12 |
| pitti | right now it's all a practical no-op as AMQP isn't yet enabled in the production checkout | 06:13 |
| pitti | infinity: of course; okay, thanks | 06:13 |
| infinity | pitti: Worst case scenario, you notice it explodes and you revert. *shrug* | 06:13 |
| pitti | right | 06:13 |
| infinity | pitti: Thankfully, I've never met a britney failure mode where it screws everything up and then decides to promote everything. | 06:13 |
| pitti | infinity: or it promotes everythign in -proposed :) | 06:13 |
| pitti | hah | 06:13 |
| infinity | Oh, except when we open a new series and intentionally disable adt for a few days. :P | 06:13 |
| infinity | Hopefully with your new setup, we can fix that lag. | 06:13 |
| pitti | we now have an infinitely large cloud to do that! | 06:14 |
| pitti | *cough* | 06:14 |
| infinity | pitti: It's not the workers that were the lag, it was the setting up all the jenkins jobs, etc. | 06:14 |
| * pitti defines 10 == ∞ | 06:14 | |
| pitti | infinity: oh dear, I want that stuff to die | 06:14 |
| infinity | pitti: Hoping the new setup makes it more of an "add new release to a config file and watch it function" thing. | 06:14 |
| pitti | infinity: well, it's still some manual work as we don't have cloud images from day 1 | 06:15 |
| infinity | Well, and "hack in temp cloud image". | 06:15 |
| pitti | right | 06:15 |
| pitti | but that's pretty much it | 06:15 |
| infinity | Sure, but a vivid cloud image with fixed sources.list is a wily cloud image. :) | 06:15 |
| infinity | (same story for buildd chroots) | 06:15 |
| infinity | Actually, buildd chroots are even easier, since lp-buildd writes sources.list at runtime, so it can literally be the same tarball. | 06:15 |
| pitti | yeah, except that this should get dist-upgraded every day to not explode the dist-upgrade/reboot time, but details | 06:16 |
| pitti | infinity: right, and I could provide that with a --setup-commands | 06:16 |
| infinity | pitti: Sure, sure. Lots of maintenance and tweaking, my point is just series opening lag time. | 06:16 |
| infinity | If it's "fix a conffile and copy some cloud images", that's cake. | 06:16 |
| infinity | And yay. | 06:16 |
| pitti | so adding a 'change release in apt sources" setup command script would make this literally an "add new config file" process | 06:17 |
| pitti | (more and more inefficient over time, but working) | 06:17 |
| pitti | but that'll be the time when I'll sit down to create a new daily job to provide a current image :) | 06:17 |
| infinity | :) | 06:17 |
| infinity | Yeah, I'm waiting for *stack on all 6 arches, so I can move my chroot tarballs to some sort of cloud buildy thingee. | 06:18 |
| infinity | Y'know, I guess I could build them as livefses. | 06:18 |
| infinity | Hrm. Why have I not been doing that? | 06:18 |
| infinity | Something to do later this week, I think. | 06:18 |
| dholbach | good morning | 06:44 |
| opiwahn | where would I have to place an initram-script if I want to have it executed as early as possible: http://snag.gy/KCkcM.jpg | 06:45 |
| pitti | opiwahn: init-top/asomething | 06:55 |
| opiwahn | pitti: thank you pitti . I will try it | 07:06 |
| opiwahn | pitti: and script inside there is executed before touching any harddisks? | 07:07 |
| pitti | opiwahn: yes | 07:07 |
| pitti | opiwahn: see "Subdirectories" in man initramfs-tools(8) | 07:08 |
| opiwahn | pitti: thank you very much :-) | 07:09 |
| jamespage | if there are any archive admins with a few spare minutes I'd appreciate a review of networking-odl in the wily NEW queue - thankyou! | 07:40 |
| infinity | jamespage: Is that a thing that has intent to also exist in Debian? | 07:44 |
| jamespage | infinity, yeah - the repo is created, but its not been testing in Debian yet | 07:45 |
| jamespage | infinity, I also have a python-os-brick in the queue - also in the NEW queue for experimental | 07:45 |
| jamespage | I just need to unblock our liberty milestone1 testing in wily | 07:45 |
| jamespage | as Debian is not targetting liberty just yet, we're leading on some of this stuff (doing more through experimental tho) | 07:45 |
| infinity | jamespage: Check. The followup question would be if the maintainer in Debian is you, or if you're working with the planned maintainer to make sure the packaging is the same. | 07:45 |
| jamespage | infinity, it will be done under the pkg-openstack team - might be me... | 07:46 |
| infinity | jamespage: With a second followup of "wtf, no python3?" ... I thought all new openstack stuff was dual-stack. | 07:47 |
| jamespage | infinity, not core projects just yet - working towards that | 07:47 |
| jamespage | networking-odl is a split out vendor driver from neutron | 07:47 |
| jamespage | python-os-brick does have py3 support tho - I had to fix that up (submitted upstream) | 07:47 |
| opiwahn | pitti: about the init-script: do I have to write my script to this file "ORDER" ? http://pastebin.com/4pbZ4nGu | 07:48 |
| pitti | opiwahn: I've never heard about ORDER, shouldn't be necessary; might be something that initramfs-tools builds/uses internally | 07:49 |
| pitti | adding the script and "sudo update-initramfs -u" shoudl suffice | 07:50 |
| opiwahn | ok.. so I just put a (shell) script to folder init-top and update-initramfs -lk all should work? | 07:50 |
| opiwahn | pitti: my issue is that the script does not appear in the live-system.. when searching in /usr/share/initramfs-tools/scripts/ all the scripts are in there.. except mine | 07:51 |
| pitti | opiwahn: not sure what -l is (that doesn't exist), I suppose you want -u | 07:51 |
| jamespage | infinity, thankyou! | 07:51 |
| pitti | opiwahn: err, live system? | 07:52 |
| opiwahn | pitti: i use -k all | 07:52 |
| opiwahn | yes.. I am doing a remastering... and I want to add an early script to initrd.lz | 07:52 |
| pitti | opiwahn: ah, that might be where this ORDER things comes from? (no idea about remastering, sorry) | 07:53 |
| highvoltage | #Â# Â-#Â-/win 24 | 07:53 |
| infinity | pitti: The ORDER files are generated by update-initramfs. | 07:54 |
| infinity | But yeah, if one was hacking the initrd manually instead of generating it properly, you'd need to hack those bits too. | 07:54 |
| opiwahn | this is how I generate it in my remaster-script: http://pastebin.com/LiNmSJJU | 07:55 |
| opiwahn | before that I unpack initrd.lz... put my script in there.. repack it.. | 07:55 |
| infinity | opiwahn: Unpacking and repacking it isn't sane. | 07:55 |
| opiwahn | I used these lines to pack/unpack: http://pastebin.com/0cCsewNb | 07:56 |
| opiwahn | isnt that ok? | 07:56 |
| infinity | opiwahn: You want to put your script in /usr/share/initramfs-tools/scripts/init-top/ and the update-initramfs -u and use the result. | 07:56 |
| opiwahn | infinity: so you mean just putting while remastering the file in there, executing update-initramfs .... without modifying any initrd.lz ?? | 07:57 |
| infinity | opiwahn: Use the tools available, instead of trying to hack around them. :) | 07:57 |
| opiwahn | so I can execute an init-script without hacking the initrd.lz ?? | 07:58 |
| infinity | opiwahn: Your goal is to add a script to the initrd in init-top, yes? So, put it in your chroot at chroot/usr/share/initamfs-tools/scripts/init-top/ and then "chroot chroot/ update-initramfs -u -k$(version)" and copy the result from chroot/boot/initrd-$(uname) | 07:59 |
| infinity | opiwahn: You *can* unpack and repack the initrd, but that means you need to know how initramfs-tools builds it, which is not knowledge worth having, really. :P | 08:00 |
| opiwahn | infinity: I really WANT to do the simple way :-) | 08:01 |
| infinity | opiwahn: Yes, the simple way is also the right way. | 08:01 |
| infinity | opiwahn: Two lines. Copy your file, run update-initramfs. | 08:01 |
| infinity | No unpack, repack, understanding inner workings, etc. | 08:01 |
| opiwahn | infinity: is this "double chroot" right? chroot chroot/ update-initramfs -u -k$(version) | 08:01 |
| pitti | all that in the chroot of the live image, I figure | 08:01 |
| infinity | opiwahn: Well, "chroot/" was the directory. In your case "chroot ${WORK}/new/ update-initramfs -u -k 3.19.0-15-generic" | 08:03 |
| infinity | opiwahn: THe trick is that BEFORE that, you do "cp myscript ${WORK}/new/usr/share/initramfs-tools/scripts/init-top/" | 08:03 |
| infinity | And just those two lines (plus copying out the finished initrd) should get you what you want. | 08:03 |
| opiwahn | doing it at the moment and looking forward :-) | 08:04 |
| infinity | I'm assuming here that ${WORK}/new/ has you live filesystem in it. :P | 08:04 |
| infinity | s/you/your/ | 08:04 |
| infinity | Hopefully writable. | 08:05 |
| opiwahn | the variable -k$(version) works on any kernel then ?? | 08:05 |
| infinity | Err, no. | 08:06 |
| infinity | That was shorthand for "-k the-kernel-version-you-use" | 08:06 |
| opiwahn | ah ok | 08:06 |
| infinity | 3.19.0-15-generic", for instance. | 08:06 |
| opiwahn | good that I asked :-) | 08:07 |
| infinity | The kernel version on the livecd and installed in the chroot, of course. | 08:07 |
| infinity | Not the one you're running on your build system. ;) | 08:07 |
| mardy | pitti, pete-woods: I'm trying to use libqtdbus{test,mock} in my tests (successfully), but they fail when they are run as part of dpkg-buildpackage; do you know any tricks to run dbus-daemon as part of the package building process? | 08:08 |
| pitti | mardy: it's always better if your test starts/uses its own private dbus server | 08:08 |
| opiwahn | infinity: the remastering runs.. I tell about the result ;-) | 08:08 |
| pitti | mardy: you should never muck around with the "real" session or system bus | 08:08 |
| pete-woods | mardy: you shouldn't have to change anything. I've used libqtdbustest in all my packaging | 08:08 |
| pete-woods | pitti: libqtdbustest does exactly that (I wrote it) | 08:09 |
| pitti | mardy: and yes, you can use dbus-launch, but really, don't | 08:09 |
| pitti | pete-woods: ah, ok | 08:09 |
| pete-woods | pitti: and libqtdbusmock uses your dbusmock internally | 08:09 |
| mardy | pete-woods: wait, I'll post the output | 08:09 |
| pitti | dbusmock also has a convenience API to start a "private" session bus (or system) | 08:09 |
| pitti | but that only works in python | 08:09 |
| pitti | for C/C++ you have to start the bus yourself, which I suppose is what pete-woods does in libqtdbusmock | 08:10 |
| infinity | It's never the starting that's a problem anyway, it's the 30 times people have reinvented the stopping wheel and failed. | 08:10 |
| pete-woods | mardy: I've likely point the finger at paths / resources are different on your dpkg build that in your local source build | 08:10 |
| pitti | infinity: ? | 08:10 |
| pitti | infinity: dbus-launch --exit-with-session ? | 08:10 |
| mardy | pete-woods: http://paste.ubuntu.com/11840275/ | 08:10 |
| infinity | pitti: Oh, just whining about all the people who fail to stop processes they start in testsuites. :P | 08:10 |
| mardy | pete-woods: I tried both with and without xvfb, same errors | 08:10 |
| pitti | that does look like you have a bus, it's just your service doesn't seem to attach to it | 08:11 |
| pete-woods | infinity: if it makes you feel better, the test processes are managed by libqtdbustest and terminated when your test binary exits :) | 08:11 |
| pete-woods | even if you segfault | 08:12 |
| infinity | pete-woods: It makes me feel warm and fuzzy. | 08:12 |
| mardy | pete-woods: when I run the tests from the terminal, they work | 08:12 |
| infinity | So very fuzzy. | 08:12 |
| mardy | pete-woods: I even unset the DBUS_SESSION_ADDRESS variable, and they still run (on the console) | 08:12 |
| pete-woods | mardy: as they should | 08:12 |
| mardy | pete-woods, pitti: does dpkg-buildpackage run the tests in a chroot? maybe some directory (/var/lib/dbus/) is not available there? | 08:13 |
| infinity | mardy: dpkg-buildpackage doesn't, no. Unless you're invoking it via something like sbuild. | 08:13 |
| mardy | (I found this, that's why I ask: https://bugzilla.redhat.com/show_bug.cgi?id=460574 ) | 08:13 |
| ubottu | bugzilla.redhat.com bug 460574 in mock "dbus can't start in chroot" [Medium,Closed: currentrelease] | 08:13 |
| pitti | mardy: no, it doesn't; you have to provide that yourself with sbuild/pbuilder/etc/ | 08:13 |
| mardy | ok | 08:13 |
| pitti | mardy: err, /var/lib/dbus? that's the session bus | 08:13 |
| pitti | mardy: you aren't allowed to attach to that as user | 08:14 |
| pitti | mardy: I mean, that's teh *system* bus | 08:14 |
| infinity | mardy: dpkg-buildpackage does the following: "fakeroot debian/rules clean && debian/rules build && fakeroot debian/rules binary" | 08:14 |
| infinity | mardy: No magic. | 08:14 |
| mardy | pitti: ok, nevermind that then :-) | 08:14 |
| pitti | mardy: do you test a system or session service? | 08:14 |
| mardy | pitti: session | 08:14 |
| pete-woods | pitti: FYI, libqtdbus test starts a private system and session bus | 08:14 |
| pete-woods | and sets all the relevant environment variables | 08:14 |
| mardy | infinity: thanks; is there a command to run the tests only? that might be easier to debug | 08:15 |
| mardy | infinity: maybe "debian/rules test" or something like that? | 08:15 |
| infinity | mardy: Depends on how you're invoking them, I didn't write your debian/rules. | 08:15 |
| pete-woods | mardy: I would suggest adding some debugging to your test code, and perhaps paring it right back | 08:15 |
| pitti | mardy: I suggest you build it once, and then just do "make check" | 08:15 |
| pete-woods | so just start one test, that prints the bus address | 08:15 |
| pete-woods | something like that | 08:16 |
| pitti | mardy: or whatever your debian/rules does to run the tests | 08:16 |
| pete-woods | just to check it's not all gone crazy | 08:16 |
| mardy | infinity: %: dh $@ --with python3 | 08:16 |
| pitti | mardy: then call fakeroot dh_auto_test | 08:16 |
| pete-woods | as I'm pretty confident about the libs - as mentioned before they are used in a number of projects for testing | 08:16 |
| * mardy tries | 08:16 | |
| infinity | mardy: Without the fakeroot. | 08:17 |
| infinity | pitti: auto_test is part of the build sequence, not the binary sequence. | 08:18 |
| mardy | pitti, infinity: so, if I just run dh_auto_test, it works; if I run "fakeroot dh_auto_test", it fails with the same errors | 08:18 |
| pitti | jamespage, smoser: do you know how cloud-init's userdata could set up apt sources, with referring to "apt_mirror:"? http://cloudinit.readthedocs.org/en/latest/topics/examples.html#add-apt-repositories doesn't really say | 08:18 |
| infinity | mardy: It shouldn't be run with fakeroot, generally. | 08:19 |
| pitti | I need to enable multiverse in the instance, but I don't see what's the preferred way of doing this other than hardcoding the mirror | 08:19 |
| infinity | mardy: Do you have a full build log instead of the short failure snippet? | 08:19 |
| pitti | mardy: so I suppose you are trying to talk to the real session bus | 08:19 |
| pitti | mardy: does it also fail with env -u DBUS_SESSION_BUS_ADDRESS dh_auto_test ? | 08:19 |
| mardy | pitti: with "env -u DBUS_SESSION_BUS_ADDRESS dh_auto_test" it works | 08:23 |
| pitti | ok, so I suppose there's a fakeroot *somewhere*? | 08:24 |
| infinity | mardy: At this point, I'm thinking the full source might be more helpful than people guessing. | 08:25 |
| mardy | infinity, pitti: the full build logs: http://paste.ubuntu.com/11840315/ | 08:25 |
| mardy | pete-woods: I also added a line to print the session address, I cannot see anything wrong in it ^ | 08:26 |
| mardy | infinity: let me push the latest commits... | 08:26 |
| infinity | Err, WTF? | 08:27 |
| infinity | Why is the whole build happening in the binary sequence? | 08:27 |
| infinity | mardy: Do you have a "build" rule in your rules file or something? | 08:27 |
| infinity | mardy: Seeing the source would be very helpful here. :P | 08:28 |
| infinity | debian/rules build | 08:28 |
| infinity | make: 'build' is up to date. | 08:28 |
| infinity | That's why it's going downhill. | 08:28 |
| opiwahn | inifity: did not work, but I think I did not understand it right.. it now just copied my script to "scripts" in the chroot and did update-initramfs.... but thats not all, right? | 08:28 |
| mardy | infinity: lp:~mardy/online-accounts-api/service | 08:28 |
| infinity | opiwahn: And then copy out the new initrd from /boot in the chroot to wherever it should live on your remaster... | 08:28 |
| mardy | infinity: ah! I created a local directory called "build", could that confuse make? | 08:29 |
| * mardy tries removing that... | 08:29 | |
| infinity | mardy: It could indeed. :P | 08:29 |
| infinity | mardy: If you need that directory, you could .PHONY build. | 08:30 |
| opiwahn | infinity: can I also copy initrd from the running live-system? | 08:30 |
| infinity | opiwahn: ...? | 08:30 |
| infinity | opiwahn: Once it's running seems a bit late, since you need it to boot. | 08:30 |
| opiwahn | infinity.. ahm ok.. I try it.. sorry for not-so-good-skills | 08:30 |
| opiwahn | infinity: so this line has to be added, right? | 08:31 |
| opiwahn | infinity: sudo mv ${WORK}/new/initrd.lz ${WORK}/ubuntu-livecd/casper/ | 08:31 |
| mardy | infinity, pitti, pete-woods: so, indeed, having a directory called "build" in the source tree breaks everything :-) Now the tests run just fine :-) | 08:32 |
| infinity | opiwahn: I'm going to assume it's ${WORK}/new/boot/initrd-$(version) or something, but yes. | 08:32 |
| infinity | opiwahn: Look for it after you do the update-initramfs and see what it is. | 08:32 |
| mardy | infinity: thanks for spotting the issue! :-) | 08:32 |
| infinity | mardy: NP. | 08:32 |
| infinity | mardy: Welcome to make? :) | 08:33 |
| opiwahn | infinity: it isnt just called initrd.lz ? | 08:33 |
| infinity | opiwahn: No, update-initramfs generates it as /boot/initrd-$(uname -r) (look at /boot/ on your running system, if you use Ubuntu). | 08:34 |
| infinity | initrd.img-$(uname -r) even. | 08:34 |
| infinity | opiwahn: When we master CDs, we copy that out to "initrd.lz" on the ISO, so our CD bootloader can be stupid and not know about versions. | 08:35 |
| infinity | rbasak: Wake up. I'm tired and want to yell at you about docker before I go to bed. | 08:36 |
| pete-woods | mardy: that's good to know :) | 08:41 |
| opiwahn | infinity: thank you infinity for so great background information.. would like to let u know that I am very very thankful | 08:45 |
| opiwahn | infinity: I located the initrd.img-3.19.0-15-generic in chroot/boot :-) and I am doing WHAT with it?? :-) | 08:53 |
| opiwahn | infinity: because I will need initrd.lz not initrd.img-3.19.0-15-generic ? | 08:54 |
| opiwahn | I have build a initrd.img-$(version) in the chroot of my remastering process. where do I have to put this file so that it "overrides" initrd.lz from original ubuntu-cd ? | 08:59 |
| infinity | opiwahn: Yeah, just copy it to foo/bar/initrd.lz (where foo/bar is the path the original initrd.lz is in on the ISO layout). | 08:59 |
| infinity | ie: copy it over the thing you were previously unpacking and repackging. | 08:59 |
| ekarlso | Hi, is there a reason for network-manager-strongswan not supporting PSK | 09:00 |
| ekarlso | as in https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1457078 | 09:00 |
| ubottu | Ubuntu bug 1457078 in network-manager-strongswan (Ubuntu) "L2TP client support for PSK removed from 15.04" [Undecided,Confirmed] | 09:00 |
| opiwahn | infinity: so e.g. to "casper" folder where I find the original initrd.lz ? should I delete initrd.lz or is this system-immanent? | 09:00 |
| infinity | opiwahn: Copy it over initrd.lz | 09:01 |
| opiwahn | infinity: do you mean renaming and overriding initrd.lz, no? | 09:01 |
| infinity | opiwahn: As in "cp path/to/boot/initrd.img-3.19.0-15-generic path/to/casper/initrd.lz" | 09:01 |
| opiwahn | infinity: yes.. you meant that | 09:02 |
| infinity | rbasak: On second though, I'll sleep. Please fix the golang-pty thing I rejected, and we'll talk docker itself when I wake up. | 09:06 |
| opiwahn | infinity: before you go to bed.. let me thank you again for such great help, patience.. | 09:07 |
| rbasak | infinity: o/ | 09:07 |
| rbasak | infinity: OK, looking | 09:07 |
| * rbasak looks at 47 new emails! | 09:08 | |
| infinity | rbasak: Oh, sure, now you show up. | 09:08 |
| rbasak | :) | 09:09 |
| infinity | rbasak: Have 5 minutes for a quick mumble... In 5 minutes? | 09:09 |
| rbasak | infinity: sure | 09:09 |
| infinity | rbasak: Should be able to clear this all up and be happy by morning. | 09:09 |
| infinity | rbasak: Alright. I'm going to grab the nightcap I was planning on putting myself to sleep with, then you can sing me a lullabye on mumble. | 09:09 |
| ekarlso | noone that knows why https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1457078 < isn't fixed ? | 09:11 |
| ubottu | Ubuntu bug 1457078 in network-manager-strongswan (Ubuntu) "L2TP client support for PSK removed from 15.04" [Undecided,Confirmed] | 09:11 |
| ekarlso | I can't use my VPN at all atm | 09:11 |
| * rbasak mumbles | 09:14 | |
| rbasak | infinity: https://git.launchpad.net/~ubuntu-server/+git/docker-backport-tools/tree/all | 09:15 |
| ekarlso | noone in this chan that knows the nm stuff ? | 09:22 |
| pitti | rbasak: could I hand the apache2 merge back to you? | 10:19 |
| rbasak | pitti: I actually did it already. It's stuck in proposed. | 10:34 |
| rbasak | (I'll sort that out when I get a chance) | 10:35 |
| pitti | rbasak: ah great; I had a faint recall that we talked about this before | 10:35 |
| pitti | * amd64: ltsp-cluster-control | 10:35 |
| rbasak | Yeah it's Ubuntu only and just needs its dependencies fixing | 10:35 |
| pitti | rbasak: ah, does the new version finally drop the apache2-mpm-* transitionals? | 10:36 |
| rbasak | Yes | 10:36 |
| pitti | ah ok, that sounds simple enough then | 10:36 |
| === greyback__ is now known as greyback | ||
| opiwahn | did this change from 14.04 to 15.04? I customized an ubuntu-live-cd.. an entry in my "isolinux.cfg" boots with parameter "text" the text-only mode... remastering 15.04 this entry still boots gui... something changed here?? | 10:46 |
| pitti | opiwahn: ah yes, our lightdm.service doesn't check for "text" | 10:48 |
| pitti | bug report appreciated | 10:48 |
| opiwahn | what can I do? | 10:48 |
| pitti | in /lib/systemd/system/lightdm.service, add ConditionKernelCommandLine=!text to the [Unit] section | 10:48 |
| opiwahn | ok. I'll try and give you feedback | 10:49 |
| pragomer | opiwahn: hello | 11:17 |
| === MacSlow is now known as MacSlow|lunch | ||
| opiwahn | pitti: I added this line to lightdm.service... after rebuild with boot-option "text" the system hangs on "rc-local.service" | 11:34 |
| opiwahn | pitti: this is my file: http://pastebin.com/C05ZEfnL | 11:35 |
| opiwahn | although I added ConditionKernelCommandLine=!text to lightdm.service boot-option "text" does not work anymore | 11:38 |
| seb128 | budgets for? | 11:43 |
| opiwahn | I added this line to lightdm.service... after rebuild with boot-option "text" the system hangs on "rc-local.service" it says "A start job is running for Wait for ...en to Quit" | 11:46 |
| opiwahn | built a initramfs script that should block harddisks (blockdev --setro /dev/sd*).... but it says /dev/sd* not found.. is it possible that a this stage of boot /dev/sda etc.. are not yet ready?? | 11:51 |
| pitti | opiwahn: please boot with systemd.debug-shell, then ctrl+alt+F9 when it hangs, and check systemctl status rc-local.service -- do you do anything funky in there? | 11:51 |
| pitti | opiwahn: yes, they very likely are not yet | 11:52 |
| pitti | not in init-top/ | 11:52 |
| opiwahn | pitti: ah.. ok.. what would be the right place to put the script in to block these devices? | 11:53 |
| opiwahn | pitti: you mean if I edited rc-local.service? nope | 11:53 |
| opiwahn | pitti: where to put such a script? http://snag.gy/4WtQp.jpg | 11:54 |
| opiwahn | how do I boot with systemd.debug-shell ? | 11:55 |
| pitti | same place as "text" | 12:00 |
| pitti | i. e. kernel command line | 12:00 |
| opiwahn | ok I try | 12:00 |
| opiwahn | pitti: found out the right place would be local-premount :-) | 12:00 |
| mardy | pitti: sorry to bother you again :-) is there a way to get my unique connection name with dbus-python, or do I have to manually call "Hello"? | 12:09 |
| teward | pitti: got a question for you with regards to apport hooks, 'cause i'm a little lost. Can apport hooks grab the output for a given command (not a log file!) for a package post installation failure, so when the bug is filed in 15.04 and up, we can get usable output and information rather than nothing useful from the existing apport handling for a package? | 12:16 |
| teward | (everyone says you're the person to poke on it) | 12:16 |
| mardy | pitti: actually, I cannot even call Hello myself: "dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: Already handled an Hello message" | 12:17 |
| === _salem is now known as salem_ | ||
| mardy | pitti: nevermind found it by using the source (bus.get_unique_name() -- looks like it's undocumented) | 12:30 |
| === mvo_ is now known as mvo | ||
| opiwahn | at what stage of initrd script: http://snag.gy/4WtQp.jpg are devices /dev/sda e.g. ready to use ? | 12:36 |
| pitti | mardy: I don't know, I'm afraid; nothing in http://dbus.freedesktop.org/doc/dbus-python/api/ ? | 12:59 |
| pitti | mardy: ah, great! | 12:59 |
| pitti | teward: sure, hooks can run arbitrary stuff; there's even an apport.hookutils convenience wrapper for it | 13:00 |
| pitti | teward: apport.hookutils.command_output() | 13:00 |
| === MacSlow|lunch is now known as MacSlow | ||
| pstolowski | hi! i need to access an arm64 box to debug an issue with unit tests of unity-scopes-api, can somebody help me with getting an access? | 13:09 |
| cjwatson | pstolowski: you want #is, ask for access to the porter boxes | 13:10 |
| pstolowski | cjwatson, k, thanks! | 13:11 |
| cjwatson | (#is internal that is) | 13:11 |
| cjwatson | pstolowski: https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes | 13:11 |
| pstolowski | ack | 13:11 |
| smoser | pitti, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt | 13:17 |
| smoser | http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L107 | 13:17 |
| pitti | smoser: ah, nice! thank you | 13:17 |
| teward | pitti: i'm horribly new to the apport hooks stuff, and embarrasingly so. Do you have syntax documented anywhere for that, and potentially a general example of that in use currently somewhere? | 13:21 |
| teward | Next question is testing the apport hook, and that's the next question. Final question is how do you include the apport hook inside of a package for inclusion in the repositories? | 13:21 |
| pitti | teward: "grep -r command_output /usr/share/apport/package-hooks/" has plenty of examples | 13:21 |
| teward | pitti: and the last part, about including in the packaging, I didn't find clear documentation on that, though I was hunting it last night when really tired | 13:22 |
| pitti | teward: or look at this for the API docs: python3 -c 'import apport.hookutils; help(apport.hookutils)' | 13:22 |
| teward | about when micahg poked me in -motu | 13:22 |
| pitti | teward: /usr/share/doc/apport/package-hooks.txt.gz is the first documentation you should read | 13:22 |
| teward | thanks, i'mma read all that. sorry for picking your brain on this :/ | 13:23 |
| pitti | teward: test> put it into /usr/share/apport/package-hooks/, and run "apport-bug yourbinarypackage" | 13:23 |
| pitti | teward: then you see the details of collected information in the window; just don't send it then | 13:23 |
| mdeslaur | The nss package has "libnss3-tools:native (>= 2:3.19-1-1~) <cross>" in Build-Depends, but the upload to Ubuntu fails with "invalid Build-Depends field; cannot be parsed by apt: Problem Parsing Dependency" | 13:24 |
| mdeslaur | I've never seen that format before, is that supported in Ubuntu? | 13:24 |
| pitti | teward: packaging> either use dh_apport (man dh_apport, in the dh-apport package), or just normal dh_install and put the file into the right place/name | 13:24 |
| pitti | mdeslaur: it's a realatively new debian thing called "build profiles" | 13:25 |
| pitti | mdeslaur: https://wiki.debian.org/BuildProfileSpec | 13:25 |
| mdeslaur | pitti: ah! thanks for the searchable term | 13:25 |
| pitti | mdeslaur: most probably Launchpad doesn't yet know about it | 13:26 |
| pitti | it's a kind of "make doko happier" feature :) | 13:26 |
| mdeslaur | oh, wow, I didn't know doko could be made happy :) | 13:27 |
| teward | pitti: thanks again. and sorry for buggin you for documentation links and such. At least I have a start point now, thanks! | 13:27 |
| pitti | teward: no worries, that's what IRC is for :) | 13:27 |
| pitti | teward: please let me know if you run into difficulties | 13:27 |
| teward | pitti: i likely will, python is NOT my forte | 13:28 |
| teward | i have a general understanding of it, enough to interpret semi-intelligible scripts and such, but ehh | 13:29 |
| pitti | teward: then I guess looking at the existing hooks and adapting them to your need is best | 13:30 |
| pitti | teward: most hooks should be simple, like collecting an extra log file or command output or two | 13:30 |
| teward | pitti: exactly, although the headache is that it's a post-installation failure - some have been ApacheAlreadyBindingTo80 issues, some have been failed configurations by the end users (i.e. something odd and nonstandard) | 13:31 |
| teward | and since systemd it's been even less diagnosable | 13:31 |
| teward | it used to spit errors out nicely. now it just 'fails' with no usable error data in apt logs | 13:31 |
| teward | pitti: i assume in the documentation there's a selective-case for the hooks such that if it's a package install/postinstall/upgrade/postupgrade failure during apt, it will only trigger then? | 13:32 |
| teward | we don't need `journalctl -xe` or `systemctl status nginx.service` for other bugs yet... | 13:33 |
| teward | (and I assume that's documented as well) | 13:33 |
| teward | (so I should just start reading xD) | 13:33 |
| pitti | teward: the hook can look at report['ProblemType'] | 13:46 |
| pitti | teward: that's "Crash", "Bug", or for your case "Package" | 13:46 |
| pitti | teward: the hook will always be called when you report something against that package, it can conditionally do/evaluate stuff based on ProblemType and the keys it has in the report object | 13:47 |
| barry | cjwatson: well, it looks like i must have released lazr.delegates 2.0.2 back in january and yet somehow managed to not check any of that into bzr or tag it. can't find it on any machine. must have been my evil twin, so now i'm going to unfutz that and try to get a 2.0.3 out in a bit | 14:27 |
| teward | pitti: right, i knew the hook would always get called, hence wanting to do some different things per problemtype | 14:27 |
| teward | pitti: thanks again | 14:27 |
| cjwatson | barry: Yikes. OK ... | 14:27 |
| barry | cjwatson: at least i have the tarball and it wasn't much | 14:28 |
| teward | um... general question, but would an SRU to add in an apport hook for a package even be considered? I only ask because with Vivid, we currently have a bunch of ambiguous bugs all for the same version all for failed-to-install, and nobody's providing additional info when we ask for it except maybe one guy on one bug. | 14:29 |
| teward | and adding an apport hook would solve that ambiguity problem. | 14:29 |
| teward | ('cause we can't diagnose bugs, even, in the current state of things) | 14:30 |
| teward | (for nginx) | 14:30 |
| barry | cjwatson: okay, 2.0.3 tagged and pushed. if you want to give it a quick look/test i can wait a bit before spinning the release | 14:41 |
| barry | gonna make some tea | 14:42 |
| doko | jamespage, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778058 -std=gnu99 should help | 14:50 |
| ubottu | Debian bug 778058 in src:percona-xtradb-cluster-galera-2.x "percona-xtradb-cluster-galera-2.x: ftbfs with GCC-5" [Serious,Open] | 14:50 |
| cjwatson | barry: looks fine by eye, I expect you can just push that | 14:52 |
| barry | cjwatson: thanks. releasing | 14:54 |
| barry | cjwatson: done | 15:09 |
| cjwatson | thanks | 15:09 |
| cjwatson | will poke again at lazr.restful in a bit then :) | 15:09 |
| pitti | mvo: is there a python-apt'ish way of getting a list/iterator of all apt sources? | 15:29 |
| pitti | mvo: I mean the "deb[-src] ..." lines in sources.list and sources.list.d/ | 15:29 |
| mvo | pitti: yes, some high level stuff even "pydoc aptsource" | 15:30 |
| pitti | mvo: oh, nice! So I create an aptsources.sourceslist.SourcesList() and then what? | 15:32 |
| pitti | mvo: oh, it's an iterator, nice! | 15:32 |
| mvo | pitti: there should be some example code and even some documentation | 15:32 |
| mvo | pitti: https://apt.alioth.debian.org/python-apt-doc/library/aptsources.sourceslist.html | 15:33 |
| mvo | pitti: https://apt.alioth.debian.org/python-apt-doc/library/aptsources.distro.html might also be interessting | 15:33 |
| pitti | mvo: perfekt, danke sehr! | 15:35 |
| === espy is now known as awe | ||
| doko | xnox, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages ftbfs on ppc64el and arm64 :-/ | 16:07 |
| doko | no, everywhere | 16:07 |
| xnox | doko: boost1.55 is 98abi only, boost1.57+ is c++11 abi. | 16:08 |
| xnox | doko: you want 1.57 from experimental. | 16:08 |
| xnox | doko: boost1.55 fixed build failures, for reverse-deps, that compile with gcc5 & 98abi. | 16:09 |
| doko | xnox, still no 1.58? | 16:10 |
| xnox | not yet, no. | 16:10 |
| xnox | didn't have time to do it yet. I guess I should work on that and other build failures asap. | 16:10 |
| xnox | doko: did you poke icu futher to determine if it will require transition or not? | 16:10 |
| doko | xnox, feel free to upload to the ppa mentioned above | 16:10 |
| xnox | i hope it doesn't, but who knows. | 16:11 |
| doko | xnox, no, just rebuilt with GCC 5 | 16:11 |
| doko | in the same ppa | 16:11 |
| xnox | doko: ok. let me check if I have upload rights there. | 16:11 |
| xnox | yes i do. good. | 16:11 |
| teward | pitti: what does one do if there's an AssertionError on the thing | 16:27 |
| teward | (for apport hooks) | 16:28 |
| === dbarth__ is now known as dbarth | ||
| === msbrown is now known as msbrown-afk | ||
| teward | oop nevermind | 16:36 |
| ogra_ | lol ... so debian goes back to ffmpeg ? | 17:03 |
| * ogra_ just saw the news, thats funny | 17:03 | |
| hich-em | hey sabdfl | 17:59 |
| hich-em | Neo31, | 18:04 |
| hich-em | hak lehna | 18:04 |
| hich-em | Neo31, | 18:05 |
| smoser | anyone able to validate my vague memory that at one point apt was not checking the checksum of Translation-* files | 18:06 |
| TJ- | smoser: That sounds familiar; I was dealing with a lot of bugs like that due to captive portals a while ago | 18:10 |
| === athairus is now known as afkthairus | ||
| teward | did pitty leave until tomorrow? | 18:12 |
| teward | pitti* | 18:12 |
| * teward hates autocorrect | 18:12 | |
| teward | so, i have one issue - I'm prompting the user in my apport hooks as to whether to include certain files. | 18:16 |
| teward | Problem is: Apport asks the same set of questions twice | 18:17 |
| teward | not sure whether it's my code or what | 18:17 |
| teward | other than pitti, is there anyone here who knows enough about apport hooks to try and diagnose the issue i'm seeing with my apport hook for a specific package? | 18:55 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| teward | is there a way to determine whether upstart or systemd are actually in use on a given system? (Some people use Upstart, some use SystemD, on their 15.04 systems...) | 19:49 |
| teward | like some file or some python that can be used as part of an apport hook | 19:49 |
| tarpman | teward: reportbug contains a snippet that tries to guess the active init system, I'd copy that | 19:50 |
| teward | so there's no easy way then | 19:53 |
| sarnold | teward: readlink /proc/1/exe might get you there | 19:53 |
| teward | sarnold: that worked for systemd on 15.04, didn't work 14.04 | 19:53 |
| teward | with upstart | 19:53 |
| teward | i know one guy who has upstart on 15.04 instead, because they're odd but eh | 19:53 |
| sarnold | teward: oh? I didn't realize 14.04 could boot with systemd well enough to use.. | 19:54 |
| teward | sarnold: it's a three pronged test | 19:54 |
| teward | sysvinit, systemd, or upstart | 19:54 |
| teward | sarnold: trying to make a 'global' apport hook :/ | 19:54 |
| sarnold | ahh | 19:55 |
| teward | such that it can NOT run the systemd gathering commands if systemd isn't present | 19:55 |
| teward | (because it will blow up in our face if we try) | 19:55 |
| teward | what I need is pitti to be here but I missed em a while ago for a followup | 19:57 |
| teward | sarnold: is it safe to assume that for 15.04 and up it's likely Upstart handling things? | 19:57 |
| teward | s/upstart/systemd/ | 19:57 |
| teward | god I am tired | 19:57 |
| sarnold | teward: it is the official; I think that makes sense. | 19:57 |
| teward | ok. | 19:58 |
| teward | because upstart and sysvinit, stderr is caught in the dpkg terminal log apparently | 19:58 |
| teward | but systemd, it holds it internal | 19:58 |
| teward | and just says "There is a problem" | 19:58 |
| teward | it's the nginx-bugs-not-having-sufficient-details problem that i'm finally attacking with the whole of my brain | 19:58 |
| sarnold | woo :) | 19:59 |
| teward | and thanks to pitti, i've got the bare minimum in apport hooks to diagnose the postinstallation scripts failed problem | 19:59 |
| teward | but me being the person i am, tryin to expand it - ask if the user wants to include the error.log, nginx.conf, and enabled site configs, which could contain sensitive info, with the report, for Crash and Bug type bugs | 19:59 |
| teward | those ones are easy | 20:00 |
| teward | but making the part to gather the stuff systemd doesn't put out to the logs is a systemd only thing, so i'll have to use that in the interim until pitti's back to spotcheck my code and give insights | 20:00 |
| teward | BEFORE putting in for SRU consideration for Vivid, and before uploading to Vivid | 20:00 |
| teward | s/Vivid/Wily/ | 20:00 |
| teward | ehh, whatever, too tired | 20:01 |
| sarnold | don't forget to exclude ssl keys and passwords :) | 20:02 |
| teward | sarnold: mmm, well, i was considering that if those are included forcing the sensitivity to Private | 20:03 |
| teward | but then i realized, ehhhh, that'd be annoying to me | 20:03 |
| teward | so i may leave that out | 20:03 |
| teward | the key important log file is error.log though | 20:03 |
| teward | that has IP addrs | 20:03 |
| teward | sarnold: how much do you know about apport hooks? | 20:04 |
| teward | tarpman: ^ same q | 20:04 |
| sarnold | teward: nothing; I just see the collected data in launchpad | 20:04 |
| teward | 'cause I get an erroneus "Error: COmmand exited with stats 3" error with command_output | 20:05 |
| teward | i really need pitti here :/ | 20:05 |
| tarpman | teward: no idea apport apport stuff, just your mention of init-detection caught my eye | 20:05 |
| teward | tarpman: yeah, that's something I'd love to incorporate into the apport hooks to NOT have systemd commands if upstart is present but eh | 20:05 |
| teward | i guess i'll stop by tomorrow morning and see if pitti is around | 20:06 |
| tarpman | teward: specifically, http://sources.debian.net/src/reportbug/6.6.3/reportbug/utils.py/#L1230 | 20:06 |
| tarpman | pretty easy | 20:06 |
| teward | tarpman: how accurate is it in Debian? | 20:08 |
| teward | fairly accurate? | 20:08 |
| tarpman | teward: haven't heard of any false results. the systemd one is definitely the supported way of detecting systemd, at least | 20:10 |
| teward | mmm, indeed | 20:10 |
| teward | sarnold: i'm definitely glad though i know have a baseline for the 'ambiguous bugs' problem now, with these TWO LINES we get all the information we need for systemd and postinst fails | 20:12 |
| teward | baseline fix* | 20:13 |
| === rbanffy-lunch is now known as rbanffy | ||
| === afkthairus is now known as athairus | ||
| === salem_ is now known as _salem | ||
| sarnold | teward: sweet :) there's certainlu enough 'postinst returns 1' errors.. | 21:57 |
| sarnold | teward: knocking off the nginx errors would be a nice start :) | 21:57 |
| teward | sarnold: the start point there: get USABLE debug info | 22:28 |
| teward | 'cause currently it's horridly unuseful **** there now | 22:28 |
| teward | -server even agreed when i went on a minirant last night | 22:28 |
| mwhudson_ | hm | 22:35 |
| mwhudson_ | when i do | 22:35 |
| mwhudson_ | sudo dpkg --add-architecture armhf | 22:35 |
| mwhudson_ | on my laptop, apt-get update complains | 22:35 |
| mwhudson_ | because the armhf stuff is on ports.ubuntu.com, not archive | 22:36 |
| teward | stupid question: why're you adding armhf arch? | 22:36 |
| mwhudson_ | oh, i guess i need to put [arch=] in sources.list a bunch | 22:36 |
| mwhudson_ | teward: hoping to be able to run stuff with qemu-arm-static | 22:36 |
| mwhudson_ | maybe that's silly | 22:37 |
| mwhudson_ | perhaps i should just make a chroot instead | 22:37 |
| teward | mwhudson_: eheheh... FWIW I have a pi coming in for when I need to run arm stuff. And I have an sbuild enviro to local-build armhf stuff, although that sometimes asplodes just like the ppa builders do | 22:38 |
| mwhudson_ | well i have a dragonboard too | 22:38 |
| mwhudson_ | but sometimes i just have my laptop | 22:38 |
| mwhudson_ | (which has arm64 installed on it, but the armhf chroot on there doesn't require qemu games) | 22:39 |
| === mwhudson_ is now known as mwhudson | ||
| === mwhudson is now known as Guest82160 | ||
| === Guest82160 is now known as mwhudson | ||
| teward | mmm, stupid question, how does one use dh_installapport / dh_apport in the package? Is it automated or is there something i have to drop into the rules file? | 23:23 |
| teward | i'm a little confused on implementation/use of dh_apport is all | 23:24 |
| teward | (to work with the apport hooks for a given package) | 23:24 |
| infinity | teward: Manpages tend to explain these things. | 23:36 |
| teward | infinity: i didn't glean anything special from the manpage, but then again, i'm fairly tired having bashed my head against python all day | 23:36 |
| teward | and i am an idiot, it explains it perfectly | 23:36 |
| * teward facedesks | 23:36 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
