alkisginfinity: 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 rule04:21
alkisgFunny, 10 hours to change 1 word :D https://github.com/ltsp/ltsp/commit/d06c08fae8c00d3ca7f63f080a19ede9500f5b1404:21
TJ-Is this a bug in "man 1 sbuild" EXAMPLES section? "distribution is inferred from debian/copyright"08:46
rbasakSurely yes if it says that!08:58
cjwatsonTJ-: 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
cjwatsonTJ-: fixed upstream, thanks.  https://salsa.debian.org/debian/sbuild/commit/fc306f4be0d2c57702c5e234273cd94b1dba094d09: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.changes09:10
cjwatsonTJ-: 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 .debs09:13
cjwatsonTJ-: If it isn't clear from that then pastebin the .changes file09:14
TJ-cjwatson: thanks... I have scanned them but unsure what I was looking for09:17
TJ-cjwatson: hmmm, so "gvfs_1.36.1-0ubuntu1.3.4~tj_amd64.buildinfo" would be the culprit09:18
cjwatsonSounds like it09:23
cjwatsonInformation about how the environment for a binary build was set up doesn't belong in a source upload09:24
cjwatsonIf 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
cjwatsonTJ-: build-depends> that's why I said -nc09:42
cjwatsonIf you aren't running the clean step then you don't need build-depends09:42
cjwatson(but you do need care that the tree is actually clean)09:42
LocutusOfBorgsomebody once told me this:09:43
LocutusOfBorgdpkg-source -b . && dpkg-source --after-build . && dpkg-buildpackage -S -nc09:43
cjwatsonSomebody was trying too hard IMO, but OK :)09:43
LocutusOfBorgthis is in my "rebuild" bash script when I don't care about dependencies...09:44
LocutusOfBorgif you have a better version I'm happy to listen and apply it :)09:44
LocutusOfBorgand mapreri probably too, since he told me that thing :)09:45
LocutusOfBorgand we should probably have a "no change rebuild" script in ubuntu-dev-tools09:45
cjwatsonI 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
LocutusOfBorghow do you create the changes after editing debian/changelog?09:46
cjwatsonJust 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 on09:47
cjwatsonThere are exceptions where the clean target does something special with substituting the version into other files, but dpkg-source doesn't help with that09:47
cjwatsonTJ-: I don't think you've understood what I said09:47
LocutusOfBorgcjwatson, doesn't in run after-build hooks?09:48
cjwatsonLocutusOfBorg: But so does dpkg-buildpackage -S -nc.  Running it manually first doesn't seem interesting09: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
LocutusOfBorgoh, got it :)09:51
cjwatsonIt does seem like an sbuild bug if it's including _amd64.buildinfo in an allegedly source build09:51
TJ-I was/am doing "sbuild --source-only-changes --no-clean-source" from the source directory09:53
LocutusOfBorgtarzeau, sorry I syncd fasrttracker after seeing you changed the blocker bug...11:04
LocutusOfBorgcan I close it now?11:04
tarzeauis 19.10 having 1.00 now? then bug can be closed11:04
tarzeauyep looks good, thanks11:05
LocutusOfBorgtarzeau, after dinstall yes11:09
LocutusOfBorgI don't want it to migrate early11:09
LocutusOfBorgbut I syncd it before seeing the bug, not the opposite :p11:09
=== ricab is now known as ricab|lunch
=== ricab|lunch is now known as ricab
seb128I 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 number13:51
seb128and 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
ricotzseb128, hey :), I have update the vala sru bug -- https://bugs.launchpad.net/ubuntu/+source/vala/+bug/180313614:20
ubottuLaunchpad bug 1803136 in vala (Ubuntu Bionic) "[SRU] Update to vala 0.40.17 in bionic" [Low,Confirmed]14:20
seb128ricotz, hey, ack, I will have a look, thx14:33
ricotzseb128, thanks14:34
seb128bdmurray, 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
seb128well most recent tracker reports in 19.10 it seems16:24
seb128we also miss debug symbols/retrace on quite some other projects/reports16:24
ddstreetLaney 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
Laneyddstreet: you got me for a few minutes, let me see16:39
Laneyddstreet: 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-jobs16:43
Laneywould that timing match up?16:43
Laneyif it's a stuck process16:43
ddstreetyep that seems to be about right, it seems to have been first noticed oct 10 after one had been stuck for 12+ hours16:46
seb128bdmurray, https://errors.ubuntu.com/problem/0f924bd29e9d9e01b0b77542ead2c68b36282ad1 also16:46
Laneyddstreet: ok, kicked it, should start working again16:50
bdmurrayseb128: I'll try and have a look at it tonight / tomorrow.16:50
seb128bdmurray, no hurry thx, I didn't mean to bother you on a day off just stacked things for once you are back :)16:51
bdmurrayseb128: I'm actually in London at the release sprint so its not a day off.16:52
seb128ah ok16:52
seb128oh well, can wait tomorrow in any case16:52
paride5bdmurray, https://code.launchpad.net/~legovini/auto-upgrade-testing/ramsettings/+merge/37409716:54
paride5what's that 516:54
=== paride5 is now known as paride
ddstreetthanks Laney! :)16:54
=== led_dark_2 is now known as led_dark_1
mwhudsonwhat does DM_MULTIPATH_DEVICE_PATH="0" mean20: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 db20:24
TJ-lib/device/dev-ext-udev-constants.h:48:#define DEV_EXT_UDEV_MPATH_DEVICE_PATH          "DM_MULTIPATH_DEVICE_PATH"20:24
mwhudsonTJ-: yeah, i got that far, i'm just want to know what the value means20:24
TJ-mwhudson: it's a Boolean ... tells us if the device is multipath connected20:24
mwhudsonTJ-: there is stuff in udev about checking for values of 0, 1, 220:25
TJ-mwhudson: hmmm, never noticed that... presumably set by dm_multipath according to the path type?20:27
mwhudson$ sudo multipath -c /dev/nvme0n120:27
mwhudsono well use the source luke etc20:27
mwhudsonDM_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
mwhudsonah hah https://www.spinics.net/lists/dm-devel/msg35965.html20:33
mwhudsonthe poster here is complaining about exactly what we are seeing i think20:33
TJ-Statement of the week: "That could be better documented by comments, I suppose." :D20:41
mwhudsonhah yes20:46

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!