[12:37] <poningru> quick question, is the gutsy kernel currently the .22 rc or are we still on .21?
[12:40] <poningru> need it for tribe1 walkthrough
[12:42] <crimsun> the latest, 6.13, merged 22-rc3
[12:42] <crimsun> it's noted in the changelog.
[12:50] <BenC> crimsun: thanks
[12:51] <poningru> awesome
[12:51] <poningru> thanks
[12:51] <BenC> and 6.13 will definitely be what tribe1 gets released with
[01:12] <poningru> another question: will SLUB be used?
[01:13] <BenC> it already is
[01:13] <BenC> has been for a few weeks now
[01:14] <poningru> awesome
[01:14] <poningru> thanks
[01:14] <BenC> np
[01:15] <BenC> poningru: since you're doing release notes, please add in there that all of our third party modules and added firmware have moved to linux-ubuntu-modules-2.6.22, and that users need to ensure that they have linux meta packages installed for proper upgrades
[01:15] <poningru> sweet will put that under upgrade notes
[01:15] <BenC> mainly linux-generic
[01:15] <BenC> thanks
[01:16] <poningru> :D
[01:16] <poningru> np
[02:37] <poningru> can you guys look over https://wiki.ubuntu.com/GutstyGibbon/Tribe1#head-8a02e12763c54b7c8a328619650ce2e38f78d93c
[02:37] <poningru> see if its ok?
[02:38] <poningru> thanks :)
[05:21] <poningru> ...
[05:21] <poningru> can someone check?
[05:22] <crimsun> it -is- Sunday night or very early Monday morning for most devels
[05:22] <crimsun> but sure, I'll once-over it, though I'm by no means comprehensive for all changes.
[05:27] <crimsun> poningru: would you like me to outline suggestions in #ubuntu-doc or just make changes?
[05:36] <poningru> either or
[05:36] <poningru> but I can do it
[05:36] <poningru> crimsun:
[05:37] <poningru> yeah I guess it can wait till later
[05:40] <crimsun> poningru: ok, I'll edit it.
[05:41] <poningru> gracias
[05:45] <crimsun> edited.
[05:48] <crimsun> (also may wish to mention continuing work with powersaving: install powertop from universe)
[05:55] <poningru> only available in gutsy right?
[06:00] <crimsun> correct, but you -are- writing Tribe1 notes, so...
[06:02] <poningru> right just making sure feisty features done make it in there
[06:02] <poningru> thanks man :D
[07:56] <jml> Is it likely that bug 117864 will be fixed in Feisty?
[07:57] <jml> i.e. https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117864
[08:00] <crimsun> it's missing `dmesg` at least.
[08:09] <jml> crimsun: ok. I'll supply that soon.
[08:44] <tepsipakki> hey, according to debian bug 424975 the fglrx driver now supports xserver 1.3, could we get this in before main is frozen for tribe 1?
[08:57] <kraut> moin
[10:25] <dimon08> hi all?
[10:25] <dimon08> !
[10:26] <dimon08> why are there so many bugs in the 2.6.20-16 kernel?
[02:05] <zul> morning
[02:10] <abogani> zul: morning
[02:29] <Mithrandir> isn't the 1068 supposed to just work with feisty?
[03:39] <toad165> A question about disk buffer cache in linux kernel: Is it possible to disable them completely?
[03:42] <mjg59> Read or write?
[03:47] <toad165> to repeat the question: Is it possible to completely disable disk buffer cache in linux kernel?
 Read or write
[03:48] <mjg59> And do you mean the disk cache or the kernel cache?
[03:48] <toad165> disk cache
[03:48] <toad165> I am running kernel inside the simulator
[03:49] <toad165> and want to disable caching of the kernel
[03:49] <toad165> That is the cache of disk blocks recenly read/written
[03:49] <mjg59> Then no
[03:49] <mjg59> You can flush it
[03:50] <toad165> Okey
[03:50] <toad165> thanks
[03:50] <mjg59> With /proc/sys/vm/drop_caches
[06:23] <iwj> Anyone here who'd like to comment on a crazy crazy plan I'm concocting ?
[06:24] <iwj> It's for a weird kind of test harness.  The basic idea is to have the kernel kmalloc a huge buffer and write some trace information into it in a circular buffer style.  It would be read out later by using /dev/mem.
[06:25] <iwj> How big a piece of contiguous ram can I allocate this way ?
[06:28] <iwj> And as a not-currently-kernel-hacker how doomed am I ?  (I've done dev work on unix kernels in the past so I'm not completely ignorant)
[07:16] <iwj> https://blueprints.launchpad.net/ubuntu/+spec/full-filesystem-sanity-gutsy is the relevant spec; wiki page at https://wiki.ubuntu.com/BootLoginWithFullFilesystem.
[07:16] <iwj> I'd appreciate comments from you guys ...
[07:18] <mjg59> Hm. It's an interesting idea.
[07:19] <mjg59> I kind of wonder whether a ramfs based solution would be possible
[07:20] <mjg59> kmalloc isn't a great plan. Stuff allocated that way is unswappable.
[07:21] <mjg59> I'm also not sold on the requirement for it to be contiguous. Providing some method for dumping it out of the kernel would be easy enough
[10:42] <maks_> do you guys deploy nouveau already?
[10:44] <kylem> no.
[10:44] <kylem> airlied asked me not to because they hadn't decided to freeze their drm abi.
[10:44] <kylem> ... then fedora went and did it.
[10:46] <kylem> anyway, keeping xf86-video-nouveau and kernel driver in sync would be a massive pain in my ass.
[10:48] <maks_> ok and how is the fedora feedback?
[10:48] <kylem> no clue.
[10:49] <kylem> the thought of building the kernel modules externally and shipping them with the X driver occured to me, and i did a bit of work on it, but i don't think nouveau is ready for a deluge of user bug reports.
[10:50] <maks_> 22:51 <jima> fedora 7 shipped with nouveau, iirc, but not enabled by default.
[10:51] <maks_> so will gone unnoticed mostly
[10:51] <kylem> yeah
[10:51] <kylem> 'nv' is improving a bit recently.
[10:51] <kylem> so perhaps nvidia is trying to deflect some criticism.
[11:15] <maks_> kylem fedora says to have added sparse as build req *cool*
[11:16] <kylem> hmm. interesting.
[11:16] <kylem> linus hasn't relicensed sparse, has he?
[11:16] <maks_> would mean trouble as in debian sparse landed in non-free afair


[05:28] <infinity> IRCsloth: Still around?
[05:29] <infinity> IRCsloth: Can you try a dapper liveCD on that machine to see if it creates the device correctly?
[05:39] <IRCsloth> yeah, I'm here, just not looking at the screen
[05:40] <IRCsloth> I'll try a dapper live cd to see. Fedora core4 wasn't creating the devices for me either so I have a feeling it's a generic udev problem
[05:40] <IRCsloth> RedHat 9 however works like a charm, heh.
[06:05] <infinity> IRCsloth: I just talked to our udev guy who showed me the code in question.  We dfinitelty SHOULD be creating tape devices.
[06:10] <neuralis> infinity: did you ever find anything out about the certification exams?
[06:18] <infinity> Nothing meaninful or interesting, no.
[06:18] <nictuku> considering your experience, what would be an acceptable maximum usage for a network wide updates server, written in python, in mb?
[06:18] <nictuku> nwu, in this case
[06:19] <nictuku> maximum memory usage, I mean
[06:19] <nictuku> like, 10M, 15, 30, 100?
[06:19] <neuralis> what memory-intensive operation(s) are you performing?
[06:20] <neuralis> are you caching something? package lists?
[06:20] <nictuku> neuralis, getting relatively big list of packages and storing in a database. only temporary sqlobjects cache (should end after the thread is closed)
[06:20] <neuralis> so how would you eat up a hundred megs of memory?
[06:21] <nictuku> I mean, not in a developers POV, but in a sysadmin pov.
[06:21] <neuralis> i understand what you're asking, but i'm not sure why you're asking it. why do you think something like nwu will end up chewing up a lot of ram?
[06:21] <nictuku> what would a an admin expect for that? I'm an admin and I don't like how much memory it's using currently, like 24mb
[06:21] <nictuku> neuralis, because it's currently buggy
[06:22] <neuralis> 24mb isn't problematic at all, but it would be nice to cut it down eventually if there's no need for it.
[06:22] <nictuku> I'm fixing that, but although it won't ever use less than 10mb (python VM and all classes loaded), I wonder what would a sane target value for that.
[06:23] <neuralis> remove obvious leaks and memory holes, and then simply don't worry about it.
[06:23] <nictuku> neuralis, last week the memory usage was growing with no limit, until linux oom killer kills the process hehe
[06:23] <neuralis> yeah, leaks are bad, m'kay.
[06:23] <nictuku> ok, I think I'm getting paranoic about that
[06:24] <neuralis> no need.
[06:24] <infinity> As neuralis said, just make sure it doesn't leak.
[06:24] <infinity> Maybe try to make certain bits more efficient, if they're obviously not.
[06:24] <infinity> No one expects a python application to be "slim", however.
[06:26] <ajmitch> I'd never call apt-proxy lightweight, for example
[06:27] <nictuku> that could be a good base of comparision, btw
[06:28] <nictuku> it's using 50mb of memory in a server at work, and it's just sitting there.
[06:28] <nictuku> nwu is fine then :-)
[06:28] <neuralis> nictuku: hoare had something to say about premature optimization... kill leaks and focus on more worthwhile things like security and stability; memory use can be optimized later.
[06:32] <nictuku> it took me a month to spot and stop the leak. i'm hoping that won't happen often after this painful learning
[06:32] <nictuku> but it was fun :-)
[06:32] <ajmitch> hi fabbione
[06:32] <fabbione> morning
[06:46] <nictuku> nwu big inserts: mysql=0m12.316s, sqlite=0m49.179s. some of these in a row (although really unlikely to happen) would kill a small server IO sub-system
[06:46] <neuralis> er. what are these inserts doing?
[06:47] <nictuku> iostat shows a big write queue and usage
[06:48] <nictuku> neuralis, initial machine setup. basically packages versions and repository data
[06:49] <nictuku> oh. transactions off
[06:49] <neuralis> ok, well, it's more than likely that you're using a suboptimal schema.
[06:50] <nictuku> I wouldn't expect a good result now that I remember it's not using transactions.
[10:36] <\sh> moins
[10:36] <\sh> fabbione: actual ubunt--server amd64 daily is broken, right?
[10:37] <fabbione> \sh: dunno.. i am not on server for this release
[10:39] <\sh> well...looks like it...no di kernel modules nothing...trying flight 6 now...debian amd64 port is far from being usable...so I need a running amd64 debian distro...
[10:40] <fabbione> \sh: check the new daily. there was a kernel abi bump
[10:43] <\sh> fabbione: well...using flight6 with updates...should work
[10:43] <fabbione> yes it should
[10:44] <infinity> \sh: The seeds were out of sync, so kernels on all dailies are messed up.
[10:44] <infinity> \sh: We just fixed that, so the next round of dailies will be fine.
[10:46] <\sh> infinity: ok :) but anyhow I need to deliver some ubuntu servers for amd64 just now...so working around is better right now then to wait for the next cd build run :)
[10:46] <infinity> Yeah, just take the daily that built at the same time as Ubuntu Flight 7.
[10:46] <infinity> That one's fine.
[10:46] <infinity> Or start at Flight-6 and upgrade, if you prefer.  Whatever.
[10:47] <\sh> hmm..nice issue right now...trying to install it via ILO and after the graphic boot selection...black screen
[10:51] <\sh> infinity: just for your info: setting vga mode to 640x480x16 and then booting works...the standard setting does't work when you try to install via ILO remote console
[10:52] <\sh> will file a bug after the installation :)
[10:53] <infinity> I'd need access to an ILO-enabled machine to debug it, unless you have more info for me than "doesn't work".
[10:55] <\sh> infinity: no display but running the installer...looks like the switch from graphics mode to text mode works only in 640x480x16 mode...
[11:00] <infinity> Yeah, that's still not enough info to be useful without a machine to look at.
[11:01] <infinity> I don't suppose you know anyone who could give me access to an ILOable box for a bit?
[11:22] <\sh> infinity: sorry no...all the ILOs here are in mgmt networks which are not accessible from the outside:(
[11:26] <infinity> \sh: If you can get me access to just one at any point, I can diagnose and fix the bug, but otherwise, there's probably little point in even filing it.
[11:54] <\sh> infinity: let me try something...
[03:46] <dyn> hi
[03:47] <dyn> problem: at install time I had no network available. later on I edited /etc/network/interfaces but still '/etc/init.d/networking restart' does not pull up eth0. how can I fix this? (the box was installed in server mode so no X11/gui clients are available)
[03:47] <dyn> how can I fix that to work correctly?
[08:22] <lionelp> idimmu ?
[08:25] <idimmu> hi
[08:25] <lionelp> hi
[08:26] <lionelp> I just fill the page on the wiki: https://wiki.ubuntu.com/BinaryDriverHowto/EiconDiva
[08:26] <lionelp> You can have a look, and comment / make changes :)


[01:40] <ScottK> slangasek: Since usplash is no longer built on ia64, what would you think of removing all the binaries on ia64.  Then I can do a new kubuntu kubuntu-meta update and germinate won't try to put usplash on ia64?
[01:45] <slangasek> ScottK: acceptable
[01:45] <ScottK> slangasek: Do you want a bug for the usplach binary removal?
[01:45] <ScottK> ch/sh
[01:45] <slangasek> I don't think so
[01:46] <ScottK> slangasek: OK.  Just let me know when it's done and I'll give it a couple of publisher cycles.
[01:46] <slangasek> will do
[01:50] <slangasek> ScottK: done
[01:50] <ScottK> slangasek: Thanks.
[02:32] <slangasek> ArneGoetje: translation full export for RC starts tomorrow(today), right?
[03:00] <ArneGoetje> slangasek: Friday 22:00 UTC
[03:02] <ArneGoetje> slangasek: export will take about 24 hours, the langpack prep another 5 hours or so.
[03:22] <ice-nine> Is there a website / bug tracker listing current bugs in 9.04, and possibly status of bugs?  Reason being, I'd like to take a look at what requires fixing, and may be lend a helping hand....
[03:25] <slangasek> ArneGoetje: ok
[03:28] <slangasek> ice-nine: the list of bugs that are known targets for Ubuntu 9.04 are found at https://launchpad.net/ubuntu/jaunty/+bugs
[03:29] <ice-nine> thanks slangasek.  I'll check out that url.  Is it possible for just anyone getting involved in committing bug fixes in common apps?
[03:30] <slangasek> ice-nine: to commit fixes, you generally have to be a member of ubuntu-dev already; but we happily accept patches via Launchpad
[03:30] <persia> ice-nine, You might find https://wiki.ubuntu.com/SponsorshipProcess useful
[03:32] <ice-nine> Thanks.  I'll look into this.
[03:46] <gopogo> ubuntu jaunty jackass is  not detecting windows during installation
[03:46] <gopogo> it says no windows instaled
[03:49] <Hobbsee> gopogo: and again, #ubuntu+1
[03:52] <jdong> wow...
[04:33] <gopogo> http://www.linuxloop.com/news/2009/04/08/why-virtualbox-should-be-included-in-ubuntu/
[04:34] <persia> apt-cache show virtualbox-ose ?
[06:08] <gopogo> Jaunty -> its saying connected to wifi netework but not pigging default gateway
[06:10] <slangasek> gopogo: this is not a support channel.  I gather that you've already been directed to #ubuntu+1 several times already.
[06:13] <YokoZar> A user submitted a bug report with this failure on Wine's --configure step: Error: contents of '/etc/mailcap.new' do not match what was written -- abort
[06:13] <YokoZar> Could this possibly be the package's fault, or is something else going on here?
[06:21] <gopogo> slangasek: no body is answering ubuntu +1
[06:23] <Hobbsee> gopogo: then perhaps you shouldn't ask when it's the European & US night, and a public holiday in a lot of countries.
[06:23] <gopogo> Ohk
[06:23] <Hobbsee> channels are always quieter then ;)
[06:24] <gopogo> is there any issue in wep in jaunty jackass ?
[06:24] <gopogo> opps jackolope
[06:25] <Hobbsee> ...but the bit about support not being here still applies, i'm afraid...
[06:25] <infinity> gopogo: Rephrasing the question doesn't make it any less a support question.
[06:25] <gopogo> WEP IS NOT WORKING LOOKS LIKE BUG
[06:25] <gopogo> ;-)
[06:26] <gopogo> its was working in 8.04
[06:26] <infinity> gopogo: If you need answers RIGHT NOW, Canonical (among other companies) offer paid support.  Otherwise, please respect the (rather small set of) rules that our community support runs by, and ask in the proper channel, browse bugs to see if you find something similar, check forums, etc.
[06:27] <gopogo> i cant pay connanical
[06:27] <gopogo> i am a student
[06:28] <infinity> gopogo: Then feel free to make use of the free support that the community offers.  Just keep in mind that said free support doesn't happen here.  Please.
[06:46] <gopogo> oks
[06:46] <gopogo> where should i report this bug
[06:47] <YokoZar> ubuntu-bug (packagename) on a terminal is best
[07:09] <slangasek> superm1: is /etc/apache2/sites-available/default-mythbuntu not a conffile?  you shouldn't need to rm -f it in the maintainer script, should you?
[07:09] <superm1> slangasek, it's not a conffile, it's generated by the postinst
[07:09] <slangasek> ok
[07:24] <dschulz> hi
[07:26] <dschulz> anyone bitten by #358915  "init crashed with SIGSEGV in event_poll()"   ?
[07:26] <dschulz> running jaunty/amd64
[07:27] <dschulz> i'm looking for clues on this
[07:42] <slangasek> not that I'm aware of
[07:42] <slangasek> I'm way impressed with apport now, though
[07:51] <dschulz> slangasek: i thought the same when I first saw the bug report finished
[09:46] <deepspring> I found a bug in Python 2.6 on Ubuntu 9.04... do I discuss it here?
[09:46] <deepspring> http://ubuntuforums.org/showthread.php?p=7046504
[09:50] <persia> deepspring, #ubuntu-bugs is a better place for discussion of bugs.
[09:50] <deepspring> ok
[09:50] <deepspring> gone
[13:11] <bigon> hi, is reloading dbus after installing a .service file still necessairy in the postinst script?
[13:44] <t325> Hello, is OpenSSL considered a part of Ubuntu? If it is, where are its linkable libraries installed?
[13:45] <t325> (coming from a FreeBSD perspective -> don't know very well the "separation of powers" here)
[13:46] <persia> t325, Do you have libssl-dev installed?  dpkg -L libssl-dev would show you the relevant files in this case.
[13:47] <persia> But this isn't a support channel: for asking about aspects of packaging (like that), #ubutnu-motu is better.  For asking more general questions about Ubuntu, #ubuntu is better.
[13:47] <t325> it wasn't installed, thanks!
[13:49] <lool> slangasek: Bug #359049 > could you have a RM look and comment?  cjwatson mentionned consistency between subarches is desirable
[14:16] <lifeless> pop quiz; is there a C url library (and not 'libcurl, its an http library, not a  URL library)
[14:16] <lifeless> I want something with urljoin, urlparse etc
[14:17] <lifeless> clearly mozilla etc etc etc have to _do_ this, but I don't want to even think about linking in those monsters
[14:17] <elmo> lifeless: I think the gnome folks have a library that does that, but I forget it's name
[14:17] <lifeless> jamesh: ^
[14:17] <elmo> lifeless: oh, maybe neon?
[14:18] <elmo> lifeless: and libsoup is the gnome one
[14:18] <lifeless> ah, blink, I remmeber that from tla; libneon changed api more often than... /me stops
[14:18] <persia> And it also is an http library, rather than a URL/URI library.
[14:18] <lifeless> yah
[14:19] <lifeless> I don't mind that so much, but the focus leads to some odd apis
[14:19] <elmo> persia: well, i assumed a http library would have URL/URI functions
[14:19] <lifeless> elmo: libcurl has exactly one - 'escape' :P
[14:19] <persia> elmo, It does: it's just that the form of the request disqualified something else for supporting http :)
[14:20] <lifeless> persia: not strictly; libcurl I've already ruled out but neon may have what I want
[14:20] <lifeless> I don't want to start a liburl project for the hell of it
[14:21]  * persia finds annoying unlicensed public code that implements URL parsing functions
[14:22] <lifeless> the ne_uri_* functions are what I need. Thanks elmo, I really should have remembered this
[14:22] <lifeless> though dragging in a full http library to get it - fail
[14:23] <lifeless> bah actually no
[14:23]  * lifeless implements
[15:01] <jamesh> lifeless: there is some basic URL parsing functions in glib, but they are really basic.
[15:03] <tedg> jamesh: Is there more in gio?
[15:03] <jamesh> tedg: perhaps.  I haven't explored it much.
[15:03] <jamesh> maybe in the GFile interface
[15:04] <lifeless> tedg: I saw that it uses dbus to access backends and cried while running
[15:04] <tedg> I figured there'd have to be, but I haven't played with it either.
[15:04]  * tedg thinks bazaar should use dbus for backed support.
[15:07] <lifeless> tedg: heh. no
[15:07] <lifeless> its not that I don't like DBus, I like it fine
[15:07] <lifeless> but its IPC/RPC.
[15:07] <lifeless> not everything needs to be hit with that particular hammer.
[15:07] <tedg> lifeless: Yes, choosing the right tool for the job.
[15:08] <tedg> lifeless: BTW, were you able to get the appropriately corrupt repository downloading it from LP?
[15:08] <lifeless> now, if you have a core implementation that allows a backend to be 'I get stuff from dbus', then you can mix and match
[15:08] <tedg> lifeless: Or should I start a tarball upload for the next couple days :)
[15:09] <lifeless> tedg: To make sure I don't waste time debugging something differnet I really want a tarball of what you have on your disk
[15:09] <tedg> lifeless: Okay, do you know if there is an attachment limit in LP?  Perhaps it should go on people.u.c
[15:09] <lifeless> past midnight here, gnight
[15:09] <lifeless> whereever is fine
[15:10] <tedg> Cool, will do.  Thanks lifeless
[16:40] <crik91> hi
[16:54] <bluefoxicy> anyone know why trackerd constantly uses 100% CPU?
[17:01] <bluefoxicy> actually you know what.
[17:01] <bluefoxicy> I can find out why it uses so much CPU.
[17:01]  * bluefoxicy bash script.
[17:03] <jdong> bluefoxicy: for me right after the upgrade it required a complete rebuild of the DB which was pretty thrashy and spinny at times, after that initial chug things settled down for the most part....
[17:03] <bluefoxicy> jdong this has been happening since I upgraded, 3 days before beta.
[17:03] <bluefoxicy> and it's not playing with my hard disk a lot.
[17:03] <bluefoxicy> % time     seconds  usecs/call     calls      function
[17:03] <bluefoxicy> ------ ----------- ----------- --------- --------------------
[17:03] <bluefoxicy>  60.34   80.164781         672    119149 g_main_context_iteration
[17:03] <bluefoxicy>  24.21   32.168548         269    119150 g_main_context_pending
[17:03] <jdong> odd; sounds like an indexer is getting stuck on some sort of file type then
[17:04] <bluefoxicy> this is where most of the work is occurring but this is pretty useless
[17:04] <jdong> lol that sounds like a main event loop or something
[17:04] <bluefoxicy> yeah.
[17:04] <jdong> hmm a profiler, then?
[17:05] <bluefoxicy> what I need is an encapsulated graph
[17:05] <bluefoxicy> like, g_main_context_iteration() takes 60%.  45% of its time is in function call to some_other_function(), which spend 80% of its time in yet_another_function()...
[17:06] <bluefoxicy> and draw pretty, space-filling boxes
[17:06] <jdong> lol is it technically feasible for strace to do that?
[17:06] <bluefoxicy> (actually ltrace could be modified to do this)
[17:06] <jdong> well it probably can
[17:06] <bluefoxicy> yes, because it can say "You are in function X" "function call to Y... we were in function X.  X called Y."
[17:06] <bluefoxicy> and trace the return path.
[17:07] <jdong> well when A() waits 1s, calls B() which takes 1s, what does strace report as the time for A(), 1s or 2s?
[17:07] <bluefoxicy> it's also feasible to output a trace to a log and write a parser to process it
[17:07] <bluefoxicy> that's a good question
[17:08] <bluefoxicy> as main() doesn't encapsulate the entire life of the program, and all times add up to 100%, I'd say it counts only the time literally spent in the function body and not in sub-calls
[17:08] <sbeattie> strace is strictly syscalls, ltrace might do it, oprofile might be useful here as well.
[17:08] <jdong> yeah it makes more sense from a "useful output" point of view if it does not double-count time in encapsulated calls
[17:09] <bluefoxicy> well, regardless
[17:09] <bluefoxicy> this is a lot of useless.
[17:23] <cjwatson> robbiew,slangasek: 339898 is actually fixed, evand just forgot to close the bug
[17:23] <cjwatson> I'll close it out
[17:23] <robbiew> cjwatson: ah, ok
[17:23] <robbiew> thnx
[17:30] <davmor2> robbiew: I can confirm it is fixed :)
[17:30] <robbiew> :D
[17:31] <davmor2> robbiew: infact only outstanding obvious bug is bug 358519
[17:32] <robbiew> davmor2: ok, thanks
[17:32] <cjwatson> I'll target that, but I'm not sure we have time to fix it for jaunty
[17:32] <robbiew> agreed
[17:33] <davmor2> cjwatson: weird thing is it was working and now isn't
[17:35] <cjwatson> davmor2: in that case, it might help a bit if you could give a rough estimate of when it last worked
[17:35] <cjwatson> but I'm not working until Tuesday, so it's a bit of a stretch
[17:35] <cjwatson> (nor, I think, is Evan)
[17:36] <davmor2> cjwatson: It didn't appear in beta so after that I think I check on Monday and it was in so maybe the week before
[17:37] <davmor2> I really should learn to use grammar
[17:37] <cjwatson> punctuation too
[17:38] <davmor2> cjwatson: I am dyslexic it's hard enough to spell with out remembering other things :)
[17:38] <cjwatson> hmm, so we're talking somewhere between 26th and 30th March?
[17:38] <cjwatson> if you could put that in the bug that'd be good
[17:38] <cjwatson> davmor2: ah, fair enough :)
[17:38] <davmor2> cjwatson: will do
[17:39]  * cjwatson eyes the enormous changelog for 1.12.0, uploaded on Mon 30th Mar
[17:39] <cjwatson> sigh
[17:39] <cjwatson> could lose a goat in there, no trouble
[17:39] <davmor2> cjwatson: it would of happened before monday as it was on monday's cd
[17:40] <davmor2> ah sorry 30th
[17:40] <cjwatson> davmor2: but there were no changes between 26th and 30th
[17:41] <davmor2> just saw mon and not the 30th
[17:41] <cjwatson> I think 1.12.0 is a good guess for the version that introduced this, as that included a merge of a branch that made reasonably non-trivial changes to the KDE partitioning page
[17:42] <cjwatson> shtylman: ^- don't suppose you could look into this, as it was your branch? see bug 358519
[17:43] <davmor2> cjwatson: can you set a status on the bug so it doesn't get missed,  because currently you can't change the partition size in side by side install.
[17:44] <cjwatson> it's targeted, it won't get forgotten
[17:44] <davmor2> ah cool :)
[17:47] <ion_> All udev’s changelog entry says is “New upstream release.  LP: #358013”. It would be interesting to see that bug report, since it appears to be closed. :-)
[17:48] <jdong> haha magic words of doom :)
[17:53] <davmor2> cjwatson: I'm going to grab a copy of beta just to confirm that it wasn't in then.  I'm pretty certain I would of logged it though. But that will at least mean that you can definitely rule out pre-beta
[18:14] <shtylman> cjwatson: will do
[18:16] <cjwatson> shtylman: thanks, give me a shout if/when you have a branch for us to merge
[18:20] <jcole> didrocks: as you already may know, calendar still doesnt work in evolution-mapi and the Authentication button still crashes evo even after your latest patch...
[18:21] <jcole> didrocks: i compiled the latest openchange, samba4 and evolution-mapi from svn and everything works :)
[18:21] <didrocks> jcole: I tried to contact you
[18:21] <didrocks> jcole: evolution-mapi is the last version, contrary to what you told previously
[18:21] <jcole> didrocks: oh, im sorry, i get busy here at work sometimes
[18:22] <didrocks> I followed upstream who told me to package the last version :)
[18:22] <jcole> didrocks: you have an old libmapi0 in jaunty
[18:23] <didrocks> jcole: yes, comming from openchange
[18:23] <didrocks> not evolution-mapi :)
[18:23] <jcole> didrocks: the libmapi0 in jaunty doesnt work with the calendar
[18:23] <didrocks> jcole: as I said in the bug report, we are waiting for debian upstream packager who is working on the update and then sync
[18:23] <didrocks> jcole: I already know that ^^
[18:24] <jcole> didrocks: oh ok
[18:24] <didrocks> jcole: that's why we wait for openchange ^^
[18:24] <jcole> didrocks: do you think it will be ready before jaunty release?
[18:24] <didrocks> jcole: if it's not packaged Tuesday, can you ping me please ?
[18:24] <jcole> didrocks: you bet :)
[18:25] <didrocks> jcole: Tuesday is the deadline seb128 and I convinced to wait for debian :)
[18:25] <didrocks> (I didn't check today if they have the new version)
[18:26] <jcole> didrocks: remind you, it takes the latest samba4 to compile the latest openchange.. the samba4 currently in jaunty wont work
[18:27] <didrocks> jcole: do you have the version for the 2 packages?
[18:27] <jcole> didrocks: thanks alot for all the hard work on this, its very appreciated
[18:27] <didrocks> it will be quicker for me to check on debian ^^
[18:27] <didrocks> jcole: I know it's a waited feature, try to have it for jaunty :)
[18:27] <didrocks> s/waited/wanted
[18:27]  * jcole looks
[18:29] <jcole> didrocks: for openchange -> http://websvn.openchange.org/filedetails.php?repname=openchange&path=%2Ftrunk%2FChangeLog
[18:29] <jcole> didrocks: yesterday was last update
[18:29] <didrocks> jcole: ok, I just wondered about last official released
[18:30] <jcole> didrocks: i think they are planning to have an official release very soon
[18:30]  * jcole pings the evo devs
[18:31] <didrocks> jcole: openchange and evolution dev are the same people?
[18:31] <davmor2> cjwatson: definitely not happening in beta
[18:32] <jcole> didrocks: the openchange devs hang out in #evolution on irc gnome
[18:33] <didrocks> jcole: ok, and if you downgrade to last samba4 version, it doesn't work. Did you test it?
[18:40] <didrocks> jcole: just give a look there
[18:41] <jcole> didrocks: ill try to downgrade and see what happens
[18:41] <didrocks> jcole: thanks a lot :)
[18:41]  * didrocks hopes that jcole used /usr/local so that it will not be an headake :)
[18:42] <jcole> didrocks: /usr/local/samba
[18:43] <didrocks> jcole: perfect :)
[18:50] <lamont> gah.  how in the hell do I get firefox to STOP stealing focus when it thinks it's a good idea?
[18:51] <ion_> A window manager shouldn’t permit such behavior.
[18:52] <lamont> ion_: yeah, and then there is metacity.
[18:52] <lamont> and compiz
[18:52] <davmor2> lamont: use epiphany
[18:52] <lamont> davmor2: and this will help me how?
[18:53] <davmor2> firefox won't steal anything any more :D
[18:53] <jcole> lamont: compiz has a "Utility" called "Windows Rules" that lets you manage annoyances like that... look in compiz settings manager and scroll to the bottom
[18:55] <lamont> jcole: true.  OTOH, metacity has focus-policy == strict, which I'd really like to migrate into compiz but haven't managed to locate where, in the 10 minutes I've spent researching it over the last year
[18:55] <jcole> lamont: looks like its called "No focus"
[18:56] <lamont> srsly?
[18:56] <lamont> because upstream was completely against == strict... which has been there since I, um, coaxed.  yeah lets use that word, seb128 into adding it for me
[18:57] <jcole> lamont: http://wiki.compiz-fusion.org/WindowMatching#Window_Rules
[18:57] <jcole> lamont: heh, looks like a firefox example there
[18:58] <lamont> huh.  what do you know.  this machine actually does have an nVidia display
[18:58] <lamont> 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0640 (rev a1)
[18:58] <lamont> though it'd be nicer if it knew what it had
[18:58] <jcole> lamont: System->Administration->Hardware Drivers
[18:59] <jcole> lamont: ubuntu auto installs the nvidia driver :)
[19:01] <lamont> yeah
[19:01] <lamont> but only if you let it
[19:01] <lamont> "no proprietary drivers are in use on this system"
[19:20] <jcole> lamont: i think your modaliases might be out of date
[19:20] <jcole> $ apt-cache show nvidia-180-modaliases | grep -E '^D|^ '
[19:20] <jcole> Description: Modaliases for the NVIDIA binary X.Org driver
[19:20] <jcole>  The modaliases provide a list of pci id's which makes it possible to
[19:20] <jcole>  detect the model of a graphic card.
[19:23] <lamont> W: Unable to locate package nvidia-180-modaliases
[19:23] <lamont> so that'd be a "yes"
[19:24] <lamont> though to be fair, the machine is stuck on hardy for other reasons
[19:25] <jcole> lamont: install envy and get the latest then
[19:27] <jcole> lamont: https://wiki.edubuntu.org/EnvyNG
[19:30] <lamont> jcole: I'm still working on figuring out why I even care if I have the latest restricted driver
[19:30] <lamont> since I'm, you know, not using it.
[19:30] <ion_> keybuk: Since you wrote the udev changelog entry “New upstream release.  LP: #358013”, perhaps you could consider making LP: #358013 open for the curious public (since the bug appears to be fixed). :-)
[19:44] <jdstrand> slangasek: fyi-- uploaded new vm-builder to fix bug #342359 and bug #354849
[20:12] <calc> anyone know what happened to the coreutils info pages?
[20:13] <calc> eg info cut just gives me the manpage that has no information and tells me to use info cut for more information
[20:14] <calc> hmm info coreutils works but not info cut
[20:44]  * calc was just made aware the dictionary issue was much bigger than he thought :\
[20:45] <calc> every dictionary package has to be manually checked and updated if out of date for new OOo (gag)
[20:45]  * calc kicks OOo hard
[20:46] <calc> i thought it was a short list of ~ 5 packages i had already fixed from reading the debian bug report
[20:47] <calc> i guess i know what i will be doing this weekend :\
[21:26] <Milosz> hey people, I am packaging an application that I want to submit and I have a question regarding the control file
[21:26] <Milosz> for libcurl, there exist 2 different -dev packages, one with openssl and one with gnutls
[21:26] <Milosz> how can I specify in the control file that either is fine?
[21:27] <geofft> put a | between them
[21:28] <geofft> but it looks like both of those Provide: libcurl-dev
[21:49] <slangasek> jdstrand: "to give the loopback a devices a chance to settle down" - why is this not a call to udevadm settle?
[21:51] <jdstrand> slangasek: I was not aware of that command
[21:51] <slangasek> ah; I don't have enough context from the diff to know if it's appropriate here, but the comment suggests it might be the Right Thing
[21:52] <ScottK-palm> slangasek: I just read the release team meeting logs. AFAIK, all the Python 2.6 bugs from last week's list are still open.
[21:53] <jdstrand> slangasek: this is a simple workaround the fact that kpartx sometimes dies. it doesn't seem to with the sleep(3), and the extra tries are just to give a sporting chance at it working
[21:53] <jdstrand> slangasek: bottom line, this was a workaround that I was told to upload until soren works out the problem and the correct solution
[21:54] <slangasek> hmm, ok
[21:55] <Keybuk> settle sounds like the right workaround
[21:55] <Keybuk> "wait for /dev to catch up"
[21:55] <ScottK-palm> jdstrand: cemc found a new apparmor issue with clamav 0.95.1. I asked him to get a hold of you. It is probably the long pole in the tent for having 0.95.1 ready to upload.
[21:55] <jdstrand> ScottK-palm: yeah, already talked to him
[21:55] <ScottK-palm> jdstrand: Great. Thanks.
[21:55] <Keybuk> he eventual plan, of course, is just to have these ioctl()s block in the kernel until /dev has caught up
[21:57] <directhex> hm. /me prepares some notes on a topic he expects to hear mentioned at UDS
[21:57]  * ScottK-palm remembers he didn't say he was going yet and goes off to write a mail ...
[22:00] <jdstrand> Keybuk: your saying 'udevadm settle' is the correct thing to do for bug #342359?
[22:00] <jdstrand> Keybuk: this is the relevant errorL:
[22:00] <jdstrand> VMBuilder.exception.VMBuilderException: Process (['kpartx', '-d', '/tmp/vmbuilderID1u60/disk0.img']) returned 1. stdout: , stderr: device-mapper: remove ioctl failed: Device or resource busy
[22:02] <jdstrand> ioctl: LOOP_CLR_FD: Device or resource busy
[22:03] <Keybuk> I can't read the bug
[22:04] <Keybuk> but if you get EBUSY, that sounds like you need a settle
[22:08] <jdstrand> slangasek: honestly I'm not sure what to do wrt the bug. vm-builder is not my code and I don't know what soren wants to do long-term (ie, maybe he wants to run it on systems without udev... I have no idea)
[22:10] <slangasek> there are no Ubuntu systems without udevz
[22:10] <jdstrand> of course, but python-vm-builder is an upstream
[22:11] <jdstrand> uhhh, vm-builder
[22:11] <slangasek> fine, but the package should still be properly integrated in Ubuntu :)
[22:11] <jdstrand> I am not arguing with that :)
[22:12] <slangasek> anyway, the diff here is, I think, wrong, but it mostly addresses the symptom and shouldn't cause regressions (aside from slowing down the process), so I'll accept it
[22:13] <slangasek> please follow up with soren about doing this with udevadm settle in the future, though
[22:13] <jdstrand> ok
[22:14] <jdstrand> btw, that is 3 seconds on an (at least) 5 minute long command
[22:14] <jdstrand> but I'll follow up with him
[22:37] <slangasek> ogra: if/when you're around, I think you should go ahead with an upload for bug #358762
[23:04] <Keybuk> DRAIIIIEEEEEE
[23:06] <jdstrand> ScottK: fyi the klamav apparmor fix is in bug #359301
[23:06] <jdstrand> ScottK: due t the pending 0.95.1 upload, I have assigned it to you
[23:09] <aaronator_>  ./fwupdate.ini: line 1: syntax error near unexpected token `newline'
[23:09] <aaronator_>  ./fwupdate.ini: line 1: `<?xml version="1.0" encoding="ISO-8859-1"?>'
[23:09] <aaronator_> what is the error?
[23:24] <slangasek> aaronator_: this isn't a support channel; please see #ubuntu
[23:25] <aaronator_> thanks
[23:46] <dcomxx> hi! is it possible to somehow add the current date to the ping result and also print the errors on timeouts or not reachables to a different text file ?
[23:50] <savvas> dcomxx: date; ping www.example.com | grep -i 'string to match here'
[23:51] <savvas> dcomxx: but you might want to ask that or future questions at #ubuntu :)
[23:53] <dcomxx> what is string to match ? the error ?
[23:54] <dcomxx> and i need it to print the date for every ping not only once
[23:54] <dcomxx> or only for the errors .. so that i know when the error happened
[23:55] <dcomxx> oh yea .. grep .. but how i know what error it will be ...
[23:58] <dcomxx> can i write like this -> ping ip | grep 'error msg' | date > file.txt
[23:58] <dcomxx> ?


[00:10] <ClientAlive> Is there anywhere on my local computer or the internet to get information about window properties? Properties is probably not the right word, but what I need to find out is what the global identifiers are for things like an active window, an inactive window, a maximised window, a minimised window, and so on. Any info can give would be appreciated.
[00:11] <sarnold> ClientAlive: investigate xwininfo
[00:11] <ClientAlive> sarnold: thx. will do
[00:12] <sarnold> ClientAlive: oh! also xprop
[00:12] <ClientAlive> sarnold: Oh, that's coool...  :>
[00:13] <sbeattie> there's also xlsclients
[00:14] <sbeattie> (but xprop's attempt at ansi-text'fying an app's icon is pretty cute)
[00:15] <ClientAlive> sbeattie: no kidding
[00:17] <ClientAlive> Hey, I'm screwing around with devilspie and all/every window is opaque so it is hard to work/read. I want this, but I also need to make the active window ( whichever one happens to be active at the time ) to be solid/not opaque. To solve the immediate problem, what condition could Itest agains in order to select the active window?
[00:17] <ClientAlive> I sure sure would appreciate it.
[00:17] <ClientAlive> Then I can move along on my own
[00:19] <ClientAlive> sbeattie: ? sarnold: ?
[00:21] <ClientAlive> Problem is, I don't see that particular information with xwininfo or xprop
[00:21] <sarnold> ClientAlive: no idea, sorry
[00:21] <ClientAlive> k
[00:22] <sarnold> ClientAlive: if devilspie lets you find e.g. _NET_WM_STATE_FOCUSED in _NET_WM_STATE you might be able to match on that
[00:23] <sarnold> but I've never tried devilspie before
[00:23] <ClientAlive> sarnold: It's a start. thx
[00:26] <ClientAlive> It's test conditions seem to correspond to things like : class; xid; role; property; name; workspace   not sure what category _NET_WM_STATE would fall under ( ir any ).
[05:36] <pitti> Good morning
[05:36] <pitti> l
[05:37] <pitti> sarnold: right, the amd64 one crashed; restarted
[05:39] <mmazing> i'm looking to learn more about how the dbus system works, can anyone recommend a book/website that can help out? there doesn't seem to be much out there, im trying to break down the datetime-indicator-service but it's a bit complicated and i'm just recently jumping back into C development
[05:52] <pitti> stgraber: can I somehow convince lxc to put ephemeral overlays on /tmp/ (or another tmpfs)? putting them on the real HD makes things rather slow (aside from the HD wearout/fragmentation)
[05:55] <mmazing> answered my own question i think : package libdbusmenu-gtk-doc
[05:57] <mmazing> maybe not :\
[05:58] <pitti> mmazing: if you want to learn about the general D-BUS concepts, http://dbus.freedesktop.org/doc/dbus-tutorial.html is the place to start
[05:58] <mmazing> thanks pitti
[06:14] <sarnold> pitti: good morning :) thanks!
[06:18] <RAOF> pitti: How would you feel about having umockdev_load_from_file/string/etc return an array of udev sysfs paths rather than a boolean?
[06:23] <pitti> RAOF: well, it's not a "rather than", as the array of paths needs to become a new (out) argument; so the success flag should still stay
[06:23] <pitti> RAOF: feels API-breaky to me, but if it's particularly helpful for some use case we can certainly do it
[06:23] <pitti> it's not yet that widely used
[06:25] <RAOF> I'm not entirely sure if that's what I want, either.
[06:25] <pitti> RAOF: thanks for your pull requests, looking at them now
[06:25] <pitti> RAOF: btw, if you add NEWS entries they can be merged fully automatically
[06:26] <RAOF> pitti: Ah, let me do so then.
[06:26] <pitti> RAOF: I can add them during the merge this time, no worries (although github supports push -f just fine)
[06:31] <RAOF> I should probably make testbed_remove send "remove" uevents, too, for symmetry.
[06:32] <pitti> RAOF: I merged the DEVNAME one, and put a qestion on the uevent one
[06:33] <RAOF> Sure, I can add a test.
[06:34] <pitti> or, probably, change an existing one to ensure that the uevent is received
[06:34] <pitti> RAOF: so, for the "return sysfs paths" thing, what's your use case for that?
[06:35] <pitti> RAOF: usually you know which devices in your dump you want to work with, and if you load an unknown dump my feeling is that you usually want to use the libudev enumeration/filtering functions to find what you are looking for?
[06:36] <RAOF> I think what I want to do is ship foo.umockdev and foo.ioctl, and have a load_stuff("foo") call that loads them in, etc.
[06:37] <RAOF> I was thinking of the return sysfspath thing so that I could trigger uevents, but it's better to just get umockdev to trigger those events.
[06:37] <pitti> ah
[06:37] <pitti> yes, that's much easier then
[06:55] <pitti> mlankhorst: hey, how are you?
[06:56] <pitti> mlankhorst: can you please upload the various xserver-*-lts-{quantal,raring,saucy,trusty} metapackages to trusty soon which move people back to the normal trusty stack?
[06:56] <pitti> mlankhorst: upgrades are still broken (e. g. https://jenkins.qa.ubuntu.com/view/Trusty/view/All/job/upgrade-ubuntu-precise-trusty-desktop-lts-quantal-i386/11/artifact/results/bootstrap.log)
[07:47] <pitti> mlankhorst: I filed bug 1278737 about that and tentatively assigned it to you, IIRC you work on the enablement stacks? If not, please re-assign to someone more appropriate
[07:47] <pitti> jibel: ^ FYI (for tracking)
[08:11] <spineau> Good morning, I need someone to process a sync request for checkbox please: bug 1278747
[08:34] <dholbach> good morning
[08:37] <spineau> dholbach: Good morning, may I ask you to process a sync request (for checkbox)?
[08:38] <spineau> it's bug 1278747
[08:38] <dholbach> hi spineau
[08:39] <dholbach> spineau, I'll take a look at it in a bit
[08:39] <spineau> dholbach: thanks a lot
[08:39] <mlankhorst> pitti: yeah ok :P
[08:40] <pitti> mlankhorst: good morning; thanks!
[09:05] <Laney> @pilot in
[09:20] <mlankhorst> pitti: if you want to test, just a second
[09:20] <darkxst> Laney, Hi
[09:20] <Laney> hiya
[09:20] <darkxst> since you piloting can you take a look at gcc vanilla MP?
[09:21] <Laney> where?
[09:22] <darkxst> Laney, ubuntu-desktop branch
[09:23] <darkxst> lp:~darkxst/gnome-control-center/vanilla
[09:24] <Laney> dude
[09:24] <Laney> using gcc like that is confusing
[09:25] <Laney> but if it is what it sounds like then I might punt to robert_ancell :-)
[09:30] <mlankhorst> pitti: can you add a ppa for testing?
[09:30] <pitti> mlankhorst: yes, when doing it manually
[09:31] <mlankhorst> hold on a sec, I should be able to upload oldxorg shortly
[09:31] <infinity> Laney: On man, I absolutely thought he meant GNU Compiler Collection.
[09:32] <infinity> darkxst: g-c-c, not GCC, if you want to avoid heart attacks.
[09:32] <Laney> infinity: No need to worry, I'd have blindly sponsored it anyway. :)
[09:32] <infinity> Laney: You desktop people scare me.
[09:32] <Laney> "YOU AREN'T A CORE-DEV?" DEBSIGN DPUT
[09:33] <pitti> "it starts with g*, must be desktop"
[09:34] <mlankhorst> pitti: I copied the oldxorg pkg to ppa:canonical-x/x-staging
[09:35] <seb128> pitti, it's why the kernel is a kubuntu thing, right? ;-)
[09:35] <pitti> seb128: yeah; and you already lost one of your pets when glibc got renamed to eglibc..
[09:35] <infinity> seb128: No, we cleverly made the source package start with 'l' to avoid that.
[09:35] <Laney> edubuntu claimed that one
[09:35] <pitti> seb128: besides, lubuntu (it's linux, not kernel)
[09:36] <infinity> Also, we have too many flavours.  Somene seems to be able to claim every letter.
[09:36] <seb128> pitti, infinity: oh, right ;-)
[09:36] <rbasak> Time to invent more letters. Unicode FTW.
[09:37]  * infinity renames glibc to ☭libg.
[09:37] <Laney> μbuntu
[09:37]  * pitti registers ƃɹo˙nʇunqn
[09:38] <seb128> 可u般你他去
[09:39] <pitti> mlankhorst: thanks! I'll wait until it's built and published and then test
[09:39] <mlankhorst> it almost finished building empty files. :P
[09:39] <infinity> I really wanted to that be code-of-conduct violating.  Google Translate let me down.
[09:39] <mlankhorst> oops.. needs multi-arch: same..
[09:40] <infinity> Also, Google's "did you mean?" sugestions for Chinese are hilariously awful.
[09:40] <pitti> mlankhorst: err, does it? they are arch:all, aren't they?
[09:40] <infinity> "Did you mean: 可u盘你他去"
[09:40] <infinity> "U disk you can go to him"
[09:40] <pitti> looks exactly the same to me
[09:40] <infinity> Thanks, Google.  That's exactly what I meant.
[09:40] <mlankhorst> pitti: hm no it should be arch: amd64 i386
[09:41] <mlankhorst> because we don't want to break upgrading libgl-mesa etc
[09:41] <mlankhorst> or end up with a 32-bits xserver on amd64! :D
[09:52] <tvoss> pitti, https://code.launchpad.net/~thomas-voss/process-cpp/add_death_observer_for_child_processes/+merge/204629
[10:06] <mlankhorst> pitti: ok pushed, can you check if it works? also can you check if /usr/lib/xorg/protocol.txt exists after upgrading?
[10:11] <pitti> mlankhorst: yes, as soon as it gets published
[10:18] <pitti> mlankhorst: are the other packages in that PPA "safe" for an upgrade test?
[10:22] <mlankhorst> they won't explode or anything
[10:23] <mlankhorst> they were from the original xorg 1.15 test rebuild, left in because version is still newer, so someone can ppa-purge them :p
[10:53] <pitti> mlankhorst: will still take a bit; I killed the test machine during the test dist-upgrade :/
[10:53] <pitti> on heavy I/O with containers wazn sometimes just dies
[10:54] <mlankhorst> !!
[10:55] <pitti> mlankhorst: (not your fault at all, just keeping you posted why you don't get a response from me)
[11:03] <apachelogger> pitti: bug 1278820 might be intersting, or at the very least it seems a bit odd ^^
[11:04] <pitti> DEBUG:root:X.org log reports loaded intel driver, disabling driver nvidia-173 for hybrid system
[11:04] <pitti> apachelogger: that's deliberate ATM, I'm afraid
[11:04] <apachelogger> ok
[11:04] <pitti> at least when we wrote that check, we couldn't use the intel and nvidia drivers in parallel
[11:04] <pitti> so you'd have to disable the intel card in the bios if you want to use the nvidia one
[11:05] <apachelogger> pitti: seems to work right now though
[11:05] <apachelogger> or at least the nvidia module is loaded and GL lists nvidia as vendor
[11:06] <pitti> apachelogger: you manually installed the nvidia driver?
[11:06] <pitti> apachelogger: yes, that'll kill the intel driver as well, and shoudl then display it
[11:07] <apachelogger> pitti: maybe, the system was upgraded from saucy, so I might have manually installed it back then
[11:10] <apachelogger> oh
[11:10] <apachelogger> pitti: jockey lists the drivers, so since we used jockey in saucy still I guess I used that to install it
[11:11] <pitti> apachelogger: hm, we had a similar check in jockey
[11:12] <apachelogger> pitti: http://i.imgur.com/1S7h2oh.png
[11:14] <pitti> apachelogger: apparently that's when you already have one installed, so your X.org isn't using intel any more, right?
[11:17] <apachelogger> pitti: yeah, xorg.0.log is attached to the bug
[11:23] <tseliot> apachelogger, pitti: that will be fixed in trusty soon
[11:24] <pitti> tseliot: oh, nice! how will that work, does the nvidia driver use the mesa libGL now?
[11:26] <tseliot> pitti: I'm working on a program that will deal with the different GPUs and take care of the required changes (in this specific case, it will tell X to use the nvidia card if nvidia is installed). This program will run on boot and also detect any hardware changes, for example when users add a new card or swap an nvidia card with an amd card, etc.
[11:27] <tseliot> this will replace the hybrid-detect program in ubuntu-drivers-common
[11:27] <tseliot> the new program is still written in C
[11:28] <apachelogger> neat
[11:35] <pitti> mlankhorst: hm, it seems that our trusty linux-meta already builds metapackages for linux*-lts-saucy, but not for quantal/raring/trusty, and not for xorg*
[11:39] <mlankhorst> pitti: yeah linux does their own thing :)
[11:40] <pitti> mlankhorst: so should linux-meta also build those for quantal, raring, and trusty?
[11:40] <mlankhorst> ask the kernel team
[11:40] <mlankhorst> I can't predict the future so I don't handle lts-trusty yet in my packaging
[11:41] <pitti> apw: so linux-meta builds transitional packages for -lts-saucy; it should also build them for lts-{quantal,raring}, and presumably for lts-trusty as well (as we already know we are going to do it, right?)
[11:41] <pitti> apw: want a bug for that?
[11:43] <pitti> apw: err, wait; they are built, but apt-cache search lts-raring spectacularly fails to find them
[11:43] <pitti> apw: so nevermind, sorry for the noise
[11:45] <pitti> apt-cache search lts-saucy works just fine, curiously
[12:05] <apw> pitti, yeah i am pretty sure we have about 100 transitional packages :)  perhaps they are in different sections from each other or something
[12:12] <pitti> mlankhorst: followed up to bug 1278737
[12:37] <mlankhorst> yeah
[12:59] <mlankhorst> pitti: oh right, libxatracker1 -> libxatracker2
[13:11] <mardy> cjwatson: hi! When you have some time, can you tell me if the approach is right? https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674
[13:11] <mardy> cjwatson: once you confirm it's OK, I'll fix the documentation
[13:13] <cjwatson> mardy: I think it's OK, yes, although FWIW I find it easier to decide whether I like the approach given the documentation :-)
[13:13] <cjwatson> mardy: (I usually write documentation for this kind of thing before I write the code)
[13:14] <cjwatson> mardy: Sorry, I've been buried in 12.04.4 and then a complex series of customer bugs for the last couple of weeks
[13:15] <mlankhorst> I could swear you said you wouldn't do another release after 12.04.2 iirc ;)
[13:15] <mardy> cjwatson: OK, then I will :-)
[13:17] <cjwatson> mlankhorst: Yeah, I think I got voluntold
[13:17] <cjwatson> 12.04.2 was awful
[13:18] <mlankhorst> 12.04.5 is going to be bad too, need to backport dri3 support ;)
[13:19] <mlankhorst> I think you should practice saying '123 NOT ME' faster this time.
[13:32] <xnox> mlankhorst: cjwatson: should things generally depend directly on libgl1-mesa-dri or should it be expected to be handled as a hardware specific thing and something should pull the right one in (either seed or ubuntu-drivers-common)?
[13:33] <xnox> mlankhorst: cjwatson: i see that qtdeclarative5-qtquick2-plugin and libgbm1 depend on libgl1-mesa-dri and thus end up pulling nvidia & radion dri onto ubuntu-touch seeds which seems pointless, as hybris is used.
[13:34] <mlankhorst> depend on libgl1-mesa-dri  | libgl1
[13:35] <mlankhorst> and include libhybris first so libgl1-mesa-dri doesn't end up being installed
[13:35] <xnox> mlankhorst: excellent! let me see if i can make this work.
[13:35] <pitti> mlankhorst: oh, you mean libxatracker1-lts-saucy actually ought to move people to libxatracker2, not to libxatracker1?
[13:36] <mlankhorst> yeah or do nothing, but i moved it to 2
[13:38] <tseliot> davmor2: mlankhorst fixed your problem in xorg-server (2:1.15.0-1ubuntu4). Let us know if you're still able to reproduce the problem with the new update
[13:39] <tseliot> davmor2: you shouldn't be ;)
[13:39] <davmor2> tseliot: thanks I'll grab the update and do a few reboot tests latter then
[13:40] <tseliot> thanks
[13:40] <mlankhorst> should be impossible really
[13:41] <tseliot> too bad, using intel as a source and a sink at the same time was fun :P
[13:43] <cjwatson> mlankhorst: I should be able to at least avoid doing two in a row
[13:48] <mlankhorst> or should you?!
[13:54] <Laney> @pilot out
[13:56] <mlankhorst> pitti: ah right, libglamor-ltss0 conflicts with libglamor0
[13:57] <mlankhorst> incorrectly, but still, I guess I'll need to transition that too
[14:08] <diwic> hmm, what happened to the right mouse button in trusty? Button positions seem to have recently switched
[14:18] <tjaalton> clickpad?
[14:18] <diwic> tjaalton, no, a five button USB mouse
[14:19] <tjaalton> i have a 10+ button mouse and it seems to work like before :)
[14:20] <soren> tjaalton: 10+ button mouse?
[14:20] <tjaalton> ok, 11
[14:20] <diwic> tjaalton, okay...I wonder what happened to this one then?
[14:20] <soren> tjaalton: pics or it didn't happen.
[14:20] <tjaalton> soren: if you count the scroll wheel as three
[14:20] <tjaalton> logitech mx revolution
[14:21] <diwic> tjaalton, ok, mine is seven buttons if you count the scroll wheel as three
[14:21] <soren> tjaalton: That's crazy.
[14:21] <tjaalton> mine has a "wheel" for thumb too
[14:21] <soren> I don't even have a mouse.
[14:21] <tjaalton> hehe
[14:22] <diwic> tjaalton, so what used to be the "popup menu" button now seems to do "open in new tab" in nautilus
[14:22] <diwic> tjaalton, and the popup menu button is now what used to be back button in firefox
[14:23] <tjaalton> diwic: what does xev show
[14:23] <diwic> hmm, and the forward button in firefox is now the back button
[14:23] <tjaalton> or xinput test-xi2
[14:25] <tjaalton> diwic: maybe try an earlier kernel to be sure
[14:25] <tjaalton> the mappings/quirks are there
[14:25] <diwic> tjaalton, hmm, both the scroll wheel button and the second button is now numbered 2
[14:26] <diwic> tjaalton, I bet that's not the case on 12.04
[14:26] <tjaalton> what isn't?
[14:29] <diwic> tjaalton, booting a 3.12 kernel has the same results, so I think it's somewhere else in the stack
[14:29] <tjaalton> you don't have any special xorg.conf then?
[14:29] <diwic> tjaalton, if I press the buttons in order, I end up with: 1, 2, 2, 3, 8.
[14:31] <diwic> tjaalton, whereas in 12.04 I end up with: 1, 2, 3, 8, 9
[14:32] <diwic> tjaalton, not that I'm aware of, where should I look for one?
[14:33] <diwic> there's no /etc/X11/xorg.conf
[14:34] <tjaalton> ok
[14:34] <tjaalton> so you haven't used any release in between?
[14:35] <tjaalton> try the guest session too
[14:36] <diwic> xmodmap -pp shows "13 buttons" and a straight mapping.
[14:36] <diwic> I booted my laptop with saucy, it works fine there.
[14:36] <tjaalton> k
[14:37] <diwic> tjaalton, guest session on trusty desktop = buggy
[14:37] <tjaalton> what mouse is it btw?
[14:37] <doko> jamespage, https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1278897
[14:37] <diwic> tjaalton, Evoluent Verticalmouse 3
[14:38] <jamespage> doko, ta
[14:39] <tjaalton> diwic: ah, well a quick google shows it has needed special mappings..
[14:39] <tjaalton> so dunno
[14:41] <diwic> tjaalton, !! it is in 10-quirks.conf
[14:43] <diwic> tjaalton, that is just...stupid. I liked it the way it was. Can I override it?
[14:44] <diwic> tjaalton, without changing a system file that will be overwritten on upgrade?
[14:44] <spineau> mterry: hello, I promise this is the last mir bug for checkbox, this one is very similar to the other plainbox provider package, just code relocation: bug 1278822
[14:44] <tjaalton> diwic: yes, put something in /etc/X11/xorg.conf or .d
[14:46] <mterry> spineau, OK
[14:46] <diwic> tjaalton, it works, thanks for saving my day! :-) And my fingers
[14:46] <tjaalton> yw
[14:47] <tjaalton> didn't know that got added upstream
[14:51] <jamespage> doko, is that 12.04 ->14.04?
[14:52] <doko> jamespage, no, that had 11.04 or 11.10
[14:55] <stgraber> pitti: what are you using? lxc-start-ephemeral or lxc-clone -B overlayfs?
[14:55] <pitti> stgraber: start-ephemeral
[14:55] <stgraber> pitti: start-ephemeral should be tmpfs by default
[14:55] <pitti> stgraber: ah, does the  clone -B one allow that?
[14:55] <stgraber> pitti: unless you manually pass -k (keep data) or set the storage type to dir instead of tmpfs
[14:56] <pitti> stgraber: this morning I had a temporary (trusty-jf923blabla) one laying around from a few days ago, and I reboot every day
[14:56] <pitti> stgraber: and I could still start it, so it was there still
[14:56] <stgraber> pitti: did it actually contain any data in /var/lib/lxc/<container>/delta0?
[14:56] <stgraber> pitti: the container definition itself is on disk but the overlay is location (delta0) is a tmpfs by default
[14:57] <stgraber> (unless you pass -k or --storage-type dir)
[14:57] <pitti> stgraber: hm, not sure, I removed it already; I'll re-create that situation and investigate
[14:57] <pitti> stgraber: so /delta0 is the tmpfs mount point?
[14:58] <pitti> stgraber: i. e. the container started alright, but it was like its pristine template, without the delta?
[14:58] <stgraber> right
[14:59] <stgraber> pitti: I just tried here with a new ephemeral container, did some changes and confirmed that none of that is committed to /var/lib/lxc/<container name>/delta0 (which remains empty at all time)
[14:59] <stgraber> it's just a bit tricky to see as the tmpfs is mounted by an lxc hook and is therefore not visible from either the host nor the container
[14:59] <pitti> right
[14:59] <pitti> stgraber: ok, so that was probably it; thanks!
[15:00] <stgraber> np
[15:37] <mlankhorst> pitti: I tested lts-saucy, that one should work, multiarch'd too
[15:51] <jamespage> doko, afaict dovecot's never actually used the snakeoil certs...
[15:51] <jamespage> bah
[15:52] <doko> ohh :-/
[15:53] <bdmurray> doko: I guess doxygen is still using tmake?  I was looking at bug 1196347.
[15:54] <bdmurray> doko: you'd mentioned they were moving to qmake
[15:55] <doko> bdmurray, yes, no change yet
[15:55] <jamespage> doko, yeah - looks like it generates one instead in 12.04 at least
[15:57] <pitti> mlankhorst: ah, splendid; btw, could you rename "oldxorg" to perhaps "xorg-lts-transitional" or so?
[15:59] <tvoss> sil2100, around?
[15:59] <mlankhorst> pitti: are the other ones tested too
[16:00] <pitti> mlankhorst: I can do that now
[16:00] <pitti> mlankhorst: with simulation, but that should be good enough for now
[16:01] <mlankhorst> simulation is fine
[16:17] <pitti> mlankhorst: done, and followed up to the bug
[16:17] <pitti> mlankhorst: so mostly good now, except for that weird geode thing
[16:17] <seb128> doko, can you get a mp with your gnome-control-center-signon changes up? your direct landing is conflicting with a CI landing that is waiting for some days
[16:18] <mlankhorst> pitti: geode is i386 only
[16:18] <pitti> mlankhorst: right, it's just weird that the upgrade says that it's holding it back
[16:18] <pitti> mlankhorst: those three tests were on amd64, doing i386 now
[16:19] <seb128> sil2100, doko just uploaded http://launchpadlibrarian.net/165639698/gnome-control-center-signon_0.1.7~%2B14.04.20131126.2-0ubuntu1_0.1.7~%2B14.04.20131126.2-0ubuntu2.diff.gz ... can we overwrite it with the planned landing?
[16:19] <pitti> mlankhorst: it's like some metapackage now wants to pull in the geode:i386 package for the upgrade
[16:19] <mlankhorst> odd :/
[16:19] <doko> sil2100, well, not override, but just merge the patch
[16:20] <mlankhorst> pitti: well I'm not respecting m-a for all original packages, probably something like that causing it
[16:21] <doko> seb128, is there any reason to hard-code the list of architectures?
[16:21] <pitti> mlankhorst: i386 is fine (also just said that in the bug)
[16:22] <pitti> mlankhorst: many thanks! can you perhaps just rename this, and then get it uploaded? (I can sponsor if you need)
[16:23] <seb128> doko, I don't remember the details, would need to ask didrocks, the issue happened when that package got ported from qt4 to qt5
[16:23] <seb128> doko, it stopped being buildable on e.g ppc since qtdeclarative is not available there
[16:23] <mlankhorst> pitti: you shouldn't install a i386 geode on amd64
[16:23] <pitti> mlankhorst: well, I didn't
[16:23] <mlankhorst> hm :p
[16:23] <pitti> mlankhorst: that's the point -- the upgrade apparenlty tried to install it (through some new dependency), and then holds it back
[16:24] <mlankhorst> would need a full log
[16:24] <mlankhorst> to see why it tries to install it
[16:24] <doko> seb128, sure, it would show up as a dep-wait or a ftbfs, but that would be preferred to limiting the set of archs
[16:24] <doko> same here: https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1278953
[16:24] <seb128> doko, I don't remember the details, britney didn't like the fact that it built before on those archs and was depwaiting after
[16:25] <seb128> doko, well, anyway, please submit a mp to the vcs with your changes
[16:26] <seb128> doko, you just screwed a planned landing by not follow the process
[16:29] <pitti> mlankhorst: attached (although I can't really see from it what's pulling it in)
[16:30] <mlankhorst> maybe video-all:i386
[16:30] <mlankhorst> I'm guessing xserver-xorg*) needs to be m-a foreign
[16:30] <xnox> seb128: "doko, I don't remember the details, britney didn't like the fact that it built before on those archs and was depwaiting after" when that happens, typically one should ask archive admin to remove binaries of the removed architectures from -release pocket.
[16:30] <pitti> mlankhorst: but *shrug*, good enough for the first iteration :)
[16:31] <mlankhorst> pitti: without even looking at the log I'll give that a shot
[16:31] <xnox> seb128: otherwise to britney it does look like: mipsel binary in -release, no mipsel binary in -proposed. *regression*
[16:31] <seb128> xnox, right, but those debs had still rdepends, and Colin didn't want to go for brutal deleting
[16:31] <seb128> xnox, I don't remember the details
[16:31] <cjwatson> eh wut?
[16:31] <seb128> that was blocking things
[16:31] <cjwatson> which packages?
[16:32] <seb128> cjwatson, http://launchpadlibrarian.net/143379896/gnome-control-center-signon_0.1.7~daily13.06.18-0ubuntu1_0.1.7~%2B13.10.20130625-0ubuntu1.diff.gz
[16:32] <cjwatson> I'm pretty sure I tore out bits of the signon stack before, bit surprised to hear my name invoked as a blocker ...
[16:32] <seb128> cjwatson, at the time it did qt4 -> qt5
[16:32] <seb128> it was a bit of a mess
[16:32] <seb128> but I don't remember the specifics of the situation
[16:32] <cjwatson> right, I think that was a change I requested
[16:32] <seb128> cjwatson, oh, you are not named as a blocker
[16:32] <seb128> cjwatson, I'm trying to remember why we did that change by then
[16:32] <cjwatson> doko: I'm pretty sure that limiting the set of arches was necessary there, as otherwise it built binaries that were uninstallable
[16:32] <seb128> doko was asking why it was made
[16:33] <cjwatson> doko: the right answer is to leave it alone for now and wait for Qt 5.2
[16:33] <doko> cjwatson, hmm, ok
[16:33] <cjwatson> 5.2 will (should?) give us a working qtscript everywhere and then we can stop worrying about this
[16:34] <cjwatson> and I gather that's pretty close
[16:34] <cjwatson> I hate explicit architecture lists as much as you do - it was a last resort
[16:35] <seb128> that's my understanding as well, qt5.2 should resolve those issues
[16:36] <cjwatson> basically once we have 5.2 I was going to crawl back up the stack and look for hacks that can be undone
[16:38] <xnox> barry: you could nuke the .py files and only leave python3.3 bytecode =)))))
[16:38] <xnox> barry: and have a custom pyupdate which uses .py files not from a public location.
[16:39] <barry> xnox: heh, yeah, probably fails the "easy" test but that's a possibility ;)
[16:40] <xnox> barry: i guess you can't drop invalid 3.4 bytecode? since python will invalidate it and import .py file instead?
[16:40] <barry> correct.  if the .py is available but __pycache__ isn't writable, then it will just run off the .py files, and you'll pay the compilation cost everytime
[16:41] <xnox> barry: why not take your patch and apply it in debian/ubuntu? or does it have side-effects?
[16:41] <xnox> barry: it's not uncommon for debian/ubuntu to patch support in ahead of upstreams...
[16:41] <doko> does genshi ship any binaries?
[16:42] <barry> xnox: which patch do you mean?  the one that prevents import, or the fix to genshi for 3.4?  i don't have the latter (and neither does upstream, it's not trivial)
[16:42] <doko> are there any rdeps?
[16:43] <xnox> doko: i think it's mostly used as a library, e.g. django can be made to use genshi templates and thus call into genshi on each request to generate .html.
[16:43] <xnox> doko: ditto other web-frameworks/webapps of the day.
[16:43] <xnox> doko: there are no, pyhon3-genshi reverse depends at the moment.
[16:44] <barry> doko: if you mean executables, no.  there is an optional .so for speedups, but it's only compatible with python2 (there's another unresolved upstream ticket for that)
[16:44] <xnox> barry: why not simply ship the module into /usr/lib/python3.3 and be done with it?
[16:44] <doko> xnox, no. would be /usr/lib/python3.3/dist-packages, and we don't have this one yet
[16:45] <doko> I like the import error much more
[16:46] <barry> doko: me too. as icky as it may be, it more or less mimics what you'd see if it wasn't installed for 3.4, so probably "good enough"
[16:50] <xnox> doko: =/ i see, and it doesn't make sense to create one just because of genshi.
[16:51] <xnox> just like with 2.5, will 3.5 be the release that will act like a barrier?! =)
[16:51] <mlankhorst> pitti: ok uploading ppa6, can you give it a shot when it finshed?
[16:53] <mlankhorst> I killed off the m-a same for everything except a few packages
[16:56] <barry> xnox: huh?
[16:57] <xnox> barry: a lot of projects struggled to move to 2.5, or choose not to. and later 2.5 projects didn't move to 2.7, at times getting 2.7 support together with 3.0 one.
[16:58] <xnox> maybe it's just my impression.
[16:58] <xnox> as in maybe around 3.5 time, genshi like problems will be widespread enough, to warrant /usr/lib/python3.x/dist-packages
[16:59] <cjwatson> I think chose not to was more common; 2.4 support seemed quite sticky
[16:59] <xnox> as in maybe around 3.5 time, genshi like problems will be widespread enough, to warrant /usr/lib/python3.x/dist-packages
[17:00]  * xnox -Efocus-follow-eye-sight
[17:00] <barry> xnox: genshi's failure is rather unique actually because it depends on the AST, which doesn't have a guaranteed stable API.
[17:01] <barry> so it probably breaks with every release (that's what you get for depending on a library documented to not be stable ;)
[17:02] <barry> one of the topics for the language summit in montreal pycon2014 will be the 3.5 release.  a strong possibility is a shorter dev cycle specifically focused on improving porting from python 2, with very limited feature set otherwise
[17:03] <barry> (something i actually favor, in the abstract ;)
[17:05] <barry> tedg: hi.  i was wondering if you could comment on LP: #1278582 and LP: #1278511.  they (and especially the former for me) are causing lots of pain for emacs users.  they seem to be recent regressions
[17:06] <tedg> barry, Hmm, seems seb128 just set it to fix committed :-)
[17:06] <seb128> tedg, barry: yeah, commenting on both
[17:06] <tedg> barry, In general that's probably a bregma thing though.
[17:07] <seb128> it's a "we need unity trunk to land in trusty, one day"
[17:07] <bregma> one day soon
[17:07] <seb128> tedg, barry: you can access it by running gnome-control-center.real
[17:07] <seb128> or http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3643
[17:08] <barry> seb128: oh wow.  why doesn't .real run when you hit the gear->System Settings? :)
[17:08] <seb128> barry, you get unity-control-center (our new default UI)
[17:09] <barry> seb128: ah, and this setting hasn't been added to u-c-c yet?
[17:09] <seb128> barry, the Unity xml is missing because unity didn't get a landing for ages
[17:09] <seb128> cf the commit I just pointed
[17:09] <seb128> it's fixed in trunk
[17:09] <seb128> but bregma's ass has been kicked by unity autopilot tests recently it seems
[17:09] <seb128> those guys didn't manage to do a landing for ages
[17:09] <barry> seb128: awesome, thanks.  i will try .real and wait for the fix-released there
[17:10] <seb128> yw!
[17:10] <seb128> barry, the other one should be an ibus issue, please try if unsetting in ibus-setup fixes it
[17:11] <barry> seb128: yeah, i actually uninstalled ibus ;)
[17:11] <bregma> we're spending more time fixing bugs in autopilot itself than in unity
[17:11] <seb128> bregma, :-(
[17:12] <seb128> bregma, are those regressions in autopilot? can't we just back out the buggy version?
[17:12] <barry> seb128: however, on LP: #1278582 i don't actually think it's fixed.  .real shows me "Key to show the HUD" as disabled, and yet both Alts still bring up the search dialog.  if in the settings panel, i hit alt-right or super, the key settings just reverts to "diabled".  but i don't think it's actually disabled!  maybe the search dialog is different than "Key to show the HUD"?
[17:13] <bregma> 40 new regressions due to #1278917
[17:13] <barry> bregma: yeah, i am struggling with autopilot failures all over the place :/
[17:14] <seb128> barry, well, the issue that bug describes "don't list keybindings" is fixed, not sure about the hud key not working as it should...
[17:14] <barry> seb128: fair enough.  i suppose i should open a new bug on that issue.  would that be on unity then?
[17:14] <seb128> yes and yes
[17:15] <barry> seb128: cool, thanks!
[17:15] <seb128> yw!
[17:27] <barry> seb128: LP: #1278985  - please let me know if my explanation was unclear or
[17:27] <barry> *unclear (no or :)
[17:30] <seb128> barry, seems clear, I can't confirm/reproduce though
[17:30] <brendand> barry, is that Alt+ something, or Alt, then something?
[17:30] <seb128> changing the keybinding works fine for me
[17:30] <samertm> barry: does that bug only appear in trusty?
[17:32] <rbasak> doko: for bug 1243076, the conclusion is to drop the package, unless you object? It seems that nobody has ported the code itself to Apache 2.4's new API.
[17:32] <rbasak> (and upstream and Debian are inactive)
[17:32]  * rbasak doesn't see any rdepends
[17:33] <barry> brendand: it's all muscle memory, but it seems to be roughly "press alt then quickly press f next' (of course, not just f - any key will do)
[17:33] <barry> brendand: although if i'm *really* careful i can press them both at the same time, and the same behavior is exhibited
[17:33] <barry> samertm: a very recent dist-upgrade of trusty, i.e. as of yesterday.  last week it all worked fine
[17:34] <barry> seb128: you're changing the keybinding via g-c-c.real?
[17:34] <seb128> barry, yes
[17:34] <samertm> barry: kk, thanks for the info
[17:35] <brendand> barry, but it doesn't work if held down?
[17:35] <brendand> barry, i.e. hold alt and press 'f' with other finger
[17:36] <barry> seb128: so, to be clear, if you open Keyboard->Shortcuts, click on "Key to show the HUD" and tap Super, you see it set to Super?  for me it just reverts to Disabled
[17:36] <seb128> barry, let me try with super, I tried "backspace" which set it to "disabled" which works
[17:37] <seb128> barry, super is the key used by the dash
[17:37] <seb128> that doesn't work
[17:37] <barry> brendand: correct.  hit and hold Alt for a few seconds, then tap 'f'.  the app with focus will *not* see the event
[17:37] <barry> seb128: what about right-alt?
[17:37] <seb128> that's the default key
[17:37] <seb128> oh, right alt
[17:37] <brendand> barry, but that works for me in e.g. chromium
[17:38] <barry> seb128: yes, it wouldn't be so disruptive if it was right-alt only (i personally use left-alt all the time for "alt")
[17:38] <seb128> barry, that doesn't work, right ctrl works, win key works
[17:38] <seb128> the menu key works
[17:39] <barry> seb128: i don't have any of those keys on this keyboard ;)  (no right control, menu, or win)
[17:39] <barry> i have right alt and right super though
[17:39] <seb128> barry, is disabled with backspace working?
[17:39] <barry> brendand: like, what key combination exactly?
[17:40] <barry> seb128: that's hard to tell, because Key to show the HUD is already "Disabled".  but hitting backspace/delete does still leave it disabled
[17:40] <brendand> barry, hold down left-alt and press f
[17:41] <seb128> barry, what is you pick any random key, e.g f8
[17:42] <barry> seb128: but i can set it to Super+Right and that does "work" in the sense that the shotcut is displayed that way.  and indeed, with show hud set to Super+Right, alt is not captured
[17:42] <seb128> ok
[17:42] <seb128> so dunno why right-alt doesn't work, likely an xkeyboard-config issue
[17:42] <seb128> you just need to find a key that exists on your keyboard and suits you
[17:43] <barry> brendand, seb128 so, setting it to Super+Right and *then* setting it back explicitly to Disabled (via backspace) defeats the capture too it seems
[17:43] <mlankhorst> pitti: if you feel like testing, I uploaded xorg-lts-transitional now
[17:43] <mlankhorst> should fix your geode issue
[17:43] <pitti> mlankhorst: oh, sweet, thanks
[17:44] <pitti> mlankhorst: I need to wrap up for today, will do it tomorrow morning
[17:44] <barry> seb128, brendand thanks.  i will update the bug, but now the pain is gone :)
[17:46] <seb128> barry, yw
[17:50] <rbasak> doko: I've filed bug 1278995
[18:18] <mdeslaur> xnox: if you do make a separate package for the two codecs, could you not name it with "bad" in the name? :)
[18:19] <mdeslaur> shipping a package called "bad" or "ugly" by default on devices doesn't sound too appealing :)
[18:19] <xnox> mdeslaur: it was going to be either inside the hybris package, or hybris-extra, or bad-subset.
[18:20] <mdeslaur> xnox: those two don't pull libav in, right?
[18:20] <xnox> mdeslaur: i think we are barred from shipping bad/ugly on default media, anyway... but i'm not going to get into that discussion.
[18:20] <xnox> mdeslaur: correct, they do not pull in libav, opecv / colorprint and a few other pieces however do.
[18:20] <xnox> mdeslaur: hence i want to drop them.
[18:20] <mdeslaur> ok, good
[18:21] <xnox> mdeslaur: i think we will still be linking to libstreamerparsersbad though, and that's library name....
[18:21] <xnox> so bad strings are here to stay =)
[18:21] <mdeslaur> meh, was just a suggestion :)
[18:21] <mdeslaur> bad-dog-bad-bad-no
[18:23]  * xnox "but, i just met you, and i already like you....." gosh, "Up" was a good movie!
[18:23] <Laney> umm
[18:37] <Laney> xnox: I'd prefer doing genuine splits rather than stuffing things into weird packages
[18:37] <Laney> please talk to Debian about it ...
[18:47] <Laney> but if they don't go for it, the normal split still feels right to me
[19:24] <vp7> is Ubuntu community participating in GSOC this year.
[22:31] <ScottK> Mirv: Do you know when Qt 5.2 is finally going to land?
[22:56] <hallyn> stgraber: thouhts on bug 1248283  (last few comments)?
[22:56] <hallyn> i should retitle that bug...  it's purely a dbus bug, not juju
[22:57] <xnox> ScottK: i spoke with Mirv about it last week, and there were still a few savere regressions on touch (e.g. screen doesn't unlock, unless one disables powerd before screen autolocks for the first time)
[22:57] <hallyn> there that's better
[22:57] <hallyn> bug 1248283
[22:57] <xnox> ScottK: =/
[22:58] <ScottK> xnox: I think our process is now fundamentally broken when it's apparently impossible to update libraries in the development release.
[22:59] <stgraber> hallyn: it's not really a bug because "restart networking" isn't supported, we just don't have a good way to prevent it. The supported way to bounce the network is "ifdown -a && do config changes && ifup -a" or the same but just for the interfaces you are changing.
[22:59] <xnox> ScottK: i agree. in the mean time i'm writting Qt patches against 5.3... which i'll then have to backport to 5.2, 5.0 and 4.8 by the looks of things.
[22:59] <stgraber> hallyn: we had a chat about this during the Core Sprint and the CTS folks said they'd make sure our documentation covers this properly (I sent a bunch of patches a while back to get rid of the worst cases)
[22:59] <hallyn> stgraber: oh that again :)
[23:00] <ScottK> Please not 4.8.
[23:00] <xnox> stgraber: if we make networking an instance job (with a default instance whatever, it will be a single one) then "restart networking" will do nothing.
[23:00] <stgraber> hallyn: "deconfiguring-network" is usually meant as "the system is going down, services should now die, please all exit because the fs is about to go away"
[23:01] <xnox> stgraber: or better, make it a task =) such that "restart networking" does no harm, or at least doesn't emit deconfiguring-network. What do you think?
[23:02] <stgraber> xnox: well, we need a started and stopped state because things unfortunately depend on this...
[23:02] <stgraber> xnox: and it needs to match name with the sysvinit job so services vaguely does the right thing
[23:02] <hallyn> stgraber: ok, so you would claim the bug is in juju or juju charms for using restart networking?
[23:03] <stgraber> hallyn: absolutely, nobody should even do restart networking
[23:03] <stgraber> *ever
[23:03] <hallyn> stgraber: I wonder if we did a poll, how many ppl would knwo that :)
[23:03] <stgraber> because it'll almost certainly always do everything but what you want it to do :)
[23:03] <hallyn> stgraber: thanks, i'll follow up in the bug
[23:04] <stgraber> well, eveyrone who used it at some point probably had problems and either filed a bug which I'd have closed as invalid/won't fix or they'd have found one of the hundred of places where I tried to explain this :)
[23:05] <stgraber> hallyn: most people using restart networking also forget that ifupdown isn't stateful, so if your interface was DHCP and you change it to static, then restart networking, this won't kill dhclient so 30min later your IP gets overriden by dhclient
[23:05] <sarnold> "oh I know I'll just restart networking, that'll do everything" --> "hunh, why is my system suddenly useless?"
[23:05] <stgraber> hallyn: hence which you're supposed to ifdown => change config => ifup
[23:05] <hallyn> i still have issues with that, but won't argue them now :)
[23:05] <stgraber> *why
[23:06] <hallyn> hm, but i can't figure out where it's being done.  maas and juju dont' seem to do it
[23:07] <stgraber> hallyn: from instance userdata apparently
[23:07] <stgraber> at least that's what they show in the bug description
[23:07] <stgraber> oh and indeed that's just completely wrong because they move eth0 into a bridge without first deconfiguring eth0, therefore leaving it with an IP and a running dhclient
[23:08] <stgraber> so even if the restart didn't blow things up to pieces, they'd end up with the network config being applied to both eth0 and br0 and two dhclient process running (one on eth0 and one on br0)
[23:09] <sarnold> what does it mean to run dhclient on a bridge device?
[23:09] <stgraber> oh and their config also doesn't need to mention eth0 at all, ifupdown is clever enough to figure it out from the br0 config
[23:09] <stgraber> sarnold: works fine, broadcasts to all devices on the bridge, attempts to get an IP and sets it on the bridge interface
[23:09] <sarnold> stgraber: crazy, I thought the point of the bridge interfaces was that they were 'below' IP, as it were.
[23:10] <hallyn> stgraber: i see it in the bug description, but the juju package doesn' tseem to include those.
[23:10] <stgraber> hallyn: so tl;dr, they should use ifdown eth0 => 'cat > /etc/network/eth0.conf << EOF\niface br0 inet dhcp\n bridge_ports eth0\nEOF\n" => ifup br0, that'll DTRT
[23:11] <xnox> ScottK: what's wrong with 4.8? there are plenty of apps still using that...
[23:11] <hallyn> /etc/network/eth0.conf?  that's new to me
[23:11] <ScottK> xnox: Are you fixing bugs or adding features?  If the former, then nothing.
[23:11] <xnox> ScottK: so we do still need to maintain it.
[23:12] <ScottK> Sure.
[23:12] <stgraber> sarnold: yeah, it's slightly trickier than that, because it both acts like a switch and a member of that switch. So it doesn't have its own MAC address (steals the lowest one in the bridge) but can have IP configuration on it and you can use it like a regular interface (so long as it has at least one member, otherwise it doesn't have a MAC and everything blows up)
[23:12] <xnox> ScottK: working on the gtk theming plugin.
[23:12] <xnox> (qgtkstyle)
[23:12] <sarnold> stgraber: thanks, I think that explains a lot about what I'd been misunderstanding about bridges :)
[23:13] <stgraber> hallyn: they're using the "source statement" to include an external file. Though they really should be using include-dir and /etc/network/interfaces.d/ since that's what's done by default on new installs now.
[23:13] <hallyn> stgraber: no no, include-dir isn't yet supported by augeas :)
[23:14] <stgraber> hallyn: well, clearly they're not using augeas at the moment, so who cares ;)
[23:14] <hallyn> they'll want to use libvirt using netcf and thatll fail
[23:14] <hallyn> anyone answer is noone seems to care so i'll probably ahve to update the lens :(
[23:15] <stgraber> so augeas supports source but not include-dir? that seems odd since the latter is basically a wildcard source (ish, there's a regexp in the interfaces manpage)
[23:15] <hallyn> stgraber: the source support is actually not yet committed iiuc.


 Hi how to add kinetic scroll to libinput touchpads on Xorg?
 Would like to implement to specific applications like Chromium/Firefox because implementing systemwide ig not possible
[13:33] <BluesKaj> Hi all
 Hello first I had the problem as seen in the video. Now the PC no longer boots up. What can I do?
 https://irc-attachments.kde.org/a5b4b3f3/file_61788.jpg
 https://irc-attachments.kde.org/084398e9/file_61789.jpg
 As it was on the video, I turned off the PC a couple of times with a button and then it started up. Now he does not go up, the last pictures on the monitor.
[16:07] <tomreyn> if you can't get help here, try https://web.libera.chat/#ubuntu
[16:07] <tomreyn> or, if you have an irc client: irc.libera.chat, port 6697 (TLS) or port 6667 (no tls), and /join #ubuntu
 Ne this did not help me (re @IrcsomeBot: <tomreyn> if you can't get help here, try https://web.libera.chat/#ubuntu)
[18:36] <tomreyn> SA: are you still around (I can't tell from IRC)?
[18:39] <tomreyn> If so, I would suggest resetting bios to manufacturer defaults. if this does not help, try booting kubuntu with !kernelparm "acpi=off" as a (temporary) workaround, then just shutdown normally, and after it powered off, start kubuntu again. to see whether the issue is gone. if not, persist the acpi=off workaround in /etc/default/grub (and run "sudo update-grub") until you get around to install a bios upgrade - which you may need to do anyways.
[18:41] <tomreyn> !kernelparm
[18:42] <tomreyn> also, if you dual-boot with windows, make sure you configure windows to shut down properly, which, by default, it won't do.
[21:58] <adminer> hej
[22:17] <kraft> hi