[06:11] <vorlon> @pilot out
[11:41] <nteodosio> RAOF, do you know why bug 2029473 hasn't made it into proposal yet?
[11:41] -ubottu:#ubuntu-devel- Bug 2029473 in software-properties (Ubuntu Xenial) "Backport Ubuntu Pro to Xenial" [High, Fix Committed] https://launchpad.net/bugs/2029473
[11:42] <nteodosio> s/proposal/proposed
[11:45] <seb128> nteodosio, he's probably eod at this time but maybe other SRU reviewers can help there, unsure if they regularly review the xenial queue
[13:27] <nteodosio> Ah, so maybe ^bdmurray?
[14:01] <ahasenack> is the TPM support for FDE in the current mantic installer? I downloaded the daily image yesterday, and only see the usual lvm + passphrase encryption. Or will that use TPM, and leave the passphrase as a backup to get in?
[14:16] <seb128> ahasenack, TPM will only be enable on some hardware, also we had a bug that it was not working with 'minimal' (which is the default), that should be fixed in today's daily
[14:17] <ahasenack> seb128: what is the indication that it's available, another option under "advanced"?
[14:17] <ahasenack> I'm trying with a VM, where I did enable TPMv2, which used to satisfy windows 11
[14:17] <ahasenack> (and am also using a non-minimal install)
[14:19] <seb128> ahasenack, yes, it should be in the advanced dialog ... any error in journalctl | grep TPM?
[14:20] <ahasenack> "not encrypting device storage as checking TPM gave: secure boot is disabled"
[14:20] <ahasenack> I used uefi boot, and UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.secboot.fd specifically
[14:20] <seb128> ahasenack, that's probably why you don't see the option
[14:21] <ahasenack> but mokutil agrees that secure boot is disabled
[14:28] <seb128> ^ was sorted out on another channel but as a follow up, /usr/share/OVMF/OVMF_CODE_4M.ms.fd is the right file to use
[16:45] <UnivrslSuprBox> It seems like libx32lsan0-amd64-cross and lib32lsan0-amd64-cross are still in mantic's Universe repository, they were last built by `gcc-13-cross (9ubuntu3)`. However, they don't appear on the NBS site. Did they slip through the cracks, maybe on account of having a different version from their source package?
[20:04] <vorlon> UnivrslSuprBox: they haven't entirely slipped through the cracks, in that https://ubuntu-archive-team.ubuntu.com/proposed-migration/mantic_outdate.txt knows about them; it's just that this is the last report to be settled because we normally drive things through the NBS report instead
[20:08] <UnivrslSuprBox> vorlon: interesting, thank you. I'll make my code more resilient against this situation (was going to anyway, especially so now that it's an expected state of the archive for a short time)


[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::<IP_ADDRESS> DIRECT   ?
[23:28] <sarnold> (with your mirror's IP in place of <IP_ADDRESS>, 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 :/


[04:22] <mwhudson> has the length at which reviews in merge proposals get truncated for display changed recently?
[04:22] <wgrant> No.
[04:22] <mwhudson> hm
[04:22] <wgrant> Oh, the comments?
[04:22] <wgrant> Yes
[04:22] <mwhudson> yeah
[04:22] <mwhudson> ok
[04:22] <wgrant> It seems a bit short.
[04:22] <mwhudson> not going mad then :)
[04:22] <wgrant> Bug comments too.
[04:22] <mwhudson> ah
[04:23] <mwhudson> is it the same config key or something?
[04:23] <mwhudson> i wonder if there's a case for bugs having a shorter link
[04:23] <wgrant> I don't think it's config any more.
[04:23] <mwhudson> *limit
[08:39] <Riddell> can PPAs be renamed?
[08:45] <czajkowski> Riddell: nope
[08:46] <Riddell> czajkowski: only the display name?
[08:47] <StevenK> Riddell: Create a second one, copy what you want from the first one and then delete it?
[08:47] <Riddell> yep, thanks
[15:44] <ppetraki> hi guys, I'm a little stumped here with the lpapi, trying to find bugs not owned by a certain group.
[15:44] <ppetraki> I'm getting ERROR: 'unicode' object has no attribute 'self_link'
[15:44] <ppetraki> , from the following code:
[15:45] <ppetraki> http://pastebin.com/zQyLiyyk
[15:48] <ppetraki> here it is with accompanying output: http://pastebin.com/hrJV8wnt
[16:58] <dobey> ppetraki: i don't think you want to use foo_link for anything in launchpadlib
[16:58] <ppetraki> dobey, :), I discovered that if I just dump the _link suffix it's fine
[16:59] <ppetraki> dobey, thanks
[16:59] <dobey> sure
[17:49] <ThiagoVespa> Please try again
[17:49] <ThiagoVespa> Sorry, there was a problem connecting to the Launchpad server.
[17:49] <ThiagoVespa> Try reloading this page in a minute or two. If the problem persists, let us know in the #launchpad IRC channel on Freenode.
[17:49] <ThiagoVespa> Thanks for your patience.
[17:50] <ThiagoVespa> I can't login into my account
[19:23] <oarcher> Hi. "Browse the code" from https://code.launchpad.net/~charmers/charms/precise/rabbitmq-server/trunk  on lp give 404, and 'bzr branch lp:charms/rabbitmq' give bzr: ERROR: Not a branch.   Is something wrong ?
[19:52] <lifeless> oarcher: perhaps there is not a charm ?


[18:47] <jelly> hmph, 1 od 3 auth dnsa za .hr ima podatke starije od 2 mjeseca i hrpa domena fali
[21:34] <MmikeM> https://nationalinterest.org/blog/buzz/b-2-bomber-has-more-firepower-aircraft-carrier-85246?
[22:14] <jelly> .rt jellese 1
[22:14] <datase> jelly: Robbie Fulks - She Took a Lot of Pills and Died
[22:14] <jelly> DJ na drogama
[22:44] <jelly> .rt jellese 1
[22:44] <datase> jelly: John Moreland - God's Medicine
[22:44] <jelly> nije to nego "Liquor and Whores"


[00:53] <JanC> hello, all, does somebody know if there is a known issue with single clicks sometimes being registered as double clicks, and at other times double clicks _not_ being recognized as such?
[00:53] <JanC> (mouse butten clicks)
[00:53] <JanC> button
[01:17] <bryce> did you look in launchpad?
[01:21] <JanC> not (really) yet, was just wondering if it's a well-known bug
[01:27] <JanC> at first sight I can't find anything, but not sure what to search for  :-/
[01:29] <JanC> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mouse/+bug/365300 sounds similar
[01:31] <JanC> it's like some events are eaten, and others are duplicated, or whatever
[01:32] <JanC> maybe I should also try with a wired mouse, but this didn't happen before karmic
[01:33] <JanC> and https://bugs.launchpad.net/ubuntu/+bug/339256 & https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/333005
[01:35] <JanC> and https://bugs.launchpad.net/ubuntu/+bug/325127
[01:35] <JanC> and https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/275590
[01:36] <JanC> bryce: seems like I'm not the only one with similar problems, although some have it for a much longer time
[01:49] <JanC> of course the main problem with this seems to be that it's not reproducible in any controlled way  :-(
[08:22] <hyperair> does anybody know what happened to xorg-driver-fglrx?
[08:24] <hyperair> oh wait nevermind
[14:00] <ScottK> What is the modern equivalent of dpkg-reconfigure xserver-xorg?  My laptop X locked up last night and won't start now.
[14:03] <hyperair> i believe it's rm /etc/X11/xorg.conf ;-)
[14:03] <ScottK> I'll see if I have one of those now.  Last I looked I didn't
[14:04] <hyperair> i don't think dpkg-reconfigure touches anything else other than xorg.conf
[14:04] <ScottK> Yeah, that's the problem.
[14:04] <hyperair> unless you're meaning you want a xorg.conf?
[14:04] <ScottK> It used to actually work for reconfiguring X.  Now it's mostly a no-op
[14:05] <hyperair> i remember there was an option to tell X to dump the xorg.conf
[14:05] <tjaalton> it doesn't call dexconf anymore
[14:05] <hyperair> then you can hand edit it?
[14:05] <ScottK> I have no xorg.conf (just looked)
[14:06] <tjaalton> it worked before the lockup?
[14:06] <ScottK> Yep
[14:06] <ScottK> I had it freeze once before, but that time restarting the system resolved it.
[14:06] <ScottK> Now it fails to start entirely
[14:06] <tjaalton> do you have a logfile?
[14:07] <ScottK> I'd like to get this troubleshot enough to where I can report a good bug.
[14:07] <ScottK> Yes.  Which do you want?
[14:07] <tjaalton> the one when it froze
[14:07] <tjaalton> or both, actually
[14:07] <ScottK> You mean Xorg.0.log?
[14:08] <tjaalton> yes
[14:08] <ScottK> OK
[14:08] <ScottK> I'll pastebin it in a moment (I have network, but no X on the box in question)
[14:09] <ScottK> tjaalton: http://pastebin.com/f4bcfe87d/
[14:10] <ScottK> tjaalton: Sorry, withtout the trailing "/"
[14:10] <tjaalton> ScottK: which one is this?
[14:11] <ScottK> The most recent
[14:11] <tjaalton> so you don't get a login screen? the log looks fine
[14:12] <ScottK> I don't.  I just get a black screen
[14:13] <tjaalton> there was a new intel uploaded yesterday, maybe downgrading it would help?
[14:13] <ScottK> Here's a point.  startx works.  kdm doesn't.
[14:13] <tjaalton> ah
[14:14] <ScottK> Just tried that
[14:14] <tjaalton> after the final line there should be the config/hal stuff
[14:20] <ScottK> http://pastebin.com/f3c2575d7 is now that I've logged in.
[14:25] <ScottK> And then once I got into KDE via startx, the next regular boot works.
[14:25] <tjaalton> huh
[14:25] <ScottK> Yeah
[14:26] <ScottK> So something got screwed and a successful login cleared it.
[14:26] <ScottK> In the future, if X just freezes, what's the most important thing to try and capture?
[14:26] <tjaalton> if you can login via ssh, get a backtrace
[14:27] <tjaalton> https://wiki.ubuntu.com/X/Backtracing
[14:27] <ScottK> This particular system I have very little luck ssh'ing into, but I'll try.  thanks.
[14:28] <tjaalton> if you can't switch the vt, then there's little you can do on just that system
[14:28] <tjaalton> s/on/with/
[14:28] <ScottK> OK.  I did try that and was unable to.
[14:30] <tjaalton> maybe the gpu was wedged, there's intel-gpu-tools which might help to get a dump
[14:30] <tjaalton> but that'd need sshd running AIUI
[14:30] <ScottK> OK.  I'll install that so I'm more ready for next time.
[16:24] <rickspencer3> bryce, are you online yet?
[17:15] <bryce> rickspencer3, yes
[17:15] <bryce> just did AMD call
[18:05] <rickspencer3> bryce, so ... mesa 7.6
[18:05] <rickspencer3> what are we going to do?
[18:14] <bryce> well, I guess I can put it in a PPA so as people find they need it we have something they can upgrade to
[18:15] <rickspencer3> bryce, I thought the current plan was to roll it out asap
[18:15] <rickspencer3> with a plan to roll back if needed
[18:16] <rickspencer3> and a set of criteria to trigger the roll back deciscin
[18:17] <bryce> hang on, I've not read all the emails in the thread yet
[18:20] <bryce> huh, ok
[18:23] <bryce> rickspencer3, there is a debian package of it, so we just need to merge it with ubuntu changes
[18:24] <rickspencer3> bryce, ok, the roll back plan will be key
[18:24] <rickspencer3> talking to marjo atm
[18:52] <tjaalton> thread?
[18:55] <bryce> tjaalton, was offlist; wasn't looking likely when I went to bed, but it seems alberto, rick, and asac worked out an acceptable compromise for us
[18:55] <tjaalton> cool
[18:56] <tjaalton> I think it's a no-brainer ;)
[19:00] <rickspencer3> bryce, could you please answer pitti's second question for me?

[19:00] <rickspencer3> My other concern is that there doesn't seem to be a final 2.6.0
[19:00] <rickspencer3> package, just a 2.6.1+gitsomething. If we upgrade to that, then we
[19:00] <rickspencer3> have the very same problem again: a git snapshot instead of a stable
[19:00] <rickspencer3> release. But if there's a tested 2.6.0 somewhere, let's get that
[19:00] <rickspencer3> uploaded (it was pre-approved in LP #420803 anyway).

[19:01] <rickspencer3> or tjaalton, or anybody ;)
[19:15] <bryce> I've got the debian package and am just checking through our recent cherrypicks to see what can be dropped
[19:27] <tjaalton> rickspencer3: if it's mesa he's referring to, we'd have a snapshot of the stable branch, not master
[19:27] <rickspencer3> thanks tjaalton
[19:28] <rickspencer3> I think bryce is packaging 2.6.0 for upload atm
[19:28] <tjaalton> 7.6 was branched after it was released
[19:29] <bryce> tjaalton, specifically, I'm merging from Debian's 7.6-1 package
[19:29] <tjaalton> ok
[19:29] <tjaalton> there's only one new bug that I saw from the debian bugtracker that we might not yet have. it's freedesktop bug 24131
[19:30] <jcristau> heh, i was going to say that
[19:30] <tjaalton> :)
[19:30] <jcristau> also maybe #550011
[19:31] <jcristau> those are the two mesa bugs reported since 7.6 was uploaded to sid, afaik
[19:32] <tjaalton> bryce: are you doing libdrm as well?
[19:32] <bryce> tjaalton, after mesa
[19:32] <bryce> tjaalton, or feel free to tackle it yourself if you have some time
[19:33]  * tjaalton shows puppy-eyes to the wife
[19:34] <tjaalton> no response, so I have some time ;)
[19:35] <jcristau> hah, looks like i prepared 2.4.14 a while ago, but never pushed/uploaded
[19:36] <tjaalton> nice
[19:38] <jcristau> ah, now i remember, i stopped because libpthread-stubs in sid is broken
[19:38] <jcristau> oh well
[19:39] <tjaalton> still is?
[19:40] <jcristau> yeah.  shouldn't affect libdrm other than adding a bogus dependency on it, though, so i'll go ahead
[19:41]  * rickspencer3 visualized tjaalton pulling a pair of bloody eyeballs out of his pocket and showing them to his wife
[19:41] <rickspencer3> close to Halloween I guess

[19:42] <jcristau> there, done
[19:43] <tjaalton> I've got "contacts" made of a split table tennis ball, they look rather nice
[19:45] <tjaalton> bryce: mesa itself doesn't need the new libdrm, but it's a prereq for intel 2.9 ;)
[19:45] <tjaalton> or at least recommended
[19:45] <tjaalton> as part of the Q32k9 release
[20:18] <ilPisano> hi, to use radeon KMS in karmic i only need to add the radeon.modeset=1 thing? (i have a r400)
[20:21] <bryce> tjaalton, right
[20:21] <bryce> ilPisano, it's kind of buggy but yeah
[20:22] <ilPisano> and with KMS i will get DRI2? atm in my xorg.0.log (without KMS) i have "(II) AIGLX: Screen 0 is not DRI2 capable"
[20:22] <ilPisano> is normal?
[20:29] <tormod> ilPisano, no that is not normal, for ati KMS = DRI2
[20:30] <ilPisano> i got that with no kms option, if i enable kms i should not see that error message?
[20:30] <tormod> ilPisano, right
[20:30] <ilPisano> ty, will try :9
[20:30] <ilPisano> :9
[20:30] <tormod> ilPisano, sorry I did not see you wrote "without kms"
[20:30] <ilPisano> :)
[20:34] <tjaalton> hrm, how easy it would be to merge libdrm if the changes since 2.4.12-1u1 were done in git..
[20:35] <tormod> tjaalton, merging with Debian?
[20:35] <tjaalton> tormod: yes
[20:36] <tjaalton> .14-1 was pushed 1h ago
[20:36] <tormod> tjaalton, aha
[20:36] <tormod> I was just about to make one for x-updates, I'll wait a bit then :)
[20:37] <tormod> s/x-updates/xorg-edgers
[20:38] <tjaalton> huh, 2.4.12+git20090801.45078630-0ubuntu1 was a mess
[20:38] <tormod> tjaalton, so you are gonna get a new libdrm through in karmic?
[20:38] <tjaalton> based on 2.4.9-2ubuntu1
[20:38] <jcristau> sounds like fun
[20:38] <tjaalton> tormod: we were discussing it before you joined
[20:39] <tormod> let me browse the log then
[20:39] <tjaalton> we'll see what comes from this
[20:40] <tjaalton> jcristau: bad sarvatt :)
[20:40] <bryce> tormod, we reached a compromise last night to get mesa 7.6, etc. in; we need to have a good plan to roll back the changes if there are serious issues
[20:40] <tjaalton> bryce: what's "etc", intel 2.9 too?
[20:40] <tormod> tjaalton, why do look at 2.4.12+etc when there is 2.4.13-1ubuntu1?
[20:41] <tjaalton> tormod: I need to track the changed done between 2.4.12-1u1 and nwo
[20:41] <tjaalton> *now
[20:41] <tjaalton> *changes
[20:41] <tjaalton> damn
[20:41] <tjaalton> sticky kbd
[20:42] <bryce> tjaalton, indeed, since it is mostly a bug fix release I got a go ahead on it; but we should do it on a different day from mesa so it'll be easier for testers to bisect if there are problems.
[20:42] <tormod> bryce, sounds good, where was this discussed?
[20:42] <tjaalton> bryce: was xserver discussed?
[20:43] <bryce> tormod, unfortunately it was all off list
[20:44] <bryce> tjaalton, yes I got an ok on that too :-)
[20:44] <tjaalton> meh, I'll bypass 2.4.12+git200909... and just look at what's in .13-1u1
[20:44] <jcristau> debian #548045 is a (ums) regression in 2.9, fwiw
[20:44] <tjaalton> bryce: nice
[20:44] <tjaalton> who cares about ums anyway ;)
[20:45] <bryce> tormod, yeah I put in a complaint about how these decisions were reached, without involving us X folk, but we decided to separate the issue of how this all was decided, from making the correct decisions.  The former needs sorted out better, but the latter is the immediate focus.
[20:46] <tormod> bryce, sounds good!
[20:46] <tjaalton> indeed it does
[20:47] <tjaalton> perhaps we could put a mesa 7.6-branch snapshot on a ppa right away, so if people report issues with 7.6 they could try it out immediately
[20:48] <tjaalton> I see some memleak fixes there
[20:48] <bryce> tjaalton, I've a copy of the package I'm working on at https://edge.launchpad.net/~bryceharrington/+archive/ppa/+packages
[20:48] <tormod> reading the log, what package is "2.6.0" ?
[20:48] <bryce> tjaalton, code and patches are all sorted, just need to fill out the changelog
[20:49] <tjaalton> tormod: a typo, I think
[20:49] <bryce> tormod, that should be 7.6.0
[20:49] <tormod> tjaalton, x-updates?
[20:49] <tjaalton> tormod: makes sense
[20:49] <bryce> x-updates == xorg-edgers
[20:49] <tormod> tjaalton, you missed my e-mails on ubuntu-x ?
[20:49] <tjaalton> looks like it :)
[20:49] <tormod> I put mesa 7.6 into x-updates long time ago
[20:49] <tormod> many people have been testing iy
[20:50] <tormod> bryce, x-updates != xorg-edgers
[20:50] <tormod> xorg-edgers has 7.7
[20:50] <tjaalton> right, but a snapshot of the branch, ie. what will become 7.6.1
[20:50] <tormod> tjaalton, it has
[20:50] <tjaalton> ah ok
[20:50] <tjaalton> good
[20:51] <tormod> I updated it every day from before the RC1
[20:51] <tormod> I had planned to make a new snapshot today
[20:51] <tjaalton> maybe I should merge libdrm in the morning when feeling more awake
[20:52] <tjaalton> I'll update my laptop to it
[20:52] <tormod> but was thinking of doing a libdrm first, but I'll hold that off until you've finished the merge :)
[20:52] <tjaalton> or, maybe via 7.6-1u1 first
[20:52] <tormod> is 7.6-1 out?
[20:53] <tjaalton> for a week now
[20:53] <tormod> debian is alive again \o/
[20:53] <jcristau> when was it not?
[20:53] <tjaalton> right :)
[20:54] <bryce> tjaalton, waiting til the morning is a good call
[21:12] <rickspencer3> bryce, how's it going?
[21:15] <bryce> I stuck a preliminary version in my ppa to check that it builds - https://edge.launchpad.net/~bryceharrington/+archive/ppa/+packages
[21:15] <bryce> I've built it successfully locally
[21:16] <bryce> I want to fill in the changelog a bit more before uploading it
[21:16] <rickspencer3> ok
[21:16] <rickspencer3> seems that Steve has some quite valid concerns regarding intil 2.9.0
[21:16] <rickspencer3> -intel, that is
[21:17] <rickspencer3> ah, I see you replied
[21:17] <rickspencer3> apw, thoughts on -intel 2.9.0?
[21:20] <rickspencer3> bryce, I'll install from your ppa
[21:21] <rickspencer3> oops
[21:21] <rickspencer3> still buidling
[21:22] <tormod> rickspencer3, just want to inform you that many people have been running mesa 7.6 packages from the x-updates PPA with luck
[21:23] <rickspencer3> tormod, thanks
[21:23] <rickspencer3> that is understood, and why we are considering it a fairly safe bet
[21:23] <rickspencer3> the main problem is that we have limited time to complete the feedback loop on a wide set of machines
[21:23] <rickspencer3> and if we want to update -intel as well, we are certainly complicating matters
[21:24] <tormod> rickspencer3, yes it should have been pushed in earlier. but I am pretty confident it fixes a lot more than it would break
[21:24] <rickspencer3> tormod, understood
[21:25] <rickspencer3> we are trying to do the right thing
[21:25] <tormod> sounds like a good plan
[21:25] <rickspencer3> updating -intel as well is giving me some heart ache
[21:25] <bryce> tormod, offhand do you know of bug report#'s which will be solved with mesa 7.6?
[21:26] <jcristau> iirc intel 2.8.1 was pretty solid, compared to earlier releases?
[21:26] <Duke`> hello, could someone test the following thing for me please: http://pastebin.com/m13b90154 ? I'm tracking a strange performance regression
[21:27] <tormod> lp bugs? no I haven't looked much for it. but there are comments many places where people have been trying out xorg-edgers and say it's better - although that's mesa trunk
[21:28] <tormod> the scary part about intel is if kernel patches are needed
[21:28] <rickspencer3> tormod, I don't think we'll be doing it if it requires kernel patches
[21:28] <rickspencer3> perhaps we should send a summary of these changes to ubuntu-devel list
[21:28] <rickspencer3> allow some discussion
[21:28] <jcristau> tormod: well it should run just fine on <IP_ADDRESS>
[21:29] <tormod> I am not saying that 2.9.0 requires kernel patches
[21:29] <rickspencer3> (and include qa and roll back planning)
[21:29] <tormod> just that many -intel bugs might need kernel patches (whether we ship with an old snapshot or with the 7.6 release)
[21:29] <rickspencer3> ah
[21:29] <rickspencer3> right
[21:30] <tormod> I think intel 2.9 is mostly bug fixes from 2.8. it's not the whole reorganisation we saw in earlier releases
[21:31] <jcristau> 2.10 will be the 'no more ums' release
[21:33] <Duke`> what is UMS?
[21:33] <rickspencer3> tormod, if I install this:
[21:33] <rickspencer3> https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/756325/+listing-archive-extra
[21:33] <rickspencer3> will I get the intended version of -intel?
[21:33] <tormod> rickspencer3, you should install the libdrm from the same ppa
[21:34] <rickspencer3> so the changes are:
[21:34] <rickspencer3> 1. mesa 7.6
[21:34] <rickspencer3> 2. libdrm
[21:34] <rickspencer3> 3. -intel
[21:34] <rickspencer3> If I install that now, i will have what will be in Karmic on Friday?
[21:34] <tormod> rickspencer3, all the packages in the xorg-edgers ppa kind of depend on each other, so you better take them all
[21:34] <rickspencer3> oh?
[21:35] <tormod> rickspencer3, note that xorg-edgers has mesa 7.7 (that's the edge)
[21:35] <tormod> rickspencer3, you probably want to try mesa from x-updates ppa
[21:35] <rickspencer3> tormod, I just want to set up my computer so it has the exact bits being proposed
[21:36] <rickspencer3> ah
[21:36] <tormod> rickspencer3, get mesa 7.6 from x-updates and -intel 2.9.0 from drivers-only
[21:36] <rickspencer3> tormod, so I don't need a libdrm as well?
[21:36] <rickspencer3> just the mesa and -intel from x updates?
[21:36] <tormod> rickspencer3, no not for x-updates, it is built against the karmic libdrm
[21:37] <tormod> -intel from "drivers-only" ppa (also no new dependencies)
[21:37] <rickspencer3> (sorry to be dense, but I want to be crystal clear)
[21:37] <rickspencer3> oh
[21:37] <rickspencer3> so, there is no proposal to update karmic's libdrm from what is currently in karmic?
[21:38] <tormod> rickspencer3, ideally you build: libdrm -> mesa -> xserver -> ddx
[21:38] <rickspencer3> so could you educate me on how this is going to go down for karmic?
[21:39] <rickspencer3> as it seems that what is proposed is just a surgical replacement of mesa, and another replacement of -intel
[21:39] <tormod> rickspencer3, there is I think. you _can_ take libdrm 2.4.14 from xorg-edgers, mesa from x-updates and -intel from drivers-only
[21:39] <rickspencer3> when the new mesa goes in, that causes a rebuild of the other components?
[21:39] <tormod> this will give you pretty much what we anticipate for karmic
[21:40] <rickspencer3> what's the "pretty much" factor?
[21:40] <rickspencer3> modula future patches for bug fixes?
[21:40] <tormod> rickspencer3, no, you don't really need to rebuild xserver and dds after mesa updates, unless major rework has been done
[21:41] <tormod> pretty much = if some features in the mesa build checks for features in the installed libdrm, these will not be taken in in these ppas
[21:41] <rickspencer3> I think I'll wait until stuff gets uploaded as normal
[21:41] <tormod> same for ddx, some features are built depending on the installed libdrm, hence the ideal build order
[21:42] <rickspencer3> I think I'll spend so much time having you guys explain everything to me, that my testing will be of no hel
[21:42] <rickspencer3> but, it's good to understand a little better what's going on
[21:42] <bryce> ok I think the mesa 7.6 package is good to go now
[21:43] <tormod> rickspencer3, it's just adding the xorg-edgers ppa, install libdrm, remove xorg-edgers, add x-updates and card drivers and update
[21:43] <bryce> rickspencer3, ok uploaded.
[21:43] <rickspencer3> sweet
[21:43] <bryce> yeah this stuff can all get complicated
[21:43] <tormod> bryce, great
[21:43] <rickspencer3> so dist-upgrade in a few hours, and we've got new mesa
[21:44] <bryce> in our situation right now, we're a bit lucky in that none of these pieces interdepend on each other or on anything else (like the kernel) that we don't have
[21:44] <rickspencer3> tomorrow, same thing with -intel, I suppose
[21:44] <bryce> right
[21:44] <rickspencer3> wasn't their a third piece to update?
[21:44] <tormod> rickspencer3, it will be much less dramatic than say, replace init after feature freeze ;)
[21:44] <rickspencer3> tormod, please, don't go there
[21:45] <rickspencer3> :)
[21:45]  * rickspencer3 clutches chest
[21:45] <bryce> libdrm and xorg-server are also in scope to do, those are both quite minor and just bug fix releases
[21:45] <rickspencer3> tormod, we are quite worried because of our experience in Jaunty
[21:45] <bryce> "in scope as options to do"
[21:45] <rickspencer3> bryce, ack
[21:45] <rickspencer3> do you need freeze exceptions for those?
[21:46] <tormod> rickspencer3, jaunty shipped with -intel 2.5 instead of the released 2.6 IIRC
[21:46] <bryce> dunno, but I'll go ahead and file FFes for them anyway
[21:46] <rickspencer3> tormod, right, I don't think the situations are comparible
[21:46] <bryce> I think they should be quite straightforward, but any extra public review cannot hurt
[21:47] <tormod> and for everything else than -intel, jaunty was a great step forward
[21:47] <rickspencer3> so I was just referring to the emotions, not the logic of the situation
[21:49] <tormod> the -intel guys were open about things going backwards a bit for a while, and it did. the situation now is different for sure
[21:50] <tormod> rickspencer3, we have so few ubuntu X resources so we have to play well with upstream. but now I going into that longer discussion, let's focus on karmic now :)
[21:50] <rickspencer3> hehe
[21:51] <rickspencer3> I think the right things are happening now
[21:51] <bryce> rickspencer3, shall I put a note about mesa 7.6 to ubuntu-devel, or do you want to do that?
[21:51] <rickspencer3> bryce, could you please
[21:51] <tormod> karmic just got a lot more karma :)
[21:51] <rickspencer3> bryce, you may want to mention *as planned*
[21:51] <rickspencer3> *occording to our previous plan*
[21:51] <rickspencer3> *as scheduled*
[21:51] <rickspencer3> etc...
[21:52] <rickspencer3> ;)
[21:52] <bryce> alright, on it
[21:53] <rickspencer3> hehe
[22:00] <tormod> I have heard about only one regression on 7.6 (https://lists.ubuntu.com/archives/ubuntu-x/2009-September/000631.html) and it got fixed today
[22:03] <tormod> (just after I made the new x-updates snapshot, of course)
[22:51] <bryce> Hrm.
[22:51] <bryce>  Rejected:
[22:51] <bryce>  mesa_7.6-1ubuntu1.dsc: Version older than that in the archive. 7.6-1ubuntu1 <=
[22:51] <bryce>  7.6.0~git20090817.7c422387-0ubuntu8
[22:52] <jcristau> i guess you get to rename it to 7.6.0-1u1
[22:54] <bryce> yep
[23:00] <tormod> bryce, maybe you want to cherrypick the above bug fix before you reupload :)
[23:05] <bryce> too late
[23:06] <bryce> but you're right
[23:12] <tormod> wait till the new libdrm anyway, so it builds in order :)
[23:12] <bryce> ok
[23:12] <jcristau> doesn't matter, really
[23:13] <tormod> I guess not, in this case
[23:19] <jbarnes> how do I disable services at boot in the brave new world of native upstart scripts?
[23:19] <jbarnes> the services applet seems to have disappeared
[23:23] <Ng> I've seen suggestions to rename the /etc/init/foo.conf to foo.conf.disabled, but I'm not sure how Correct that is
[23:25] <jbarnes> I'll try it
[23:25] <jbarnes> wanted to be able to start it later possibly
[23:29] <rickspencer3> hi jbarnes
[23:29] <jbarnes> rickspencer3: hi
[23:44] <bryce>  <alanc> that's not a bug, it's rendering in Pink for Breast Cancer Awareness month 8-)
[23:47] <rickspencer3> jbarnes, I checked in #ubuntu-devel for you
[23:47] <rickspencer3> indeed, you are kind of on your own, adding and removing files from /etc/init I am afraid
[23:48] <jbarnes> oh well
[23:48] <jbarnes> rickspencer3: thanks
[23:48] <rickspencer3> jbarnes, sorry, I will log a bug for you
[23:48] <rickspencer3> essentially, the applet will need to be ported
[23:49] <jbarnes> rickspencer3: btw did you see the X release process changes we discussed at XDC?
[23:49]  * jbarnes digs up a link
[23:49] <jbarnes> http://www.x.org/wiki/XServer
[23:49] <rickspencer3> jbarnes, I did see a reference, but haven't had time to look closely
[23:49] <jbarnes> bryce, rickspencer3 ^^
[23:49]  * rickspencer3 reads
[23:49] <jbarnes> if it works people could start thinking about moving things around
[23:50] <jbarnes> might be good to have kernel release, then X, then gnome, then distros
[23:50] <rickspencer3> jbarnes, is there somewhere in there that I could help?
[23:50] <jbarnes> maybe, I haven't looked at the latest page
[23:51] <jbarnes> I'd ping peter & xorg-devel
[23:51] <jbarnes> peter hutterer that is
[23:51] <rickspencer3> I'm not excatly made of free time, but I think we could spare some PM-type resources
[23:52] <rickspencer3> nice to see that they RM lined up
[23:52] <rickspencer3> that is great
[23:52] <jbarnes> yeah
[23:52] <jbarnes> we'll see if it sticks
[23:53] <rickspencer3> well, I'll see if I can pick up a couple hours of busy work from it
[23:53] <rickspencer3> free up the engineers
[23:53] <jbarnes> cool
[23:53] <jbarnes> bug herding and nagging would both be big helps I think
[23:53] <rickspencer3> yeah
[23:54] <rickspencer3> "those who can't do, nag"
[23:54]  * rickspencer3 feels hair get a bit pointier
[23:55] <jbarnes> haha