[00:13] <xnox> hallyn, a more canonical name was taken
[00:32] <Unit193> The confusion exists with github.com/ubuntu/ \o/
[00:46] <xnox> Unit193, that's the other half of the company we don't speak to =)
[00:46] <xnox> muahahahahhaha
[00:51]  * Unit193 makes note to give xnox a good sanity check. :>
[00:55] <dpb1> hallyn: :)
[01:03] <slangasek> Unit193: like an autopkgtest, when the sanity check always comes back negative, it doesn't do you much good
[15:19] <Laibsch> Can somebody help me understand what's going on in bug 991471? It still affects bionic and I'd like to see what I can do to get it fixed. IOW, how does the automatic mounting happen?
[15:21] <Faux> The ticket says udisks2, presumably driven by gvfs or some other gnome automounting component. You've asked before, so presumably read the ticket. What else is there to know?
[15:22] <Laibsch> Well, it's me who set the component to udisks2 ;-)
[15:22] <Laibsch> I'm not entirely sure that's correct, but seems like the most likely candidate.
[15:23] <Faux> Presumably reproducing the problem isn't too hard if you have a system you don't mind installing udisks2 on, and a usb stick.
[15:23] <Laibsch> What I'd like to know for example is why in the case of a 2-device btrfs the automounter mounts it twice.  What is the command-line I can check where this goes astray.
[15:24] <Laibsch> Faux: I *am* affected by the problem
[15:24] <Laibsch> no need for a test system.
[15:24] <Faux> I imagine the automounter is very much "for device in new_devices; do mount $device /media/automounted$i; i=$((i+1)); done".
[15:24] <Laibsch> then the question is what populates $new_devices
[15:26] <Laibsch> I have to admit I simply don't know enough of what's going on under the hood.  That's why I'm here to ask.
[15:26] <Faux> The fact that those devices just appeared on the system? I don't think this is the appropriate place to discuss it, nor do I know anything about udisks2.
[15:26] <Laibsch> a 10-device btrfs is still just a single FS and should be mounted only once
[15:27] <Faux> I have a multi-device btrfs here and mount using /etc/fstab and it works fine. :)
[15:28] <Laibsch> In the past I've experienced it that one additional mount was added every hour or so.  You appear awfully non-chalant about this.  I can tell you it's highly annoying.
[15:28] <Laibsch> Yes, multi-FS btrfs in /etc/fstab are excluded from the problem
[15:28] <Laibsch> But then again, they do not show up in nautilus, etc. as automounts anyhow.
[15:29] <Faux> I don't mean to be rude, but this is almost certainly the wrong place, and I'm the wrong person.
[15:29] <Laibsch> OK
[15:29] <Laibsch> What is a better place?
[15:29] <Laibsch> I've already asked ubuntu+1.  And posed this question several times over the last few years.
[15:30] <Laibsch> somebody must know HOW automounting happens
[15:30] <Laibsch> that's all I'm trying to understand
[15:32] <xnox> Laibsch, it's just a property of btrfs, that all btrfs drives are added together to the total pool, no?
[15:33] <xnox> Laibsch, as in you cannot connected two sets of drives, with distict / disjoint btrfs pools and operate them separately.
[15:33] <Laibsch> not sure I get your question right, but other FS are also affected
[15:33] <Faux> xnox: No, you can have many btrfs filesystems made from many different partitions in a machine; it's not systemwide like that.
[15:34] <xnox> Laibsch, i don't see how any other FS is also affected. the bug is very btrfs specific, as far as I can tell.
[15:35] <xnox> or, the fact that generic functionality, doesn't work as expected with a special-case of advanced btrfs features.
[15:37] <Laibsch> I have to concede that in the bug tracker there is no mention of other FS, it's just something I seem to recall, but I've seen this for years now so I might be wrong
[15:41] <xnox> we used to have bugs with lvm snapshots being shown in nautilus over and over and over again, which was a bit ugly. that was fixed. but again, was specific to lvm features in that case.
[15:42] <Laibsch> what's a good place to discuss this?
[18:21] <bdmurray> xnox: Have you seen bug 1765724?
[18:22] <xnox> bdmurray, lovely
[18:22] <xnox> bdmurray, will debug
[18:22] <bdmurray> xnox: thanks!
[18:56] <ahasenack> hi, has anybody seen debhelper (or one of its tools) do this to a manpage:
[18:56] <ahasenack> ./usr/share/man/man3/pmem_deep_drain.3.gz.gz -> pmem_flush.3.gz
[18:56] <ahasenack> pmem_deep_drain.3 contains just a .so reference, so dh_installman correctly creates a symlink
[18:56] <ahasenack> but the package in the end is getting this double .gz :/
[18:56] <sarnold> .gz.gz ?
[18:56] <ahasenack> yeah
[18:56] <ahasenack> I used dh_installman -v
[18:56] <ahasenack> and it showed this:
[18:56] <ahasenack>         rm -f debian/libpmem-dev/usr/share/man/man3/pmem_deep_drain.3.gz
[18:56] <ahasenack>         ln -s pmem_flush.3 debian/libpmem-dev/usr/share/man/man3/pmem_deep_drain.3.gz
[18:56] <ahasenack> so up to that point it all seems correct
[18:57] <ahasenack> I also added -v to dh_install, and it all looks fine
[18:57] <ahasenack> but after the build, debian/*/usr/share/man/man3 has the double gz
[18:58] <ahasenack> I'm now adding find -type l to some build stages in d/rules via overrides to try to catch it
[19:04] <cjwatson> what does the .so line say?
[19:04] <cjwatson> ahasenack: ^-
[19:05] <ahasenack> checking
[19:05] <ahasenack> cjwatson:
[19:05] <ahasenack> $ cat doc/generated/pmem_deep_drain.3
[19:05] <ahasenack> .so pmem_flush.3
[19:06] <cjwatson> huh, I was at least half-expecting to see an extra .gz extension on the .so line there, but that seems correct.  in that case I have no immediate explanation, sounds like a debhelper bug then
[19:06] <ahasenack> ok, thanks anyway
[19:17]  * ahasenack intercepts dh_compress
[19:22] <cjwatson> ahasenack: just export DH_VERBOSE=1 for the whole build, no point messing around with individual commands
[19:32] <ahasenack> I also injected a find -type l before and after
[19:35] <ahasenack> ok, getting close
[20:11] <ahasenack> so, I was following the "life" of pmemlog_create.3*
[20:11] <ahasenack> the .gz.gz happens in dh_compress
[20:11] <ahasenack> https://pastebin.ubuntu.com/p/TmyKycSkGK/ (search for pmemlog_create to follow)
[20:12] <ahasenack> er, pmemlog_close
[20:12] <ahasenack> not create
[20:16] <ahasenack> http://people.ubuntu.com/~ahasenack/build-log is the whole build log (2.6Mb)
[20:21] <jbicha> ahasenack: I can't see the source but I suspect the upstream build system is compressing the manpages and Debian doesn't expect that
[20:47] <ahasenack> jbicha: yep, upstream's Makefile is definitely compressing them
[21:05] <jbicha> you can use override_dh_compress but I suggest also filing a bug against debhelper to tell it not to compress a file if it's already compressed!
[21:12] <ahasenack> this is surprisingly annoying
[21:12] <ahasenack> dh_compress is not just about manpages