[02:40] <p0s> where can i speak to the person who packages eclipse for 14.04?
[02:47] <bluezone> p0s, oh lord :P
[02:47] <p0s> bluezone: are you the one?
[02:47] <bluezone> no, but i would always use the official site of eclipse :P
[02:48] <infinity> bluezone: Are you aware of specific bugs in the packaged version?
[02:49] <bluezone> infinity, eclipse has 50 different versions and plug-ins and it is known to break often, my opinion would be to use the distributions on the official website so at the very least you won't have to spend time figuring out what you're getting in the eclipse package
[02:50] <p0s> bluezone: if you think having a *distribution* of software is wrong and people should assemble their own system, why are you in #ubuntu-devl? :)
[02:50] <infinity> bluezone: ^-- What he said.
[02:50] <bluezone> you don't have to assemble anything
[02:50] <bluezone> you download, extract and double click the executable
[02:51] <p0s> bluezone: and then you manually update it whenever updates arise because you have no package manager. and then you forget about it when there are security issues. and then you are back at something like the windows world where every machine is compromised because it takes years until everyone has a certain security update
[02:52] <p0s> anyway, if someone could tell me the channel where the packager of eclipse likely is present or even his nickname, i would be glad. thanks in advance! :)
[02:53] <bluezone> p0s, if you are talking about "help->update" then yes you have to do it manually, but it is a small price to pay
[02:53] <infinity> p0s: We sync it from Debian, so the packagers are the folks listed in 'apt-cache show eclipse' (or on http://packages.qa.debian.org/e/eclipse.html)
[02:53] <infinity> bluezone: Assuming single-user systems, etc.
[02:54] <bluezone> that's true
[02:54] <infinity> bluezone: The point is that, in a distro channel, saying "don't use the distro-packaged software" isn't the most helpful of things.
[02:54] <infinity> bluezone: If you can offer constructive criticism, bugs are welcome.  If it's just a "distros suck, use upstream" opinion, I'm not entirely sure this is the best place for that.
[02:55] <p0s> infinity: this part of the apt-cache output? "Original-Maintainer: Debian Orbital Alignment Team <pkg-java-maintainers@lists.alioth.debian.org>"
[02:56] <infinity> p0s: Aye, or the Uploaders, but I guess that doesn't make it into the binary package, only the source package.
[02:56] <infinity> p0s: But that mailing list would be a good start.
[02:56] <p0s> infinity: and given that debian has a very slow release cycle, it is unlikely for them to update it to the latest version any soon, right?
[02:59] <infinity> p0s: Nah, we pull from unstable, so if they updated unstable, we'd get that for "free".
[03:00] <p0s> infinity: i had to distupgrade because the previous ubuntu version which i was on isn't supported anymore, and now i ran into this https://bugs.launchpad.net/eclipse/+bug/1241101  ... it breaks my complex development environment, and i work for a donation funded organization, and i don't feel like billing them hundreds of euros for me to manually re-setup eclipse to a downloaded version.... and i feel like given that 113 people are affected by this
[03:00] <p0s> bug and 11 duplicates have already been filed, it is rather very questionable why ubuntu still ships an eclipse version from 2012...
[03:00] <infinity> p0s: I suspect there's a #debian-java channel on freenode where those sorts of people might hang out.
[03:00] <p0s> infinity: so i am considering to bribe someone to update the eclipse package...
[03:00] <infinity> p0s: Have you tried upgrading to 14.04 and same issue?  13.10 is EOL in a month.
[03:00] <infinity> Whereas 14.04 is supported for 5 years.
[03:01] <p0s> infinity: yes, i am on 14.04
[03:01] <infinity> p0s: Kay, didn't read the bug yet, just the title. :P
[03:02] <p0s> infinity: i also tried ALL workarounds in the launchpad bugtracker entry, in the eclipse bugtracker entry and in the KDE one... only thing left to try is the latest version, which someone recently said in the launchpad entry fixes the issue
[03:03] <p0s> infinity: #debian-java redirecty to ##debian-java which is empty
[03:03] <infinity> Oh, annoying.  That was just a guess. :P
[03:05] <infinity> p0s: So, if it's an issue with menuproxy, that's Ubuntu-specific, but if you say disabling all of that still breaks it, certainly mailing the debian java packaging list and/or debian-java@debian.org and asking about newer versions might not go amiss.
[03:05] <infinity> p0s: If the new upstream *does* fix it, perhaps someone can find the commits that fix it and backport to 14.04
[03:05] <p0s> infinity: people of all kinds of different distributions have said they suffer the same issue
[03:06] <p0s> infinity: i will try the debian list then if nobody in the ubuntu bugtracker responds
[03:08] <infinity> p0s: Well, a fair two-pronged approach regardless.
[03:08] <infinity> jamespage: Do we have anyone who cares about eclipse in Ubuntu?
[03:16] <p0s> infinity: i really feel like nagging everyone this time because it stops me from working :|
[03:16] <p0s> infinity: it crashes like every 10 minutes
[03:20]  * bluezone rests his case
[03:21] <infinity> p0s: Probably worth trying the upstream non-package to see if you can reproduce the crash, as a useful data point.  That bug log is a mess, and probably several different bugs, so it's hard to say if one person saying it's fixed means much for others.
[03:36] <psusi> cjwatson, hah, cool.. upstream git guys were able to reproduce and fix the git rebase --skip bug... seems it happens any time you have two consecutive conflicting patches
[03:57] <p0s> infinity: i will probably end up having to try the latest, yes. nevertheless i will idle here overnight, waiting for you or jamespage to figure out whether ubuntu has an eclipse maintainer...
[04:14] <pitti> Good morning
[05:17] <darkxst> pitti, hi
[05:19] <pitti> hey darkxst, how are you?
[05:19] <darkxst> pitti, good, apart from all the rain!!!!
[05:20] <pitti> darkxst: heh, I wish we'd get some again :)
[05:20] <darkxst> we have plenty! I will send you some ;)
[05:24] <darkxst> pitti, do you know if its possible to pass through environment variables to schroot hooks, when using sbuild?
[05:25] <pitti> darkxst: I'm not aware of anything except --preserve-environment
[05:33] <darkxst> only want 1 variable not everything!
[06:25] <dholbach> good morning
[06:55] <pitti> ogra_, cjwatson: are "live" and "desktop" just cruft in ubuntu-touch.utopic? touch, desktop, and live all have langpack sets, but I suppose I only actually need to change "touch"?
[07:02] <didrocks> pitti: from what I can remember, yeah, only touch counts
[07:02] <pitti> bonjour didrocks
[07:02] <pitti> didrocks: merci
[07:02] <didrocks> Guten Morgen pitti :)
[07:03] <zyga> good morning :-)
[07:03] <didrocks> hey zyga
[07:04] <pitti> didrocks: so I can "bzr branch lp:ubuntu-system-settings", add the langpack flag, debcommit -r (for tagging), and dput?
[07:06] <didrocks> pitti: exactly :)
[07:06] <didrocks> it was designed for that ;)
[07:07] <pitti> didrocks: nice! I'll start with that as it has the most translations in that list
[07:08] <pitti> didrocks: there will be some days when system-settings becomes untranslated, until it appears in the LP exports
[07:09] <pitti> but I set up the cron jobs, etc.
[07:13] <michagogo> 5:54:24 <infinity> bluezone: The point is that, in a distro channel, saying "don't use the distro-packaged software" isn't the most helpful of things.
[07:13] <michagogo> Well, there are some exceptions to that
[07:13] <michagogo> For example, bug 1314616
[07:20] <ogra_> pitti, no, they are the base of desktop-next
[07:20] <ogra_> if you do changes in touch please do them in desktop too
[07:21] <didrocks> oh, Laney reput them on the touch seed instead of creating a new one after all? (I remember that was under discussion)
[07:21] <pitti> ogra_: ah, I see; so replacing hte langpacks with language-pack-touch-* should only be done in "touch"
[07:22] <ogra_> pitti, why ? i guess we want the desktop translated too ?
[07:22] <pitti> ogra_: FYI, I put the toucuh langpacks on another diet by dropping unimportant translations, that halved their size again (35 MB for  28 languages)
[07:22] <ogra_> whee !
[07:22] <ogra_> you rock !
[07:22] <pitti> ogra_: right, but desktop-next should use the full langpacks, not just the touch ones?
[07:23] <ogra_> not sure ... will they have the same translations ?
[07:23] <ogra_> (plus extra cruft)
[07:24] <pitti> ogra_: well, "extra cruft" == "translations for all packages in main", but they of course *also* have the phone/touch packs
[07:24] <pitti> err s/packs$/translations/
[07:24] <ogra_> well, then it is up to Laney to decide i guess ... image size is his authority for that flavour
[07:25] <ogra_> leave them for now and he can decide
[07:25] <pitti> ogra_: I won't change it today yet anyway; first we need to rebuild these ~ 20 projects with the langpack control flag so that the langpacks will make actual sense :)
[07:25] <ogra_> yeah, i saw the dsicussion
[07:25] <pitti> doing that now for system-settings to have a guinea pig (these are also the biggest ones)
[07:26] <pitti> ogra_: I'll file a block-proposed bug so that the untranslated rebuilds stays in -proposed until wednesday when we'll get a new LP translation export with the system-settings translations
[07:26] <ogra_> ++
[07:29] <pitti> bug 1330360 FYI
[07:29] <pitti> didrocks: argh! I can't push to https://code.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk
[07:30] <pitti> "You cannot upload to this branch. Members of Ubuntu Touch System Settings can upload to this branch. "
[07:30]  * pitti moves to dialer-app instead
[07:30] <didrocks> pitti: something you should, but sometimes, upstream changed team after we setup the CI system and drop commit access. Not sure for that one
[07:31] <pitti> ok, dialer-app pushed and uploaded
[07:44] <smb> stgraber, Hi morning. I was looking at my ppu list this morning and think I only got rights on virt for utopic. Somewhat having those for P, S, and T would be helpful. Were those omitted intentionally or just an oversight?
[07:50] <Noskcaj> dholbach, How can i try and prevent conflicts in my merges? They all seem to be random upstream files
[07:50] <dholbach> Noskcaj, it might be just a matter of unapplying d/patches before committing?
[07:51] <Noskcaj> I try to have the same ones applied as when i branched it
[07:51] <Noskcaj> should i just have none applied in future?
[07:52] <dholbach> Noskcaj, it's the only thing I can imagine going wrong to cause conflicts
[07:52] <dholbach> try it out :)
[07:52] <Noskcaj> ok
[07:55] <darkxst> Noskcaj, do you see a bunch of .pc/* files in the conflicts?
[07:55] <Noskcaj> darkxst, just a random file (not .pc), it happens a bit
[07:57] <Noskcaj> dholbach, The patches are all dropped
[07:58] <darkxst> Noskcaj, some branches has patches applied, and some don't
[07:59] <Noskcaj> I think my cheese merge will need a patch de-commited now
[08:00] <dholbach> Noskcaj, the following will result in text conflicts: bzr branch ubuntu:gtkspell3; cd gtkspell3; bzr merge lp:~noskcaj/ubuntu/utopic/gtkspell3/3.0.6
[08:00] <dholbach> Noskcaj, even if I    quilt pop -a; bzr commit -m "unapply patches"   before the merge
[08:00] <seb128> shrug
[08:00] <Noskcaj> dholbach, strange
[08:00] <seb128> dholbach, Noskcaj: that cheese update uses CSD, it should be reverted to 3.10
[08:00] <Noskcaj> I've no idea how to fix that
[08:01] <Noskcaj> seb128, I'll leave it broken then
[08:01] <Noskcaj> (my merge, not cheese itself)
[08:01] <seb128> hum, Laney updated it
[08:01] <darkxst> Laney patched cheese
[08:02] <seb128> Noskcaj, in fact it got patched, so ignore my comment
[08:03] <Noskcaj> seb128, could you look at my libgweather merge? It's been sitting there for some timenow
[08:04] <seb128> Noskcaj, not really, I've been skipping it because I don't know enough about the topic to know if the provider change is something we want
[08:06] <Noskcaj> seb128, ok. I'd only assumed it was ok as it had been put in debian and darkxst had told me to merge it, so i don't know either
[08:07] <seb128> Noskcaj, yeah, it's fine, ignore my comment ;-)
[09:43] <dpm> hi pitti, I've just read your last message re: touch langpacks - do you have a new list of domains after further filtering? And does that imply that perhaps more languages are above the cut-off?
[09:43] <pitti> dpm: yes, it's now 28 languages with >= 70%
[09:44] <pitti> dpm: the packs are now ridiculously small, we really need to do these X-Use-Langpacks thingies to make them useful
[09:45] <pitti> dpm: basically just colord, webbrowser-app, lightdm, unity
[09:46] <pitti> although, hmm, that sounds like a bug; e. g. apport should be there, too
[09:46] <dpm> pitti, ok, great.
[09:46] <dpm> pitti, what about the indicators? And why is colord there?
[09:46] <pitti> dpm: I'm still working on this, and I uploaded dialer-app to get its translations imported/exported
[09:46] <dpm> ack
[09:46] <pitti> dpm: colord has prio 7000
[09:47] <dpm> oh, really? I should fix that
[09:48] <pitti> dpm: argh, I know what happened, it just downloaded the current update tarball
[09:48] <pitti> locally I built with the base tarball
[09:48]  * pitti rebuilds
[09:50] <pitti> dpm: so in my local builds it shrank by 1/2 and lost some 20 domains; hang on, I'll build you an updated list
[09:51] <dpm> pitti, ok, cool. Shall we request a full export in LP for the next langpack?
[09:52] <pitti> dpm: not necessary
[09:53] <dpm> ok
[09:53] <pitti> dpm: stats: http://paste.ubuntu.com/7652243/
[09:53] <pitti> dpm: ca is at 68% almost over the limit :) (but we can also slightly lower the treshold)
[09:54] <pitti> dpm: domains for -es: http://paste.ubuntu.com/7652244/
[09:54] <pitti> dpm: so e. g. gdb is gone, and glib
[09:55] <pitti> dpm: gtk20-properties.po really ougth to be lower these days too?
[09:55] <pitti> dpm: can you move that from 7400 to perhaps 1000?
[09:55] <pitti> dpm: and in turn, bump gtk30-properties?
[09:56] <dpm> ok
[09:57] <dpm> pitti, done
[09:59] <seb128> dpm, pitti: gtk2 is still used in e.g firefox or libreoffice, so it shouldn't be ranked too low
[09:59] <pitti> seb128: we use neither on touch, though?
[09:59] <seb128> pitti, is the ranking specific to touch?
[09:59] <pitti> seb128: btw, it's not gtk2 itself, just gtk20-properties
[10:00] <seb128> k
[10:00] <pitti> seb128: no, it's not; but it's still an obsolete version, so translators shouldn't translate that before gtk30-properties
[10:00] <seb128> right
[10:00] <bluesabre> mdeslaur, infinity: is there anything that needs to be done to move these bugs to trusty-updates?
[10:00] <seb128> well, as long as it's still mark as "useful to translate"
[10:00] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1326741
[10:00] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1326740
[10:00] <dpm> pitti, I've also lowered the priority of libgweather-locations
[10:00] <pitti> dpm: exiv2 is huge and can also be lowered IMHO; it has tons of not-really-translated camera models, hmm
[10:01] <dpm> seb128, yeah, that won't make it go away
[10:01] <pitti> dpm: oh, but we still want that on touch, I figure?
[10:02] <dpm> pitti, you mean that we want exiv2 in touch? I know gallery depends on it, but I'm not sure we show any translations for camera models in the UI
[10:02] <seb128> bluesabre, they are in the SRU unapproved queue (https://launchpad.net/ubuntu/trusty/+queue?queue_state=1)
[10:02] <pitti> it's not like they'd actually get translated :)
[10:03] <pitti> msgid "EOS Rebel T2i / 550D / Kiss X4"
[10:03] <pitti> msgstr "EOS Rebel T2i / 550D / Kiss X4"
[10:03] <seb128> somebody from the SRU team needs to review/accept them
[10:03] <pitti> dpm: but anyway, this file also has a lot of (what looks like) human visible strings
[10:03] <pitti> dpm: I'm not sure whether it actually does display any string from the library, or just has its own
[10:10] <dpm> pitti, let me ask nerochiaro. I've seen exiv2 being used in camera and gallery, but my hunch is that we don't display any strings
[10:12] <dpm> pitti, it seems we only use exiv2 to read metadata
[10:12] <pitti> dpm: ok, thanks; so it seems we can trim these packags quite some more :)
[10:13] <pitti> exiv2 is 700 kB alone per language
[10:13] <pitti> dpm: anyway, uploading fixed langpacks now
[10:14] <pitti> dpm: actually, I think I do want a -base refresh soon, so that I can remove the really badly translated desktop langpacks
[10:14]  * pitti requests
[10:15] <dpm> ok, I see you were quicker than I :)
[10:20] <dpm> pitti, which priority value are you using?
[10:20] <pitti> dpm: 1500
[10:21] <pitti> dpm: I made a few experiments this morning, and between 1500 and 2000 was already stuff that we want
[10:21] <dpm> ok, cool
[10:23] <pitti> dpm: ok, and on Wednesday the packs hopefully contain dialer-app :)
[10:24] <dpm> cool :)
[10:26] <mapreri> sil2100: ping
[10:27] <sil2100> mapreri: pong
[10:28] <mapreri> sil2100: here https://bugs.debian.org/750148 you stated that you want to package lucene++ for debian. That mean I can change the bug to an ITP and set you as owner? (I'm doing a wnpp cleanup)
[10:28] <dpm> pitti, I've made some notes on the list of domains. I think we should still be able to further filter out, but we'd be reaching the limits of priority-based filtering, as we cannot just lower down the priority of all the packages without affecting the desktop priorities too. I think what we've got now might be a good start and we can look at more filtering on the next ones. Perhaps filtering on priority + a static blacklist might be an option? In any ca
[10:28] <dpm> se, here is the list of current domains you gave me, with the comments: http://pad.ubuntu.com/touch-domains
[10:28] <sil2100> mapreri: sure :) I might even do some work today for that one
[10:29] <mapreri> sil2100: good. The persone who report that bug made a gread "disaster" (a RFS bug for every binary package -.-)
[10:30] <sil2100> mapreri: yeah, I saw that, but then I saw that someone renamed the lucene++0 one to lucene++
[10:30] <pitti> dpm: thanks; I'm afraid I can't immediately answer most of these, but we should also consider their size; i. e. it doesn't make much sense to carefully maintain blacklists for 5 kB files, but for things like exiv and gtk[23]0-properties that's certainly worth it
[10:30] <sil2100> So I decided to comment on that particular one
[10:31] <mapreri> sil2100: he reneamed from liblucene++0 to liblucene++, I'm going to rename it again to lucene++.... Anayway good choice.
[10:31] <sil2100> mapreri: ah, ok, I missed that one... thanks for working on that!
[10:32] <dpm> pitti, yeah, I agree, but I'm more concerned about domains that are generally not translated affecting the stats and thus the languages included in the langpacks than the size per se
[10:33] <dpm> e.g. as exiv2
[10:33] <pitti> dpm: ah, right
[10:36] <pitti> ogra_: I uninstalled German langpacks on my phone, verified that indicators and some other things are untransalted, installed language-pack-touch-de, and all back to normal
[10:36] <ogra_> cool !
[10:36] <pitti> ogra_: hence I'd like to commit http://paste.ubuntu.com/7652390/ ; can I just do that or does that need an MP? also, do I need anything else?
[10:36] <pitti> ogra_: (except for the obvious double *, fixed locally already)
[10:37] <ogra_> pitti, just go ahead ... we usually dont do MPs for seed changes since you need to manually update -meta anyway
[10:37] <pitti> ogra_: right, I'll do that afterwards
[10:38] <ogra_> pitti, we probably want to only have langpacks for the langs we have keyboards for ...
[10:39] <ogra_> (just strikes me ... )
[10:39] <pitti> ogra_: well, don't we use some IM for e. g. Chinese?
[10:39] <pitti> I had assumed they'd use an English keyboard with some IM on top
[10:39] <ogra_> might be, not sure
[10:40] <pitti> ah, ubuntu-keyboard-chinese-pinyin
[10:40] <ogra_> ubuntu-keyboard-chinese-pinyin
[10:40] <smb> apw, Can you remember whether you sponsored drbd8 for precise for me (well actually whether only the *12.04.2 or *12.04.3 combined). Somehow the pending sru report oddly shows the bug addressed in the combined one but it seems only the initial version was uploaded
[10:40] <ogra_> ah, you beat me :)
[10:41] <pitti> ogra_: so, I'm fine either way; we can always adjust it further, of course
[10:41] <ogra_> we can seed them all for now ... but i think in the end we should tie them to kbd layouts
[10:44] <pitti> ogra_: languages where we have langpacks, but no keyboard, FYI: Greek, Gaelic, Galician, Indonesian, Japanese, Latvian, Norwegian, Slovenian, Serbian, Ukrainian
[10:45] <pitti> ogra_: many of those can be done on an English or Russian keyboard, but certain not e. g. Greek
[10:45] <ogra_> right, some of these might prefer english kbds ...
[10:45] <pitti> or Japanese
[10:45] <ogra_> iirc greek people usually use english
[10:45] <ogra_> not sure about others
[10:45] <pitti> well, you wouldn't have Greek letters anywhere?
[10:46] <pitti> ogra_: well, I'll upload that for now; it already shrinks from 135 MB -> 32 MB, and with dpm's priority adjustments even more
[10:46] <ogra_> awesome
[10:46] <pitti> but indeed it's also a presentation matter, i. e. we might not offer some languages like Greek if you can't type them
[10:47] <ogra_> right, or we might just want to create kbd layouts for them
[10:47] <ogra_> i dont think it matters in tteh short term for now
[10:47] <dpm> pitti, awesome. Could we upload the 'ca' one for me to test it too?
[10:47] <pitti> dpm: how do you mean?
[10:48] <pitti> dpm: I uploaded all of them to utopic, and currently adjusting the touch seeds
[10:48] <pitti> (done)
[10:48] <pitti> dpm: ah no, -ca; sorry :)
[10:48] <dpm> pitti, yeah it didn't seem to make the cut-off
[10:49] <dpm> although the phone is very well translated
[10:50] <apw> smb, i cannot rembmer at all :)  but it is the sort of thing we would do together
[10:51] <pitti> dpm: http://people.canonical.com/~pitti/tmp/langpack-touch/
[10:51] <smb> apw, Yeah, unfortunately I see a bit of confusing data on http://people.canonical.com/~ubuntu-archive/pending-sru.html
[10:52] <smb> apw, Somehow .2 waits for verification and would be good if not somehow having the second bug referenced which cannot e verified with that version
[10:52] <dpm> pitti, awesome, thanks
[10:53] <apw> smb, seems i didn't sponsor either of them
[11:01] <pitti> dpm: I started with http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/revision/478
[11:01] <pitti> dpm: maybe that's already enough to bring it over the hump :)
[11:02] <dpm> pitti, ah, nice, thanks :)
[11:02] <dpm> I think exiv2 will be the one to make the difference, yes
[11:03] <pitti>   caribou 5883 (90%)
[11:03] <pitti> WTF
[11:03] <pitti> dpm: "ca  5883 (90%)" :)
[11:03] <pitti> caribou: sorry, I was pasting ca<tab>
[11:03] <dpm> :)
[11:03] <dpm> (yay!)
[11:05] <pitti> dpm: so, I'll build fresh ones on Wednesday, with (hopefully) dialer-app
[11:06] <dpm> sounds great, thanks a lot
[11:09] <smb> Ok, looks that actually the drbd8 package uploaded is a merged version from what I had prepared (including my .2 and .3 and merging the changelog).
[11:18] <Laney> doko: know about this ld segfault? http://paste.ubuntu.com/7652533/
[11:28] <caribou> pitti: no worry
[11:28] <caribou> pitti: there's a package called caribou as well
[11:45] <Laney> doko: (filed #1330451)
[12:04] <doko> Laney, do you build with these malloc settings by default?
[12:04] <Laney> comes from the test harness somewhere
[12:04] <doko> "the"?
[12:05] <Laney> in glib
[12:07] <Laney> which uses automake's AFAIK
[12:15] <Laney> doko: ah no, glib sets it itself
[12:15] <Laney> still ld, shouldn't crash
[12:15] <Laney> (that comma slipped across one word)
[12:31] <LocutusOfBorg1> sil2100, sorry I read some news about lucene++ but I joined the chan when you said the last reply
[12:31] <LocutusOfBorg1> any progress on debian side?
[12:32] <LocutusOfBorg1> :)
[12:33] <sil2100> LocutusOfBorg1: hi! Will make some progress today, in the morning we only had some paper-work discussion
[12:35] <LocutusOfBorg1> ah ok :)
[12:35] <LocutusOfBorg1> I read just a few words when I joined today
[12:43] <cjwatson> doko: does https://launchpad.net/ubuntu/+source/sogo/2.2.5-1/+build/6081133 make any sense to you?  is gobjc just entirely broken right now or something?
[12:45] <doko> cjwatson, I assume this is the 4.8/4.9 version mismatch ... so once we default to 4.9 again, that should go away. couldn't reach tvoss today, but this should be done today or tomorrow
[12:45] <tvoss> doko, ping
[12:45] <doko> tvoss, yes ...
[12:46] <tvoss> doko, around. MR'd the dbus-cpp change, checked on process-cpp
[12:46] <doko> "MR"?
[12:46] <tvoss> merge request
[12:48] <doko> tvoss, including the versioned b-d?
[12:49] <tvoss> doko, yeah, I added g++ (>= 4.9). Is that correct?
[12:49] <smb> Ok, I did a quick verification of the missing part (second bug number) for the drbd8 backport in precise-proposed. So sooner or later it should move to updates anyway. But if someone could do it sooner, I think people currently broken will appreciate.
[12:52] <doko> tvoss, no
[12:53] <tvoss> doko, what is the correct version line, then? g++-4.9?
[12:53] <LocutusOfBorg1> can anybody please point me to the libav transition tracker?
[12:53] <LocutusOfBorg1> I uploaded hedgewars in debian, I would like to track the ubuntu sync, to make sure it doesn't fail to build somewhere
[12:54] <doko> tvoss, g++ (>= 4:4.9.0-3ubuntu6)
[12:55] <mantiena-baltix> Hi, maybe someone could sync new meld package from Debian experimental - current meld package in Ubuntu Utopic is completely broken, see LP bug #1298266
[12:57] <seb128> you should subscribe ubuntu-sponsors to the sync request
[12:58] <LocutusOfBorg1> done
[13:01] <mantiena-baltix> seb128: thanks\
[13:01] <seb128> yw!
[13:01] <doko> tvoss, please let me know when you are done
[13:08] <tvoss> doko, updated: https://code.launchpad.net/~thomas-voss/dbus-cpp/bump-so-name-and-major-version/+merge/223224
[13:18] <pitti> xnox: hey Dimitri, how are you?
[13:18] <pitti> xnox: I'm afraid I'm a bit behind: where do we stand wrt. startpar these days?
[13:19] <shadeslayer> pitti: https://bugs.launchpad.net/debian/+source/abi-compliance-checker/+bug/1330481 < could you have a look at that
[13:20] <pitti> shadeslayer: yes, that makes sense; let's see what the Debian maintainer says?
[13:21] <pitti> otherwise it'll need to become a test dep
[13:23] <shadeslayer> pitti: haven't heard back from the debian maintainer in forever
[13:23] <stgraber> smb: it takes a bit of work to copy the packagesets to old series and grant matching rights to it so we don't do that by default. Can you e-mail devel-permissions about it? (I'm off today and about to leave now)
[13:24] <smb> stgraber, ack. thanks
[13:26] <brendand> what's the command to delete a chroot? or is it done some other way?
[13:32] <pitti> brendand: is that schroot, or plain chroot?
[13:33] <pitti> brendand: with a plain chroot, just rm -rf; but make double sure that you unmount all bind mounts before :)
[13:34] <brendand> pitti, well i'm using schroot
[13:35] <pitti> brendand: "sudo schroot -e --all-sessions" is quite useful for cleaning up a pile of leftovers
[13:35] <pitti> brendand: otherwise, sudo schroot -e -c <session name>
[13:35] <pitti> -e == --end-session
[13:36] <cjwatson> brendand,mvo: https://code.launchpad.net/~cjwatson/cupstream2distro-config/click-tests/+merge/223240 - flying a bit blind so hopefully not totally broken
[13:36] <brendand> pitti, --list still shows things though
[13:36] <mantiena-baltix> Hi again, gnome-main-menu package isn't synced from Debian, see http://packages.qa.debian.org/g/gnome-main-menu.html and https://launchpad.net/ubuntu/+source/gnome-main-menu
[13:37] <pitti> brendand: you mean --list --all-sessions ?
[13:37] <pitti> brendand: oh wait, this is for removing sessions, not the underlying chroot, sorry
[13:37] <cjwatson> brendand: end all sessions, check nothing's mounted from that chroot, then "rm -rf --one-file-system" the chroot files in /var/lib/schroot/chroots/ and the configuration file in /etc/schroot/chroot.d/
[13:37] <brendand> cjwatson, i'll get fginther to have a look at it. he's the expert
[13:37] <cjwatson> brendand: ta
[13:37] <pitti> brendand: end all sessions for it, then rm -rf the directory (or tarball), and remove the config in /etc/schroot/chroot.d/
[13:38] <cjwatson> brendand: where would this actually end up?  https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/ClickPackage/ doesn't look current
[13:38] <mantiena-baltix> It seems this is because gnome-main-menu was removed from Ubuntu at ~11.10, but now this package is actively maintained by mate team. Should I report a bug and subscribe ubuntu-sponsors to that bug?
[13:39] <brendand> cjwatson, s-jenkins
[13:39] <mitya57> mantiena-baltix: See http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[13:40] <mitya57> You should probably contact pitti (or release team) to get it removed from blacklist.
[13:40] <mitya57> Better release team, I think.
[13:41] <cjwatson> no, archive team.  file bug with rationale, subscribe ubuntu-archive
[13:42] <cjwatson> brendand: ah, I guess https://jenkins.qa.ubuntu.com/view/Utopic/view/All/ is the public one
[13:42] <cjwatson> brendand: (digging through private jenkins instances is a pain and not community-friendly so I try not to if I can avoid it)
[13:42] <brendand> cjwatson yeah
[13:42] <cjwatson> https://jenkins.qa.ubuntu.com/view/Utopic/view/All/job/url-dispatcher-utopic-amd64-ci/ seems to be an example with coverage
[13:45] <fginther> brendand, what am I the export for?
[13:45] <fginther> hmmm, that should have been expert. I'm not sure I can export anything useful
[13:46] <brendand> fginther, that's funny. i almost mispelled it 'export' myself
[13:46] <brendand> fginther, cupstream2distro
[13:46] <brendand> fginther, cjwatson just submitted an MP to have a job for click
[13:46] <fginther> brendand, I'm checking that out now. does the build already create a coverage.xml file?
[13:47] <brendand> fginther, yes it should
[13:47] <fginther> cool
[13:56] <doko> Laney, the ld issue is known upstream. should be fixed with the next upload
[13:56] <Laney> doko: ok, do you know when?
[13:56] <Laney> any chance of a cherry-pick?
[13:57] <Laney> can't build glib until it's fixed
[13:57] <doko> there seem to be many cherries to pick ...
[13:57]  * Laney is trying a build with some tasty looking cherries right now as it happens
[13:57] <ogra_> yum, cherrres
[13:58] <ogra_> *cherries
[13:59] <Laney> tee: ../binutils_2.24.51.20140612-0ubuntu2_amd64.build: No space left on device
[13:59] <Laney> bad cherry :(
[14:00] <mantiena-baltix> cjwatson: against which ubuntu package/component I should report bug about missing gnome-main-menu?
[14:01] <cjwatson> mantiena-baltix: you can just report it against gnome-main-menu even though that's been removed; it doesn't matter as long as ubuntu-archive is subscribed
[14:17] <mantiena-baltix> Is this bug correctly reported? LP Bug #1330500
[14:18] <jdstrand> @pilot in
[14:19] <Laney> doko: I took c72f2fb2bb6a3e1850b081dbfce4040970fae8e6^..d495ab0d843def702a6641fa4fc31708d7fc97b1 and it doesn't segfault on that example now
[14:21] <doko> Laney, can you upload? not sure if I will make it today. there is one more ARM issue I'd like to look at
[14:22] <Laney> doko: well I want to fix glib in experimental too, not sure I'm brave enough to upload binutils there :)
[14:23] <doko> well, then please wait a day
[14:23] <Laney> I can wait for your next snapshot
[14:23] <doko> ok
[14:23] <Laney> it at least confirms that this issue should be fixed with that
[14:27] <mitya57> Noskcaj: Your jquery and jquery-goodies uploads dep-wait on node-uglify (which is not in main, because we don't want nodejs in main)
[14:28] <mitya57> Hm, no, jquery-goodies is not your upload, it was autosynced. But anyway, please fix jquery (and add back recommends on javascript-common).
[14:39] <cjwatson> manjo: yes
[14:39] <cjwatson> manjo: sorry
[14:39] <manjo> cjohnston, no worries
[14:40] <cjwatson> ha, touché
[14:40] <manjo> cjwatson, ^ ooops
[14:40] <Laney> haha
[14:40] <cjwatson> mantiena-baltix left apparently
[14:40] <ogra_> lol
[14:54] <LocutusOfBorg1> LOLOLOL
[14:55] <LocutusOfBorg1> please loook at this bug report
[14:55] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/boinc/+bug/1330507
[14:55] <LocutusOfBorg1> how the fuck they report windows bugs on launchpad?
[14:57] <rbasak> LocutusOfBorg1: you could be more polite. What if boinc hosted their upstream bug tracker on Launchpad, for example? Then it would only be a minor error.
[14:57] <rbasak> LocutusOfBorg1: maybe point the reporter to http://boinc.berkeley.edu/trac/?
[14:57] <LocutusOfBorg1> reload the page
[14:57] <LocutusOfBorg1> :)
[14:57] <LocutusOfBorg1> I already did this
[14:57] <LocutusOfBorg1> I was writing
[14:58] <rbasak> Thanks
[14:58] <LocutusOfBorg1> no, boinc doesn't use lp as upstream bug tracker
[14:58] <LocutusOfBorg1> I just replied with the "seriously", but I was already writing the correct answer :D
[15:10] <seb128> sil2100, tvoss: net-cpp fails to build on ppc with a test failure, is that something being worked?
[15:11] <sil2100> !
[15:11] <tvoss> seb128, got a build log for me?
[15:11] <seb128> tvoss, sil2100: https://launchpadlibrarian.net/177394289/buildlog_ubuntu-utopic-powerpc.net-cpp_0.0.1%2B14.10.20140611-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:11] <sil2100> seb128: ok, I need to apologise for this one, it seems that citrain does not inform of such failures in case of NEW packages (as it has no 'archs available' from the archive)
[15:12] <sil2100> seb128: so it slipped my eyes completely :|
[15:12] <seb128> sil2100, no worry
[15:12] <sil2100> seb128: I was unaware it failed for ppc...
[15:12] <sil2100> I remember the unit tests had some issues once in net-cpp, not being entirely reliable, but I wonder if it's the same thing still
[15:14] <seb128> sil2100, tvoss: source package looks good for NEW, I'm going to accept it, but please look at/fix the ppc build
[15:14] <sil2100> seb128: thank you! And sorry for missing this one out
[15:15] <seb128> that happens, no worry
[17:21] <p0s> did you guys find out where you have an eclipse maintainer? :)
[17:36] <dobey> p0s: if eclipse is in the archive, then information about who maintains it, is also in the archive
[17:37] <p0s> dobey: where is that?
[17:40] <dobey> pbn: "apt-cache show eclipse"
[17:41] <p0s> dobey: yea someone suggested that already, only results in mailing lists (Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> / Original-Maintainer: Debian Orbital Alignment Team <pkg-java-maintainers@lists.alioth.debian.org>)
[17:42] <dobey> so what is the problem? that seems pretty clear to me
[17:42] <p0s> dobey: well i was hoping to find someone which could talk to live on IRC
[17:45] <dobey> you should mail the debian java maintainers list probably. there are no changes in ubuntu to eclipse. we are just including the package from debian right now
[17:45] <p0s> dobey: the problem is that its unusably broken and someone needs to update it to the latest version available, and i wonder whether debian will do that, being a conservative distro...
[17:46] <p0s> dobey: i might try my luck in the debian channel though :|
[17:47] <dobey> p0s: i would hardly call debian conservative
[17:47] <manjo> in d-i are proxy's setup done before NTP setup ?
[17:47] <p0s> dobey: ok well thanks :)
[17:49] <dobey> p0s: i'm sure the maintaienrs will appreciate help to get a newer version in if there is one; but it will only go into experimental/unstable at first. at some point can go to testing. but it's not likely to get updated in stable
[17:49] <dobey> but once it's in unstable, you can ask for it to be synced to ubuntu, and it will be included in the archive for the next release of ubuntu
[17:50] <p0s> dobey: well the version in ubuntu is from 2012, and the bug which breaks it has 114 people claim to be affected, which is something which i haven't seen in any other bug reports, so its rather very likely that it doesn't work for anyone...
[17:51] <p0s> dobey: and there has been a new version in june 2013 which is claimed to fix the issue...
[17:51] <dobey> p0s: well, i guess packaging of eclipse is also pretty complex, as upstream likes to do their own thing
[17:51] <p0s> dobey: FYI https://bugs.launchpad.net/eclipse/+bug/1241101
[17:53] <dobey> ok
[18:03] <hallyn> is there a way for me to kill ppa builds (that i know will time out eventually) msyelf?
[18:53] <infinity> hallyn: Do you not have a cancel button on your builds?
[18:56] <hallyn> infinity: d'oh.  not if i dont' log in...  thx
[18:57] <infinity> hallyn: We can change the permissions to anonymous users can kill any build owned by you (and only you), if that makes your life easier. :P
[18:57] <infinity> s/to/so/
[18:58] <hallyn> i miss the innocent internet
[18:58] <infinity> Yeah, 1993 was a good year.
[18:59] <infinity> Well, I guess 1992.  It all went to hell in a handbasket in 1993.
[20:00] <xnox> pitti: latest status from UOS was to make blueprint to start tracking stuff properly.
[20:00] <xnox> startpar is not enabled yet, still had a few packages to fix / upload.
[20:00] <xnox> don't like the task patch, thus want to enable without startpar learning about tasks
[20:02] <tedg> xnox, What was the PPA you gave me for upstart with cgroups?
[20:21] <dobey> hmm
[20:22] <tedg> xnox, slangasek, using the daily upstart PPA it seems that my phone/emulator don't finish boot. Is that known or should I investigate enough to file a bug?
[20:24] <slangasek> tedg: I don't know anything about it; most of the time all I see of the daily upstart PPA is build failures.  Please investigate :)
[20:24] <tedg> Heh, okay. Was hoping for a different answer ;-)
[20:25] <infinity> tedg: The pheasant has no agenda.
[20:27] <infinity> rcj: That open-vm-tools-lts-trusty in precise-proposed looks suspect to me.
[20:28] <infinity> rcj: You can't both have a transitional package *and* have the package it's transitioning to conflict/provide that same package.
[20:28] <infinity> rcj: Erm.  By which I mean open-vm-tools in trusty-proposed.
[20:30] <hallyn> infinity: say would it be possible to get a process listing on  chindi06 where a ppa build is hanging?
[20:30] <infinity> rcj: What you want here is "foo-lts-trusty, Depends: foo" and "foo, Breaks/Replaces: foo-lts-trusty (<< transitional version)"
[20:31] <infinity> hallyn: Nope.
[20:31] <hallyn> infinity: drat.  thanks.  will just keep bisecting then
[20:31] <rcj> infinity, okay.  I'll correct it.
[20:31] <infinity> rcj: Did that make sense?
[20:32]  * infinity goes for lunch.
[20:38] <rcj> infinity, it did make sense
[21:30] <tedg> slangasek, I filled bug 1330692, went to the end of my understanding. Hope it helps some :-)
[22:24] <brentwal1her> How do new versions of packages become updated in the repositories?
[22:25] <brentwal1her> I'm curious because the i3 package is behind many versions and the maintainer is "Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>"
[22:26] <sarnold> brentwal1her: it depends if the package needs a sync or a merge -- a sync is just a copy from debian, a merge is needed if there are ubuntu-local changes to the package
[22:27] <sarnold> brentwal1her: this is a useful place to start learning about it: https://wiki.ubuntu.com/SyncRequestProcess
[22:28] <brentwal1her> Thank you sarnold
[22:29] <cjwatson> In this case it's in sync with Debian, and the version of i3 in utopic was updated yesterday to the latest version from upstream.
[22:29] <cjwatson> We don't normally update stable releases to new upstream versions, only cherry-pick important bug fixes as needed.
[22:29] <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates describes that process.