[00:10] <infinity> soniah: None of those changes look Ubuntu-specific in the least, have you proposed the patch to the Debian maintainer?
[00:12] <infinity> soniah: He actually literally JUST did an upload to Debian, and he's on IRC right now as jamessan.
[00:31] <soniah> infinity - no - I didn't realise I should push it to Debian.
[00:34] <infinity> soniah: We try to make sure all our (non-Ubuntu-specific) patches end up pushed to Debian, so it really makes sense to just start there, IMO.
[00:35] <infinity> soniah: Makes sense doubly-so right now, since Ubuntu is in a freeze leading up to a release, so uploading for cosmetic fixes seems less likely.
[00:42] <soniah> infinity: I'm just learning IRC - how would I contact jamessan? I see he's on lindbohm.freenode.net
[00:43] <sladen> soniah: /query jamessan
[00:43] <soniah> infinity: thanks!
[00:46] <soniah> infinity: he's away, but thanks anyway. All part of the learning, that's why I'm starting packaging :-)
[00:48] <infinity> soniah: Well, the "correct" way to contact him about it would be to file a Debian bug with your patch, and rationale. ;)
[00:48] <infinity> soniah: I was just suggesting IRC, since I knew he was quite recently around.
[00:49] <infinity> soniah: That said, most people like him probably read their queries when they wander back to their computers, so it doesn't hurt to contact him even if he's marked "away".
[00:50] <infinity> soniah: And happy learning.  Always good to see new blood to replace the old folks like me. :P
[01:05] <Darxus> What needs to be done to get this sensors-applet package in the quantal archives?  It got a FFE, and was apparently uploaded to New:  Bug #1049343
[01:09] <infinity> Darxus: It needs reviewing in the queue.  I'll get there.
[01:09] <Darxus> infinity: Thanks.
[01:10] <Darxus> I don't suppose there's any of that process I can see?  A list of the contents of the queue?
[01:10] <Darxus> Ooh https://wiki.ubuntu.com/ArchiveAdministration
[01:11] <Darxus> https://launchpad.net/ubuntu/quantal/+queue  Nice.
[06:35] <dholbach> good morning
[07:04] <pitti> james_w: thanks!
[07:04] <pitti> Good morning
[08:19] <soren_> infinity: Thanks for doing the qemu-kvm rebase for me.
[08:20] <infinity> soren_: No big deal.  I didn't want it to get forgotten after being superseded.
[08:20] <infinity> soren_: (It was a bit of a sore point for me, as my eglibc SRU had just been superseded by a security update around the same time)
[08:23] <soren_> infinity: Cool. The first day or so after uploading it, I checked the unapproved queue every once in a while to see if it moved, but eventually I got distracted.
[09:02] <mnencia> Is this the right channel to ask a question about Debian Unstable -> Ubuntu  package sync process?
[09:02] <geser> yes
[09:06] <mnencia> I'm the Upstream of a package which was just accepted in Unstable (barman) . Given that it's an application for PostgreSQL disaster recovery (no interaction with other applications) there is any chance to have it in universe for the upcoming release or i need to setup a private repository for make it available to users?
[09:17] <geser> mnencia: given that we are short before the release, it's too late to get it directly into the next release but should fit fine into the backports repository
[09:18] <mnencia> geser: ok thanks
[09:18] <infinity> Actually, wait.
[09:18] <infinity> mnencia: Completely new source, doesn't affect any others?
[09:19] <mnencia> completely new. only has a dependency (python-argh) which is also completely new
[09:19] <Laney> Given pre-release backports is already a thing, you can use that
[09:19] <infinity> Laney: Yeah, but syncing new stuff into universe that has no effect on other packages is perfectly reasonable, IMO.
[09:20] <infinity> Also, lolz to "python-argh".
[09:20] <infinity> Looks like I named it.
[09:20] <Laney> Not massively bothered, but this is the kind of thing that backports is best at (and doesn't involve getting exceptions from the RT)
[09:21] <Laney> so, go ahead with whichever way you fancy given that infinity will give you the FFe :P
[09:21] <infinity> True, but the RT is well-represented right here (and I'm about to give it an exception).
[09:21] <Laney> and NEW it too!
[09:21] <infinity> With bonus-points for awesomely-named packages.
[09:22] <infinity> I'll hold off on barman until LP knows about the current version in Debian, but I synced python-argh.
[09:22] <infinity> mnencia: ^^
[09:23] <mnencia> infinity: thanks
[09:28]  * ogra_ glares at -changes ... there is a package called python-argh ? 
[09:28] <ogra_> tsk
[09:28] <Laney> ARGH!
[09:29] <ogra_> :)
[09:29] <infinity> ogra_: I intend to write python-blah, python-bleh, and python-fuck, and it will match the naming scheme of the majority of my test .c files and scratch directories.
[09:29] <ogra_> the latter wont comply with family friendliness though
[09:29] <infinity> I'll claim it's French.
[09:30] <ogra_> so you support seb128's secret strategy ?
[09:30] <infinity> No, but that's because technical French sounds silly.
[09:30] <infinity> If I could get my pretty prose in French, but my technical writing in English, I'd probably be happy.
[09:30]  * pitti mumbles télécharger
[09:30] <infinity> (Or the latter in German, even)
[09:30] <seb128> did you try technical German before says that?
[09:31] <seb128> saying
[09:32] <cjwatson> My test files and scratch directories tend to be called things like x, y, and t
[09:32] <cjwatson> I think there's something in policy about single-character names :)
[09:32] <pitti> heh, I use /tmp/x, /tmp/y for files, or /tmp/p for patches
[09:32] <GunnarHj> jamespage: Hello! Could you please help with a merge of a simple patch clean-up MP?
[09:32] <GunnarHj> jamespage: https://code.launchpad.net/~gunnarhj/gnome-settings-daemon/drop-patch-43/+merge/128371
[09:32] <infinity> My names tend to be representative of how frustrated I've become with a problem.
[09:33] <jamespage> GunnarHj, sure
[09:33] <pitti> infinity: doesn't that collide with lazyness at some point?
[09:33] <infinity> Eventually, they lose all semblance of creativity and just start repeating expletives.
[09:33]  * jamespage forgot to pilot out - but had time
[09:33] <jamespage> @pilot out
[09:33] <GunnarHj> jamespage: great
[09:33] <GunnarHj> jamespage: Sometimes you are lucky. ;-)
[09:33]  * dupondje is sad about the fact quantal doesn't seem to be able to open his new Samsung S3 :(
[09:35]  * dholbach hugs jamespage
[09:35] <jamespage> GunnarHj, any particular reason for merging those two patches?
[09:35] <jamespage> they seem quite unrelated
[09:36] <jamespage> morning dholbach!
[09:36] <dholbach> hey :)
[09:36] <dupondje> pitti: as you seem to be the gvfs guy, any idea's on how to debug gvfs not able to mount my Samsung S3 (Android MTP) ?
[09:36] <dupondje> also see https://bugs.launchpad.net/ubuntu/+source/udev/+bug/903422
[09:36] <GunnarHj> jamespage: It started with an attempt to build the package without patch 43, and then I discovered that patch 48 didn't apply. Well, to the purpose they are unrelated. Just an attempt to simplify things.
[09:36] <pitti> dupondje: doesn't it provide mass storage?
[09:37] <dupondje> pitti: Android 4+ doesn't have mass storage anymore
[09:37] <dupondje> only PTP or MTP
[09:37] <pitti> dupondje: gvfs doesn't support MTP; the closest thing is PTP through the libgphoto backend
[09:37] <pitti> dupondje: I have CyanogenMod 9, which is Android 4 (ICS), and mass storage works fien
[09:37] <pitti> fine
[09:37] <dupondje> libgphoto2 doesn't support MTP ?
[09:38] <pitti> Rhythmbox does, though libmtp
[09:38] <pitti> but that's not gvfs
[09:38] <dupondje> pitti: seems there are apps to re-enable mass storage on ICS
[09:38] <pitti> dupondje: I think listing files etc. should be possible through libgphoto, but ICBW
[09:38] <dupondje> but default is MTP
[09:39] <pitti> I dont' have any MTP devices, so I never tested thsi
[09:39] <pitti> I only have a PtP digicam
[09:39] <pitti> dupondje: ah, maybe cyanogenmod has that by default then
[09:39] <dupondje> Well, with PTP I can see my files on the device itself, SD card shows empty
[09:39] <dupondje> and with MTP, it sees the device, shows in nautilus, but unable to mount it
[09:40] <pitti> dupondje: do you see it in 'gphoto2 --auto-detect'?
[09:40] <pitti> dupondje: if not, try running it as root and see if that makes a difference
[09:41] <jamespage> GunnarHj, so the setproxy call is no longer required?
[09:41] <dupondje> pitti: yes it shows
[09:42] <pitti> dupondje: gphoto2 --list-cameras at least lists »Samsung Galaxy Nexus/Galaxy S i9000/i9250, Android 4.0 updates«
[09:42] <dupondje> that also matches the S3
[09:42] <GunnarHj> jamespage: you mean set_locale().
[09:42] <jamespage> GunnarHj, yeah - sorry - brain misfired then
[09:42] <jamespage> I think I see
[09:43] <GunnarHj> jamespage: In standard ubuntu it should be disabled - has been for a while.
[09:43] <jamespage> GunnarHj, patch 48 completely removes that function  - I see now
[09:43] <dupondje> pitti: but gphoto2 --summary fails for example
[09:43] <pitti> dupondje: so it seems libgphoto2 doesn't handle it then
[09:43] <GunnarHj> jamespage: But if you want to use upstream GNOME interface for language/locales settings it's needed.
[09:44] <pitti> dupondje: does it work any better in Rhythmbox? that uses libmtp, which should be more suitable
[09:44] <pitti> dupondje: at least for the music part?
[09:44] <dupondje> It gives failed to lock usb I tought :) (not on my quantal pc atm)
[09:44] <dupondje> pitti: well, mainly need it to move my pics I made on my phone :)
[09:45] <seb128> can you browse over bluetooth as a workaround?
[09:45] <dupondje> seb128: haven't tested that. Tested to send the pics over bluetooth to my pc, but it fails also :(
[09:46] <jamespage> GunnarHj, this is just housekeeping right?
[09:46] <GunnarHj> jamespage: Indeed.
[09:47] <mvo> barry, pitti: can I ask you for your opinion about bug #1058038? the issue is that dbus activated aptd is runnig without lang/language from the auto-activation. that means that the default encoding for the filesystem is "ascii" instead of something more sensible like utf-8. python sets this once that interpreter startup apparently so any subsequent changes to env will not get honored afaict. so it seems we can either set the default system lan
[09:47] <mvo> guage on dbus activiation or add a wrapper around aptd that sources /etc/default/locale - wdyt?
[09:48] <pitti> mvo: yeah, that's something that annoys me in Python 3 as well
[09:48] <pitti> mvo: I fought with this too often, and as a consequence I now always open those kind of files in binary mode and call .decode('UTF-8') explicitly
[09:48] <pitti> mvo: if you don't need py2 suport, you can use open('file.txt', encoding='utf-8')
[09:48] <cjwatson> Simpler to open them with encoding="UTF-8")
[09:48] <cjwatson> Yeah
[09:48] <pitti> mvo: but thaht doesn't work with py2
[09:49] <cjwatson> There are workarounds for that if you need them
[09:49] <pitti> 'rb' and .decode('UTF-8') works everywhere
[09:49] <cjwatson> Cumbersome as hell though :)
[09:49] <pitti> *nod*
[09:49] <cjwatson> Any way we can pass the language across dbus activation?
[09:49] <cjwatson> er, locale
[09:50] <pitti> but as aptdaemon still builds a py2 package, it might be unavoidable
[09:50] <mvo> pitti, cjwatson: just to double check, will that work with utf8 *filenames* as well? I get e.g. os.stat() errors for a utf8 encoded filename when running without LANG/LANGUAGE on python startup
[09:50] <pitti> mvo: not sure, but I don't think it will
[09:50] <pitti> I'm not aware of a way to pass the client locale to the activated d-bus service
[09:51] <pitti> and either way that wouldn't make sense, as the service is already running when the next client calls (which might have a different locale)
[09:51] <pitti> a feasible thing might be a SetLocale() d-bus method?
[09:51] <mvo> pitti: well, I just need it to have a sensible sys.getdefaultfsencoding()
[09:52] <GunnarHj> jamespage: Simply to make that alternate build a little easier. If you approve the MP, those who need the set_locale() call can just add it. https://launchpad.net/~gunnarhj/+archive/misc/+sourcepub/2704893/+listing-archive-extra
[09:52] <mvo> pitti: so that this is set to utf-8 instead of ascii so that stuff like os.stat() works (and open() too)
[09:52] <cjwatson> There really needs to be a sys.setdefaultencoding()
[09:52] <mvo> pitti: its probably really a bug in python as changing locales apparently never changes the filesystem encoding, I will ask barry about it
[09:52] <pitti> mvo: my gut feeling at this point of the release cycle is to just set it to UTF-8
[09:52] <mvo> cjwatson: yeah
[09:53] <pitti> mvo: that will at least not break any case that currently works (with ASCII default), and we never really supported non-UTF8 locales in Ubuntu anyway
[09:53] <mvo> pitti: I tend to agree, not sure how much upstream will like that though
[09:53] <pitti> mvo: and perhaps for trunk/r-cycle add a SetLocale() method?
[09:53] <cjwatson> Or else there needs to be a way to break the caching when we change Python's locale at run-time
[09:53] <mvo> pitti: but I think that its a much more sensible defalt than ascii
[09:53] <cjwatson> That might be a good idea anyway
[09:54] <mvo> cjwatson: yeah, that would be the cleanest I think, ensuring this is reset on setlocale()
[09:54] <pitti> yeah, a locale.setlocale() call ought to change the fs encoding, too
[09:54] <mvo> ok, I can look into that
[09:54] <pitti> just saying that if all else fails, hardcoding utf-8 shoudl avoid 99% of the problems with a really trivial/safe patch?
[09:55] <pitti> (past beta2 and all that..)
[09:56] <jamespage> GunnarHj, OK - so I commented on the merge pre your last comment in channel
[09:56] <jamespage> GunnarHj, I think the housekeeping makes sense but I indicated it should be deferred
[09:56] <mvo> pitti: the patch for this is probably trivial, its just that I'm slightly concerned about upstreams reaction to it, but +1 for trying it
[09:57]  * mvo will have lunch first and look at it afterwards
[09:57] <tkamppeter> I have a problem with Avahi, bug 1059286, this is a major issue for the release and it seems that no one had a look at it yet.
[09:57] <jamespage> GunnarHj, but it sounds like you need it for your alternate build right?
[09:58] <seb128> tkamppeter, nobody is maintaining avahi in Ubuntu...
[09:59] <tkamppeter> Is Avahi serving for any essential functions in a Ubuntu desktop system?
[10:00] <tkamppeter> I know that CUPS uses it to broadcast printer info (mainly to Apple clients) and to discover network printers. Is it used for anything else?
[10:01] <seb128> tkamppeter, it's use for services discovery (music in rhythmbox, shares in nautilus)
[10:01] <pitti> pulse can use it to discoover remote audio sources/sinks, and RB for remote DAAP music shares
[10:01] <GunnarHj> jamespage: Yes, it would be nice.
[10:01] <pitti> as well as Telepathy's salut module (talking to other computers on same network)
[10:02] <jamespage> GunnarHj, in which case it needs better justification and ideally a bug ref in the changelog
[10:02] <jamespage> remember the release team have to review every upload to quantal
[10:02] <jamespage> so it needs to be made clear as to why this change is required.
[10:03] <tkamppeter> pitti, and this functionality can get compromised by Avahi blowing up all the time.
[10:03] <GunnarHj> jamespage: Ok, it makes sense to me.
[10:04] <GunnarHj> jamespage: I'll submit a bug where I explain the reason behind the 'clean-up'. Thanks for your time!
[10:04] <jamespage> GunnarHj, np
[10:06] <tkamppeter> pitti, is apport using avahi? Now I have both avahi-daemon and apport spinning up (now I know why one needs a quad core CPU).
[10:07] <dupondje> pitti: just chatting with libgphoto2 dev's and seems like thing may be improved in 2.5.0 version. But I guess its way to late for that now :)
[10:07] <pitti> tkamppeter: no, it's not
[10:07] <pitti> dupondje: you could try building it from source and testing it with the gphoto2 command line tool? If it works, then perhaps there's an upstream commit or two to backport
[10:17] <tkamppeter> pitti, avahi-daemon only spins up if you have very many queues (in my case 17), so the problem affects users who want to set up a print server. A workaround which works for me is having avahi-daemon always running under strace and shooting the log to the moon (/dev/null). Perhaps we should do this in Quantal.
[10:18] <pitti> tkamppeter: running under strace is hardly a solution :)
[10:18] <pitti> tkamppeter: does it keep using 100% CPU forever, or just for a few seconds until it announced all its queues?
[10:18] <tkamppeter> pitti, it is a workaround, not a fix.
[10:18] <pitti> tkamppeter: does it stop spinning when you stop cupsd?
[10:19] <pitti> i. e. is it cups constantly telling avahi about printer queues, or is it avahi itself?
[10:19] <tkamppeter> pitti, it keeps the 100% forever, even after stopping CUPS.
[10:20] <pitti> tkamppeter: some debugging ideas: attach strace to a spinning avahi-daemon;watch the console when you start avahi-daemon in a terminal
[10:20] <seb128> use gdb to see if you get details about what it's spinning on...
[10:21] <tkamppeter> pitti, I already did and attached the result to the bug report. See bug 1059286.
[10:24] <seb128> it seems to be spammed by "HP Photosmart C8100 series" detection
[10:25] <seb128> tkamppeter, if you use "avahi-browse-domains -a", does it keep listing the same thing?
[10:36] <tkamppeter> seb128, while it is spinning avahi clients cannot access at all. avahi-discover simply hangs and only errors out when avahi-daemon gets killed.
[10:37] <seb128> tkamppeter, weird
[10:37] <seb128> it looks like something DoS avahi with printer notifications though
[10:37] <seb128> not sure if something is remote or if it's cups
[10:40] <semvoz> hello :)
[10:54] <tkamppeter> seb128, pitti, I have done the gdb test three times now and when I interrupt, it always interrupts in the same function, with the same backtrace (but at different queue names).
[10:59] <tkamppeter> seb128, pitti, can we consider this also as a security vulnerability, as avahi-daemon can get broken by a DoS.
[10:59] <pitti> if something keeps firing requests at it, it's a DoS, yes
[11:09] <tkamppeter> pitti, seb128, but it seems that CUPS does not keep firing, as after stopping CUPS avahi-daemon keeps spinning.
[11:14] <seb128> tkamppeter, does it stop if you disconnect "HP Photosmart C8100 series" from the network?
[11:26] <tkamppeter> seb128, pitti, printer was totally crashed (touch screen not responding), restarted printer, restarted avahi, restarted cups, spinning again ...
[11:27] <seb128> tkamppeter, if you disconnect the printer does it stop?
[11:28] <tkamppeter> seb128, pitti, Turning of printer, still spinning.
[11:28] <seb128> hum, k :-(
[11:29] <seb128> tkamppeter, you seem to be the only one having the issue and avahi didn't change a lot in the recent cycles, I think what is creating the issue is something on your local setup DoSing the service, it's not happening to every user if that's a consolation
[11:29] <tkamppeter> Restarted avahi-daemon, restarted cups, avahi-daemon spinning again.
[11:30] <seb128> if you strace avahi it's still listing those same requests?
[11:30] <pitti> you could also try dbus-monitor --system to see which process is talking to avahi that much
[11:32] <tkamppeter> pitti, does avahi get all its requests via D-Bus?
[11:33] <pitti> locally, yes; remotely it gets them through DNSSD network packets
[11:38] <tkamppeter> pitti, seb128, it sends a message containing the service names of all local print queues several 100 times a second.
[11:39] <seb128> tkamppeter, "it"?
[11:39] <seb128> cups?
[11:39] <tkamppeter> seb128, where did you find messages it received? I do not find them as it is too busy sending the announcement of all CUPS queues.
[11:39] <tkamppeter> seb128, "it" = avahi-daemon.
[11:41] <seb128> tkamppeter, can you pastebin a bit of the log?
[11:42] <tkamppeter> seb128, pitti, it is attached to bug 1059286, comment #6.
[11:43] <seb128> tkamppeter, that's not a dbus-monitor log
[11:44] <seb128> tkamppeter, dbus-monitor should start lines with e.g "signal sender=:1.6"
[11:44] <seb128> tkamppeter, you can install,run d-feet to find out what :1.6 is
[11:45] <seb128> tkamppeter, well :1.6 -> the sender
[11:45] <tkamppeter> seb128, sorry, that is the strace log.
[11:45] <seb128> tkamppeter, install, run d-feet, use the menu to connect to the system bus, select the sender id on the left pane and look at the top of the right pane
[11:46] <tkamppeter> seb128, pitti, on the D-Bus nearly nothing is happening: http://paste.ubuntu.com/1267303/
[11:47] <seb128> tkamppeter, hum, and on the session bus (dbus-monitor --session)?
[11:48] <seb128> tkamppeter, I wonder if some of your printer spam it over the network with dnssd
[11:48] <seb128> tkamppeter, does it stop if you disconnect from your local network?
[11:51] <tkamppeter> seb128, keeps on spinning if I do "Disable Networking" in the Network manager menu.
[11:51] <seb128> tkamppeter, no crazy activity in dbus-monitor --session
[11:52] <seb128> tkamppeter, something is spamming avahi with printer queue discovery, those requests must come from somewhere (are you sure it's not cups?)
[11:52] <tkamppeter> seb128, have it running now and it is very calm, minutes passing by without anything happening ...
[11:53] <seb128> tkamppeter, it stopped spinning cpu you mean?
[11:54] <tkamppeter> Now I have two avahi-daemons in top, one spinning at 100 % and the other spinning at -166%, so I got an extra 2/3 of a CPU core by avahi-daemon.
[11:54] <tkamppeter> seb128, nothing stopped spinning, it keeps spinning.
[11:57] <tkamppeter> Here is the top output: http://pastebin.ubuntu.com/1267316/
[11:57] <tkamppeter> seb128, pitti ^^
[11:58] <seb128> tkamppeter, I don't know what is sending those requests if it's neither the network nor cups
[11:58] <seb128> tkamppeter, maybe try to stopping both network and cups and restart avahi and see if it keeps happening...
[11:58] <seb128> tkamppeter, btw, could you look at https://errors.ubuntu.com/bucket/?id=%2Fusr%2Flib%2Fcups%2Fdriver%2Fopenprinting-ppds%3AUnicodeEncodeError%3A%3Cmodule%3E%3Amain%3Als
[11:59] <seb128> tkamppeter, I don't find an openprinting-ppds package in quantal to open a bug,assign it to you but it's high on https://errors.ubuntu.com/
[12:03] <tkamppeter> seb128, cannot see the link, login system is totally broken.
[12:04] <tkamppeter> seb128, openprinting-ppds is a binary package of foomatic-db.
[12:05] <seb128> tkamppeter, ok, the bug is https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/1014852
[12:07] <tkamppeter> seb128, seems that the built-in uncompressor of openprinting-ppds stopped working, probably depending on locale.
[12:15] <tkamppeter> seb128, pitti, avahi-daemon does not stop to spin when stopping CUPS and stopping the network.
[12:15] <tkamppeter> seb128, pitti, I have also shut down all virtual machines.
[12:15] <seb128> tkamppeter, that doesn't make sense, those printing queue requests have to come from somewhere
[12:16] <seb128> tkamppeter, try rebooting, maybe you have lot of requests queued in dbus and it's still processing those...
[12:17] <seb128> we had the issue with libreoffice recently, it was spamming dbus so much with menu stuff that it was still spinning cpu for a long time after the requests sent
[12:17] <seb128> stopped
[12:19] <tkamppeter> seb128, pitti, strace log of avahi-daemon spinning after stopping cups and turning off networking: http://pastebin.ubuntu.com/1267337/
[12:19] <seb128> tkamppeter, reboot and try on a freshly started state please, your system might have queue hours of backlog at this point
[12:20] <seb128> tkamppeter, reboot and try on a freshly started state please, your system might have queue hours of backlog at this point
[12:20] <tkamppeter> seb128, pitti, strace log of avahi-daemon spinning after stopping cups and turning off networking: http://pastebin.ubuntu.com/1267337/
[12:24] <dupondje> pitti: just testing my phone on my other laptop (Precise), and its working
[12:24] <dupondje> so seems like a regression :(
[12:25] <dupondje> Hmz, well 'working', I see the device, can mount it, I see the folders, but everything is empty :p
[12:25] <seb128> dupondje, hum, I doubt it's new, https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/972311 and such started before precise
[12:26] <dupondje> seb128: well indeed, but in Precise I can mount it, in Quantal even that is not possible
[12:26] <seb128> :-(
[12:29] <dupondje> joy, and now nautilus crashed, and it doesnt work again :p
[12:29] <dupondje> ah well :(
[12:30] <tkamppeter> as usual, I am floating between the channels.
[12:30] <tkamppeter> seb128, I have done so now: Stopped cupsd, keeps spinning, stopped network, keeps spinning, attached strace to avahi-daemon, log of some seconds (<10 sec): http://pastebin.ubuntu.com/1267347/.
[12:30] <tkamppeter> pitti, ^^
[12:32] <seb128> tkamppeter, those strace log have a sin_addr=inet_addr("224.0.0.251") ... what machine is that, your computer?
[12:33] <tkamppeter> seb128, pitti, 2 MB of log per second.
[12:33] <dupondje> seb128: thats multicast addr
[12:33] <tkamppeter> seb128, pitti, I have done so now: Stopped cupsd, keeps spinning, stopped network, keeps spinning, attached strace to avahi-daemon, log of some seconds (<10 sec): http://pastebin.ubuntu.com/1267347/.
[12:33] <tkamppeter> seb128, pitti, 2 MB of log per second.
[12:34] <seb128> tkamppeter, well, something, somewhere on your local network or system is sending those requests
[12:34] <seb128> tkamppeter, can you pastebin a ps aux of your box?
[12:34] <seb128> tkamppeter, you can try using ethereal as well to see if something on the network is sending those
[12:36] <tkamppeter> seb128, pitti: ps auxwww: http://pastebin.ubuntu.com/1267354/
[12:38] <seb128> tkamppeter, what is tprintdaemon?
[12:39] <seb128> tkamppeter, can you stop it in case that's due to it?
[12:41] <tkamppeter> seb128, simply killing tprintdaemon does not stop the spinning.
[12:41] <seb128> tkamppeter, can you stop hp-systray as well?
[12:43] <tkamppeter> seb128, stopped hp-systray spinning goes on.
[12:45] <seb128> tkamppeter, ok, I don't know then, wait for a bit in case it's backlog being still cleared, otherwise I would recommend next to install wireshark and to try to see if there are network trames corresponding to that activity listed
[12:45] <seb128> to try to figure what is sending those
[12:46] <tkamppeter> seb128, I have installed wireshark but it does not find my network interface. It is eth2.
[12:49] <tkamppeter> seb128, for me it also looks like that avahi-daemon does not get flooded by anything. It still spins under complete isolation (no cupsd, no network, ...) It stops spinning immediately when restarted (and with this the network traffic should not change). It starts spinning when cups is started and keeps spinning until killed from then on, independent what one does to try to stop it.
[12:49] <tkamppeter> seb128, and the strace log only shows that avahi-daemon is sending out messages, no hint that it receives messages.
[12:50] <seb128> weird
[12:50] <seb128> dunno, I need to run for an hour or so, bbiab
[13:06] <pitti> @pilot in
[13:17] <stokachu> if something is in the unapproved build queue is it just a matter of waiting for someone to approve it?
[13:17] <stokachu> or is there anything else from my side I would need to do
[13:19] <pitti> stokachu: you mean the unapproved queue? the release team reviews that regularly
[13:19] <pitti> (we have unapproved and build queues, but not an unapproved build queue)
[13:20] <ev> mpt: even factoring out RecoverableProblem reports, 12.10 is pretty high. (See http://poppy-dev.local, ignoring the line starting too early)
[13:20] <ev> ~0.12 for the past two days
[13:21] <ev> I'm going to back-populate the previous days to give us more information
[13:21]  * dholbach hugs pitti
[13:21]  * pitti hugs dholbach back
[13:22] <pitti> mvo: wrt. https://code.launchpad.net/~vericalcroft/ubuntu/quantal/app-install-data-partner/misc-depends-added/+merge/125288, is there a Vcs for this?
[13:22] <pitti> mvo: this looks like a change which doesn't warrant an upload by itself
[13:23] <pitti> oh, indeed, the MP is against the UDD branch
[13:23] <pitti> I'll just commit it to Vcs-Bzr:
[13:23] <pitti> mterry: ^ FYI
[13:23] <pitti> mterry: (as you commented on this)
[13:23] <mpt> ev, so that's the "by 12.04 standards" line for the past 3 days?
[13:23] <pitti> mvo: except that Vcs-Bzr: doesn't exist, hmm
[13:23] <ev> mpt: yeah
[13:24] <ev> hacked into place for now
[13:24] <mpt> ev, so RecoverableErrors are about 1/7 of the total
[13:24] <ev> I'll clean that up, back populate, and create separate all collected and by 12.04 standards lines
[13:25] <mpt> (1 - 0.12/0.14)
[13:25] <ev> indeed
[13:25] <ev> was just looking at the raw numbers
[13:25] <ev> for the 7th
[13:25] <mvo> pitti: meh, I will add one, sorry for that
[13:26] <ev> 225 RecoverableProblem reports
[13:26] <ev> 5201 Crash reports
[13:26] <pitti> mvo: hm, and lp:app-install-data-commercial  seems out of date
[13:26] <pitti> mvo: should this perhaps just use the UDD branch now?
[13:26] <pitti> mvo: I'm happy to do an upload with dropping Vcs-Bzr: and adding the misc:depends thing
[13:26] <pitti> (and yay for wasting time on such trivialities)
[13:29] <ara> We would need sponsorship for Checkbox, if anyone is free:
[13:30] <ara> https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.8/+merge/127923
[13:31] <mvo> pitti: no strong opinion either way (branch vs udd). feel free to upload or I can do it later (once I finished wrestling aptdaemon)
[13:31] <stokachu> pitti: ah yes, the unapproved queue
[13:32] <pitti> mvo: ok; I think it's easier to use the UDD branch
[13:41] <tkamppeter> seb128, pitti, what I guess what is happening I commented on bug 1059286 now: For me it looks like that avahi-daemon falls into an infinite loop sending out certain messages repeatedly (there are several 100 messages per second announcing the available CUPS queues) and does not listen any more to requests (loop does not go through the code for listening). Therefore avahi-discover cannot connect and also CUPS is not able to unregister it
[13:41] <tkamppeter> s printers on shutdown. This leaves avahi-daemon continue to spin and announce CUPS queues.
[13:48] <xclaesse> seb128, does ubuntu patch glib, something related to GDBus ?
[13:50] <xclaesse> seb128, I've got that problem: https://bugs.freedesktop.org/show_bug.cgi?id=55761#c1
[13:50] <xclaesse> my code works with glib 2.34.0 from git, but not from ubuntu package
[13:52] <xclaesse> hm, could be some modules that have side effects
[13:55] <pitti> xclaesse: we do have some patches, but not against dbus
[13:55] <pitti> xclaesse: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/experimental/glib2.0/debian/patches/
[13:55] <pitti> xclaesse: mostly test suite fixes, translation, and multi-arch
[13:57] <xclaesse> pitti, yeah, I'm suspecting modules that gets loaded and uses gdbus
[13:57] <xclaesse> pitti, is there a way to know what modules gets pulled by any glib process?
[13:57] <pitti> xclaesse: check /proc/pid/maps ?
[14:29] <pitti> dholbach: for stuff like https://code.launchpad.net/~logan/ubuntu/quantal/nodm/debian-merge/+merge/128406, you don't push the branch?
[14:29] <pitti> dholbach: or mark them as merged manually?
[14:29] <dholbach> ah sorry, I didn't
[14:29] <dholbach> I can mark it as merged
[14:29] <pitti> dholbach: I can as well if you want me, just wondering about what went wrong here
[14:29] <dholbach> usually I wait for the importer to mark it as merged for me ;-)
[14:30] <dholbach> or rather import it
[14:30] <pitti> import yes, but the importer won't notice that MP
[14:30] <dholbach> ok, I'll bear that in mind until next time
[14:31] <dholbach> I wish we had push-to-build
[14:32] <pitti> bzr: ERROR: Unable to unapply quilt patches for 'other' tree: rmdir: failed to remove `.pc/force-ruby1.8': No such file or directory
[14:32] <pitti> go, bzr merge
[14:34]  * pitti downloads diff, cleans it, and applies manually
[14:48] <Sweetshark> lamont: scheat is fed up with compiling libreoffice and remounted /home read-only. In protest it left interesting jabbering in dmesg. Maybe remount/reboot it?
[14:49] <Sweetshark> cd ..
[14:57] <ahasenack> SpamapS: hi,
[14:58] <ahasenack> SpamapS: do you know why only the precise packages were uploaded? bug #1053057
[14:58] <ahasenack> SpamapS: and landscape-client is gone from the sponsoring queue at http://reqorts.qa.ubuntu.com/reports/sponsoring/
[14:58] <ahasenack> so no-one else will look at it I think
[15:01] <SpamapS> ahasenack: they were all uploaded, but only precise was approved
[15:02] <SpamapS> ahasenack: we are really far behind on SRU's so its likely we're just skipping the non-precise releases to try and get maximum impact on precise's backlog
[15:02] <ahasenack> SpamapS: ok, I suppose it's still in some list/report that someone looks at?
[15:03] <cjwatson> wookey: slang2 uses 'dh $@ --with autotools_dev', so your patch for that is unnecessary
[15:03] <cjwatson> wookey: All the others are uploaded (some still in the unapproved queue) now
[15:05] <SpamapS> ahasenack: http://people.canonical.com/~ubuntu-archive/pending-sru.html and at the bottom you will find links to the queues
[15:06] <SpamapS> ahasenack: I see it in 11.10, 11.04, and 10.04
[15:06] <ahasenack> SpamapS: thanks
[15:07] <wookey> cheers colin. I've binned that one from my list too.
[15:30] <pitti> @pilot out
[15:53] <dupondje> pitti: http://pastebin.com/d3dRmqx3 this is what happens when I connect my device
[15:53] <mlankhorst> bdmurray: that apt bug would actually be high or critical since it's a blocker for 12.04.2 :-)
[15:53] <pitti> dupondje: btw, you might be interested in gnome bug 666195 :)
[15:53] <dupondje> pitti: yep just read it :)
[15:54] <dupondje> Quantal+1 is smilin :p
[16:01] <dupondje> pitti: something new, gphoto2 --summary works if I execute it in the first seconds the device is connected
[16:17] <hallyn> jodh: hey, when you get a chance, could you comment in bug 1056927 ?  (then un-assign yourself :)
[16:32] <jodh> hallyn: done.
[16:36] <hallyn> jodh: thanks
[18:11] <wookey> doko: gcc stage2 build is falling over building libgcc1 due to not finding 'bit/predefs.h'.
[18:13] <wookey> Is that something I should expect to see needed at this point? There is one in the libc-headers unpacked under arm64-toolchain-cross-base/debian/tmp/ (usr/include/aarch64-linux-gnu)
[18:13] <wookey> but I don;t see anything telling the build to look in that dir. So either the build-line is missing a -isystem or it's trying to build something it shouldn't at this stage
[18:17] <wookey> which means eglibc stage1 completed :-) so I am making (slow) progress :-)
[18:18] <barry> is anybody else seeing recent terrible regressions on window animation speeds?  e.g. bug 1063980
[18:29] <infinity> wookey: The location for that file is correct, you may be missing multiarch foo in your gcc build?
[18:30] <infinity> wookey: (Long weekend here, so I'm running off again, but we'll touch base tomorrow on all of this)
[18:30] <wookey> infinity: good - it's slow progress with no one to share the pain with :-)
[18:31] <wookey> wife is away tonight so I'll hack some more until fed up
[19:27] <doko> wookey, what does build/gcc/xgcc -Bbuild/gcc/ -v -c foo.c say about the include dirs?
[19:45] <wookey> doko: sorry, was on phone. build log is here: http://wookware.org/files/gccstage2faillog
[19:48] <wookey> --includedir=/usr/aarch64-linux-gnu/include
[19:49] <wookey> and --with-build-sysroot=/home/wookey/linaro/armv8/toolchain/quantalnew/arm64-cross-toolchain-base-1.89/debian/tmp which combined with above should find it
[19:51] <doko> wookey, I'm confused. you talk about stage2 for a cross compiler?
[20:01] <robert_ancell> @pilot in
[20:01] <doko> wookey, best thing would be to ask hrw about this. maybe this is something which just works by chance in his setup.
[20:01] <wookey> OK. He's mostly fogotten how all it all works :-)
[20:02] <wookey> something about the armel setup makes it work.
[20:02] <wookey> I'm jujst trying to work out what's missing/different/wrong
[20:03] <wookey> there is build-gcc1, build-gcc2, build-gcc3 rules in the toolchain bootstrap package. It's failing on build-gcc2
[20:03] <wookey> export LD_LIBRARY_PATH=${CURDIR}/debian/tmp/$(PF)/$(HOST_GNU_TYPE)/${CROSS_GNU_TYPE}/lib/:${CURDIR}/debian/tmp/usr/lib:${CURDIR}/debian/tmp/lib
[20:04] <wookey> cd gcc && DEB_CROSS_NO_BIARCH=yes WITH_BUILD_SYSROOT=${CURDIR}/debian/tmp DEB_STAGE=stage2 PKG_IGNORE_CURRENTLY_BUILDING=1 BACKPORT=false dpkg-buildpackage  -b -uc -us -d
[20:04] <wookey> which loks plausible to me
[20:05] <wookey> I don;t know what PKG_IGNORE_CURRENTLY_BUILDING=1 does, and hrw couldn't remember
[20:06] <wookey> don't worry - I was just wondering if you'd go 'ah yes, that's probably X'
[20:34] <doko> wookey, I'll try to have a look, but it's not priority for me until the quantal release
[20:36] <wookey> sure
[20:57] <cjwatson> wookey: PKG_IGNORE_CURRENTLY_BUILDING tweaks a behaviour of pkgbinarymangler; there's a rationale for why one might do that in its changelog
[20:57] <cjwatson> (don't know if it's the same reason as here)
[22:12] <hallyn> so, this is hillarious...  when you create a volume group called 'kvm' and with a LV called 'root', it creates /dev/kvm/root (-> ../dm-0).  Obviously that's trouble if you also want to use kvm.
[22:12] <hallyn> should there be a blacklist to prevent the /dev/kvm dir from being created?
[22:13] <hallyn> i.e. is that "just life suckign", or an actual bug in the lvm2 package?  (it happened to a user on the libvirt mailing list)
[22:16] <mbiebl> hallyn: heh, I'll guess I name my next vg dri0 :-)
[22:16] <SpamapS> hallyn: that does seem like a good idea (blacklisting known paths)
[22:16] <hallyn> mbiebl: :)
[22:17] <hallyn> SpamapS: i'm wondering if it's already beign done...
[22:17] <hallyn> (for some paths, that is)
[22:19] <hallyn> well i guess i'll file a bug and see what lvm2 folks say :)
[22:19] <hallyn> then i'm outta here - ttyl
[22:21] <hallyn> filed bug 1064099
[23:46] <wookey> doko: I've worked it out - it's multiarch vs old includedir paths. Now I just have to work out wherre in that epic build system to fix it...