[00:20] rbasak: in retrospect, should it not be reconstruct/ as that, in our current workflow, indicates the deconstructed one :) where each version has been broken into its individual changes, one per commit [00:23] nacc: good point. [00:25] rbasak: how are you still awake? :) [00:25] rbasak: i do like reconstruct/ and deconstruct/ but that's just because it's funny to me [00:26] nacc: I can't think of anything better :) [00:27] rbasak: when you drop a change from the logical sequence because it was added and removed, do you document that in the final changelog? Just mention its an add/remove and that's the reason to drop it? [00:29] nacc: no, I don't mention it at all. That it was added and removed is still in the changelog against the uploads where that happened. From the point of view of the merge, the logical delta didn't contain it (any more), so it is neither a remaining change nor one that is dropped as a result of the merge. It was dropped before, and changelogged at the point where that happened. [00:30] nacc: in a way, I don't "drop a change from the logical sequence" either. I squash the add and remove together and end up with nothing. [00:30] rbasak: yep, that makes sense, just wanted to verify it :) [00:31] rbasak: i guess if we really want to use our workflow via that tool, i could tag old/debian new/debian and old/ubuntu in the process, too [00:31] since they are defined relative to the invocation basically [00:33] Yes, but those tags would collide with a subsequent merge. I'm not sure if that's OK or not, since now we expect people to follow the importer tree a little bit more. [00:33] OTOH it is trivial to delete or overwrite those of course. [00:33] rbasak: ah true -- i guess what i can do is provide it as a paramter to the helper script (and if so, it can use -f) [00:33] rbasak: or provide some user opportunity to say override the existing tag if found [00:33] I have no objection either way [00:34] rbasak: ack, not a priority, wsa just realizing we have all the data (esp. old/debian which can be potentially hard to track down otehrwise) [00:42] Logan: i just sent a message to the debian maintainers on if they want me to send the debdiff up or if we can just drop the delta (as in they'll never take it) -- if i don't hear back, worst case i'll merge it for now and we'll hopefully be able to sync again during 16.10 sometime [00:45] nacc: thanks so much! [00:46] there are a lot of those bootstrapping deltas for PHP packages, not sure how Debian will address them [00:58] Logan: yeah, my intention (the best of them) was to get them all pushed up by now [00:58] Logan: clearly not achieved [00:58] and well, they also ended up not being 100% necessary as the php5/php7 binary packages became coinstallable [00:58] like the day i finished bootstrapping all the deps :) === juliank is now known as Guest35539 === juliank_ is now known as juliank [06:47] cjwatson: thanks, so this is intended; I skipped the test in 3.20.9 now (without deb-src) [06:47] Good morning [07:05] xnox, infinity: meh -- aupkg02 (10.100.0.13) is AWOL *again* -- what on earth is wrong with that box :/ [07:11] hum, there's a race with bind mounts and zfs.. zpool can't be mounted if the directory is not empty, and bind mounts populate the directory before zpool gets mounted [07:14] tjaalton: What are you bind mounting? [07:15] rlaager: a directory behind the zpool to somewhere else [07:15] before I open up a bug (none found on LP), I still wanted to ask first if anybody else has seen "tar --exclude" being broken on Yakkety (and Stretch as it is the same)? [07:15] tjaalton: I'm not quite following the setup. [07:16] * cpaelzer is checking debian bugs atm ... [07:16] so the zpool is mounted to /srv, then I'd bind-mount /srv/foo elsewhere, but when the machine boots up the bind mount is created (and /srv/foo in the process) so the zpool doesn't get mounted because /srv isn't empty [07:18] tjaalton: Would symlinking /srv/foo meet your needs, instead of a bind mount? [07:18] how did you define the bindmount? [07:18] /srv/builds /n/builds none bind 0 0 [07:18] rlaager: it's for nfs [07:18] so not really [07:19] easier to just drop the bind mounts, it's not critical for me [07:20] just wondering if this is filed or should be [07:20] not a zfs bug.. [07:20] In that case, I'd probably add a systemd override (or whatever those .conf files are called) for zfs-mount.service that sets a Before= for the auto-generated unit for that bind mount. (I'm new to this systemd stuff, so that's more a suggestion than a known-working fix.) [07:21] well it has Before=local-fs.target [07:22] which probably should cover this [07:23] Wouldn't "srv-build.mount then zfs-mount.service then local-fs.target" be an order in which zfs-mount.service is still Before local-fs.target, but you'd experience this problem? [07:24] it would [07:24] because it should be later than zfs-mount [07:25] systemd-analyze dot may be useful [07:25] I'd try adding a Before=srv-build.mount (assuming that's the name of the autogenerated unit) and see if that resolves the race. I don't think there's a way to fix this generically (and completely) short of implementing a ZFS mount generator or something. [07:26] it seems like a difficult problem [07:27] I could just as easily imagine wanting the filesystem set up by /etc/fstab before doing any of the zfs things.. [07:34] jeebus, what a spaghetti it is (systemd.svg).. === stokachu_ is now known as stokachu === FourDollars_ is now known as FourDollars === Trevinho_ is now known as Trevinho === lfaraone_ is now known as lfaraone [08:47] PSA: I need to take down the http://autopkgtest.ubuntu.com/ web UI for a while for maintenance (disks running out of space) [08:47] this won't affect proposed-migration, just the web presentation === zsombi_ is now known as zsombi [09:24] are we experiencing an unintentional debian import freeze? [09:26] hm, I thought the same yesterday; I manually synced autopkgtest, but I thought I was just being impatient [09:27] then again the imports themselves seem to be rather slow, so maybe it's just that [09:28] 'limnoria' hasn't made it over at all. [09:33] File "/home/ubuntu-archive/ubuntu-archive-tools/auto-sync", line 500 [09:33] src.startswith("haskell-"): [09:34] * Laney fixs, runs manually === marcusto_ is now known as marcustomlinson [09:58] meh it's hitting errors downloading from launchpad === \b is now known as benonsoftware [10:07] pitti: http://autopkgtest.ubuntu.com/ => 403? [10:08] 10:47:18 pitti | PSA: I need to take down the http://autopkgtest.ubuntu.com/ web UI for a while for maintenance (disks running out of space) [10:08] 10:47:29 pitti | this won't affect proposed-migration, just the web presentation [10:08] mapreri: still ongoing, moving the gazillion files around is slooooow [10:09] pitti: ah, I see. too much backlog i didn't read it, sorry. [10:11] pitti: do you think you can make src:biniou migrate by ignore botch tests? (botch is just broken atm) === Saviq_ is now known as Saviq [10:18] BTW I see too many entangled transitions: poppler gdal gl2ps vtk6, and I fail to understand why all of them aren't migrating [10:18] * LocutusOfBorg is really bad at parsing update_output.txt [10:20] Laney: ah, sorry, my bad [10:20] (for the blatant syntax error) [10:21] cjwatson: No worries (but see #launchpad for me not being able to actually run it to completion) [10:22] LocutusOfBorg: i think suitesparse is entangled with most of them, and it now depends on metis. I file an MIR LP: #1588407 [10:22] Launchpad bug 1588407 in metis (Ubuntu) "[MIR] metis" [Undecided,New] https://launchpad.net/bugs/1588407 [10:24] oh, wrt suitesparse, did you see glpk and octave shown as red? [10:24] I didn't investigate yet [10:27] they seem false positive [10:36] LocutusOfBorg: yes, I saw that, I think false positive too. (auto-suitesparse) [10:37] yes, but still unsure about where the ben file failed ;) [10:46] LocutusOfBorg: you can use my awesome (not awesome [but does the job]) script to help untangle transitions like this https://paste.debian.net/713720/ and https://paste.debian.net/713723/ === bduncan_ is now known as bduncan [10:51] thanks Laney ! [10:54] question about the script output you pasted above [10:54] laney@raleigh> apt-get -oDir=/home/laney/.cache/brapt/aptroot -oDir::State::status=/home/laney/.cache/brapt/aptroot/status --dry-run install dynare liboctave3 libgl2ps0 ~ [10:55] obviously wrong, and indeed it can't work [10:55] that's not a script [10:55] apt-get install dynare liboctave3v5 libgl2ps1 <-- this works instead [10:55] that's a sample of me using it [10:55] the script is the first one... [10:55] I mean, I guess you ran it now, and I'm not sure why it tries to install the libraries from -release instead of -proposed [10:56] that is telling you that octave needs to be rebuilt and become a candidate for migration [10:57] because liboctave3 depends on a library which is going away [10:57] slangasek: any news on reviewing https://github.com/ltangvald/mysql-5.7/commit/fa6ea034692 [10:57] 9584373aee3b373cba0751fb81830 for me please? [10:57] liboctave3 is called liboctave3v5 on proposed [10:58] so, it is going away too [10:58] ... [11:00] elbrus: I think you should apply for dbconfig-common as you're maintaining it in Debian anyway. I don't know if there's any special requirement for a package in main. I'm not aware of one. [11:01] elbrus: for MOTU I think we'd expect to see a need or a recent history of sponsored uploads to that set of packages. [11:01] I guess that applies in general, but you de-facto upload to dbconfig-common regularly. [11:13] pitti: I notice you overrode qt4-x11 autopkgtest failures, did you consider qtbase-opensource-src too? the remaining failures seem related to the new KDE release and its dependency problems or other problems. qt4-x11 can't migrate to release pocket without doing it together with qtchooser and qtbase-opensource-src, due to Debian changes. [11:14] Mirv: I didn't wade through the qtbase-opensource-src regressions yet; if you checked them, fine for me [11:15] this would untangle at least some of the stuck stuff indeed [11:16] Mirv: hinted [11:16] hello. I have some old C knowledge and would like to write simpe time tracking app that appears in the top bar tray. where I should start to with it? Is quickly good for that? I would like to have something like hammster, but a littlbe bit different [11:16] akkonrad: #ubuntu-app-devel [11:16] pitti: thanks, yes I went through all them [11:17] akkonrad: probably the best place to start a personal app discussion for ubuntu [11:18] mapreri: need to wait until debci is back; ATM I can't decide if it got broken because of biniou, or dose3, or something else [11:24] tx ikonia ! === JanC is now known as Guest27710 === JanC_ is now known as JanC === _salem is now known as salem_ === hikiko is now known as hikiko|ln [13:12] rbasak: such as the cacti-spine updates ... === hikiko|ln is now known as hikiko [13:45] mterry: Hey! I replied to your comments in https://bugs.launchpad.net/ubuntu/+source/libertine/+bug/1588050. [13:45] Launchpad bug 1588050 in libertine (Ubuntu) "[MIR] libertine" [Undecided,Incomplete] [13:45] ChrisTownsend, oh yeah, sorry got distracted [13:45] * mterry replies [13:46] mterry: Sure, no worries. [13:58] elbrus: yes but that's a reason to have PPU for cacti-spine. === inaddy is now known as tinoco [14:08] can i get an archive admin or sru team member to NAC the curtin uploads that are in xenial and trusty and wily ? [14:15] smoser: just in the unapproved queue, or are they already accepted? [14:15] no curtin in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 at least [14:16] stgraber: around? Could you help with https://lists.ubuntu.com/archives/devel-permissions/2016-May/000930.html please? I did some research. It looks like these packages are only seeded in edubuntu/dvd, but it's excluded in packageset-report because "This would cause ubuntu-netbook to be sucked into Edubuntu, which has complicated effects." [14:17] pitti, xenail and trusty in -proposed wily in unapproved [14:17] stgraber: I presume there are no reasons to not put ltsp etc into the edubuntu packageset because that's where it would be by the automatic generation rules anyway if it weren't for that disablement? [14:18] stgraber: and if so, then should I add an exception, or can we add edubuntu/dvd to the list now that ubuntu-netboot isn't (I presume) relevant any more? [14:18] smoser: wily rejected [14:19] stgraber: (but if I add edubuntu/dvd to the list, I see many other changes too) [14:19] and i can re-upload for xenial and trusty then, right ? [14:20] smoser: yes; still at removing them, but you can reupload (needs a higher version number, though) [14:21] pitti, yeah, i'll just re-upload with new version and use -v to denchanges ? [14:21] genchanges. [14:21] *nod* [14:22] smoser: removed [14:22] although that wouldn't really have been necessary, if you have a new uplaod that'll trump the previous version anyway [14:24] pitti, thanks! [14:51] rbasak: can you paste the list of changes when whitelisting edubuntu/dvd? [14:52] stgraber: http://paste.ubuntu.com/16948158/ [14:53] stgraber: I'm not sure how to present that better. It'd be nice if packageset-push could work from a local source but I don't see an option for that. [15:01] rbasak: are all of those kde additions to the edubuntu set or to something else? [15:04] rbasak: not too sure what's going on with all those kubuntu bits in there... looks like the script thinks a bunch of them are somehow part of ubuntu-server too which is clearly wrong (that or I'm not reading that diff properly) [15:04] are you sure ... who knows, probably -server is nowadays KDE based without all of us knowing ;) [15:05] Hi, is there some problem with the uploading of package to ppa currently? dput command is working, but I don't get the mail (I double checked by sign key) [15:05] jfi: Can you provide the dput command so I can check logs? [15:06] cjwatson, dput ppa:jfi/ppa ./psensor_1.1.4-1ppaxenial2_source.changes [15:06] jfi: Logs say your key on the keyserver has expired [15:06] cjwatson, Oo [15:06] cjwatson, weird and a very bad idea, if I reached the expiration date of my key [15:07] cjwatson, thanks for the information [15:07] jfi: Yeah, I checked the keyserver and it has an expiration date of about 7 months ago [15:09] stgraber: will look but otp for an hour or so. [15:12] cjwatson, according to pgp it is set as 'never' expires, should I reupload the key or I am wrong and the key has really expired? [15:13] jfi: try reuploading it to the keyserver then [15:13] I forget what it does with keys that it thinks have already expired [15:14] you presumably removed the expiration date at some point but didn't send that to the keyserver [15:23] cjwatson, there is really something weird [15:23] cjwatson, I have desactivited my key [15:23] cjwatson, then redo an import [15:24] cjwatson, and it fails with the key XXXX cannot be validated because it has expired. [15:24] cjwatson, but: [15:24] pub 2048R/XXXXX created: 2010-11-14 expires: never usage: SCA [15:24] trust: ultimate validity: ultimate [15:25] (output of gpg --edit-key jeanfi@gmail.com) [15:33] rbasak: would it make sense to create a public wiki page under https://wiki.ubuntu.com/UbuntuDevelopment/Merging for our process & tooling? [16:01] nacc: it would be better served in the packaging guide, which still references I think the bzr method that is outdated [16:01] my two cents [16:04] rbasak: i'm also going to add a couple helper scripts, presuming i can script them: usd-import-commit-merge (which will do the parenting) and usd-import-tag-merge (which will take a -f flag to force the tagging). Ok with that? I'd like to document them in the public page for the git-workflow. [16:04] pitti, if you're still around and wanted to let my xenial , wily, trusty uploads for curtin into -proposed i'd appreciate it. [16:04] teward: link? this isn't yet official [16:05] nacc: sorry, IRCing from my phone [16:05] don't have eone [16:05] teward: it's ok, i'll find it [16:05] http://packaging.ubuntu.com/html/ ? [16:13] nacc: yeah, specifically http://packaging.ubuntu.com/html/udd-merging.html [16:13] but starting in the wiki is a better spot [16:14] let the doc team analyze and decide to update the packaging guide [16:14] teward: yeah, udd was more 'official' than this is ... although i'm being told it's going to the direction [16:14] *that direction :) [16:14] nacc: :P [16:14] sort of accidentally :) [16:15] nacc: problem is that udd guide doesn't work for Xenial+ [16:15] teward: but i'll use that page as a reference too, thanks! [16:15] teward: ack [16:15] nacc: case in point the nginx merges, though not even the git workflow worked for that one (nasty nasty merges!) [16:15] s/nginx merges/pending nginx merge/ [16:16] teward: since i lack the knowledge already, what was nasty about the merge that made the git workflow not work? [16:17] nacc: nfc, all I know is that the git workflow skipped over the addition of the dynamic module packages by Debian [16:17] but that was every merge workflow I've used in the past [16:17] solution: redo the delta, by hand, using Debian as a base :P [16:17] teward: hrm, i'd need to see the git tree to figure that out, i think [16:17] teward: i can do that locally :) [16:18] as, if there is a case where it simply doesn't work, i'd like to use it as an example of how to do the merge 'manually' still [16:18] nacc: edge case most likely, but i think it works in most cases [16:18] nacc: public wiki page> sure! [16:19] nacc: usd-import-commit-merge makes sense. I'm not sure I follow what usd-import-tag-merge does. [16:19] urgh i need lunch >.< [16:19] (back later) [16:19] nacc: thank you for the writeup to the ubuntu-server ML BTW. Perhaps it's time to take it wider and send also to ubuntu-devel? [16:19] nacc: UDD has a mailing list too, so we could move all discussion there if we wish. [16:20] rbasak: it would do the prep work of old/debian new/debian old/ubuntu tagging [16:20] rbasak: possibly needs a different name :) [16:20] figured they'd start out as 3 and then eventually get combined into one script with parameters [16:21] nacc: ah, I see. Yeah, sure. [16:21] nacc: if they're user tools we might want shorter names, too. [16:21] rbasak: yeah, i was hoping to write up some stuff on the wiki first, so i can use that as a reference, and send a summary to ubuntu-devel and i'm happy to include the udd list [16:21] rbasak: yeah :) [16:22] rbasak: i think it'd become `usd-merge (tag|reconstruct|merge)` [16:22] rbasak: to parallel `usd-import` [16:23] nacc: sounds good === tyhicks` is now known as tyhicks === Serge is now known as hallyn === salem_ is now known as _salem [21:16] I have a question about package hooks and apport - would it be sane to try and get information during a package installation failure of a webserver package such as whether default ports are currently bound to, etc. by executing other commands as part of the hook? [21:17] as well, would it be sane to gather information about the system such as CPU core information (number of processor cores seen by the system, etc) and such? Asking because there may be a race condition with regards to systemd and things [21:47] netstat or ss to find out if the port is free makes sense; I can't imagine processor information being useful but it's collected for other hooks [21:51] sarnold: was asking for processor because of a confirmed systemd/initscript race condition when starting nginx on 1CPU systems [21:51] sarnold: i'd love to be able to grab netstat data, but also nginx error.log if it exists [21:51] but, i need a little guidance to what's sane or not [21:51] (if i had my way, i'd grab all error logs from everywhere heh) [21:51] (for nginx) [21:51] heh, you get a race condition on 1 CPU but not on more CPUs? [21:52] JanC: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1581864 [21:52] Launchpad bug 1581864 in nginx (Ubuntu) "nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument" [Low,Confirmed] [21:52] usually it's the other way around ;) [21:52] non-critical race condition [21:52] 'cause it fixes itself [21:52] supposed race condition, but it still chokes? [21:52] s/fixes itself/doesn't break startup/ [21:53] with that not on my radar, though, knowing current listening ports is a plus, but getting error.log for nginx would be beneficial too in many cases [21:53] problem being, that's not always 'clean' to include [21:53] (sometimes, sensitive request data gets dumped there) [21:53] yeah sanitizing that feels likely to overlook a lot.. [21:53] I doubt if it happens on 1-CPU systems it can't happen on multi-CPU systems, although for that user it might only show with 1 [21:54] sarnold: a secondary problem is anything that doesn't use pure english characters and has multibyte characters is choking up the main apport hooks [21:54] sarnold: but that's something I can't fix :/ [21:54] oops forgot to plugin my laptop back in a few [21:55] teward: heh yeah more than a few apport hooks were useless when xenial was released.. [21:57] sarnold: because of the same reason I just stated? [21:58] yes [21:59] teward: I filed at least 1582992 and 1582950 -- I think I filed a third but it's since been fixed [22:01] sarnold: these need to be extended to 'apport' [22:01] not just libvirt or similar [22:01] because i'm seeing this in global hooks too [22:01] not just the local hooks [22:01] what's the third one? [22:02] I may have been thinking about 1580412 [22:05] teward: reproduced! [22:05] teward: in a lxc xenial container [22:05] nacc: the no-output thing? [22:05] teward: fully fresh `lxc launch ubuntu:xenial` [22:05] teward: the bugs you just linked [22:05] nginx failed to install :) [22:06] nacc: so its only in lxc? [22:06] nacc: mind doing further debugging? [22:06] because I don't have an lxc-capable system just here [22:06] teward: well, i use lxc for my reproductions cuz it's easy [22:06] i guess technically lxd :) [22:06] nacc: close enough, can you stab it to see why it's failing? [22:06] teward: yeah what do you need? [22:06] nacc: whatever the hell you can provide [22:06] specifically: [22:07] reproduction steps [22:07] let me paste what i just got first, so you can eyeball [22:07] http://paste.ubuntu.com/16965632/ [22:07] reproduction: lxc launch ubuntu:xenial; lxc exec bash [22:07] apt-get update; apt-get install apache2; apt-get install nginx; blammo [22:08] nacc: wait [22:08] so in that case, i know nginx wasn't already running, as it wasn't installed... [22:08] nacc: that's a conflict [22:08] nacc: apache and nginx both use the same port [22:08] 80 [22:08] for default [22:08] teward: then it shouldn't have allowed me to install? [22:08] nacc: that's why it fails, we didn't get logic ACK'd to test [22:08] or do you mean it's a configuration conflict? [22:08] nacc: default config conflict [22:08] let me show you the master bug on that [22:08] teward: ack, so ... 1588972 is simply that, no? [22:09] as they installed apache2 -> php -> nginx [22:09] afaict [22:09] https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1512344 [22:09] Launchpad bug 1512344 in nginx (Ubuntu) "[Master Bug] Package nginx-* failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (due to "Address in Use" issue)" [Undecided,Invalid] [22:09] nacc: that's the logical step, yes, but I want confirmation of that being the case [22:09] nacc: sarnold: any way to determine if it's running in an lxc/lxd container? [22:09] as in, within apport hooks [22:10] teward: well, i mean in both cases, they installed apache2 then nginx [22:10] nacc: ok, then that's the issue [22:10] are you sure they aren't both just this known master case? [22:10] want to help me triage? :P [22:10] nacc: well [22:10] teward: ack, i'll respond [22:10] nacc: this known master case is autodetected in apport dupe detection [22:10] AND all such cases show in systemctl -l [22:10] nacc: AND all such cases wouldn't start nginx [22:10] it'd just [emerg] crit error [22:10] and die [22:10] hrm [22:11] nacc: so unless you can inquire on both cases asking if it's in a container and if apache2 was installed first and is running on port 80 [22:11] and they respond as such [22:11] then i can't confirm it's a dupe of the master case [22:11] yep, i'll ask [22:11] (though, after getting that added to the list of known duplicate signatures, the number of new "bugs" dropped significantly) [22:12] nacc: thank you kindly [22:12] * teward now needs to scrounge together $650 to get his parents' internet upgraded to a sane setup/environment [22:12] teward: lxc maybe totally false positive, i just use it as my fast reproduction env, i doubt it is the underlying cause [22:12] nacc: hrm [22:13] lxc/lxd that is [22:13] right [22:13] my gut feeling is these are dupes, just based upon the output and such [22:13] nacc: i'm not sure how my VMs aren't reproducing this though, maybe containerization is important? [22:13] or does something odd? [22:13] teward: right, but in your VMs, did you install apache2 first? [22:14] nacc: no, but when I install apache2 first, then install nginx, it crits as shown in the bug [22:14] not the latest bug, the known one [22:14] and apport filing will trigger dupe detection [22:14] oh i see [22:14] right, but mine didn't, so what's different about being in a container ... hrm [22:14] nacc: my question exactly [22:14] mine failed the same as these two newer bugs [22:14] nacc: lxc/lxd usable inside a VM? [22:15] teward: to be sure, you started off with a fresh 16.04 VM? [22:15] (containerization/virtualization ception!) [22:15] teward: it should be, yeah [22:15] nacc: every time [22:15] hah, /bin/running-in-container is from upstart. thus not on xenial. [22:15] nacc: scratch-install base Ubuntu Server 16.04 x64 [22:15] teward: should just be an `apt-get install lxd` and you should be able to be up and running pretty easily [22:15] nacc: ack, i'll hunt that [22:15] teward: i'm presuming, i've not tried it in a VM :) [22:15] maybe stab Docker in a 14.04 [22:15] nested bridging, i guess :) [22:15] first, i have to fix DNS on my network [22:15] funny, i've only used lxd from within vms :) [22:15] sarnold: heh [22:15] sarnold: :) [22:16] we're just all dogfooding little bits, it's good :) [22:17] :p [22:18] sarnold: security/privacy wise, wouldn't getting netstat output be a cause for concern in terms of sanitizing IP addresses? [22:18] in cases of public-facing machines, IPs may be 'sensitive' [22:18] (whereas internal private IPs wouldn't be) [22:18] teward: I think there's loads of IPs in the logs.. [22:18] teward: i guess, worst-case, we know that in my specific lxc reproduction, the crit doesn't catch [22:18] nacc: i think i'll stab it myself [22:18] but if containerization doesn't catch the apport data right [22:18] then that's a HUGE issue [22:19] unless it's a known documented issue with lxc/d [22:19] nacc: thanks for the assist though on hunting this [22:19] it's been something plaguing me for a few weeks [22:19] with "WTH is with these bugs?!?!?" [22:20] teward: can you explain what catches the port-in-use? is it strictly apport's bug dupe detection? [22:20] nacc: I have to dig up the signature [22:21] teward: because in my paste, i see: "No apport report written because the error message indicates its a followup error from a previous failure." [22:21] so if it relies on apport, then maybe that's why it didn't trigger? [22:21] ubuntu bugpatterns [22:22] nacc: possibly, but if the previous failure wasn't caught either, then you still have the issue [22:22] nacc: http://bazaar.launchpad.net/~teward/apport/ubuntu-bugpatterns-nginx/revision/552 [22:22] Error: launchpad bug 552 not found [22:22] silence you [22:22] teward: http://paste.ubuntu.com/16966119/ [22:22] nacc: that's the merged revision to the bugpatterns for nginx [22:22] not crit, but emerg? [22:22] nacc: synonymous [22:22] [emerg] is nginx's log level for critical failures [22:22] k, that's what's in my lxc's journalctl [22:23] nacc: OK, we pull the journalctl data too [22:23] I should probably add a separate bugpattern for that [22:23] nacc: but that doesn't apply in the cases shown in the bugs either [22:23] because the other file on journalctl data would show it [22:23] and it doesn't show [22:23] yeah good point (and the same output is in my systemctl) [22:24] "Journalctl_Nginx.txt.txt" <-- also captured by apport hook [22:24] as the failures in dpkg have recommended, i pull in both [22:24] because that way we get both sides [22:24] yeah [22:24] so to do for me: extend the bugpatterns slightly to add in the second nginx pattern for journalctl detectino... [22:25] but that doesn't explain why that data's not showing up, nor why the program is actually listed as 'running' [22:25] nacc: only thing I can think of is systemctl fubar'd in the process and couldn't kill an older process [22:25] which *could* be the case if it's an upgrade bug [22:25] teward: ack, in my case, it's not listed as running at all, so it's different [22:25] yep [22:25] so i guess there are two issues to track down :) [22:25] :/ [22:26] i think for the two bugs you linked earlier, it's totally reasonable for them to be in incomplete while the submitter gives more complete information,a nd you've don your due diligence [22:26] and for this bug, if you are able to setup lxd, it should be easy to figure out why the dupe isn't getting detected (it could just be some ordering condition) [22:27] nacc: do me a favor and file a crash bug on it? [22:27] from inside the container [22:27] you can add in the details i asked [22:27] see if it catches [22:27] if apport isn't broken, it should catch [22:28] teward: although, if nginx is already running, and they installed apache2, wouldn't it have failed to install apache2? [22:28] very confusing state [22:28] nacc: i haven't poked the apache2 configs [22:28] teward: sure, .... how do i do that? :) [22:28] but theoretically? yes [22:28] file a crash bug that is :) [22:28] sarnold: what's the command to file an apport bug on a crash report? [22:28] apport-bug ... somethign something? [22:28] ubuntu-bug /var/crash/blah.crash? [22:28] where blah is the packagefailure [22:29] ack, found it [22:29] ugh [22:29] teward: one sec, something worrisome [22:30] "apport has died, killing init..." [Kernel Panic] [22:30] loljk [22:30] no, but i had restarted the container and nginx came up fine ... i wonder if that's why systemctl says it's running? that is, it failed to install, mabye they rebooted and then reported the bug? let me start a fresh container :) [22:31] nacc: thanks, if you can prove that's the case, all hail you :P [22:31]