=== TheMaster is now known as Unit193
=== cpaelzer__ is now known as cpaelzer
dokoddstreet: I see you touched knot-resolver before. would it be possible to look at the merge? currently fails autopkg tests with the new knot version10:23
dokoxnox: did you follow-up on https://github.com/ntop/nDPI/pull/840 ?11:45
xnoxdoko:  i have not11:53
xnoxdoko:  i failed at configuring wireshark and inspecting packets to understand if nDPI is broken, or if the test data is broken (and is endian specific), or both.11:53
danboiddidrocks: Will zsys handle spare disks ie automatically replacing dead disks with spares?11:57
danboidI've not had any luck getting this to work with zed11:58
ahasenackgood morning12:01
danboidIn my experience, when a disk fully gives up the ghost, zfs sees it as REMOVED, which is when it would ideally be auto-replaced with a hot spare12:01
danboidAt the moment I'm having to replace failed disks manually when they fail with my proxmox RAID2 array12:04
=== gusnan is now known as Guest88701
ahasenackdanboid: is zed running? afaik it's the one responsible for the replacement actions12:13
ahasenackmaybe it's missing a config12:13
ahasenacksorry, just jumping in on what you said last, no idea about context12:13
danboidahasenack, Yeah its running bu I've read reports of others having this issue with zed12:14
danboidclaiming it doesn't actually work for swapping spares. Have you got zed to work?12:14
ahasenackI remember having to do something with in to enable hot spare12:15
danboidI have attempted to configure it according to the docs and a guide I found12:15
ahasenackback when I tested this, in an older system12:15
danboidDon't suppose yoiu still have your zed config do you?12:15
ahasenackI'm trying to remember12:16
ahasenackI think it had to be told to listen to this particular event12:16
ahasenackI'm checking the default config to see if something rings a bell12:16
danboidOK thanks12:16
danboidI'm wondering if zsys may expand to cover this12:16
ahasenackdanboid: do you have autoreplace=on in the pool?12:19
ahasenackzpool get autoreplace12:19
danboidahasenack, No! That could be my problem then. I'll enable that12:21
ahasenackhope it works12:23
ahasenackmore details I don't have at the moment12:24
dokosforshee, apw: looking at https://launchpad.net/ubuntu/+source/gkrellm2-cpufreq/0.6.4-6/+build/19239466 is libcpupower-dev something which should be built from the kernel sources?12:31
LocutusOfBorgtjaalton, http://debomatic-amd64.debian.net/distribution#unstable/renderdoc/1.7+dfsg-3.1/buildlog do you care about debian?12:31
LocutusOfBorgI uploaded in groovy the fix12:31
ahasenackdoko: upstream golang fix for that s390x issue :) https://go-review.googlesource.com/c/go/+/238628/12:36
didrocksdanboid: this is rather a built-in ZFS feature. But we'll propose in the future built-in raid and spare in the installer12:46
xnoxahasenack:  so obvious!12:46
ahasenackxnox: I'm confused, in which timezone are you in again? :)12:46
ahasenackI thought UK12:46
ahasenackbut then I saw you online at like 10pm my time12:46
xnoxi have midnight weekly calls12:50
danboiddidrocks: Yes, adding spare zfs disk suppport to the installer would be a very nice feature to have12:55
danboiddidrocks: Any idea when the installer will better support zfs ie creating zfs partitions, RAIDZ etc?12:56
danboidMight we see any of this in 20.10?12:57
ahasenackxnox: ouch12:57
oSoMoNI doubt this is going to collide with anyone else doing +1 maintenance, but just in case, I'm looking at rocksdb FTBFS (bug #1884072)13:36
ubottubug 1884072 in rocksdb (Ubuntu) "FTBFS in groovy" [Undecided,New] https://launchpad.net/bugs/188407213:36
oSoMoNha, just saw rbalint's comment on the bug, ok…13:37
oSoMoNso I guess I'm not working on this any longer :)13:37
oSoMoNpython-cogent autopkgtests pass locally, can anyone please retry https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=python-cogent&trigger=python-cogent%2F2020.2.7a%2Bdfsg-2 , https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=arm64&package=python-cogent&trigger=python-cogent%2F2020.2.7a%2Bdfsg-2 , https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=ppc64el&package=python-cogent&trigger=python-cogent%2F214:06
oSoMoN020.2.7a%2Bdfsg-2 and https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=s390x&package=python-cogent&trigger=python-cogent%2F2020.2.7a%2Bdfsg-2 ?14:06
seb128oSoMoN, I clicked those14:07
oSoMoNseb128, looks like they're failing again, at least on arm64 (didn't catch the output on other arches and the logs aren't there yet), but one difference with my local run is that I was using all of groovy-proposed, including pytest=4.6.11-1, can you rerun with that additional trigger?14:26
seb128oSoMoN, done14:30
=== alan_g is now known as alan_g_
oSoMoNstill failed, bleh14:55
=== bipul_ is now known as bipul
=== alan_g_ is now known as alan_g
oSoMoNseb128, are you looking at the libvorbis autopkgtest failures? if not I'll take it16:39
oSoMoN(the fix looks trivial)16:40
oSoMoNseb128, I'll take the answer to my first question as a no :) I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963082 and submitted https://salsa.debian.org/multimedia-team/libvorbis/-/merge_requests/1, will share a debdiff for an ubuntu upload in a moment17:00
ubottuDebian bug 963082 in src:libvorbis "libvorbis: Autopkgtests depend on pysycache-i18n which was removed from testing and unstable" [Normal,Open]17:00
oSoMoNthere we go: https://people.canonical.com/~osomon/+1maintenance/libvorbis.debdiff17:08
oSoMoNcore devs: sponsoring welcome ^17:09
rbasakbryce: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/386013 is ready for an initial look please17:46
rbasakI expect this will take you quite some time17:46
brycerbasak, ok noted17:49
rbalintoSoMoN, thanks, sponsoring libvorbis17:53
rbalintoSoMoN, also upstreaming the fix to Debian17:53
oSoMoNrbalint, done already17:53
rbalintoSoMoN, merging then as well :-)17:55
oSoMoNgmenuharness was removed in focal (bug #1866434), but is back (and FTBFS) in groovy, I guess it should be removed again? (and how did it manage to creep back in?)17:57
ubottubug 1866434 in gmenuharness (Ubuntu) "Please remove gmenuharness from Ubuntu" [Undecided,Fix released] https://launchpad.net/bugs/186643417:57
rbalintoSoMoN, usually I prefer updating the changelog with gbp dch in a separate commit17:57
oSoMoNrbalint, feel free to break that up in two commits (or keep only the functional changes part)17:58
rbalintoSoMoN, ok, doing that17:58
seb128oSoMoN, sorry i was too slow to reply :)19:42
oSoMoNseb128, no worries, it's all handled now19:43
oSoMoNdo you know what happened with gmenuharness (see my question above)?19:43
seb128oSoMoN, no, I don't know, https://launchpad.net/ubuntu/+source/gmenuharness/+publishinghistory is weird19:46
seb128it was deleted from focal on 2020-04-01.19:46
seb128but on 2020-04-2419:47
seb128 Copied from ubuntu focal in Primary Archive for Ubuntu  to G19:47
seb128but ye19:47
seb128but yeah, it should be removed again I guess19:47
=== xevious_ is now known as xevious

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