[15:50] <adesai_> Hi guys
[15:50] <adesai_> Could you help me with the issue I'm having?
[15:51] <adesai_> After upgrading Linux kernel from 4.4 to 4.12, I cannot see the option to enable WiFi. iwconfig shows no wireless extension.


[13:54] <studio-user928> help < l'installation les fichiers ne s'installe pas
[13:55] <studio-user928> hrlp reste bloqué a ext 2
[13:56] <studio-user928> help reste bloqué < création syste de fichier ext 2
[14:03] <studio-user928> help failed to load module
[19:44] <Mortus> Hello all.
[19:49] <Mortus> Having some strange menu issues with my fresh install of Ubuntu Studio 16.04 if some one is available to help me track it down.
[20:02] <Mortus> Okay, had a flash thought to make sure I was actually logged in under the Ubuntu Studio session and not plain XFCE. That does not seem to be the issue.
[20:03] <Mortus> If anyone comes along that can help me track down why the Ubuntu Studio menus are missing, any help if appreciated.
[20:24] <krytarik> Mortus: Is it LP bug 1430571 perhaps?
[20:25] <Mortus> Could well be, but I am a little confused as to what the fix actually is, if one is yet present.
[20:31] <Mortus> Ah, okay, found the solution eventually. Alot of voodoo and half explanations to read.
[20:59] <Mortus> Thanks for the help. Have that sorted out at last. Was wondering why I could not find a bunch of my applications.
[21:01] <krytarik> You are welcome.
[22:10] <OvenWerks> krytarik: Thank You
[22:11] <krytarik> Well, hi OvenWerks. :)


[04:50] <archpower> hi
[05:19] <stlsaint> archpower: o/
[05:19] <archpower> hows it going
[05:20] <stlsaint> archpower: nm
[05:20] <stlsaint> archpower: you in texas?
[05:20] <archpower> yeah
[05:20] <archpower> well not atm
[05:21] <archpower> but im from texas
[05:22] <archpower> dallas
[05:23] <stlsaint> ah kk
[05:36] <archpower> Just finished this project the other day:
[05:36] <archpower> http://postimage.org/gallery/12fax27w/
[05:37] <stlsaint> archpower: wow man built from scratch??
[05:41] <archpower> its a 1969 mustang fastback - some suttle some not so suttle changes to this one.
[05:44] <archpower> i cut the whole roof out and made my own roof, we widened the rear-end of the car, its no longer a subframe we built our own chasis. 6 speed, and this is a rare one of 10 all aluminum 494 cubic inch.
[05:44] <archpower> the engine i mean
[05:45] <archpower> its got electric breaks, electric steering . its got those brembos
[05:45] <stlsaint> archpower: man i know nothing really about cars...your going way over my head. I stick to computers
[05:47] <archpower> we made all the interior look like the 2012 mustangs
[05:47] <archpower> we made the dash and everything
[05:48] <archpower> we made the taillights
[05:49] <archpower> its really subtle.


[03:38] <chila> hello
[03:44] <chila> i need some help
[03:44] <chila> with ispconfig
[03:44] <chila> can someone help me
[03:52] <chila_> can anyone help with configuring ispconfig
[03:53] <chila_> am I doing this right
[03:53] <chila_> or is no one really talking
[04:00] <chila> hello again
[04:03] <chila> hello
[04:08] <chila> i need help still
[02:30] <heno> Hi. would bug 19889 and bug 65047 typically be the domain of the server team?
[02:30] <heno> (ah, no ubugtu here)
[02:31] <heno> https://bugs.launchpad.net/ubuntu/+source/sysklogd/+bug/19889 https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/65047
[02:34] <heno> shawarma: ^ ?
[02:40] <shawarma> snmp and sysklogd smells like server stuff, so I'd say yes.
[02:40] <shawarma> heno: ^^
[02:42] <heno> shawarma: ok, thanks. These are high impact bugs that we should consider SRUsfor, so if anyone on the team has a chance to poke at them, that'd be great
[02:42] <heno> (it will also make elmo very happy :) )
[02:44] <shawarma> heno: ia64 is not even an officially supported platform? Do we do SRU's for those then?
[02:45] <shawarma> I don't mind doing it, I'm just wondering.
[02:46] <heno> shawarma: if they are ia64-specific, then no, but are they?
[02:47] <shawarma> heno: The first two comments suggest so, as does the bug we link to in Debian. I'm looking at it right now.
[02:48] <heno> thanks
[02:49] <shawarma> heno: Yeah, the original reports talks about snmpd (the daemon) while the last comment (on an intel core duo) looks like an entirely different issue.
[02:49] <shawarma> heno: I'll put it on my todo list (near the top).
[02:49] <mralphabet> somebody mentions reproducable on i386
[02:50] <heno> shawarma: great thanks! I'll find out what our policy on ia64 is
[02:50] <shawarma> mralphabet: No. a) He's talking about the client crashing, b) he's not on Dapper.
[02:50] <shawarma> mralphabet: ...if we are speaking of the same person, of course.
[02:51] <shawarma> mralphabet: this guy? https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/65047/comments/2
[02:51] <mralphabet> sorry, I was looking at the sysklogd one
[02:51] <shawarma> mralphabet: Oh, ok. I haven't checked that one yet.
[02:53] <mralphabet> didn't mean to get signals crossed there ;)
[02:58] <shawarma> mralphabet: Oh, don't feel bad for piching in. It's quite alright.
[03:34] <bkudria> hello. i'm on feisty, and i'm trying to get phpmyadmin to work with mysql-server
[03:34] <bkudria> i've changed the mysql password for the 'root' user
[03:34] <arthur_kalm> Hi everyone, this is driving me a little crazy... our servers cannot maintain accurate time. Every time I check up on them they are a minute or two behind. Now what I really don't understand is, I already set up ntpd. I know that the server in the configuration file works because I had manually set the time to it. So is there a way to increase the number of times ntpd updates time with the server?
[03:34] <bkudria> but phpmyadmin bounces me back to the login page, without an error.  what is wrong?
[03:35] <arthur_kalm> bkudria: have you checked phpmyadmin's logs to see what the actual error is?
[03:40] <bkudria> arthur_kalm: checking logs?  pshaw, no! :)
[03:41] <bkudria> err, does phpmyadmin *have* logs?
[03:43] <bkudria> hmm, login works with firefox, not with konqueror - doesn't sound like a server-side issue
[03:45] <bkudria> grrr, and now firefox logged me out and is doing the same thing.  what is going on?
[03:48] <bkudria> aah, got it
[03:48] <bkudria> http://www.cwassall.co.uk/pages/linux/ubuntu.html#resolving-phpmyadmin-login-issues
[03:48] <bkudria> uses cookies by default, and this breaks things
[03:48] <bkudria> *I* shall file a bug!
[04:08] <bkudria> for anyone else who is confused, if you are trying to get phpmyadmin cookie auth (the default) to work on an amd64 system, you need to install php5-mcrypt.  i think it works fine on an x86 system
[04:09] <shawarma> bkudria: Why would you think that?
[04:09] <bkudria> shawarma: https://bugs.launchpad.net/ubuntu/+source/phpmyadmin/+bug/114044
[04:09] <bkudria> this problem fixed in gutsy
[04:09] <bkudria> although there is a different mcrypt bug in gutsy which makes things worse, for now
[04:10] <bkudria> but in feisty, installing php5-mcrypt miraculously fixes it instantly
[04:10] <shawarma> Interesting.
[04:10] <bkudria> maddening
[04:12] <lionel> this bug would be a good candidate for SRU
[04:13] <bkudria> what is sru?
[04:15] <lionel> Stable Release Update
[04:15] <lionel> pushing the fix in Feisty
[04:15] <bkudria> aah.  yep, seems like it
[04:15] <bkudria> since it is only adding a package to Depends:
[04:16] <lionel> really small change, but it would save people time :)
[04:16] <bkudria> phpmyadmin is a popular package
[04:16] <lionel> I know
[04:19] <shawarma> I actually thought it was in main..
[04:27] <lionel> he no :)


[00:57] <smp4488> im trying to get openbox to run on my beagleboard xm. When i start x the screen flickers but the logs are showing no protocol specified
[01:01] <smp4488> got it! needed to delete all the .Xauthority files in /~
[03:16] <jeramee> hi guys
[03:22] <persia> hey jeramee
[13:25] <mahmoh> ppisati: testing the latest 3.0.0-1~dd and seeing kjournald timeouts with IO tests, unsure if they're new or not
[13:49] <ppisati> mahmoh: how did you get it?
[13:50] <cmagina> ppisati: he said he was running io stress tests
[13:51] <cmagina> one thing i noticed were the usb resets found before the hung task warnings
[13:51] <ppisati> usb hardisk?
[13:51] <cmagina> i believe so
[13:56] <cmagina> ppisati: yeah, it has a usb disk enclosure plugged into an externally powered hub
[13:59] <ppisati> unfortuntaley it seems usb support is flaky
[13:59] <ppisati> and it has been like this for a while
[14:00] <ppisati> e.g. lp 709245
[14:00] <ubot2> Launchpad bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed] https://launchpad.net/bugs/709245
[14:00] <ppisati> if you ping the board while doing I/O tests, performance improve
[14:01] <mahmoh> it's getting pinged now and still seeing the resets
[14:05] <ppisati> can you try with a natty kernel?
[14:07] <mahmoh> natty?  I guess, can you point me to a package?  I think GrueMaster confirmed yesterday that he saw it with natty and maverick, the usb ping problem
[14:07] <GrueMaster> ppisati: I have tested this with a natty image as well as a maverick image.
[14:08] <mahmoh> I think it makes more sense to crash or dump when the problem occurs so we can see what's actually happening, no?  cmagina?
[14:08] <GrueMaster> And apparently it has also been reproduced on a beagleXM.
[14:09] <GrueMaster> It is a problem with either the usb chip or the driver for it.  prpplague has more insight.
[14:10] <cmagina> mahmoh: doubt it, as the crash would occur ~2 minutes after the usb reset occurred and that is the probable culprit for the hang
[14:10] <mahmoh> could we lower the timeout and attempt the crash that way?
[14:11] <ppisati> imo the best thing we can do is a fill a new bug for it (how to reproduce it, logs, etcetc) so we can forward it to more people
[14:11] <ppisati> TI, usb ml, arm, more people can see it, etcetc
[14:11] <mahmoh> or throw USB into debug?  what's the best approach here?
[14:11] <ppisati> but yes, the usb support for all the omap chips so far always had problems
[14:13] <mahmoh> http://pastebin.ubuntu.com/649155/
[14:14] <ppisati> uhmmm
[14:14] <ppisati> updatedb.mlocat? at the same time with an IO test? i bet it's stuck! :)
[14:16] <mahmoh> what's updatedb.mlocat from?
[14:18] <ppisati> mahmoh: from your pastebin -> Started Run 1 @ 05:29:28[27121.715026] INFO: task updatedb.mlocat:7519 blocked for more than 120 seconds.
[14:22] <cmagina> heh, missed that
[14:25] <GrueMaster> Next time you guys run io tests, you should run "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" first.  That will disable the timeout errors (what you are seeing).
[14:25] <mahmoh> yep, but what is "updatedb.mlocat", part of the fs?
[14:27] <GrueMaster> It may have nothing to do with the test suite.  Notice you also have an error in that pastebin from java.
[14:27] <cmagina> no, updatedb.mlocate generates the index that the locate commands uses
[14:28] <cmagina> its a cron job
[14:28] <cmagina> you should disable it
[14:28] <GrueMaster> No, leave the background tasks alone.  Just run the echo command above.
[14:29] <mahmoh> it's part of the default system plus we're on a dual core board, it should be fine
[14:29] <cmagina> its not cpu bound, its io bound
[14:29] <GrueMaster> we're hitting generic kernel timeouts on panda.  We either disable them (as above) or we change the kernel config.  I suggest manually disabling them first.
[14:29] <mahmoh> as for the timeouts, those should not occur either, I want to see when they happen
[14:30] <cmagina> the hung task timeout is just notifying you of the problem
[14:30] <cmagina> of a problem
[14:30] <mahmoh> exactly
[14:30] <cmagina> this could be that the system is thrashing as well
[14:30] <GrueMaster> Find out what the default timeout is and try increasing it.
[14:30] <mahmoh> 120s
[14:30] <GrueMaster> So try doubling it and rerunning.
[14:32] <cmagina> i would leave it, its not the problem, what we need to know is if we are getting completely hung or if the system is just thrashing under the load and as a result some processes are not getting the time they need
[14:32] <mahmoh> I'm not tweaking the system at this point except to debug this problem
[14:32] <mahmoh> so how do we find that out?
[14:32] <cmagina> we could enable sar data gathering and see if we are seeing high io wait times
[14:32] <cmagina> not sure if there is an easier way
[14:33] <mahmoh> hm, it is running the threaded io tests after all, hm, and elevator=deadline
[14:33] <GrueMaster> Look at your logs and see exactly what test reproduces this, then rerun just that test with different timeout settings.
[14:38] <mahmoh> ppisati: so this is with the 300-1~dd kernel, but I'm pretty sure it'll happen with stock, should I switch back or push forward?  I'm going to try the same thing on two other boards
[14:39] <mahmoh> the problem is there's no schedule as to when this occurs but I may be able to force it running background IO tasks (like updatedb.mlocat)
[14:39] <GrueMaster> mahmoh: I think you are beating a dead horse.  We need to keep moving forward.
[14:39] <mahmoh> you may be right but if there's a fundamental problem that needs to be fixed then it should be looked at; I can dedicate one board for this and push on on the other ones
[14:40] <cmagina> mahmoh: 252 is currently hovering around 70% io_wait
[14:40] <GrueMaster> There is a fundamental problem, but we do not have the resources or time to dedicate everything to it.  Others outside ubuntu are also looking at it.
[14:41] <GrueMaster> One board is good.  3 is a bit much.
[14:41] <cmagina> and by adding updatedb, it hit ~90%
[15:05] <siji> persia, you there?
[15:30] <GrueMaster> mahmoh: In reply to server kernel question in #u-meeting, there probably won't be a server specific kernel.
[15:30] <mahmoh>  then install should add a scheduler line to boot, Daviey?
[15:31] <GrueMaster> I don't know what the differences are on x86, or if they have any affect on armel.  May be worth looking into after Alpha 3.
[15:31] <mahmoh> sounds like just a bug to me, where should it go if it's against the installer vs. kernel image?
[15:32] <GrueMaster> It can be added to the server preinstalled images fairly easily I would think.  Not sure about netinstall.
[15:33] <mahmoh> should be both
[15:33] <GrueMaster> We should run some benchmarks on it to see if it helps performance on armel.
[15:33] <Martyn> GrueMaster ; What are the major differences, if any, between the desktop and the server kernel for x86?
[15:33] <GrueMaster> I know it should be both, just not sure how to go about it with netinstall.
[15:34] <GrueMaster> Martyn: ENOIDEA.
[15:34] <Martyn> copy that
[15:34] <mahmoh> it should install server kernel when selecting Ubuntu Server
[15:34] <Martyn> I'll take a look at it right now
[15:34] <GrueMaster> Hence why I raised the question.
[15:34] <mahmoh> scheduler is diff.
[15:34] <ppisati> janimo: i couldn't fidn any marvin24 3.x kernel on gitorius
[15:34] <janimo> ppisati, I think he justs sends stuff to lkml or the tegra list, at least that was my impression
[15:34] <janimo> are you on #ac100 ?
[15:35] <janimo> I do not know of a 3.0 kernel of his, just saw him active upstream
[15:38] <ppisati> yep, i'm on ac100
[15:41] <mahmoh> GrueMaster: so where should an arm-server-kernel bug request go? and where should a net-install-server bug go?
[15:42] <GrueMaster> I have no idea.  This is the first server work i have done with Ubuntu.
[15:43] <mahmoh> it's not server related it's either kernel image related or installer related, where do those bugs live?
[15:43] <GrueMaster> In launchpad.  beyond that I don't know.
[15:44] <GrueMaster> File a bug on the kernel for tracking purposes.
[15:44] <GrueMaster> From there, a comparison should be made on x86, and the relevant bits tested on arm.
[17:05] <arcaico> Hello, I am using ubuntu linux on SDcard .. my root (/) filesystem is not the total size of the sdcard
[17:05] <arcaico> my (df -h) is http://pastebin.com/fw6zeG5D
[17:07] <GrueMaster> arcaico: What image is this ?
[17:11] <arcaico> Linux FriendlyARM <IP_ADDRESS>-FriendlyARM #2 Sat Jun 26 13:24:08 CST 2010 armv6l GNU/Linux   --- by: http://www.friendlyarm.net/
[17:15] <GrueMaster> I have no idea what that is or where it comes from.  Not an Ubuntu linux for sure.
[17:16]  * GrueMaster doesn't even see any references to Ubuntu on their web page.
[17:17] <arcaico> GrueMaster, http://www.youtube.com/watch?v=mBN0BUWoxa0
[17:17] <arcaico> http://kanebebe.dip.jp/download/ARM11-6410-DVD/images/Ubuntu/
[17:18] <GrueMaster> Unfortunately, we dropped support for 9.10 at the beginning of this release cycle, and since 10.04 have only supported armv7.
[17:18] <GrueMaster> You might have better luck with debian arm.
[17:20] <arcaico> Ok GrueMaster, I will give a researched
[17:23] <GrueMaster> mahmoh: Have you been able to do preseeding with netinstall yet?
[17:23] <mahmoh> not yet, should work fine though
[17:24] <GrueMaster> Ok.  No worries, just curious.
[17:24]  * GrueMaster was getting ready to reinstall on one of the pandas in the pool.


[00:34] <ScottK> janimo: It's the first time the dbus/dbus.cpp code's been built on arm* in a python3 environment.  Might be something with that or barry's patch then.  Thaks.
[00:34] <slangasek> cjwatson: any chance you could push your debhelper merge to the bzr branch?  importer doesn't seem to be grabbing it
[00:38] <cjwatson> slangasek: hm, I didn't do it in bzr as it happens; is a local import-dsc likely to fare any better than the importer?
[00:38] <slangasek> not sure :/
[00:38] <slangasek> cjwatson: actually, import-dsc fails for native packages
[00:38] <slangasek> so no
[00:39] <slangasek> (also, not sure if it does sane things with branches for merges)
[00:40] <cjwatson> I guess I can try to reconstruct something
[00:41] <cjwatson> actually, I think it would be bad to try - lp:debian/sid/debhelper is out of date so if I tried it would result in a lack of merge metadata
[00:41] <slangasek> right
[00:42] <slangasek> so maybe we should just get the importer kicked
[00:42] <cjwatson> I think so
[00:56] <psusi> cjwatson, is it time to poke you about my parted/dmraid/multipath-tools merges yet? ;)
[01:11] <Jatinder> Good Morning Everyone !!!
[01:12] <Jatinder> How to remove complete GUI of Ubuntu 11.10?
[01:12] <Jatinder> I tried this : sudo apt-get remove ubuntu-desktop
[01:13] <Jatinder> but system replied that it will remove only 16kb of the data
[01:13] <slangasek> Jatinder: this is not a support channel; please see #ubuntu
[01:14] <Jatinder> Sir I am trying to work on derived ubuntu so thought its developers' talk
[01:14] <Jatinder> so got into here
[01:14] <slangasek> well, that's not a development question :)
[01:15] <Jatinder> okay. i'll  leave then
[01:48] <smoser> slangasek, ping
[01:48] <slangasek> smoser: hey there
[01:48] <smoser> https://cloud-images.ubuntu.com/server/precise/current/
[01:48] <smoser> we sign SHA1SUMS and MD5SUMS with some key on nectarine
[01:48]  * slangasek nods
[01:48] <smoser> but that public key (as far as I know) is not distributed anywhere.
[01:49] <slangasek> really? hmm
[01:49] <smoser> $ gpg --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --verify SHA256SUMS.gpg SHA256SUMS
[01:49] <smoser> gpg: Signature made Tue 24 Jan 2012 09:36:24 PM EST using RSA key ID 7DB87C81
[01:49] <smoser> gpg: Can't check signature: public key not found
[01:49] <smoser> the same command works for me with Release and Release.gpg (from archive.ubuntu.com)
[01:50] <slangasek> smoser: no, it is distributed via the public keyrings
[01:50] <smoser> so what am i doing wrong?
[01:50] <slangasek> smoser: e.g., gpg --keyserver pgp.mit.edu --recv-keys 7DB87C81
[01:51] <slangasek> it could probably do with some more public signatures beside my own, btw :)
[01:51] <slangasek> (from other people who have access to nectarine and can verify the authenticity of the key)
[01:52] <smoser> hm.. yes, i suppose it could
[01:53] <smoser> this obviosly exposes my grave gpg ignorance
[01:53] <smoser> but how would someone come up with that key ?
[01:54] <slangasek> smoser: your gpg output shows the key ID and reports that you don't have it locally; the next step if you want it is the gpg --recv-keys command to fetch it from the public keyservers
[01:55] <smoser> ah. duh.
[01:56] <slangasek> if you are intending to sign the pgp key yourself, please make sure to verify that the full pgp fingerprint of the key you download locally matches the fingerprint of the public key on nectarine :)
[04:52] <dhana013>  Hi guys. I want make custom distro. It's based on ubuntu derivative. but not depends on ubuntu,  How to compile source code from scratch , make deb packages, please guide me.
[04:56] <RAOF> dhana013: This seems unlikely to be on-topic for #ubuntu-devel.  dpkg-buildpackage is the standard way to go from source-package→binary package, though.
[05:01] <dhana013> RAOF: Any guide how to proceed, with my creating custom destro.
[05:17] <RAOF> dhana013: Um, don't?  I don't think there's a particularly good reason to.
[05:18] <dhana013> RAOF: New distro creation in am my project
[07:39] <dholbach> good morning
[08:09] <pitti> slangasek, cjwatson: has there been any discussion about kmod by any chance? i. e. "we want this for precise" or "we want to keep it out of precise"?
[08:09] <pitti> apw: ^
[08:09] <pitti> newer udev versions now need it, they use libkmod instead of calling modprobe a thousand times
[08:09] <pitti> which might also give a nice speedup
[08:10] <pitti> but of course it's still fairly new; Fedora and Arch linux use it, but I haven't tested it yet (it's in Debian experimental)
[08:10] <pitti> is that something I should have a look at, or do we want to stay at udev 175 and just backport some fixes?
[08:12] <pitti> we could at least sync it into universe, so that it's easier to test and play with
[08:20] <broder> i'm +1 for having it somewhere in the archive - i have some applications i'd like to use it for
[08:21] <pitti> ah, we can't sync it directly, it builds a transitional module-init-tools
[08:22] <pitti> I figure we do not want to do this right away, unless we decide to actually do replace m-i-t
[08:22] <pitti> and that requires some merging of ubuntu changes
[08:22] <pitti> so we could do a ~ubuntu1 upload without the transitional package into universe
[08:23] <pitti> (~ so that we retain the option to sync)
[08:59] <apw> pitti, yeah not heard anything but if thats the way upstream is rattling we should have it somewhere to play with
[09:00] <pitti> apw: apparently it's the m-i-t successor
[09:05] <apw> pitti, folling the libudev model i assume "do it yourself" functionality
[09:06] <pitti> apw: I don't understand, I'm afraid
[09:06] <apw> library to be directly involved in module loading, find out what is and isn't and load them so you don't need to fork all the time
[09:07] <pitti> apw: yes, udev went into that direction
[09:07] <pitti> instead of calling blkid, modprobe, and whatnot, it now uses their libraries
[09:08] <pitti> I'd like to at least get the libbklid change, but I could cherry-pick that even without kmod
[09:08] <pitti> if I look at http://people.canonical.com/~pitti/bootcharts/daniel-oneiric-20111027.png, the blkid and modprobe calls take no small percentage of the boot
[09:09] <pitti> path_id, iput_id, usb_id are now also builtin
[09:11] <apw> pitti, it would be nice to have this thing for testing and no mistake
[09:12] <pitti> apw: the debian package does some transitional changes: http://packages.qa.debian.org/k/kmod/news/20120110T221730Z.html
[09:13] <pitti> apw: so I think we need to apply some work to be able to install it for testing and then revert back to m-i-t
[09:14] <apw> pitti, yeah, why could this not have happened a month ago ...
[09:15] <pitti> apw: well, kmod existed back then, but it was still pretty young
[09:15] <pitti> apw: anyway, I don't think it's particularly urgent
[09:15] <apw> heh "cannot login to my machine as any user since kmod replaced module-init-tools" ... suspect there will be some fun :)
[09:15] <pitti> we can probably get away with reverting the kmod bits and update to 179, or cherry-pick other changes
[09:16] <pitti> I mainly wondered if there was any dicussion about that already which I wasn't aware of
[09:16] <pitti> if not, I think we should stay at m-i-t for precise
[09:16] <apw> pitti, no seems we missed out on the whole thing by missing plumbers
[09:28] <apw> pitti, do if this dicussion is correct kmod will have a kmod binary which is the  official interface which can also be symlinked to modprobe etc.  so it should be testable at least
[09:28] <pitti> yes, that's what I understood
[09:39] <apw> pitti, what is daniel, 16 blkids seem like a lot
[09:39] <pitti> apw: daniel is my Dell Mini 10v
[09:40] <pitti> i. e. my boot speed test machine
[09:40] <pitti> this was a pristine oneiric install in default partitioning mode
[09:40] <apw> pitti, and how many partitions does it have
[09:40] <pitti> apw: it's running over all ram/loop/whatnot devices, too
[09:40] <apw> oh gawd
[09:40] <pitti> apw: I think two: system and swap
[09:40] <pitti> apw: you just don't see those on faster boxes as they are quicker than bootchart's measuring interval
[09:40] <apw> no wonder you want to use it
[09:40] <pitti> which is what makes this Abacus so nice for boot speed testing :)
[09:41] <apw> yeah i wish my abacus hadn't broken, i must source another
[09:43] <pitti> it's not that easy to revert, but I'll see what I can do
[11:29] <Daviey> lynxman: around/
[11:29] <Daviey> ?
[13:45] <lynxman> Daviey: kinda, but not much, will be around in full force tomorrow
[13:46] <Daviey> lynxman: k
[13:52] <james_w> cjwatson, hi, were you planning a wadllib upload with your py3 changes?
[13:58] <cjwatson> james_w: I was waiting for somebody with permissions to do so (i.e. not me) to do an upstream release
[13:58] <cjwatson> james_w: barry has a work item to shepherd that all into the archive
[13:58] <cjwatson> maybe poke the lp people if they haven't already been poked?
[13:59] <james_w> cjwatson, ok, thanks
[14:05] <quadrispro> ScottK, waiting for a signal from you and I'll push audiofile to precise
[14:07]  * quadrispro reminds: "At my signal, unleash hell"
[14:25] <slangasek> pitti: I don't know that there's been discussion of kmod; I've assumed our answer is we don't want it due to the newness
[14:27] <pitti> slangasek: ok, thanks; that's all I wanted to know; so I'll check if the kmod bits can be reverted in udev and we upgrade to 179, or I'll try to cherrypick the interesting bits
[14:27] <pitti> the latter won't be any easier, so I'll try the former first
[14:28] <slangasek> are there good reasons to upgrade to 179, even?
[14:29] <pitti> slangasek: the biggest change is replacing the external blkid, path_id, input_id etc. calls (and also modprobe, with libkmod) with internal libraries
[14:29] <pitti> slangasek: if you look at a bootchart like http://people.canonical.com/~pitti/bootcharts/daniel-oneiric-20111027.png (mini 10), that'll should speed it up quite nicely
[14:29] <pitti> slangasek: and then the usual set of keymap quirks, but these are easily backported
[14:30] <pitti> there's also some bug fixes, but nothing major AFAIK
[14:39] <slangasek> pitti: aren't we doing ok right now with boot speed target?  not sure it makes sense to me to change udev just for this... also, has anyone run tests to show the speed improvement is actually significant?
[14:39] <pitti> slangasek: no, as we don't yet have an udev version with this
[14:39] <pitti> we can't build > 175 right now
[14:40] <pitti> slangasek: well, I wouldn't call it 'ok', but the speed regressions in natty/oneiric are certainly not udev's fault
[14:40] <pitti> (in the sense that it didn't get worse)
[14:40] <pitti> it's relatively low-hanging fruit
[14:42] <stokachu_> pitti, ping
[14:42] <pitti> stokachu_: hello
[14:42] <stokachu_> pitti, hey there :) was curious about LP#860765, was there any particular reason it was set to wont fix for natty?
[14:44] <pitti> stokachu_: it's not a high-priority bug, and natty has been out long enough for it to not matter any more
[14:44] <pitti> if someone wants to prepare an SRU, it'd be alright, but there is little to be gained
[14:55] <TREllis> slangasek: thanks for the cpp:any tip - works. Lintian doesn't like it, guess that's lintian bug tho
[14:58] <apw> pitti, would you be able to tickle the linux-ti-omap4 through for me
[14:58] <cjwatson> mvo: so I'm trying auto-upgrade-tester again, this time with apt-cacher-ng set up so that it doesn't spend eons re-downloading stuff
[14:59] <pitti> apw: ah, sure; already looked this morning, but the armel builds were still missing for both that and linux
[14:59] <cjwatson> mvo: however it fails on the apt-clone file from bug 917173 because apt-clone wasn't in lucid
[14:59] <cjwatson> mvo: do you know any way around this?
[14:59] <apw> pitti, thanks, i think linux is still lacking powerpc
[14:59] <pitti> apw: yep; omap4 done
[15:02] <apw> pitti, thanks a lot
[15:05] <mvo> cjwatson: jibel put it into a PPA afaik, jibel - if so, could you please tell colin what ppa that is?
[15:06] <slangasek> pitti: so the reason I'm pushing back a bit on udev 179 is that I don't think it's a slam dunk to take a new upstream version of udev; we spent about half a cycle chasing regressions in oneiric due to udev behavior changes, and still have one we haven't closed the gap on.  So I'm really not sure that fruit feels "low-hanging" to me
[15:06] <ScottK> Riddell: re python-qt4: That's the first time it's been built against Qt 4.8 on arm*, but it built before that with 4.7.4.  The function with the error isn't a new one, so I'm inclined to blame Qt 4.8.  sip: QPainterPathStroker::setDashPattern() unsupported function argument type - provide %MethodCode and a valid C++ signature - Thoughts?
[15:06] <cjwatson> mvo: how do I force auto-upgrade-tester to use that?
[15:07] <ScottK> Oops.  Wrong channel.
[15:07] <jibel> mvo, I didn't, sorry.
[15:09] <barry> ScottK: python-qt4 on arm is giving us headaches
[15:10] <ScottK> barry: Yeah.  Riddell and I are discussing on #kubuntu-devel.  Feel free to join.
[15:10] <mvo> jibel: oh, sorry then, I misremembered
[15:11] <mvo> cjwatson: so if there is a apt-clone in a PPA then you can do:
[15:11] <mvo> +AddRepo=local_testing.list
[15:11] <mvo> +AddRepoUpgradeImmediately=true
[15:11] <mvo> to [NonInteractive] (to e.g. profile/server-amd64/DistUpgrade.cfg)
[15:12] <mvo> and the file "local_testing.list" would contain something like deb http://ppa.launchpad.net/mvo/apt-precise/ubuntu oneiric main
[15:13] <mvo> cjwatson: there is even a branch for the backport https://code.launchpad.net/~mvo/apt-clone/lucid-backport but apparently I did not upload it into a ppa :/
[15:13] <cjwatson> do you think you could, if you already have that?
[15:14] <mvo> cjwatson: sure
[15:15] <cjwatson> mvo: do I need to do anything special if I'm testing e.g. DistUpgrade.cfg changes?
[15:17] <mvo> cjwatson: anything special when using a apt-clone file? I'm not sure, its pretty new (the integration) and jibel did those bits, IIRC its just a matter of pointing to the right apt-clone file and I guess a bit of hackery to ensure that the ppa with the apt-clone is actually in the sources.list
[15:18] <cjwatson> well, I mean inserting a different DistUpgrade.cfg file and seeing what would have happened to the upgrade if it had been done with that ...
[15:18] <cjwatson> (DistUpgrade.cfg doesn't seem to be in the apt-clone file anyway)
[15:22] <mvo> cjwatson: if you simply modify the one in the profile directory that should have the desired effect, e.g. if you want to test with a additional "KeepInstalledPkgs=" line you can just add it and it will "win" over the default value from the upgrader
[15:22] <mvo> https://launchpad.net/~mvo/+archive/apt-clone-lucid - but it neeeds to build first
[15:24] <cjwatson> oh, the profile directory, right
[15:26] <cjwatson> mvo: does it inherit from DistUpgrade.cfg.lucid on the fly or something?
[15:26] <cjwatson> sorry for asking so many questions, just finding it really hard to get going on this
[15:27] <mvo> cjwatson: it should inherit, yes (unless there is a bug somewhere)
[15:27] <mvo> cjwatson: no worries about the questions, I know its a tricky piece :/
[15:27] <cjwatson> OK
[15:28] <cjwatson> the last time I played with this I couldn't make it pick up code changes to DistUpgrade (not .cfg), and found that rather baffling
[15:28] <cjwatson> I expect I'll give that another go ...
[15:28] <mvo> cjwatson: ohhh
[15:28] <mvo> cjwatson: please set "UseUpgraderFromBzr=false" to "true" in [NonInteractive]
[15:29] <mvo> cjwatson: in AutoUpgradeTester/profile/defaults.cfg.d/defaults.cfg
[15:29] <mvo> cjwatson: or in your individual profile
[15:29] <cjwatson> ah!
[15:29] <mvo> cjwatson: otherwise it uses the version of the upgrader code from the archive
[15:29] <cjwatson> marvellous, thank you
[15:30] <mvo> yw
[15:58] <pitti> barry: dbus-python (1.0.0-1) UNRELEASED; urgency=low
[15:58] <pitti> o_O
[15:58] <barry> pitti: it's basically what we had in 0.84.0-2ubuntu3 anyway ;)
[15:59] <pitti> barry: I mean, was this uploaded prematurely?
[15:59] <barry> pitti: sync'd from experimental, but i think it's safe
[15:59] <pitti> oh, http://packages.qa.debian.org/d/dbus-python/news/20120124T214728Z.html has the same problem
[15:59] <pitti> barry: I mean "UNRELEASED" as target; it shoudl certainly be "experimental" or "unstable"
[16:00] <pitti> anyway, just looked odd
[16:01] <barry> pitti: yeah, it does, and probably should.  i'll drop a message to simon about it, but i debdiff'd the .debs and tested in a chroot.  all seemed okay, modulo http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657488
[16:01] <pitti> barry: ok, thanks
[16:01] <barry> pitti: thanks
[16:20] <ericbee> can anyone point me to some documentation about creating applets for the systray?
[16:29] <cjwatson> The following packages have unmet dependencies.
[16:29] <cjwatson>   apt-clone: Depends: python-argparse but it is not installable
[16:29] <cjwatson>              Recommends: dpkg-repack but it is not installable
[16:29] <cjwatson> mvo: ^-
[16:29] <cjwatson> (from your PPA)
[16:30] <SpamapS> Could someone offer some guidance on how this needs to be fixed:
[16:30] <SpamapS> https://launchpadlibrarian.net/90939944/buildlog_ubuntu-precise-amd64.gearmand_0.27-1_FAILEDTOBUILD.txt.gz
[16:30] <SpamapS> Looks like an ABI bump is needed upstream..
[16:31] <cjwatson> SpamapS: using the syntax for filtered C++ symbols files rather than raw ones would be a good start
[16:31] <cjwatson> SpamapS: but C++ symbols are difficult; there's a thread on debian-devel about them at the moment ...
[16:31] <cjwatson> you might just find those symbols are inlined on some architectures or something
[16:31] <mvo> cjwatson: meh, this sounds like universe is not enabled (which is the default). you will have to tweak it and add "Components=main,restricted,universe" to the AutoupgradeTester/profile/defaults.cfg.d/defaults.cfg or the individual profile
[16:32] <mvo> cjwatson: the easier option is to start the image manually (its in /var/cache/auto-upgrade-tester/test-image.$name.lucid and add it manually there
[16:32] <mvo> cjwatson: probably a quicker solution
[16:36] <cjwatson> mvo: oh right
[16:39]  * mvo is away for a bit
[16:40] <mpt> mvo, hi, what do I need to know before doing this? "[mpt] Invite people to port release-upgrader to aptdaemon"
[16:40] <mpt> d'oh
[16:52] <manish> where is federico?
[16:52] <manish> sorry, wrong channel :)
[17:15] <kenvandine> anyone around that can re-score a ppa build?  indicator-appmenu in the unity-team/hud ppa has a pretty critical fix and it is estimating 20 hours
[17:15] <kenvandine> infinity or stgraber ^^
[17:16] <stgraber> kenvandine: url?
[17:17] <infinity> kenvandine: Done
[17:18] <kenvandine> thanks!
[17:42] <bryceh> @pilot in
[18:15] <slangasek> jibel: hi, should I see the effects of your job rearranging on https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/ ?  I still see all red at the top level
[18:17] <smoser> can i get someone to approve dbus-python's new 'python-dbus-dev' at https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=
[18:17] <slangasek> jibel: oh n/m, you said "published to the public instance on the next run" :)
[18:17] <jibel> slangasek, the jobs are still running/queued
[18:17] <slangasek> jibel: ack - sorry for reading with my manager glasses on
[18:17] <smoser> it is depends of python-dbus with is depended on by a lot of things and is currently not installable
[18:17] <jibel> slangasek, np
[18:18] <slangasek> smoser: looking
[18:18] <slangasek> smoser: python-dbus depends on python-dbus-dev, though?  That's surely broken
[18:18] <smoser> changelog says
[18:19] <smoser> make python-dbus depend on python-dbus-dev for now, to preserve istorical functionality (but packages which use it, like PyQt, should  switch to depending on it explicitly)
[18:19] <smoser> so it was by design
[18:19] <slangasek> ah, so it's a package splitting
[18:19] <slangasek> ok
[18:21] <slangasek> jibel: oh, also - did you catch my note that the prompting for service restart on glibc upgrade on server installs is by design and shouldn't be counted as a test failure?
[18:21] <slangasek> smoser: accepted
[18:22] <smoser> gracias
[18:22] <jibel> slangasek, yes, I'll add the prompt to the whitelist.
[18:29] <smoser> slangasek, how fast does that take affect? every 1/2 hour?
[18:32] <cjwatson> smoser: should start publishing in one minute and finish in about half an hour from now
[18:32] <smoser> thank you cjwatson
[18:39] <bryceh> @pilot in
[19:16] <arges> bryce, hello patch pilot. have a patch that needs reviewing. this is my first one so i probably have it all wrong
[19:17] <arges> bryce, tried to follow the directions in the wiki. its a patch to fix https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/885502.
[19:21] <slangasek> smoser: every half hour, yes
[19:22] <smoser> its in now
[19:22] <slangasek> jibel: oh, is that whitelist somewhere I could see it?  (Mostly out of curiosity)
[19:22] <smoser> my build is going
[19:22] <slangasek> smoser: yay
[19:32] <stgraber> slangasek: trying to refresh ubuntu-meta, I'm getting "Skipping package resolvconf (package not in debootstrap)". Do you know what needs to happen for germinate to be happy and add it to -minimal?
[19:36] <stgraber> slangasek: <cjwatson> It probably means that the package isn't Priority: required/important yet.  An archive admin who isn't in the pub can fix that based on priority-mismatches output.
[19:36] <stgraber> slangasek: priority-mismatches says it should be moved from optional to important
[20:54] <hallyn> jdstrand: this is getting ridiculous.  I ran 'make check' in netcf in a precise chroot on hardy.  Pass.
[21:06] <Daviey> doko: Hey, had a chance to look at bug 914160 ?
[21:07] <infinity> hallyn: So, it's not the kernel version either? :/
[21:07] <hallyn> infinity: (GAH!) so it seems...
[21:07] <infinity> hallyn: Did you try it in that configuration, but with sbuild?
[21:08] <hallyn> infinity: so i'm at a loss
[21:08] <infinity> Not that I'd expect sbuild's FD buggery to behave differently on a hardy kernel, but...
[21:08] <hallyn> no, i don't know how to do that
[21:08] <hallyn> debootstrap wouldn't do precise.  that's hwy i scp'd over a precise chroot
[21:08] <infinity> debootstrap is an arch:all package with no deps, you can install the precise version on hardy.
[21:09] <hallyn> install precise version of debootstrap?  just 'dpkg -i' it?
[21:09] <infinity> https://launchpad.net/ubuntu/+source/debootstrap/1.0.38/+build/2945367/+files/debootstrap_1.0.38_all.deb
[21:09] <infinity> Yeah.
[21:09] <hallyn> all right lemme try, thanks
[21:21] <hallyn> lack of aufs and ext4 is really annoying
[21:28] <hallyn> infinity: build... successful
[21:29] <hallyn> and with that, i'm pulling 'make check' from the build
[21:35] <infinity> hallyn: Wasn't it only one test that was failing?  Surely you can disable that one.
[21:35] <infinity> hallyn: test-debian, or whatever it was.
[21:35] <hallyn> infinity: all the other tests are just gnulib tests.  and one of those (test-float) actually fails on powerpc
[21:35] <hallyn> that is, there is only one test supplied by netcf itself
[21:35] <infinity> Oh.
[21:35] <infinity> Special.
[21:40] <hallyn> infinity: is there any way to get a shell in an *exact* replica of buildd env?
[21:40] <htorque> hi all! on ask ubuntu someone asked when btrfs-tools will see an update. is there anything else than bug 894456 i can tell that user?
[21:42] <micahg> htorque: needs a merge from Debian
[21:43] <infinity> hallyn: Well, you can download the buildd chroots from launchpad.
[21:43] <hallyn> oh?
[21:44] <htorque> micahg: is that planned for precise (or is it a case of "someone needs to do it")?
[21:44] <infinity> hallyn: https://api.launchpad.net/1.0/ubuntu/precise/armhf/ for example.
[21:44] <infinity> hallyn: (replace armhf with the arch you want)
[21:44] <hallyn> infinity: thanks.
[21:44] <infinity> hallyn: That said, I tried reproducing it in a buildd chroot, and got nowhere.
[21:45] <micahg> htorque: someone needs to do it, cjwatson touched it last, I don't know if he's interested in doing it though
[21:45] <htorque> micahg: ok, thanks for the info! :-)
[21:58] <slangasek> jcastro: who has access to delete pages from help.ubuntu.com?
[22:03] <stgraber> slangasek: can you override the priority of resolvconf to important? that needs to happen before I can upload a new ubuntu-meta
[22:11] <jibel> slangasek, that will be quick, the list empty.
[22:11] <jibel> the code of the debconf test is there http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/AutoUpgradeTester/post_upgrade_tests/debconf_test.py
[22:16] <hallyn> infinity: you say the netcf 'make check' passed when you ran it in the buildd chroot right?
[22:16] <slangasek> jibel: heh, ok :)
[22:17] <slangasek> stgraber: yes, looking
[22:18] <slangasek> stgraber: done
[22:18] <stgraber> slangasek: thanks
[22:20] <micahg> I'm guessing pitti isn't around anymore at this hour
[23:23] <micahg> stgraber: I think you forgot to set DEBEMAIL :)
[23:26] <stgraber> micahg: yeah, I just noticed in -changes ;)
[23:27] <stgraber> micahg: should have checked the output of that script a bit more carefully
[23:29] <stgraber> micahg: will make a note to fix the changelog entry next time I upload it... (and fixed that chroot to have a decent environment)
[23:35] <Laney> ah I heard about this 'root' fellow somewhere
[23:37] <ajmitch> pretty dangerous person, I heard
[23:37] <stgraber> ;)
[23:45] <pp7> root is a badass!


[02:25] <smoser> ugh.
[02:25] <smoser> hey, my core dev mempership expired today
[02:25] <smoser> can i get it fixed ?
[04:52] <pitti> doko: kde4pimlibs 5 h? it ran for 2:30 h, which is fairly normal
[04:53] <pitti> oh, you mean it was waiting for 5 h?
[05:09] <pitti> doko: wrt. your question of "someone else"> the cloud stuff can be handled by infinity, slangasek, stgraber, and Laney (I gave training to Laney); the most common admin tasks are documented on prod-ues-proposed-migration
[05:10] <pitti> doko: err, documented on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration
[05:10] <pitti> doko: armhf and ppc64 are still kind of "step kinds" from the old infra, waiting  to move to scaling stack; happy to show you (or some one else) about admin
[05:27] <pitti> dpm: hey David! Can we please have http://people.canonical.com/~dpm/data/ubuntu-l10n/ for RTM 15.04?
[05:27] <dpm> morning pitti
[05:27]  * dpm files RT
[05:28] <pitti> dpm: ah, that's something for IS? thanks
[05:28] <dpm> yeah
[05:28] <pitti> dpm: you can drop rtm 14.09 btw, it's obsolete
[05:29] <pitti> dpm: (and utopic too)
[05:29] <dpm> ack
[06:44] <dholbach> good morning
[07:31] <didrocks> @pilot in
[07:58]  * dholbach hugs didrocks
[07:58]  * didrocks hugs dholbach back
[08:06] <Laney> pitti: I don't think I would have known how to debug a stuck "in progress", if that's what it was
[08:07] <pitti> Laney: you could have looked at the queue length
[08:07] <Laney> yeah
[08:07] <pitti> Laney: we have 8 armhf runners, any number of requests that's larger than that will have to wait
[08:07] <Laney> so I could have said that it looks like it might be waiting
[08:07] <pitti> Laney: http://autopkgtest.ubuntu.com/packages/k/kde4pimlibs/wily/armhf/ looks like it took its usual time (2:30)
[08:08] <Laney> would it be hard to have a separate queued state?
[08:08] <pitti> it started at 20:56:30 UTC, not sure when britney requested it (could dig out of the logs)
[08:09] <pitti> Laney: not easy right now; we'd need a way to export what's currently running from all the workers
[08:10] <pitti> Laney: rabbitmq should know this (i. e. which are being processed and which are waiting), but we don't export the queue status right now
[08:10] <pitti> the rabbit management plugin has quite some nice stuff, this sounds like a good place to start
[08:11] <pitti> Laney: or the other way round, you can get access to the armhf runners, and  then just check what's currently running; want to?
[08:28] <pitti> infinity: FYI, I gave you access to the cyclops and wolfe boxes, in case you want to peek at them (or reboot, restart worker, or what not); I added some documentation to https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration
[08:32] <infinity> pitti: Mmkay.  That's temporarily helpful, but I'm hoping we can get more to a self-service model, like lp-buildd.
[08:32] <pitti> infinity: yes, absolutely; this is for administration, not for developers
[08:32] <infinity> (Which, granted, it took us 8 years to build a user-accessible "cancel" function but...)
[08:32] <pitti> (i. e. when the boxes lock up or what not)
[08:32] <infinity> pitti: Sure, point being that once this is all in scalingstack, an "admin" and a "user" should look almost identical, minus a tiny bit of glue.
[08:32] <pitti> infinity: it's still the plan to export the queues and show them in debci
[08:33] <pitti> infinity: yes, once armhf/ppc64el work in scalingstack all these external workers will just disappear
[08:33] <pitti> until then, we have to make-do
[08:33]  * infinity nods.
[08:33] <infinity> pitti: So, for the scalingstack arches, do we have a clean way to cancel a job?
[08:34] <infinity> pitti: May as well work on the utopia on x86, and be happy we get it all for free when the other arches catch up.
[08:34] <pitti> infinity: clean, yes (kill the adt-run process); "easily accessible", no; and I'm not even sure we should make this
[08:34] <infinity> pitti: Why not?
[08:35] <pitti> I mean, if you kill adt-run, it'll just be re-run immediately
[08:35] <infinity> pitti: It's just a build job like any other.
[08:35] <infinity> pitti: Killing should be from the master/queue, not the slave. ;)
[08:35] <pitti> infinity: what's your use case? i.   Sometimes you don't want it to run.  Sometimes it's hung.  Sometimes you're freeing up resources.  Sometimes you know it's going to fail and why waste 8h, etc, etc.
[08:37] <pitti> infinity: if it's hung, the kill will work right now (but it'll be immediately re-picked up by some worker, and re-run)
[08:37] <infinity> pitti: master is your queue.  britney is just a fire-and-forget job creation client.
[08:37] <pitti> ah
[08:37] <pitti> right, removing it from the queue and killing the running job would work
[08:37] <infinity> pitti: In the LP sense, britney would be like creating package build records on upload.    Easily murdered at will.  Not with killing a process, probably, but just by hard resetting VMs.
[08:38] <infinity> (Though having the kill fallback is nice for non-VM runners, as we also do in lp-buildd)
[08:39] <infinity> Or, rather, lp-buildd tries a "clean" kill, and if that times out *and* the builder is a VM, buildd-manager says "ah, screw it", and resets hard.
[08:40] <infinity> But we also reset VMs between all builds for security/sanity reasons too.  Not sure if you're doing that yet in scalingstack autopackagtest, but you probably should be.
[08:40] <infinity> Once you're always resetting VMs anyway, it starts looking like the hammer for every nail, cause it's simple. :P
[08:40] <infinity> pitti: Anyhow, all of this also needs a sane view of the queue in general, before queue manipulation is a thing.
[08:41] <infinity> pitti: So, a, then b.
[08:41] <infinity> Oh, and A, section 2, which is that we need a view into in-progress jobs, or "is it hung?" is a question no one can answer without a shell.
[08:41] <pitti> infinity: every test always gets a brand new VM
[08:41] <pitti> infinity: i. e. with nova boot, and nova delete at the end
[08:42] <infinity> pitti: Excellent, good.  I expected that, but wasn't sure.
[08:42] <pitti> tests have full root, and can break the testbed in unknown and interesting ways; there's nothign to salvage
[08:42] <pitti> infinity: right, that's part of the "show queue in debci" thingy
[08:42] <pitti> to see which are running, and which are queued
[08:42] <infinity> pitti: Kay, so queue+logtail, ideally.
[08:43] <infinity> pitti: queue is interesting info, but without a logtail, it's still a guessing game.
[08:43] <infinity> "Job was started 3h ago, and...?"
[08:44] <infinity> (FWIW, this is the thing I hate the absolute most about buildd.debian.org after the last decade of Soyuz usage, that tail is way more useful than we thought it was when implementing it as a silly, shiny feature)
[08:44] <pitti> undoubtedly :) (unfortunately also rather involved to implement)
[08:52] <infinity> pitti: Do the slaves have a listener of any sort, or do you do all your state polling via ssh/scp?
[08:53] <pitti> infinity: no ssh involved, it's just AMQP for the requests, and the slaves put the results directly into swift
[08:53] <pitti> loose coupling
[08:54] <pitti> infinity: i. e. they listen to AMQP queues
[08:54] <infinity> pitti: Ahh, kay, so the slave is returning bits to swift?
[08:54] <pitti> infinity: we can implement tailing via AMQP (just send out the log tail every 30 s to a broadcast queue or so)
[08:54] <infinity> pitti: So, one could just jam a logtail into swift as well.
[08:54] <pitti> nah, not into swift
[08:55] <pitti> seems easiest to use a broadcasting AMQP queue for that
[08:55] <pitti> then we don't need any new auth/firewall holes/host name hardcoding anywhere
[08:55] <infinity> Fair enough, I don't speak AMQP.
[08:56] <pitti> infinity: it's more or less just a queue which you can feed requests into, and someone else picks out a request (with lots of routing options, but an unbreakable FIFO is the simplest use case)
[08:57] <pitti> i. e. what we don't want is britney to do "ssh armhfworker1.canonical.com", as that is brittle and not scalable in so many ways
[08:57] <infinity> pitti: Right.  But it handles large messages fine, then?
[08:57] <pitti> so britney puts a test request for "linux" into some "wily-amd64" queue, and whichever worker listens to that queue can process it
[08:58] <pitti> infinity: FSVO large -- the messages are mostly bound by memory; so they shouldn't exceed 50 MB or so
[08:58] <pitti> but we are speaking about a  log tail of maybe 1 kB or so
[08:58] <infinity> pitti: Oh, sure, a logtail should never be more than a few dozen kB, or you're doing it wrong.
[08:58] <infinity> (or less, indeed)
[08:59] <pitti> infinity: so an idea is that every release-arch queue could have an accompanying release-arch-logtail queue which works in teh other direction; i. e. the workers put the log tail into these every n seconds
[08:59] <pitti> and whoever bothers to listen can show them
[09:00] <pitti> this queue would be configured to be in this kind of "lossy" mode, as opposed to the request queues which never lose anything
[09:05] <pitti> infinity: heh, seems http://notes.variogr.am/post/143623387/broadcasting-your-logs-with-rabbitmq-and-python does pretty much that
[09:08] <pitti> infinity: so maybe implementing this should even be A1 -- once we have a page with all logtails of all currently running tests, then this implies knowing which tests are running; and everything on excuses.html which is "in progress" but not running is then queued
[09:19] <Riddell> pitti: KDE mostly cleared from excuses, rocs is failing on ppc64el with an unknown error, worth trying again? http://autopkgtest.ubuntu.com/packages/r/rocs/wily/ppc64el/
[09:20] <pitti> error writing to /tmp/ccPiwlDE.s: Cannot allocate memory
[09:20] <pitti> Riddell: yes, worth retrying; done
[09:20]  * pitti looks at bluez-qt
[09:20] <pitti> Temporary failure resolving 'ports.ubuntu.com' - sigh, retrying
[09:34] <cjwatson> smoser: ~developer-membership-board should be able to fix that up quickly.  did you miss the expiration warning mails?
[09:38] <infinity> cjwatson: It got sorted.  And yes, he missed all the emails.
[09:39] <sitter> pitti: can we somehow dump arbitrary files into the artifacts tarball? namely upon ACC failure it would be handy to have the ACC headers and so forth artifacted
[09:39] <cjwatson> smoser: Would it have helped if those mails were more filterable?  Since I have a branch in progress for that ...
[09:40] <pitti> sitter: yes, absolutely; see https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html , your test can put anything into the $ADT_ARTIFACTS dir, and it'll appear in the "artifacts.tar.gz" from autopkgtest.u.c.
[09:40] <sitter> groovy thanks
[09:45] <pitti> Riddell: ack, rocs happy again
[09:46] <Riddell> awooga
[11:29] <mapreri> dholbach: thanks :)
[11:38] <didrocks> @pilot out
[11:56] <diwic> doko, so, I *think* trust-store should be in main now, because it says so in launchpad, so I retried the pulseaudio build, but it didn't seem to help
[11:56] <cjwatson> You're reading the wrong bit of the LP UI.
[11:57] <cjwatson> "Component:" on https://launchpad.net/ubuntu/+source/trust-store just means the package defaults, as indicated by the small print there (sorry ...).  The actual published location is per-series below.
[11:57] <doko> didrocks, what cjwatson said, still in universe
[11:57] <cjwatson> Also pulseaudio will retry automatically once trust-store is actually in main.
[11:57] <diwic> doko, cjwatson, ok, thanks
[11:58] <doko> but I find this ui confusing too
[11:59] <didrocks> phew, for a sec, I didn't get the context ;)
[11:59] <cjwatson> It's tempting to just delete the Component field there.
[11:59] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/521722 ends up suggesting that too
[12:04] <cjwatson> diwic: would it have been less confusing if the Component:* field there were simply absent?  there's then the per-series bit below that says "release (universe)" etc.
[12:04] <infinity> cjwatson: I'm inclined to agree that the .dsc component is completely useless and should just not be shown.
[12:05] <infinity> cjwatson: The other option is "show component of the proposed>updates>security>release pocket in the devel series", but that's really not useful.  About as not useful as the package list from the current stable. ;)
[12:06] <cjwatson> Also misleading in a different way, because we don't know what you care about (latest, or LTS, or ...)
[12:07] <infinity> Basically, the whole top half of that page is useless.
[12:07] <cjwatson> It makes a slight difference whether it's contrib or non-free for Debian stuff imported into multiverse, but really not a lot and not +index-worthy.
[12:07] <infinity> cjwatson: I'd argue that what most people looking at that page care about is the package list from the devel series, but I'd be just as happy with not showing it there at all, since it's not clear which series it's from.
[12:07] <cjwatson> Yeah, it needs a total rework, but it seems worth dealing with the bits that are actually bleeding (.dsc component).
[12:08] <cjwatson> Since that's a five-line change.
[12:08] <infinity> cjwatson: anyhow, yes, agreed.  Package list is a bigger debate (perhaps), I think consensus that .dsc component is useless and confusing is pretty much unanimous.
[12:08] <cjwatson> OK, I'll nuke it
[12:08] <cjwatson> But first, shopping
[12:09] <diwic> cjwatson, thanks for asking. I'm not familiar with the internals of main vs universe and how things are promoted/demoted, but I suppose if not all the binary packages are in the same as the source package, then yes, it's a bit confusing
[12:09] <infinity> cjwatson: Curiously, somtimes it's correct...
[12:09] <infinity> cjwatson: I wonder if that's just historical data versus new.
[12:10] <cjwatson> diwic: Well, that and the fact that the source isn't in main either; the "Component:" at the top is extracted from the source package and has nothing to do with actual publication other than setting defaults
[12:11] <cjwatson> Which is utterly mysterious to most people
[12:11] <infinity> cjwatson: Could it be that historical data was ginaed from Ubuntu and older packages get it "right" by accident or something?
[12:11] <cjwatson> infinity: The package list?
[12:11] <infinity> cjwatson: (see, eg: poppassd, which is 'main' per .dsc, but 'universe' on the offending page)
[12:11] <infinity> cjwatson: No, the component.
[12:11] <infinity> cjwatson: So, it's not even consistently wrong. :P
[12:16] <smoser> cjwatson, i wish i had a good excuse. but only excuse is "so much mail stuff gets lost". maybe it could have pinged me on irc.
[12:17] <infinity> smoser: I'd say rejecting your uploads is a fair last resort to the mail going missing.
[12:17] <cjwatson> infinity: Probably something to do with one being a direct upload and the other being copied from SPRs created by gina, indeed, but meh, too twisty for me to really want to totally track down.
[12:18] <cjwatson> infinity: Oh, in fact, I expect it's because trust-store's initial upload was to a PPA.
[12:18] <cjwatson> infinity: Which only has main.
[12:19] <infinity> cjwatson: Ahh, could be.
[12:19] <smoser> infinity, it definitely got my attention :)
[12:19] <infinity> cjwatson: All very confusing anyway.  Purge with fire.
[12:19] <cjwatson> Yeah.
[12:21] <cjwatson> infinity: Though you're right that it's weirdly inconsistent - compare poppassd and makepasswd
[12:22] <infinity> cjwatson: But makepasswd has been synced recently, the last poppassd was lucid, the consistency is probably a historical thing.
[12:22] <cjwatson> I guess that could just be because something in gina has changed since 2010.
[12:22] <cjwatson> Right.
[12:22] <infinity> cjwatson: Also, kinda not caring anymore.
[12:22] <cjwatson> :-)
[12:23] <infinity> cjwatson: Anything that deletes some code and cleans up a bad UI can't possibly be wrong.
[13:41] <rbasak> Hash Sum Aaargh!
[13:43]  * pitti tosses an apt 1.1 to rbasak and pats him
[13:49] <barry> pitti: ubuntu-drivers-common \o/ - thanks :)
[13:49] <pitti> barry: yw :)
[15:04] <smoser> anyone generally oauth knowledgable that could help me ...
[15:04] <smoser> currently i  have some code that is logging a oauth request and its headers.
[15:06] <smoser> like : http://paste.ubuntu.com/12263581/
[15:06] <smoser> i'm wondering is there anything there that i shoudl redact from the log ?  is is token or consumer key needed to be masked out. Its easy enough to do it, but if they're not sensitive (note, there is no token_key or token_secret) then they're quite likely useful for debugging
[15:29] <ricotz> stgraber, hi, pastebinit could you use a little tweak to deal with paste.debian.net forcing https
[15:31] <octoquad> didrocks & Laney thanks for merging my MP for USC :)
[15:32] <didrocks> thanks you octoquad for your MP! :)
[15:35] <octoquad> I'm curious, what's the plan for USC and Snappy?
[15:36] <didrocks> ogra_: ^
[15:36] <stgraber> ricotz: patches are welcome :) not that I've touched pastebinit in over a year, I should probably do another release soon-ish :)
[15:41] <doko> mitya57, will you still merge python-sphinx?
[15:44] <ogra_> didrocks, no idea, i'm not a software center person :)
[15:44] <didrocks> ogra_: you are the snappy one though :p
[15:44] <ogra_> i would guwss the snappy store will replace it at some point
[15:45] <ogra_> well, the "snappy scope" actually
[15:45] <ogra_> which isnt much different from the click scope on the phone afaik
[15:48] <ogra_> didrocks, i think kyrofa works on that iirc
[15:49] <didrocks> nice :)
[15:49] <octoquad> cool, thanks ogra_
[15:50] <ricotz> stgraber, https://paste.debian.net/plain/310262 ;)
[15:51] <infinity> in 103
[15:51] <kyrofa> didrocks, ogra_ is right. Demo is here: https://www.youtube.com/watch?v=17nVOHrCh7Y&feature=youtu.be
[15:52] <didrocks> I guess that's for octoquad ^
[15:52] <octoquad> watching already :P
[15:53] <Laney> kyrofa: you have a good narrating voice
[15:53] <octoquad> nice, remember to add dark theme support hey :P
[15:53]  * Laney wants to buy whatever it is you are selling
[15:53] <kyrofa> Laney, haha, thanks!
[15:53] <Laney> a box of air? i'll have ten!
[15:57] <ogra_> Laney, and if you take them all at once you get a discount !!
[15:58] <Laney> $100 each, 10 for the low low price of $1050
[15:59] <ogra_> $1049 with friendship bonus, others pay more !
[15:59] <didrocks> (without shipping)
[15:59] <stgraber> ricotz: pushed to trunk
[16:28] <dobey> hmm
[16:28] <dobey> noooooo
[16:28] <dobey> sigh
[16:32] <doko> barry, did you file bug reports for the python3.5 ftbfs?
[16:43] <dobey> didrocks: well that was rude :(
[16:43] <didrocks> dobey: hum? what about?
[16:44] <dobey> didrocks: pushing stuff directly to lp:software-center like that
[16:44] <didrocks> dobey: seems Tarmac was down for 8 hours, nobody is reviewing USC merge for ages, Laney told we were ok to push directly after build
[16:44] <dobey> there is no tarmac for software-center
[16:44] <dobey> it is not ok to push directly to trunk
[16:44] <didrocks> is the procedure for it documented?
[16:44] <didrocks> I may have missed it, but tried to look
[16:45] <dobey> i have been meaning to switch it over to the CI train, yes; but i haven't gotten around to it yet
[16:45] <dobey> but anyway, those two branches shouldn't have been merged anyway, since they don't meet the requirement of contributor agreement
[16:45] <didrocks> so, you are maintaining USC? We keep get us (desktop team) pinged about it because nobody is taking care of MP
[16:46] <dobey> well, you can ship distro patches until they get merged if you want
[16:46] <didrocks> dobey: so if you are taking again some time for looking at this project, please unmerge them (also, I saw that most of people just distro-patch it and it hadn't a release for almost 2 years) and get it in line
[16:46] <dobey> as i've told to do in the past
[16:46] <didrocks> dobey: yeah, let's do that
[16:47] <didrocks> octoquad: reopening MP ^
[16:47] <octoquad> didrocks, np
[16:47] <didrocks> dobey: let me rewind trunk
[16:47] <dobey> if desktop team wants to take over ownership of it, i'm fine with that too. i really don't want to deal with it. but patience is appreciated
[16:47] <didrocks> dobey: no, it's just that it's been weeks/months that we are pinged about USC issues
[16:48] <didrocks> but we do prefer you, as you have more expertise on it looking at things if possible :)
[16:48] <dobey> well we don't ship it on the phone, snappy, or server
[16:48] <didrocks> we do have a desktop product we ship every 6 months though
[16:48] <dobey> i wouldn't say i have more expertise about it.
[16:49] <dobey> it got dumped in my lap a few years ago
[16:49] <didrocks> you were not agile enough to avoid it it seems :p
[16:49] <dobey> yes, and unfortunately the ubuntu.iso includes software-center
[16:49] <dobey> well it made sense at the time
[16:49] <didrocks> dobey: trunk rewinded, reopening MP in a sec
[16:50] <dobey> since we were the "ubuntu one" team at the time, and software-center fit fairly well under that
[16:50] <dobey> software-center doesn't really fit well under the scope of "unity api" though
[16:51] <dobey> anyway
[16:51] <didrocks> dobey: indeed, so all done now, if you have some time to give a look, that would be great!
[16:51] <didrocks> dobey: let's keep the distro patches for now
[16:51] <octoquad> doby didrocks what will happen to the mp now? will it still make it for ui freeze?
[16:51] <didrocks> octoquad: it's still in wily
[16:51] <didrocks> octoquad: just not in software-center trunk
[16:52] <didrocks> (in distro as distro-patches)
[16:52] <octoquad> I see. Thanks for clearing that up.
[16:52] <didrocks> yw!
[16:52] <dobey> octoquad: you need to sign the contributor agreement, before your changes can land
[16:52] <octoquad> where do I find that dobey?
[16:53] <dobey> octoquad: http://www.ubuntu.com/legal/contributors
[16:53] <octoquad> but, does it really matter? The future of USC might come to an end soon right?
[16:53] <octoquad> ta dobey
[16:54] <dobey> it's been coming to an end soon for three years, so i wouldn't put too much stock in "soon" right now :)
[16:54] <octoquad> dobey, hehe
[16:55] <dobey> the sooner it goes away, the happier i'll be though (as will anyone who wants to get rid of python2 from the ISO)
[16:55] <jcastro> dobey: if no one is maintaining that stuff then your team could at least let people know
[16:55] <jcastro> this whole black-hole business won't help anyone
[16:55] <octoquad> didrocks, will that fix also be available in xx?
[16:55] <dobey> jcastro: it's in "maintenance" mode
[16:56] <jcastro> it's like you guys keep dropping projects but not telling anyone, how are people supposed to contribute?
[16:56] <dobey> we aren't dropping projects
[16:56] <didrocks> octoquad: the fix will stay until someone remove the distro-patch
[16:56] <didrocks> octoquad: so the default is "yes" :)
[16:56] <octoquad> didrocks, ok. What's a distro-patch, I'm relatively new to contributing
[16:56] <jcastro> is there a different definition for not responding to pings or MPs from people other than dropping?
[16:57] <dobey> we should just call 16.04 "dos equis"
[16:57] <jcastro> "maintenance" isn't the word most people would use
[16:57] <didrocks> octoquad: a patch applied to the package in a distro that isn't in upstream trunk
[16:57] <didrocks> octoquad: so basically "only on ubuntu" in this case
[16:57] <dobey> jcastro: don't add more confusion to the issue, please. i have responded to pings
[16:57] <octoquad> didrocks, aaah, thanks :)
[16:57] <didrocks> octoquad: yw ;)
[16:58] <octoquad> bbl
[17:00] <dobey> didrocks: anyway, if your team is getting too many pings about software-center, and think it needs more attention/priority for a bit, then get your PM to bring it up in the unity api stakeholders meeting
[17:00] <didrocks> dobey: or get your team doing their patch pilot shift for people with upload rights and they will see them?
[17:01] <dobey> didrocks: our team doesn't have a patch pilot shift
[17:01] <mitya57> doko, not in this cycle
[17:01] <didrocks> I thought everyone with upload rights had some
[17:01] <doko> mitya57, just because we have some dep-waits
[17:02] <dobey> and i'm the only one with any upload rights, and it's only like 2 or 3 packages i have upload rights for :-/
[17:02] <mitya57> doko, I will merge it in the beginning of wily+1, but I can look at the dep-waits now
[17:02] <didrocks> dobey: so maybe look at the shifts on the list for those 2-3 packages? That would make dholbach even happier :p
[17:02] <didrocks> and will fix that issue
[17:02] <doko> mitya57, ta
[17:03] <dobey> didrocks: CI train has basically eliminated any need for people to get upload rights too
[17:03] <didrocks> yeah
[17:03] <mitya57> doko, though this is strange as sphinx 1.3 arrived in main just a couple of days before the import freeze
[17:03] <mitya57> You probably need to blame those who synced those packages
[17:07] <hallyn> pitti: stgraber: want to get http://paste.ubuntu.com/12264542/ into systemd in the archive.  i could just push, but i assume pitti  is in the middle of some changes so don't want to cause a mess :)
[17:10] <doko> mitya57, can't see who synced it: https://launchpad.net/ubuntu/+source/routes and no email to changes email. https://launchpad.net/ubuntu/+source/routes/+publishinghistory
[17:11] <doko> probably I should just remove it, unstable already has a newer version
[17:11] <mitya57> oh yes, routes was uploaded by p1otr on the same day I uploaded 1.3 to unstable
[17:12] <mitya57> Can we just remove 2.2-1 from -proposed and let it be autosynced again when wily+1 opens?
[17:12] <doko> I'll do it
[17:13] <mitya57> Thx
[17:16] <tdaitx> tjaalton, hi! I have been taking a look at a few FTBFS for armhf... a few of those are caused by GLsizeiptr type being khronos_ssize_t on GLES* and a ptrdiff_t in glext (and GLEW), on armhf ptrdiff_t  is a signed int while khronos_ssize_t is a signed long int - a similar problem happens to GLintptr, do you know of any reason for that mismatch? I was wondering if there anything preventing khronos_ssize_t to be set to ptrdiff_t
[17:16] <tdaitx> (I build mesa fine that way, have yet to build reverse deps)
[17:18] <tdaitx> tjaalton, since you are a mesa maintainer, you might have come across a discussion on this (I haven't been able to find anything so far)
[17:57] <tjaalton> tdaitx: huh, no idea.. first time i hear about it
[17:58] <tdaitx> heh, ok, then it might be fixable =)
[19:28] <to10fcm> hey guys, i am getting this error running different binaries on my system: "relocation error: /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference"
[19:28] <to10fcm> any ideas on how to fix? i saw a reference to it and GCC5 in a log for this chan (http://irclogs.ubuntu.com/2015/07/17/%23ubuntu-devel.txt) so I thought I'd come here to ask first
[19:40] <to10fcm> brb restating
[19:43] <smoser> infinity, could you look at https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1491111
[19:44] <smoser> it seems like something you've helped me with before. and seems to fit in with pitti's SRU stuff https://lists.ubuntu.com/archives/technical-board/2015-September/002154.html
[20:00] <doko> infinity, could you provide a glibc 2.22 test build in a ppa? then I could include it in the test rebuild
[20:01] <sarnold> to10fcm: what are you trying to do? I think you'd want either all the libraries and executable to be compiled with gcc <5 or gcc >5, but mixing the two would lead to problems, probably of the sort you tripped on
[20:02] <doko> barry, fyi, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-ppc64el-20150902-wily.html was built with 3.5 as the default
[20:03] <barry> doko: cool, thanks
[20:45] <to10fcm> sarnold, I just want to run dolphin. I have kubuntu installed and I did apt-get update && apt-get upgrade and I'm on 15.10 dev preview and dolphin errors out with this error:
[20:45] <to10fcm> dolphin: relocation error: /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference
[20:56] <doko> to10fcm, dpkg -l dolphin ?
[20:57] <to10fcm> ii  dolphin                              4:15.04.2-0ubuntu1      amd64                   file manager
[20:57] <doko> to10fcm, should be 4:15.08.0-0ubuntu1
[20:57] <doko> is your mirror up to date?
[20:57] <doko> did you run apt-get dist-upgrade?
[21:00] <to10fcm> a while back when i upgraded to 15.10 dev preview. i guess i can do it again and see if i get upgraded to some newer version
[21:09] <TJ-> Anyone got 2 bluetooth adapters working? I'm finding that bluetoothd/bluetoothctl only see hci0 whereas 'hcitool dev' sees all adapters. I'd like to get confirmation that others get the same result
[21:10] <doko> to10fcm, you have to run the complete apt-get update && apt-get dist-upgrade
[21:11] <doko> TJ-, any news about your openjdk-8 backport?
[21:13] <TJ-> doko: I've not had chance to look at it recently. I didn't find any problems with the limited testing I could do, but I didn't have time to do testing against tomcat/jboss etc.
[21:13] <doko> ta
[21:14] <to10fcm> doko, will do. brb after restart to tell u how it went lol
[21:14] <TJ-> I've not had a stable working environment for a while now either. Hit so may bugs on 15.10 I'm about 5 years behind
[21:19] <doko> TJ-, anything compiler specific?
[21:21] <TJ-> doko: No ... almost exclusively upstream's tearing out existing functionality in 'new' releases and breaking existing functionality
[21:24] <TJ-> e.g. systemd-cryptsetup *won't* support keyscripts; bluez not providing a simple agent nor PinCode Pairing, A2DP (punted to gstreamer/pulseaudio), headset profiles HCF/HSP (punted to ofono), LMV pvs not recognising metadata ... the list goes on!
[21:27] <doko> TJ-, bug reports, or pester pitti about systemd, and seb128 about bluez
[21:27] <lamont> wily dist-upgrade, now I have nopanel/launcher/etc...  hints on what more I need to have installed?
[21:28] <TJ-> Yeah, reports are in. I've been attempting to figure out fixes or workarounds but some of them are far too big for simple patches.
[21:29] <TJ-> pitti: is aware of, and just as frustrated, about the systemd-cryptsetup issue. Nothing we can do to fix it though. Upstream want a major new generic API implementing. I've suggested we disable systemd-cryptsetup and use the 'legacy' cryptsetup init scripts which do the job perfectly (and are still used in the initrd)
[21:34] <doko> lamont, working here ...
[21:35] <lamont> it helps when ubuntu-desktop hasn't been removed (apt-get  install -f)
[21:36] <lamont> testing now
[21:37] <lamont> much happier
[21:38] <lamont> (u-d brogut back in unity, compiz, compiz-gnome, et. al.
[21:38] <lamont> :(
[21:38]  * lamont goes back to selep
[21:38] <to10fcm> whoever was helpiing me, thank you!
[22:06] <sarnold> to10fcm: excellent :)
[22:13] <doko> infinity, https://launchpad.net/ubuntu/+source/pytango/8.1.5-1build3
[22:13] <doko> could you have a look at the image, where the c++ alternative points to? looks very much this is still pointing to g++-4.9
[22:16] <Unit193> sarnold: Hiya, know much about openssl's interaction as a library with other applications?
[22:17] <sarnold> Unit193: hey :) I'm going to guess "no", but keep going.. I might get lucky :)
[22:17] <Unit193> Maybe I should take this to #ubuntu-server.
[22:18] <tdaitx> doko, gcc 4.7 FTBFS on ppc64el due to the gcc-as-needed.patch trying to apply to a non existing aarch64-linux.h, for the aarch64 to exist I would need to enable with_linaro_branch, is that ok?
[22:19] <tdaitx> doko, or should I separate the aarch64-linux.h part from gcc-as-needed.diff and apply it only when with_linaro_branch is valid?
[22:19] <doko> tdaitx, ignore it. 4.8 is the first version to build there
[22:20] <tdaitx> oh, ok
[22:20]  * tdaitx moving to the next FTBFS package...
[22:22] <slangasek> mdeslaur: edk2 updated in Debian unstable; will sync it to wily when I think of it again
[22:22] <slangasek> mdeslaur: which I guess actually requires a round-trip through binary new hmm
[22:46] <tdaitx> slangasek, seems like someone else unblocked sssd for the build, the dependencies it was waiting for are done and it builds fine locally
[22:49] <tdaitx> slangasek, same for pulseaudio, libtrust-store-dev is available as well, so a rebuild should go fine
[22:51] <slangasek> tdaitx: the build-dependencies of sssd exist but are not in main
[22:51] <slangasek> tdaitx: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
[22:53] <tdaitx> slangasek, in this case, how exactly can I help?
[23:01] <slangasek> tdaitx: you can follow https://wiki.ubuntu.com/MainInclusionProcess
[23:02] <slangasek> tdaitx: be sure to check for existing bugs for the dependencies in question, to avoid duplication


[07:41] <hakonw> Is it possible to select which bootloader to use with maas?
[14:46] <roaksoax> hakonw: what do you mean ?
[18:00] <cc> exit
[23:01] <fallenour> o/
[23:01] <fallenour> Im having some pretty serious issues with maas after my update to bionic, is anyone else experiencing the same problems as me?
[23:02] <fallenour> my juju instances arent downloading apt-packages anymore, even though I know they should be able to, dns isnt working anymore, even though ip based internet connectivity works, and now my maas page wont load via webbrowser, and it loaded with nginx, with laoded broken.
[23:29] <roaksoax> fallenour: dpkg -l | grep maas
[23:30] <roaksoax> win 4
[23:31] <roaksoax> fallenour: what's the version it is showing ?
[23:32] <fallenour> roaksoax: 2.4.0~beta2-6865
[23:33] <fallenour> roaksoax: In better news, the page is loading again, this time I have to connect to it directly via port, but it still loads, which means its primary config is laying around somewhere, but the proxy isnt forwarding me well.
[23:34] <roaksoax> fallenour: sudo add-apt-repository ppa:maas/stable -y
[23:34] <roaksoax> fallenour: sudo apt-get update && sudo apt-get dist-upgrade
[23:34] <roaksoax> fallenour: that will install 2.4.0
[23:34] <roaksoax> fallenour: 2.4.0 is in the process of being SRU'd into Xenial
[23:36] <roaksoax> sd/xenial/bionic
[23:36] <roaksoax> s/xenial/bionic/g
[23:37] <roaksoax> fallenour: i think that 2.4.0 will resolve your issues


[18:40] <Guest2> Hi. I run jammy with amdgpu. It recently pulled new kernel linux-image-5.19.0-32-generic and was unable to load amdgpu with a fatal error ([drm:amdgpu_device_ip_init [amdgpu]] *ERROR* sw_init of IP block <uvd_v4_2> failed -19). I went back to Ubuntu 5.15.0-60.66-generic 5.15.78 and the system works fine again. Wondering if there is a bug for the
[18:40] <Guest2> issue that I can follow so I can try a newer 5.19 in the future with fix applied.