[00:57] <soreau> Guys, I have no idea what happened but all of the sudden, evince fails with "evince: error while loading shared libraries: libX11.so.6: failed to map segment from shared object: Permission denied"
[00:57] <soreau> Can someone give me a hint as to what might be wrong?
[00:58] <soreau> Also I can't seem to start 'gksu software-properties-gtk'. It just gives a busy cursor for a few seconds, returns and gives no additional output
[04:53] <ScottK> pitti: I'd appreciate it if you could arrange for qt4-x11 to get out of binary New.  AIUI didrocks needs this for work at the sprint this week and it's my upload, so I shouldn't do it.
[08:52] <pitti> ScottK: oh, sure
[08:53] <pitti> doing now
[09:00] <tkamppeter> pitti, hi
[09:00] <pitti> hey tkamppeter
[09:00] <tkamppeter> pitti, are you in Dublin now?
[09:00] <pitti> yes
[09:01] <tkamppeter> pitti, it is about AirPrint. we could ask the people on the Sprint to test.
[09:02] <tkamppeter> pitti, first you should pass the SRU of bug 801306 to -updates (it is already verified) and upload CUPS for Oneiric, so that everyone gets the fixed AirPrint support by a simple update.
[09:03] <tkamppeter> pitti, then make a call for testing on the Sprint, for example during today's plenaries.
[09:03] <pitti> tkamppeter: with cups I was going to wait until the current unstable version goes to testing, but if it's helpful, I can upload the current bzr head to oneiric, yes
[09:03] <tkamppeter> pitti, would be great.
[09:03] <pitti> tkamppeter: or do it on Friday, when most people want to print their your boarding passes anyway :)
[09:04] <tkamppeter> pitti, I by myself will be on the Sprint on Thu and Fri, but doing the testing through the whole Sprint would be much better.
[09:05] <tkamppeter> pitti, is there a printer on the Sprint, or does the testing only work as I described on the list, with a file printer?
[09:05] <pitti> I haven't seen a printer yet, need to ask around
[09:09] <tkamppeter> pitti, can you have a look at bug 799064?
[09:10] <tkamppeter> pitti, what is going wrong there?
[09:12] <pitti> tkamppeter: (in plenaries, looking later)
[09:39] <evfool> tkamppeter, pitti : that's an interesting bug, I saw quite a few bur reports related to that, aka unable to find standard output to write to
[09:40] <SpamapS> jhunt: hey lets get together some time before lunch to chat about some stuff to collaborate on this week
[09:41] <tkamppeter> evfool, so it is not specific to this package?
[09:41] <tkamppeter> evfool, if this is a general problem, it most probably needs to get reassigned to another package. Which one?
[09:42] <evfool> tkamppeter: i saw problems similar in docbook-xml, libcap2, gthumb, compiz-plugins-main, aso...
[09:43] <evfool> tkamppeter: i'm not sure, as it happens while installing/upgrading either it's a problem in dpkg, or the package install scripts do something ugly for many packages
[09:43] <evfool> tkamppeter: but that's just a guess
[09:44] <evfool> tkamppeter: found that, its dpkg, bug 545790
[09:45] <tkamppeter> evfool, will mark my bug as duplicate of this one. Thanks.
[09:47] <jhunt> SpamapS: sure. do you want to get together in 5?
[09:48] <SpamapS> we won't be able to break out of here for a bit.. mor elike 90
[09:49] <tkamppeter> evfool, never seen such a long duplicate list.
[09:49] <evfool> tkamppeter: yep, it's interesting, and I see many which are not yet marked as dupes
[10:11] <kirkland> slangasek: could you fairly urguently look at https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/802197 ?
[10:11] <kirkland> slangasek: the recent util-linux update is locking oneiric users out of their encrypted-home directories because util-linux is not writing an /etc/mtab entry for sysfs
[10:13] <slangasek> kirkland: we should ask lamont the question of whether this behavior change is intended
[10:13] <slangasek> lamont: ^^
[10:14] <kirkland> slangasek: sure... lamont?
[10:14] <kirkland> slangasek: is lamont here in Dublin?
[10:15] <slangasek> kirkland: I don't think so
[10:16] <slangasek> I haven't heard loud and dry from IS so far, only loud and cackling
[10:16] <kirkland> slangasek: :-D
[10:16] <kirkland> slangasek: i'll subscribe him to that bug and ask for a comment
[10:16] <slangasek> ok
[10:25] <evfool> mvo:ping
[10:28] <mvo> hey evfool
[10:31] <evfool> mvo: how bad is an aptdaemon api change? to fix bug 771678, had to change the space and download transaction props from int32 to int64
[10:31] <evfool> mvo: could you please check the branch attached, as that bug's starting to have lots of dupes
[10:33] <em> hey what is to prevent ubuntu devs/security team from stealing people's bitcoins?
[10:33] <glatzor_> evfool, since there are currently only python clients the change should not do any harm
[10:33] <directhex> em, nothing. muahahahaha, etc.
[10:34] <em> hehe
[10:34] <evfool> thanks glatzor, thats good
[10:34] <em> I better keep my bitcoin wallet.dat on a usb flash drive separate from my computer.
[10:36] <Laney> how would that help?
[10:37] <cjwatson> if you don't trust your operating system, you shouldn't run it
[10:37] <mvo> evfool: thanks, I will do that
[10:37] <evfool> thanks mvo, glatzor
[10:37] <cjwatson> there's really not much way around that
[10:37] <em> well i believe the only way that someone can get my coins is if they have the keys that are in wallet.dat
[10:37] <mvo> hey glatzor_!
[10:38] <cjwatson> it's hardly new to bitcoins; an evil browser maintainer could snoop on all traditional e-commerce transactions conducted through a web browser, too
[10:39] <em> cjwatson: true but somehow i think if a person successfully steals bitcoins it is very likely and much easier for them to get away scott free.
[10:39] <slangasek> this is merely evidence of why bitcoins are a naive system
[10:39] <Laney> luckily you're running a Free OS, so can inspect the code running on your computer
[10:39] <cjwatson> it's a fundamental trust issue either way
[10:39] <Laney> but... how far can you trust that? http://cm.bell-labs.com/who/ken/trust.html
[10:39] <ion> em: To which operating systems would you attach the drive?
[10:40] <directhex> em, have you ever audited the *upstream* bitcoin code?
[10:40] <em> im not too paranoid about the code in Ubuntu/Linux. I surely trust that more than the propreitary ones. But I am a little nervous about the Ubuntu Security team and what they (can) see with updates or bug fixes to certain aps.
[10:41] <cjwatson> if you are nervous about the Ubuntu security team, I don't think you can safely run Ubuntu at all
[10:41] <em> Also I don't know who the Ubuntu Security team is on a personal level so don't feel insulted.
[10:41] <cjwatson> I think it's more likely that the Ubuntu security team has zero interest in stealing people's bitcoins
[10:41] <directhex> mostly former kgb agents, why does that have any bearing?
[10:42] <ion> Simply don’t run Ubuntu at all, run the operating system whose security team you do trust instead. Problem solved.
[10:42] <glatzor_> hey mvo!
[10:42] <em> I think everyone would agree that they are probably basically very upstanding people but wouldn't everyone also agree that the finest of people could break if they had a chance to get away with 400 thousand dollars without a trace?
[10:42] <jdstrand> what is the specific problem here? that dpkg runs maintainer scripts as root?
[10:43] <cjwatson> I can only repeat that if this is a genuine concern then you shouldn't run Ubuntu (or shouldn't use bitcoins in conjunction with it)
[10:43] <em> Well then I think that it's just an interesting thing to consider how bitcoins make security even more interesting and important than it ever was before. Now that many people have really valuable stuff on their computers.
[10:43] <cjwatson> there is no way to reassure you
[10:43] <StevenK> em: I disagree.
[10:43] <em> how come?
[10:43] <cjwatson> bitcoins are hardly more "really valuable" than all the credit card transactions people have been doing on their computers for over a decade
[10:43] <jdstrand> ah, bitcoins
[10:43] <StevenK> em: People have been storing usernames and passwords for things that give access to *real money* for years.
[10:44] <StevenK> Pretty much what cjwatson said.
[10:44] <em> cjwatson: Well the reason I disagree with that is that if you have my credit card number, sure enough you could steal from me, but (1) It's much more difficult for you to get away with it, and (2) It's pretty easy for me to undo the damage to myself.  Neither of those are true with bitcoins.
[10:45] <cjwatson> if you log into my online banking facility and make a non-CC transfer of some kind, it would be difficult for me to undo the damage
[10:45] <barry> if you steal enough bitcoins can you buy a cache of stolen credit card numbers?
[10:45] <cjwatson> it would certainly cause me a good deal of work
[10:45] <directhex> em, you seem to be under the mistaken belief that the security team is anonymous. let's follow your supposition, that someone in the security team uploads a bitcoind which sends keys someplace, or sends coins to some address, or somesuch.
[10:45] <StevenK> em: Then the flaw is with bitcoins, not the OS you run?
[10:45] <ion> em: Given your assertion that any person is likely to choose to steal the 400k dollars given a chance i don’t see how the issue affects Ubuntu any differently than the alternatives.
[10:45] <directhex> em, now, what happens when the first guy notices a missing balance? then the next guy? the issue is isolated to ubuntu, the rogue update is found, the person who uploaded it is named and sued
[10:46] <cjwatson> directhex: (and fired, in all probability)
[10:46] <jdstrand> and arrested
[10:46] <em> StevenK: no I don't think that's fair to say. I'm not here to cast dispersions on anyone or say there is any flaw in any OS. It's just the nature of bitcoins. And I think bitcoins create a new level of interest in security.
[10:46] <directhex> cjwatson, i think that's implicit?
[10:46] <cjwatson> yeah, but just to make it explicit.  anyone trying this has a lot to lose.
[10:46] <directhex> jdstrand, afaik you can't be arrested in the uk for stealing bitcoins. they're considered a virtual good, so have no value until traded for something material
[10:47] <em> ion: yeah this is not about Ubuntu really.
[10:47] <jdstrand> I would be surprised if I couldn't get arrested in the US for it. but I don't know. let's just say it sounds incredibly risky :)
[10:48] <kees> SECURITY UPDATE: your bitcoins were not part of my balance. This has been fixed.
[10:48] <directhex> kees++
[10:48] <StevenK> Hahaha
[10:48] <cjwatson> directhex: I expect you could be arrested; whether it would be wrongful is a different matter ;-)
[10:48] <jdstrand> CVE-2011-$$$$
[10:48] <em> ion: I dont know that I'm asserting "any" person is likely to steal 400K.  That 400K was a made up number and Im sure that many (most?) people would resist the temptation. But I think it is human nature that given the chance to commit a 'perfect crime' most people have some price.
[10:48] <cjwatson> em: the notion that such a thing would be untraceable is not accurate, I think
[10:48] <cjwatson> all changes to the Ubuntu archive are traceable
[10:48] <directhex> em, your belief that it's a perfect crime is based upon several veriufiably false premises
[10:49] <em> directhex: could be you are right about your senario but bitcoins make a certain sort of anonymity pretty easy for someone who knows what they are doing. No one could say for sure who actually has the bitcoins once they are gone.
[10:49] <cjwatson> sure, it would likely take time to trace, but *shrug*
[10:50] <Laney> you can say for sure who pushed out the malicious piece of software though
[10:50] <Laney> unless they manipulated the archive ...
[10:50] <cjwatson> a security update that turned out on inspection to include 'mail<EMAIL_ADDRESS></home/em/wallet.dat' would be a bit of a smoking gun
[10:50] <em> do you guys know a lot about bitcoins?  Let me try to catch up.
[10:51] <cjwatson> unless it was a security update that gave a particular security team member a shell on your system, and then *that* would be traceable and probably even more easily prosecuted
[10:52] <cjwatson> (since there are plenty of established computer misuse laws in most jurisdictions)
[10:52] <em> Oh yeah you are saying that it will be possible to figure out who put the trojan/backdoor/malicious code in.
[10:52] <Laney> Launchpad is a better place to do this really
[10:52] <directhex> em, not possible: trivial.
[10:53] <em> I guess the attack could either be that you somehow get a copy of my wallet.dat or else that you actually hijack my bitcoin client and use it to send yourself my coins.
[10:53] <cjwatson> this is no more fundamentally interesting than any of many other possible attacks that people with upload privileges to the Ubuntu archive might perform (and similarly be traced for)
[10:54] <em> anyway i didn't mean to disrupt things here and i'm not trolling you guys. I am just not usually awake right now :)
[10:54] <cjwatson> don't get distracted by the anonymity provided by bitcoins; that's only one level
[10:54] <jpds> http://www.economist.com/node/18836780
[10:55] <em> I think the advent and growth of bitcoins increases the incentives for people to attack ordinary people's computers, and the incentive for ordinary users to be paranoid VERY significantly.
[10:55] <em> But this last comment I made here has nothing to do with ubuntu or ubuntu security in particular.
[10:56] <directhex> yet people trust their wallets to mtgox. look how that turned out
[10:56] <em> people do not trust their wallets to mtgox.
[10:56] <em> they do trust however many bitcoins they have there though and USD.
[10:57] <em> mtgox is a weird case because, like most things in the 'bitcoin economy' it's an ad hoc project slapped together by some ambitious kids and now it's making thousands of dollars a day.
[10:57] <em> but it's true, i dont think anyone that runs mtgox is any kind of professional or really knows what they are doing.
[11:05] <barry> cr3: hey man, are you around and if so, what room?  can we chat about checkbox?
[11:05] <cr3> barry: hey dude, I'm around but kinda busy right now. lets plan to merge chad's branch this week
[11:07] <barry> cr3: cool.  any chance we can do that earlier in the week?  i'd love to close out the conversion task as early as possible.  i'm happy to help in any way
[11:07] <barry> cr3: thanks!
[11:10] <cr3> barry: sure, I'm all for it
[11:10] <barry> cr3: awesome, thanks man
[11:26] <slangasek> doko: the avahi pointer-from-integer failure is due to changed gtk headers, actually :)
[11:29] <cjwatson> pitti: do you know why http://people.canonical.com/~ubuntu-archive/pending-sru.html doesn't list bug 56679 for netcfg?
[11:30] <slangasek> maybe it doesn't know what to do with 5-digit bugs ;P
[11:45] <pitti> cjwatson: hmm, looking
[11:47] <pitti> slangasek, cjwatson: the bug number is in http://launchpadlibrarian.net/73636370/netcfg_1.51ubuntu3_source.changes, so until there it worked
[11:47] <pitti> (it parses Launchpad-Bugs-Fixed:)
[11:47] <cjwatson> right
[11:50] <pitti> ah, drat
[11:50] <pitti> slangasek: you were right after all :)
[11:50] <slangasek> hahaha
[11:50] <pitti> re.compile('lp:?\s*#(\d{6,7})', re.I)
[11:50] <slangasek> :-)
[11:50] <pitti> I think I added that after getting too many false positives by other garbled changelogs
[11:51] <pitti> {'56679': [u'patch', u'verification-done']}
[11:51] <pitti> there we go
[11:51] <pitti> cjwatson: fixed; and congrats for fixing a five-digit bug :)
[11:52]  * pitti will fix it more properly now, though
[11:52] <cjwatson> that doesn't merit congratulations, all I did was ignore it for some years ;-)
[12:02] <pitti> tkamppeter: I asked on the bug for debugging; no immediate idea either, there's not much information there
[12:03] <pitti> tkamppeter: oh, someone duped it in the meantime
[12:03] <pitti> tkamppeter: seems it's quite an old dpkg bug inded
[12:03] <pitti> indeed
[12:08] <pitti> ScottK, any KDE expert: is pkgkde-debs2symbols and/or pkgkde-gensymbols a magic solution to the per-architecture .symbols files somehow?
[12:08] <pitti> IOW, when I want to add symbols files for a C++ library, can I get them any other way than just upload, grab the diffs from the buildd logs, and upload again?
[12:12] <cjwatson> pitti: having to use per-architecture symbols files normally means that you're failing to use dpkg-gensymbols' facilities for C++ symbols properly
[12:12] <cjwatson> for example, using mangled names
[12:13] <cjwatson> see the "Using symbol patterns" section in dpkg-gensymbols(1)
[12:16] <slangasek> cjwatson: except for functions which use a different int type on 32- vs. 64-bit systems, where counterintuitively things wind up using 'int' on 32-bit and 'long' on 64-bit
[12:17] <pitti> cjwatson: I'll read that then; but manually creating patterns for 537 symbols sounds painful
[12:18] <cjwatson> slangasek: yes; you could use (c++|regex) though
[12:18]  * slangasek nods
[12:18] <doko> gcc -v -E - < /dev/null 2>&1 | awk '/^#include/,/^End of search/ {i=1} i==1 && /^ / {print}'
[12:33] <stgraber> barry: http://paste.ubuntu.com/633583/
[12:37] <tkamppeter> pitti, I was the one who duped the bug, after evfool helped me with it.
[12:38] <ScottK> pitti: Thanks (on qt4-x11) and AIUI yes on pkgkde-gensymbols.  http://pkg-kde.alioth.debian.org/symbolfiles.html has additional information on it.
[12:38] <tkamppeter> pitti, any news about possibilities of AirPrint testing on the sprint?
[12:38] <mvo> evfool: your branch looks fine, did glatzor give you any feedback ? if he is fine as well, I'm happy to merge it right away
[12:40] <evfool> mvo: glatzor only wrote that as aptdaemon has only python clients, changing from int32 to int64 shouldn't affect them
[12:42] <mvo> evfool: sounds like agreement to me ;)
[14:22] <sconklin> pitti: Do you think you'll be able to publish our kernels today?
[14:50] <slangasek> stgraber: the umount manpage (even in natty) says that umount takes a '-d' option to handle loop device removal... were you using that option?
[15:20] <cjwatson> slangasek: I must say I don't ever recall having to do so; and I don't see why umount couldn't detect that
[15:20] <cjwatson> the man page says "The umount command will free the loop device (if any) associated with the mount, in case it finds the option `loop=...' in /etc/mtab, or when the -d option was given."
[15:21] <cjwatson> hm, a test loop mount/umount here does free the loop device though
[15:23] <slangasek> ah, so maybe it's a bug in the mtab writing, rather
[15:36] <pitti> does that depend on uevents in any way?
[15:36] <slangasek> shouldn't
[15:36] <pitti> because I noticed that umount doesn't remove the loop devices in a way that udev picks up
[15:37] <pitti> i. e. umount() fails to generate a remove event for them (which losetup -d does)
[15:37] <pitti> ok
[15:40] <slangasek> odd
[15:41] <psusi> pitti: did the device actually get removed?
[15:41] <pitti> psusi: yes, but silently
[15:41] <psusi> whoa... that shouldn't be possible
[15:42] <pitti> which causes bugs like bug 548546
[15:42] <pitti> psusi: well, mount as in the program doesn't do this; it's the mount() syscall which is cleaning up the loop mount, and the kernel just forgets to send the uevent
[15:43] <psusi> pitti: what?  no... it's the umount program that does it when it sees the loop option in mtab
[15:44] <pitti> last time I looked, umount() didn't actually have any code for the loop cleanup
[15:44] <pitti> kees: released linux linux-meta linux-ports-meta linux-backports-modules-2.6.35 to maverick-security
[15:46] <apw> cjwatson: am i right in thinking that if i replace caspers initrd.lz with an initrd.gz it will just work without change?
[15:49] <kees> pitti: thanks!
[15:51] <cjwatson> apw: should do, yes, as long as you adjust the boot loader configuration too
[16:04] <psusi> pitti: wait a second... loop devices don't actually get deleted... they are precreated when the module is loaded...
[16:09] <psusi> pitti: ohh boy... I think I just found it... it seems there's a flag you can set to have the kernel auto clear the loop when the last reference to it is dropped, so I guess that is what mount uses instead of having umount clear it.
[16:09] <pitti> psusi: right, but they shold still generate a change event, like losetup -d does
[16:09] <pitti> psusi: right
[16:09] <psusi> pitti: when it auto clears in loop.c:1525, it passes NULL for the bdev to loop_clr_fd, which causes it to not emit the uevent
[16:10] <pitti> I think I even reported that to bz.k.o, checking
[16:10] <pitti> https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/548546/comments/44
[16:11] <pitti> had my findings back then
[16:11] <pitti> hmm; seems I meant to report it, but didn't
[16:33] <pitti> bdmurray: filed as bug 802589, FYI
[16:41] <bdmurray> pitti: thanks
[17:21] <debfx> superm1: could you please have a look at my dkms patches on bug #802617 and bug #766150
[17:22] <debfx> tjaalton: ^ you might be interested in them as well
[17:24] <tjaalton> debfx: thanks, looking
[17:27] <tjaalton> debfx: thanks, they make a great deal of sense :)
[17:37] <loganaden> hi
[18:27] <NewbieToKernel> where can i find ubuntu source code including the kernel?
[18:31] <holstein> NewbieToKernel: https://help.ubuntu.com/community/Kernel/Compile#Get the kernel source
[18:32] <holstein> http://ubuntuforums.org/archive/index.php/t-14756.html might be helpful as well
[18:40] <NewbieToKernel> the linux kernel is same accross all distributions rite?
[18:41] <hallyn> NewbieToKernel: no
[18:41] <hallyn> NewbieToKernel: different distros use (a) different versions with (b) different patches and (c) different configs
[18:41] <NewbieToKernel> so there is a seperate ubuntu kernel?
[18:41] <hallyn> but the heart of it is the same
[18:41] <NewbieToKernel> oic
[18:42] <NewbieToKernel> so what are the other packages that constitute the ubuntu distro?
[18:42] <hallyn> you can look at http://kernel.ubuntu.com/git/ for the source used in ubuntu
[18:43] <hallyn> i'm not sure i understand the question, but if you have an ubuntu system running you can do 'dpkg -l' to look at all the packages installed
[18:43] <hallyn> then 'apt-get source <packagesourcename>' to download the source
[18:44] <hallyn> (where packagesourcename is what you get from 'apt-cache show <package> | grep Source')
[18:44] <hallyn> that should get you going enough to look around
[18:44] <hallyn> btw, the current development kernel is at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=summary
[18:44] <NewbieToKernel> so that is just the kernel or the other packages that come along with ubuntu as well?
[18:45] <hallyn> dpkg -l shows them all
[18:45] <hallyn> all that are installed that is
[18:46] <NewbieToKernel> so i has all the packages along with the ubuntu specific kernel?
[18:50] <NewbieToKernel> hallyn?
[18:50] <hallyn> hm?
[18:51] <hallyn> i don't understand your question.  do you have a running system?
[18:51] <hallyn> a running ubuntu system?
[18:51] <NewbieToKernel> no
[18:51] <NewbieToKernel> i want to build the ubuntu kernel
[18:52] <NewbieToKernel> for x86 although it has already been built
[18:52] <NewbieToKernel> the i want to include the packages one by one that constitute ubuntu
[18:52] <NewbieToKernel> and build them from sources
[18:53] <NewbieToKernel> the link that you gave me has a lot of git repos
[18:53] <hallyn> the next link i gave you has exactly one
[18:53] <hallyn> you can get clone that and build it as any other kernel
[18:53] <NewbieToKernel> ok. cool
[18:54] <hallyn> 'make defconfig; make -j16 > log 2>&1'
[18:54] <NewbieToKernel> so after that how do i know what other packages are included as part of the standard uuntu distro?
[18:54] <hallyn> now, if you want to build the kernel exactly as it would be built for ubuntu,
[18:54] <hallyn> i.e., same configs,
[18:54] <hallyn> there's more to it.  jump to #ubuntu-kernel for such info
[18:55] <NewbieToKernel> ok...cool
[18:55] <NewbieToKernel> so after the kernel is built ... how do i build packages?
[18:56] <NewbieToKernel> and how do i know what packages are part of ubuntu distro?
[18:57] <hallyn> not sure what the easiest way would be to do that.  TO build, just apt-get source like i said before, then do 'fakeroot debian/rules build'
[18:57] <hallyn> biaw
[18:59] <NewbieToKernel> thx!!
[19:56] <superm1> debfx, yeah i'll look.  do they apply to trunk?
[20:01] <debfx> superm1: I'm not sure
[20:01] <superm1> debfx, well trunk is significantly different
[20:01] <superm1> hopefully it will be pulled into debian and merged for ubuntu
[20:02] <debfx> trunk as in master or <IP_ADDRESS>?
[20:03] <superm1> <IP_ADDRESS> was just released so it's same as master, but the version in ubuntu is about a year old
[20:03] <superm1> so if the patches are relative to the version in ubuntu they might need rework
[20:06] <debfx> superm1: looks like master hasn't been updated. <IP_ADDRESS> is more recent than master
[20:06] <superm1> hm, i wonder if forgot to push the tag
[20:10] <superm1> debfx, no the tag is out on master
[20:10] <superm1> http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=dkms.git;a=summary
[21:15] <psusi> pitti: it looks like since kernel 2.6.37, mount sets the autoclear flag instead of recording the loop device in mtab.  The previous behavior was to just record the device name in mtab and umount will properly clear it.  A simple fix should be to simply cut that line of code and force the old behavior
[21:17] <psusi> pitti: mount.c:1270 in util-linux checks the kernel rev and enables SETLOOP_AUTOCLEAR... one snip there should take care of it
[22:02] <hallyn> bug 802538
[22:03] <hallyn> does anyone here know whether/why it was assumed that not creating persistent /etc/udev/rules.d/ net entry for vmware net devices would not impact guests?
[22:03] <hallyn> (re bug 802538)
[22:17] <broder> hallyn: presumably it was an attempt to avoid situations where the mac address of the guest changed each time the guest was started
[22:18] <broder> xen used to do that in its default configuration
[22:19] <broder> and so you'd end up with eth0, then you'd reboot and get eth1, then eth2, etc
[22:19] <hallyn> hm, does vmware do that?  if so that makes sense
[22:25] <hallyn> lunaphyte_: is there something you need that file for?  or was this curiosity?
[22:25] <hallyn> ie do you actually have two NICs (not in the logs) you want to keep straight?
[22:27] <lunaphyte_> i have a vmware guest, running ubuntu - that i use as a template.  when i deploy a new guest from that template, the mac address changes.  i have a little deployment utility i wrote to address this item [along with a few other items], which deletes that file.  then, when a new guest is deployed, a new file is created, with the new mac address.
[22:28] <lunaphyte_> just one nic
[22:28] <hallyn> but not having the file created doesn't actually cuase trouble right?
[22:29] <lunaphyte_> i have not seen vmware change the mac address of a guest between reboots.  that would potentially break things quite heavily.
[22:29] <lunaphyte_> i haven't tried with the file, so i'm not certain what would happen.
[22:29] <lunaphyte_> err - *without the file, rather.
[22:30] <lunaphyte_> i can test that, if it would help.
[22:31] <hallyn> well i'm just wondering how much we should care and what lengths to go to to document this.  like i say, i think vm's with multiple nics are the ones who might be negatively impacted.
[22:31] <hallyn> do you know if, evne if you restart vmware (and maybe reboot the host), does the vm still maintain the same MAC?
[22:31] <hallyn> biab
[22:32] <lunaphyte_> well, i can't restart vmware or reboot the host - there are many other guests on it, but i can just about guarantee you that it will not change.
[22:32] <lunaphyte_> bbiab myself :)
[22:37] <hallyn> mdeslaur: was able to create an oneiric vm with the new vm-new.  It doesn't boot, but I *assume* that's unrleated :)
[22:37] <mdeslaur> desktop or server?
[22:38] <mdeslaur> hallyn: ^
[22:38] <hallyn> server
[22:38] <mdeslaur> ah, I did test oneiric desktop, but I just added server support, and may not have tested oneiric
[22:38] <hallyn> ok i'll try out desktop tomorrow.  Just need to find the right iso :)
[22:39] <hallyn> do you plan to add support for vm-new automatically rsync'ing?
[22:39] <mdeslaur> last oneiric desktop daily iso I tried was 20110622
[22:39] <mdeslaur> and it worked
[22:39] <mdeslaur> rsyncing the isos?
[22:39] <hallyn> yeah
[22:39] <mdeslaur> I hadn't thought about it, but it seems like a good idea
[22:41] <hallyn> just bc i had downloaded the -alternate cd before realizing i couldn't use that :)
[22:41] <mdeslaur> oh, yeah, sorry :)
[22:41] <mdeslaur> I should add support for that as well
[22:51] <mdeslaur> hallyn: confirmed, I tested with hardy-natty server, but had not tested with oneiric...I'll look at it tomorrow if I have a minute
[23:18] <lunaphyte> hallyn: my particular environment is vmware esx, with 10 hosts, housing ~120 guests - this is just one of the guests.  guests are always being rebooted, shut down, moved from host to host [automatically sometimes even], and in the years we've been using this, i've never seen the mac address of a guest change - aside from as intended/desired when a template is deployed.
[23:24] <hallyn> lunaphyte_: can you comment that on the bug?  I don't know if that change came from udev upstream, from debian, or from us...  we should find out who filed the bug that was being addressed
[23:32] <lunaphyte> yeah, i'll do that.
[23:46] <bdrung> kirkland: does anything speak against upstreaming the changes from lintian 2.4.3ubuntu3?


[19:33] <JND314> hey, I've some install pbs.
[19:34] <JND314> I've tried to install ubuntu 12.10 remix amd64 both via usb and dvd.
[19:35] <JND314> I have a new lenovo C30 workstation, literally fresh out of the box. It had windows but I blew that away with my first install attempt.
[19:35] <JND314> The fundamental pb is that once remix is installed I cannot boot.
[19:36] <JND314> With the usb install, which I tried first, I ran all the boot-fix utils, but to no avail.
[19:38] <JND314> As I read in places that the ubuntu OS may have been installed right on my usb stick, I changed coarse and installed w/ a dvd.
[19:38] <JND314> both with usb and dvd the install proceeded fine, but all appearances.
[19:38] <JND314> currently 'drive 1' is on the top of the primary source grub list
[19:39] <JND314> clearly grub is falling through, past the dvd (which I removed) and hitting the network boot, which doesn't exist.
[19:42] <JND314> I've exhausted the possibilities that I know of, and/or have found via google.
[20:07] <jbicha> JND314: I'd recommend you try the regular Ubuntu DVD; then if you still have problems you can try support channels like #ubuntu or askubuntu.com
[20:08] <JND314> yeah, ok, working on that already. This hasn't been a regular pb then, is it.
[20:14] <JND314> one thing that I was baffled by: http://ubuntuforums.org/showthread.php?t=2023086
[20:15] <JND314> it says, "Please do not forget to make your EFI-BIOS boot on sda1/EFI/ubuntu/grubx64.efi file!"
[20:15] <JND314> well, that link is the complaint about the directions that say to do this. Does anyone in this chat know how to get grub to point to this file?
[20:33] <darkxst> JND314, does your machine have secure boot enabled?
[20:34] <JND314> I haven't enabled or disabled it explicitly. I can have a look, but I haven't touched this part.
[20:35] <JND314> I may be disconnected but I'll brb
[20:39] <JND3141> one point is that I've been electing to install with LVM. Perhaps I should not select this.
[21:04] <JND314> lvm isn't the pb
[21:05] <JND314> just reinstalled remix again, didn't select lvm. good install, removed disk when asked, rebooted -> grub did not find /dev/sda1
[21:05] <JND314> installing ubuntu 12.10 (unity -- ugh!) now
[21:22] <JND314> ok -- confirmed. ubuntu 12.10 + lvm is a go.
[21:22] <JND314> rebooted the first time.
[21:23] <JND314> its the remix install that's horked for my lenovo c30.
[21:23] <darkxst> JND314, did you check if your system is using secure boot?
[21:23] <JND314> I've tried both the usb install (first) and then dvd.
[21:24] <JND314> well, hmmm...
[21:24] <JND314> like I said, I didn't check anything, like encryption.
[21:24] <JND314> if you let me know what to report when I'm in the bios config I'll let you know
[21:25] <JND314> (but I have unity on in now. at this point I can reinstall again to see)
[21:25] <darkxst> JND314, looks for an option 'secure boot' or similar
[21:26] <darkxst> (in bios)
[21:26] <JND314> ok, where? in the bios config ?
[21:26] <JND314> haha
[21:26] <JND314> crossed msgs.
[21:27] <darkxst> our image should work with secure boot enabled, however I don't think it was ever tested
[21:28] <JND314> bias version a1kt40aus, fyi
[21:28] <darkxst> JND314, anyway you can get to a mostly ubuntu gnome system via 'upgrade' instructions in release notes
[21:31] <JND314> ok -- in the bios security
[21:32] <JND314> hardware passwd enabled, current setting enabled. admin passwd no installed, power-on passwd not installed.
[21:32] <JND314> I haven't set the admin or power-on passwds
[21:32] <JND314> report pOP on restart -- no
[21:32] <darkxst> no thats not it
[21:32] <darkxst> nothing to do with passwords
[21:33] <JND314> ok.
[21:33] <JND314> I'm in 'security' in the bios config
[21:33] <darkxst> it probably in 'boot' section
[21:33] <JND314> fyi in 'startup' UEFI boot mode is auto
[21:35] <JND314> yeah, I just don't have an entry 'secure boot [enabled]' in my boot config pages.
[21:36] <darkxst> ok, maybe thats not the issue then
[21:37] <JND314> Just to report: brand id: ThinkStation C30, BIOS A1KT40AUS, firmware ver 2012/03/23.00,
[21:39] <JND314> thanks for helping. re the 'upgrade' instructions, they are in the ubuntu-gnome pages, or mainline ubuntu ?
[21:40] <JND314> I'm really dreading unity, been working on gnome 6 years.
[21:40] <JND314> would prefer to use this group's version.
[21:42] <darkxst> https://wiki.ubuntu.com/UbuntuGNOME/ReleaseNotes/12.10
[21:45] <jbicha> maybe that UEFI boot mode option
[21:45] <JND314> I was reading that samsung laptops got bricked w/ ubuntu 12.04. uefi pb.
[21:46] <darkxst> jbicha, but install should work fine with efi, especially if normal ubuntu works
[21:48] <darkxst> but sounds like the grub installer is not inserting the boot entry for some reason
[21:52] <JND314> thanks for the link, fyi


[05:28] <pleia2> anyone happen to still be around to write any summaries?
[05:28]  * pleia2 works on stats and moving other things over
[05:28] <jose> pleia2: hey
[05:28] <jose> will take a quick look
[05:29] <pleia2> thanks jose
[05:29] <pleia2> if we get planet done at least I'll be happy
[05:29] <jose> np :)
[05:29] <jose> it's been quite a busy/messy day today
[05:30] <pleia2> :)
[05:31] <pleia2> hopefully in a good way
[05:36] <jose> can you give me a couple mins? Firefox is just eating up memory and crashing
[05:36]  * jose frowns
[05:38] <pleia2> sure
[05:47] <jose> pleia2: almost done
[05:49]  * pleia2 pulls together in the press summary
[05:51] <jose> Canonical news can go bullet-pointed this time
[05:52]  * pleia2 nods
[05:55] <pleia2> jose: want to add your name in credits? (or you can do it yourself when you do editorial review ;))
[05:56] <jose> pleia2: I'll do after I do the editorial review tomorrow :)
[05:56] <pleia2> k
[05:57] <pleia2> you're a lifesaver, I wasn't looking forward to writing all the summaires myself
[05:58] <jose> no worries, glad I could help :)
[06:01] <pleia2> alright, it's off to editors, time for me to be off to bed
[06:01] <jose> same here, you have a good night!
[06:03] <pleia2> thanks! you too
[23:12] <pleia2> jose: lmk when you have done review, I'll publish in a couple hours
[23:12] <jose> sure
[23:12] <pleia2> same goes for anyone else who is around :)
[23:12] <pleia2> Unit193: link check? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue373
[23:13] <Unit193> Sure thing, doc.
[23:20] <Unit193> Looks good.
[23:24] <jose> pleia2: removed a comment on the glossary thing, but it looks good to me :)
[23:36] <pleia2> thanks Unit193 and jose :)
[23:36] <pleia2> walking my friend to the train station, will publish upon my return


[08:12] <noodles775> thumper or anyone who can rs a testfix: http://pastebin.ubuntu.com/447621/
[08:12] <noodles775> It was the result of a bad but non-conflicting merge.
[08:12] <noodles775> to test: `bin/test -vvm test_sourcepackagerecipebuild`
[08:14]  * noodles775 RS's himself.
[08:39] <thumper> noodles775: it is fine to rs those yourself I think
[08:42] <noodles775> thumper: yeah, I thought so too :)
[10:51] <noodles775> Thanks jelmer_ :)
[12:52] <jtv> noodles775, jelmer_: got a slightly weird but very simple review for you.
[13:14] <noodles775> jtv: r=me, but why not just merge it and resolve the conflict once (then you won't have to worry about it?) Are you keeping a pipeline with your feature, or just a single branch?
[13:22] <bigjools> trivial CP branch
[13:22] <bigjools> well - trivial if you know SQL like stub does :)
[13:22]  * bigjools -> kunch
[13:22] <bigjools> lunch even
[13:22] <noodles775> :)
[13:36] <abentley> wgrant, mainly because _handleStatus_OK scares me, but also because I don't trust that if I break it the tests will catch it, and because another team is the main owner of the code.
[13:36] <wgrant> abentley: Mmm, true, it is pretty scary.
[13:37] <wgrant> But large piles of hacks also scare me. :/
[13:38] <abentley> wgrant, whether or not it's a hack depends on whether you think _handleStatus methods should always notify.  Otherwise, it's just programming-by-difference.
[13:53] <stub> https://code.edge.launchpad.net/~stub/launchpad/pending-db-changes/+merge/27263 has some random minor DB related updates for production stuff
[14:30] <noodles775> Ah, jelmer_, had you already started stubs review?
[14:30] <jelmer_> no, I haven't started yet
[14:30] <jelmer_> noodles775: did you already start?
[14:31] <mars> noodles775, jelmer_, have time to review a branch that will restore everyone's confidence in ec2?  :)   https://code.edge.launchpad.net/~mars/launchpad/use-zope.testing-3.9.4-p1/+merge/27265
[14:31] <jelmer_> I can take mars' mp
[14:31] <noodles775> mars: I've already done it.
[14:31] <mars> noodles775, wow, that was fast.  Thanks!
[14:31] <mars> noodles775, thinking about your comment
[14:32] <noodles775> jelmer_: ^^, and no, I hadn't started stubs, I just clicked on claim a few seconds before you changed the topi.
[14:32] <noodles775> topic.
[14:32] <noodles775> jelmer_: I'll just finish stubs now that I've claimed it then :)
[14:32] <jelmer_> noodles775: Ok :-)
[14:33] <jelmer_> mars: what does your branch fix wrt ec2 ?
[14:34] <mars> jelmer_, updates to a new version of the zope.testing testrunner with a backported patch fixing a crash.
[14:34] <mars> jelmer_, the testrunner would crash, forgetting all previous work, then continue to run the suite as if nothing happened: false suite success.
[14:37] <jelmer_> mars: ah, ok
[14:37] <jelmer_> mars: I'm still seeing branches disappear, is that a known issue?
[14:38] <mars> jelmer_, when was the last disappearance?  I landed the fix yesterday
[14:39] <jelmer_> mars: yesterday evening, after your fix landed afaik
[14:39] <jelmer_> mars: I'm running the testsuite locally but I'll try again with ec2 as well
[14:40] <mars> jelmer_, may have been a different bug: same crash, different source
[14:40] <mars> jelmer_, the subprocess handling in zope.testrunner is screwed.  This will keep happening until I land another branch or two.
[14:41] <jelmer_> mars: ah, ok
[14:41] <mars> jelmer_, with what frequency are you seeing ec2 disappearances?
[14:41] <mars> I was seeing it with 40% frequency
[14:43] <jelmer_> mars: it varied; it used to be one in 4 but I've seen more recently (40% sounds about right)
[14:43] <jelmer_> also, some branches seem more prone to disappearance than others
[14:44] <mars> makes sense depending on what the branch changed.  So far the failures are caused by race conditions and such.
[14:45] <mars> jelmer_, it is also possible that this branch that fixes the doctest failures will fix the crashes you are seeing
[14:45] <mars> jelmer_, I'll let you know when it lands.  Hopefully that will make more of them go away.
[14:46] <jelmer_> mars: thanks!
[14:56] <noodles775> jelmer_: are you landing that branch of mvo's? (or can you?)
[17:27] <rockstar> jelmer_, you're not still around, are you?
[17:36] <jelmer_> rockstar: I am
[17:36] <jelmer_> rockstar: what's up?
[17:39] <rockstar> jelmer_, I was gonna change the topic...  :)
[17:42] <jelmer_> ah :-)
[18:49] <gary_poster> rockstart, anyone, up for reviewing a change to our deps for the python2.6 switch? https://code.edge.launchpad.net/~gary/meta-lp-deps/generic-python/+merge/27292
[18:49] <gary_poster> rockstar
[18:49] <rockstar> gary_poster, sure.
[18:49] <gary_poster> thank you
[18:50] <rockstar> gary_poster, r=me
[18:51] <gary_poster> thanks rockstar
[22:00] <abentley> rockstar, could you please review https://code.launchpad.net/~abentley/launchpad/version-revno/+merge/27308 ?
[22:00] <rockstar> abentley, sure.
[22:01] <abentley> rockstar, ta
[22:02] <rockstar> abentley, is {revno} special to bzr-builder?
[22:02] <abentley> rockstar, yes.
[22:02] <rockstar> abentley, ah great, so we don't need the MANIFEST at all.
[22:03] <abentley> rockstar, huh?
[22:03] <rockstar> abentley, we were talking about doing this ourselves, but we needed access to the MANIFEST to get to the bzr revno.
[22:04] <abentley> rockstar, we'll still need manifests to abort duplicate builds, because {revno} is only evaluated once the build has started.
[22:05] <rockstar> abentley, ah, okay.
[22:05] <rockstar> abentley, r=me
[22:07] <abentley> rockstar, thanks.


[06:25] <flocculant> Unit193: I did - you were right :p
[06:27] <Unit193> A couple are translation only, whisker has small changes, weather uses a new version of the same API.
[06:28] <flocculant> k
[17:41] <flocculant> evening lurkers
[17:42] <pavlushka> evening flocculant !
[17:42] <flocculant> hi pavlushka
[17:42] <flocculant> and hi cm2
[17:44] <pavlushka> flocculant: had your evening tea?
[17:44] <flocculant> cm2: the 16.04.1 release will get whatever fixes for not-xubuntu and anything we can get in from xfce if there is anything
[17:45] <flocculant> but as far as intel wireless things landing - we're not able to really do anything there, personally I'd like to see that back of the disappearing cursor on lock/suspend with intel more :)
[17:46] <flocculant> but to be honest I'm not *completely* sure what .1 will have
[17:46] <flocculant> the first point release is more (afaik) about making sure there is a sane and working upgrade from previous LTS
[17:48] <flocculant> knome: re "ACTION: knome to initialize voting on the council proposal on devel ML (week from now)" I assume that refers in truth to getting nominations?
[17:48] <cm2> flocculant: do you know what the wireless issue is about? bug in iwlwifi?
[17:49] <flocculant> cm2: not really - not actually seen it or heard of it
[17:49] <flocculant> and people in *here* use intel and wireless and not heard them shouting either
[17:49] <flocculant> like ochosi for instance
[17:49] <cm2> flocculant: ok; but it's always after a suspend.
[17:49] <flocculant> yup
[17:50] <cm2> flocculant: not in general. and restarting NM fixes it.
[17:50] <cm2> so not the end of the world.
[17:50] <flocculant> I did point skjones at something
[17:50] <flocculant> right - that's what I found
[17:50] <cm2> i was looking through the power manager code, and there is a wait for a network manager dbus call.
[17:51] <cm2> because it doesn't happen when issuing a "systemctl suspend"
[17:51] <flocculant> given it's *buntu not just us - then that's definitely not something we'd be looking at specifically
[17:51] <cm2> xfce4-power-manager
[17:51] <cm2> flocculant: or do you mean you heard of the wireless thing from other *buntus?
[17:52] <flocculant> www.debugpoint.com/2016/05/quick-fix-no-wireless-connection-after-sleep-suspend-in-ubuntu-16-04-xenial-xerus/ and the bugs appear to be *buntu
[17:53] <flocculant> also not sure I saw that when checking out the cursor issue on my dead and dying lappy
[17:53] <cm2> flocculant: speaking of which, the xna vs sna doesn't help me
[17:53] <cm2> odd because it seems to work for everyone else
[17:54] <flocculant> cm2: ok - it was just something I saw while looking through 6 million reports (it felt like)
[17:54] <flocculant> I think that the vt change is the best one generally
[17:54] <cm2> flocculant: :) so i won't tell you about my flickering lightdm
[17:55] <flocculant> and the sna issue seems to cause other problems too
[17:55] <flocculant> cm2: you can - I'll ask for the bug number :p
[17:55] <flocculant> and I'd love to see it tested with yak too
[17:55] <flocculant> just to check that
[17:55] <cm2> flocculant: will do.
[17:56] <flocculant> awesome
[17:56] <cm2> flocculant: long weekend here, so maybe i'll have some time
[17:56] <flocculant> :)
[17:56] <flocculant> same here
[18:01] <flocculant> cm2: you appear to be about a bit at the moment - I assume you know that our testing/qa team is always looking for people who're not just drive-by testers?
[18:02] <flocculant> (and I think I recognise from ubuntuforum - or might be coincidence of course)
[18:06] <cm2> flocculant: yes i know.
[18:06] <cm2> i'm a dev. thinking that maybe i should help with code?
[18:07] <flocculant> I'm sure that bluesabre and Unit193 would love to know that and have some help :)
[18:07] <flocculant> maybe send a mail to the dev list offering - they're not about till later in the *day*
[18:07] <flocculant> not sure what tz you are
[18:07] <cm2> flocculant: ok; i've been putting this off for like 5 years it seems like ;)
[18:08] <cm2> all the while enjoying my xubuntu experience
[18:08] <flocculant> and frankly more dev help trumps testing - unless you're not testing your code and/or fixes :p
[18:09] <flocculant> cm2: funnily enough I've been about more or less as long as you (gnome2/unity change)
[18:09] <cm2> flocculant: :)
[18:09] <cm2> although dont remind me. that was painful at first.
[18:09] <flocculant> yup
[18:09] <cm2> xubuntu has come a long way!!
[18:09] <flocculant> it certainly has :)
[18:10] <cm2> flocculant: btw, the thunar crashing thing, was it whilst renaming files?
[18:10] <flocculant> cm2: seems so - I can do that if I keep at it for a while
[18:11] <flocculant> but general re-naming I don't see it
[18:11] <cm2> flocculant: i already saw a patch for it.
[18:11] <flocculant> knome was seeing it often
[18:11] <flocculant> cm2: we applied a couple/few patches - which is what we have in yak ppa afaik
[18:12] <cm2> flocculant: ah ok. i'm looking at it now, g_file_monitor and friends.
[18:12] <flocculant> if that's the case ( bluesabre Unit193 ) ^^ then if we SRU it needs to be in yak?
[18:13] <cm2> flocculant: it might be in it already
[18:13] <flocculant> cm2: seems that thunar activity in xfce is 'low'
[18:13] <cm2> flocculant: yes, but mostly it's because it is stable.
[18:13] <flocculant> cm2: I think we do have those patches - but I got lost between what we found pre-release and now
[18:14] <flocculant> and it's harder still because I have to manically rename things to crash it
[18:14] <cm2> flocculant: yeah, i've been trying to crash it but to no avail :)
[18:15] <flocculant> well that's good :)
[18:15] <cm2> flocculant: he he he yes.
[18:15] <flocculant> ok - evening time - disappearing for a while - be back later
[18:16] <cm2> flocculant: have fun
[18:16] <flocculant> well ... mostly food needed :p
[18:16] <cm2> :)
[22:18] <bluesabre> evening all
[22:18] <knome> hello
[22:19] <flocculant> hi bluesabre
[22:20] <bluesabre> hey knome flocculant
[22:20] <bluesabre> how's it going?
[22:20] <knome> not too shabby
[22:20] <flocculant> as good as expected :)
[22:20] <bluesabre> better than I hoped :D
[22:21] <flocculant> ha ha
[22:23] <Unit193> bluesabre!
[22:23] <bluesabre> hey Unit193
[22:24] <bluesabre> I'll start catching up from all the pings this week soon
[22:27] <Unit193> \o/
[22:27] <Unit193> I dumped off a packaging thing for you. :P
[22:29] <knome> Unit193 and the big dumb
[22:29] <knome> ...i mean dump
[22:29] <knome> (;
[22:29] <Unit193> knome haates me again. :'(
[22:29] <knome> noooo
[22:29] <knome> me loves you
[22:29] <knome> :D
[22:29] <Unit193> >_>
[22:29] <Unit193> KEEP BACK!
[22:30] <knome> ahahah
[22:30] <flocculant> hah
[22:30] <bluesabre> yeah, saw that, decided to keep it on the backburner til I made it to the weekend :D
[22:30] <Unit193> Ahaha. :D
[22:30] <Unit193> bluesabre: I got the others up!  Well, kind of ignored panel plugins because meh.  Xfconf might be fixed though.
[22:30] <bluesabre> saw that too, good news from aliov
[22:31] <flocculant> that's all great - personally I'd love to know what's going to happen about intel lock cursor fail :p
[22:32] <Unit193> Nothing I can do, and you certainly don't want me to try patching core things like that...
[22:33] <flocculant> Unit193: wfm
[22:33] <flocculant> or rather I've not got the problem so go for it :p
[22:33] <bluesabre> flocculant: I don't really know what to do with that, not touching the kernel, probably shouldn't change intel defaults for everybody
[22:33] <flocculant> Unit193: or are you talking about interesting stuff :D
[22:33] <flocculant> bluesabre: I agree with that :)
[22:34] <Unit193> that == intel drivers.
[22:36] <Unit193> bluesabre: I'm presuming http://paste.openstack.org/show/505960/ is of no importance.
[22:39] <Unit193> flocculant: Want to test xfconf before I copy it into xubuntu-dev/xfce4-gtk3? :P
[22:39] <Unit193> (I hit http://paste.openstack.org/show/505957/ too, but that's actually of no interest to us anyway.)
[22:42] <flocculant> Unit193: not right now ;)
[22:58] <bluesabre> Unit193: looks important
[22:59] <Unit193> :3
[23:00] <Unit193> Well, gtk/gnome stuff/etc always output warnings all over, so wasn't a surprise and the desktop worked. :P
[23:06] <bluesabre> fair enough :)


[01:29] <Nico__> hola
[12:22] <trijntje> Hi all, is https://wiki.ubuntu.com/Unity/Lenses still up to date? I noticed the code on there is C, while the wikipedia-lens tutorial uses Python
[12:29] <sil2100> hm
[12:30] <sil2100> larsu: indicator-appmenu is failing to build in staging for quantal it seems
[12:32] <sil2100> Trevinho: ping
[12:32] <Trevinho> sil2100: pong
[12:33] <sil2100> Trevinho: it seems that (probably) after commit 227 to lp:indicator-appmenu, indicator-appmenu stopped building for staging - do you know what could be the reason?
[12:33] <Trevinho> sil2100: looking
[12:33] <sil2100> It can't seem to find references to g_object_unref and etc.
[12:33] <sil2100> https://launchpadlibrarian.net/126400947/buildlog_ubuntu-quantal-amd64.indicator-appmenu_12.10.4daily12.12.14-0ubuntu1%2Bbzr226pkg0quantal2_FAILEDTOBUILD.txt.gz
[12:44] <larsu> sil2100, PKG_CHECK_MODULES for HUD is missing gobject-2.0
[12:44] <larsu> which is weird, I would have thought gio pulls that as a dependency
[12:44] <larsu> or dbusmenu ..
[12:46] <sil2100> Didn't know you had to explicitly ask for gobject-2.0, since I saw gio-2.0 deps in the configure's
[12:47] <larsu> yeah I don't think its necessary, let me dig deeper :)
[12:48] <larsu> no its not necessary, `pkg-config --libs gio-2.0` gives -lgobject
[12:48] <larsu> (among others)
[12:50] <larsu> sil2100, is there a way to rerun this with `make V=1`? I can't reproduce it locally
[12:50] <sil2100> larsu: I was able to reproduce it on my quantal system, when I did apt-get source from staging and tried building it with bzr bd
[12:51] <larsu> oh, thanks
[12:51]  * larsu only tried building upstream
[12:56] <sil2100> Maybe it's a packaging problem, but I didn't see anything strange
[12:57] <larsu> sil2100, I still can't reproduce it :-(
[12:57] <sil2100> larsu: are you using quantal?
[12:57] <larsu> no, raring
[12:58] <larsu> which might be the issue?
[13:04] <sil2100> I think so, hm, since latest indicator-appmenu seems to build correctly on raring
[13:04] <sil2100> `pkg-config --libs gio-2.0` on quantal gives -lgio-2.0 -lgobject-2.0 -lglib-2.0
[13:04] <sil2100> So hm, not sure what might be wrong?
[13:05] <larsu> sil2100, can you compile it with `make V=1` (or configure with --disable-silent-rules)
[13:06] <larsu> so that we can see whether the right libs get passed
[13:07] <sil2100> gcc -I/usr/include/libdbusmenu-glib-0.4 -I/usr/include/libbamf3 -I/usr/lib/x86_64-linux-gnu/libbamf3/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wall -Werror -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -Wl,-z -Wl,defs -Wl,--as-needed -o hud-verify-app-info hud_verify_app_info-create-db.o hud_verify_app_info-load-app-info.o
[13:07] <sil2100> Ok, here it doesn't seem to add -lgobject-2.0, so maybe I'll have to add it to the dependencies indeed
[13:08] <larsu> hm, all libraries are missing from that line
[13:08] <larsu> except glib
[13:08] <larsu> oh, no, that's include as well
[13:12] <sil2100> Ah, wait, I think I see the problem
[13:12] <larsu> sil2100, wait! this build is 12.12.14, which is *before* the 227 commit
[13:12] <sil2100> (not sure why it works for raring)
[13:13] <sil2100> larsu: it's hm, based on revision 226 - strange thing!
[13:13] <sil2100> You're right
[13:14] <sil2100> So it doesn't have Trevinho's latest commit that adds the deps
[13:14] <larsu> yep, gio isn't in there yet
[13:15] <larsu> dbusmenu should pull it I think, but it doesn't: `pkg-config --libs dbusmenu-glib-0.4` --> -ldbusmenu-glib
[15:10] <lborda> Hi Guys, does anybody have a clue about this issue on precise? This happens on precise https://bugs.launchpad.net/ubuntu-advantage/+bug/1090919
[15:11] <lborda> sorry that's the right one: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1096954
[16:09] <didrocks> hey sil2100, how are you?
[16:19] <didrocks> sil2100: didn't check the merge request, going to have a breakfast right now, but can you please refresh me by email on the flackyness of the indicator test?
[17:00] <didrocks> sil2100: hey, I'm back :)
[21:59] <cwayne1> davidcalle: ping
[22:06] <davidcalle> cwayne, pong
[22:06] <davidcalle> cwayne1, pong
[22:09] <cwayne1> davidcalle: hey!  just wondering if theres anything i can do to help on ubuntu-scopes
[22:22] <fginther> mhr3, ping
[22:22] <mterry> Two hud autopkg tests are failing
[22:22] <mterry> https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/76/
[22:25] <sil2100> Yes, the one failed once before in the past
[22:26] <sil2100> The first one I mean
[22:26] <sil2100> The second, well...
[22:26] <mhr3> fginther, pong
[22:26] <sil2100> Trying to find what happened that suddenly those autopilot tests stopped being reliable
[22:26] <fginther> dee-ci job is fixed
[22:26] <fginther> mhr3, ^^
[22:27] <thomi> sil2100: one of those tests (this one: https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/76/label=autopilot-ati/testReport/junit/unity.tests.test_hud/HudBehaviorTests/test_app_activate_on_enter/) is poorly written
[22:27] <mhr3> fginther, great, thx
[22:27] <thomi> sil2100: it uses assertFalse, where it should use Eventually
[22:27] <thomi> (and assertThat)
[22:27] <thomi> (or assertProperty)
[22:30] <sil2100> thomi: right, that's true - but test_super_h for instance looks fine, but still it seems to not change the keybinding correctly
[22:31] <sil2100> Not much debugging for that though
[22:31] <thomi> sil2100: yeah, I don't know why that one's not passing...
[22:31] <sil2100> thomi: and for instance, in failure 75, test_hud_to_dash_has_key_focus fails even though the vid shows that everything is ok
[22:31] <thomi> sil2100: possibly you can increase the verbosity of unity for that test - that way you'll get some more information
[22:32] <didrocks> sil2100: you should go to bed :)
[22:32] <didrocks> sil2100: did you see that this test is not the only one failing?
[22:32] <sil2100> It fails on hiding the dash during cleanup!
[22:32] <didrocks> sil2100: if you switch back to some runs, some other tests are failing
[22:33] <sil2100> didrocks: yes, that's what I just told thomi - since those are really mostly different tests failing, which means that something is unreliable
[22:33] <didrocks> you're right
[22:56] <sil2100> thomi: maybe in the set_compiz_option the time.sleep(0.5) is not enough?
[22:58] <sil2100> thomi: not much we can do here, we could increase the wait here, but this would impact the speed and not give any guarantee, and still we won't have 100% certainity that it would help anyway
[22:59] <didrocks> sil2100: oh btw, if you need to launch the autopilot tests, just do it
[22:59] <didrocks> sil2100: don't wait for me on that, the machine are yours :)
[22:59] <sil2100> didrocks: you mean, on jenkins? ;)
[22:59] <didrocks> yep :)
[22:59] <didrocks> you can do it, right?
[22:59] <sil2100> didrocks: not sure, never tried before! ;p Is it done through jenkins?
[23:00] <didrocks> sil2100: yep, just this test
[23:00] <didrocks> sil2100: empty the package list if you want to test with the whole ppa content
[23:00] <didrocks> sil2100: meaning, unity
[23:01] <sil2100> didrocks: ok, I'll be firing tests there then
[23:01] <didrocks> sil2100: excellent!
[23:03] <sil2100> See you tomorrow!