[00:00] <Bluefoxicy> geofft:  I checked for updates and patches and fixes.  14.04 wasn't this broke, and it had hundreds of updates in the first week or so. This has been a dead stick; no patches coming down.  I am completely up to date.  :|
[00:00] <Bluefoxicy> oh, and I'm using an Intel core i5 with Intel HD 3000 graphics
[00:00] <Bluefoxicy> If anything should not be broken, it's the Intel graphics driver :|
[00:01] <JanC> Bluefoxicy: keep dreaming  :p
[00:01] <Bluefoxicy> Seriously this is like when people had XP and installed Vista.  I was like "ahahaha I have Ubuntu over here"
[00:01] <JanC> (Intel driver did break several tbefore)
[00:01] <Bluefoxicy> and now I'm like A*<#AG<Y(%I#(CT#<IU)(#$C
[00:02] <JanC> *times*
[00:02] <Bluefoxicy> Gnome keeps forgetting my keymap, so I have to go load something else and then delete it to get dvorak back
[00:02] <JanC> but not sure this is what's happening here
[00:02] <Bluefoxicy> oh and then I get a pop-up dialog telling me I have multiple input methods installed and that it doesn't know what to do with my config.
[00:05] <JanC> do you?
[00:10] <JanC> (do you use multiple input methods?)
[00:20] <Bluefoxicy> JanC:  I mean like... ibus and imx or such
[00:20] <Bluefoxicy> it's found 2 different installed back-ends to type in Gapanese or Arab or something.
[00:20] <JanC> so, any reason why you have 2?
[00:20] <Bluefoxicy> Think of it like having SystemD and upstart both running
[00:21] <Bluefoxicy> no, no reason I have 2.  I wound up with 2 during the 14.04 to 14.10 upgrade and don't know why.
[00:22] <JanC> likely you had 2 before?
[00:23] <JanC> or maybe ibus got pulled in while you had another one
[00:23] <Bluefoxicy> Possibly.  Not sure how I got 2 in the first place.  I know how I got 1:  I had set up the keyboard a year ago to type japanese
[00:24]  * Bluefoxicy eats a pork chop.
[00:24] <Bluefoxicy> I'm pretty sure this is the first time I've actually regretted upgrading my OS.  Ever.
[00:36] <Bluefoxicy> oh
[00:36] <Bluefoxicy> my god.
[00:37] <Bluefoxicy> JanC:  it's sound.
[00:37] <Bluefoxicy> Rhythmbox hangs.  VLC won't play sound, but plays video.  Flash plays video, but no sound.
[00:41] <Bluefoxicy> http://pastie.org/9682073
[00:41] <Bluefoxicy> so is this bad?
[00:43] <Bluefoxicy> seems like an occasion to reboot, to me
[00:47] <Bluefoxicy> Yeah... that's bad.
[03:05] <hyperair> what's the colour of the default ubuntu tty?
[03:06] <hyperair> i mean the actual tty, not gnome-termianl
[03:07] <infinity> hyperair: Black?
[03:07] <hyperair> okay
[03:07] <hyperair> i'm still sane.
[03:07] <hyperair> still sane
[03:07] <hyperair> *deep breaths*
[03:07] <infinity> Doesn't sound like it...
[03:08]  * infinity backs away slowly.
[03:08] <hyperair> 11:00:14 <bonsaikitten> ubuntu just lacks basic QA
[03:08] <hyperair> 11:00:35 <hyperair> :/
[03:08] <hyperair> 11:00:39 <bonsaikitten> e.g. their black is still broken, startup flickers in ways that suggest no one cares, and distro upgrade usually self-destructs
[03:08] <hyperair> 11:00:44 <hyperair> black?
[03:08] <hyperair> 11:00:52 <bonsaikitten> yeah, black is purple
[03:08] <hyperair> deep calming breaths
[03:08] <hyperair> must not rage
[03:08] <hyperair> must not flip tables
[03:09] <rww> > gentoo developer
[03:09] <rww> > complaining about upgrade stability
[03:09] <rww> hrm.
[03:09] <infinity> hyperair: I'd love bug reports for the last thing.
[03:09] <hyperair> rww: lol! i didn't notice!
[03:09] <geofft> also it's not purple, it's aubergine. please.
[03:10] <hyperair> :)
[03:10] <infinity> hyperair: I mean, assuming he's interested in being constructive instead of just slagging Ubuntu for kicks.
[03:10] <RAOF> GRUB's background is aubergine, which is what most people will be seeing for most of the boot...
[03:10] <hyperair> infinity: unfortunately i haven't been able to reproduce the distro upgrading self-destructing issue, because once i'm done, it's kinda... gone..
[03:11] <hyperair> infinity: and i'm just stuck picking up the pieces with dpkg --configure -a
[03:11] <hyperair> and apt-get install -f
[03:11] <hyperair> and aptitude install -f
[03:11] <hyperair> i ran those commands almost 20 times, each time upgrading 200 packages or so
[03:11] <infinity> hyperair: There are logs from the upgrade, generally.  The first failure is the interesting one.
[03:11] <hyperair> whera?
[03:12] <hyperair> where*
[03:12] <infinity> hyperair: In your experience, is this with update-manager/do-release-upgrade, or raw apt-get?
[03:12] <hyperair> infinity: do-release-upgrade bails halfwya
[03:12] <hyperair> it's done that for the past few distro upgrades for me
[03:12] <hyperair> but this time was particularly bad, because apt-get install -f wouldn't budge
[03:12] <hyperair> a bunch of odd broken packages here and there
[03:12] <hyperair> aptitude install -f did work
[03:12] <infinity> Kay.  It leaves a log somewhere (I forget the precise name) when it explodes.
[03:13] <hyperair> but even that only managed to move 200 packages or so
[03:13] <infinity> I wonder if we could get away with taking "anonymous usage statistics" that grabbed people's package lists.
[03:13] <hyperair> and then it bailed again a few times due to broken postinst or something
[03:13] <infinity> Cause testing random upgrade paths is nice, but doesn't simulate real users.
[03:13] <hyperair> infinity: cue: ubuntu IS SPYWARE
[03:13] <infinity> hyperair: Yeah.
[03:14] <hyperair> god fucking damnit
[03:21] <ScottK> Well once you start sending local search results to remote servers by default, you can't blame people for being suspicious.
[04:30] <hyperair> yeah well, it's a little hard to benefit from hive-mind optimization without sending local search results to remote servers.
[04:36] <JanC> infinity: if you ask the users nicely, probably
[05:53] <Logan_> is it okay to forward patches to debian for build-depending on libappindicator-dev for indicator support? they do have that package as well
[05:57] <pitti> Good morning
[05:58] <hyperair> Logan_: it depends.
[05:58] <hyperair> Logan_: debian does have libappindicator
[05:58] <hyperair> but most people don't use it, and more importantly, it breaks the UX on DEs that use GtkStatusIcon
[05:58] <Logan_> ah, I see
[05:58] <hyperair> i mean the standard notification area
[05:59] <Logan_> so a given Debian maintainer probably wouldn't accept the patch?
[05:59] <Logan_> and I should keep the delta?
[05:59] <hyperair> i know appindicator has some fallback that stuffs itself into the notification area, but it clobbers left click launch, and launches the menu on left click
[05:59] <Logan_> well that's wonderful :P
[05:59] <hyperair> it depends. don't file a bug, just try looking for the maintainer directly
[05:59] <Logan_> he orphaned the package
[05:59] <hyperair> oh lol
[05:59] <hyperair> then it's up to qa.debian.org
[05:59] <hyperair> which package is this?
[06:00] <Logan_> flush
[06:00] <Logan_> some obscure Bittorrent client
[06:00] <hyperair> heh i see
[06:00] <hyperair> is upstream still alive?
[06:00] <Logan_> idk, I like forwarding things whenever possible
[06:00] <Logan_> no, it's inactive
[06:00] <hyperair> you could try forwarding
[06:00] <Logan_> I guess the worst that could happen is they don't accept the patch
[06:01] <hyperair> yeah
[06:01] <Logan_> usually Debian gets mad if we forward things without justification, though
[06:01] <hyperair> not Debian in general, but some maintainers
[06:01] <Logan_> yes, I should've clarified that
[06:01] <ScottK> If it's orphaned and dead upstream, removal is more likely the right move.
[06:02] <hyperair> true that
[06:02] <Logan_> the Git repo hasn't been touched in two years
[06:02] <Logan_> it's marked as inactive on Sourceforge
[06:02] <Logan_> and it doesn't even support magnet links :P
[06:03] <hyperair> Logan_: with my DD hat on, i'd say that the first time a dumb patch is uploaded, i'd reject it with an explanation. and the following times, possibly without an explanation
[06:03] <Logan_> if it's orphaned, do I have to ask for approval from QA before filing for removal in Debian?
[06:03] <hyperair> hmm
[06:03] <ScottK> Logan_: In Debian, the QA team is everyone.
[06:03] <Logan_> so I can ask myself
[06:03] <hyperair> i don't think there's any prereq for filing for removal
[06:03] <ScottK> Yes.
[06:04] <hyperair> check popcon
[06:04] <hyperair> some users might get annoyed
[06:04] <hyperair> but that could be a good thing
[06:04] <ScottK> Then they can maintain it.
[06:04] <Logan_> :D
[06:04]  * hyperair has stepped up as maintainer for things that have been RM'd before
[06:04] <hyperair> mostly out of rage
[06:04] <hyperair> like NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO DON'T REMOVE THIS I STILL WANT IT
[06:04] <Logan_> I was so surprised when they removed compiz
[06:04] <ScottK> Take your motivation where you can get it.
[06:04] <hyperair> indeed
[06:04] <hyperair> wait
[06:04] <hyperair> compiz was removed?
[06:05] <hyperair> seriously?
[06:05] <Logan_> yep
[06:05] <hyperair> =\
[06:05] <hyperair> meh
[06:05] <Tribaal> huh
[06:05] <hyperair> whatever floats their boat.
[06:05] <Logan_> they said it was dead upstream I believe
[06:05] <Logan_> which is BS
[06:05] <hyperair> is it still maintained?
[06:05] <hyperair> smspillaz has retired from compiz iirc
[06:05] <goodwill> compiz is not dead?
[06:06] <Logan_> it's definitely still being developed
[06:06] <hyperair> afaik it's an undead state
[06:06] <hyperair> unity's moving away from compiz
[06:06] <hyperair> and after what canonical's done to compiz, it's probably just going to die without unity's support
[06:06]  * hyperair shrugs
[06:06] <Logan_> there's now an ITP for compiz in Debian
[06:07] <Logan_> that's amusing
[06:07] <goodwill> http://cgit.compiz.org/?s=idle
[06:07] <goodwill> or is somewhere else now?
[06:08] <goodwill> last change anywhere was 5 months and compiz core has not been updated in 3 years
[06:08] <hyperair> Logan_: that typically happens with RM'd packages.
[06:08] <hyperair> Logan_: i think it happened for aircrack also
[06:08] <hyperair> goodwill: bzr possibly
[06:08] <hyperair> because canonical loves bzr
[06:09] <goodwill> I've been meaning to ask does anyone else use bzr? what is it about bzr that Canonical loves
[06:10] <goodwill> hmmm ... I guess it is not dead
[06:10] <goodwill> how nice
[06:10] <hyperair> hmm, i think emacs used to use bzr
[06:10] <Logan_> I think they haven't switched to Git because it would require changing the whole LP infrastructure
[06:10] <hyperair> then they moved to git
[06:10] <hyperair> like every other sane project ;-)
[06:10] <infinity> We're working on git in LP, it's just not done yet.
[06:11] <Logan_> there's nothing special about Bazaar, other than that it's backed by Canonical
[06:11] <hyperair> infinity: oh, so it's actually being worked on!
[06:11] <Logan_> infinity: that's music to my ears
[06:11] <hyperair> infinity: that's nice!
[06:11] <Tribaal> infinity: nice :) Good to hear
[06:11] <infinity> goodwill: As for "what Canonical loves about it", it's that we developed it (and it predates git), and inertia is hard to overcome, even when you've "lost".
[06:11] <goodwill> right
[06:11] <goodwill> mercurial is still alive right?
[06:11] <infinity> Alive and well.
[06:11] <goodwill> good
[06:11] <goodwill> :)
[06:11] <goodwill> love mercurial
[06:11] <hyperair> meh
[06:11] <hyperair> git ftw
[06:11] <ScottK> Written in Python and used by Python upstream.
[06:11] <infinity> Not my cup of tea, but some communities swear by it.
[06:12] <Logan_> Mozilla does, for sure
[06:12] <Logan_> although they've been using Git for some projects as well
[06:12] <hyperair> oh mariadb uses bzr too
[06:12] <infinity> I'm a simple man, though.  I still don't mind SVN, even though that makes me a social pariah in the modern DVCS world.
[06:12] <Logan_> they'll probably move away from it once Ubuntu does
[06:13] <Logan_> go away Adam, we don't want your outdated opinions here ;)
[06:13] <Tribaal> well, bzr is a GNU project technically
[06:13] <infinity> RCS FOR LIFE.
[06:13] <hyperair> i wouldn't mind bzr so much if git-bzr was actually properly usable
[06:14] <hyperair> but about half of the time, it fails with some kind of error due to some weird compatibility issue with the repo it's trying to fetch from
[06:20] <RAOF> Probably doesn't help that bzr has a slightly richer data model.
[06:21] <hyperair> heh
[06:21] <hyperair> i've found some repositories with unresolvable tags as well
[06:21] <hyperair> referring to wrong hashes
[06:22] <infinity> RAOF: The richer data model, unfortunately, is sometimes a hindrance.
[06:22] <Logan_> crap
[06:22] <Logan_> I accidentally wrote utopic in a changelog instead of vivid
[06:22] <infinity> RAOF: Overly complicates things like tracking moves in merges and such.
[06:22] <infinity> Logan_: Need a reject from the queue?
[06:22] <Logan_> can someone please reject 0.9.12-3.1ubuntu1 from topic?
[06:22] <Logan_> *utopic
[06:23] <infinity> Logan_: flush, I assume?
[06:23] <Logan_> yup
[06:23] <Logan_> thanks :)
[06:23] <Logan_> I probably shouldn't be doing package merges at 2:30 AM
[06:23]  * Logan_ goes to sleep
[06:23] <RAOF> infinity: Right. I've not found git's non-handling of moves problematic, whereas bzr sometimes gets shirty.
[06:25] <Logan_> infinity: I thoroughly appreciated your rejection reason
[06:25] <infinity> Logan_: :)
[06:25] <infinity> Logan_: That's my default for "people I know/like well enough to not be professional".
[06:26] <infinity> Logan_: So, welcome to the inner circle, I guess.
[06:26] <Logan_> I feel so honored
[06:26] <pitti> oh, upgrading util-linux triggers update-initramfs -u, which now synchronously starts fstrim.service
[06:26] <pitti> that causes the package upgrade to hang a looooong time
[06:26] <pitti> infinity: ^ that's presumably not intended? fstrim.service shouldn't be started on package install IMHO
[06:27] <infinity> pitti: I feel like there's a Debian bug about this that I've seen fly by my INBOX.
[06:27] <infinity> pitti: I've been amazingly disconnected from all of that, but I need to get involved again before ah shanks me in my sleep.
[06:27] <pitti> oh, it was mvo who merged that, nevermind
[06:28] <pitti> I don't see anything relevant on https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=util-linux, I'll file one then
[06:45] <pitti> filed now as Debian bug 767194, I'll have a look
[06:45] <pitti> it's highly annoying as each initramfs upgrade now takes 10 minutes or longer
[06:47] <pitti> wgrant: hey William!
[06:48] <pitti> wgrant: all the outstanding imports at https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ciborium/+imports?field.filter_status=all&field.filter_extension=all , are these normal? the pots got imported over a week ago
[06:48] <wgrant> pitti: Probably because of the arch in the path?
[06:48] <pitti> wgrant: well, I imported the armhf pot and deleted all the others (as this is RTM)
[06:48] <wgrant> Some packages end up with the POs in both the source and binary directories.
[06:49] <pitti> wgrant: but the outstanding PO files are from all arches
[06:49] <pitti> i. e. neither get the armhf ones imported nor the !armhf ones ignored
[06:49] <pitti> wgrant: yeah, unfortunately stuff only ends up in the per-arch build dir for ciborium
[06:50] <pitti> but then again, https://translations.launchpad.net/ubuntu/utopic/+source/ciborium/+imports?field.filter_status=all&field.filter_extension=all looks similar
[06:50] <pitti> so perhaps that's "normal"
[06:50] <wgrant> pitti: Are you sure? The template path is currently set to "po/ciborium.pot", no arch.
[06:50] <pitti> wgrant: hm, that's not what I imported, but perhaps someone else already did that
[06:51] <pitti> https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ciborium/+pots/ciborium has translations, so supposedly it somehow works
[06:51] <wgrant> Examining the tarballs in the queue, they're in source/po/*.po too
[06:51] <wgrant> Someone should really fix all these cmake-y build systems to not produce both, though.
[06:51] <pitti> ok
[06:52] <wgrant> I don't think there's a problem here, besides the duplicated import entries.
[06:52] <wgrant> https://launchpad.net/ubuntu-rtm/14.09/+queue?queue_state=3&queue_text=ciborium, look at one of those tarballs.
[06:52] <pitti> wgrant: so po files in dirs where pot files got explicitly deleted/rejected don't get cleaned up, they just keep stuck in "needs review"?
[06:52] <wgrant> pitti: Files are approved based on templates, not based on other files.
[06:53] <wgrant> A queue entry has no idea that another queue entry was rejected.
[06:53] <wgrant> Though Blocked has some special handling.
[06:53] <pitti> wgrant: ok, so that is normal then?
[06:53] <wgrant> This particular case seems very common with qt things; someone should investigate and remove the duplication, I think.
[06:53] <wgrant> This behaviour is normal and expected given the input tarball, yes.
[06:53] <pitti> wgrant: ack, thanks for checking!
[06:54] <pitti> (and yay broken build systems)
[07:01] <wgrant> pitti: I guess that's probably easy enough to fix in pkgstriptranslations, too.
[07:09] <dholbach> good morning
[07:12] <pitti> hey dholbach
[07:14] <dholbach> hey pitti
[07:14] <dholbach> how's life over there?
[07:15] <pitti> dholbach: lots of catch-up to do from last week :)
[07:15] <dholbach> yep, I can relate to that :)
[07:51] <pitti> mvo: guten Morgen
[07:52] <pitti> mvo: so where's the magic in http://launchpadlibrarian.net/188488665/command-not-found_0.3ubuntu15_0.3ubuntu15.1.diff.gz ? is there an external blacklist which isn't represented in that diff, or did you hand-edit scan.data after scanning?
[07:54] <mvo> pitti: there is a external blacklist on nusakan
[07:55] <mvo> pitti: I ran a full scan with postgresql-xc blacklisted
[08:00] <pitti> mvo: ah, thanks; so SRUing this to trusty would merely mean to re-run scan, and it picks up the blacklist?
[08:02] <mvo> pitti: yeah, thats probably the most simple way, do you want me to prepare trusty too?
[08:03] <pitti> mvo: depends, if it's not too much effort for you; otherwise I can look into it. I mostly wanted to understand the mechanics how this works
[08:06] <pitti> mvo: I verified the utopic SRU, thanks!
[08:07] <mvo> pitti: no problem, I just started the extraction
[08:09] <Noskcaj> Does ubuntu have any plans to implement dep-11? https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAA&url=https%3A%2F%2Fwiki.debian.org%2FDEP-11&ei=uaBQVPyeE8btmQW7oYLYCQ&usg=AFQjCNFAC6PqqgyxzcQWi42MmlGzNBouKQ&sig2=mZX3PiNYRlsX2hlWGzHwKg
[08:09] <mvo> pitti: it takes some time to run though
[08:10] <pitti> mvo: would hand-editing have been faster?
[08:10] <pitti> well, I assume "yes"; I meant "more appropriate"
[08:11] <mvo> pitti: either way is fine, the upside of running the extraction again is that we catch if more got changed in trusty (which really shouldn't be the case). but yeah, hand-editing is the fastest path :)
[08:21] <ogra_> mvo, i just noticed that ubuntu-core-system-image fails to build images in vivid ... with the same issue we had on touch and ubuntu-core yesterday (image builds accidentially using PPA builders) ... infinity knows what to do (he fixed the two others)
[08:27] <mvo> ogra_: thanks, but it seems like the latest image build was successful (3h ago) - I had to update a bunch of stuff in the PPA because of vidid changes
[08:27] <ogra_> ah, k
[08:28] <ogra_> sorry, didnt check the timestamp on the mail
[08:33] <mvo> ogra_: no problem :)
[09:02] <ogra_> hmm
[09:04]  * ogra_ has by accident looked into his router syslog ... runnint minimal trusty there and i just noticed os-prober running there 
[09:04] <ogra_> is that normal ?
[09:04] <ogra_> i never saw that on an installed system
[09:09] <Laney> @pilot in
[09:09] <ogra_> irritating ...
[09:09] <ogra_> it also seems to load a lot of filesystem modules doing that
[09:10] <ogra_> even before os-prober runs
[09:13] <xnox> ogra_: os-prober is executed by update-grub
[09:13] <xnox> ogra_: well one of the snippets to test/check/detect/generate boot entries.
[09:13] <ogra_> xnox, why would that run on a regular basis on a running system  though ?
[09:13] <ogra_> i seem to see it pretty regular in syslog
[09:14] <xnox> ogra_: trusty gets new kernels every two weeks. so i'd expect it to run every two weeks.
[09:14] <ogra_> hmm
[09:14] <xnox> ogra_: unless your /boot is full, and unattended upgrades active, which would constantly try to configure new kernel, run os-prober, and fail.
[09:14]  * ogra_ checks his /boot 
[09:15] <ogra_> indeed i run unattended upgrades  ... since its a router :)
[09:15] <ogra_> andin fact there is a newer kernel than i run
[09:16] <ogra_> so why didnt i get a reboot notification on login
[09:16] <ogra_> my trusty server install definitely gives me one ... weird
[09:17]  * ogra_ guesses ubuntu-minimal lacks that bit 
[09:17] <ogra_> xnox, thanks ! you rock !
[10:11] <cjwatson> Laney: dh-autoreconf> I don't think so; part of the rationale for the split is that virtually nothing actually needs /usr/bin/libtool, and typically should be fixed if it does
[10:16] <LocutusOfBorg1> Laney, so should I ask for miniupnpc and transmission merges? I actually did them both, also rdesktop
[10:16] <LocutusOfBorg1> usually dholbach doesn't ask me to do, but I can ask if needed :)
[10:16] <LocutusOfBorg1> they are all trivial merges
[10:24] <Laney> cjwatson: Maybe so. I found three packages broken by this during the gi transition, which were using `libtool --mode=execute' in their test wrappers. (Okay, these three were Ubuntu specific)
[10:24] <Laney> LocutusOfBorg1: You risk duplicating work or missing some piece of knowledge
[10:24] <Laney> LocutusOfBorg1: See the first bullet https://merges.ubuntu.com/universe.html
[10:25] <Laney> This cycle I've already had two merges I was already working on performed by someone else
[10:26] <cjwatson> Laney: If they're doing that, then they should have a direct build-dependency anyway, rather than relying on dh-autoreconf to supply it for them.
[10:26] <cjwatson> Laney: But the right fix is to make them use the libtool in their build tree, not /usr/bin/libtool which may bear only passing resemblance in terms of configuration.
[10:27] <cjwatson> Laney: Compare e.g. http://git.savannah.gnu.org/cgit/man-db.git/tree/src/tests/testlib.sh#n17
[10:28] <Laney> Right
[10:28] <Laney> I'm just observing that there are things now which have become broken because they were assuming dh-autoreconf gave them /u/b/libtool
[10:28] <LocutusOfBorg1> oh indeed, so do you plan to merge gdcm? it is a package I worked on debian
[10:28] <cjwatson> Oh, yeah, just saying those are things to be fixed and not papered over
[10:29] <LocutusOfBorg1> bdrung, you there?
[10:30] <bdrung_work> LocutusOfBorg1, yes
[10:30] <LocutusOfBorg1> I would like to report a bug against wrap-and-sort
[10:30] <LocutusOfBorg1> but I ask you prior
[10:30] <LocutusOfBorg1> http://anonscm.debian.org/cgit/collab-maint/transmission.git/commit/?id=aa78e17e550005e12bd8251d694af450113f5d9c
[10:30] <LocutusOfBorg1> look at this
[10:30] <Laney> you know he's in #debian-devel too? :)
[10:30] <LocutusOfBorg1> wrap-and-sort dropped dpkg-dev b-d, because seems to strip everything after the first comment "#" in b-d
[10:30] <LocutusOfBorg1> ops :)
[10:31] <Laney> gdcm> go ahead
[10:31] <LocutusOfBorg1> Sometimes I feel more confortable here rather than in debian :)
[10:31] <bdrung_work> LocutusOfBorg1, i am 99% sure that this is a bug in python-debian (and it is probably already reported)
[10:32] <cjwatson> dpm: If you're talking about myspell-ca, I copied that in a few days back, you just weren't on IRC for me to respond at the time
[10:32] <darkxst> So Noskcaj posted a silly google link, but are there any plans for DEP-11 in ubuntu in the near future?
[10:32] <darkxst> pitti, cjwatson ^
[10:33] <darkxst> Ubuntu GNOME will probably switch to gnome-software at some point, but without that, is largely useless
[10:33] <pitti> I don't think it has ever been discussed so far
[10:33] <LocutusOfBorg1> bdrung_work, you mean something like #694142?
[10:34] <bdrung_work> LocutusOfBorg1, yes, that's exactly the bug you described
[10:34] <LocutusOfBorg1> :D thanks!
[10:34] <LocutusOfBorg1> I subscribed to it, thanks for avoiding me to report a new bug
[10:35] <bdrung_work> i should implement an option to just show the diff instead of applying it
[10:35] <bdrung_work> thanks for asking
[10:35] <LocutusOfBorg1> bdrung_work, I'm wondering how many times people drops b-d in an unaware mode
[10:35] <LocutusOfBorg1> seems dangerous!
[10:36] <bdrung_work> i only run wrap-and-sort in git repositories (where you can run 'git diff' afterwards to check the result)
[10:36] <LocutusOfBorg1> yes, but sometimes with huge dependencies it becomes difficult to track all of them, I double check them (this is why I spotted this one, in the transmission merge)
[10:37] <dpm> cjwatson, ah, awesome. I hadn't re-pinged as I wasn't sure if you were away. Thanks!
[10:37] <LocutusOfBorg1> but the "one-line" to multiline switch makes things hard
[10:38] <GunnarHj> dholbach: Thanks for uploading https://code.launchpad.net/~gunnarhj/ubuntu/vivid/im-config/merge-0.27-1/+merge/239853
[10:38] <GunnarHj> dholbach: Can you please push the branch too? (The bots didn't do their job.)
[10:40] <darkxst> pitti, right, would be good to start that discussion at some point, but not really a priority this cycle
[10:41] <darkxst> though given it require backend changes to the archives afaics it might be better to start sooner than later?
[10:44] <dholbach> GunnarHj, done
[10:45] <GunnarHj> dholbach: Great, thanks!
[10:57] <LocutusOfBorg1> Laney, can I give you the debdiff or should I open abug?
[10:57] <Laney> LocutusOfBorg1: bug please
[10:57] <LocutusOfBorg1> s/abug/a bug/
[10:57] <LocutusOfBorg1> ack
[11:01] <LocutusOfBorg1> FYI #1387114
[11:01] <LocutusOfBorg1> was trivial :)
[11:08] <ogra_> bah
[11:08]  * ogra_ glares at his half pushed livecd-rootfs branch 
[11:09] <ogra_> damn
[11:17] <LocutusOfBorg1> so will the next ubuntu have systemd by default?
[11:18] <LocutusOfBorg1> most of the ubuntu deltas I'm looking at have upstart init scripts, I'm wondering if they can be synced over
[11:23] <ogra_> mvo, any objections to me uploading livecd-rootfs ?
[11:24] <ogra_> (just ran into your changes there)
[11:27]  * ogra_ uploads ... 
[11:29] <Laney> ogra_: there's a sponsor request in the queue
[11:29] <Laney> can you take that at the same time?
[11:29] <Laney> actually two
[11:34] <cjwatson> LocutusOfBorg1: we'll need to retain upstart jobs as a transition mechanism for a while no matter what
[11:34] <cjwatson> LocutusOfBorg1: please don't drop those
[11:38] <ogra_> Laney, i'll have to do more subsequent uploads of livecd-rootfs today (this one is just to give you proper info in the build error so all needed changes are listed in it, i actually need to make these changes i teh next one)
[11:39] <ogra_> Laney, so yeah, i'll happily take them with the next one
[11:39] <Laney> thanks
[11:39] <Laney> One of them is basically a c+p of a script in ubuntu-touch hooks, wonder if they can be shared somehow
[11:40] <ogra_> i'll take a look
[11:40] <ogra_> hoperfully not the password hardcoding :)
[11:40] <ogra_> (since i'm just changing that bit)
[11:40] <Laney> nah, /etc/writable stuf
[11:41] <ogra_> ah, thats fine
[11:41]  * ogra_ notes that systemd causes issues in touch even before being the default 
[11:42]  * ogra_ blames lennart ... because everyone does
[11:49] <mdeslaur> @pilot in
[11:54] <mvo> ogra_: none, thanks
[11:54] <ogra_> :)
[11:54] <mvo> ogra_: sorry for the delay, was having lunch
[11:54] <ogra_> to late anyway :)
[11:55] <mvo> ogra_: I meant to upload them but got distracted :)
[11:55] <ogra_> (i assumed if you merge into trunk the code would be ready)
[11:57] <mvo> ogra_: yes, it should be fine and got tested in our PPA for some time already
[11:57] <ogra_> right
[11:57] <mvo> thanks
[11:57] <ogra_> :)
[11:59] <mvo> ogra_: oh, just got the mail from the archive that I did indeed upload (and not dreamed it). so you will have to do another upload with your "  * properly redirect error output in 99zz-check-uid-gid.chroot" change and a new version number. maybe you looked while LP was still processing the upload
[11:59] <ogra_> hmm
[11:59] <ogra_> mvo, did you debcommit ?
[12:00] <ogra_> the tree didnt have a new tag
[12:00] <ogra_> oh, and there is the rejected mail :P
[12:01] <ogra_> hmm the tree is a mess
[12:02] <ogra_> mvo, please push --overwrite your upload and do a proper debcommit ... seems the tree has my debian/changelog and my tag now
[12:03] <mvo> ogra_: sure, done
[12:03] <ogra_> thx
[12:03] <mvo> ogra_: at r990
[12:03] <mvo> ogra_: sorry for the trouble, that was the part I meant to do and got distracted
[12:04] <ogra_> yeah, no prob ...
[12:04]  * mvo hugs ogra_
[12:05]  * ogra_ hugs mvo 
[12:23] <LocutusOfBorg1> cjwatson, I never drop without asking first :) and of course *not* before any systemd transition :D
[12:23] <LocutusOfBorg1> and thanks for the clarification ;)
[12:53] <Laney> LocutusOfBorg1: are you going to handle rebuilds for gdcm?
[13:03] <LocutusOfBorg1> Laney, I have no upload privileges :( I can try a rebuild in a ppa if this helps
[13:03] <LocutusOfBorg1> should I?
[13:03] <Laney> test builds would be helpful
[13:04] <LocutusOfBorg1> camitk insighttoolkit insighttoolkit4 itksnap vmtk vtk-dicom right?
[13:05] <LocutusOfBorg1> this is what is given me with reverse-depends -b src:gdcm
[13:05] <Laney> anything that has a depends on libgdcm2.2
[13:06] <LocutusOfBorg1> ack
[13:12] <Laney> LocutusOfBorg1: miniupnpc is the same
[13:12] <geser> could someone please give-back gexiv2 and grilo. They failed as the gir files weren't in multi-arch directories, they should build now with the current gobject-introspection from vivid.
[13:12] <LocutusOfBorg1> ack
[13:14] <Laney> geser: yep
[13:15] <Laney> @pilot out
[13:48] <LocutusOfBorg1> Laney, uploading rdeps :)
[14:04] <seb128> bdmurray, pitti: do you know what that means?
[14:04] <seb128> SegvAnalysis: Skipped: missing required field "Disassembly"
[14:05] <seb128> unity8 segfault on the phone, apport failed to collect a dump, I wonder if that's the cause or a consequence
[14:17] <bdmurray> seb128: I believe the Disassembly is still in the report
[14:19] <bdmurray> seb128: I reported this as bug 1374544 a little while ago
[14:19] <seb128> bdmurray, thanks
[14:19] <seb128> in my case it is
[14:19] <seb128> no coredump/stacktrace in the .crash
[14:19] <bdmurray> ah, I believe that usually happens due to lack of memory on the device
[14:21] <LocutusOfBorg1> Laney, rebuilds for miniupnc done (I hope)
[14:21] <LocutusOfBorg1> some spurious armhf failures due to qemu crashes (multithread stuff)
[14:23] <LocutusOfBorg1> I also uploaded a vino merge in my ppa, I hope to have a feedback from seb128 :)
[14:23] <LocutusOfBorg1> ppa:~costamagnagianfranco/locutusofborg-ppa
[14:23] <seb128> LocutusOfBorg1, read https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1271358 §?
[14:24] <seb128> LocutusOfBorg1, basically we can't update since the new version drops the UI for controlling it, which is used under !GNOME desktops, including Unity
[14:25] <LocutusOfBorg1> anyway vino at least in debian uses the embedded miniupnpc
[14:26] <LocutusOfBorg1> so I hope it can be patched to use again it also in ubuntu, right?
[14:28] <seb128> LocutusOfBorg1, no, we don't want to use the embedded one
[14:28] <seb128> LocutusOfBorg1, we can't update anyway due to what I wrote before
[14:35] <LocutusOfBorg1> mmm so  miniupnpc is blocked by 1271358?
[14:36] <seb128> LocutusOfBorg1, why would it?
[14:36] <seb128> LocutusOfBorg1, did miniupnpc change soname/abi? in which case somebody needs to rebuild vino/make it work with that version
[14:36] <seb128> LocutusOfBorg1, updating vino is not the only way to get there
[14:38] <LocutusOfBorg1> ok so I'll try to rebuild it :)
[14:38] <seb128> thanks
[14:40] <LocutusOfBorg1> thanks to you for pointing me to the best solution ;)
[14:45] <LocutusOfBorg1> :( https://launchpadlibrarian.net/188608080/buildlog_ubuntu-vivid-amd64.vino_3.14.0-2ubuntu2.is.3.8.1-0ubuntu3_FAILEDTOBUILD.txt.gz
[14:50] <seb128> LocutusOfBorg1, yeah, needs code changes...
[14:56] <LocutusOfBorg1> seb128, yes, working on it
[14:56] <seb128> great
[14:58] <mdeslaur> @pilot out
[15:35] <pitti> seb128: I'm back -- seems you figured that out?
[15:36] <LocutusOfBorg1> seb128, I fixed it :)
[15:36] <LocutusOfBorg1> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/6518423
[15:36] <LocutusOfBorg1> :D
[15:49] <LocutusOfBorg1> Laney,  miniupnpc seems fine :)
[15:50] <Laney> k, i'll look soon
[15:59] <LocutusOfBorg1> Laney, no hurry :) I was just giving you the information, sorry if I bother :D
[16:56] <Riddell> LocutusOfBorg1: ping
[16:56] <Riddell> LocutusOfBorg1: bug 1357270 you included multiarch-python-include-dirs.diff
[16:56] <Riddell> LocutusOfBorg1: that points to http://public.kitware.com/Bug/view.php?id=14156
[16:57] <Riddell> which xnox says should be dropped
[16:57] <Riddell> who's right?
[16:57] <jono> mdeslaur, hey, pal
[16:57] <mdeslaur> uh-oh :)
[16:57] <jono> mdeslaur, can I ask a favor? there is an interesting discussion going on on the Bad Voltage forum about packaging, and your name came up :-)
[16:57] <mdeslaur> jono: what'd I do?
[16:58] <jono> would you mind going and responding? http://community.badvoltage.org/t/on-package-creation-and-maintenance/8358
[16:58] <jono> :-)
[16:58] <jono> others are of course, welcome to respond too :-)
[17:01] <xnox> Riddell: it's mostly harmless. But imho should be dropped, but i didn't retest rebuilding cmakish/pythony packages.
[17:01] <Riddell> xnox: there's two other patches, should I submit them upstream?
[17:01] <xnox> Riddell: timeline-wise LocutusOfBorg1 simply did the merge, with his intended change, preserving all others.
[17:01] <Riddell> boost-multiarch.patch cmake-crosscompile.patch
[17:02] <teward> is there a list of supported ubuntu architectures for precise and later lying around anywhere?  trying to figure out what alternative architectures exist for any given release
[17:02] <xnox> Riddell: boost-multiarch.patch possibly can also be dropped, but needs reverse-dep builds test.
[17:02] <xnox> Riddell: cmake-crosscompile.patch is required to stay, and is not fully ready for submission to upstream.
[17:03] <xnox> Riddell: i'm adding cmake-crosscompile patch re-review to my floss todo list. Will look at it during mini-debconf uk next weekend.
[17:03] <Riddell> thanks xnox
[17:04] <xnox> Riddell: i don't even have a vivid chroot yet, so I haven't done anything for this cycle yet.
[17:04] <xnox> (well sans all the things that got synced in)
[17:17] <pitti> Noskcaj, Laney: FYI, your libmediaart sync broke tracker: https://jenkins.qa.ubuntu.com/job/vivid-adt-tracker/11/?
[17:17] <pitti> so it's held back in -proposed
[17:18] <pitti> (uploader notifications aren't yet reenabled for vivid)
[17:18] <pitti> looks like this needs some porting, maybe a newer tracker upstream version
[17:20] <LocutusOfBorg1> Riddell, yes, as xnox said, that patch was intended for cmake 3
[17:20] <LocutusOfBorg1> s/3/2.8.12.2
[17:20] <seb128> LocutusOfBorg1, nice
[17:20] <LocutusOfBorg1> with cmake 3 some things can be dropped, and the debian changelog from fgeyer was already mentioning that
[17:20] <LocutusOfBorg1> I didn't open a new one, sorry for that :)
[17:20] <LocutusOfBorg1> seb128, thaks, was trivial
[17:20] <seb128> pitti, not really, well I still don't know why apport doesn't collect dumps for unity8 segfault on my phone, I edited the .py to change the 3/4 of free memory requirement to see if it's that
[17:21] <pitti> seb128: the dash takes more than  half of available memory (~ 550 MB), so it's indeed difficult; but with that check disabled it might work (unless it then runs into OOM, of course)
[17:22] <mdeslaur> jono: replied, thanks
[17:22] <seb128> pitti, yeah, let's see, it would be nice if apport was writing in the log if that'sthe reason it doesn't do the collection
[17:23] <pitti> seb128: ack; bug report appreciated (and assign to me)
[17:24] <seb128> pitti, I can do that, thanks ;-)
[17:24] <Laney> pitti: Indeed, new versions fix this
[17:28] <LocutusOfBorg1> xnox, why MultiArchCross.cmake is not in debian?
[17:28] <LocutusOfBorg1> I'm wondering why a plain sync isn't possible now
[17:29] <xnox> LocutusOfBorg1: because it's incomplete, and relies on (not present in debian) at the time qt packaging changes.
[17:29] <xnox> i need to reconcile it with debian's developments.
[17:30] <xnox> and as i said, i'll do that soon.
[17:30] <xnox> please keep it for now. otherwise ubuntu-touch sdk will break.
[17:35] <jono> mdeslaur, thanks!
[17:35] <mdeslaur> jono: ARGH We're sorry, but new users are temporarily limited to 3 replies in the same topic
[17:35] <jono> mdeslaur, I can fix that for you if you like?
[17:36] <mdeslaur> jono:  please, I have a long post #4 :)
[17:36] <jono> mdeslaur, ok one sec
[17:36] <LocutusOfBorg1> thanks for clarifying
[17:36] <jono> mdeslaur, should be fixed now
[17:37] <mdeslaur> jono: awesome, thanks!
[17:38] <LocutusOfBorg1> we are in the early development, so if cmake breaks something in python we can handle it, right?
[17:38] <LocutusOfBorg1> anyway, keeping a patch is safer :D
[17:42] <jono> thanks mdeslaur, for replying :-)
[17:43] <mdeslaur> jono: FWIW, my wife agrees that I am rude.
[17:45] <ogra_> mdeslaur, lies !!! she doesnt know you as good as we do !
[17:45] <ogra_> :)
[17:45] <LocutusOfBorg1> ;)
[17:45] <mdeslaur> ogra_: I know, right? :)
[17:50] <jono> mdeslaur, LOL
[18:57] <Noskcaj> pitti: That was to be expected. The new version has been merged
[19:33] <infinity> Ick.  bash is telling me about sudo on every invocation now?
[19:36]  * infinity wonders what's meant to write in_successful /etc/bash.bashrc 
[19:37] <infinity> Err..
[19:37] <infinity> What's meant to write $HOME/.sudo_as_admin_successful and why don't I have one?
[19:39] <mdeslaur> infinity: oh, did that get dropped in sudo? /me checks
[19:40] <mdeslaur> infinity: ah, crud, sudo is looking at the group called "admin" too
[19:42] <mdeslaur> infinity: I'll fix sudo
[19:42] <Jelle_> Hello guys. At the moment I got my Ubuntu server up and running, but I have to install the server-software for Jira. I followed the following tutorial: https://confluence.atlassian.com/display/JIRA/Installing+JIRA+on+Linux , altho at step 2.1 I need to execute a .sh file, but I get the 'Command not found' error. I hope someone can help me out :)
[19:42] <infinity> mdeslaur: Ah-ha.
[19:42] <infinity> mdeslaur: Make it check both, I guess, we get to retain backward compat forever.
[19:42] <mdeslaur> yep
[19:44] <infinity> mdeslaur: Might want to SRU the sudo change back too, so people on old releases get the semaphore created before they upgrade and get the message back for no good reason.  But I guess that's purely cosmetic, so meh.
[19:44] <jtaylor> Jelle_: you are probably missing the 32 bit linker
[19:44] <jtaylor> libc6-i386 I think
[19:45] <Jelle_> I've no idea what that could be.. :P I'm very new to linux actually
[19:45] <Jelle_> http://paste.ubuntu.com/8736982/  btw that is my output
[19:45] <jtaylor> Jelle_: try bash instead of sh
[19:46] <Jelle_> Nope didn't do the trick :/
[19:46] <Jelle_> looks like the same error
[19:47] <infinity> Which error are you referring to?
[19:47] <infinity> In your output, the only error is bashisms.
[19:47] <Jelle_> well the output link I just pasted
[19:48] <infinity> Right, using "sudo bash ./start-jira.sh" would fix the unexpected operator errors.
[19:48] <infinity> And I see no other errors.
[19:49] <infinity> Jelle_: Anyhow, this is very much not a support channel.  #ubuntu for Ubuntu support, or some Jira channel for Jira support would be much more appropriate.
[19:49] <Jelle_> Oh I'm sorry, I thought this would match devs
[19:50] <Jelle_> Couldn't find any jira support channel, excuse me!
[19:50] <sergiusens> Jelle_: only if it's for dev'ing ubuntu
[19:51] <Jelle_> i'm sorry :) good night!
[19:59] <Wellark> what super powers I need to be able to target bugs for ubuntu series?
[20:00] <Wellark> right now I can only nominate
[20:01] <Wellark> infinity: you probably know --^
[20:01] <ogra_> Wellark, #ubuntu-bugs does ...
[20:03] <Wellark> oh, we have such channel as well..
[20:04] <infinity> Wellark: There's a superpower team I can add you to if you make a solid argument for why you need to be in it.
[20:04] <infinity> Wellark: I'm heading out for lunch, so you have time to convince me while I'm gone. :P
[20:05] <Wellark> infinity: I'm upstream of i-network, unity-action-api and connectivity-api
[20:05] <Wellark> and would be easier for anyone if I get the powers to handle the targeting myself
[20:06] <Wellark> infinity: or other option is that I give you the list of multiple dozens of bugs and you can do the targeting for me ;)
[20:06] <Wellark> infinity: + there will be some other projects coming in during this cycle