[00:54] <sarnold> bdmurray: hello! 1726297 hasn't retraced yet (CoreDump.gz is still attached), but was filed ~16 hours ago -- are the retracers happy?
[00:55] <bdmurray> sarnold: I just had something retraced
[00:55] <bdmurray> sarnold: Is it your bug?
[00:56] <sarnold> bdmurray: no, someone else's, but it's currently private security, and I don't want to open it with a coredump still attached, but it'd be nice to get usable data out of it first if we can
[00:56] <bdmurray> sarnold: do you know what arch the crash is?
[00:56] <sarnold> bdmurray: x86_64
[00:58] <bdmurray> sarnold: Hmm, well they tried! I'll dig into it tomorrow.
[00:58] <sarnold> bdmurray: thanks! :)
[01:01] <sarnold> bdmurray: a second similar case, x86_64, 17.10, 1726388 -- it also had the 'need-amd64-retrace' tag removed ~11 hours ago, but the CoreDump.gz is still attached and no new retraces
[06:37] <fabbione> doko: do you still maintain toolchain in ubuntu?
[07:43] <CoderEurope> https://www.youtube.com/watch?v=tE2PEzhA7IQ
[12:10] <TJ-> sil2100: ping? re your comments on upstream dbus bug 95263: unix fd in-flight counting broken
[12:11] <TJ-> ubottu: you're not that intelligent you know!
[12:11]  * TJ- nods
[13:42] <smoser> nn
[13:47] <sil2100> TJ-: hey! It's been a while since I last heard about that bug IIRC ;)
[13:48] <TJ-> sil2100: do you have 5 minutes to talk about what you recall?
[13:48] <sil2100> TJ-: hard to say, I wasn't directly encountering this issue, I was only a middle-man working on getting fixes released, not sure if I remember much of any importance
[13:48] <sil2100> What do you need to know?
[13:51] <TJ-> sil2100: Well, we have a user, maszlo, that both nacc and myself have been working with to debug an obscure issue. Lenovo T450, latest firmware, 17.10 upgrade from 17.04, acpi_osi="Windows 2015", etc. *only* when it starts on battery it fails to start. main reason is services fail because the rootfs is read-only. fsck in initrd succeeds, no issues.  *However* systemd-remount does remount rootfs
[13:51] <TJ-> read-write but *something* causes it to be put back into read-only mode...
[13:52] <TJ-> sil2100: ... we suspected laptop-mode-tools but having disabled that completely (.service and .timer and the polling) the issue still occurs. Then I noticed with "systemd.log_level=debug" that systemd starts reporting " Transport endpoint is not connected" and that eventually led me via systemd issue 2925 to dbus bug 95263
[13:53] <TJ-> sil2100: I checked 17.10 and saw we don't see to be carrying the fix from that dbus issue and wondered if you knew anything more
[13:53] <TJ-> s/see/seem/
[13:55] <jbicha> http://markshuttleworth.com/archives/1518
[13:59] <sil2100> TJ-: give me a moment to look at the original bug again
[14:00] <TJ-> sil2100: thanks.
[14:04] <sil2100> TJ-: you said we're not carrying the dbus fix in 17.10?
[14:05] <TJ-> sil2100: as far as I could tell from the changelog/version number, but the commit history looks a bit messed up since an accidental commit of the 1.11 branch into the 1.10
[14:06] <TJ-> sil2100: plus it was 4am when I was looking, after 12 hours chasing this!
[14:06] <sil2100> TJ-: ok, so from what I see we are carrying a fix for LP:#
[14:06] <sil2100> eh, rogue enter
[14:07] <sil2100> TJ-: ok, so from what I see we are carrying a fix for LP: #1591411 since zesty+ in dbus, but it's not the final fix that Simon proposed in the 95263 bug
[14:07] <sil2100> I guess dbus has the workaround that Simon proposed a bit earlier in the discussion
[14:08] <sil2100> i.e. we have this:
[14:08] <sil2100> http://launchpadlibrarian.net/290293124/dbus_1.10.10-1ubuntu1_1.10.10-1ubuntu2.diff.gz
[14:09] <sil2100> Do you think it's necessary to have the real fix, i.e. all the things mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=95263#c43
[14:10] <sil2100> ?
[14:10] <TJ-> sil2100: hmmm, the follow-on dbus bug was only commited for 1.11.6 in July this year... https://bugs.freedesktop.org/show_bug.cgi?id=95619#c10
[14:11] <TJ-> sil2100: I'm not even sure if this is the cause of the issue as yet, but the fact we're seeing Transport endpoints missing and connection errors makes me think it is related to these at least.
[14:13] <sil2100> TJ-: hmmm, maybe you could test that on a PPA-built dbus with all those fixes cherry-picked?
[14:13] <sil2100> Sorry I can't be of much help, I didn't have this issue so I was only working on what people were reporting back to me
[14:13] <TJ-> sil2100: I'll try to get the user to do that. After yesterday's marathon it'll be a few days before he's ready for that again. I'll talk to nacc too we can probably coordinate on it.
[14:14] <sil2100> TJ-: ok, if you need any help in that just give me a sign
[14:14] <TJ-> sil2100: same here, can't reproduce. this is the relevant dmesg, search for "Transport endpoint is not connected" to see where it seems to start the problems. http://paste.ubuntu.com/25804737
[14:15] <TJ-> My problem is, how the heck does the root file-system get returned to read-only mode!?
[14:41] <smoser> xnox: i'd really appreciate review of https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/330043
[14:41] <smoser> if i dont get some, or a suggestion that there is another planned way to do this comming "really soon", then i think i'll just upload it.
[14:43] <xnox> smoser, hm. I still want to review that =/ and i wanted to check how feasable it is to run systemd-networkd + netplan in the initramfs.
[14:43] <xnox> smoser, plus some of your concerns are odd. For example, if there is netplan in the root filesystems, surely the current initramfs is specific to said root filesystem, and thus initramfs should have same networking configs, no?
[14:44] <xnox> smoser, if initramfs is generic, the host is generic too, and not yet provisioned / configured, thus initramfs setup networking is fine for the target too.
[14:44] <xnox> smoser, cause imho writting match any, dhcp in netplan and simply running netplan apply is better than ipconfig, dhclient, etc.....
[14:45] <smoser> hm..
[14:45] <smoser> "the initramfs is generic" is basically never able to be determined.
[14:45] <smoser> and if someone gave kernel command line options, then they probably wanted those to be taken.
[14:47] <smoser> xnox: i guess just please review that... you are welcome to review the implementation, but the description of what happens is in the commit message. i think its fairly complete.
[14:48] <smoser> and you can see the rendered tests. they do not handle writing the
[14:48] <smoser> 'match', (see line 113.. that is not excercised in test cases)
[16:37] <fabbione> doko: thanks for taking care of https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1726711
[17:26] <smoser> is bionic "open" ?
[17:26] <smoser> can i upload?
[17:27] <smoser> i'm sure nacc or rbasak know ^
[17:27] <tumbleweed> launchpad doesn't even know about it yet https://launchpad.net/ubuntu/+series
[17:27] <tumbleweed> and the topic tracks such things
[17:28] <smoser> tumbleweed: gracias.
[17:30] <TJ-> How should package A that 'knows' it'll break package B, and declares a "Breaks: B", handle removal of B during a do-release-upgrade ?
[17:31] <tumbleweed> TJ- https://wiki.debian.org/PackageTransition
[17:31] <nacc> smoser: per /topic, not open (and no ubuntu-anounce email yet)
[17:31] <nacc> tumbleweed: there is a bb-series placeholder, which i believe will get renamed
[17:31] <tumbleweed> yes, which means if you do an upload for bionic...
[17:34] <TJ-> tumbleweed: 17.10 systemd declares "Breaks: laptop-mode-tools" but after a 17.04>17.10 d-r-u l.m.t remained. should that 'Breaks' be a "Conflicts" then?
[17:35] <tumbleweed> Breaks should be fine, but that doesn't guarantee that systemd will win the fight
[17:35] <tumbleweed> I presume it does for priority reasons, though? Not actually sure how safe that is
[17:37] <nacc> TJ-: it's a versioend breaks
[17:37] <nacc> TJ-: and the version in artful is new enough
[17:37] <nacc> perhaps the version is wrong?
[17:37] <bdmurray> If I want to report a bug about the desktop search feature in 17.10 is that gnome-shell too?
[17:37] <TJ-> nacc: where do you see the version for the Breaks? I don't see it with apt-cache depends
[17:38] <nacc> TJ-: apt show systemd
[17:38] <nacc> TJ-: laptop-mode-tools (<< 1.68~
[17:38] <nacc> added in systemd 229-6
[17:38] <TJ-> nacc: that's a pain! apt-cache depends ought to show that!
[17:38] <nacc> from debian bug #762018
[17:39] <nacc> TJ-: --^ lol
[17:39] <nacc> TJ-: that might be the same bug??
[17:39] <TJ-> which is what we have with bug 1726930
[17:41] <nacc> TJ-: i wonder if l-m-t broke itself
[17:41] <nacc> TJ-: would take some archaeology as to what was the 'fix' in 1.68 and wehther it's still there
[17:41] <nacc> TJ-: I can do that in a bit
[17:41] <TJ-> nacc: right. it looks like it re-broke doesn't it?
[17:42] <TJ-> nacc: i've still not figured out how the rootfs returns to read-only mode even though systemd-remount returns success
[18:50] <elbrus> Laney: can you confirm that https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=fe627aa was indeed only to catch NEW packages that FTBFS?
[19:04] <mdeslaur> kees: TB?
[19:17] <guest2239> any OP's in here?
[19:18] <dax> (note for others: i just answered in another channel)
[20:23] <powersj> nacc: Looks like `apt-cache showsrc src_package` and look for Section is one way of determining what component (universe vs main) a package is from?
[20:23] <powersj> is there an easier/faster way to determine if something is in main vs universe vs multiverse?
[21:01] <jbicha> a slower way is to use rmadison, you can also use a web browser https://people.canonical.com/~ubuntu-archive/madison.cgi
[22:00] <xnox> powersj, seeded-in-ubuntu
[22:04] <powersj> xnox, is it correct to say: if it returns any images a package is seeded in therefore it must be in main?
[22:04] <xnox> powersj, no.
[22:05] <xnox> powersj, ubuntu-desktop ubuntu-server and supported are in main.
[22:05] <xnox> powersj, what is your actual quection? I find $ reverse-depends -r artful -c main -b src:foo -> what i use the most
[22:05] <xnox> which tells me all the reverese depends of something, that are in main =)
[22:05] <powersj> xnox: give a package or src package, is the package currently in main
[22:06] <xnox> powersj, .... because, what?
[22:06] <powersj> I think looking at the package-team-mapping at those 3 teams you point out and checking if the src package is present would be fastest in my case
[22:06] <xnox> powersj, there is supported field on the package, for LTS, which is 5yrs for things in main.
[22:07] <xnox> powersj, what do you actually care about, if it's in main or not? to check upload rights?
[22:07] <xnox> there is ubuntu-upload-permission for that?
[22:07] <xnox> there is ubuntu-upload-permission for that.
[22:07] <xnox> powersj, what do you intend to do with the information that something is in main or not.
[22:07] <xnox> powersj, also you usually need to include restricted too.
[23:34] <bdmurray> sarnold: FYI I sorted out what was wrong and I'm gonna mark a bunch of failures for retracing
[23:34] <sarnold> bdmurray: excellent, thanks!
[23:35] <sarnold> bdmurray: that reminds me that some ofthe stacktraces I've seen in private bugs had far more memory contents in them than I've expected. I've deleted a handful of them before opening bugs up to the public, and that feels pretty new too
[23:36] <bdmurray> sarnold: zip it
[23:36] <bdmurray> sarnold: don't be bringing me more issues
[23:37] <sarnold> bdmurray: hehe :)
[23:37] <sarnold> bdmurray: https://bugs.launchpad.net/ubuntu/+source/dnscrypt-proxy/+bug/1703186/+activity