[00:13] <psusi> pitti, you seem to have written udisks2-inhibit, so maybe you can help me... it doesn't seem to work because it tries to mount --move a tmpfs.. and much to my surprise... the kernel doesn't appear to support moving a tmpfs
[00:22] <mwhudson> dobey: ah had a think, although that patch i pointed at might help your build, the truth is that cgo just doesn't work very well with go 1.5 on ppc64el
[00:23] <mwhudson> dobey: 1.6 will be better, and gccgo may well work better too
[00:28] <stgraber> "cgo doesn't work very well with go 1.5 on ppc64el", quite the understatement :)
[00:32] <mwhudson> it works to build the go tool itself and more or less nothing else
[00:32] <stgraber> oh, didn't really the go tool itself was using cgo
[00:32] <mwhudson> well
[00:33] <mwhudson> there are two standard lib packages that use cgo (os/user and net)
[00:33] <mwhudson> the go tool uses both iirc
[00:33] <mwhudson> so i guess i mis-spoke: it works for the stdlib cgo usage
[00:33] <mwhudson> and more or less nothing else
[00:33] <stgraber> oh, right, the DNS resolving is using getaddrinfo from libc depending how you built go itself
[02:00] <cjwatson> mapreri,infinity: https://code.launchpad.net/~cjwatson/launchpad/delete-more-component-ui/+merge/278393 should address the confusion you ran into earlier.
[02:18] <hhhggg> i i have recently changed to linux mate Rafela but when I rebooted I can get past the login screen but then it just goes blank the screen
[04:28] <cyphermox> @pilot out
[05:05] <pitti> Good morning
[06:33] <pitti> Laney: hah! tracked down the "ugly" autopkgtest instance names, fixed in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=a02dda206f6
[08:07] <pitti> bdmurray: I need to upload avahi, so I'm stealing the merge from you while I'm at it
[08:17] <lathiat> pitti: will be another release out shortly if that makes your life any better or worse..  won't really change the distro patch stuff though so thats probably most of the work since i merged most of them
[08:17] <lathiat> pitti: if theres anything i havent & should merge let me know
[08:18] <didrocks> pitti: I was wondering why we only see the armhf run on http://autopkgtest.ubuntu.com/running.shtml while the queue for other archs are longer?
[08:18] <didrocks> pitti: is that because of other archs runner are down?
[08:19] <didrocks> (which would explain why the queue is going up)
[08:20] <pitti> lathiat: thanks; I dropped the dbus dep bump and the udebs, these are both obsolete
[08:20] <pitti> lathiat: the skip-nproc-in-container.patch is Ubuntu specific; whether or not you take the upstart jobs, that's a matter of taste I guess
[08:21] <pitti> didrocks: right, I need to deploy a new ssh runner setup script, and thus wait until the current jobs finish
[08:21] <lathiat> pitti: is there a repo i can pull or do i just have to grab the source package
[08:21] <dholbach> good morning
[08:21] <pitti> didrocks: oh, they did! great, will restart
[08:21] <didrocks> pitti: great, thanks! :)
[08:22] <seb128> hey dholbach!
[08:22] <dholbach> hey seb128
[08:23] <pitti> didrocks: they are grinding again
[08:23] <pitti> lathiat: no repo, but you can get the individual patches
[08:23] <didrocks> sweet!
[08:23] <pitti> lathiat: https://patches.ubuntu.com/a/avahi/
[08:23] <pitti> lathiat: but perhaps wait until I uploaded the merge, then the diff will be much smaller
[08:25] <pitti> lathiat: I think the running-in-container patch might also have stopped working with systemd
[08:27] <pitti> current LXC doesn't create /run/container_type, so this looks entirely obsolete
[08:27] <pitti> yep, avahi starts fine in LXC, away with this
[08:27] <lathiat> we should just make avahi not fail if it can't set nproc
[08:27] <lathiat> container or otherwise
[08:28] <pitti> it already does that
[08:28] <lathiat> so whats the patch doing then?
[08:28] <pitti>  * Merge from Debian unstable, remaining changes:
[08:28] <pitti>     - Add debian/avahi-daemon.upstart, debian/avahi-dnsconfd.upstart,
[08:28] <pitti>       debian/avahi-cups-reload.upstart
[08:28] <pitti> lathiat: ^ so that's the only remaining Ubuntu delta
[08:29] <pitti> lathiat: it does nothing any more, I just dropped it; in the past failure to set the rlimit was apparently fatal
[08:29] <lathiat> ah ok
[08:29] <lathiat> looks like it throws a warning but i don tthink it will fail
[08:29] <pitti> correct
[08:29] <pitti> apparently that was fixed upstream for the same reason
[08:30] <seb128> pitti, speaking about avahi bug #1441008 would be nice to fix before the LTS
[08:31] <pitti> lathiat: that's the remaining diff, just adding the upstart jobs: http://paste.ubuntu.com/13490393/
[08:32] <lathiat> is there any documentation on the rationale of killing avahi-daemon if .local exists anyway? I think the real fix (tm) woudl be to remove the [NOTFOUND=return] from nsswitch.conf in those cases, should cause it to fall back
[08:32] <pitti> seb128: ah, ten seconds too late, but I'll assign it to me and deal with it
[08:32] <lathiat> which is a speed optimisation / spec compliant to not send .local to nameservers
[08:32] <seb128> pitti, thanks!
[08:33] <pitti> it's been a few years; back then avahi didn't get along well with a "real" .local domain, perhaps it got better at that
[08:33] <lathiat> pitti: i think it would still cause issues simply because the default nsswitch will return an error if a .local lookup isnt found in mdns.. but thats controlled by nsswitch.conf
[08:33] <lathiat> unless im missing something
[08:53] <pitti> didrocks: uh, you earned the plymouth merge..
[08:54] <smb> pitti, Not sure whether this is already old news or rather me misunderstanding. I thought that creating an /etc/udev/rules.d/70-persistent-net.rules manually should still create old naming (in Xenial). But it did not when preparing Xenial partitions on my test boxes.
[08:54] <seb128> poor didrocks
[08:54] <didrocks> pitti: I didn't claim it yet, notice! :)
[08:54] <didrocks> it shouldn't be that much TBH, as it's dead upstream
[08:54] <seb128> unsure it is
[08:54] <seb128> well, there are still commits/activity at least
[09:23] <pitti> smb: yes, it should still work
[09:23] <pitti> seb128: can you show the file to me? did you rebuild the initramfs?
[09:26] <seb128> pitti, I guess that was for smb?
[09:26] <pitti> seb128: err yes, sorry
[09:26] <pitti> smb: can you show the file to me? did you rebuild the initramfs?
[09:26] <smb> Ah
[09:27]  * smb was wondering
[09:28] <smb> pitti, I think I did but I can retry to be sure. The file has been used before and was working (I basically start with a debootstrap and then blow it up with server^ and ubuntu-minimal, then inject config files)
[09:28] <smb> pitti, But give me a sec to get the host up
[09:37] <smb> pitti, bah... possibly the "forgotten rebuild" of initramfs... of course this morning all is good... should not try those things late in a day... sorry for the noise
[09:37] <pitti> smb: no worries; initrd rebuild should not be strictly required, but if you use the names in the initrd (open-iscsi for example), then that's necessary
[09:40] <smb> pitti, Hm, I don't think I do (but thats the beast of having things automated, one forgets) but its at least installed and maybe that is enough
[09:48] <pitti> didrocks, Laney: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mesa -> "in progress/always failed" in actaion
[09:48] <pitti> action too
[09:48] <didrocks> \o/
[09:48] <Laney> pitti: ah, that made it migrate?
[09:48] <Laney> nice
[09:48] <pitti> which is nice because gmsh/i386 takes 2:50 hours (it times out)
[09:48]  * didrocks likes consistency)
[09:48]  * pitti hugs didrocks
[09:48]  * didrocks hugs pitti back
[09:49] <Laney> not consistency in your balanced ()
[09:49]  * Laney screams
[09:49] <pitti> didrocks: now, REAL consistency would be "(Always failed)", not "(always failed)" :-P
[09:49] <didrocks> Laney: that was done on purpose :p
[09:49] <Laney> suuuuuuuuure :)
[09:49] <didrocks> pitti: well, I doubted about the capital letter for at least… 1.337 seconds
[10:21] <seb128> jamespage, seems like pysendfile could be synced if you sent that delta to Debian, http://launchpadlibrarian.net/194619680/pysendfile_2.0.0-6ubuntu1_2.0.0-6ubuntu2.diff.gz ... did you try to report it there/see if they were interested?
[10:21] <seb128> unsure what the .egg-info is needed you wrote "correct dependency detection."
[10:21] <seb128> but that probably apply to Debian as well?
[10:25] <ginggs> hi, could someone retry fop (main) please? https://launchpad.net/ubuntu/+source/fop/1:2.0+dfsg-4
[10:27] <pitti> ginggs: nothing to retry, it's in depwait
[10:27] <pitti>  libfontbox-java | 1:1.8.10-1 | xenial/universe | all
[10:27] <pitti>  libmockito-java | 1.9.5+ds-2 | xenial/universe | all
[10:27] <pitti> ginggs: needs MIRs, or these new dependencies dropped again
[10:28] <pitti> lathiat: meh, we have a package maas-enlist-udeb which actually needs the avahi udebs
[10:28] <pitti> lathiat: so that delta will come back :/
[10:28] <ginggs> pitti: ah, ok thanks
[10:29] <didrocks> sil2100: congrats!
[10:31] <ginggs> pitti: so should i look at filing MIRs or see if fop build without libfontbox-java and libmockito-java ?
[10:31] <pitti> ginggs: I'm not sure TBH; if the two pacakges are trivial, then a MIR seems better as then we'll stay in sync
[10:32] <sil2100> didrocks: thanks!
[10:32] <sil2100> :)
[10:44] <killall> where can i get support libevdev?
[11:03] <pitti> tkamppeter: thanks for committing the cups change!
[12:56] <Mirv> bdmurray: hi! is there a way to skip/fix "E: Some packages could not be authenticated" when running apport-retrace? the packages comes from a PPA (and I've added the sources to the lp:daisy's sources.list so the package is found) and the gpg key of the PPA is in the host's keys
[13:24] <lotuspsychje> is nvidia-current going to be depraced?
[13:24] <lotuspsychje> shows still nvidia-graphics-drivers-304
[13:30] <tjaalton> it's already deprecated, as it's just a transitional package
[13:32] <lotuspsychje> tjaalton: ok tnx, it will be removved from repos?
[13:32] <tjaalton> once 304 itself is gone
[13:32] <tjaalton> which I don't think will happen anytime soon
[13:32] <lotuspsychje> tjaalton: ok thank you mate
[13:33] <lotuspsychje> tjaalton: you also know the reason?
[13:33] <tjaalton> of what?
[13:33] <lotuspsychje> tjaalton: users need to manually install specific driver versions now?
[13:33] <tjaalton> the driver manager (or whatever it's called) will do that
[13:34] <lotuspsychje> ok tnx
[13:47] <Mirv> bdmurray: unping, I probably didn't do apt-key adv recv-keys earlier, now it worked
[14:35] <killall> where can i get support libevdev?
[14:36] <sladen> killall: what type of support are you after?  The API reference is here:  http://www.freedesktop.org/wiki/Software/libevdev/
[14:37] <sladen> killall: at the other end of the scale, if you're wanting to hire-in support you could go to a company such as  http://www.canonical.com/services
[14:38] <killall> sladen,  I have 2 touchscreen from diferent batches, one works and other wont work on ubuntu 14.04 but booth work on ubuntu 10.04.
[14:38] <killall> I want to know if libevdev is the one opening the device in raw mode and if so why wont it work?
[14:41] <sladen> killall: first of all check  lsusb -v  to see what the devices show up as
[14:41] <killall> sladen, booth show exactly the same on lsusb, on lshw
[14:42] <sladen> killall: then you can use   lsof   to perhaps see what is opening the device
[14:42] <killall> sladen, can you teach  me how?
[14:42] <sladen> killall: or perhaps if you share some information (eg. USB IDs, name, manufacture) others may be able to help more easily
[14:42] <killall> Bus 002 Device 007: ID 0c45:8419 Microdi
[14:43] <sladen> killall: sudo apt-get install lsof && lsof | grep /dev.*usb
[14:43] <sladen> killall: perhaps best is if you open a bug report, then there's a way of tracking all the information in one place
[14:43] <sladen> killall: https://launchpad.net/ubuntu/+filebug
[14:44] <killall> sladen, thanks but that wont fix my problem at least for now :) and yes that is waht i want to do but i dont have no clue how to pont the developers
[14:44] <killall> im also a developer by the way but no experience on drivers or kernel
[14:45] <sladen> killall: well, filing a but report is normally a good way to ensure all the details are together in one place so that the relevant developers can look at it
[14:45] <sladen> s/but report/bug report/
[14:46] <killall> sladen, yes i know but at the moment i cannot tell that 50 touch panels i bought dont work.
[14:46] <killall> i have to point the way or the solution
[14:46] <sladen> killall: one of the useful things to include would be  lsub -vvvv -d 0c45:8419   to try and see how the panels are different
[14:47] <sladen> killall: but please open a bug report and start to collate the output there so that everyone can find and locate it, and if doesn't get lost in scrollback
[14:47] <killall> sladen, doing that the diff show nothing, i have contacted the manufacter and he said the code in the firmware was changed keeping the version and the output the same
[14:47] <pitti> Laney, apw, infinity: there, test queue contents: http://autopkgtest.ubuntu.com/running.shtml
[14:48] <sladen> killall: riiiight, please include that information from the manufacturer in the bug report as well
[14:48] <killall> ok thanks :)
[14:48] <sladen> killall: as that's pretty important
[14:48] <Laney> pitti: woot!
[14:48] <pitti> (this is a bit synthetic, but the next real xenial requests will come soon :) )
[14:48] <killall> any usefull command i must input
[14:50] <apw> pitti, which order is the queue in, top first or bottom first
[14:50] <apw> pitti, and wow of course
[14:50] <pitti> apw: top entry gets run next
[14:50] <pitti> i. e. new requests are added at the bottom
[14:51] <pitti> fungible of course, but right now it's writing the lines in the order it reads it off the queeu
[14:51] <sladen> killall: I have given you at least two useful commands that would help already
[14:51] <sladen> killall: so perhaps start with these
[14:54] <sladen> killall: but if that's two hard in the first step, please at least say  "USB 0c45:8419 Microdia touch-screen should work on 14.04: manufacturer stated on date XXX that the firmware touch panel firmware had been changed without changing the product ID
[15:10] <sladen> killall: so any progress/success, do we have the bug number/URL yet?
[15:11] <killall> https://bugs.launchpad.net/ubuntu/+source/evtest/+bug/1519393
[15:12] <killall> if any problem please inform and if possible i will fix :) thanks for the time and patience on me
[15:12] <killall> sladen, thanks
[15:18] <dobey> mwhudson: well, right now i just want the quickest possible solution to have somewhat reliable builds and get this stuff landed. so if that patch enables that, i'd love to have it be uploaded. :)
[15:22] <sladen> killall: thanks, for each of these commands, please could you attach the output for the working one, and *then* for the working one
[15:22] <sladen> killall: to be able to compare A and B, one needs A and B to start with!
[15:23] <killall> it has booth, but wich command do you need in particular?
[15:24] <killall> you have booth evtest working and non working lsusb of booth and python report.py of booth
[15:24] <killall> the only comand you dont have is the cat /dev/hidraw0 wich is equal to hidraw1
[15:24] <sladen> killall: I'd like to be able to run  diff -u lsusb-vvv-working.txt lsusb-vvv-not-working.txt
[15:25] <killall> ok
[15:25] <killall> i got you :) one sec
[15:26] <sladen> killall: ideally *unplug both*.  Plug in the first, and run  sudo lsusb -vvvv -c -d 0c45:8419 > lsusb-vvvv-0c45:8419-working.txt
[15:26] <sladen> killall: then unplug the first, and plug in the second, and run   sudo lsusb -vvvv -c -d 0c45:8419 > lsusb-vvvv-0c45:8419-not-working.txt
[15:26] <sladen> killall: and attach both
[15:27] <killall> yes thanks
[15:32] <killall> sladen, uploaded thanks
[15:32] <killall> i added even dmesg ouput
[15:33] <teward> hate to ask, but I know there's a "fails to upgrade" bug in libuuid... which bug is that?
[15:33]  * teward had the link but lost it :/
[15:35] <sbeattie> teward: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1518151
[15:37] <teward> sbeattie: thanks, i assume the affect is 'global' in terms of building software via sbuild?
[15:37] <teward> (even to test build things)
[15:41] <killall> sladen, anything else to append to the bug report, what can it be? Can you point me the light? im compiling libevdev but i dont think it is that
[15:42] <sladen> killall: do /you/ have any way to tell the two batches apart
[15:42] <sladen> killall: are they visibly different in anyway
[15:43] <sladen> killall: have you tried multiple devices, or just one from each batch?
[15:43] <killall> i have tried from the fist batch 250 touch screens and from the second batch 10 of 50
[15:44] <killall> the batches are 99% equal from outside the only diference is the usb cable a few centimeter longer
[15:49] <didrocks> mterry: answered, maybe try with this sbuild chroot to reproduce the issue?
[15:49] <didrocks> mterry: if you can't reproduce, I'm happy to add any logs you feel I need to add
[15:53] <sbeattie> teward: dunno about "global" but I keep hitting it over and over again, even after apt-get installing it manually in my source schroots. It's really frustrating in that I make it go away for a while and then it comes back.
[15:59] <mterry> didrocks, I agree with you btw.  This is not my favorite solution to the problem.  Just given time constraints, it was the best I knew we promise to do.  :-/
[16:00] <didrocks> mterry: yeah, it's not a critize, but I prefered to state the obvious :)
[16:00] <mterry> didrocks, duplicity upstream seems happy to stay on python2 for years, so if we want this change, we have to do it ourselves
[16:00] <didrocks> mterry: you know I'm kind of pragmatic due to what I had to do on Ubuntu Touch and such ;)
[16:00] <didrocks> mterry: so no worry!
[16:00] <mterry> didrocks, :)
[16:00] <didrocks> mterry: how much work will it be in your opinion to migrate duplicity?
[16:00] <didrocks> like a month? less/more?
[16:01] <mterry> didrocks, I dunno, 2 to 3 weeks I'd guess
[16:01] <didrocks> python:       15272 (96.60%)
[16:01] <mterry> didrocks, but it's tricky
[16:01] <didrocks> yeah :/
[16:01] <didrocks> quite a lot
[16:01] <mterry> didrocks, it has a lot of backend plugins
[16:01] <didrocks> and some doesn't have python3 support I guess?
[16:01] <mterry> didrocks, which we could port or drop
[16:01] <didrocks> yeah
[16:01] <mterry> didrocks, right
[16:02] <didrocks> (was more curious to know if we should or not try to port it ourself…)
[16:02] <didrocks> sounds like not really pratical
[16:02] <killall> thanks sladem
[16:02] <mterry> didrocks, but it seems crappy to port not all of them (because some ubuntu users might rely on them)
[16:02] <killall> thanks sladen
[16:02] <didrocks> mterry: agreed
[16:02] <mterry> didrocks, well I've made some porting attempts in my spare time in the past
[16:02] <mterry> didrocks, and kept getting bogged down
[16:02] <didrocks> yeah, unsurprisingly
[16:02] <mterry> didrocks, and it doesn't seem like I'll have clearance to do it on work time this cycle.  Hence this solution
[16:03] <didrocks> mterry: no worry! Keep me posted if you can't reproduce at all the failing tests, I'm happy to add something in debian/rules to export the log files you need
[16:03] <mterry> didrocks, by the time it matters, maybe deja-dup can just be a snap that bundles python2  :)
[16:03] <mterry> didrocks, I will try your sbuild reproduction steps
[16:04] <didrocks> keep me posted!
[16:10] <sladen> killall: I've updated the bug report again for you.  Please could you fill in which cable is longer
[16:10] <sladen> killall: and please could you re-run the   hid-replay  tests each into a separate, clearly labeled file, and attach them
[16:10] <killall> sladen, yes i can :)
[16:25] <sladen> killall: any luck with re-running  'evtest'  for working and non-working?
[16:26] <sladen> killall: the hexdumps look useful, but only if one can diff and compare
[16:27] <killall> one sec :) uploading
[16:28] <decci> Hello Developers
[16:28] <decci> I am trying to do .DEB packaging
[16:28] <MrBIOS> no need to capitalize it
[16:28] <decci> I am following a general dh_make && debian/rules && debian/rules binary
[16:28] <decci> MrBIOS: Sorry
[16:29] <MrBIOS> no need to apologize  :)
[16:29] <killall> sladen, evtest show notghing special ill post it to, wich hex dump?
[16:29] <decci> need suggestion on http://pastebin.com/37Vg49bp
[16:31] <decci> I have source code precompiled from developer which is run with cmake and make command. Now while I ran dh_make -f ../.tar.gz -p sa_source_6.2.0 && debian/rules clean && debian/rules build, will it gonnna build it again.
[16:33] <killall> sladen, appended the evtest but what hex dump do you mean? also added the hidreplay output
[16:34] <decci> Anyone with debian packaging experience
[16:41] <sladen> killall: yes, the hidreplay
[16:42] <killall> the hidreplay is there :) with https://bugs.launchpad.net/ubuntu/+source/evtest/+bug/1519393/comments/8
[16:43] <pitti> slangasek, stgraber, kees, infinity, mdeslaur: TB meeting reminder in 17 mins
[16:43] <slangasek> pitti: ack. who's chairing?
[16:43] <slangasek> (is it me? :)
[16:43] <pitti> slangasek: kees, fallback to mdeslaur
[16:43] <slangasek> ok
[16:43] <pitti> not that we'd have an agenda :)
[16:44] <kenvandine> @pilot out
[16:46] <seb128> kenvandine, oh, already done? any chance you could still do https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1518053 ? ;-)
[16:46] <seb128> kenvandine, seems like it would help chromium users
[16:46] <seb128> kenvandine, shouldn't be too difficult to review
[16:49] <sladen> killall: can you upload the evtest not working
[16:49] <sladen> killall: I've deleted the other dup
[16:49] <killall> ok :) sladen  np
[16:50] <killall> sladen,  done
[16:52] <kenvandine> seb128, i'll look
[16:52] <seb128> kenvandine, thanks
[16:53] <sladen> killall: so (comparing the evtests), the not-working one never sends any events, even if you move fingers/click buttons etc
[16:54] <killall> yes correcy
[16:54] <killall> right
[16:54] <killall> *correct
[16:54] <LocutusOfBorg1> pitti, pbuilder should be fixed, wrt lp: #1511938
[16:54] <mdeslaur> slangasek, kees, pitti, infinity, stgraber: meeting in 5 min?
[16:56] <killall> sladen,  what else can i help?
[16:56] <slangasek> mdeslaur, kees, pitti, infinity, stgraber: meeting in 4 min ;)
[16:57] <mdeslaur> heh
[16:57] <stgraber> :)
[17:10] <killall> sladen, anything else i can provide and help?
[17:18] <kenvandine> seb128, there debdiff no longer applies cleanly, there's been a new upload since them
[17:18] <kenvandine> i cleaned it up so the debdiff applied cleanly, but one of the patches doesn't apply still
[17:18] <seb128> kenvandine, oh :-(
[17:18] <seb128> kenvandine, maybe mention it to qengho on -desktop?
[17:19] <kenvandine> debian/patches/handle-multiple-exec-lines.patch
[17:19] <kenvandine> yup
[17:21] <sladen> killall: did there an ebay link/amazon link/alibaba link for these devices incase the developers want to get hold of one.  Are there windows drivers that might be useful for reverse-engineering any "knock sequence" (initialisation sequenence needed)
[17:22] <sladen> killall: is there any information from the manufacturers about what they changed (who are the manufactures?)
[17:24] <pitti> [ubuntu/xenial] ruby-defaults 1:2.2.3ubuntu1 (Accepted)
[17:24] <pitti> doko: ^ hah!
[17:24] <killall> sladen,  nothing and nothing.... amazon link no. they only sell big batches unfortunatly guess low as 25.
[17:25] <sladen> killall: yeah, so who *is* the manufacturer?
[17:26] <sladen> killall: is there a picture on the internet of what it looks like
[17:26] <sladen> killall: are there any names or logos on the device
[17:26] <sladen> killall: are there any names or logos on the packaging?
[17:27] <killall> http://www.wivitouch.com/sdp/1079694/4/pd-5199630/7116924-2132434/Multitouch_screen_infrared_touch_screen_19.html
[17:27] <killall> this is the manufacter and product page
[17:27] <killall> http://img.diytrade.com/smimg/1079694/17764824-1256906-0/nn/58f1.jpg this is what i have without straps
[17:28] <killall> same manufacter  wivitouch wich does not supply a lot of support
[17:42] <sladen> killall: are you in a position to try alternative kernels
[17:46] <sladen> killall: eg. starting with the (working) 10.10 install, recording that kernel version
[17:46] <sladen> killall: and then trying progressively newer ones until you find the first one that doesn't work
[17:47] <sladen> killall: and if all the kernsl work, then that would point to it being userspace, rather than the kernel
[17:49] <MrBIOS> sladen: which HW?
[20:22] <Bluefoxicy> I'm calling Libidinous Lagomorph for 2023.4
[20:23] <Bluefoxicy> Also noticed if you use the official Ubuntu 15.10 docker image, you can't install mariadb-server-10.0; it fails to run mariadb-server-10.0.postinst configure
[20:23] <Bluefoxicy> near as I can tell, it's trying to start MariaDB via init script, which wants to run mysqld_safe, which aborts because it tries to drop to mysql and can't drop privileges (it stays as root), and refuses to run as root
[20:45] <mwhudson> dobey: i'd recommend you build on ppc64el with gccgo
[20:45] <mwhudson> (or not at all)
[21:03] <dobey> mwhudson: how would one force gccgo there?
[21:03] <TJ-> does anyone happen to have the Debian syslinux 3:6.03+dfsg-9 source package? Debian's source tracker no longer has (only -10 and -11) - was published in August. I wanted to pull a patch from it that was added in -0 and removed in -10
[21:03] <mwhudson> dobey: Build-Depends: gccgo [ppc64el], golang [!ppc64el] I think?
[21:03] <TJ-> errr, added in -9
[21:03] <mwhudson> dobey: lxd does this
[21:04] <dobey> ok
[21:06] <sarnold> TJ-: tada https://launchpad.net/debian/+source/syslinux/3:6.03+dfsg-9
[21:06] <infinity> TJ-: pull-debian-source syslinux 3:6.03+dfsg-9
[21:07] <TJ-> many thanks! that'll fix all the syslinux/startup-disk issues (a gcc 5 transition breakage)
[21:09] <dobey> mwhudson: but golang should be fine on all the other archs (powerpc arm64)?
[21:09] <mwhudson> dobey: yes
[21:09] <mwhudson> on powerpc you really get gccgo
[21:09] <mwhudson> arm64 cgo stuff should be fine
[21:11] <dobey> ok
[21:21] <TJ-> mpt: are you aware syslinux ldlinux.sys "Boot Error" is still present due to building with gcc 5? I can't see any bugs indicating work on it
[21:25] <TJ-> mpt: fix available upstream, tested on Wily bug 1507002
[22:26]  * tsimonq2 is gone: test
[22:49] <brendand> if python3-selenium is in sid, should there be any problem pulling it into xenial?
[22:51] <cjwatson> brendand: no, just requires somebody to merge the python-selenium source package from Debian
[22:52] <cjwatson> brendand: you'll see it on https://merges.ubuntu.com/multiverse.html
[22:53] <cjwatson> brendand: (or sync, if none of the current Ubuntu delta is relevant any more; I don't know)
[22:57] <brendand> cjwatson, a tar.gz is mentioned but it's not linking to anything??
[22:58] <brendand> ah right, appending that to the end of the url seems to work
[22:58] <brendand> after https://merges.ubuntu.com/p/python-selenium/
[22:59] <cjwatson> brendand: it's only a rough guide anyway, may not be a sensible starting point in this case (delta includes new upstream version, etc. - if I were you I'd probably work it out by hand and compare to what Debian's done)
[22:59] <cjwatson> https://wiki.ubuntu.com/UbuntuDevelopment/Merging#Things_to_check_during_the_merge
[23:21] <mwhudson> er, is there any special reason why "sbuild-update --update xenial-amd64" would give hash sum mismatch errors?
[23:22] <mwhudson> i think i have apt-cacher-ng installed, maybe i need to give that a slap
[23:22] <xnox> mwhudson, archive update is atomic, but a client can catch the update mid-way that is to get "old" Release and "new" Packages.gz
[23:22] <mwhudson> xnox: it seems to be persistent
[23:23] <xnox> mwhudson, there is a solution to this, to do by hash Packages et.al. but it's in experimental apt.
[23:23] <sarnold> apt-cacher-ng can make an annoying transient condition annoying and permanent :)
[23:23] <xnox> mwhudson, in that case something is borked =)
[23:26] <mwhudson> blargh it even happens if i run apt-get update -o Acquire::http::No-Cache=True
[23:28] <sarnold> how about Acquire::http::proxy::192.168.122.1 DIRECT   ?
[23:28] <sarnold> (with your mirror's IP in place of 192.168.122.1, of course)
[23:28] <mwhudson> nope
[23:30] <sarnold> dang; that means it's time to wget things by hand and see if the mirror itself is broken
[23:30] <sarnold> writing a tool to check this has been on my todo list for a dozen years
[23:30] <sarnold> sigh
[23:30] <mwhudson> well chdist apt-get xenial update outside the schroot succeeded
[23:32]  * mwhudson disables the proxy yet more forcefully in the schroot
[23:32] <xnox> there are hooks that re-add it too
[23:33] <mwhudson> joy
[23:33] <mwhudson> i like fast builds but i also like builds that don't fail for stupid reasons too :(
[23:34]  * xnox gave my new isp an ultimatum - either you provide ubuntu mirror, or i mirror 1TB =)
[23:34] <xnox> they responded with "we have passed your query to actual technical staff to respond"
[23:34] <sarnold> haha
[23:35] <mwhudson> i wonder if i can smuggle a cheap 1u into the rack here in the coworking space
[23:39] <xnox> mwhudson, 1TB NVMe sticks are small =)
[23:39] <mwhudson> xnox: not cheap though
[23:40] <mwhudson> is nvme the form factor or the interconnect? my x1 carbon won't boot from the newer interconnect
[23:40] <xnox> i have no idea what interconnect is,
[23:41] <sarnold> nvme is the "not sata" bit :)
[23:41] <xnox> but i have fixed ubiquity to install on nvme driver prior to them going public.
[23:41] <xnox> it ends in like n0p1 for namespace zero, first partition.
[23:41] <sarnold> if I've understood it correctly, nvme can run over pcie addon cards, in howswap bays, and via m.2 adapters
[23:41] <xnox> cking confirmed they will work fine.
[23:41] <xnox> sarnold, si.
[23:42] <sarnold> I think those are all electrically nvme, even if the form factors are vastly differently among all three
[23:42]  * xnox is awaiting dell shipment with nvme. They keep pushing back.
[23:42] <mwhudson> ah yeah, it's nvme that the x1 carbon doesn't support
[23:43]  * zyga looks at a long chain of python backports for precise
[23:43] <mwhudson> you can get ahci pci things that work, but not the full nvme
[23:43] <mwhudson> i guess nvme would work if you boot from a usb stick or something silly like that
[23:44] <sarnold> I understand nvme has much higher power requirements than the typical sata device; some nvme pcie cards draw something like 25 watts...
[23:48] <xnox> sarnold, the best bit is that the industry have moved on before nvme drives hit mainstream shelfs.
[23:48] <xnox> prior to "standardtised" nvme drives we had all the custom fusioio cards et.al.
[23:48] <xnox> and now nvme is too slow too, and everyone is working on direct access memory / persistent memory.
[23:48] <xnox> such that there is no hard-drive in the userspace, just continious memory which persists.
[23:49] <sarnold> xnox: I dunno man, pmem is pretty far-out there stuff
[23:49] <sarnold> xnox: it looks -awesome- but I think nvme is going to be around for a few years
[23:51] <sbeattie> mwhudson: most but not all of the hashsum mismatches I get are due to Translations files, I've started setting 'Acquire::Languages "none";' in my schroots because of it.
[23:52] <mwhudson> sbeattie: this was Sources, fwiw
[23:52] <mwhudson> but that might not be a bad idea i guess
[23:54] <sarnold> sbeattie: hmm, I wonder if this can help you https://code.launchpad.net/~adconrad/canonical-is-charms/ubuntu-mirror/+merge/267728
[23:55] <sarnold> sbeattie: .. that may help your local mirror.. if the mirror you're copying from needs to use this too then it won't help you much :/
[23:56] <sbeattie> sarnold: I added a local patch to apt-mirror to disable pulling translations yesterday; I'm going to give it a few runs to make sure it's doing the right thing before submitting it upstream.
[23:56] <sarnold> xnox: does the experimental apt address the hash sum mismatches by changing files to predictable non-colliding names? or .. bundling signatures/hashes into the files so they're replaced atomically? I'm curious....
[23:56] <sarnold> sbeattie: ahhh
[23:56] <xnox> sarnold, yes.
[23:57] <xnox> sarnold, ala rpm style.
[23:57] <xnox> but better, cause it's on debian.
[23:57] <sarnold> xnox: nice nice. it sure feels like these hash sum mismatches are showing up more often these days than they used to.
[23:58] <sarnold> xnox: so some different layout to be more predictable sounds fantastic at this point :)
[23:59] <sarnold> sbeattie: I turned off trnslations on my laptop ages ago and then wondered why apt-cache search was returning 1/10th the results I expected; just turning them off entirely may not be ideal either :/