[12:17] <xnox> infinity, smoser - please elleborate if I am dissolusioned about the btrfs-progs/tools bug.... i thought i went with smoser over this before, and it should be all fine with a (transitional-package -> provides), no?
[12:17] <xnox> i don't believe i've done such a hack before, but i hoped it would be all fine like that.....
[12:54] <ginggs> xnox: hi! i think there are some issues with boost and python3.7, did you see my message in #-release?
[13:30] <ahasenack> hi guys,
[13:30] <ahasenack> I see that ldb is in cosmic-proposed for quite some time
[13:30] <ahasenack> I checked it out and all it needs is a samba rebuild
[13:30] <ahasenack> I have a samba MP prepared to bump it to 4.8.2 (from 4.7.6), but I hit a regression in a test suite
[13:31] <ahasenack> filed bug upstream and with debian, but can't tell when it will get some attention
[13:31] <ahasenack> so if somebody could perhaps do a no-change rebuild/upload of cosmic's current samba, that should unblock libldb (which is a sync)
[13:31] <ahasenack> better do that now than closer to the release I think
[13:32] <ahasenack> upstream bug I opened: https://bugzilla.samba.org/show_bug.cgi?id=13486
[13:32] <ubottu> bugzilla.samba.org bug 13486 in File services "CIFS guest connection can't read back file it just created in mode 0600" [Normal,New]
[13:32] <ahasenack> debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902431
[13:32] <ubottu> Debian bug 902431 in samba "samba: cifs guest connection can't read back 0600 file it just created" [Normal,Open]
[13:32] <ahasenack> I also emailed samba@
=== osx is now known as Majoe
[13:32] <ahasenack> but no thread ensued
[13:34] <ahasenack> this is one of the failing tests: https://git.launchpad.net/qa-regression-testing/tree/scripts/test-samba.py#n763
[13:35] <ahasenack> it fails at https://git.launchpad.net/qa-regression-testing/tree/scripts/test-samba.py#n785 (when trying to write to the mkstemp file that was just created)
[13:56] <lubuntuuser> anyone knows the command-line name for TUI installer?
[15:59] <dmj_s76> Trevinho: Any chance to get the fix to https://bugzilla.gnome.org/show_bug.cgi?id=786929 backported for 18.04?
[15:59] <ubottu> Gnome bug 786929 in general "Attaching a monitor to laptop while in suspend and then waking up laptop will reliably crash gnome-shell" [Major,Resolved: fixed]
[16:04] <Trevinho> dmj_s76: would love to, althoug there's a bit of changes in mutter and g-s too, so I'd prefer to stay a bit on master then we'll backport to gnome-3-28 branch and thus we'll pick it from there
[16:05] <dmj_s76> Thanks, want to make sure suspend works reliably for users :)
[16:05] <Trevinho> I agree
[17:23] <cybernout> does any one here know the command ( bash ) , that would do the same thing as , the "Clear All" on 18.04  messages tray : https://i.stack.imgur.com/VlcPe.png
[17:24] <nacc> cybernout: i'm not sure there is necessarily anything exposed for that
[17:25] <nacc> cybernout: you may want to ask #gnome?
[17:28] <cybernout> thought ubuntu is using a modified version.. and not the default gnome one
[17:29] <cybernout> but ok , i will try there ;)
[17:34] <cybernout> by the way, there seems to be no limit the the messages that can get there, after a while it gets really clutterd
[17:35] <cybernout> in that way its an ubuntu problem as well
[17:54] <cjwatson> Generally when people ask you to talk to upstream they aren't denying that it's an Ubuntu problem too, just saying where the most effective place to solve the problem would be
[18:05] <cybernout> no problem, i understand ..
[18:05] <nacc> cybernout: what cjwatson said; i mean, yes, ubuntu is a downstream of gnome, but i'd imagine if there is a cli version of that tool, #gnome would know immediately :)
[18:05] <cybernout> trying to write a wrapper to avoid problem, thanks for the feedback
[18:05] <nacc> cybernout: why is that a problem, btw? If you don't acknowledge the messages there ...
[18:07] <cybernout> public space computer, after a day running its eating resources
[18:08] <nacc> cybernout: oh i see, if it's public, why even have the notification tray?
[18:09] <nacc> i wonder if it's disable-able (maybe with tweaks, etc.)
[18:09] <nacc> cybernout: but, tbh, i think you want #ubuntu at this point :)
[18:09] <nacc> cybernout: or #gnome, as i mentioned
[18:11] <cybernout> moving from 16.04 to 18.04 created some problems with lockdown scripts that also used desktop notifications to inform user about usage , any way thanks..
[18:12] <cybernout> bye and keep up the good work
[18:12]  * cybernout afk
[21:06] <ahasenack> it looks like for exim4 debian only maintains the debian/ directory in git: https://salsa.debian.org/exim-team/exim4
[21:06] <ahasenack> is that something each team decides, and how does one build a source package from that usually?
[21:06] <ahasenack> I'm assuming scripts or tools exist, otherwise I'll just do it manually
[21:07] <ahasenack> my motive is pushing an ubuntu delta up to debian, I want to make an MP there, but it's the first time I see this structure
[21:07] <ahasenack> (in salsa)
[21:25] <xnox> ahasenack, debuild can build that
[21:26] <ahasenack> xnox: just plain debuild in that git checkout that only has debian/ ?
[21:26] <xnox> ahasenack, it prints many warnings "ignoring deletion of <every single upstream file>" but otherwise it is fine.
[21:26] <xnox> ahasenack, yes.
[21:26]  * ahasenack tries
[21:26] <xnox> ahasenack, one needs orig tarball in ../ e.g. with pull-debian-source -d exim4 for example
[21:27] <ahasenack> yep
[21:27] <xnox> and well, build a source package $ debuild -S, obviously =) it will fail to build binaries ;-)
[21:27] <xnox> or like unpack tarball and move in '.git' and $ git checkout debian/
[21:42] <ahasenack> xnox: worked, thanks
[22:41] <infinity> xnox: Oh, I didn't notice the provides.  It's still generally not good practice to depend on a virtual instead of a real package, mind you, but you're right that the provides makes removal less dire.
[22:49] <xnox> infinity, it will be easier once all the things with old name are dead =/
[22:51] <xnox> infinity, if it makes things happier, we can change the dep in curtin; but the installer code will continue to install the old (virtual) package name
[22:52] <xnox> (installer code inside curtin that is)