[00:38] <nacc> mdeslaur: i believe LP: #1669764 is now fix-committed for zesty (it's in z-p)
[12:24] <tinoco> could someone review LP: #1670659 and close it as won't fix if agrees to same conclusion ?
[12:31] <cpaelzer> tinoco: here
[12:31]  * cpaelzer reading
[12:31] <tinoco> cpaelzer: o/ tks
[12:32] <cpaelzer> tinoco: so you reported, nominated and want me to close - and all that in 19 minutes :-)
[12:32] <cpaelzer> tinoco: I guess this is just a dump of work you already did right?
[12:32] <tinoco> cpaelzer: yep, took me 2 hours yesterday
[12:32] <tinoco> but to review is just follow the idea
[12:33] <tinoco> cpaelzer: unfortunately its not "so good" because of line breaks, maybe its best to download txt from comment
[12:33] <tinoco> for the comments on every stack frame
[12:34] <cpaelzer> tinoco: I think download as text is only for long posts
[12:34] <cpaelzer> but I can of course copy and read
[12:35] <tinoco> cool. i had to understand libvirt logic for the monitor logging and its abstraction and all (for fun)
[12:35] <tinoco> but the main idea is pretty simple, you will see
[12:35] <tinoco> ill wait you
[12:46] <cpaelzer> tinoco: I'm with you and commented as well as updated the status
[12:46] <cpaelzer> tinoco: I've set some traps for optional extra work that you can opt-in or not however you want
[12:46] <tinoco> cpaelzer: checking
[12:46]  * cpaelzer <- bad hunter setting traps and warning about it
[12:47] <tinoco> cpaelzer: nice, ill get the apport cmds to show people how to check that was the error
[12:47] <tinoco> cpaelzer: tku very much for the review =)
[12:49] <cpaelzer> tinoco: there is a very similar discussion in the STS channel, you might have the first user of that script "at home" for you
[13:13] <viral_mutant> I am creating a DEB package. The config files in the package are always being created with 644 permissions. I am tring override_dh_install , install -D -m 0640, but that doesn’t seem to work
[13:13] <viral_mutant> where can I find the documentation for this ?
[13:22] <cjwatson> viral_mutant: Start by running the build with DH_VERBOSE=1 to see exactly what is operating on that file.
[13:23] <cjwatson> viral_mutant: But it's almost certainly dh_fixperms.
[13:24] <viral_mutant> cjwatson: meaning fixperms is modifying the perms ?
[13:24] <cjwatson> viral_mutant: That would be my guess.
[13:24] <viral_mutant> cjwatson: oh, that is the default for conf files ?
[13:25] <cjwatson> viral_mutant: There's generally not much point in having non-world-readable files be shipped by a package, since the packages themselves are usually available on the internet.  But you can write an override_dh_fixperms target if you have a good reason to make a different decision.
[13:25] <cjwatson> viral_mutant: dh_fixperms makes everything world-readable, with only a few exceptions.
[13:25] <cjwatson>         complex_doit("find $tmp ! -type l $find_options -print0",
[13:25] <cjwatson>                 "2>/dev/null | xargs -0r chmod go=rX,u+rw,a-s");
[13:26] <cjwatson> (there's a bunch more stuff in there, but I expect that's the relevant bit)
[13:27] <viral_mutant> ok, that is what is within fixperms ?
[13:29] <viral_mutant> I could not locate any specific chmod on my conf after the verbose output
[13:37] <viral_mutant> cjwatson: yes got it. It was indeed the code snippet you pasted
[13:39] <viral_mutant> cjwatson: how do I override it ?
[13:53] <cjwatson> viral_mutant: do you know how to write debhelper override rules in general?
[13:53] <viral_mutant> yes
[13:53] <viral_mutant> cjwatson: using -X option with dh_fixperms ?
[13:54] <cjwatson> viral_mutant: Yes, that would work fine.
[13:55] <viral_mutant> cjwatson: it would need just the conf file name or the complete path ?
[13:55] <cjwatson> man dh_fixperms
[13:55] <cjwatson> "Exclude files that contain item anywhere in their filename from having their permissions changed."
[13:56] <cjwatson> You can also do something like this if you need more flexibility:
[13:56] <cjwatson> override_dh_fixperms:
[13:56] <cjwatson>         dh_fixperms
[13:56] <cjwatson>         chmod ...
[13:56] <viral_mutant> also put in the chown in there ?
[13:58] <cjwatson> You didn't mention that before, but sure, if you need to.
[13:58] <cjwatson> A chown will only work sensibly if it's a user with a static ID; if it's dynamic, you'll need to do that in the maintainer scripts instead.
[14:00] <viral_mutant> I am creating the user in preinst with static ID
[14:00] <viral_mutant> but that seems to work fine with the install -o -g options
[14:00] <viral_mutant> only the -m is being disturbed by fixperms
[14:01] <viral_mutant> BTW, since I new to deb packaging, what is maintainer script ? Where should I look for documentation around the install options etc. ?
[14:02] <viral_mutant> is the post/pre inst/rm called the maintainer script ?
[14:02] <cjwatson> viral_mutant: It sounds like you're doing user creation wrongly, from your description.
[14:02] <cjwatson> viral_mutant: Can you go into more detail about what you're doing?
[14:02] <cjwatson> viral_mutant: Maintainer scripts are described in the policy manual; indeed, it's the collective term for {pre,post}{inst,rm}
[14:59] <rbasak> If a maintainer script fails because PATH isn't set sensibly, is that a maintainer script bug for relying on PATH? Or is that a reasonable assumption to make?
[14:59] <rbasak> /usr/bin I think.
[15:01] <cjwatson> rbasak: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s6.1
[15:01] <cjwatson> "Those programs, and any other program that one would expect to be in the PATH, should thus be invoked without an absolute pathname."
[15:02] <rbasak> Thanks!
[15:02] <rbasak> I was looking at the policy document but failed to find that part.
[15:03] <rbasak> nacc: so that's my answer for bug 1669831
[15:13] <rbasak> nacc: so wrt. 1aa0f46 in usd-importer, something I learned from the Launchpad team is to not try too hard to line things up after the brackets on a following line, as things tend to get pushed too far to the right. Instead, you can newline and single further indent straight after the '(', and then close ')' on another line afterwards. Looks nicer IMHO, so I thought I'd mention it. Not that I'm
[15:13] <rbasak> insisting on it or anything, just a suggestion.
[15:14] <rbasak> Although the only thing I haven't figured with that kind of thing is what to do in a long 'if' or 'for' statement, since then you need an additional indent, and things get confusing. I have never figured out a style I both like and that keeps the pep8 tool happy.
[15:15] <viral_mutant> cjwatson: I am creating deb package for openstack-swift. I am using our RHEL package as references
[15:15] <viral_mutant> In the preinst, creating ‘swift’ user and group using ‘addgroup’ and ‘adduser’ command
[15:15] <rbasak> viral_mutant: you know we already have swift packaged, right?
[15:16] <rbasak> Along with the rest of OpenStack?
[15:16] <viral_mutant> rbasak: yes
[15:18] <viral_mutant> The preinst also creates /etc/swift directory and sets ‘swift’ as owner. The addgroup and adduser is with specific UID/GID.In the rules files override for dh_install puts the conf files in /etc/swift directory with -o -g as ‘swift’ and -m640
[15:18] <viral_mutant> this 640 is what was not working for me
[15:19] <viral_mutant> cjwatson: you mentioned that I might be wrongly doing user creation ?
[15:20] <cjwatson> If you're using dynamic IDs, then there's no guarantee that they'll be present when debian/rules runs, or have the same ID on the installed system.  I forget exactly what happens in the latter case.
[15:20] <cjwatson> (It may work - I suspect .debs store ownership by name.  But there's still the former problem.)
[15:21] <cjwatson> You should look at what the existing Ubuntu swift packages do here.
[15:21] <cjwatson> I have no idea exactly what they do, but it probably has the benefit of working :-)
[15:26] <viral_mutant> cjwatson: yes, I will surely look into the Ubuntu debian/ dir for reference. Thanks for your help, it really solved some issues in deb installation :)
[15:28] <viral_mutant> rbasak: We have a forked out code from Openstack community and lot of changes going in. So I cannot use Ubuntu packages. I have been assigned the humongous task to build our own DEB packages from the code :(
[16:22] <bdmurray> xnox: In bug 1668802 you mention "jounal files" are those things that already show up in apport bug reports in Launchpad? If so what are they called? JournalErrors.txt? journal.txt?
[16:25] <xnox> bdmurray, when you say "apport bugreports" which ones do you? apart from this launchpad bug report, i don't see any others.
[16:25] <bdmurray> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1619844
[16:25] <xnox> JournalErrors.txt is already parsed text output which is sans corrupt entries, i'm interested in raw /var/log/journal/*/* files
[16:26] <xnox> raw, because it would include everything, not just error/warning messages.
[16:26] <bdmurray> xnox: In that bug report some stuff is collected by apport and makes it to Launchpad, but doesn't end up at errors.ubuntu.com. We could change that if it would help.
[16:27] <bdmurray> change that by either modifying the apport package hook for systemd or allowing whoopsie to upload already existing info in the report to errors
[16:27] <xnox> although it's hard to get those logs, if the logger itself is what is crashing (journal logs & journald) =))))))
[16:32] <bdmurray> xnox: I don't feel like that's an answer. Is there something we can do to get you the log files you need?
[16:32] <xnox> bdmurray, ideally we should be attaching all of /var/log/journal/*/* and /run/log/journal/*/* but it may be sensitive info; and can span multiple boots.
[16:32] <xnox> files themself; not the parsed output from $ journalctl
[16:33] <xnox> unrelated to that studied the logs on the shutdown/reboot hangs bug report and responded to it.
[16:33] <Laney> yeah not sure about that
[16:34] <Laney> the journal often contains a super lot of stuff
[16:34] <Laney> for me information about my mailboxes, and hints to my browsing history
[17:10] <bluefoxxx> http://pastebin.com/tdW1gRi9 This has been happening for the past few days
[17:10] <bluefoxxx> on yakkity
[17:37] <bluefoxxx> wtf
[17:38] <bluefoxxx> it happens if I install cups, but no hash mismatch if I install just the libgssapi3-heimdal package itself
[17:38] <bluefoxxx> COMPUTERS DON'T WORK THAT WAY.
[18:05] <freedwhayt> Hello, where is the apt PGP key in Ubuntu LiveCD? Thank you.
[18:49] <sarnold> freedwhayt: dunno about the live-cd. apt uses /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/
[18:50] <sarnold> freedwhayt: the 4096 bit RSA key has fingerprint "790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32" -- other keys are listed at https://wiki.ubuntu.com/SecurityTeam/FAQ#GPG_Keys_used_by_Ubuntu
[19:07] <freedwhayt> sarnold: Thank you for the hint I will do my best do decipher it.
[20:50] <mdeslaur> ogra_: did you just modify the tech board meeting on purpose?
[21:16] <Unit193> http://dev.deluge-torrent.org/wiki/ReleaseNotes/1.3.14: "WebUI users: Highly recommended to upgrade to this release as it contains a fix for CSRF vulnerability that has the real potential to compromise your machine."  that sounds fun.
[21:50] <tdaitx> slangasek, I have updated LP: #1637239 in case you want to sponsor that merge
[22:41] <bdmurray> xnox: Have you had a chance to look at the apport autopkgtest apt issue?