[11:52]  * facubatista is not here today, but...
[11:52] <Chipaca> facubatista: *bonk*
[11:53] <facubatista> Chipaca, jam, there I merged master (with all the other branches) into my store-names branch, pushed
[11:53] <Chipaca> nice
[11:53] <Chipaca> facubatista: now scram
[11:54] <facubatista> Chipaca, I updated also de "messages to the user doc", told Lilyana about it
[11:54] <facubatista> and now, I fade into the weekend
[11:54] <facubatista> see you on Monday :)
[11:54]  * Chipaca puts on his kicking boots
[11:56]  * Chipaca takes the boots off
[16:29] <__chip__> EOD and EOW for me. See y'all Monday!


[00:43] <q4a> Hi all. Is there Lubuntu 17.04 alpha/daily iso with LXQt? Is there any ETA for it? Thanks!
[13:20] <ShellcatZero> is Lubuntu shipping with LXQT now?
[13:28] <ShellcatZero> nevermind, I see that it is not
[13:32] <Zborg> how well will lubuntu work on an old 1.6ghz atom netbook?
[17:50] <non2003> Hello everyone. I have lubuntu 16.04 on an AMD system (both CPU and graphics) and after the latest update my video image cuts off after a few minutes. Could you guys help me?
[17:51] <non2003> I am a linux noob so I have no idea what to do.


[01:34] <ockham> hi, any clue why this https://launchpad.net/ubuntu/+source/pysolfc-cardsets package's version is suffixed "fakesync1"? i originally (2.0+dfsg-0ubuntu1) submitted it via MOTU and have recently had an updated version submitted to debian (2.0+dfsg-1, which has now been synced to ubuntu. is it because i changed the orig tarball (some cardsets turned out to be ok with dfsg)? could it have been avoided by versioning the dfsg suffix?
[01:34] <ockham> most of all: is a fakesync something i need to worry about?
[01:46] <broder> ockham: yes. because of how apt repositories work, a repository can never hold two different files with the same file name
[01:46] <broder> when an orig tarball gets uploaded to ubuntu then a different one gets uploaded to debian, this would create a conflict for a normal sync
[01:47] <broder> a fakesync takes the packaging from debian and overlays it on the orig tarball that ubuntu is now stuck with
[01:48] <broder> so if debian had gotten the same orig tarball, or they had been named differently, there wouldn't have been a conflict, and we wouldn't have needed to do a fakesync
[01:49] <broder> most of our tools will automatically detect if a fakesync is needed instead of a normal sync and do the fakesync instead (syncpackage can do this, for instance)
[03:15] <mikeit> Hello!
[10:13] <l3on> jtaylor, around? I'm patchig dkopp (ukopp already done by Ilya). Have you talked with upstream, right? There is no new release in the download page :/
[13:57] <jtaylor> l3on: hm I'll just fix dkopp as it doesn't affect debian, ping me when a new upstream comes out and you have it in debian
[13:57] <l3on> jtaylor, I applied patch in debian packages, now waiting for a sponsor.
[13:57] <jtaylor> ok
[15:25] <jtaylor> wtf python2.7-dev amd64 2.7.2-9ubuntu1 [44.0 MB]
[15:25] <jtaylor> why is that so large
[18:56] <KNRO> hello, I encountered a dependency error building in launchpad
[18:56] <KNRO> libapogee-dev : Depends: libapogee2 (= 2.2-0ubuntu1) but 2.3-0~21~oneiric1 is to be installed
[18:57] <KNRO> I don't understand why the latest version 2.3 is not installed if it's available?
[18:57] <KNRO> there is no requirement for = 2.2
[18:58] <jtaylor> -dev packages usually have = {binary...} dependencies
[19:00] <KNRO> yes, should I say the dev package should be >= 2.3 then?
[19:01] <jtaylor> no, -dev packages should always be the exact same version as the accompanied library
[19:01] <l3on> KNRO, apt-cache policy libapogee2
[19:02] <KNRO> jtaylor: the problem is the 2.2 is available in universe while 2.3 of the package is available in my ppa
[19:02] <KNRO> so apparently launchpad tries to use the 2.2 version but it also 'sees' the 2.3
[19:03] <jtaylor> doesn't your ppa provide the -dev package?
[19:03] <KNRO> yes
[19:04] <jtaylor> then apt should see that too
[19:04] <jtaylor> whats the output of l3ons line?
[19:06] <KNRO> Installed: (none)   Candidate: 2.2-0ubuntu1   Version table:    2.2-0ubuntu1 0
[19:06] <KNRO> but this is local, I'm trying to build this on launchpad using a recipe
[19:08] <KNRO> so I'm trying to build a package (indi-apogee) that depends on libapogee2. The version in universe is 2.2, the version in my ppa is 2.3. launchpad says that libapogee-dev depends on 2.2, even though when it can see that 2.3 is the latest one and is going to be installed.
[19:12] <Ampelbein> KNRO: Can you give the link to your ppa?
[19:13] <KNRO> Ampelbein: Sure. https://launchpad.net/~mutlaqja/+archive/ppa
[19:14] <KNRO> This is the buildlog: https://launchpadlibrarian.net/89300412/buildlog_ubuntu-oneiric-i386.indi-apogee_1.1-0~23~oneiric1_FAILEDTOBUILD.txt.gz
[19:15] <Ampelbein> KNRO: The -dev package of your ppa version is named libapogee2-dev, you build-depend on libapogee-dev.
[19:20] <KNRO> Ampelbein: arghhh! Ok thanks let me check!
[19:22] <KNRO> Ampelbein: Spent two hours on this! Thanks for catching the problem, will have to READ carefully next time
[19:22] <Ampelbein> Happens to all of us ;-)
[20:41] <Ampelbein> l3on: fdm sync (#913253) accepted, thanks for your work!
[20:41] <l3on> Ampelbein, thanks for your review :)
[21:37] <achiang> ugh, this should be simple, but i'm not getting it. how does one add a brand new file using quilt? a binary doesn't have a manpage, so i did:
[21:37] <achiang> 1) quilt new add-manpage.patch
[21:37] <achiang> 2) touch resources/man/foo.1
[21:37] <achiang> 3) <edit foo.1>
[21:37] <achiang> 4) quilt add resource/man/foo.1
[21:37] <achiang> 5) quilt refresh
[21:38] <achiang> step 5 gives an error: Nothing in patch add-manpage.patch
[21:39] <jtaylor> can you add before touching it?
[21:39] <Ampelbein> achiang: switch steps 3 and 4.
[21:40] <achiang> Ampelbein: jtaylor: thanks, will give it a shot
[21:41] <Ampelbein> Quilt refresh will diff the current version versus the original version added with quilt add, so  if you edit before adding quilt will never see the original.
[21:41] <achiang> ah
[21:42] <achiang> this is a leaky difference between quilt and a real vcs like git/bzr
[21:43] <jtaylor> in format 3.0 packages just create the file and run debuild
[21:43] <Ampelbein> better, run dpkg-source --commit.
[21:43] <Ampelbein> as the default is currently to abort on uncommited changes.
[21:44] <jtaylor> does that work < preciase?
[21:45] <achiang> jtaylor: it is a 3.0 package... but doesn't that create a debian-changes patch?
[21:45] <jtaylor> yes
[21:45] <Ampelbein> jtaylor: nope, was introduced in <IP_ADDRESS>, only in precise.
[21:45] <jtaylor> rename it and fill out the templete
[21:45] <achiang> right
[21:49] <achiang> yay, that got it
[21:49] <achiang> and now i'm lintian clean
[22:11] <ockham> what do i need to do about that fakesync issue in pysolfc-cardsets? (https://launchpad.net/ubuntu/+source/pysolfc-cardsets  ). i've modified the orig tarball in the version that got synced from debian (some more cardsets had turned out to be dfsg-compatible), and now there's that fakesync which apparently means that the version that's now scheduled for inclusion in precise has the old orig tarball.
[22:12] <ockham> what's necessary for ubuntu to have the updated orig tarball?
[22:15] <soren> bencc: Well, essentially, from upstart's perspective the package just needs to ship two job descriptions.
[22:15] <soren> bencc: I.e. two files in /etc/init
[22:16] <bencc> soren: now I have upstart
[22:16] <soren> bencc: Usually, if you only have a single job, you just name it debian/whatever.upstart, right?
[22:16] <bencc> soren: so I need to replace it with /etc/init/script1 and /etc/init/script2?
[22:16] <bencc> soren: right
[22:16] <soren> bencc: Kinda.
[22:17] <soren> bencc: That is what needs to happen, but debhelper lends you a helping hand here.
[22:17] <bencc> soren: how?
[22:17] <soren> bencc: You can just put another upstart job in debian/. Call it e..g debian/whatever.somethingelse.upstart
[22:18] <soren> bencc: It'll be installed as /etc/init/somethingelse.conf
[22:18] <bencc> soren: don't I need to call it with my package name?
[22:18] <bencc> just arbitrary name?
[22:18] <soren> bencc: Yes. That's the "whatever" part.
[22:19] <soren> If your single upstart job is now called whatever.upstart, your other one should be called whatever.somethinglese.upstart
[22:19] <bencc> soren: thanks
[22:19] <soren> I.e. the first part tells debhelper which binary package the upstart job will go to.
[22:19] <soren> The second part tells it what the name of the job should be.
[22:20] <soren> Makes sense?
[22:20] <bencc> yes, makes sense
[22:21] <bencc> so I could have mypackage.script1.upstart and mypackage.script2.upstart
[22:46] <soren> bencc: Right.


[05:35] <Kilos> hellooo africa
[05:37] <Fatar> how are you doing kilos? :)
[05:38] <Kilos> good ty and you Fatar ?
[05:38] <Kilos> :)
[05:38] <Fatar> good good
[07:45] <ariabbas> .
[11:56] <ariabbas> .


[00:49] <guiverc> my monitor.settings are fixed so thanks... I noted a lxqt-config change yesterday which improved it (-members comment)... I've confirmed all good on other lunar installs now too
[00:57] <arraybolt3> guiverc: Nice.
[00:57] <arraybolt3> (Heads up, jbicha accidentally caused some problems with our LXQt stack by syncing the whole entire stack (or at least a bunch of it) from Debian, so we're doing a full update/repair of the stack. So be prepared for updates on Lunar boxes to go south, and maybe don't update LXQt components any more.)
[00:58] <arraybolt3> I've got quite a few of the packages fixed, thankfully, and will continue to be fixing them up.
[01:01] <guiverc> thanks.. if they're updated & problems are discovered; it allows us to know (eg. my login yesterday) & even to detect when fixed (lxqt-config-monitor just opened instead of closing post package upgrade when that was fixed) ... it's only the GUI which at worst impacts only my sanity? not my data..
[01:06] <arraybolt3> *don't update LXQt components anymore for a while (lol don't update them any more? At all?!)
[01:07] <guiverc> :)
[04:12] <arraybolt3> pong!
[04:35] <arraybolt3> There are a couple of no-change rebuilds in the archive that aren't in lxqt-qtplugin's Git history yet, and some changes to the Git history in lxqt-qtplugin that aren't in the archive yet, so another force-push is going to happen there. !!! FORCE PUSH ALERT


 @KMyers http://www.webhostingtalk.com/showthread.php?t=1475009&p=9430763#post9430763
 Found out why the domain I'm watching might be unavailable, there's two 30 day waiting periods
 and a 5 day waiting period
 @KMyers :D
 There are 6 mods pictured here.
 It's a frankenprinter
 It looks like comcast uped my speed at the other house
 They doubled it
 75 -> 150
 @KMyers thanks for that Trim thing
 @ahoneybun you didn't read the fine print  "Unfortunately, increased Comcast speeds can only be utilized for faster communication with comcast-owned speed test servers."
 I didn't change it
 @govatent, nice m8, keep us posted!
 Anyone here a docsis pro?
 Netgear C6300 router/cable modem
 Moved to a new place and my box started being weird
 factory reset and tinkering later
 I noticed I lose all of my LAN side when I plug in the COAX.
 Like, all of it
 2.4 no longer broadcasts
 and I get a 50.x.x.x WAN IP over ethernet
 I'm sitting here on hold for support to ask them wth they're doing to my box.
 I'm two beers deep already...
 brb, grabbing my 3rd
 New house, different beers, and internet problems. fvck ya!
 ?
 I am 3D Printing my laptop
 Ah righr
 @KMyers, What? How do you mean?
 @Abrerr, Soon grasshopper
 💔
 Btw, they had my device set to bridged mode. Docsis gives complete hardware control apparently. Pretty cool and scary at the same time.


[00:04] <stgraber> cjwatson: hey, looks like you broke publishing of the chinese images to the localized tracker ;) (they're supposed to get to localized-qa.ubuntu.com and by the look of it, the new python code tries to push to iso.qa.ubuntu.com instead)
[00:11] <stgraber> cjwatson: I think something like "http://paste.ubuntu.com/5672171/" should fix it, though we may want something cleaner in qa_product() so that we can easily redirect products to a different QATracker config section
[00:31] <slangasek> infinity: I think it's safe to say that cangjie isn't needed on kylin
[00:32] <slangasek> kylin have expressed preferences regarding input methods, but cangjie aren't it - and I wouldn't expect it to be given what I read about cangjie... which seems to be the colemak of the cjk world :)
[00:32] <slangasek> (well, no, worse than that)
[00:37] <balloons> cjwatson, sure.. didn't even realize there was 2 entries for it!
[00:39] <slangasek> balloons: every package in Ubuntu effectively has two (or more) entries... but when filing bugs about Ubuntu, we want to use the Ubuntu package :)
[00:39] <slangasek> "upstream" bugs may or may not go anywhere useful
[00:39] <balloons> :-).. I'll be sure and keep an eye out
[00:44] <phillw> hi Can I give a heads up on a possible bug heading this way?
[01:05] <infinity> phillw: No, we prefer to be blindsided by last-minute panic-inducing bugs.  It builds character.
[01:11] <infinity> slangasek: Fair enough.  Just a coincidence, then, that we're spinning up a new Chinese flavour, and have a bunch of Chineseish stuff in NEW?
[01:14] <slangasek> infinity: yes, there are apparently enough Chinese people to allow for multiple unrelated bits of Chinese software in the archive ;)
[01:15] <infinity> slangasek: I dunno, man.    I think something's up here.
[01:16] <slangasek> infinity: China's population is distributed in two dimensions instead of one
[01:21] <phillw> infinity: well, just for a laugh... beware of http://bugs.centos.org/view.php?id=6363 as it will cripple KVM's that are used for testing :D
[01:25] <infinity> phillw: An Ubuntu bug that mentions which versions are affected would be much more helpful than that link.
[01:26] <infinity> phillw: Unless the bug isn't in Ubuntu at all, as it was introduced in a version we don't ship, then I don't really see the issue.
[01:29] <phillw> infinity: then look at https://www.centos.org/modules/newbb/viewtopic.php?topic_id=42193&forum=55 are ubuntu expecting to add the 'extra stuff' to libvert? I'm only asking so that it is flagged that libvirt with extra functionality causes OOM errors. If ubuntu are not ever going to use it, then there is no problem. All I am doing is alerting you to the fact there is a problem with it.
[01:30] <phillw> *libvirt*
[01:30] <phillw> infinity: "(01:44:32) phillw: hi Can I give a heads up on a possible bug heading this way?"
[01:31] <infinity> The bug isn't heading this way if it's already fixed upstream, and we're not shipping a currently broken package.
[01:31] <infinity> But alright.
[01:32] <phillw> infinity: do not ship Name : libvirt
[01:32] <phillw> Arch : x86_64
[01:32] <phillw> Version : 0.10.2
[01:32] <phillw> Release : 18.el6_4.2
[01:32] <phillw> it will kill KVM's.
[01:33] <slangasek> phillw: however, #ubuntu-release is not really an effective way to escalate this concern, the release team have nothing to do with the maintenance of libvirt
[01:33] <infinity> Do we even use the same upstream for libvirt?  Our versions are quite different.
[01:35] <phillw> slangasek: this is why I asked here. From where do you get your updates? for this to pass into CentOS 6.4 as a stable update, my other concern is that it could 'hit' ubuntu server.
[01:35] <phillw> and to whom should I alert?
[01:36] <infinity> I think it's safe to say that if Ubuntu doesn't currently have that bug, it's not likely to pick it up.
[01:36] <slangasek> phillw: see the libvirt changelog on your own system for the identity of the folks who tend the package in Ubuntu
[01:36] <infinity> But you could hunt down people who've uploaded libvirt and make them aware of it.
[01:37]  * slangasek nods
[01:37] <phillw> infinity: so long as they do not pick up the library version.... Is there anyway to alert against picking it up?
[01:37] <infinity> When you asked about warning us about impending doom, I didn't think it was going to be "I noticed a random bug" but, like, "I saw something in proposed that make grub shave your kitten and kick your puppy."
[01:39] <infinity> phillw: Why would they pick up an old version?  Upstream has released with those bugfixes since, so the next upstream bump in Ubuntu would include them.
[01:39] <infinity> phillw: So, again, if the bug doesn't *currently* happen with the Ubuntu packages, it doesn't seem worth worrying about.
[01:40] <slangasek> phillw: note that the Ubuntu on stable release updates is specifically designed to reduce the risk of random regressions, by allowing updates (for most packages) only in response to *specific* bugs. https://wiki.ubuntu.com/StableReleaseUpdates
[01:40] <slangasek> s/Ubuntu on/Ubuntu policy on/
[01:40] <phillw> infinity: ubuntu server, as you well know cherry picks from fedora for kernal and other stuff. I only wanted to make *some one* aware that the newer, enhanced, libvirt has a major issue which also has a full bug fix. I've done my part and brought it to your attention. As I closed my comment
[01:41] <phillw> on the bug, I'm only QA.... I only raise bugs. :)
[01:41] <slangasek> Ubuntu does not "cherry pick from Fedora"
[01:42] <phillw> slangasek: sorry, red hat
[01:42] <slangasek> not them either
[01:42] <infinity> We all share code back and forth because we're lovely people that way, but we certainly don't just look at RH stable updates and say "hey, yeah, we want some of that" and apply them blindly.
[01:42] <phillw> slangasek: I got a kernel bug from one of those two installed... That is called life.
[01:43] <slangasek> there are cases where bugs are spotted first in Red Hat and the fix is first posted in their tracker, and Ubuntu may take the fix from their tracker without first waiting for it to go upstream, but this is hardly the same thing as cherry-picking from Red Hat / Fedora
[01:44] <phillw> infinity: and this bug is also called life. Read the bug report and see if ubuntu would like it to happen?
[01:45] <slangasek> phillw: I appreciate your concern about avoiding a regression in Ubuntu, but please familiarize yourself with the SRU policy we already have in place to guard against random updates causing regressions
[01:45] <slangasek> that policy is "don't take random updates"
[01:47] <phillw> slangasek: infinity I'm out of my depth here. All I know is that this can completely bork KVM's and I wanted you guys to be aware of it. I don't want a distro war, or who gets what from where. simply, as a QA guy for whom this bug has affected me on a so called stable server release, I do not want it to happen to ubuntu stable server release.
[01:48] <phillw> I apologise for mentioning a possible 'complete bork' and will remain silent in the future :(
[01:51] <slangasek> phillw: my point is that there's no need to be worried about such an issue hitting Ubuntu as part of a stable update
[03:09] <infinity> Who accepted qapt?
[03:09] <infinity> And pidgin, etc?
[03:09] <ScottK> Not me.
[03:10] <ScottK> infinity: If qapt is in, muon should go in too.  Do you mind if I accept that?
[03:10] <ScottK> That or you can block them in proposed with britney.
[03:11] <infinity> ScottK: I don't mind if they go in after the current builds (like I said).
[03:11] <infinity> But I guess they won't migrate from proposed before the kubuntu build (in progress) is done. :P
[03:11] <ScottK> I'd guess not.
[03:14] <ScottK> There's actually a significant bug fix in muon it'll be nice to have in anyway.
[03:14] <infinity> Accept away, then.
[03:14] <infinity> All the livefses are done except for armhf.
[03:14] <infinity> Dunno how long it'll take.
[03:15] <infinity> Do you guys actually test (and, more importantly, use) the omap4 kubuntu images?
[03:20] <ScottK> I know Riddell tests them.
[03:20] <ScottK> I don't know how much they are used, although a KDE upstream dev did complain about them not working for him on planet KDE recently, so there are users.
[03:21] <ScottK> I know there are a number of people using plasma active on Nexus devices.  Slightly different point, I Know.
[03:21] <infinity> Woo hoo.  Just got private hate mail because I removed libudev0 and Google's Chrome builds depend on it. :P
[03:22] <ScottK> Win.
[03:22] <ScottK> They should get with the program.
[03:23] <infinity> I'm boggling at the juxtaposition of someone who managed to wind their way through Launchpad publishing records to sort out who to blame for the removal, but doesn't understand that old libraries get removed from development releases.
[03:23] <infinity> Like, it's hurting my brain a bit.
[03:26] <ScottK> I guess it just means launchpad has an intuitive UI.
[03:26] <ScottK> No actual knowledge required.
[03:26] <infinity> *choke*
[03:27] <infinity> Can we use that quote in promotional material?
[03:30] <ScottK> Sure.
[04:14] <ScottK> infinity: Did you accept geis and lightdm?
[04:14] <infinity> Yeah.
[04:14] <ScottK> OK.
[04:14] <infinity> The builds (except for core) are all done, so we're safe to selectively accept things.
[04:15] <infinity> Just nothing that will be horribly destabilising if we have to do another spin. :P
[04:15] <infinity> Then again, whoever accepted the other stuff earlier still hasn't admitted to it, so...
[04:17] <ScottK> Someday there will be logs ...
[04:17] <infinity> I like your optimism.
[04:18] <infinity> Shame I built up an immunity to optimism when I was training for this career.
[04:18] <ScottK> You mistake patience for optimism.
[04:18] <ScottK> Someday can span a lot of days.
[04:19] <infinity> Patience implies optimism.
[04:19] <infinity> Since you can't patiently await something without believing it will eventually happen.
[04:19] <ScottK> Or not caring much either way.
[04:19] <infinity> ;)
[04:19] <ScottK> The absence of patience might someday imply motivation and that is to be avoided.
[04:22]  * ScottK starts to wonder if it's his mail client is broken of d-devel stoped spewing crap for a bit.
[09:20] <geoubuntu> Please give me [UIFe] to https://bugs.launchpad.net/ubuntu/+source/tvtime/+bug/1163770
[09:20] <ubot2`> Launchpad bug 1163770 in tvtime "[UIFe] tvtime channel selection menu behavior need to be more logical" [Undecided,New]
[09:51] <ogra_> hmm, infinity did you change the crontab ?
[09:51]  * ogra_ notes the image syncs are commented out
[09:52] <ogra_> (as well as mirroring the logs )
[09:52]  * ogra_ fixes
[11:32] <cjwatson> doko: ~ubuntu-toolchain-r/test set back to not using -proposed
[12:12] <cjwatson> royal is back - kicking off some relevant builds
[12:13] <cjwatson> thanks to jacekn
[12:14] <cjwatson> (there was a fstab problem that might well have afflicted other livefs builders in the future, so it was worth investigating despite it being an unsupported arch!)
[12:14] <ogra_> yay
[12:23] <cjwatson> builds for all the powerpc images on their way
[13:22] <plars> infinity: what's the plan with regards to the oversized warning on the images?
[13:24] <phillw> hi good people <Lubuntu> The Desktop image for PPC is missing in Beta2.  Can that be added to the spins?
[13:29] <ogra_> phillw, the buildd just came up again, patience :)
[13:30] <phillw> cjwatson / ogra_: sorry, just read the scroll back.
[13:30] <ogra_> (i'm sure lubuntu is on the list)
[14:14] <phillw> cjwatson: the current alternate image for lubuntu ppc is over 700MB and won't fit on a CD, I *think* Julien mentioned that it had more than one kernel set on it (and I guess, possibly the desktop image). could you have a look and see if you can put it (or them) onto a crash diet. Many thanks.
[14:15] <xnox> phillw: cjwatson: multiple kernels is intended feature of powerpc images in raring to support all the hardware BenC is working on.
[14:16] <xnox> however, I don't know if we can drop some of them for lubuntu/powerpc combo....
[14:16] <xnox> phillw: is there no dvd drive available?
[14:16] <phillw> xnox: not for all the elderly ppc macs, and some cannot boot from usb.
[14:18] <cjwatson> phillw: I'm happy to help integrating patches from others, but don't plan to work on it myself; experience suggests it can take a while
[14:19] <phillw> okies, by the way queuebot is telling fibs... "queuebot: (notice) Builds: Ubuntu Desktop powerpc [Raring Beta 2] (20130403) has been added"  It hasn't.
[14:20] <phillw> sorry, I take that back!
[14:20] <phillw> mis read it as lubuntu :)
[14:20] <cjwatson> It sure has.
[14:20] <cjwatson> Lubuntu's in the queue.
[14:21] <smartboyhw> phillw: I found testing time for Beta 2 very short this time..
[14:21] <phillw> smartboyhw: exceedingly short!
[14:47] <cjwatson> stgraber: applied and I've posted the most recent images
[14:47] <cjwatson> (not that I checked whether that had been done already)
[14:53] <stgraber> cjwatson: thanks
[16:12] <cjwatson> phillw: ^- there's the Lubuntu powerpc build
[16:13] <phillw> cjwatson: thanks, I'll go and poke Lars in the ribs (he's been pecking my head!).
[16:39] <infinity> cjwatson: Did oversize detection regress with the rewrites?
[16:41] <infinity> Or maybe I'm just not doing the math, and 785MB is > 800*1000*1000
[16:55] <cjwatson> infinity: Yeah, 785 * 1024 * 1024 * 1024 ==<PHONE_NUMBER>40
[16:55] <cjwatson> infinity: So - were you planning to pre-publish soonish
[16:55] <cjwatson> ?
[16:56] <infinity> cjwatson: Looking at results that have wandered in.
[17:08] <infinity> cjwatson: We seem pretty woefully undertested at the moment, except for core.
[17:12] <infinity> cjwatson: We could probably pre-publish ubuntu-desktop.
[17:13] <cjwatson> infinity: OK.  If you want to give that a try, now's a good time.
[17:26] <phillw> infinity / cjwatson ubuntu PPC shows as ready with no tests?
[17:27] <smartboyhw> phillw neither do some other builds
[17:27] <infinity> phillw: That was me fiddling with some things.  I can unready it again.
[17:27] <cjwatson> infinity was working on pre-publication - it's artificial
[17:27] <phillw> ahh, okies :)
[17:27] <smartboyhw> :)
[17:27] <infinity> Err, maybe I can.
[17:27] <infinity> I'm not sure how to untoggle that.
[17:28] <smartboyhw> Mark it for testing?
[17:28] <infinity> Ahh, perhaps.
[17:28] <infinity> Not the most intuitive buttons.
[17:28] <phillw> infinity: I was going to ask the L-QA PPC guys to give it a try if ubuntu plan on releasing a desktop PPC image?
[17:29] <cjwatson> infinity: I usually ask stgraber when I get confused :)
[17:30] <cjwatson> Eh, I think the presence of Ubuntu Desktop powerpc was my mistake
[17:30] <cjwatson> Except, hmm
[17:31] <cjwatson> No, it was supposed to be there as a daily, but it doesn't signify anything about releasing
[17:31] <infinity> I have no problems with releasing the PPC desktop image if it gets tested.
[17:31] <smartboyhw> cjwatson I think letting the L-QA guys test is good..
[17:31] <infinity> phillw: If they have the spare cycles to give it a boot/install/reboot smoketest, that would be lovely.
[17:32] <infinity> phillw: If they don't, I won't complain.
[17:32] <cjwatson> smartboyhw: Sure
[17:32] <smartboyhw> After all they aren't very enthusiatixlc
[17:32] <cjwatson> I was just confused by the images being absent from an earlier build directory, but I think that was cosmic rays or something
[17:32] <smartboyhw> s/arent/are/
[17:32] <cjwatson> The build logs show it being tried consistently, so it's all good
[17:33] <phillw> infinity: they're just finishing the usual battle with bug 1066435 which is a never ending source of 'amusement' for them :)
[17:33] <ubot2`> Launchpad bug 1066435 in linux (Ubuntu) "powerpc: "Fixing recursive fault but reboot is needed!"" [High,Confirmed] https://launchpad.net/bugs/1066435
[17:33] <smartboyhw> lol
[17:40] <tjaalton> hey @ release team. we (ubuntu-x) have prepared mesa 9.1 for raring, but it took longer than expected because there was a regression in blur performance (issues with kwin, and unity dash). those are now fixed and pushed upstream, but raring got frozen in the meantime :/
[17:41] <tjaalton> so, even though it's late, can we update mesa to 9.1?
[17:41] <tjaalton> post-beta
[17:41] <smartboyhw> tjaalton: FFe?
[17:41] <phillw> smartboyhw: looks more like a bug fix to me :)
[17:42] <tjaalton> well, maybe
[17:42] <jokerdino> a new version that is not really bug-fix only but primarily it is. would that still need a FFe?
[17:43] <smartboyhw> not sure
[17:43] <jokerdino> re-reading my own question, i think it would.
[17:43] <jokerdino> because well, it is not just bug fix o.O
[17:43] <tjaalton> also, it's been on the canonical-x/x-staging repo for weeks, and it has worked fine for us
[17:44] <tjaalton> hmm, I'll upload it to ubuntu-x-swat ppa
[17:44] <tjaalton> x-staging would pull the whole stack
[17:49] <infinity> tjaalton: File an FFe bug, include an upstream changelog, explanation of why it's awesome, etc.
[17:50] <infinity> tjaalton: But my gut feeling is that it's probably going to be okayish, but I reserve the right to scowl at you.
[17:51] <tjaalton> infinity: heh, right
[17:51] <tjaalton> I'll do that
[17:52] <tjaalton> was silly to wait two weeks for upstream to pull the bugfix branch
[17:52] <tjaalton> i mean, it needed ffe anyway
[17:53] <infinity> We've done post-release mesa bumps, if I recall, so there's a certain amount of precedence for trusting upstream's sanity here.  Whether that's a good precedent or not, I'm not commenting on.
[17:53] <tjaalton> post freeze you mean, and yes
[17:53] <infinity> I meant post-release. :P
[17:53] <tjaalton> oh
[17:53] <infinity> I'm almost sure there's been a mesa microrelease as an SRU.
[17:53] <tjaalton> right, it has a MRE
[17:54] <tjaalton> and this is 9.1.1 already :)
[17:54] <tjaalton> and some
[17:54] <infinity> Ahh, but the MRE probably only covers the third digit.
[17:54] <infinity> And this is 9.0->9.1
[17:54] <tjaalton> yes
[17:54] <infinity> So, yeah.  FFe and explanations, plox.
[17:54] <tjaalton> gotcah
[17:54] <tjaalton> -cha
[18:18] <jbicha> hey, has anyone looked at bug 1163879? are we just waiting for rebuilds to happen or what?
[18:18] <ubot2`> Launchpad bug 1163879 in Ubuntu QA Website "Ubuntu GNOME images listed on QA Tracker not "linked" to daily images" [Undecided,New] https://launchpad.net/bugs/1163879
[18:28] <stgraber> sounds like you're just missing a bunch of download links on the tracker
[18:29] <stgraber> if you had an Ubuntu GNOME release team associated with the tracker you could fix that yourself ;)
[18:34] <tjaalton> infinity: 2549 commits between 9.0..9.1, roughly 2340 new compared to 9.0.3. so a changelog dump isn't that useful for the ffe, maybe just the relnotes diff
[18:37] <infinity> tjaalton: Whatever you think will get the point across and be informative enough to make a rational decision.
[18:37] <tjaalton> right
[19:44] <xnox> Please move libindicate source & binary to universe, as it is superseeded by messaging-menu. It doesn't look like we will be able to remove it from the archive this cycle, but at least we can move it to universe.
[19:45] <infinity> xnox: I was waiting for someone slightly more desktoppy to confirm that they didn't need it anymore.
[19:45] <infinity> seb128: ^
[19:46] <xnox> seb128: ^^^ please confirm punting libindicate to universe.
[19:46] <xnox> infinity: snap.
[19:46] <infinity> (It's in component-mismatches, just want to make sure that's not a mistake)
[19:46] <xnox> infinity: it's part of the ongoing quantal's granted FFe bug 1040259
[19:46] <ubot2`> Launchpad bug 1040259 in skype-wrapper "FFE: libmessaging-menu transitions for quantal" [High,In progress] https://launchpad.net/bugs/1040259
[19:47] <seb128> infinity, xnox: I would prefer having it dropped (since it's runtime broken, indicator-messages doesn't consume that api anymore), but universe is better than nothing
[19:47] <infinity> I can drop it if it has no rdeps.
[19:47] <seb128> well, it seems that xnox was saying it still has
[19:47] <infinity> It does, yeah.
[19:47] <xnox> seb128: we cannot drop it because of a working implementation. libindicate -> libindicate-qt -> plasma-widget-messaging-menu -> 6 kde apps that work.
[19:48] <seb128> xnox, oh, right, ok, fair enough
[19:48] <xnox> seb128: it all "works" in a kde desktop with 6 apps.
[19:48] <seb128> xnox, infinity: please demote then ;-)
[19:48] <infinity> Done.
[19:48] <xnox> seb128: infinity: thanks a lot.
[19:48] <seb128> infinity, xnox: please accept the new gwibber and demote it as well btw ;-)
[19:49] <infinity> Hrm?
[19:49] <infinity> I don't see gwibber on component-mismatches.
[19:49] <seb128> iinfhttp://launchpadlibrarian.net/135987453/gwibber_3.7.0bzr13.04.02-0ubuntu1_source.changes
[19:49] <seb128> infinity, http://launchpadlibrarian.net/135987453/gwibber_3.7.0bzr13.04.02-0ubuntu1_source.changes
[19:49] <seb128> hum
[19:49] <xnox> seb128: I'm just a minion on the Foundations Team, I actually don't have magic Release Team / Archive Admin powers =)
[19:49] <seb128> we dropped the ubuntu-desktop recommends yesterday
[19:51] <seb128> infinity, well the intend is to drop gwibber to universe and get the new version (using qt5 and "friends") in
[19:51] <infinity> If only we weren't releasing in a couple of weeks.
[19:51] <infinity> Has that all been FFeified?
[19:52] <infinity> (Yes, changing desktop recommends is a feature...)
[19:52] <xnox> seb128: doesn't the new gwibber depend on the non-landing new unity scopes et. al.?
[19:53] <seb128> infinity, changing recommends is a feature?
[19:53] <seb128> infinity, well, we got ffe to get the new gwibber on the CD
[19:53] <seb128> but security nacked us because qt5 ships a v8 copy with security issues
[19:54] <seb128> so we have the options to keep an old buggy, unmaintained gwibber on the CD (which we don't want)
[19:54] <seb128> or update it, but put it in universe with qt5
[19:54] <infinity> seb128: Changing recommends is changing the default installed applications.  That's a bigger feature change than most.
[19:54] <xnox> seb128: recommends will try to pull the new gwibber on to the cd....
[19:54] <seb128> xnox, we dropped the recommends yesterday
[19:54] <infinity> xnox: No, he removed the recommends.
[19:55] <xnox> now, I gotcha. And not going to add one on the new-gwibber-with-lib-friends was the bit I was missing in my head =)
[19:56] <seb128> infinity, so what do you suggest, that we file a ffe request for moving gwibber to universe?
[19:57] <infinity> (Also, it's gwibber-service-sohu and gwibber-service-sina that are keeping gwibber in main)
[19:57] <seb128> urg
[19:57] <seb128> why are those in main at all?
[19:57] <infinity> supported-desktop-extra: * gwibber-service-sina
[19:57] <infinity> supported-desktop-extra: * gwibber-service-sohu
[19:57] <infinity> = For Project Qin =
[19:58] <infinity> That may be obsolete now.  Dunno.
[19:58] <seb128> thanks
[19:58] <seb128> I will talk to Ken about those
[19:58] <seb128> once that's resolved, do you still want a ffe for gwibber->universe?
[19:58] <infinity> Yeah, he committed that back in oneiric.
[19:58] <seb128> I think those are unmaintained and stopped working last cycle
[19:59] <seb128> I'm surprised we kept them in main
[19:59] <seb128> I guess nobody noticed/acted and they stayed there
[19:59] <seb128> I will get it sorted
[19:59] <seb128> what about the ffe?
[19:59] <infinity> seb128: I'm not against moving gwibber to universe, just saying that desktop dependencies and recommends are clearly features.  I'm fine with a verbal approval.
[19:59] <infinity> (So, consider this your verbal approval)
[19:59] <seb128> ok, I give you a verbal approval, we planned to drop the version we currently ship in favor of the rewrite
[20:00] <seb128> but we can't because of qt5
[20:00] <infinity> Once you sort the seeds, I'll move if before I accept the new one, not after.
[20:00] <infinity> (So the new one doesn't get translations stripped)
[20:00] <seb128> so our fallback option is still to drop it, but just to move the new gwibber to universe ;-)
[20:00] <seb128> that makes sense
[20:00] <seb128> infinity, thanks ;-)
[21:15] <jbicha> stgraber: I created the ubuntu-gnome-release LP group (and I think I inadvertently spammed a bunch of people)
[21:30] <phillw> ahh, to whoever is marking things ready, I was just finishing lubuntu i386 alternate. That is also now good for release. stgraber if the teams are allowed to mark things as ready, would you please add that functionality to myself. Julien added me to https://launchpad.net/~lubuntu-product-managers a while back :)
[21:31] <infinity> phillw: I've just been marking things ready when they get full test coverage and don't appear to have any new showstopper bugs.
[21:31] <phillw> infinity: also the ac100 in lubuntu has one test and a it is a fail,
[21:32] <phillw> not sure why not a red bug, but the arm team look after their own images :)
[21:32] <ScottK> phillw: arm team isn't likely to focus on something lubuntu specific.
[21:32] <phillw> ScottK: it their only ac100 release :D
[21:32] <infinity> Well, Oli might care about that one.
[21:33] <ScottK> infinity: Yes, but as a personal matter, not as part of the arm team.
[21:33] <stgraber> jbicha: yeah, I saw the e-mail, I'll process that as soon as I get IPv4 connectivity again (as iso.qa.ubuntu.com sadly isn't on IPv6 yet)
[21:33] <infinity> There is no "arm team" anymore, so true.
[21:33] <ScottK> That as well.
[21:33] <phillw> ScottK:
[21:34] <infinity> ogra_: Have any ideas about what's up with #1164071 ?
[21:34] <phillw> hmm, so, the ac100 will just quietly die? It was the 'arm' team who asked if they could use lubuntu as the other DE's resulted in being too big to install / boot.
[21:34] <infinity> ogra_: I don't have an ac100 anymore...
[21:34] <ogra_> infinity, not tonight anymore
[21:35] <ogra_> but i'll look at it tomorrow
[21:35] <ogra_> skip the beta for ac100
[21:35] <infinity> Kay.
[21:35] <ogra_> phillw, i'll make sure it is releasable
[21:35] <phillw> ogra_: thanks, as you know, none of the L-QA people have an ac100 :)
[21:36] <ogra_> phillw, and the reason for the siwtch is simply unextendable 512M ram :)
[21:36] <stgraber> highvoltage: what's the status on Edubuntu testing?
[21:37] <phillw> ogra_: I do recall the chat, just not the full gory details :P
[21:37] <ogra_> ubuntu runs fine on it ... but space to run apps gets pretty short then :)
[21:37] <phillw> if one of us had an ac100, I'm sure they'd be over the iso like a bad rash :P
[21:38] <infinity> I gave mine to hallyn, otherwise I'd be happy to donate.
[21:38] <infinity> ScottK: Any idea what the deal is with Kubuntu testing?  Seems sparse.
[21:39] <ScottK> No.  I've had no time.
[21:39] <ScottK> Riddell: ^^^
[22:00] <Riddell> ScottK: I'm on it now
[22:00] <xnox> infinity: nexus7 is all done http://iso.qa.ubuntu.com/qatracker/milestones/264/builds/41192/testcases
[22:00] <ScottK> Great
[22:01] <highvoltage> stgraber: my edubuntu images are still being replaced by symlinks when I rsync, that never happened before. http://paste.ubuntu.com/5674925/
[22:01] <highvoltage> any ideas?
[22:01] <doko> Riddell, ScottK. while you are here ... bug 1163794
[22:01] <ubot2`> Launchpad bug 1163794 in qt-assistant-compat (Ubuntu Raring) "qt-assistant-compat ftbfs in raring" [High,Confirmed] https://launchpad.net/bugs/1163794
[22:02] <Riddell> doko: hum
[22:03] <stgraber> highvoltage: are you rsyncing current/? if so, yes something changed
[22:04] <doko> Riddell, and http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html is past k for universe, so maybe have a look at the armhf failures. x86 will hopefully catch up later
[22:04] <highvoltage> stgraber: yes I am
[22:05] <highvoltage> but I think it will work if I add the -L option to rsync, trying...
[22:05] <ScottK> doko: How does one fix:
[22:05] <stgraber> highvoltage: in short, images under current/ are now symlink that change based on jenkins result (or will soon be at least)
[22:05] <ScottK> dpkg-deb: building package `libpimcommon4-dbgsym' in `../libpimcommon4-dbgsym_4.10.1-0ubuntu1_armhf.ddeb'.
[22:05] <ScottK> Segmentation fault
[22:06] <highvoltage> aah
[22:06] <stgraber> highvoltage: cjwatson sent an e-mail about the change recently and mentioned it may break things for rsync users
[22:06] <cjwatson> indeed, use -L
[22:06] <cjwatson> bit my scripts too :)
[22:06] <stgraber> highvoltage: I can send you my mirroring script that uses zsync, as far as I can tell, that one wasn't affected and actually uses less bandwidth than rsync too
[22:06] <cjwatson> in this case it isn't jenkins, it's due to different build IDs on different architectures
[22:07] <cjwatson> which is a bit odd since they're meant to be carried over, so probably a bug, but you should update your scripts anyway
[22:07] <highvoltage> stgraber: yes that would be nice
[22:07] <barry> infinity: curl_7.29.0-1ubuntu2 should fix bug 1124508 and pycurl bug 1163609
[22:07] <ubot2`> Launchpad bug 1124508 in curl (Ubuntu) "Segfault in curl_multi_cleanup error() when multi->closure_handle is NULL" [High,In progress] https://launchpad.net/bugs/1124508
[22:07] <ubot2`> Launchpad bug 1124508 in curl (Ubuntu) "duplicate for #1163609 Segfault in curl_multi_cleanup error() when multi->closure_handle is NULL" [High,In progress] https://launchpad.net/bugs/1124508
[22:08] <doko> ScottK, please could you be less sarcastic?
[22:08] <stgraber> highvoltage: http://paste.ubuntu.com/5674941/ (script), http://paste.ubuntu.com/5674943/ (config)
[22:08] <ScottK> Probably not.
[22:08] <doko> which source? did you try to rebuild that locally?
[22:08] <barry> doko: ^^ in your test rebuild, once the new curl version lands, you should be able to just retry the pycurl build
[22:08] <ScottK> doko: That was kdepim in your rebuild.
[22:09] <highvoltage> thanks stgraber, I'll use it post beta2
[22:09] <ScottK> I don't currently have hardware that can build armhf on raring, so about all I could do is hit retry.
[22:14] <doko> ScottK, given back
[22:15] <xnox> stgraber: highvoltage cjwatson: I use dl-ubuntu-test-iso now, as it's packaged and it's another script I don't have to maintain =) qa maintains it for me ;-) YMMV with it though...
[22:17] <xnox> doko: did you give back tktcl fallout after the compat script got uploaded? or do i need to go through them and poke you to give those back?
[22:17] <stgraber> xnox: well, I haven't had to maintain my script for the past 2 years and I'm pretty sure it's lots more efficient than dl-ubuntu-test-iso ;)
[22:18] <doko> xnox, what I did see. I greped the failed build logs.if there's anything more, please tell me
[22:18] <highvoltage> xnox: ok thanks, I'll check that out too
[22:18] <xnox> stgraber: dl-ubuntu-test-iso is in python & uses zsync by-default and have options to mirror the cdimage tree layout. But yeah I'm sure your one liner perl script with fancy drupal frontend is much better & quicker =)
[22:19] <xnox> what I like is that it does batch sync of everything i care about based on a config file.
[22:20] <stgraber> xnox: my script is also python and also is based on a config file, I remember sending mine to QA at some point, so it's likely some bits ended up in dl-ubuntu-test-iso ;)
[22:21] <doko> cjwatson, infinity: is the "Sets" attribute for syncs not set, or isn't there a set for these packages?
[22:21] <infinity> The former.
[22:21] <infinity> And who accepted curl?
[22:21] <doko> I did
[22:21] <infinity> Please don't?
[22:21] <infinity> I mean, a bit late now.  But.
[22:22] <doko> ok. but why?  I didn't see it on a cd set
[22:22] <infinity> (core) is an intersection of many sets.
[22:22] <infinity> Surely, you don't think we don't ship libcurl? :P
[22:23] <cjwatson> doko: use seeded-in-ubuntu
[22:23] <cjwatson> http://paste.ubuntu.com/5674984/
[22:24] <doko> ahh, thanks! that's useful
[22:43] <cjwatson> The wubi/precise error in cron mail is my fault; I'll figure it out at some point soon ...
[22:44] <stgraber> was just about to poke about it, good ;)
[23:00] <plars> infinity: panda bug with using the keyboard to enter the passphrase for encrypted filesystems is rearing it's head again: bug #1164198
[23:00] <ubot2`> Launchpad bug 1164198 in initramfs-tools (Ubuntu) "Keyboard not working to enter password for encrypted fs on panda" [Undecided,New] https://launchpad.net/bugs/1164198
[23:01] <infinity> plars: Oh, I probably never fixed the arm-specific part of that in d-i.
[23:37] <phillw> infinity: lubuntu amd64 Desktop is now 'good to go' :)


[02:16] <SlackShrike> How to create ubuntu from scratch ? I am like a kubuntu.iso in my house !
[02:16] <SlackShrike> please
[02:40] <Riddell> motaboy: we're around, but busy conferencing
[02:42] <motaboy> Riddell: koffice is ready. :D But I cannot put it on for the ssh problem.
[02:42] <Riddell> http://udu.wiki.ubuntu.com/KubuntuRoadmap
[02:42] <Riddell> if anyone has anything to add
[02:42] <Riddell> oh yes, I've asked them to remove the ssh firewall
[02:43] <motaboy> Riddell: thanks
[04:18] <uniq_> hello guys.
[04:23] <Riddell> hello uniq_
[04:24] <uniq_> what's up?
[04:28] <uniq_> what's the deal with hoary-updates, is that just for main, or do we have a universe-hoary-updates too?
[04:29] <uniq_> s/or/if that is the case/
[04:36] <Riddell> yet to find out
[04:36] <uniq_> ok.
[04:37] <Riddell> wonder who I should ask
[04:37] <uniq_> I have a few packages i'd like to put into a "hoary-universe-update"-repository somewhere.. krusader and aterm for starters.
[04:39] <Riddell> suspect they should just go into breezy
[04:40] <uniq_> yes, that's what i'm thinking too..
[09:38] <AndreH> has anyone tried using kdevelop and the qt-designer? I want to edit a cpp file in the qt-designer, but I get the following error: "there is no plugin for editing c++ code installed"
[09:38] <AndreH> but kdevelop3-plugins is installed
[10:36] <KaiL_> anymody already tried a VIA K8T890 or nForce 4 Mainboard (means pci-express..)?
[10:40] <KaiL_> oops, wrong window