[03:58] <bullgard4> [Symmetrical Multiprocessing, SMP]: Is there a tool that shows if an application program uses both processors on a particular two-processor SMP machine?
[04:07] <lifeless> bullgard4: do you mean 'does it have threads' ?
[04:10] <bullgard4> lifeless: No. I imagine that an application may either be processed by only one processor or by both.
[04:11] <stgraber> no, if your application has a single process it can't be using two CPUs
[04:11] <lifeless> stgraber: it can get scheduled to both, just not concurrently :P
[04:12] <stgraber> lifeless: right :)
[04:12] <lifeless> bullgard4: your question is essentially ill-defined in kernel terms, heck, even application isn't that well defined (I know single apps that have 10's of different images with 100's of processes active concurrently)
[04:13] <lifeless> bullgard4: I'm sure you are asking this as part of answering some larger issue/project - perhaps some context about that will help us answer you
[04:17] <bullgard4> May be referring to a more specific case will help me better to understand. Does pbzip2 load the two processor kernels while gzip, bzip2 do load only one?
[04:19] <lifeless> bullgard4: pbzip2 is probably threaded, so the kernel can schedule it onto multiple CPU's at once
[04:20] <lifeless> gzip and bzip2 are single threaded and can only be scheduled on a single cpu at a time
[04:23] <bullgard4> lifeless, stgraber: Thank you very much for your help.
[10:00] <Kano> hi, why does 2.6.28-8 depend on wireless-crda which is only in universe?
[10:05] <Kano> remove that depend please...
[10:05] <ivoks> is there a change hardy's latest kernel was compiled with an older version of gcc that we have in repository?
[10:05] <ivoks> which would make building kernel modules impossible?
[10:18] <persia> ivoks, Older version, no.  Older revision, yes.  It was built with the gcc that was available at the time it was built.
[10:19] <ivoks> persia: i'm aware of that...
[10:19] <ivoks> but, we can't build kernel modules if kernel doesn't get rebuild
[10:20] <ivoks> gcc in hardy is 4.2.4
[10:20] <ivoks> it was updates couple of months ago
[10:20] <ivoks> yet, the kernel is compiled with 4.2.3
[10:20] <persia> Hrm?
[10:20]  * persia looks
[10:20] <Kano> depends, you can even build the kernel with gcc 4.1.1 and then compile modules with 4.3
[10:20] <Kano> just not the other way around
[10:20] <persia> ivoks, Which arch?
[10:20] <ivoks> persia: i386
[10:21] <Kano> but then the linux-headers are not installable
[10:26] <persia> ivoks, For some reason I can't find the build log for 23.48, apparently in part because it's a security update.  Sorry not to be able to help.
[10:26] <ivoks> persia: right, that was security update
[10:29] <ivoks> persia: bug 292381
[10:29] <ubot3> Malone bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,Triaged] https://launchpad.net/bugs/292381
[10:29] <persia> ivoks, It may well have been built against 4.2.3 then, as I believe -security only has 4.2.3 and -updates has 4.2.4.
[10:29] <persia> ivoks, Trick being that for people only tracking -security, I think 4.2.3 is correct.
[10:29] <ivoks> i understand that
[10:29] <ivoks> that's a gcc bug
[10:30] <ivoks> gcc should never get version change during release
[10:30] <persia> Or at least never get any sort of ABI change.
[10:30] <persia> The version string isn't the important part.
[10:36] <ivoks> well
[10:36] <ivoks> i just did more digging
[10:37] <ivoks> kernel's 64bit buildd doesn't have gcc 4.2.4
[10:37] <ivoks> while 32bit buildd does
[10:47] <persia> ivoks, Found it: http://launchpadlibrarian.net/21747228/buildlog_ubuntu-hardy-i386.linux_2.6.24-23.48_FULLYBUILT.txt.gz shows gcc-4.2_4.2.3-2ubuntu7 : it's entirely due to skew between -updates and -security.
[10:48] <persia> Either needs two different kernels (one for -updates and one for -security) or to not have impactful variation.
[10:48] <ivoks> correct
[12:36] <lukehasnoname> I would be interested in someone could solve this problem:
[12:36] <lukehasnoname> http://www.nabble.com/Yaird-throws-error-about-bad-sr0-device-link-td21449825.html
[12:37] <lukehasnoname> I know it's not Ubuntu-kernel related, but perhaps it's a slow morning for someone who wants to help me out
[12:41] <soren> Why use yaird? What does it do that mkinitramfs doesn't?
[13:00] <lukehasnoname> >_> I'm using a video tutorial which stated using that tool. I'm not familiar with kernel building.
[13:00] <lukehasnoname> I googled the error I was getting and found that ml archive
[13:05] <alex_joni> lukehasnoname: googling I found some people having to update to a newer yaird version (with erros similar to yours), but I would do as soren suggest.. use mkinitramfs
[13:19] <lukehasnoname> I'll try it later. I've been awake 24 hours in studying for tests and finishing up a project proposal
[13:19] <lukehasnoname> thanks
[13:54] <ivoks> hi... are there any plans to support more than 8 cpus in hardy?
[13:55] <rtg> ivoks: debian/config/amd64/config.server:CONFIG_NR_CPUS=64
[13:55] <ivoks> ah, right
[13:56] <ivoks> so, only i386 supports 8
[13:56] <rtg> correct
[13:56] <ivoks> thanks
[13:56] <persia> rtg, WIth the lpia kernel merge, does linux-lpia now have the same modules and udebs as i386/amd64 or are there significant differences?
[13:57] <rtg> persia: udebs should be pretty close, but I'm not sure about all of the modules. The configs came over intact, so that likely hasn't changed.
[13:58] <persia> Thanks.  I'm thinking some bugs I was thinking of filing may have become obsolete, but I'll retest, and maybe file.
[13:59] <rtg> persia: who is the archive admin today? I need to get wireless-crda promoted to main
[14:00] <persia> rtg, You already have an approved MIR?
[14:00] <rtg> yep, hang on.
[14:00] <persia> https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days says nobody is the offical archive-admin on Fridays.
[14:01] <rtg> persia: which is why I asked
[14:01] <rtg> https://bugs.launchpad.net/ubuntu/+bug/325801
[14:01] <ubot3> Malone bug 325801 in ubuntu "Main inclusion request: wireless-crda" [Undecided,In progress]
[14:01] <persia> So just beg in #u-d and any of the team might be able to help (including the few who don't have days).
[14:03] <persia> Theoretically anyone in https://launchpad.net/~ubuntu-archive/+members ought to be able to do it.
[14:03] <rtg> persia: thanks, I'll see whom I can annoy.
[14:04] <rtg> actually, I thought you were on that list.
[14:05] <persia> No.  I signed up for enough of those "it sounded like a good idea at the time, but it's a bunch of work" things already :)
[14:05] <rtg> I hear yuo :)
[15:25] <Kano> rtg: you forgot my patch, you only need to apply it then you get a quickcam.ko as you still have it enabled in the config
[15:26] <rtg> I did not forget, I just didn't do it yet.
[15:26] <Kano> also i had to revert one config
[15:27] <Kano> as you depend on something now which is only in jaunty universe
[15:28] <Kano> wireless-crda is not even in main...
[15:28] <Kano> of course i used =y
[15:29] <Kano> and removed that depend
[23:24] <BUGabundo> hi
[23:24] <BUGabundo> is any kernel dev awake around here?
[23:25] <BUGabundo> if it wasn't to much trouble
[23:25] <BUGabundo> could some one take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/329254
[23:25] <ubot3> Malone bug 329254 in linux "kernel: [  341.030356] Pid: 0, comm: swapper Tainted: P        W  2.6.28-7-generic #20-Ubuntu" [Undecided,New]


[00:03] <valorie> @RikMills that page hasn't worked for me all day
 @valorie, The author broke it trying to change it, and hasn't had a chance to fix yet.
[00:06] <valorie> yeah
[00:06] <valorie> I like the idea
[00:06] <valorie> but IMO it will be hard to keep current
 Oh wow, that page on KDE is awesome 🥰
 (Photo, 1280x960) https://irc-attachments.kde.org/6i92Q8dN/file_20433.jpg
 (Photo, 1280x960) https://irc-attachments.kde.org/tpyVdXAy/file_20434.jpg
 valoriez
 @valorie, It is deliberately limited to just a few, so perhaps not
 Page is back up anyway.
[20:53] <valorie> cool
[20:53] <valorie> @ahoneybun that's amazing
 Yep!
[20:54] <valorie> @RikMills that page is gorgeous
 Oh yeah! That gets a +1 from me


[05:34] <mgedmin> hm, so the gnome-control-center-2.0.mo is shipped by the gnome-control-center-data package in the gnome3-staging ppa, rather than by a locale pack
[05:58] <mgedmin> whoa, the minimum ram requirement for the 16.10 livecd is just 384 MB?
[08:42] <altin> Where do I find the custom keybindings file?
[08:42] <altin> I created some keybindings via gui
[08:42] <altin> but I want to find the config file
[08:52] <pchoo> Hi all, what will be the expectation for Optimus laptops with NVidia gfx cards in Ubuntu Gnome 16.10?
[10:26] <geoff10000> hi all. How do ensure new windows are placed in the middle of the screen in Gnome 3.22?
[10:26] <geoff10000> currently, they open top left corner
[13:01] <mgedmin> altin: custom keybindings are saved in dconf
[13:02] <mgedmin> try dconf dump / to see ALL THE SETTINGS
[13:04] <jbicha> mgedmin: where do you see the 384MB? https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/UbuntuGNOME says 1.5GB
[13:06] <mgedmin> boot the livecd, press any key at the very earliest syslinux screen, hit F1 for help, hit F2 for minimal system requirements
[13:06] <mgedmin> the syslinux help files are full of ancient advice from the elders (on thinkpads pass a special 'floppy' parameter etc.)
[13:11] <jbicha> mgedmin: well, is it possible to run the live iso with 384 MB of RAM? You can test in VirtualBox. If not please file a bug about that
[13:12] <jbicha> I don't think even Lubuntu would recommend installing a system with that little RAM though
[13:15] <mgedmin> do you remember which package ships the .txt files with syslinux help?
[13:15] <mgedmin> afaiu they're shared between all flavours (at least one of the help pages says something of the kind)
[13:20] <jbicha> mgedmin: no to the first question but maybe you could ask in #ubuntu-installer ; and yes, it's shared


[14:39] <Darael> Mentioning in here because it's not an emergency, but it is irritating:  We've got a user in #ubuntu who is being really quite unhelpful, snarking at someone who has a broken system and claiming to have given the most helpful advice of anyone ("give up and reinstall").
[14:39] <bazhang> nick?
[14:40] <Myrtti> usually it helps us to pinpoint things if nicks are mentioned, yes
[14:40] <Darael> kx
[14:40] <Darael> Apologies; my brain seems to be slow.


[03:44] <horace_ubuntu> bspencer, ping
[03:45] <bspencer> horaceli !  imagine finding you here
[03:45] <bspencer> ok.  there were a few ideas for 8+sec mail
[03:45] <bspencer> one was to use dpkg-divert
[03:46] <bspencer> and run the cache updater and hten dpkg
[03:47] <horaceli> there is no existed cache updater at present, and we need to create one, right?
[03:49] <bspencer> and lool said something about triggers "soon"
[03:49] <horaceli> I have read the mail loop, yes
[03:49] <horaceli> he mentioned that
[03:49] <horaceli> just I am thinking what do we need to cache
[03:49] <bspencer> so those are the two options to get notified.   Then, correct, we need to define the cache and the cache updater
[03:49] <bspencer> let's chat about that
[03:49] <bspencer> - flat file with a list of apps, prog, icon
[03:50] <bspencer>  - sqlite db -- overkill?
[03:50] <bspencer>  - xml file
[03:50] <horaceli> currently, gnome-menu read through *.menu file, which is XML formatted
[03:50] <bspencer>  - binary (speedy, hard to debug)
[03:50] <bspencer> horaceli: but slow, true?
[03:51] <horaceli> right, 'cause it parsed every tag in XML
[03:51] <bspencer> of course our cache could be a single file, read all in at once.  It won't be that big
[03:51] <horaceli> and stored then and build up a huge tree.
[03:51] <bspencer> even with 200 apps, should be <.5s
[03:51] <bspencer> I'm hoping for .5s
[03:51] <horaceli> I have verified on C2D based computer,
[03:51] <horaceli> building up applications list by gnome-menu interface takes 1.8s
[03:52] <bspencer> C2D?
[03:52] <horaceli> so I am not sure what we should cache for next time usage
[03:52] <horaceli> Core 2 Duo
[03:53] <bspencer> we should put:   Label, Icon path, Prog path+parms, X-osso.
[03:53] <bspencer> ...but, what if user changes locale?
[03:53] <bspencer> then we're hozed.
[03:53] <horaceli> I am thinking whether or not we could simply parse XML formatted .menu file
[03:54] <horaceli> and then read through <AppDir> & <DefaultAppDir> that are defined in .menu file
[03:54] <bspencer> yes, ok.  I could be wrong.  For example, we have to know the category from the menu files.
[03:54] <horaceli> yes
[03:54] <horaceli> we can
[03:55] <horaceli> sorry, I misunderstand your last sentence.
[03:55] <bspencer> and also read gconf value each time on startup.
[03:56] <bspencer> horaceli: so if we put all the info into a single file for all apps, one-line per app, we should see improvement.   But this is a read-only solution.
[03:56] <bspencer> we can't update very easily when a pkg changes.
[03:57] <bspencer> without re-reading all the .desktop files again.
[03:57] <bspencer> which adds 8sec to each pkg add/remove
[03:57] <bspencer> (although perhaps that is a rare event in UME land)
[03:57] <bspencer> are we sure our 8sec isn't just bad coding?
[03:58] <horaceli> bspencer, if we put all info into one single file.
[03:58] <horaceli> it would make default .menu files and menu spec useless (I feel)
[03:58] <bspencer> that's a long time to read 50 .desktop files.
[03:59] <horaceli> bspencer, yes, I know. we suspsect it too, thnking of if it is caused by bad coding
[03:59] <horaceli> I have inspect our loop several times
[03:59] <horaceli> and moved out two general operations (reading strings and flags from gconf) out of the loop
[04:00] <horaceli> and it could save 2s and I mentioned that in mail
[04:00] <horaceli> I could ask Frank's help to help review the code
[04:00] <horaceli> for double insurance.
[04:00] <horaceli> but I did look into  gnome-menu code
[04:00] <horaceli> yesterday
[04:00] <bspencer> Q:  if someone adds a new pkg today in UME, will it show up in menu?
[04:01] <bspencer> or do they have to restart X?
[04:01] <horaceli> I have no answer to it at present.
[04:02] <bspencer> what about changing locale?  If we put all info into a flat file and hte user changes locale, the strings won't change
[04:03] <bspencer> Terminal|Application|uxterm -fa Monospace -fs 12|UTF-8|xterm|Application;Utility|org.moblin.xterm|GNOME;Mobile;|xterm
[04:03] <bspencer> ...
[04:03] <horaceli> bspencer, I am in #moblin too
[04:04] <horaceli> talking about bug scrubs
[04:04] <horaceli> now back
[04:04] <bspencer> ah
[04:04] <horaceli> btw, you have several bugs and I have accepted them
[04:05] <bspencer> oh!  thx.
[06:33] <dholbach> good morning
[09:27] <davmor2> 20080421.1 image doesn't match the md5sum again
[16:44] <lool> Hey bspencer
[16:45] <lool> bspencer: We have that urgent issue with xul 1.9 for which you received a couple of emails :)
[16:45] <lool> bspencer: Do you think you could find someone to look into it today?
[18:15] <persia> I've been browsing http://moblin.org/repos/releases/ and updated a couple packages in my PPA.  Are there any special procedures before pushing to the team PPA?
[18:16] <agoliveira> persia: As long as you're in the team you should be able to dput it.
[18:16] <persia> agoliveira: I can, but if there was a VCS for packaging in place, I'd want to update that as well, etc.
[18:17] <agoliveira> persia: VCS?
[18:17] <persia> Version Control System (likely bzr in this case)
[18:18] <agoliveira> persia: Oh, I see. Not really. PPA will have your packages for testing and people with the power to upload to the repositories will do it if needed.
[18:19] <agoliveira> persia: You know, all the MOTU, coredev stuff.
[18:19] <persia> agoliveira: OK.  Just checking.  I'm not tempted to upload to the repos just now, as these are new upstreams, and likely don't match the specific criteria for the hardy release in a couple days :)  I'll push the packages to the team PPA then.  Thanks.
[18:20] <agoliveira> persia: My pleasure
[19:11] <ian_brasil> hey...anyone see this report about nokia sponsoring ubuntu on arm? http://www.linuxdevices.com/news/NS2097004728.html
[19:15] <agoliveira> ian_brasil: Yep, we've being talking about it a few days ago. There was a rumor around for some time BTW.
[19:19] <ian_brasil> putz...trust me to be the last one to know  :)
[20:57] <dantalizing> hi folks. i installed hildon-desktop, but applets are not showing....what needs to happen for them to show?
[20:58] <dantalizing> other than them being installed
[21:04] <tremolux> lool: where was that RSS feed to track new releases at gnome?
[21:20] <lool> tremolux: Yes
[21:20] <lool> tremolux: http://download.gnome.org/LATEST.xml
[21:21] <tremolux> lool: thx!
[21:21] <lool> dantalizing: That's a known bug
[21:21] <lool> dantalizing: Since we moved to xul 1.9
[21:21] <lool> dantalizing: It's being worked on by bspencer, asac and StevenK
[21:21] <dantalizing> ah..thx lool
[21:22] <lool> persia: Only hildon packages are in bzr AFAIK
[21:22] <lool> persia: Concerning moblin modules, you can probably upload
[21:22] <lool> persia: As long as they work :)
[21:23] <PaowZ> hi there
[21:24] <PaowZ> anybody there ?
[21:24] <lool> Nope
[21:24] <PaowZ> cool :)
[21:25]  * GrueMaster is only present in ghost form
[23:49] <dantalizing> how do i get the application launcher shown here? http://www.moblin.org/toolkits/basicDevGuides/simpleApp/toolkits_DevGds_simpleApp_understandHildon.php


[03:40] <pitti> Good morning
[04:36] <mlankhorst> g'daaay
[05:46] <didrocks> good morning
[05:46] <pitti> bonjour didrocks
[05:47] <didrocks> bonjour pitti, comment ça va?
[05:48] <pitti> didrocks: ça va bien, merci ! Je me suis levé tôt aujourd'hui, avec ma femme
[05:48] <pitti> didrocks: et toi ?
[05:49] <didrocks> pitti: ça va bien, on dirait que le temps n'est pas si horrible que ça, un peu de soleil malgré les nuages :)
[05:49] <pitti> ooh!
[05:50] <veebers> didrocks: ping
[05:50] <pitti> didrocks: enfin, tu vas avoir l'été ? :-)
[05:50] <didrocks> pitti: il faut croire, au moins aujourd'hui :)
[05:50] <didrocks> hey veebers!
[05:51] <didrocks> veebers: thanks for your MP on the testsuite listing :)
[05:51] <veebers> how goes it didrocks?
[05:51] <veebers> didrocks: heh no problem, hopefully it's helpful
[05:51] <didrocks> veebers: I'm doing good, thanks. Yourself?
[05:51] <veebers> didrocks: hmm, had a day scratching my head WRT to a couple of the autopilot functional tests failing in the jenkins job
[05:52] <veebers> didrocks: which is why I bother you now, it appears that with a i386 install the tests fail, using a amd64 install they pass no problems
[05:52] <didrocks> veebers: interesting, normally, it's more the other way around :)
[05:52] <didrocks> veebers: do you have a link?
[05:53] <veebers> (this is WRT to the email that sil2100 sent)
[05:53] <didrocks> ah, just got to it (60 emails in the morning, can't be that efficient)
[05:53] <didrocks> one sec!
[05:53] <veebers> didrocks: I don't have a link to the passing job as there is not one, I'm manually manipulating the machine, but there is a link to the failing one in the email :-)
[05:53] <didrocks> ah ok, those ones
[05:53] <thomi> didrocks: only 60?
[05:53] <thomi> :P
[05:54] <didrocks> thomi: in inbox :p
[05:54] <thomi> didrocks: right
[05:54] <didrocks> then, I don't count the bugs, MP, ML… :p
[05:54] <thomi> didrocks: me neither :P
[05:54] <didrocks> heh ;)
[05:54] <didrocks> ok, the good thing is that it's reproducible everyday on both intel and ait
[05:54] <didrocks> ati*
[05:54] <didrocks> so, if I bzr branch lp:autopilot
[05:54] <didrocks> and run the tests
[05:55] <didrocks> I won't see those on my amd64?
[05:55] <thomi> didrocks: the entire autopilot test suite passes for both veebers and myself, and on an amd64 machine veebers has going in the QA lab, and on a VM
[05:56] <thomi> didrocks: None of us have an i386-installed machine, so it took us a while to think about trying that
[05:56] <didrocks> thomi: can I run tip trunk in my session without being scared?
[05:56] <thomi> didrocks: yes, it's fine
[05:56] <veebers> didrocks: yep
[05:56] <thomi> didrocks: trust me :P
[05:56] <veebers> oh, thomi you bet me to it :)
[05:56]  * thomi quickly pushes some code to trunk :)
[05:56] <didrocks> ahah :p
[05:57] <didrocks> thomi: veebers: bin/autopilot run autopilot/tests/ ?
[05:57] <veebers> didrocks: I'm about to try a i386 VM, but waiting for iso
[05:57] <thomi> bin/autopilot run autopilot.tests
[05:57] <didrocks> oh right
[05:57] <veebers> didrocks: autopilot run -v autopilot.tests.functional.test_input_stack.TouchTests
[05:57] <thomi> or that
[05:57] <veebers> didrocks: that is for 2 of the 3 failing
[05:57] <thomi> but I guess you want *all the tests*
[05:57] <didrocks> yeah, I prefer to see all the tests, if this has an impact :)
[05:58] <didrocks> (running btw)
[05:58] <veebers> didrocks, thomi I'll be back in a little bit. Need to do the grocery shop and have tea :-)
[05:59] <didrocks> veebers: sure, enjoy!
[05:59]  * veebers hates the supermarket
[05:59] <veebers> :-P
[05:59] <didrocks> don't enjoy then :p
[05:59] <veebers> didrocks: cheers
[05:59] <veebers> o_0
[06:04] <didrocks> thomi: ok, I have a lot of failures, but I think it's not related to that :)
[06:04] <didrocks> thomi: some surely due to autopilot-gtk not being installed I guess
[06:04] <thomi> didrocks: ahhh, you're missing some deps then
[06:04] <didrocks> and a lot of getcwd() failing
[06:05] <didrocks> interesting
[06:05] <didrocks> it rmed my trunk!
[06:05] <didrocks> zomg :p
[06:05] <thomi> didrocks: check out the deps listed in debian/control for the python-autopilot-tests
[06:05] <thomi> packahe
[06:05] <didrocks> maybe /tmp/autopilot wasn't the right place to put it :)
[06:06] <thomi> didrocks: that should work fine
[06:07] <didrocks> thomi: weird that the directory was removed once the test finishes though :p
[06:07] <thomi> didrocks: really?
[06:07] <didrocks> yeah
[06:07] <didrocks> I bzr branch lp:autopilot in /tmp
[06:07] <didrocks> cd /tmp
[06:07] <didrocks> bin/autopilot …
[06:07] <didrocks> and /tmp/autopilot was removed
[06:07] <didrocks> hence all the getcwd() error I guess
[06:07] <didrocks> thomi: maybe you use that directory somewhere as a temporary placeholder?
[06:08] <thomi> didrocks: ahhhhhh
[06:08] <thomi> didrocks: yes, now that I think about it
[06:08] <didrocks> :p
[06:08] <thomi> didrocks: file a bug if you like
[06:08] <didrocks> thomi: with pleasure! :-)
[06:09] <thomi> :)
[06:09] <didrocks> thomi: ok, I don't have python-evdev
[06:09] <didrocks> let me see if it's in the ppa
[06:09]  * didrocks steals
[06:09] <thomi> should be
[06:10] <didrocks> thomi: I'm getting now UInput: UInputError('"/dev/uinput" cannot be opened for writing',)
[06:11] <didrocks> (on the autopilot.tests.functional.test_input_stack.TouchTests)
[06:11] <didrocks> which is still different from what the error was on the tests
[06:11] <thomi> didrocks: on sec
[06:11] <thomi> just in a call
[06:12] <didrocks> sure :)
[06:12]  * didrocks opens the bug meanwhile
[06:13] <didrocks> thomi: bug #1182755 FYI
[06:13] <ubot2> Launchpad bug 1182755 in Autopilot "autopilot removes /tmp/autopilot while running its testsuite" [Undecided,New] https://launchpad.net/bugs/1182755
[06:14] <thomi> didrocks: so to fix your permissions issue, you can build the package and install python-autopilot
[06:15] <thomi> didrocks: it will add you to the autopilot group
[06:15] <thomi> didrocks: which will give you the permissions you need
[06:15] <didrocks> thomi: ah ok
[06:15] <didrocks> doing that now
[06:15] <thomi> didrocks: or you can do it manually I guess
[06:15] <didrocks> thomi: hum, let's have the autopilot package installed anyway
[06:22] <didrocks> thomi: ok, logging out and back now that I have all the deps installed
[06:22] <thomi>  \o/
[06:24] <didrocks> thomi: keep getting:
[06:24] <didrocks> 08:23:56.041 WARNING __init__:185 - Caught exception while searching for autopilot interface: 'DBusException("Could not get PID of name 'org.freedesktop.DBus': no such name",)'
[06:24] <didrocks> (running autopilot run -v autopilot.tests.functional.test_input_stack.TouchTests)
[06:24] <didrocks> with the installed tip trunk of autopilot, and installed tests
[06:27] <thomi> didrocks: and the test fails?
[06:28] <didrocks> thomi: yep, with an unsurprising RuntimeError: Unable to find Autopilot interface.
[06:28] <thomi> didrocks: I'm afraid I need to go to dinner, we have guests, but perhaps you can email me the details? I can assure you that the tests all pass for me... I suspect there's some odd library issue going on
[06:28] <thomi> but that seems really odd. veebers tested with a fresh VM and it worked perfectly
[06:29] <didrocks> thomi: well, it was just to double confirm the failure on we have while tests are executing
[06:29] <didrocks> thomi: you will continue with an i386 machine I guess?
[06:29] <didrocks> thomi: basically, this is what today is blocking all the stacks to go to saucy
[06:29] <didrocks> (touch included)
[06:29] <didrocks> no pressure ;)
[06:30] <thomi> didrocks: if it's that important, just disable those three tests. We know they pass for amd64, and I'm pretty confident in the quality of the code.
[06:30] <didrocks> thomi: ok, we can do that, indeed
[06:30] <didrocks> or have a trigger of 4 tests failing
[06:30] <thomi> didrocks: probably the best idea at the moment, especially since I'm kinda busy these days
[06:30] <thomi> didrocks: 3 tests
[06:30] <didrocks> thomi: no, 4 ;)
[06:31] <thomi> didrocks: we already fixed one of the failures yesterday, but after your last run was triggered
[06:31] <didrocks> ah ok
[06:31] <thomi> didrocks: so we're down to 3
[06:31] <didrocks> thomi: so I'll put the trigger to 3
[06:31] <didrocks> so that we don't disable them in trunk
[06:31] <didrocks> thomi: but then, we'll need to tackle that I guess
[06:31] <thomi> ok
[06:31] <thomi> anyway, I gotta go. Talk to you later
[06:31] <didrocks> thomi: enjoy your dinner!
[06:48] <jibel> good morning
[06:48] <didrocks> hey jibel !
[06:48] <jibel> salut didrocks !
[06:54] <didrocks> jibel: jenkins isn't really happy right now :(
[06:54] <didrocks> jibel: all the prepare jobs are red (even if the upload to the ppa was successful)
[06:54] <didrocks> /var/lib/jenkins/jobs/cu2d-oif-head-1.1prepare-frame/builds/2013-05-22_02-01-23/archive is empty though
[06:55] <didrocks> so that's why have:
[06:55] <didrocks> Archiving artifacts
[06:55] <didrocks> ERROR: No artifacts found that match the file pattern "*xml". Configuration error?
[06:55] <didrocks> ERROR: '*xml' doesn't match anything
[06:56] <didrocks> the xml are there though in the workspace: /var/lib/jenkins/cu2d/work/head/oif/
[06:56] <didrocks> pitti: bon ben voilà… c'est plus l'été ici :(
[06:57]  * didrocks will ask for refunding from the weather master
[07:01] <Mirv> jenkins also seemed to be down earlier
[07:04] <didrocks> Mirv: ah, let me try to rerun a prepare then
[07:05] <didrocks> Mirv: no, still the same issue :/
[07:05] <Mirv> ok :(
[07:06] <jibel> didrocks, looking
[07:06] <didrocks> Mirv: since the sprint, we are quite unlucky, it was really stable beforehand
[07:17] <jibel> didrocks, it doesn't make sense workspace is set to WORKSPACE=/var/lib/jenkins/jobs/jenkins-autocheck/workspace while it should be /var/lib/jenkins/jobs/cu2d-oif-head-1.1prepare-frame/workspace
[07:17] <jibel> or the name of the project
[07:18] <didrocks> jibel: hum, maybe that's when we relaunch prepare directly
[07:18] <didrocks> jibel: as we inherit fro m
[07:18] <didrocks> from the parent*
[07:19] <didrocks> jibel: one sec, trying the parent
[07:19] <didrocks> hum still WORKSPACE=/var/lib/jenkins/jobs/jenkins-autocheck/workspace
[07:20] <didrocks> jibel: waitonstack is in the right ws though
[07:20] <didrocks> Building on master in workspace /var/lib/jenkins/jobs/cu2d-oif-head-0waitonstacks/workspace
[07:20] <didrocks> ah that doesn't mean anything
[07:20] <didrocks> Building on master in workspace /var/lib/jenkins/jobs/cu2d-oif-head-1.1prepare-frame/workspace
[07:20] <didrocks> but waitonstack didn't fail, so I think the relative dirs were ok
[07:22] <didrocks> WORKSPACE=/var/lib/jenkins/jobs/jenkins-autocheck/workspace
[07:22] <didrocks> jibel: for waitonstack ^
[07:24] <seb128> hey desktopers
[07:24] <didrocks> salut seb128!
[07:25] <jibel> didrocks, this is a problem with the master node, even the most simple job inherit from this workspace
[07:26] <didrocks> jibel: some workspace root directory?
[07:27] <jibel> didrocks, my guess would be that someone restarted jenkins with this variable set in his environment
[07:27] <jibel> but that's just a guess
[07:27] <didrocks> jibel: oh, and that override everything? Mirv mentionned that jenkins was down earlier
[07:29] <Mirv> didrocks: jibel it seemed like down at least, but I cannot be sure if it was VPN or jenkins itself
[07:29] <jibel> didrocks, I'll restart master with a clean env, do you need to wait for webapp-head?
[07:30] <didrocks> jibel: I have no hope for webapp, so kill please :)
[07:53] <pitti> didrocks, jibel: OOI, how's otto behaving in the DC?
[07:54] <didrocks> pitti: we are more fighting with jenkins issues (env not being good) for now…
[07:55] <jibel> pitti, we didn't test much yesterday becasue the lab was down most of the day. But we made good progress on the integration with autopilot
[07:56] <pitti> yeah, I just looked at the most recent commits (and did some README fixes)
[07:56] <pitti> looking great!
[07:56] <didrocks> nice :)
[07:59] <seb128> pitti, salut, ça va ?
[07:59] <pitti> seb128: bonjour Monsieur ! ça va bien, et toi ?
[07:59] <seb128> pitti, ça va bien merci ;-)
[07:59] <pitti> I'm happy that I didn't get bombarded with regression reports from udev so far :)
[07:59] <jibel> I wished I could finish the autopilot side this morning, but once again didrocks killed my morning ;)
[07:59] <didrocks> jibel: you killed mine as well
[07:59] <didrocks> :p
[08:00] <didrocks> TBH, since the sprint, the jenkins machine is really horrible, we lost of lot of runs and hours…
[08:00] <seb128> pitti, hehe, good job!
[08:02] <Laney> guten morgen
[08:07] <seb128> Laney, good morning
[08:07] <Laney> hey
[08:08] <Laney> apparently Skype fixed the bug I reported in the new release ... probably didn't need to workaround it in glib yesterday
[08:08] <Laney> ho hum
[08:12] <seb128> Laney, nice, we can drop it in the next upload then
[08:12] <Laney> yep
[09:10] <sil2100> attente: ping!
[09:17] <chrisccoulson> good morning
[09:21] <Laney> ricotz: p11-kit goes depwait on libtasn1-6-dev
[09:32] <chrisccoulson> hi Laney, how are you?
[09:33] <Laney> hey chrisccoulson
[09:33] <Laney> I'm on cup of tea #4 ... getting there ;-)
[09:33] <Laney> how are you?
[09:34]  * czajkowski nicks Laney bucket of tea
[09:34] <chrisccoulson> Laney, good thanks. i'm looking forward to the weekend so I can open a bottle of AB:13 :)
[09:34] <Laney> :O
[09:35] <Laney> I shouldn't ... don't ... buy ... arghgosdihgsoih
[09:36] <chrisccoulson> heh
[09:36] <Laney> I wonder if you can buy bottles from the pubs
[09:36] <Laney> that would be more cost effective
[09:37] <Laney> it's about 10 minutes from here ...
[09:37] <chrisccoulson> yeah, the delivery costs really suck
[09:37] <chrisccoulson> we have a local off-license who normally gets them in (http://www.stirchleywines.co.uk/)
[09:39] <Laney> even the AB?
[09:39] <seb128> hey chrisccoulson
[09:39] <chrisccoulson> Laney, yeah, they still have some of the older ones in stock too
[09:39] <chrisccoulson> hi seb128 :)
[09:39] <Laney> wow
[09:40] <ricotz> Laney, ah sorry, libtasn1-6 needs to be MIRed :\
[09:40] <Laney> our beer shop is pretty CAMRA so I doubt you'd see any brewdog there ever :P
[09:40] <Laney> ricotz: well, 1-3 is in main so maybe not
[09:40] <ricotz> https://launchpad.net/ubuntu/+source/libtasn1-6
[09:40] <Laney> but perhaps we could avoid having both in main
[09:40] <ricotz> Laney, ah, ok
[09:41] <chrisccoulson> Laney, see, there are *some* advantages to living in the west midlands
[09:41] <chrisccoulson> well, 1
[09:41] <chrisccoulson> :)
[09:41] <seb128> bah
[09:41] <Laney> I checked it out a little bit and gnutls (one of the rdeps) was reverted back to 1-3 in Debian
[09:41] <seb128> wifi reconnect
[09:41] <Laney> should check out why
[09:41] <Laney> ricotz: want to investigate?
[09:41] <seb128> chrisccoulson, hey ;-) (not sure it went through before)
[09:41] <Laney> I also checked and p11-kit seems to be OK against 1-3
[09:41] <chrisccoulson> hi seb128 :)
[09:42] <ricotz> Laney, will testbuild it again 1-3
[09:42] <Laney> grand
[09:43] <seb128> chrisccoulson, did you see that ted asked you for small stylistic changes for your dbusmenu fix?
[09:43] <chrisccoulson> seb128, yeah, i saw that
[09:45] <chrisccoulson> seb128, it's great being able to change my network configuration in the morning and not have to restart nm-applet :)
[09:46] <seb128> chrisccoulson, did it start doing it more frequently recently for you?
[09:46] <seb128> nobody was able to reproduce that around the precise time
[09:47] <chrisccoulson> seb128, yes, but i suspect that is to do with the explosion of wifi networks nearby (it runs out of ID's faster)
[09:47] <seb128> right
[09:48] <seb128> I'm glad you figured it out anyway
[09:48] <seb128> we should get that in and then backport to precise
[09:48] <seb128> with the 2 leak fixes you made earlier
[09:48] <chrisccoulson> yeah, would be good :)
[09:48] <seb128> chrisccoulson, I guess you never managed to find time to write testcases for those?
[09:48] <chrisccoulson> not yet. it probably shouldn't be too hard though
[09:49] <seb128> chrisccoulson, step 1, update that MR to address ted's comment so we can get the fix in saucy
[09:49] <seb128> then we can discuss SRUs ;-)
[09:54] <ricotz> Laney, gcr/keyring related functions working as expected -- http://paste.debian.net/plain/5709
[09:55] <Laney> ta
[09:55] <Laney> just looking at clutter-1.0 first
[09:56] <Laney> ricotz: can't that be pushed to exp?
[09:56] <Laney> (clutter)
[09:56] <ricotz> no problem, thanks
[09:56] <ricotz> Laney, 1.14.4 yes
[09:56] <Laney> want to update it in svn? I can sponsor there
[09:57] <ricotz> Laney, hmm, ok
[09:57] <Laney> seems like a straightforward update
[09:57] <Laney> cheers
[11:37] <attente> sil2100: pong
[11:45] <sil2100> attente: hello, can I poke you in 15 minutes?
[11:46] <attente> sure
[11:52] <sil2100> attente: ok, free again
[11:53] <sil2100> attente: so, I actually had a question - when I unisntall appmenu-gtk3 and use unity-gtk3-module instead, I actually get some errors in gedit
[11:53] <sil2100> `menu_proxy_module_load': gedit: undefined symbol: menu_proxy_module_load
[11:53] <sil2100> (gedit:5089): Gtk-WARNING **: Failed to load type module: (null)
[11:53] <sil2100> The appmenu is there, but all entries seem to be grayed out
[11:53] <sil2100> Am I missing some package/patch?
[11:58] <seb128> sil2100, you might need http://bazaar.launchpad.net/~indicator-applet-developers/indicator-appmenu/trunk.13.10/revision/238
[11:58] <seb128> sil2100, what version of indicator-appmenu do you use?
[11:59] <sil2100> Ah, let me check
[12:00] <sil2100> 13.01.0daily<IP_ADDRESS>ubuntu.unity.next-0ubuntu1 <- old one indeed
[12:01] <attente> yeah, seb128's right
[12:02] <attente> the warning is probably because UBUNTU_MENUPROXY is still set to the old appmenu.so
[12:03] <seb128> sil2100, iirc that update would fix the inactive items
[12:12] <Mirv> any other still getting the -ati machine brokenness in check phase?
[12:14] <Mirv> not seeing the same elsewhere, but getting "UTAH timeout: Timeout (3600) occurred for install complete message." on SDK
[12:24] <sil2100> seb128, attente: thanks guys
[12:25] <seb128> sil2100, does it work with the new appmenu?
[13:41] <kenvandine> didrocks, you had said to remove the -check for webcred after redeploying, how do i do that?
[13:42] <didrocks> kenvandine: just click on the job
[13:42] <didrocks> kenvandine: then, on the left, you have a delete job option
[13:43] <kenvandine> didrocks, i don'
[13:43] <kenvandine> t
[13:43] <kenvandine> oh
[13:43] <didrocks> kenvandine: are you logged in?
[13:43] <kenvandine> i'm not logged in anymore...
[13:43] <didrocks> :)
[13:44] <kenvandine> i have  "Delete Project"
[13:44] <didrocks> yep, that's the one
[13:44] <kenvandine> woot
[13:44] <kenvandine> thx
[13:45] <Laney> is something wrong with the public jenkins?
[13:45] <Laney> Please wait while Jenkins is getting ready to work....
[13:46] <didrocks> kenvandine: yw :)
[13:47] <sil2100> didrocks: still not merged :<
[13:48] <didrocks> sil2100: did you repoke mmrazik?
[13:48] <sil2100> didrocks: I poked Martin, he said that he unblocked it and put on the queue, but it's merging over 4 hours now
[13:48] <didrocks> sil2100: and repoked?
[13:48] <sil2100> didrocks: I'll repoke fginther ^
[13:48] <didrocks> yeah, thanks!
[13:48] <didrocks> Mirv's one is merged
[13:49] <sil2100> fginther: poke, could maybe you take a look if it's still building, or is it broken?
[13:49] <didrocks> Mirv: waiting for jenkins to restart and then I'll do the rebuild for sdk
[13:49] <fginther> sil2100, didrocks it's still running, about 30 minutes left
[13:49] <didrocks> fginther: after 4h? :/
[13:50] <didrocks> sounds like it's not armhf only the issue ;)
[13:50] <sil2100> Maybe the merger was busy ;p
[13:50] <didrocks> kenvandine: webappsappsappsapps :)
[13:50] <didrocks> thanks!
[13:50] <kenvandine> np
[13:51] <didrocks> kenvandine: I see that some are rereleasing like -youtube
[13:51] <didrocks> kenvandine: without any new content
[13:52] <didrocks> kenvandine: it means that building the source package is creating some diff with trunk
[13:52] <didrocks> kenvandine: do you mind having a look?
[13:52] <fginther> sil2100, didrocks, :-(
[13:52] <didrocks> same for gmail, facebookmessenger
[13:52] <didrocks> kenvandine: I think go on all the ones that were published and when there is no commit message, it means there is something that needs to be fixed
[13:53] <kenvandine> humm... i thought prepare prevented that?
[13:55] <didrocks> kenvandine: yeah, if the source package doesn't have any diff with trunk (apart from .bzr)
[13:55] <didrocks> kenvandine: as it's making a diff to compare
[13:55] <kenvandine> so there must have been some diff there?
[13:55] <didrocks> yeah, like some .log
[13:55] <didrocks> or whatever
[13:55] <kenvandine> oh
[13:56] <kenvandine> i'll look at one of them
[13:57] <didrocks> kenvandine: thanks, FYI the diff I'm doing is:
[13:57] <didrocks>     diffinstance = subprocess.Popen(['diff', '-Nrup', '.', dest_version_source], stdout=subprocess.PIPE)
[13:57] <didrocks>     filterinstance = subprocess.Popen(['filterdiff', '--clean', '-x', '*po', '-x', '*pot', '-x', '*local-options'], stdin=diffinstance.stdout, stdout=subprocess.PIPE)
[13:57] <didrocks>     lsdiffinstance = subprocess.Popen(['lsdiff'], stdin=filterinstance.stdout, stdout=subprocess.PIPE)
[13:57] <didrocks>     (relevant_changes, err) = subprocess.Popen(['grep', '-v', '.bzr'], stdin=lsdiffinstance.stdout, stdout=subprocess.PIPE).communicate()
[14:05] <kenvandine> didrocks, i looked at gmail
[14:05] <kenvandine> there was a translations merge
[14:05] <kenvandine> all the .po files were changed
[14:05] <didrocks> kenvandine: hum, see my filterdiff ^
[14:05] <kenvandine> yeah
[14:05] <kenvandine> that is the only change
[14:05] <didrocks> kenvandine: you did try to run the command?
[14:06] <kenvandine> ok, i'll try that
[14:06] <didrocks> kenvandine: remember to bzr revert && bzr uncommit the last commit :)
[14:07] <didrocks> as the generated one wasn't there
[14:09] <kenvandine> didrocks, weird... i ran that and it returns nothing
[14:10] <kenvandine> so prepare shouldn't have prepared it...
[14:10] <didrocks> kenvandine: what did you run exactly? can you paste the command?
[14:10] <didrocks> $ diff -Nrup . ../unity-webapps-gmail-2.4.16daily13.05.17/ | filterdiff --clean -x '*po' -x '*pot' -x '*local-options' | lsdiff | grep -v ".bzr"
[14:10] <dobey> sigh
[14:10] <didrocks> ./debian/files
[14:10] <didrocks> so yeah
[14:10] <didrocks> there is a diff
[14:10] <didrocks> kenvandine:  ^
[14:10] <kenvandine> oh wait... if there is a commit message you still prepare right?
[14:11] <didrocks> kenvandine: no, it's only the diff deciding
[14:11] <didrocks> dobey: ?
[14:11] <dobey> wtf does libpeas have python and python3 as separate loaders for? it should just have a --with-python3 configure option or something, to specify whether to use python3 or python2 for the loader
[14:11] <kenvandine> oh... i wasn't doing it from bzr
[14:11] <didrocks> kenvandine: diffing the same folder twice? :p
[14:11] <kenvandine> what are you diffing it with unity-webapps-gmail-2.4.16daily13.05.17 ?
[14:12] <didrocks> trunk?
[14:12] <kenvandine> i was diffing the commit that was in the changelog
[14:12] <didrocks> with latest reverted commit as we are in daily release, so before the change in changelog is done)
[14:12] <kenvandine> yeah
[14:12] <kenvandine> i reverted that and did a bzr diff -c 50
[14:12] <kenvandine> with the filterdiff
[14:12] <didrocks> dobey: argh, not fun :(
[14:12] <didrocks> ah ;)
[14:12] <kenvandine> didrocks, so the latest in the ppa is <IP_ADDRESS>
[14:12] <didrocks> kenvandine: no, you want to diff trunk and what's in the distro :)
[14:12] <kenvandine> not 05.17
[14:13] <kenvandine> ah, right what was published
[14:13] <didrocks> kenvandine: yeah, but I'm diffing with distro
[14:13] <didrocks> the destination :)
[14:13] <didrocks> (or next for instance)
[14:14] <dobey> didrocks: tell me about it, since i have a plug-in that's written in python, and rhythmbox git has switched to 'python3' as the loader, and there's no way to tell which one i should use (plus i'd need to do it at runtime, which is basically impossible, since there's no way to know which one to use before then, and the plug-in won't run unless you pick the right one)
[14:14] <kenvandine> didrocks, 2.4.16daily<IP_ADDRESS>-0ubuntu1 was the previous version in saucy
[14:15] <didrocks> kenvandine: are you sure? ;) https://launchpad.net/ubuntu/saucy/+source/unity-webapps-gmail
[14:15] <kenvandine> http://launchpadlibrarian.net/140436635/unity-webapps-gmail_2.4.16daily<IP_ADDRESS>-0ubuntu1_2.4.16daily13.05.22-0ubuntu1.diff.gz
[14:15] <kenvandine> there is a changes file for it
[14:15] <didrocks> dobey: that's why I don't want to do bindings :p
[14:15] <kenvandine> which is weird
[14:15] <kenvandine> there are two changes files for today's version
[14:16] <didrocks> kenvandine: it's been never published to saucy though, you should get that from a ppa ;)
[14:16] <dobey> didrocks: eh?
[14:16] <didrocks> kenvandine: see my link, last one is .17
[14:16] <kenvandine> yeah
[14:16] <kenvandine> oh... so it was in saucy-proposed i guess
[14:16] <didrocks> I don't think so, I don't even see it in -changes
[14:16] <kenvandine> regardless... why doesn't that file show in the diff?
[14:17] <kenvandine> https://launchpad.net/ubuntu/+source/unity-webapps-gmail/2.4.16daily13.05.22-0ubuntu1
[14:17] <kenvandine> look there
[14:17] <didrocks> kenvandine: because you compare tarball to tarball
[14:17] <kenvandine> diff from 2.4.16daily<IP_ADDRESS>-0ubuntu1 to 2.4.16daily13.05.22-0ubuntu1
[14:17] <didrocks> kenvandine: not tarball to trunk
[14:17] <didrocks> so if the file is generated/removed from trunk, it will be removed in both diff
[14:18] <didrocks> kenvandine: so, basically in trunk, you have this debian/files
[14:18] <kenvandine> yeah, it hasn't changed since september
[14:18] <didrocks> which is not shipped in the source package
[14:19] <didrocks> hence the diff having one file between trunk and source package
[14:19] <kenvandine> so i guess this one has been publishing everyday that it's ran?
[14:19] <didrocks> kenvandine: yep
[14:19] <kenvandine> we should remove this from trunk :)
[14:20] <didrocks> kenvandine: agreed, mind doing that? (and looking at the other?)
[14:20] <didrocks> kenvandine: feel free to push directly
[14:20] <kenvandine> yeah... i guess they probably all have it
[14:20] <didrocks> that doesn't worth a change :)
[14:20] <didrocks> yep
[14:20] <didrocks> maybe better to double check with a second one
[14:20] <didrocks> kenvandine: and looking if something else wants to release tomorrow
[14:20] <didrocks> that way, it forces us to ensure that we really ship trunk
[14:20] <didrocks> not trunk + some modification to generate the source tarball
[14:23] <kenvandine> i'll check with another, but i am sure they are all the same.  robru did these all with a script
[14:23] <kenvandine> so they are the same
[14:26] <didrocks> kenvandine: he's all wrong! :-)
[14:27] <didrocks> kenvandine: yeah, so when getting to a new stack, that's why it's important to look a little bit
[14:27] <didrocks> kenvandine: I could as well prepare a new source from trunk and compare that
[14:27] <didrocks> but I prefer to force us to clean the packaging
[14:27] <didrocks> (I only ignore bzr stuff basically and things we don't want to daily release for just that change)
[14:39] <kenvandine> didrocks, mind reviewing this? https://code.launchpad.net/~ken-vandine/cupstream2distro-config/settings/+merge/165170
[14:40] <didrocks> kenvandine: we can build on saucy if needed
[14:41] <didrocks> and directly on daily-build
[14:41] <didrocks> the other are on raring because of autopilot
[14:41] <didrocks> which we don't have for that one, right?
[14:41] <kenvandine> right
[14:41] <kenvandine> but i don't want to land it in distro just yet
[14:41] <kenvandine> it isn't useful
[14:41] <kenvandine> but we want it building some plugin developers can start creating plugins
[14:41] <didrocks> kenvandine: set it to manual publicatoin
[14:41] <kenvandine> so i retargetted it for raring
[14:42] <didrocks> ok then
[14:42] <didrocks> kenvandine: can we avoid having on ppa?
[14:42] <didrocks> kenvandine: trying to kill all those CI ppas
[14:42] <kenvandine> oh we are?
[14:42] <didrocks> people can use next (or then the distro)
[14:42] <didrocks> yeah
[14:42] <didrocks> which at least is "certified"
[14:42] <kenvandine> cool
[14:43] <didrocks> and you didn't enable the schedule
[14:43] <didrocks> for daily build
[14:43] <didrocks> is that wanted? :)
[14:43] <didrocks> (if so, please, put it late, like at 7)
[14:43] <kenvandine> copy and paste mistake... actually that means webcred isn't scheduled
[14:43] <didrocks> ;)
[14:44] <didrocks> oh?
[14:44] <kenvandine> how did we not notice that!
[14:45] <kenvandine> so to recap... for CI autolanding i can use the same ppa_target as the ppa for the stack?
[14:45] <kenvandine> and i can just build for saucy and manual publish
[14:48] <kenvandine> didrocks, ^^
[14:48] <didrocks> kenvandine: no no
[14:48] <didrocks> kenvandine: they shouldn't be any ppa
[14:49] <didrocks> but for the rest, yeah, saucy, and manual publish
[14:49] <didrocks> in daily-build ppa
[14:49] <didrocks> and schedule at 7
[14:56] <kenvandine> didrocks, so drop ppa_target
[14:56] <didrocks> yep ;)
[14:57] <kenvandine> didrocks, pushed... and i enabled the schedule for webcred too :)
[14:58] <kenvandine> oh
[14:58] <kenvandine> i guess drop the hook too
[14:59] <kenvandine> didrocks, ok pushed again
[15:04] <sil2100> Ok, I jump out for practice now, be back later
[15:05] <kenvandine> later sil2100!
[15:15] <didrocks> kenvandine: approved, I'll let you redeploy :)
[15:15] <didrocks> ttyl sil2100 ;)
[15:15] <kenvandine> didrocks, thx
[15:15] <didrocks> yw
[15:16] <kenvandine> didrocks, boom.. traceback
[15:16] <kenvandine> http://paste.ubuntu.com/5690685/
[15:16] <didrocks> kenvandine: did you look at the ui? :)
[15:17] <didrocks> kenvandine: also, please deploy with trunk, I've pushed a change to the template that you want ;)
[15:17] <kenvandine> what ui?
[15:17] <didrocks> kenvandine: jenkins
[15:17] <didrocks> in a browser :p
[15:17] <kenvandine> oh
[15:17] <kenvandine> jenkins is dead :)
[15:17] <didrocks> restarting
[15:18] <didrocks> retoaded is trying to fix the issue that we had to workaround
[16:37]  * didrocks waves good evening
[19:48] <mlankhorst> evening
[22:57] <xnox> Sweetsha1k: libvigraimpex is fixed now. I cherrypicked 4 patches for libreoffice, it builds but there is at least one test suite failure. I will not rerun a full clean build & probably will have  to pass it over to you, if that one fails as well.
[22:57] <xnox> i'm confident that trunk builds fine though. so probably just missing cherry-pick or a new regression in saucy.
[23:02] <xnox> libhsqldb-java is not installable in saucy at the moment =( *sigh*


[21:25] <nathwill> how goes everybody?
[23:25] <tgm4883> bkerensa, so.... do we have a server I can ssh into yet?
[23:25] <tgm4883> bkerensa, or rather, one I can run ZNC on