[00:08] <mdeslaur> valorie: wait a day and I should appear by itself when we do monday triage
[00:09] <mdeslaur> it*
[00:13] <valorie> ok
[00:19] <tsimonq2> valorie: also I saw that Debian applied these fixes, that might help too
[00:19] <tsimonq2> s/applied/released/
[00:21] <valorie> excellent
[00:26] <tsimonq2> valorie: You might want to point them towards bug 1745635 as it seems to be the tracking bug for this.
[00:26] <ubottu> bug 1745635 in clamav (Ubuntu) "Security release 0.99.3 available (CVE-2017-12374 CVE-2017-12375 CVE-2017-12376 CVE-2017-12377 CVE-2017-12378 CVE-2017-12379 CVE-2017-12380)" [Undecided,Confirmed] https://launchpad.net/bugs/1745635
[00:28] <valorie> tsimonq2: thanks for that -- passed along
[05:41] <cpaelzer> bdrung: hi
[05:41] <cpaelzer> bdrung: I think smb will do the next iproute2 merge somewhere along kernel 4.15
=== maclin1 is now known as maclin
[07:00] <cpaelzer> I'm wondering which way to install a file to use
[07:00] <cpaelzer> dh_install doe sonly want to move, but not rename
[07:00] <cpaelzer> suggestions are made to dh-exec
[07:00] <cpaelzer> but I need mv + rename + chmod afterwards
[07:01] <cpaelzer> should I just go for a few lines in d/rules instead?
[07:30] <alkisg> Hi, some package in the Ubuntu archive has some security issue (details deliberately omitted) that ends up in all /home/*/.config folders being world-readable. Is it possible to reset that directory to its proper permissions for all users with a package upgrade, or is that prohibited by the Debian policy?
[07:31] <cpaelzer> alkisg: if it can be safely detected that the reason access is open is the bug in said package an update can fix it up I think
[07:31] <cpaelzer> alkisg: but otherwise I think it is bad to mess with access controls kind of unconditionally
[07:31] <cpaelzer> after all people might have set up the same intentionally
[07:31] <cpaelzer> therfore the "is it safe to detect" question
[07:32] <cpaelzer> in general LP bugs can be opened private + security which allos discussions on non disclosed security issues
[07:32] <alkisg> cpaelzer: very nice, where would you put the detect/restore login, in postinst or in an /etc/xdg/autostart script?
[07:32] <cpaelzer> alkisg: depends too much on the actual issue that caused it to answer, I'd expect a postinst actually
[07:33] <cpaelzer> as packages could be used on non graphical environments - so xdg/autostart would never trigger
[07:33] <alkisg> Hmm indeed, although they may also be installed when /home is unmounted :/
[07:34] <alkisg> Thanks, I think a private+security bug report might be the best place to discuss this
[07:48] <alkisg> I filed LP: #1745929.
[07:48] <ubottu> Error: Launchpad bug 1745929 could not be found
[07:54] <valorie> alkisg: none of use will be able to look at it unless we're part of the security team
[07:54] <valorie> thanks for doing that
[07:54] <alkisg> valorie: the package maintainer (I assigned the bug to him) will still be able to see it, right?
[07:55] <valorie> that I don't know
[07:55] <Unit193> "Should"
[07:55] <alkisg> I think I've seen some security issues that were assigned to my packages in the past, so I believe so...
[07:55] <alkisg> (wrongly assigned to my packages :P :D)
[07:55] <valorie> I would assume that the maintainer will see the proposed patch at least
[07:56] <Unit193> My favorite are errors.ubuntu.com bugs, contain no info and just link to a place you can't view details (though to be fair, a quick poke and people usually are very willing to help by pasting stuff into the report.)
[08:10] <juliank> ugh, systemd-journal uses 100% CPU again.
[08:10] <juliank> ah / remounted r/o again
[08:10] <juliank> yay
[08:10] <Unit193> Why'd you do that?
[08:10] <Unit193> You're silly.
[08:11] <juliank> btrfs remounted itself r/o because it was "full"
[08:16] <juliank> And I'm back.
[08:16] <juliank> Rebooted, deleted a few snapshots of / and added another 100 MB to the LV it's on
[08:17] <juliank> now my vg has no free space left :(
[08:17] <juliank> I'm not sure I like btrfs remounting r/o when it's out of space
[08:19] <juliank> or journald going insane on CPU usage
[08:26] <alkisg> Remount-ro on errors sounds sane, 100% cpu, not so much
[08:34] <juliank> alkisg: well at least it helps you notice the problem!
[08:34] <alkisg> Haha, an effective way :D
[09:45] <juliank> jibel: I think I figured u-r-u / bug 1744722 out  https://code.launchpad.net/~juliank/ubuntu-release-upgrader/valid-release/+merge/336761
[09:45] <ubottu> bug 1744722 in ubuntu-release-upgrader (Ubuntu) "Unknown bad source brings up during 'zesty' to 'artful' upgrade and It break the process" [Critical,In progress] https://launchpad.net/bugs/1744722
[09:46] <juliank> The goal was to check if the entry we are creating is valid. Checking that the dist is a valid toDist seems to be the right thing
[09:47] <juliank> Rather than just checking if the old entry was a valid old distribution
[09:48] <jibel> juliank, ok, but actually wouldn't the right fix to change the current entries to old-releases.u.c if it's a valid mirror?
[09:49] <jibel> then recheck if there is a basemetapackage and proceed with the upgrade
[09:49] <jibel> nowhere we tell the user that its release is EOL afaik
[09:51] <juliank> huh
[09:52] <juliank> Doesn't it look at the meta package for the target release?
[09:52]  * juliank not sure what it does
[09:52] <jibel> juliank, let me check again but I don't think so. I does the veirfication before rewriting sources.list
[09:52] <juliank> In any case this fix seems like a fixed variant of your fix
[09:53] <jibel> juliank, indeed, sounds good to me
=== Spads_ is now known as Spads
[10:15] <juliank> jibel: So I'd merge and upload this then. Unfortunately, I don't see how we could SRU that to artful - we need a proper test case for it.
[10:16] <juliank> If only we had the sources.list
[10:17] <juliank> jibel: Ah, got a test case
[10:18] <jibel> juliank, we have the sources.list from the reporter. I'm testing your fix with his list
=== ret2libc_ is now known as ret2libc
[10:19] <juliank> jibel: I added "deb https://dl.bintray.com/aluxian/deb/ stable main" to the test data which causes the problem to occur
[10:20] <juliank> It then generates deb http://archive.ubuntu.com/ubuntu stable main # auto generated by ubuntu-release-upgrader
[10:21] <juliank> It's not even that code generating that entry
[10:23] <juliank> Maybe I just ran the test wrong :D
[10:24] <juliank> Yeah, it works
[10:28] <juliank> or not
[10:28] <juliank> well it also worked before
[10:33] <jibel> juliank, for the test you need a valid mirror with an obsolete release and an entry with a third part repo eg a ppa
[10:33] <jibel> third party*
[10:37] <juliank> jibel: I'm trying to write a test case for it, but I have not found anything that breaks yet
[10:39] <juliank> It breaks and fixes when I run tests/test_sources_list.py manually, but if I run via nose-tests it works in both cases.
[10:39] <juliank> the test suite is of course, somewhat broken, as usual.
[10:40] <juliank> (if you run tests with python-apt, you basically have to run apt_pkg init at least in a setupClass or something)
[10:40] <juliank> otherwise some state might stick around from other tests
[10:45] <juliank> Oh, my test case is broken.
[10:45] <juliank> # deb https://dl.bintray.com/aluxian/deb/ stable main # disabled on upgrade to gutsy
[10:45] <juliank> is there all the time
[10:45] <juliank> but before, there also is
[10:45] <juliank> deb http://archive.ubuntu.com/ubuntu stable main # auto generated by ubuntu-release-upgrader
[10:54] <juliank> there are a ton of bugs in the test suite because we only check that the expected sources are there, not any unexpected
[11:02] <juliank> jibel: I added/modified a test case now in https://code.launchpad.net/~juliank/ubuntu-release-upgrader/valid-release/+merge/336761 and verified that it was broken before and passes now
[12:27] <jbicha> xnox: please open a new bug for your comment at LP: #400573
[12:27] <ubottu> Launchpad bug 400573 in ubuntu-meta (Ubuntu) "[include in live-cd] wvdial (1.60.1+nmu2)" [Wishlist,Fix released] https://launchpad.net/bugs/400573
[12:33] <xnox> jbicha, the comment was on purpose, such that people who are subscribed to that bug get the notification. As I was trying to reach them. If there is no responses there for a while, I will be opening a brand new bug to "demote" wvdial.
[12:34] <jbicha> could you go ahead and open that bug now? :)
[12:35] <jbicha> I am a fan of demoting/removing stuff earlier in the release cycle if possible so there's more time to notice problems :)
[12:40] <tsimonq2> xnox: I'll pull the OpenSSL 1.1 patch in during the Qt 5.9.4 transition I'm currently prepping in Bileto if that's OK?
[12:43] <xnox> tsimonq2, if that does dual-build, where the qt builds with either openssls, then yes, please.
[12:43] <xnox> tsimonq2, if it does "require openssl1.1.0 only" then that would obviously will ftbfs.
[12:44] <xnox> tsimonq2, still discussing when and how to introduce openssl1.1.0
[12:45] <tsimonq2> xnox: ok, I'll take a closer look later and let you know
[12:45] <xnox> tsimonq2, tah!
[13:04] <sforshee> doko: this is from your test rebuild - https://launchpadlibrarian.net/353098637/buildlog_ubuntu-bionic-arm64.linux_4.13.0-17.20_BUILDING.txt.gz
[13:58] <doko> sforshee: ohh, it's in superseded section :-/  does 4.15 build?
[14:03] <sforshee> doko: I don't think I've tried 4.15 yet with that binutils, will test
[14:04] <doko> sforshee: maybe wait for the final 2.30, once it's built
[14:04] <sforshee> ack
[14:07] <juliank> doko: ld from proposed segfaults on armhf trying to build systemd: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3114/+build/14286752
[14:07] <juliank> it also does not build on i386 or arm64
[14:08] <juliank> i386: /usr/bin/ld: /tmp/ccp5bmno.ltrans0.ltrans.o(.text+0x3362): unresolvable R_386_PLT32 relocation against symbol `__udivdi3'
[14:08] <juliank> arm64: ld: /usr/lib/crt0-efi-aarch64.o: relocation R_AARCH64_ABS16 against `EFI_SUBSYSTEM' can not be used when making a shared object
[14:12] <jibel> could someone re-run the failed autopkgtest for network-manager on ppc64el https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#network-manager
[14:17] <seb128> jibel, done
[14:17] <jibel> seb128, thanks
[14:17] <seb128> yw!
=== Spads_ is now known as Spads
[15:32] <ginggs> How can I figure out why the build-dependencies of hwloc-contrib and eztrace-contrib are not installable?
[15:44] <seb128> xnox, slangasek, is systemd/persistant log something you are (still?) looking at for the LTS?
[15:44] <seb128> there was an ubuntu-devel@ list discussion but it didn't get any real traction
[15:44] <xnox> seb128, it's enabled, not sure if it has migrated yet.
[15:45] <seb128> xnox, oh ok, might be good to follow up on that list discussion to say that then :)
[15:45] <seb128> good news
[15:45] <xnox> ack
[15:45] <seb128> yeah, looks like it migrated
[15:51] <LocutusOfBorg> juliank, https://sourceware.org/bugzilla/show_bug.cgi?id=22751 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888478 :)
[15:51] <ubottu> sourceware.org bug 22751 in ld "LTO broken for libgcc libcalls" [Normal,Resolved: fixed]
[15:51] <ubottu> Debian bug 888478 in binutils "binutils: lto broken for libgcc libcalls" [Serious,Open]
[16:25] <juliank> cpaelzer: Oh, you updated sanlock. Now we just need to get it into main
[16:25] <juliank> lvm2 wants it :(
[16:32] <cpaelzer> juliank: well I didn't want ti MIR it
[16:33] <cpaelzer> juliank: I just wanted to make it somewhat usable
[16:33] <cpaelzer> like able to install :-)
[16:33] <juliank> cpaelzer: :)
[16:33] <cpaelzer> juliank: it didn't seem MIR-worth to me when I looked at the code this afternoon
[16:33] <cpaelzer> juliank: could you go without in lvm2 ?
[16:34] <juliank> cpaelzer: Well lvm2-lockd needs it. some people want lvm2-lockd.
[16:35] <GunnarHj> doko: Did you see my ping at #ubuntu-desktop?
[16:35] <GunnarHj> https://irclogs.ubuntu.com/2018/01/29/%23ubuntu-desktop.html#t12:31
[16:35] <juliank> cpaelzer: nacc knows more about that https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1741986
[16:35] <ubottu> Launchpad bug 1741986 in lvm2 (Ubuntu) "Please merge lvm2 from Debian unstable for lvmlockd and sanlock support" [Wishlist,Fix committed]
[16:36] <juliank> cpaelzer: But I'm sure we'll figure something out eventually
[16:36] <juliank> We could also demote lvm2-lockd to universe
[16:36] <juliank> but I don't want to decide that :D
[16:44] <TJ-> juliank: Yes, we very much would like lvm2 with proper lock support, several users of it
[16:44] <TJ-> juliank: nacc took it on when we dealt with it recently
[16:50] <juliank> TJ-: Right. It will go to universe it seems, unless a team MIRs it.
[16:52] <TJ-> juliank: that'll be good; saves having to maintain a custom build :)
[16:55] <slangasek> xnox: you've enabled persistent log in systemd?  What steps have you taken to avoid double-logging to syslog?
[16:55]  * juliank thinks double logging sounds like a good idea for now
[16:57] <juliank> Well, at least you don't lose logs that way :)
[17:24] <bbear> you can still double lose them.
[17:57] <tsimonq2> kor
[17:57] <tsimonq2> (mistype)
[18:02] <xnox> slangasek, given that one has full timestamps, and the other one does not, i choose to keep data.
[18:03] <xnox> slangasek, let's talk about enabling nano-timestamps in syslog by default, and thus breaking everyone's syslog parsing regexp-es? aka all the logwatch / graylisting things.
[18:03] <xnox> slangasek, and enable journald module of syslog by default
[18:09] <slangasek> xnox: the full timestamps are in the journal, yes?  I'm not saying we shouldn't do the persistent journal, I'm asking how we get rid of the duplication of data that is syslog
[18:13] <xnox> slangasek, well, imho we currently have dataloss since `systemclt status` and `journalctl` do not read syslog files and the user gets the "no logs available" messages and/or incomplete output.
[18:13] <xnox> slangasek, imho syslog should be pulling data from journal using the journald module that it has.
[18:14] <slangasek> xnox: I think you're misunderstanding my objection
[18:14] <xnox> slangasek, I think you are misunderstanding our users =)
[18:14] <slangasek> enabling persistent journal - yes, +1
[18:14] <xnox> slangasek, all of our users want more logs, not less.
[18:14] <slangasek> still having data logged to syslog, causing redundant disk usage - -1
[18:14] <xnox> well.
[18:15] <xnox> slangasek, our users expect to have both plain text logs; and useful `systemctl status` output.
[18:15] <xnox> i have as many people shouting at me that we shall not remove plain text logs; and that we should have complete journals across reboots.
[18:15] <xnox> slangasek, note that xenial's journalctl fails to read bionic's .journal files =/
[18:16] <slangasek> xnox: so I'll gather a bunch of people on my side to also shout about the wasted disk space ;-)
[18:16] <xnox> and everything can read plain text syslog.
[18:16] <slangasek> and then it'll be well-balanced
[18:16] <xnox> slangasek, disk space is not wasted, as logs are rotated.....
[18:17] <xnox> slangasek, oh, i totally do have roughly equal amount of people shouting at me about all the logs and disk space =)
[18:17] <xnox> at the moment, keep everything prevents dataloss.
[18:17]  * xnox .... log-loss?
[18:19] <xnox> slangasek, do you know of a way to support 1) plain text logging 2) remote syslog logging 3) full journals -> without duplication?
[18:20] <alkisg> Plain text logging isn't very important if there's a command that can display plain text output...
[18:20] <slangasek> xnox: nope :)
[18:20] <xnox> slangasek, cause to have full remote logging journal should be pushed to syslog, and to not have duplicate disk space somehow plain text syslog and journal should be picked for some/all/split logs.
[18:22] <slangasek> xnox: right - so rsyslog has all kinds of clever filtering, and I think it would be appropriate for us to configure rsyslog by default to not write to disk logs that systemd is also writing to the journal
[18:22] <slangasek> while having systemd continue to /send/ them to syslog, for remote logging etc
[18:23] <xnox> slangasek, interesting.
[19:03] <jbicha> !dmb-ping
[19:03] <ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
=== Spads__ is now known as Spads