| xnox | hallyn, a more canonical name was taken | 00:13 |
|---|---|---|
| Unit193 | The confusion exists with github.com/ubuntu/ \o/ | 00:32 |
| xnox | Unit193, that's the other half of the company we don't speak to =) | 00:46 |
| xnox | muahahahahhaha | 00:46 |
| * Unit193 makes note to give xnox a good sanity check. :> | 00:51 | |
| dpb1 | hallyn: :) | 00:55 |
| slangasek | Unit193: like an autopkgtest, when the sanity check always comes back negative, it doesn't do you much good | 01:03 |
| === Whoopie_ is now known as Whoopie | ||
| === sergiusens_ is now known as sergiusens | ||
| 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:19 |
| ubottu | bug 991471 in udisks2 (Ubuntu) "multi-device btrfs filesystem automatically mounted once for each device" [Medium,Confirmed] https://launchpad.net/bugs/991471 | 15:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| Faux | I have a multi-device btrfs here and mount using /etc/fstab and it works fine. :) | 15:27 |
| 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:28 |
| 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:29 |
| Laibsch | somebody must know HOW automounting happens | 15:30 |
| Laibsch | that's all I'm trying to understand | 15:30 |
| xnox | Laibsch, it's just a property of btrfs, that all btrfs drives are added together to the total pool, no? | 15:32 |
| 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:33 |
| 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:34 |
| xnox | or, the fact that generic functionality, doesn't work as expected with a special-case of advanced btrfs features. | 15:35 |
| 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:37 |
| 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:41 |
| Laibsch | what's a good place to discuss this? | 15:42 |
| bdmurray | xnox: Have you seen bug 1765724? | 18:21 |
| ubottu | bug 1765724 in cryptsetup (Ubuntu) "Xenial -> Bionic - System fails to boot after upgrade - <email address hidden> fails to start" [Critical,New] https://launchpad.net/bugs/1765724 | 18:21 |
| xnox | bdmurray, lovely | 18:22 |
| xnox | bdmurray, will debug | 18:22 |
| bdmurray | xnox: thanks! | 18:22 |
| 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:56 |
| 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:57 |
| ahasenack | I'm now adding find -type l to some build stages in d/rules via overrides to try to catch it | 18:58 |
| cjwatson | what does the .so line say? | 19:04 |
| cjwatson | ahasenack: ^- | 19:04 |
| ahasenack | checking | 19:05 |
| ahasenack | cjwatson: | 19:05 |
| ahasenack | $ cat doc/generated/pmem_deep_drain.3 | 19:05 |
| ahasenack | .so pmem_flush.3 | 19:05 |
| 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:06 |
| * ahasenack intercepts dh_compress | 19:17 | |
| cjwatson | ahasenack: just export DH_VERBOSE=1 for the whole build, no point messing around with individual commands | 19:22 |
| ahasenack | I also injected a find -type l before and after | 19:32 |
| ahasenack | ok, getting close | 19:35 |
| 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:11 |
| ahasenack | er, pmemlog_close | 20:12 |
| ahasenack | not create | 20:12 |
| ahasenack | http://people.ubuntu.com/~ahasenack/build-log is the whole build log (2.6Mb) | 20:16 |
| 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:21 |
| ahasenack | jbicha: yep, upstream's Makefile is definitely compressing them | 20:47 |
| 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:05 |
| ahasenack | this is surprisingly annoying | 21:12 |
| ahasenack | dh_compress is not just about manpages | 21:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!