| alkisg | infinity: got it, I had to put the path in the "mount source" of the mount command, as a signal so that snap-confine would generate the appropriate apparmor rule | 04:21 |
|---|---|---|
| alkisg | Funny, 10 hours to change 1 word :D https://github.com/ltsp/ltsp/commit/d06c08fae8c00d3ca7f63f080a19ede9500f5b14 | 04:21 |
| TJ- | Is this a bug in "man 1 sbuild" EXAMPLES section? "distribution is inferred from debian/copyright" | 08:46 |
| rbasak | Surely yes if it says that! | 08:58 |
| cjwatson | TJ-: Yes. I can just fix it here - do you want some kind of "reported by" credit and if so what? | 08:58 |
| TJ- | cjwatson: no thanks... just remove the confusion it caused me when I was forgetting how to use sbuild :) | 09:03 |
| TJ- | I started to doubt my mastery of changelog :) | 09:03 |
| cjwatson | TJ-: fixed upstream, thanks. https://salsa.debian.org/debian/sbuild/commit/fc306f4be0d2c57702c5e234273cd94b1dba094d | 09:06 |
| TJ- | cjwatson: looking at some of your comments about how not to do things in mailing list over the years, but I cannot find an explanation of *why* PPA uploader would report "Mismatch in binaryfulness (arch) False != (files) True ... what precisely is it choking on? This after an sbuild of a source package (gvfs) with a small bugfix and dput ... ..._source.changes | 09:10 |
| cjwatson | TJ-: That means that the Architecture field in the .changes file lists only "source" (which is correct for a source-only upload) but the part of the .changes file that lists other files being uploaded includes some binary files like .debs | 09:13 |
| cjwatson | TJ-: If it isn't clear from that then pastebin the .changes file | 09:14 |
| TJ- | cjwatson: thanks... I have scanned them but unsure what I was looking for | 09:17 |
| TJ- | cjwatson: hmmm, so "gvfs_1.36.1-0ubuntu1.3.4~tj_amd64.buildinfo" would be the culprit | 09:18 |
| cjwatson | Sounds like it | 09:23 |
| cjwatson | Information about how the environment for a binary build was set up doesn't belong in a source upload | 09:24 |
| cjwatson | If you're building the source package from a clean git tree or similar then you could just use debuild -S -nc (and debdiff old and new source packages to make sure that no extra cruft has crept in) | 09:25 |
| TJ- | I'm trying to prevent any build-depends installation on the host with the source, so it is all done from the sbuild schroot ... so I've just 'fixed' it post-build with a "dpkg-genchanges --build=source > .../ X_source.changes" | 09:38 |
| cjwatson | TJ-: build-depends> that's why I said -nc | 09:42 |
| cjwatson | If you aren't running the clean step then you don't need build-depends | 09:42 |
| cjwatson | (but you do need care that the tree is actually clean) | 09:42 |
| LocutusOfBorg | somebody once told me this: | 09:43 |
| LocutusOfBorg | dpkg-source -b . && dpkg-source --after-build . && dpkg-buildpackage -S -nc | 09:43 |
| cjwatson | Somebody was trying too hard IMO, but OK :) | 09:43 |
| LocutusOfBorg | this is in my "rebuild" bash script when I don't care about dependencies... | 09:44 |
| LocutusOfBorg | if you have a better version I'm happy to listen and apply it :) | 09:44 |
| LocutusOfBorg | and mapreri probably too, since he told me that thing :) | 09:45 |
| LocutusOfBorg | and we should probably have a "no change rebuild" script in ubuntu-dev-tools | 09:45 |
| cjwatson | I don't see why a rebuild script needs any particular effort there. If you've just fetched and unpacked the source package then it's clean by definition. | 09:46 |
| LocutusOfBorg | how do you create the changes after editing debian/changelog? | 09:46 |
| cjwatson | Just dpkg-buildpackage -S -nc on its own is nearly always fine; I don't see what the dpkg-source hackery there buys you. | 09:46 |
| TJ- | cjwatson: I was referring to needing to do "sbuild --no-clean-source ..." to prevent failures due missing build-depends the Makefile relies on | 09:47 |
| cjwatson | There are exceptions where the clean target does something special with substituting the version into other files, but dpkg-source doesn't help with that | 09:47 |
| cjwatson | TJ-: I don't think you've understood what I said | 09:47 |
| LocutusOfBorg | cjwatson, doesn't in run after-build hooks? | 09:48 |
| cjwatson | LocutusOfBorg: But so does dpkg-buildpackage -S -nc. Running it manually first doesn't seem interesting | 09:50 |
| TJ- | cjwatson: Yes, I did ... I was talking about an orothogonal issue as to why I ended up with the binary reference and why I was going around the houses :) | 09:50 |
| LocutusOfBorg | oh, got it :) | 09:51 |
| cjwatson | It does seem like an sbuild bug if it's including _amd64.buildinfo in an allegedly source build | 09:51 |
| TJ- | I was/am doing "sbuild --source-only-changes --no-clean-source" from the source directory | 09:53 |
| LocutusOfBorg | tarzeau, sorry I syncd fasrttracker after seeing you changed the blocker bug... | 11:04 |
| LocutusOfBorg | can I close it now? | 11:04 |
| tarzeau | is 19.10 having 1.00 now? then bug can be closed | 11:04 |
| tarzeau | yep looks good, thanks | 11:05 |
| LocutusOfBorg | tarzeau, after dinstall yes | 11:09 |
| LocutusOfBorg | I don't want it to migrate early | 11:09 |
| LocutusOfBorg | but I syncd it before seeing the bug, not the opposite :p | 11:09 |
| === ricab is now known as ricab|lunch | ||
| === ricab|lunch is now known as ricab | ||
| seb128 | I probably ask that in the past, but is there a way to query unattendeed-upgrade to know how many updates it applied and the toal number | 13:51 |
| seb128 | and also maybe to tell it to exit once it's done with its batch so I can use my machine and I install the dbgsym I need without being blocked for half an hour? | 13:52 |
| ricotz | seb128, hey :), I have update the vala sru bug -- https://bugs.launchpad.net/ubuntu/+source/vala/+bug/1803136 | 14:20 |
| ubottu | Launchpad bug 1803136 in vala (Ubuntu Bionic) "[SRU] Update to vala 0.40.17 in bionic" [Low,Confirmed] | 14:20 |
| seb128 | ricotz, hey, ack, I will have a look, thx | 14:33 |
| ricotz | seb128, thanks | 14:34 |
| seb128 | bdmurray, hey, do you have any idea why https://errors.ubuntu.com/problem/8432dce420a23f06dbb667734330eb0ef23301a4 and https://errors.ubuntu.com/problem/c01ad6266575bee8065679508008b968593a86fd have no backtrace? | 16:23 |
| seb128 | well most recent tracker reports in 19.10 it seems | 16:24 |
| seb128 | we also miss debug symbols/retrace on quite some other projects/reports | 16:24 |
| ddstreet | Laney not sure if you're still around, but systemd-upstream CI appears to have stopped updating github with any results...the tests look like they are running on our infrastructure, but their github PR pages show the tests are 'Pending' forever...could you check the autopkgtest-cloud logs? | 16:38 |
| Laney | ddstreet: you got me for a few minutes, let me see | 16:39 |
| Laney | ddstreet: www-data 27586 0.0 0.0 10552 664 ? S Oct09 0:00 | \_ flock -w 60 /run/lock/update-github-jobs.lock /home/ubuntu/autopkgtest-cloud/webcontrol/update-github-jobs | 16:43 |
| Laney | would that timing match up? | 16:43 |
| Laney | if it's a stuck process | 16:43 |
| ddstreet | yep that seems to be about right, it seems to have been first noticed oct 10 after one had been stuck for 12+ hours | 16:46 |
| seb128 | bdmurray, https://errors.ubuntu.com/problem/0f924bd29e9d9e01b0b77542ead2c68b36282ad1 also | 16:46 |
| Laney | ddstreet: ok, kicked it, should start working again | 16:50 |
| bdmurray | seb128: I'll try and have a look at it tonight / tomorrow. | 16:50 |
| seb128 | bdmurray, no hurry thx, I didn't mean to bother you on a day off just stacked things for once you are back :) | 16:51 |
| bdmurray | seb128: I'm actually in London at the release sprint so its not a day off. | 16:52 |
| seb128 | ah ok | 16:52 |
| seb128 | oh well, can wait tomorrow in any case | 16:52 |
| seb128 | thx | 16:53 |
| paride5 | bdmurray, https://code.launchpad.net/~legovini/auto-upgrade-testing/ramsettings/+merge/374097 | 16:54 |
| paride5 | what's that 5 | 16:54 |
| === paride5 is now known as paride | ||
| ddstreet | thanks Laney! :) | 16:54 |
| === led_dark_2 is now known as led_dark_1 | ||
| mwhudson | what does DM_MULTIPATH_DEVICE_PATH="0" mean | 20:19 |
| TJ- | mwhudson: from lvm2: lib/device/dev-ext-udev-constants.h:43: * DEV_EXT_UDEV_MPATH_DEVICE_PATH is set by multipath in udev db | 20:24 |
| TJ- | lib/device/dev-ext-udev-constants.h:48:#define DEV_EXT_UDEV_MPATH_DEVICE_PATH "DM_MULTIPATH_DEVICE_PATH" | 20:24 |
| mwhudson | TJ-: yeah, i got that far, i'm just want to know what the value means | 20:24 |
| TJ- | mwhudson: it's a Boolean ... tells us if the device is multipath connected | 20:24 |
| mwhudson | TJ-: there is stuff in udev about checking for values of 0, 1, 2 | 20:25 |
| TJ- | mwhudson: hmmm, never noticed that... presumably set by dm_multipath according to the path type? | 20:27 |
| mwhudson | $ sudo multipath -c /dev/nvme0n1 | 20:27 |
| mwhudson | DM_MULTIPATH_DEVICE_PATH="0" | 20:27 |
| mwhudson | o well use the source luke etc | 20:27 |
| mwhudson | DM_MULTIPATH_DEVICE_PATH="2" seems to be "maybe" | 20:29 |
| TJ- | I was wondering if it was the queue mode :) | 20:30 |
| === jdstrand_ is now known as jdstrand | ||
| TJ- | so a tri-state Boolean :) | 20:32 |
| mwhudson | ah hah https://www.spinics.net/lists/dm-devel/msg35965.html | 20:33 |
| mwhudson | the poster here is complaining about exactly what we are seeing i think | 20:33 |
| TJ- | Statement of the week: "That could be better documented by comments, I suppose." :D | 20:41 |
| mwhudson | hah yes | 20:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!