[00:00] <robru> infinity: do you want the list of regressions that actually correspond with the gcc5 upload?
[00:00] <infinity> Since the way we give gcc-5 a pass is to tell britney to ignore all gcc-5 related tests.
[00:00] <infinity> Which I won't do until we're sure all the ones we care about are good.
[00:00] <robru> ah
[00:00] <infinity> (The other way is to ignore tests for specific packages, but that gives those regressions a pass, which we don't want)
[00:01] <infinity> Some of these might be flappy weirdness.
[00:01]  * infinity retries a few.
[00:02] <infinity> ... after I read pitti's mail about how to retry.
[00:02] <slangasek> is there a hand gesture to go with "flappy weirdness"?
[00:02] <infinity> slangasek: Imagine Kermit flailing.
[00:15] <tdaitx> doko, should we create a bug report for LP: #1483403 in Debian as well?
[01:52] <cyphermox> so, where should I start to help with gcc5? I have the pad open but I'm not quite sure where to begin
[02:33] <tdaitx> cyphermox, still looking where to help on gcc5?
[02:56] <tdaitx> cyphermox, anyway, the stuff at the bottom is more recent, so you can start there
[05:11] <tjaalton> I wonder if xcb-util could be dropped from NEW before we have a unwarranted diff against debian
[05:11] <tjaalton> an
[05:18] <RAOF> tjaalton: Pretty sure the answer is “yes, but I'm not meant to press that button”
[05:18] <tjaalton> riight
[05:18] <tjaalton> ok
[05:18] <tjaalton> I'll wait for a reply first..
[05:19] <tjaalton> from the uploader :)
[05:19] <tjaalton> before doing anything myself
[05:20] <tjaalton> the only thing being reverting the change from the debian branch
[05:33] <infinity> tjaalton: What diff do we not want?
[05:33] <tjaalton> infinity: renaming libxcb-util
[05:34] <tjaalton> well, pkg-xorg doesn't wan't the transition on debian, because it's pointless
[05:34] <infinity> tjaalton: It's not renamed because the SOVER changed?
[05:34] <tjaalton> the sover has been like that for ages
[05:34] <infinity> I mean, 0 -> 1 seems pretty clear.
[05:34] <tjaalton> hmm
[05:35] <tjaalton> or I'm completely wrong
[05:35]  * infinity looks at actual contents.
[05:35] <tjaalton> meh
[05:35] <infinity> Yeah, it really did bump SOVER.
[05:35]  * tjaalton woke up at 4am
[05:35] <infinity> Not renaming would be very wrong. :P
[05:37] <infinity> Hah.  That's something you don't see every day.  kwayland-integration was FTBFS on everything except arm64.
[08:30] <flexiondotorg> Laney, who can help promote deja-dup-caja out of the NEW queue for wily/
[08:30] <flexiondotorg> ?
[08:31] <Laney> ~ubuntu-archive
[08:38] <darkxst> Laney, how often do the packageset scripts run?
[08:38] <darkxst> (for seeded stuff)
[08:39] <Laney> manually, I run it once a week or so
[08:41] <darkxst> Laney, manually automatic ;) can you run it this week some time ? to pick up gnome-getting-started-docs
[08:42] <Laney> it means that the sets aren't managed by hand
[08:42] <Laney> will run it now if you want
[08:43] <darkxst> Laney, that would be good, images took a 120MB hit from seeding it
[08:45] <darkxst> though that in itself its not a huge problem, at this point, but want to be able test langpacks are getting installed correctly before B1 hits
[08:51] <Laney> need to fix this script to not rsync ALL the dists/wily-*
[09:00] <lamont> I want to get bcache-tools into trusty/precise...  I'm guessing that I probably did wrong in 1429857 and actually just want to upgrade 1449099 from wishlist? or progress it anyway...
[09:00] <lamont> what's the next step for me here, really, oh mighty release gods?
[09:27] <infinity> lamont: precise seems a bit much.
[09:28] <infinity> lamont: But if it builds cleanly on a straight backport, meh.
[09:28] <infinity> lamont: If so, then we just need SRUs of said backports from vivid (versioned as 1.0.7-1~14.04 and 1.0.7-1~12.04)
[09:29] <infinity> lamont: Given that the package didn't exist before, there's no regression chance, so the backport is not really problematic, but do put a test plan in the SRU bug for how you intend to validate that it's working on both releases.
[09:34] <lamont> infinity: lts kernel on precise... :(
[09:34] <lamont> infinity: ack
[09:34] <lamont> ta
[11:31] <tseliot> infinity: any updates on nvidia-352{-updates} ?
[14:21] <slangasek> sigh; jackd2 has a wrong symbols file (seemingly generated out of nowhere), so all the jackd2 rebuilds have to be redone
[14:24] <slangasek> oh, d-shlibs again.  thanks Jonas
[14:28] <slangasek> except... d-shlibs isn't used in the build either
[14:34] <slangasek> Laney: it looks like the go script has been updated again, considering some of the things dropping out of the list.  How confident are we that this is correct, before I start culling the list of in-progress transitions?
[14:37] <Laney> slangasek: Indeed, I deployed a new version --- moderately confident? :)
[14:37] <slangasek> heh
[14:37] <Laney> I fixed the problems I knew about and have verified some transitions today
[14:57] <slangasek> ok so no symbols file in libjack-jackd2-0v5 at all, just a shlibs file and the shlibs file looks correct.  Brilliant
[14:58] <Laney> Got an example of a bad package? Second pair of eyes might be helpful?
[14:59] <slangasek> Laney: every darn thing on http://people.canonical.com/~ubuntu-archive/transitions/html/jackd2-g++5.html
[14:59] <slangasek> I'm starting from the zynjacku end
[14:59] <slangasek> oh of course
[14:59] <slangasek> it pulled in libjack-dev instead of libjack-jackd2-dev at build time
[15:00] <slangasek> a) why do we still have two of those things, b) that obviously won't work if the ABI has changed so either there's no ABI transition or libjack is now bustificated
[15:01] <slangasek> doko: how did you determine that jackd needed an ABI transition?
[15:03] <doko> slangasek, https://people.debian.org/~doko/logs/gcc5-20150701/jackd2_1.9.10+20140719git3eb0ae6a~dfsg-2_unstable_gcc5.log
[15:28]  * Laney cries at the libbpp stack
[15:37] <slangasek> doko: ok so on jack.  jackd provides two libraries; libjack and libjacknet.  libjack has a C-only ABI.  the shlibs point to libjack-jackd2-0v5 (>= 1.9.5~dfsg-14) | libjack-0.116.  libjacknet has a C++ ABI; its shlibs also point to libjack-jackd2-0v5 (>= 1.9.5~dfsg-14) | libjack-0.116.  However, libjack-0.116 is a virtual package provided by both libjack-jackd2-0v5 and by libjack0, and libjack0 do
[15:37] <slangasek> esn't include libjacknet at all
[15:37] <slangasek> if nothing has noticed this, it's possible libjacknet is completely unused and we shouldn't do a package name change
[15:41] <Laney> Should we start to see stuff migrating once it's ready?
[15:41] <Laney> modulo gcc-5 itself
[15:41] <slangasek> Laney: probably small clusters only
[15:41] <Laney> in theory though
[15:41] <slangasek> yes
[15:42] <Laney> I like attacking things from the proposed-migration direction too
[15:42] <Laney> pick a package and drill down on it until it goes in
[15:42] <slangasek> doko: confirmed that libjacknet is an internal library only with no header files, it shouldn't even be part of the libjack package AFAICS but it certainly shouldn't have the shlibs it currently has.  I'll back out the transition
[15:42] <slangasek> Laney: yes, you should be able to do that soon
[15:42] <Laney> nod, thanks
[16:21] <cyphermox> doko: are you aware of some change in our gcc5 that would affect floating point precision on i386?
[16:22] <doko> cyphermox, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323  -> almost always bad code
[16:22] <cyphermox> figured that's what you'd link me ;)
[16:22] <doko> glad you found it on your own =)
[16:22] <cyphermox> hehe
[16:23] <cyphermox> doko: danke.
[16:24] <slangasek> I've seen some no-change rebuilds for boost today; is anyone working on systematically rebuilding for http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.58.html ?
[16:25] <doko> not me
[16:31] <flocculant> afternoon - could someone point balloons and I at what we need to report against for wily live sessions in Ubuntu and Xubuntu falling to login screen rather than starting the desktop
[16:32] <doko> slangasek, ocaml packages could need some attention (e.g. liblastfm-ocaml-dev not installable) who did those in the past?
[16:32] <slangasek> doko: I don't know
[16:33] <Laney> cjw I think did some
[16:33] <Laney> it's the same as haskell - rebuild them in level order
[16:49] <cyphermox> flocculant: I saw something like that related to compiz perhaps, but it depends
[16:49] <cyphermox> flocculant: wily daily for xubuntu and ubuntu?
[16:54] <flocculant> both
[16:55] <flocculant> cyphermox: so not compiz I would have to assume
[17:10] <cyphermox> flocculant: if both try to log in and fail, falling back to the login prompt, then something is broken
[17:10] <flocculant> cyphermox: want some logs?
[17:10] <cyphermox> I'd watch .xsession-errors carefully (or whatever gets written), to see where it breaks
[17:12] <cyphermox> flocculant: check .xsession-errors and the logs in .cache/upstart/, like gnome-session.log or unity7.log
[17:12] <cyphermox> I'll check in a bit
[17:39] <flocculant> cyphermox: logs http://pastebin.com/MnV18Csc
[17:58] <robru> anybody have any easy gcc5 stuff for a noob like me to poke at?
[18:03] <doko> robru, https://launchpad.net/ubuntu/+source/openvdb/3.0.0-3ubuntu3
[18:04] <robru> doko: thanks
[18:05] <doko> robru, there's also tbb ftbfs on arm64
[18:05] <doko> would suggest to contact debian and/or upstream
[18:05] <doko> or looking for patches upstream
[18:27] <robru> doko: I don't see any new versions for tbb or openvdb either upstream or in debian
[18:28] <robru> doko: do you want me to just file bugs in debian?
[18:28] <doko> robru, no, I meant upstream trunk
[18:29] <robru> doko: what? I went to the upstream homepages and they had nothing new?
[18:29] <doko> robru, ohh, np VCS?
[18:29] <robru> doko: not that I could see...
[18:29] <doko> robru, yes, debian forwards would be ok, but you probably can't reproduce on these architectures
[18:30] <doko> tbb and openvpn without VCS? can't believe that
[18:30] <robru> doko: well I didn't look into openvdb that closely but tbb was definitely just tarballs on a website. no VCS I could find
[18:32] <robru> doko: ah, openvdb does have a github
[18:40] <robru> doko: actually wait, https://launchpadlibrarian.net/214176471/buildlog_ubuntu-wily-arm64.tbb_4.3~20150611-1~exp3_BUILDING.txt.gz this just says "build killed after 150 minutes of inactivity", could that not be a transient issue? retry the build maybe?
[18:41] <doko> robru, could you check on the developer box first?
[18:41] <robru> doko: sure
[18:48] <robru> doko: ok, arm64 build started, apparently it takes 4 hours if successful though
[18:51] <robru> doko: also for openvpn, v3.0.0 has never built on powerpc. last successful powerpc build was 2.3.0-2
[19:36] <doko> slangasek, time to force gcc-5 and gcc-defaults to -release?
[19:36] <slangasek> doko: where did we get to with the analysis of the failures?
[19:36] <doko> see the pad. it's kde only, one ada issue, nothing important
[19:37] <slangasek> ok
[19:37] <slangasek> then yes, let's
[19:37] <doko> the ftbfs for main are fixed
[19:38] <slangasek> doko: hint added
[19:39] <infinity> slangasek: Oh, good, "force" didn't mean what I feared it did. :)
[19:39] <slangasek> infinity: acceleratin' that mass
[19:40] <infinity> slangasek: AKA, American sexy fun times?
[19:40] <slangasek> infinity: you have a dirty mind
[19:40] <infinity> slangasek: Little bit.
[19:44] <slangasek> doko, infinity: robru is looking at openvdb, which ftbfs on powerpc because it uses tbb which appears to be reinventing the wheel on atomics.  What's the right way to do atomics in C++?
[19:45] <infinity> slangasek: Lemme see the failure?
[19:45] <slangasek> infinity: https://launchpadlibrarian.net/214175949/buildlog_ubuntu-wily-powerpc.openvdb_3.0.0-3ubuntu3_BUILDING.txt.gz
[19:45] <infinity> slangasek: If it's *only* on ppc, they might be doing atomics correctly, but missing -latomic.
[19:45] <slangasek> "incomplete type" suggests otherwise
[19:46] <slangasek> /usr/include/tbb/atomic.h:220:34: error: 'tbb::internal::atomic_impl<T>::my_storage' has incomplete type
[19:48] <tdaitx> slangasek, infinity: this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787084
[19:48] <infinity> Yeahp.  With a patch, no less.
[19:48] <slangasek> oh hey
[19:49] <slangasek> "Here is a patch whic huse the gcc libatomic instead of [...]" there we go
[19:49] <slangasek> oh, except that the maintainer claims it's applied in experimental
[19:49] <slangasek> and that's the version we have synced, I think?
[19:50] <infinity> No.
[19:50] <infinity> We have unstable.
[19:50] <infinity> Oh, tbb.
[19:50] <slangasek>  tbb          | 4.3~20150611-1~exp3   | wily-proposed/universe | source
[19:50] <slangasek> yes
[19:50] <infinity> I'm looking at ... Yeah.
[19:50] <slangasek> oh, hangon
[19:50] <infinity> So, there may still be a missing -latomic on top of this.
[19:51] <slangasek> robru: what version of libtbb-dev was openvdb building /against/ ?
[19:51] <slangasek> infinity: it's not a linker error
[19:51] <infinity> Get:161 http://ftpmaster.internal/ubuntu/ wily-proposed/universe libtbb-dev powerpc 4.3~20150611-1~exp3 [208 kB]
[19:51] <infinity> From the build log.
[19:51] <slangasek> well phooey
[19:52] <robru> slangasek: yeah, that
[19:52] <robru> slangasek: I had that idea too, maybe it was an older version or something
[19:52] <robru> but no
[19:54] <infinity> Oh.
[19:55] <infinity> This was definitely applied... Differently.
[19:55] <slangasek> (said in a raiders of the lost ark voice)
[19:56] <infinity> Hrm.
[19:56] <slangasek> oops, no, not that movie the other one
[19:56] <infinity>     #if (TBB_USE_GCC_BUILTINS && __TBB_GCC_BUILTIN_ATOMICS_PRESENT)
[19:56] <infinity>         #include "machine/gcc_generic.h"
[19:56] <infinity> So, maybe that's not actually working.
[19:57] <slangasek> Last Crusade, that's what it's called
[19:57] <slangasek> so, gcc regression?
[19:58] <infinity> Ah-ha.
[19:58] <infinity> No, stupid patch.
[19:58] <infinity> See debian/patches/ppc32_atomics.patch
[19:58] <infinity> Which should be dropped.  And libtbb should just be linked with -latomic.
[19:59] <infinity> Maybe.
[20:00] <infinity> Yeah.
[20:00] <infinity> The atomic-rework patch explicitly fixes things to work with -latomic (ie: new style intrinsics), then the ppc patch disables it. :P
[20:01] <infinity> slangasek: Gimme a few minutes to play on a porter, and I'll have a fix on the way.
[20:01] <slangasek> hah
[20:01] <slangasek> infinity: or do you want to hand it off to robru?
[20:01] <robru> infinity: but wait though. the latest changelog specifically says "restoring this patch because it never should have been dropped"
[20:03] <infinity> robru: Yes, because his atomic-rework failed on ppc32 because he didn't link with -latomic, and he misread that as "oh, this doesn't work on ppc, then"
[20:03] <robru> infinity: alright, want me to make a debdiff with the patch dropped?
[20:04] <infinity> robru: If you want to figure out how to make it link correctly (and drop that patch) as learning exercise, go nuts.
[20:04] <infinity> robru: The linking bit is important, not just dropping the patch. :)
[20:04] <robru> oh, well
[20:04] <robru> slangasek: how hard is that? for somebody who's never written any C++ and would just be stabbing in the dark ^
[20:05] <slangasek> robru: library linkage is unrelated to writing C++
[20:05] <slangasek> so it should be a piece of cake ;)
[20:05] <slangasek> Good: .depends ~ /libassimp3v5/
[20:05] <slangasek> Bad: .depends ~ /libassimp3/
[20:06] <robru> slangasek: ok well I'm also completely unfamliar with library linkage.
[20:06] <slangasek> also bad: someone's regexp handling at 3 in the morning?
[20:06] <slangasek> robru: now's a great time to learn :)
[20:06] <robru> slangasek: ok can you point me at some documentation to get me started
[20:06] <robru> ?
[20:07] <infinity> Documentation won't help you here, these are custom Makefiles, not something pleasant(?) like autoconf.
[20:07] <slangasek> robru: 1) drop the patch that's identified as bad 2) test-build on powerpc 3) see where it's failing to build because underlinked 4) fix the necessary makefile
[20:08] <doko> slangasek, gcc-5 in -release, plus 7 libs
[20:08] <doko> \o/
[20:08] <slangasek> and so it begins
[20:08] <robru> infinity: autoconf? pleasant? uh-huh.
[20:09] <doko> wondering if we can force boost1.58 and icu as well
[20:10] <robru> doko: so the tbb rebuild on arm64 is stuck in the same spot, darn
[20:10] <infinity> robru: Just adding -latomic to LIBS in build/linux.gcc.inc will probably do the trick.  Maybe.
[20:11] <robru> infinity: thanks
[20:11] <infinity> robru: If you have access to the ppc porter, that will help a bit.
[20:11] <slangasek> doko: I think we want to wait and see what p-m returns for those libraries
[20:11] <doko> sure
[20:11] <robru> infinity: yeah, just looking now
[20:11] <doko> but boost1.58 is all new, and icu changed the soname, so the old lib isn't removed
[20:12] <infinity> robru: Not that that was much of a learning exercise, since I can't leave well enough alone, but I got there by backtracking from the Makefile generating the library through to the Makefiles in build/ and then to the include bits.
[20:12] <robru> k
[20:12] <slangasek> doko: yes; but if that was all there was, p-m should have figured it out already on its own so I want to see why it refused before we use a hammer
[20:12] <infinity> robru: All untested.  So please test a full build with testsuite.
[20:13] <infinity> robru: And then if you fix it, forward to Debian with a "well, actually..." explanation.
[20:13] <robru> infinity: yep, just firing it up now
[20:13] <slangasek> hmm, only 7 libraries? I just got 38 wily install notification mails
[20:14]  * infinity goes to fix North Korea.
[20:14] <slangasek> infinity: now for that, you'll want a hammer
[20:14] <slangasek> cyphermox: ignition-math2, I just noticed was never built on i386 so not a regression; did you see the same?
[20:15] <infinity> slangasek: Or just a tzdata update.  That'll fix ALL their problems, right?
[20:15] <cyphermox> slangasek: I had not noticed
[20:15] <cyphermox> slangasek: in any case, I'm sending a patch to debian now
[20:15] <slangasek> infinity: as long as their clocks match the reality and declare that they're in the stone age, all is good
[20:15] <cyphermox> it's not perfect, but it allows it to build on i386
[20:15] <slangasek> cyphermox: ok.  taking it off the pad anyway
[20:16] <infinity> slangasek: Setting all their clocks back to 1950 would be a great idea.  I wonder if we're popular enough there to cause an international incident.
[20:17] <doko> slangasek, where do you get these emails? I only get those for my own uploads
[20:18] <slangasek> doko: who do you think uploaded the libraries
[20:18] <slangasek> :P
[20:18] <doko> heh
[20:18] <slangasek> and 38 was just the first batch, p-m appears to still be running
[20:20] <infinity> ... and firefox has developed an -latomic issue suddenly too.
[20:20] <infinity> Weird.
[20:20] <robru> doko: oh, actually, so there was a pause but tbb build succeded on arm64. not sure if you want to retry the arm64 build or just wait for the new upload that fixes powerpc anyway
[20:25] <doko> robru, given back. please check tomorrow
[20:25] <robru> doko: thanks
[20:32] <doko> infinity, could you update the buildd images? get gcc-4.9 removed, and 5 wouldn't need updates, speeding up the builds a bit
[20:33] <infinity> doko: Yup, I was waiting for it to migrate before I mangled them.
[20:34] <infinity> doko: Are you happy (enough) with this version of GCC until the transition is done?
[20:34] <infinity> I mean, barring critical bugs you didn't know about, of course.
[20:34] <infinity> Cause not updating it until post-transition would be a big help for speed.
[20:34] <doko> yes, at least we didn't find any GCC issue, after the transition started
[20:34] <infinity> Alright, I'll do some refreshes shortly here.
[20:37] <infinity> robru: I'm guessing from this slow build that no one ever taught you about export DEB_BUILD_OPTIONS="parallel=$(nproc)"
[20:49] <infinity> robru: Shiny, looks like that worked.  Score one for me for (educated-)random sed?
[20:50] <robru> infinity: yeah lots of stuff nobody ever told me about ;-)
[20:50] <robru> was also eating lunch
[20:50] <robru> infinity: ok, want the debdiff? or did you grab it since you're snooping in my home dir anyway? ;-)
[20:51] <infinity> robru: Well, depends on who wants credit for the upload and who's forwarding the fix to Debian. ;)
[20:51] <robru> infinity: seeing as I have no upload rights...
[20:51] <infinity> robru: Though, for paranoia's sake, I think I'll stage it in my devirt PPA and try rebuilding whatsit against it first.
[20:51] <robru> infinity: fair enough
[20:51] <infinity> WHatever whatsit was.  I already forgot.
[20:51] <infinity> open... something.
[20:51] <robru> infinity: openvdb
[20:52] <robru> infinity: anyway, tbb.debdiff is there for you
[20:52] <infinity> robru: Sure.  If I was sponsoring this for you (and I can, if you want credit), I'd ask you to flesh out the headers on that patch to explain it a bit better.
[20:53] <robru> infinity: I'm not particularly bothered about credit for something that you directly told me to do that I didn't really understand.
[20:53] <infinity> "Since gcc-4.9, the atomic intrinsics on some architectures (like powerpc) are split off into -latomic, so always attempt to link it."
[20:54] <infinity> robru: Hah.  Well, maybe you undestand it a bit better with my above edit. :)
[20:54] <infinity> robru: I'll take this one from here, though, thanks for the test run.
[20:54] <robru> infinity: thanks for the instructions ;-)
[21:07] <slangasek> doko: update_output is updated, and shows that icu has tentacles into a lot of other stuff; doesn't look like the old and new are coinstallable
[21:08] <doko> well, the library is, probably not the -dev package
[21:08] <slangasek> the -dev package isn't causing 11000 binary packages to be uninstallable
[21:09] <slangasek> infinity: can you refresh my memory on what's expected to happen here?  Should p-m calculate installability assuming the NBS binaries stick around?
[21:09] <infinity> robru: Also, your debdiff missed running "update-maintainer"
[21:10] <infinity> slangasek: It calculates assuming they're removed.
[21:10] <robru> infinity: probably because I don't know what that is
[21:10] <infinity> robru: It needs running whenever we introduce a delta on top of Debian.
[21:11] <robru> infinity: k, thanks
[21:13] <doko> first nbs removals ...
[21:17] <infinity> robru: And found another bug while I was in there.  Whee.
[21:18] <robru> infinity: good thing you're on it then
[21:20] <slangasek> infinity: so; if it assumes the NBS removals, there's no way to get p-m to show us the results of a partial upgrade?
[21:20] <slangasek> (like it does in Debian these days)
[21:25] <robru> NBS?
[21:25] <doko> not built from source (anymore)
[21:28] <infinity> slangasek: I'm not entirely sure what you mean by "show results of a partial upgrade".
[21:29] <infinity> slangasek: But, indeed, our britney carries a patch to do things the inverse of how Debian does them, because we're dealing with a partial suite, and they have a full suite.
[21:30] <slangasek> infinity: doko has requested, and it makes sense, to have icu transition into wily and unblock a bunch of stuff because it *should* be a soft migration - the old library binary should be coinstallable
[21:30] <slangasek> infinity: er, I don't see why partial suiteness implies forcing hard transitions
[21:30] <slangasek> that is, forcing transitions to be hard
[21:30] <infinity> slangasek: So they require NBS removal in sid before something can migrate, which gives them a wholistic view, we have to pretend to do NBS removal in "testing" to get a similar consistent view.
[21:31] <slangasek> hmm
[21:31] <slangasek> right, so it's because we don't have the old binary packages in the partial suite, so can't just look at -proposed to decide whether a package is ready to migrate
[21:31] <infinity> Is it desperately difficult to just finish the icu transition?
[21:32] <slangasek> infinity: 11,000 binary packages
[21:32] <slangasek> the icu transition underlies half the other C++ libraries in the archive
[21:32] <infinity> Ahh, a drop in the bucket!
[21:32] <infinity> Yeah, icu is always large, I've done it before.
[21:32] <infinity> Though, it's rarely problematic on its own.
[21:32] <infinity> Tied up with a new g++, though.  Ick.
[21:33] <slangasek> so if we tried to force icu in via p-m, it would remove libicu42 from wily?
[21:33] <infinity> slangasek: So, if we're sure it's not problematic on its own, we can force icu through the pipe manually.
[21:33] <infinity> slangasek: No, it won't *actually* remove it.  britney does no removals.  The inst checker just *pretends* it's removing it.
[21:34] <slangasek> infinity: I checked, libicu52 and libicu55 are coinstallable (at least on amd64, should be same for all archs)
[21:34] <infinity> slangasek: So, if we're sure it's good, we can manually copy it, and let it unwind itself on the next run.
[21:34] <slangasek> infinity: ok, I think we ought to. can you poke that in this afternoon?
[21:34] <infinity> I can.
[21:35] <slangasek> ta
[21:36] <infinity> It does mean that list of broken packages migrates from update_output to the NBS report instead, but as long as there's a commitment to follow up sooner rather than later, I don't think it's an actual problem.
[21:36] <infinity> Oh.
[21:36] <infinity> It might also make the uninstall count go up?
[21:36] <infinity> Depends on how stupid britney is.
[21:36] <infinity> Hopefully stupid enough that it doesn't.
[21:37] <infinity> If it counts NBS binaries in testing as still being available, we're fine.
[21:37] <infinity> If not, we'll break the whole world.
[21:39] <infinity> Perhaps I'll copy it and do a no-commit britney run afterward to make sure the world didn't explode.
[21:39] <infinity> But I think it's sufficiently unclever enough to not break.
[23:17] <robru> how do you tell if something is a regression on an arch vs if something was never supported on that arch?
[23:31] <infinity> robru: rmadison, see if binaries exist on the arch in question.
[23:31] <infinity> robru: Or check the previous version on LP for successful/failed builds.
[23:32] <infinity> Holy crap on a stick, tbb takes forever to build on arm64.
[23:32] <robru> infinity: so if the latest version in the release pocket is failed, that's authoritative that the arch isn't supported?
[23:32] <infinity> I wonder what's up with that.
[23:32] <infinity> robru: Well, it's authoritative that it's not a regression against the release pocket. :P
[23:32] <robru> heh
[23:33] <infinity> robru: When I'm touching a package for unrelated reasons, I tend to look at the arch FTBFSes anyway to see if it's trivial to fix in passing.
[23:33] <infinity> robru: But if it's not trivial, as long as it's not a regression, the status quo is fine.
[23:33] <robru> infinity: just curious about this pymia/mia thing mentioned on the pad. it suggests to rebuild mia against vtk5 on armhf except as far as i can tell armhf was never supported so I have no idea why this is blocking anything
[23:33] <infinity> robru: Where is this magic pad people are working from?  I'm out of touch with the transition so far.
[23:34] <robru> infinity: http://pad.ubuntu.com/gcc-5-transition has a bunch of TODOs, I'm finding it hard to follow though
[23:35] <infinity> robru: Right, I see no pymia/mia on armhf at all, in any release, so that line can likely be deleted.
[23:36] <robru> infinity: well I started a build with the suggested change, maybe let's see how it turns out first ;-)
[23:37] <infinity> robru: Having it have different deps on different arches sounds like more trouble than it's worth, IMO.
[23:39] <infinity> robru: And the fact that it's never built in the past makes it a bit of a "who cares".  If we leave it as-is, it'll magically work if/when someone fixes vtk6.
[23:39] <robru> fair point
[23:39] <robru> I don't  know who put it on the list in the first place
[23:39] <infinity> Probably someone who just looked at the missing build without checking history.
[23:40] <infinity> Oh.  And vtk6 on armhf is the usual Glfloat/GLdouble GL/GLES madness.
[23:40] <infinity> That's fixable, if anyone cares.
[23:41] <slangasek> yes, please don't make something like mia build-depend vtk5 on armhf
[23:41] <slangasek> I also don't know why it ended up on the pad; someone must've been working from their build-failure email notifications as a todo list, instead of the trackers
[23:42] <infinity> Are we not yet at a point where we have a new enough OpenGL that we can just use GLES everywhere as a pure subset of GL and stop this insanity with different standards on different arches?
[23:42] <slangasek> not sure what you mean by that
[23:43] <infinity> slangasek: So, the reason one used to have to choose A or B was that GLES was, annoyingly, not a pure subset of GL.  It was mostly a subset, but also included some features GL didn't have.
[23:43] <slangasek> I thought the library entry points, not to mention the OpenGL runtime "whoami?" insanity, were different between the two
[23:43] <infinity> slangasek: Newer versions of the GL/GLES standard have GLES as a pure subset (or GL as a pure superset, however you want to look at it), so one can, in theory, write all their stuff to target GLES, and make it work on both.
[23:43] <infinity> slangasek: But, yes, that probably still needs fixing in mesa with a hybrid loader or something to fix the final step, now that the standard makes it possible.
[23:44] <slangasek> right, so that doesn't really help if you're using things like libGLU
[23:44] <slangasek> I guess in theory you just have everything building against GL headers, and if it's smart it only uses a subset and then you're happy?
[23:45] <slangasek> but currently the compiler is what you use to enforce the subsetness
[23:45] <infinity> Right.
[23:45] <infinity> Oh well.  Maybe next decade.
[23:45] <infinity> Our (correct) choice to make ARM GLES in Ubuntu (deviating from Debian) has been no end of pain, though.


[18:51] <harlowja> smoser shall we make a tag/branch for 0.7.x on https://github.com/stackforge/cloud-init ?
[18:51] <harlowja> now that i see it has the full history there :-P
[18:51] <harlowja> didn't know it had that, ha
[18:52] <harlowja> i guess the last bzr move-over is https://github.com/stackforge/cloud-init/commit/d90bfd6268e8 ?
[18:53] <harlowja> and then i guess stop accepting bzr changes, ha
[18:54] <smoser> harlowja, hm..
[18:54] <harlowja> and/or create a 0.7.x branch from that commit; update it
[18:54] <harlowja> and have master be 2.x
[18:54] <smoser> i think keep 0.7.x on bzr
[18:55] <harlowja> seems like its on stackforge though :-P
[18:55] <smoser> what do you mean ?
[18:55] <harlowja> https://github.com/stackforge/cloud-init 2678 commits, ha
[18:55] <harlowja> so there is some history there :-P
[18:55] <harlowja> afaik nobody has done that many commits yet, lol
[18:55] <harlowja> so seems useful to have some kind of branch at least
[18:56] <harlowja> also then removes the need for https://github.com/number5/cloud-init
[18:56] <harlowja> ^ which is doing similar mirroring...
[18:56] <harlowja> ^ whoever that is...
[18:56] <smoser> hm..
[18:57] <smoser> well, i basically consider 0.7.x in maintenance
[18:57] <smoser> and figure just as well to do that in bzr on launcpad.
[18:57] <smoser> but id ont know.
[18:57] <smoser> yeah, i think keep it there for now.
[18:57] <harlowja> ok, i'd make it easier for yahoo, but sureeee, since we wanted to mirror bzr -> internal git
[18:57] <harlowja> makes it real easy if stackforge already does it :-P
[18:58] <smoser> :)
[18:58] <harlowja> sooo how about that :-P
[18:58] <smoser> well, i'm not really opposed to it i guess.
[18:59] <harlowja> i can push up a branch for the current 0.7.x on git (which seems to be from revision 1046 from bzr)
[18:59] <smoser> do we know of anythign that can mirror for us ? so that github.com/cloud-init/cloud-init is a mirror of stckforge/cloud-init ?
[18:59] <harlowja> and get someone to update that branch
[18:59] <harlowja> unsre
[18:59] <harlowja> poke #openstack-infra folks?
[18:59] <harlowja> i would think they would know something (some tool or other)
[19:00] <harlowja> so i'll push up 0.7.x branch on stackforge
[19:00] <harlowja> ok dokie?
[19:01] <smoser> so you'll push 0.7.x branch to stackforge... how do you do that ?
[19:01] <harlowja> magic
[19:01] <harlowja> lol
[19:01] <smoser> that wont force review ?
[19:01] <harlowja> clone the stackforge repo
[19:01] <harlowja> nope, no reviews for this
[19:02] <harlowja> $ git checkout d90bfd6268e8
[19:02] <harlowja> $ git checkout -b 0.7.x
[19:02] <harlowja> $ git push gerrit 0.7.x:0.7.x
[19:02] <harlowja> ^ is the sequence
[19:03] <harlowja> arg, didn't work
[19:03] <harlowja> ha
[19:04] <smoser> hnm.
[19:04] <smoser> well punt for now
[19:04] <smoser> but if we wanted, i think we can make bzr (on launchpad) be a mirror of github easily enough
[19:04] <smoser> launchpad supports that
[19:04] <smoser> harlowja, so please confirm... python in rhel 6 is 2.6 ?
[19:05] <smoser> if thats the case, i think it kind of forces 2.6 for cloud-init 2
[19:06] <harlowja> yup
[19:06] <harlowja> that is the case
[19:06] <harlowja> stupid rhel6
[19:06] <harlowja> lol
[19:07] <smoser> ok. so 2.6 requirement for cloud-init 2. :-(
[19:10] <harlowja> boo
[19:10] <harlowja> lol
[19:10] <harlowja> ya
[19:10] <harlowja> not that hard, just pita, lol
[19:19] <harlowja> guess i need https://review.openstack.org/#/c/172179/ to go in before branches can be made...
[19:19] <harlowja> arg
[19:23] <harlowja> guess we'll need that anyway so might as well get the ACLs over with...
[19:34] <smoser> claudiupopa, if i wanted to write what versions of windows we'll support
[19:34] <smoser> what would i write ?
[19:35] <smoser> harlowja, can you make the above not refs/heads/stble/*
[19:35] <smoser> but refs/heads/0.7.X ?
[19:35] <smoser> or somethign to that affect.
[19:35] <smoser> ie, at the point when there is sstable 2.0.0, we dont want you going out of control
[19:35] <harlowja> i think so
[19:36] <harlowja> updated; let's see if people are ok with that
[19:37] <harlowja> ha
[19:37] <harlowja> u go out of control first, not me, ha
[19:37] <smoser> whats the yum equivalent of 'apt-get update'
[19:37] <smoser> ie, not upgrade
[19:37] <harlowja> hmmm, forgot, thought it did the scanning automatically or something
[19:38] <harlowja> yum clean && yum list (?)
[19:38] <harlowja> i think that has similar effect
[19:39] <smoser> makecache
[19:39] <smoser> i think
[19:39] <harlowja> could be
[19:39] <smoser> how do i get python3?
[19:42] <harlowja> in rhel6?
[19:42] <harlowja> u don't, ha
[19:42] <harlowja> :-P
[19:42] <harlowja> u compile it, lol
[19:43] <harlowja> then make altinstall or whatever
[19:43] <claudiupopa> smoser: we currently support windows 2003+ upwards, but it will be EOL after 17 june (if I remember correctly). So starting from vista should be fair to document.
[19:43] <harlowja> XP ftw!
[19:43] <harlowja> lol
[19:44] <claudiupopa> ;-) a decent os nevertheless.
[19:44] <harlowja> def, my mom still runs it afaik
[19:44] <harlowja> ha
[19:44] <harlowja> guess i should fix that someday, lol
[19:48] <smoser> claudiupopa, for the windows novice (i've just heard about this cool thing from seatle) what is that list ?
[19:49] <smoser> ie, i dont knwo windows server names othe rthan the ones you have just told me about above :)
[19:49] <claudiupopa> one moment. ;-)
[19:50] <claudiupopa> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%29.aspx
[19:50] <claudiupopa> Everything starting with Vista.
[19:50] <claudiupopa> from Vista*
[19:57] <harlowja> forgot all the 9x versions.... jeez
[19:57] <harlowja> lol
[19:57] <harlowja> or millenuim (the best version ever)
[19:59] <smoser> claudiupopa, thanks.
[20:00]  * smoser saw windows 8.X for the first time this weekend on sisters new laptop
[20:00] <harlowja> http://en.wikipedia.org/wiki/Windows_ME  was the best version ever ;-P
[20:00] <harlowja> lol
[20:01] <smoser> now i've used it for 3 minutes. uninstalled the antivirus software (norton or something) that was on there, and set windows defender instead.
[20:01] <harlowja> last of the weird crappy windows versions, ha
[20:01] <harlowja> ya, remove the crapware if the first thing i usually do, lol
[20:01] <harlowja> *is the first
[20:03] <smoser> oh, you'd have liked this, harlowja
[20:03] <smoser> my sister was using yahoo to search for videos (youtube).
[20:03] <harlowja> man, thats weird, ha
[20:03] <smoser> i made a comment about not knowing i'd stepped into a time warp and being thrown back to 2002
[20:04] <harlowja> :)
[20:04] <harlowja> whattttt
[20:04] <harlowja> haha
[20:04] <smoser> i guess yahoo paid HP some money (or someone some money) to make it the default search engine in IE there.
[20:04]  * harlowja can no longer associate with smoser
[20:04] <harlowja> nice, ha
[20:06] <harlowja> well thx for supporting me smoser
[20:07] <harlowja> every click u do i get 1 piece of rice
[20:07] <harlowja> so thx!
[20:07] <smoser> hoohoo.
[20:07]  * harlowja has to feed all my kids...
[20:07] <harlowja> who would otherwise starve...
[20:13] <smoser> wow: http://www.ec2instances.info/
[20:13]  * smoser remembers the days of m1.small, m1.large and m1.xlarge
[20:20] <harlowja> ha
[20:20] <harlowja> ya
[20:20] <harlowja> crazy amount of choices there
[20:20] <harlowja> to many...
[20:21] <harlowja> way to many...
[20:21] <harlowja> ^ is not what the cloud is supposed to be, lol
[20:21] <harlowja> (for my version of cloud, ha)
[21:38] <bodik> hi
[21:39] <bodik> in our new version deployed by cloudguys at our grid site, they introduced a power_state: mode: reboot, which should reboot the machine at the end of the cloudinit work
[21:39] <bodik> but at that time runcmd and bootcmds are already executed, nebula is reporting vm as running
[21:40] <bodik> so i wonder how should i detect that vm is really ready after final reboot ? so i can start to really use the machine ?
[21:40] <bodik> anyone has some trick beside sleep X to do it ?
[21:51] <harlowja> use /var/lib/cloud/data/status.json
[21:51] <harlowja> and examine that
[21:51] <harlowja> ex http://paste.ubuntu.com/10786345/
[21:53] <bodik> great thanx
[21:53] <bodik> meanwhile i'm trying to use write_files to modify rc.local which is executed after the final reboot ;)
[21:54] <bodik> but it that would not work i will try the status file
[21:54] <bodik> thnakx
[22:21] <bodik> write_files does not work ;( rc.local is still executed after cloudinit but before reboot so the file is there too soon


[14:44] <vir17> how can I install snapcraft 1 instead from the current version?
[15:05] <faddat> I s there are recommended/standard way to do snappy by pxe?  I did see the mailing list bi5t
[15:05] <faddat> but curious if anything has evloved since then
[15:06] <faddat> also-- docker 1.6.0 in xenial is very weak sauce
[21:51] <vir17> guys I try to install the webchat example and I get this error: webchat_0.0.1_armhf.snap failed to install: open /tmp/read-file224232084/unpack/meta/package.yaml: no such file or directory


[00:00] <wolter> not literally
[00:01] <wolter> now that you provide me with such query, I see some useful results appear enlisted.
[00:02] <wolter> well troy_s, not really
[00:03] <wolter> I saw GEmblemedIcon, but that is for programming uses only, as far as I understood
[00:12] <wolter> so troy_s, is it possible?
[01:27] <troy_s> wolter: Judging from the pages I have read, and the bug report... https://bugs.launchpad.net/humanity/+bug/455879
[01:28] <troy_s> wolter: My best guess is that the answer is no.
[01:28] <wolter> Oh, too bad, thank you anyway.
[10:15]  * thorwil giggles
[10:15] <thorwil> http://www.underconsideration.com/brandnew/archives/microsoft_office_version_bland0.php
[10:49] <thorwil> seems the manual issue inspired Troy to write about spec work / contests: http://troy-sobotka.blogspot.com/2010/01/specs-and-contests-we-all-lose.html
[21:00] <thorwil> a must for everyone doing presentations with a beamer: http://www.slideshare.net/thecroaker/death-by-powerpoint


[01:04] <naxil> dream?
[01:04] <naxil> anyone is here?
[01:04] <unheeding> no
[01:09] <naxil> unheeding.. i have a problem.. i need to set my wifi internal card to hotspot
[01:09] <naxil> can u helpme?
[01:09] <naxil> i have xubuntu12.10
[01:09] <unheeding> i can't sorry
[01:10] <naxil> ok
[01:12] <naxil> unheeding, u know where is Propietary driver on xubuntu?
[01:36] <Unit193> naxil: Software Sources, last tab.
[01:52] <naxil> Unit193, i need to turn my wifi internal card to master/hotspot
[01:52] <naxil> is atheros card and teh driver is ath5
[01:53] <naxil> how to do it?
[01:59] <Unit193> !atheros
[02:08] <naxil> tnx bye
[02:37] <Cigam> hey there djtf
[04:37] <c2tarun> hi friends, tab is not working for commands in my xubuntu terminal. Though its working for location/paths.
[05:59] <c2tarun> hi friends, tab is not working for commands in my xubuntu terminal. Though its working for location/paths.
[06:05] <holstein> http://forums.bodhilinux.com/index.php?/topic/1150-terminal-tab-completion-missing-solved/
[06:07] <c2tarun> holstein, I am also facing one more problem, I am not seeing any color schemes in xubuntu terminal. In ubuntu/kubuntu all the executable files are displayed with green, folders with blue, but there is nothing like that here.
[06:09] <c2tarun> can anyone please suggest me a good or better terminal emulator for xubuntu?
[06:14] <nikolam> c2tarun, you don't like the default one, Terminal ?
[06:15] <c2tarun> nikolam, actually I just found out the problem :( I mounted my other partition over /home and that is why .bashrc is missing which is causing all the troubles
[06:15] <c2tarun> I just need a way to bring bashrc back. Is there anyway of copying the file without unmounting home?
[06:16] <nikolam> c2tarun, wel mount the other one to /tmp and copy it
[06:16] <Unit193> Copy from /etc/skel/.bashrc
[06:16] <c2tarun> Unit193, I checked .bashrc is not there as well
[06:17] <c2tarun> ohh sorry that must be hidden :P Its so stupid
[06:17] <c2tarun> Unit193, great thanks :)
[06:18] <Unit193> Sure thing.
[06:18] <nikolam> Or having another user with sudo privileges handy and log in using consoles (ctrl alt f2)
[06:19] <c2tarun> nikolam, thanks for help :) I found .bashrc in /etc/skel
[11:02] <Zoraktar> I'm having worst luck of getting some ubuntu help... I have tried almost all forums links about Non-pae linux and still not getting any... Last downloaded were Xubuntu 12.04.1 what i was told is for Non-Pae computers... Any suggestions?
[11:03] <Zoraktar> Computer is Hp Compaq nx6110 and it's not having PAE support. At least installer tells me that.
[11:05] <ochosi> hm, strange, 12.04 should support non-pae
[11:05] <ochosi> personally i don't have any non-pae supporting pcs, so i don't have any experience with this
[11:05] <ochosi> have you tried the alternate installer?
[11:07] <Zoraktar> Hmm i'm not pretty sure. I been trying with CD and with USB installer atm but seems it does not just want to try even from USB anymore.
[11:09] <knome> 12.04 has non-pae
[11:09] <ochosi> (knome is my parrot-friend :))
[11:09]  * knome dances the parrot dance
[11:10] <ochosi> this isn't a very lively dance – this parrot is dead!
[11:10] <Zoraktar> Heh. Yeah but still when trying to boot it comes error about Pae. No OS installed and only USB device in with universal USB installer but still getting that error.
[11:10] <knome> ochosi, har har... :))
[11:11] <ochosi> Zoraktar: yes, but as i said, it might be that you need to use the alternate, not the desktop image for that (i'm guessing a bit here though)
[11:11] <Zoraktar> Okies. What to do then?
[11:12] <ochosi> dl the alternate image, create a usb-stick with that and see whether the installation works
[11:13] <Zoraktar> Okies. Trying that. Btw what you think about using Xubuntu at school computers? Is there some law issues or could this just be installed? School is poor and computers cant run even XP well. They asked me about different OS systems what can go net and got some office clone :)
[11:13] <ochosi> yeah, no problem
[11:14] <ochosi> it's quite nice for that imo
[11:14] <Zoraktar> Yeah that's why tryng it. Found 500Mhz laptop with 512mb ram inside. XP were so slow that i werent able to listen music well with that machine.
[11:15] <ochosi> if the performance of xubuntu isn't satisfactory, you can as well try lubuntu, it's supposedly a bit lighter on resources
[11:15] <ochosi> or you can cut down certain things in xubuntu (mostly things that make your life easier though) and get a really light desktop
[11:16] <Zoraktar> Yeah well it needs to have kinda these stuff inside: Flash support, Java support, Shockwave support (as web-browsing only) and Wireless + Printer installing support.
[11:16] <Zoraktar> Ah and ofc some text program what allows you print and make some almost "offical" papers.
[11:19] <ochosi> yeah well, flash is a performance problem on all platforms...
[11:19] <baizon> html5 is a better solution
[11:21] <Zoraktar> What kinda problem? Because this would come only for like stuff like android got nothing like really heavy flash games. Tough could keep as "office" computer that too.
[11:22] <ochosi> it's simply that flash consumes a lot of cpu power, so if you don't have a lot of that, that can cause problems
[11:31] <Zoraktar> Alternative install downloaded. I have only USB stick atm to use. Do i burn image with Power-iso to bootable or do i use universal USB installer?
[11:33] <Yotson> unetbootin +1 ;)
[15:17] <c2tarun> my system is not remembering my brightness settings. How can I do that?
[15:43] <wonderworld> hi, since 12.10 i hve problems with running KDE-apps under xubuntu. after start the window sometimes shows and sometimes doesnt. the process is running but the application window fails to spwan. this happens with kaffeine, k3b, yakuake, konversation, etc
[15:46] <GridCube> havent heard of this before, let me do some research
[15:46] <wonderworld> i can't really reproduce it. it just works sometimes
[15:46] <wonderworld> i'd say i can run run KDE-apps about 3 times out of 10 tries
[15:47] <wonderworld> with 12.04 and before it always worked without any problems at all
[15:49] <GridCube> wonderworld, try launching from a terminal and see if you get a warning like this: QGtkstyle was unable to detect the current GTK+ theme
[15:50] <wonderworld> nope, i dont. I am getting this:
[15:50] <wonderworld> QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
[15:50] <wonderworld> QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
[15:50] <wonderworld> but i am getting this no matter if it wokrs or not
[15:52] <GridCube> mmhm, try a few times till you get one that doesnt work
[15:52] <wonderworld> ok, let me try
[15:55] <wonderworld> haha testing effect
[15:55] <wonderworld> works now. strange
[15:55] <GridCube> XD
[15:55] <wonderworld> maybe i need to reboot first. i think something is not properly initialized
[15:55] <GridCube> well
[15:55] <wonderworld> and some app does it, if i successfully start it
[15:58] <GridCube> wonderworld, maybe this will point you to where to look at: https://bugzilla.redhat.com/show_bug.cgi?id=702493
[15:59] <wonderworld> hey, thanks a lot, i'll have a look.
[15:59] <wonderworld> can't reboot right now, i'll try later
[15:59] <wonderworld> thanks for being helpful :)
[15:59] <GridCube> wonderworld, i would also suggest you to report this bug anyway once you have found some clues
[16:00] <wonderworld> yes i will
[16:00] <GridCube> :) also this might help aswel: https://bbs.archlinux.org/viewtopic.php?pid=940213
[16:07] <wonderworld> ok, i guess it's neither of the two bugs. *if* the app starts, it works just fine. themed and with icons
[16:07] <wonderworld> i'll reboot now. be back in a minute...
[16:11] <wonderworld> ok back
[16:11] <wonderworld> very strange. it seems to work now.
[16:11] <wonderworld> it didn't 2 days ago
[16:11] <wonderworld> maybe some update fixed it
[16:12] <wonderworld> sorry for wasting your time
[16:22] <Ammar> Hi, can anybody tell me where to find the difference between *ubuntu-distros ? I mean a real comperance, I am a developer coming from windows, and I am already fed up with it, and want to change...
[16:23] <Ammar> I am totally in Linux since almost 1 year, but was just working with Server-versions, so I know the meaning of so many things, but still need help...
[16:24] <bpuzzled> Ammar: essentially it comes down to what packages are pre-installed.
[16:24] <bpuzzled> Ammar: and that depends on their target audience.
[16:25] <Ammar> I am student of software engineer, but working also as Android Developer, and have experience in that, so which one would suite me ?
[16:25] <Ammar> I have searched online of course, and only found non-detailed compare
[16:26] <bpuzzled> again, ultimately they're all the same -- just have different preinstalled software.  xubuntu is a fine choice.  it just comes down to preference.
[16:26] <wonderworld> Ammar: basicly they are all the same with slightly different preinstalled software
[16:26] <GridCube> wonderworld, :) thats nice to hear, maybe something else was off, keep your eyes open :D
[16:27] <wonderworld> you can install all the software afterwards, so it's no big deal
[16:27] <Ammar> ah, this is the answer I wanted, Thanks @wonderworld :)
[16:27] <wonderworld> main difference is the preinstalled GUI
[16:27] <wonderworld> just watch some youtube videos and see which gui suits your needs mostly
[16:27] <GridCube> Ammar, all the *buntu are actually just "desktops" for the mainbuntu
[16:28] <wonderworld> most popular guis are: unity, KDE, MATE, XFCE, GNOME3
[16:28] <GridCube> mainbuntu uses the Unity Desktop, xubuntu the xfce desktop, kubuntu kde and lubuntu lxde
[16:28] <Ammar> Is there any resources where I can find out more about this "mainbuntu" ?
[16:28] <Ammar> @worlderworld: those are desktops, I know that, but are this the only difference between them ? I understand : yes
[16:29] <wonderworld> yes, and different preinstalled software. like KDE has another IRC client then Gnome3
[16:29] <Ammar> @DridCube thanks, I have already read that somewhere,,, but just wondering if this was the only difference
[16:29] <wonderworld> but you can install all the software afterwards
[16:30] <Ammar> ok, and can anybody tell me how to start development for "those Desktops" ? I mean apps for the desktops
[16:30] <GridCube> !tab | Ammar
[16:31] <Ammar> GridCube: thanks :)
[16:31] <GridCube> Ammar, :) if you do that that way people will get highlighted and you dont need the @
[16:32] <Ammar> GridCube: I just saw that I need to do it, thanks
[16:34] <GridCube> Ammar, if you like some desktop, or program, or what ever, you go to their launchpad page, and see the bugs they have reported make a fix for them and post it in the bug report, thats the best help you can bring to start with
[16:34] <GridCube> Ammar, if you want to develop new applications, you need to learn a language, and choose a toolkit, usual toolkits are gtk and qt
[16:35] <Ammar> GridCube: ok that could be a good start, thanks
[16:35] <GridCube> i don't know much about programation, but you can join the -devel channels and ask where they need help
[16:35] <GridCube> that way you will learn
[16:35] <GridCube> :)
[16:36] <GridCube> P: and we always need more help
[16:36] <Ammar> ok thanks, I am very much excited about it,,, have a nice day/night and bye bye :)
[16:43] <martian> Hey folks, I asked about this a while back but no one seemed to have any insight. Video describes the problem with google chrome menu's: http://www.youtube.com/watch?v=xlEZW4r9W_Y
[16:46] <baizon> martian: have you tried chromium 23?
[16:47] <baizon> imo its not xubuntu releated
[16:47] <martian> The only other system I have to test this on is a windows virtual machine :-/
[16:48] <baizon> martian: try other DE, like gnome :)
[16:48] <martian> chromium 23? What's the 23 mean?
[16:48] <baizon> martian: version
[16:48] <martian>  /smack forehead
[16:49] <martian> I haven't. Seems like 22 is in the repos. Seems to do the same.
[16:50] <martian> Yeah, I'll try out gnome
[16:52] <baizon> ok
[16:52] <baizon> report back if it works or dont
[16:52] <martian> So can you confirm that you don't have the same issue?
[16:53] <baizon> martian: if you wait a min
[16:53] <baizon> i have to install chromium first
[16:53] <xubuntu425> just installed xubuntu 12.10 in a netbook and the interface don't work, when i restart the system, it start whithout graphical interface... help!!!
[16:54] <baizon> xubuntu425: does it boot into something?
[16:55] <xubuntu425> start with terminal... boot from hard disk
[16:55] <xubuntu425> there is a string to activate the interface?
[16:55] <xubuntu425> or it's a bug?
[16:56] <baizon> xubuntu425: which version did you install? the destkop or server version?
[16:56] <baizon> try to install lightdm
[16:56] <xubuntu809> hi everyone
[16:57] <xubuntu192> i'm the user with trubles with graphical interface... please rewrite the answere
[16:57] <xubuntu809> There is a bug in live session for 12.10, you can boot your live session adding a few lines to /etc/X11/xorg.conf
[16:58] <xubuntu809> "with eeePC"
[16:58] <xubuntu809> no sorry i was about to ask some stupid question
[16:59] <baizon> martian: got the same "issue"
[16:59] <xubuntu809> oh ok
[16:59] <xubuntu809> after the install, will i have to cope with it again ?
[17:00] <xubuntu809> i'm currently installing xbuntu from my live usb
[17:00] <xubuntu192> i'm installing from usb too with UNEBOOTIN
[17:01] <xubuntu809> and got no graphic interface at all ?
[17:01] <xubuntu192> i tried ubuntu 12.10 first... but it doesn't work
[17:01] <xubuntu809> ok it's a reported bug
[17:02] <xubuntu809> yu can still boot it, editing a file with command line tooll vi
[17:02] <xubuntu192> now i'm trying xubuntu 12.10 but after the installation when i restart... it start from terminal!!!!
[17:02] <xubuntu809> yeah
[17:02] <xubuntu809> ok
[17:02] <xubuntu192> i can't use terminal!! where is my graphic? eheheh
[17:02] <xubuntu809> edit the file /etc/X11/xorg.conf
[17:02] <xubuntu192> ok
[17:02] <xubuntu809> :oO
[17:02] <xubuntu192> and then?
[17:02] <xubuntu809> gotta do it in root
[17:03] <xubuntu192> ok
[17:03] <xubuntu809> typein something i'm currently googling for u
[17:03] <xubuntu192> oh thanks...
[17:03] <xubuntu192> i'm googling too but i can't find the answer
[17:04] <xubuntu809>   Live session: 1. On boot push F5 and add to kernel option: text 2. Boot to TTY1 3. Creat /etc/X11/xorg.conf which contains:  Section "Device"    Identifier "Intel GMA3600"    Driver "fbdev" EndSection  4. Save configs 5. Start the LightDM whith command: sudo service lightdm start 6. Enjoy!
[17:04] <xubuntu809> ok
[17:04] <xubuntu809> I got better
[17:05] <xubuntu809> google "bugs launchpad xorg 1069031
[17:05] <xubuntu809> first anwser is the good one
[17:07] <xubuntu809> gotta go. just in case it's bug 1069031 on launchpad
[17:08] <xubuntu192> ok i'm reading
[17:08] <xubuntu192> hope will work
[17:08] <xubuntu192> if don't work i'll trey xubuntu 12.04 versio
[17:08] <martian> baizon: Just tried it in ubuntu-desktop and same thing. Soooo annoying! Well, off to lunch
[17:09] <baizon> martian: so its a chromium bug, you can report it :)
[18:08] <acuozzo> Does Xubuntu a clean (from CD) installation of Xubuntu come with gnome-disk-utility (a.k.a., "Disks")?
[18:09] <acuozzo> damn
[18:09] <acuozzo> s/Xubuntu//
[18:11] <ferni> no
[18:11] <ner0x> Does xubuntu have any specific accounting software?
[18:11] <knome> ner0x, there's some in the repositories, but none is installed by default.
[18:12] <acuozzo> OK, thanks ferni.
[18:13] <martian> baizon: mmhmm, so I shall! So does google pull off of the chromium source ya think?
[18:14] <ner0x> knome: Any suggestions?
[18:15] <knome> ner0x, i'm sorry, don't know those well
[18:16] <martian> ner0x: LibreOffice Calc? Roll your own :)
[18:16] <ner0x> knome: No problem.
[18:16] <ner0x> martian: I could but I'd like something that parses the csv I get from the bank.
[18:17] <knome> LO Calc can parse csv
[18:18] <ner0x> knome: It can open it, I'd like it to assign it to the appropriate categories for my accountant.
[18:18] <martian> ner0x: lmgtfy ;) http://www.gnucash.org/
[18:19] <GridCube> i used gnucash once or twice
[18:19] <GridCube> its nice and simple
[18:20] <ner0x> gnucash may work.
[18:21] <ner0x> I was just looking for *opinions* on what people have used.
[18:21] <ner0x> Not what they use. :)
[18:21] <GridCube> ner0x, https://wiki.ubuntu.com/Accounting
[18:21] <ner0x> GridCube++ # helpful for sure.
[18:22] <GridCube> though that page was last updated in 2008, there might be other options now, do some searchs and update the wiki ner0x :D
[18:29] <asarch> What is the best way to do CPU Frequency Scaling ala Xfce (without evolving any GNOME software)?
[18:29] <asarch> sysfsutils doesn't work at all
[18:39] <koegs> xfce4-cpufreq-plugin?
[18:41] <martian> baizon: already reported it seems: http://code.google.com/p/chromium/issues/detail?id=103009
[18:41] <baizon> good :(
[18:41] <baizon> :)
[19:55] <pressman57> hi all, just a quick question. will steam be available to xubuntu users?
[19:56] <pressman57> or does it requre unity?
[19:58] <Unit193> pressman57: I do not know, but the depends of the package installer itself don't have it as a depends.
[19:58] <baizon> pressman57: it will work
[19:58] <baizon> you dont need unity
[19:58] <pressman57> baizon: cool. xfce rocks imho
[19:58] <baizon> indeed
[19:59] <pressman57> thanks. off to download the iso.
[19:59] <baizon> iso?
[19:59] <baizon> you mean deb ;)
[20:39] <puff> I'm running xubuntu 11.10, empathy-chat keeps losing its connection and then when it reconnects, gives me a security exception.  Also, every time I reboot, authentication fails until I edit the account settings and retype (the same) password in.
[20:41] <puff> I'm running xubuntu 11.10, empathy-chat <IP_ADDRESS>, empathy keeps losing its connection and then when it reconnects to google talk, gives me a security exception.  If I click to connect anyway everything works.  Every time I reboot, authentication fails until I edit the account settings and retype (the same) password in.
[20:41] <puff> Whoops, sorry.
[22:25] <xubuntu313> hi
[22:25] <xubuntu313> iatlian mod ?
[22:25] <knome> !it | xubuntu313
[22:26] <xubuntu313> tmx
[23:47] <VercingeTorege> hi
[23:48] <VercingeTorege> can anyone help me?
[23:49] <pleia2> !hi
[23:49] <pleia2> you can just go ahead and ask your question :)
[23:49] <VercingeTorege> hi pleia2
[23:50] <VercingeTorege> I can not complete the installation of xubuntu
[23:51] <VercingeTorege> the installer search more so for a long time


[06:07] <amritbera> hi
[06:07] <amritbera> all
[06:08] <amritbera> can somebody help me for GPRS connection???
[06:13] <amritbera> can somebody help me for GPRS connection???
[06:19] <AlanBell> amritbera: this is not a support channel, please ask in #ubuntu or #ubuntu-beginners-help
[06:59] <amritbera> hi
[07:00] <amritbera> hi
[07:01] <amritbera> can anybody help me to connect GPRS??
[07:01] <amritbera> can anybody help me to connect GPRS??
[14:05] <Pendulum> nigel_nb: you're about to hate me, but my mic is  broken :( (discovered yesterday when I tried to do the voice bits of those screencasts)
[14:05] <nigel_nb> Pendulum: hahaha
[14:08] <nigel_nb> Pendulum: so you wont be able to record too?
[14:08] <Pendulum> no :(
[14:10]  * nigel_nb bangs his head on the keyboard
[14:11] <Pendulum> there was swearing when this was discovered
[14:12] <Pendulum> and then I took the anger out on the cockroach infestation in my flat
[14:12] <nigel_nb> now I'm lost wondering whom to ask
[14:13] <nigel_nb> Pendulum: do u know if pleia2 has a working mic (my last option) :(
[14:13] <Pendulum> dunno
[14:14] <Pendulum> you could also do them yourself (or find a non-female-voiced person since at this point it's finding someone that seems to be the problem)
[14:14] <pleia2> not a good one
[14:14] <pleia2> (and I don't really have time for it anyway)
[14:18] <cjohnston> mornin
[14:21] <nigel_nb> Pendulum: indian accent is not really ideal for a screencast
[14:21]  * popey is happy to voice over :)
[14:21] <popey> if you dont mind English Male
[14:21] <nigel_nb> i dont :)
[14:21] <nigel_nb> great :)
[14:22] <popey> i will not be offended if not chosen though :)
[14:22] <nigel_nb> popey: its the same one we talked sometime back
[14:22] <nigel_nb> using IRC with pidgin and Webchat
[14:22] <popey> i do have decent recording equipment though
[14:22] <Pendulum> popey: I think you've likely now got the job :P
[14:22] <popey> heh
[14:22] <nigel_nb> Pendulum: hehe
[14:23] <nigel_nb> popey: yep, you got the job.  Now, the only question is how I get the videos to you (I think you may have one of them already)
[14:23] <popey> i thought I had two?
[14:23] <popey> what are the names, I'll look for them
[14:24] <nigel_nb> IRCwithWeb and IRCwithPidgin
[14:24] <popey> ta
[14:24] <nigel_nb> popey: you can voice over them, mix them, and add to screencasts team yourself if u want to
[14:24] <popey> cool
[14:24] <nigel_nb> I just want it up and be able to share it :)
[14:25] <nigel_nb> the idea is when we blog about user days, we can add to the posts " If you dont know how to use IRC, see these videos .."
[14:29] <nigel_nb> _marx_: I still haven't gotten the files from ubuntuone :(
[14:35] <nigel_nb> popey: when a video is added to the screencast team, is it okay to post in on our blogs?
[14:35] <popey> sure
[14:36] <nigel_nb> great :)
[14:36] <nigel_nb> just give me a shout when you're done and I'll update the wiki pages too :) :)
[14:40] <nigel_nb> cjohnston: I have something close to a bad news for you
[14:41] <cjohnston> uh oh
[14:41] <nigel_nb> cjohnston: I *may* need to go home on a family emergency on the week of Ubuntu User Day, I'll make sure that you have the entire content of my session so that anyone can lead it
[14:41] <cjohnston> ok
[14:52] <Pendulum> pleia2: ping?
[15:31] <_marx_> nigel_nb: I've repeated the steps on ubuntuone
[15:31] <nigel_nb> checking again
[15:32] <nigel_nb> I'm supposed to check shared with me right?
[15:33] <_marx_> afaik yes
[15:35] <nigel_nb> _marx_: nothing in shared with me :(
[15:35] <_marx_> hum
[15:36] <nigel_nb> well, then its not working, bah, bug
[15:36] <nigel_nb> now wat do we do :(
[15:37] <nigel_nb> try mediafire then
[15:37] <_marx_> well check your email nigel_nb it says you haven't accepted the share
[15:37] <nigel_nb> oh
[15:37] <nigel_nb> checking
[15:39] <nigel_nb> _marx_: check the email you sent it to
[15:39] <nigel_nb> I haven't gotten it
[15:44]  * _marx_ needs to learn to type
[22:06] <Vantrax> hi all, sorry im not around much atm, just in the middle of moving house and getting my daughter started in daycare
[22:07] <mhall119|work> Vantrax: first year in daycare?
[22:07] <Vantrax> yeah, shes only 4 months old
[22:07] <mhall119|work> have fun
[22:07] <mhall119|work> sometime in the next 5 days, everyone in your house is going to be sick
[22:07] <mhall119|work> just warning you
[22:07] <Vantrax> yeah... she doesnt like it
[22:08] <Vantrax> I dont even have internet at home yet >.<
[22:08] <Vantrax> damn phone company is screwing around
[22:08] <mhall119|work> find yourself a good book then
[22:08] <Vantrax> yeah, been reading Robert Jordan
[22:08] <mhall119|work> daycares and schools are like shock and awe for the immune system
[22:09] <Vantrax> lol, i can imagine
[22:26] <doctormo> Hey Vantrax, hope your having a good new year.
[22:27] <Vantrax> yeah,  not bad so far, but no internet sucks
[22:28] <doctormo> It would drive me to start living at my community center.
[22:32] <Vantrax> i keep going into work to use the internet while im on holidays:P
[22:33] <doctormo> I remember doing that back int he day
[22:33] <doctormo> Now I just make aragements with neighbours, that's why local community is still important... shared wifi
[22:34] <Vantrax> lol
[22:37] <Vantrax> http://www.downloadsquad.com/2009/12/26/chinese-copy-cat-pirates-launch-ubuntu-that-looks-just-like-windows-xp/
[22:40] <doctormo> Vantrax: That's not exactly piracy... it's more like copyright infringment through a dirivitive work.
[22:41] <Vantrax> funny tho
[22:41] <doctormo> Sure
[22:41] <doctormo> Interesting too, the guile of people and also the amount of familarity we have to overcome in our teaching.
[22:44] <_marx_> saw that too and wondered how a familiar looking interface could help new users
[22:49]  * _marx_ was a windows user for a year or so and has 10 minutes on mac
[22:50] <doctormo> _marx_: It can't, it's mostly about confusing the brand (trademark problems) and making people believe they are getting one thing, when they are really getting another.
[22:52] <_marx_> doctormo: I think you are correct: it's important for new users to "see" a difference immediately
[22:52] <_marx_> prepares them for more differences to come
[22:52] <doctormo> This is why I think that making things blue with a start button is just the wrong way to go.
[22:53] <doctormo> I've had a lot of positive reactions from new interfaces, it makes people believe that what they're getting is different and they brace for niggles.
[22:54] <_marx_> exactly, and ask questions from the person making the introduction


[03:30] <lfaraone> mhall119: I submitted a merge proposal to django-openid-auth a few weeks ago. Is the project still active, slash where should I poke on that branch?
[04:08] <TheMuso> c/
[05:48] <apachelogger> pitti: apport uses core_pattern, getting the core dump from the kernel as argument?
[06:48] <pitti> Good morning
[06:49] <pitti> apachelogger: not as argument, the core dump gets fed into stdin; there are some macros like %p (pid)
[06:49] <apachelogger> ah
[06:49] <pitti> %s (signal number), %c (core limit)
[06:49] <apachelogger> I see
[07:04] <apachelogger> pitti: after poking around a bit I think that we'll end up having the core dump handled by apport anyway. the kde crash handler acts on the in-process signal of the crashing application so we don't have access to a core dump at that point. what I imagine right now is triggering a core dump after kde's crash handler (currently we exit()) and have apport itself handle the report business.
[07:04] <pitti> apachelogger: ah, if you do that you should just re-raise() the signal in the sighandler
[07:04] <pitti> apachelogger: that's the usual way that we do with firefox or LibO
[07:04] <apachelogger> raise(sig);
[07:05] <apachelogger> yeah, testing that right now
[07:05] <pitti> apachelogger: but I guess you want the KDE crash handler UI, right?
[07:05] <pitti> apachelogger: from that, can you somehow see (in the coredump or whereever) if the user agreed to report the issue?
[07:05] <apachelogger> that's the plan
[07:05] <pitti> apachelogger: oh, I guess you can conditionally re-raise() only if the user agreed to
[07:06] <apachelogger> oh, that's a good idea
[07:07] <pitti> apachelogger: then you can call /usr/share/apport/whoopsie-upload-all from an upstart job to process the initial .crash and create the .upload stamp
[07:07] <pitti> apachelogger: we do that in our CI machinery to auto-upload crashes during testing
[07:08] <pitti> apachelogger: we can discuss the details of that, but I think these are  the ready-made building blocks which ought to work for you
[07:08] <pitti> apachelogger: then we'll only report to whoopsie for reports that the user agreed to send, and you don't get a second UI
[07:09] <pitti> apachelogger: do you have a plan what to do for non-signal crashes? (package installation failures, python, etc.)
[07:10] <apachelogger> they go through apport, kde's kcrash handler only applies to actual kde applications
[07:10] <pitti> apachelogger: right, I meant in terms of UI
[07:10] <apachelogger> apport-kde
[07:11] <apachelogger> for UI consistency reasons I will probably have to fiddle with that a bit as well
[07:33] <penghuan> cjwatson: ping
[07:35] <penghuan> cjwatson: Can you take some time to have a look at my merge proposal about  https://code.launchpad.net/~penghuanmail/ubiquity/lp.1197220/+merge/195712
[08:08] <dholbach> good morning
[08:40] <OdyX> tkamppeter_: Hi. Did you see http://bugs.debian.org/731658 ? It would be nice to avoid using PATH_MAX globally. Your advice on the patch would be nice too...
[09:54] <brendand> does anyone know why my qt plugin (with suffix .so) might have cpython-33m-x86_64-linux-gnu inserted into its name?
[09:56] <apachelogger> pitti: to not discriminate against !kapplications I think we shouldn't simply assume that every report was actually accepted by the user. instead I am thinking about having specific stamps set by the kde crash handler with the suffixes .drkonqi-accept or .drkonqi-reject. former would lead to UI-less upload, latter would discard the entire report as the user didn't want an automatic report. reports without either will bring up the apport UI. any
[09:56] <apachelogger>  opinion on possibly supporting this by apport in general? or should I simply limit support for ui-less accept/reject to kubuntu tools?
[09:57] <pitti> apachelogger: no, you shouldn't assume it; my thought was that the signal handler would know whether drkonqui accepted the crash or not, and only re-raise if it was accepted
[10:00] <apachelogger> hm
[10:00] <apachelogger> pitti: and write a .upload file immediately I guess?
[10:01] <pitti> apachelogger: no, that won't work; you need to add package and other information to it, i. e. call sr/share/apport/whoopsie-upload-all or do the equivalent steps
[10:01] <pitti> "usr/..."
[10:01] <apachelogger> right, that's why I was thinking about those additional stamps
[10:01] <apachelogger> as we need to set the reports apart as already-approved or already-rejected
[10:01] <pitti> apachelogger: where would you create the stamps, if not in the signal handler?
[10:02] <apachelogger> pitti: in the signal handler :P
[10:02] <pitti> apachelogger: then skip the stamps and just don't raise() if  the user doesn't want to report
[10:02] <pitti> apachelogger: that saves you needlessly calling apport and creating the .crash (which is quite CPU intense), and the stamp handling
[10:02] <apachelogger> true, we'd still need and approved/accept stamp though
[10:03] <pitti> why?
[10:03] <pitti> oh, for non-KDE crashes
[10:03] <apachelogger> aye
[10:03] <pitti> well, that stamp is .upload
[10:03] <apachelogger> -> [11:00:18] <apachelogger> pitti: and write a .upload file immediately I guess?
[10:04] <apachelogger> that's what I meant there ;)
[10:04] <pitti> apachelogger: for that, can you teach drkonqui to either call a few python functions or call a script which adds the necessary information to the .crash?
[10:04] <pitti> argh no, at that point the .crash doesn't even exist yet
[10:04] <pitti> meh
[10:05] <apachelogger> I know, it's headache material ^^
[10:05] <pitti> we might put that into whoopsie itself, it could do the information collection when needed
[10:06] <pitti> w/when/if/
[10:08] <apachelogger> pitti: that'd be cool
[10:12] <ev> pitti, apachelogger: branches welcome :)
[10:17] <apachelogger> ev: oh, btw, how does the metrics stuff work?
[10:18] <ev> apachelogger: which metrics stuff is this?
[10:18] <apachelogger> ev: com.ubuntu.WhoopsiePreferences.SetReportMetrics
[10:19] <seb128> xnox, https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1259111 is probably yours (new since your uploaded on friday according to e.u.c)
[10:19] <xnox> seb128: argh =) thanks.
[10:19] <seb128> yw ;-)
[10:20] <ev> apachelogger: that's not wired up to anything yet
[10:20] <apachelogger> I see
[10:20] <xnox> seb128: i wonder how come i am not subscribed to usb-creator bugs.... now subscribed
[10:20] <ev> apachelogger: https://wiki.ubuntu.com/ErrorTracker#Invitation_for_metrics_collection
[10:21] <seb128> ev, we have been consistently tackling highest reports for 13.10 since release, and they are dropping off the list, it's weird that the curve doesn't reflect more that...
[10:21] <apachelogger> ev: I'll hide the UI option for the time being then
[10:21] <seb128> xnox, seems like a good idea if you are the maintainer nowadays ;-)
[10:24] <Laney> some cool guy wrote a script to automatically subscribe you to packages you upload
[10:25] <seb128> does it unsubscribe you have <n> days?
[10:25] <Laney> yep
[10:25] <seb128> cool
[10:25] <seb128> how is that called/where is it?
[10:25] <Laney> cron
[10:26]  * Laney tries to remember where it is
[10:26] <xnox> Laney: i found that it would randomany unsubscribe my custom subscriptions....
[10:26] <ev> seb128: we need to re-run the calculation to generate that graph, I suspect. Adding something into Asana to track this
[10:27] <seb128> ev, thanks
[10:27] <Laney> you didn't report the bug?!?!?!
[10:28] <xnox> Laney: well, i didn't backup my existing subscriptions, now did I?! =)
[10:29] <Laney> it's supposed to not subscribe you if you already are
[10:29] <Laney> ho hum
[10:32] <xnox> Laney: where was that script again? i clearly haven't used it since the incident....
[10:32] <Laney> lp:~laney/+junk/lp-subscribe-uploads
[10:33] <Laney> it was fairly fire and forget, but I'd still merge patches / fix bugs
[10:40] <Laney> bah
[10:40] <Laney> screen has started segfaulting
[11:01] <cjwatson> penghuan: done
[11:02] <penghuan> cjwatson:thx
[11:03] <seb128> Laney, let's maybe ask here?
[11:03] <seb128> doko_, what's the rational for changes like
[11:03] <seb128> -	dh $@ --with autotools_dev
[11:03] <seb128> +	dh $@ --with autoreconf
[11:03] <seb128> (Laney was trying to get that harfbuzz diff to Debian but pochu wants to understand what it's fixing/the rational)
[11:05] <cjwatson> seb128: does a better job of handling new ports - there's a libtool fix that that picks up
[11:05] <seb128> cjwatson, do we have a description of "better job" for those who want to understand want issue it fixes in practice?
[11:05] <seb128> e.g a link to an email/wiki/bug reference?
[11:06] <cjwatson> man dh_autoreconf ? :-)
[11:06] <Laney> mmm, that fix doesn't appear to be in Debian
[11:07] <cjwatson> seb128: dh_autotools-dev_* only updates config.guess/config.sub
[11:07] <seb128> cjwatson, fair enough, thanks ;-)
[11:07] <cjwatson> seb128: dh_autoreconf does a full update of all the autotools output - so it also picks up bug-fixes in other parts of that toolchain
[11:07] <seb128> cjwatson, thanks, that's the sort of explanation I was after, and it makes sense ;-)
[11:08] <cjwatson> seb128: dh_autoreconf is more complete, but it also requires more care, because it's often the case that packages' autotools source requires some massaging before it can be regenerated
[11:08] <seb128> yeah, I know about that :p
[11:08] <Laney> We were more after the specific rationale for this batch of changes; the libtool hint was enough
[11:09] <cjwatson> seb128: dh_autoreconf is a superset of dh_autotools-dev_* only if libtool is used (I think that's right) - there are some edge cases that are more complicated, so it's definitely not a "drop it in automatically" kind of thing
[11:10] <seb128> cjwatson, thanks
[11:10] <seb128> we have been using dh-autoreconf for all the desktop stuff for a while
[11:10]  * cjwatson nods
[11:10] <seb128> (especially when we had launchpad integration changes that needed to update configure and other stuff)
[11:11] <seb128> I was just unsure how to "sell" it to others/not familiar enough with dh_autotools-dev to explain the difference
[11:11] <seb128> as Laney said, we have what we need to forward that fix to Debian ;-)
[11:11] <xnox> cjwatson: slangasek: any updates re https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1184006 branches ?
[11:11] <Laney> it was more "why specifically is this interesting for this package now"
[11:11] <Laney> not "why is dh-autoreconf good in general?"
[11:12] <xnox> Laney: to get libtool goodness =)
[11:12] <Laney> got it
[11:12] <Laney> ta
[11:16] <cjwatson> xnox: not something I've had time to look at for some time
[11:17] <cjwatson> (nor expect to before EOY)
[11:18] <xnox> cjwatson: in that case no outstanding merge proposals for ubiquity, upload time? (it has quite a few changes staged)
[11:19] <Laney> xnox: want to review the remaining libtimezonemap changes? :-)
[11:19] <cjwatson> xnox: up to you, I wasn't touching that due to the note at the top of the changelog ...
[11:21] <xnox> cjwatson: yeah, that's all fixed now.
[11:21] <xnox> Laney: =)
[11:22] <Laney> I did a chunk but there's still a few left
[11:22] <Laney> changes what are more relevant to ubiquity's use of it
[11:32] <xnox> doing a package merge "cross-cross merge encountered" => please work it all out =)))
[11:54] <xnox> cjwatson: do you mind if I do a debhelper merge, or would you rather do it? (i have a dep-wait on 9.20131104 for debian bug #728620)
[11:55]  * xnox goes to check if emacsen-common is merged.
[11:55] <xnox> yeap, we do have the new enough emacsen.
[11:59] <cjwatson> xnox: go for it
[11:59] <xnox> ack.
[12:05] <tkamppeter> OdyX, this with PATH_MAX was simply overlooked when merging foomatic-rip into cups-filters. I will take your patch upstream. Thanks for the patch.
[12:27] <tkamppeter> OdyX, fixed upstream, BZR rev. 7140.
[12:28] <mlankhorst> how often do packages move from NEW to DONE?
[12:29] <cjwatson> no fixed schedule, depends on human attention
[12:30] <cjwatson> assuming you're asking about mesa, accepted now
[12:33] <mlankhorst> ah
[12:33] <mlankhorst> i was curious since arm64 was accepted
[12:34] <cjwatson> mlankhorst: I assume it was just the first one in place
[12:35] <cjwatson> mlankhorst: oh, no, it's because arm64 doesn't build libxatracker*
[12:35] <cjwatson> and those were the new binaries
[12:35] <mlankhorst> ah right, ofc :)
[12:36] <cjwatson> wait, what?  sbuild is seriously in universe?
[12:36] <cjwatson> that I did not expect
[13:04] <tseliot> didrocks: hey, bbswitch is now ready for promotion (bug 1255583)
[13:04] <didrocks> tseliot: thanks, please just reassign to me, on other stuff, will do later on
[13:04] <tseliot> didrocks: sure, thanks
[13:28] <mlankhorst> doko: hey, can you check if needing to suppress building gallium and egl is still needed? We're no longer carrying the patches in 10.0 that broke things
[13:30] <doko> mlankhorst, I'd like to wait for a fast reliable native system. don't want to setup my cross hacks again to build this
[13:31] <mlankhorst> ok
[13:39] <mlankhorst> doko: but we already build arm64 right? you could just test the package from debian-experimental on arm64
[13:47] <OdyX> tkamppeter: great, thanks. I hope it won't break anything then. Uses of PATH_MAX should be replaced though, see http://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html ...
[14:22] <alkisg> highvoltage: /etc/xdg/menus/applications.menu is a mess in Trusty, the gnome-session-flashback is ruined with that. If I replace it with the version from Precise, then it's fine.
[14:23] <alkisg> ...is that also used in gnome-shell? Can we ship the version from Precise in order to have sane menus?
[14:24] <alkisg> I could create a wrapper package e.g. gnome-session-flashback-oldmenus that dpkg-diverts it, but wouldn't it be better to solve it upstream, or at least in debian?
[14:25] <alkisg> (or stgraber ^)
[14:26] <seb128> alkisg, what's the issue exactly? and no you can't put the old content back, open an upstream bug if GNOME screwed it up for other desktops, they did some tweaking for gnome-shell I think
[14:27] <alkisg> seb128: the new menu structure splits the menus in a non-sensible way, half of the things that were in accessories have now gone to utilities,
[14:27] <seb128> mardy, hey, did you see bug #1258578? seems a new issue in trusty with the signon update, it's one of the most reports errors there
[14:28] <alkisg> there's a sundry submenu, a full "others" menu... and some translations are the same, so e.g. in greek I see two same entries for "Accessories" and "Utilities", "Βοηθήματα" for both of them
[14:28] <alkisg> The settings submenus are all wrong.. too many things are wrong to list them in order
[14:29] <alkisg> I tried to find the logic behind the new organization, but I couldn't find any, and I don't use gnome-shell nor unity, so I don't know if those entries make more sense there...
[14:29] <alkisg> (logic ==> I meant the rationale, via googling...)
[14:30] <alkisg> The .desktop files in /usr/share/applications are more or less unchanged, it's just that /etc/xdg/menus/applications.menu file that messes up everything...
[14:30] <seb128> alkisg, you are using trusty? https://git.gnome.org/browse/gnome-menus/commit/?h=gnome-3-8&id=b89833d78a9ab43f1fea1d01cd233551d47f08a7 was supposed to fix the "others" category issue
[14:31] <alkisg> Yup I'm using trusty, let me check the bug report, but the "others" submenu is only 5% of the problems there
[14:31] <seb128> alkisg, you should open upstream gnome-menus bugs reports for each of the specific issues you have, you might want to open launchpad bugs corresponding to those as well
[14:31] <seb128> but we are not going to revert upstream work randomly
[14:32] <alkisg> seb128: thanks, will do, but could you help me a bit to understand the rationale? Are those menus used for gnome-shell nowadays?
[14:32] <seb128> we need to understand the changes, why they are there and what we can do that accomodate gnome-shell uses and other desktops as well
[14:32] <seb128> alkisg, https://git.gnome.org/browse/gnome-menus/commit/?h=gnome-3-8&id=36d5d699d7d4193a1b3d84777566466326f78b19
[14:32] <seb128> read https://bugzilla.gnome.org/show_bug.cgi?id=694131 I guess
[14:33] <alkisg> Thanks, I think that last one contains most of the changes
[14:34] <alkisg> Hehe, "Uhm, except for the first patch, the series was not actually meant to be committed literally."
[14:35]  * alkisg wonders if there's any way to dump the effective menu layout to attach it to bug reports
[14:38] <JordiGH> How do I get the debian/control of this package? https://launchpad.net/~octave/+archive/unstable/+packages
[14:38] <alkisg> Is mate-desktop going to be available in Trusty? Maybe they've already solved this problem there...
[14:38] <JordiGH> I mean, other than adding it to my apt.sources and doing apt-get source.
[14:38] <pitti> jibel: download and unpack https://launchpad.net/~octave/+archive/unstable/+files/octave_3.7.7-0%7Eppa1%7Eraring1.debian.tar.gz
[14:38] <pitti> sorry
[14:39] <pitti> JordiGH: ^
[14:39] <pitti> jibel: wrong nick, sorry
[14:39] <JordiGH> Man, I wish there was a web interface to it like packages.debian.org :-/
[14:39] <JordiGH> pitti: Okay, thanks.
[14:39] <sladen> alkisg: /usr/lib/libdbusmenu/dbusmenu-dumper
[14:39] <pitti> JordiGH: there (kind of) is for ubuntu packages, but not for PPAs
[14:42] <alkisg> sladen: thanks, I installed libdbusmenu-tools, will check that in a while.
[14:42]  * alkisg waves...
[14:43] <seb128> sladen, he was asking about xdg .desktop menus, I doubt that's the right tool...
[14:44] <JordiGH> pitti: Alright, thanks for your help.
[14:45] <mhall119> lfaraone: I think jamesh is still running that project, but I can take a look at the mp
[15:17] <lfaraone> mhall119: awesome, thanks!
[15:18] <mhall119> lfaraone: have a link to the MP?
[15:20] <lfaraone> mhall119: https://code.launchpad.net/~lfaraone/django-openid-auth/custom_response/+merge/195845
[15:27] <mhall119> lfaraone: can you add tests that check the value of openid_response in render_failure?
[15:29] <lfaraone> mhall119: sure.
[15:29] <mhall119> thanks lfaraone
[16:17] <bdmurray> seb128: were you going to do the merging / upload of the apturl fix for bug 1050826?
[16:17] <seb128> bdmurray, hey, yes, I just got a busy monday and didn't get to do it yet ;-)
[16:17] <seb128> bdmurray, thanks for the review!
[16:19] <hallyn_> is there a simple way to get do-release-upgrade (for a test) to ignore the fact that some packages are unauthenticated?
[16:20] <bdmurray> hallyn_: I don't think so
[16:20] <hallyn_> drat
[16:21] <bdmurray> hallyn_: what exactly are you trying to do?
[16:22] <hallyn_> test whether a candidate qemu for trusty woudl cleanly upgrade in lts-to-lts
[16:23] <xnox> hallyn_: i do schroot into precise & add sources as appropriate and do a dist-upgrade.
[16:23] <rbasak> hallyn_: you can just update sources.list and dist-upgrade I think
[16:23] <xnox> hallyn_: also you can run piuparts to do automated lts->lts upgrades/downgrades/install/remove/reinstall and a bunch of other tests.
[16:24] <xnox> hallyn_: piuparts can work with pbuilder tarballs or schroots, if I remember correctly.
[16:26] <hallyn_> rbasak: no, but i can ctrl-z and re-insert my custom entries.  that bit is fine :)
[16:27] <hallyn_> piuparts?  i've heard of it...
[16:27] <hallyn_> sounds like maybe what i need
[16:28] <hallyn_> xnox: is there a good wiki link showing simple usage?
[16:28] <xnox> hallyn_: it's running automatically against the whole debian archive and reports problems to PTS.
[16:28] <xnox> hallyn_: https://piuparts.debian.org/
[16:29] <xnox> hallyn_: and links from there https://piuparts.debian.org/doc/README_1st.html https://piuparts.debian.org/doc/piuparts.1.html
[16:29] <hallyn_> well, it does seem to be workign ok though (just drops to complaints about trusty packages not installed)
[16:29] <hallyn_> xnox: ok, thanks.  i'll definately have to add that to my repertoire
[16:48] <hallyn_> xnox: how do you run it for lts-to-lts upgrades?
[16:48] <xnox> hallyn_: i can't remember for sure, but the semantics was to specify the base release (e.g. precise) and the target releases, or even a just compiled binaries.
[16:49] <xnox> hallyn_: it was a long time since i used it last =) i know I am bad.
[16:50] <hallyn_> xnox: oh - np, i just figured you used it daily.  thanks!  i'll figure it out
[17:06] <slangasek> xnox: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1184006> none, sorry; haven't had time to straighten out the bugs cjwatson pointed out
[17:06] <slangasek> xnox: if you're merging debhelper, please take care to preserve the versioned dep on sysv-rc that joeyh dropped recently, as it still applies for precise upgrades in Ubuntu
[17:07] <xnox> slangasek: thanks.....
[17:07]  * xnox goes to reupload debhelper i think.
[17:08] <mlankhorst> hm, why is mesa still in -proposed ? (it has a new binary libxatracker2)
[17:11] <xnox> slangasek: looks good? http://paste.ubuntu.com/6546703/
[17:11] <xnox> darn, wrong DEB_NAME
[17:13] <slangasek> xnox: it looks familiar, and if it's a straight revert I trust that it's fine :)
[17:13] <xnox> ack.
[17:13] <cjwatson> trying: mesa
[17:13] <cjwatson> skipped: mesa (68 <- 160)
[17:13] <cjwatson>     got: 26+0: i-26
[17:13] <cjwatson>     * i386: kubuntu-active, xserver-xorg-video-all, xserver-xorg-video-vmware
[17:13] <cjwatson> mlankhorst: ^-
[17:13] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[17:13] <mlankhorst> oh right
[17:14] <mlankhorst> fixed :p
[17:28] <jibel> slangasek, could you review the MP attached to bug 1257305 ? I think it is the only change between the version in the distro and upstream so it is probably better to directly release latest upstream revision.
[17:34] <slangasek> jibel: I've seen it, and the change is obviously correct; but I'm more concerned about getting sbsigntool upstream sorted out so we can get proper releases
[17:34] <slangasek> jibel: if you want to upload it be my guest
[17:36] <jibel> slangasek, thanks but I cannot upload :)
[17:41] <brendand> hi, i'm trying to build a package containing a qt plugin whose target is 'libgui-engine'
[17:42] <brendand> this builds as 'libgui-engine.so'
[17:43] <brendand> but when i install the package, it turns into 'libgui-engine.cpython-33m-x86_64-linux-gnu.so'
[17:43] <brendand> i can't figure out how python comes into it
[17:45] <xnox> brendand: did you install the .so into /usr/lib/python* ?
[17:45] <slangasek> jibel: ok.  are you ok to have this wait until I have a chance to get a poper upstream release sorted?
[17:45] <slangasek> jibel: (which will be a couple weeks at least)
[17:45] <brendand> xnox, no it's installed to /usr/lib/checkbox-gui/plugins
[17:47] <brendand> xnox, i think i just realised :/
[17:47] <brendand> xnox, for some reason i put ${python3:Depends} in the binary packages Depends
[17:51] <xnox> brendand: don't do that =) or do override_dh_python3 and use exclude to exclude that path and/or that package
[17:51] <xnox> such that they are untouched.
[17:51] <brendand> xnox, well having it serves no purpose so i remove it :)
[17:51] <brendand> xnox, dumb stuff that creeps in thanks to the evils of Ctrl+C/V
[17:53] <slangasek> Laney: I hear you may know something about libwebkitgtk being broken; once it's fixed, can you let me know and/or give back gnome-online-accounts for building?
[17:53] <cjwatson> slangasek: I notice that seb128 has an update building at the moment
[17:53] <Laney> slangasek: I expect it's just du
[17:53] <Laney> that
[17:53] <slangasek> ok
[17:54] <Laney> uninstallable due to transition etc
[17:57] <slangasek> xnox: do you know anything about the jquery/flot stuff on http://package-import.ubuntu.com/status/ ?  It is not well-behaved and makes my browser angry
[17:59] <xnox> slangasek: with my limited W3C skillz, it appears to me entirely unused?!
[17:59] <slangasek> hmm
[17:59] <slangasek> isn't it used to create the graphs at the bottom of the page?
[17:59] <xnox> slangasek: also it looks fine in my web-browser.
[17:59]  * xnox uses Google Chrome
[17:59] <slangasek> I didn't say it doesn't /look/ ok :)
[18:00] <slangasek> but it gets itself into some stupid busy loop (in firefox) that eventually causes firefox to kill it as a runaway js process
[18:00] <xnox> slangasek: ouch, that graph is sure a good way to generate..... every client does it, instead of server side.
[18:01] <slangasek> xnox: and it is used, <div id="queue_graph" style="width:600px;height:300px"></div>[...]$.plot($("#queue_graph"), [[ [...]
[18:01]  * xnox ponders to write a javascript bitcoin miner and infect parked domains with it.
[18:01] <xnox> slangasek: yeah spotted it now.
[18:01] <xnox> slangasek: i can look into splitting a graph into a separate page, would that work?
[18:02] <slangasek> xnox: bitcoin miner> hahaha
[18:02] <slangasek> xnox: sure, splitting it would work
[18:05] <shadeslayer> I'm curious as to what's the long term plan with logind
[18:06] <shadeslayer> will Ubuntu maintain logind with upstart integration? ( I'm mostly interested in the dbus interfaces )
[18:06] <shadeslayer> or will upstart have it's own user session namespace ?
[18:07] <xnox> shadeslayer: what do you mean? logind as a daemon is here to stay, as is with compatible dbus API as everywhere else.
[18:07] <shadeslayer> xnox: well, that's my question, will logind be dropped in the future or is it going to stay
[18:07] <xnox> shadeslayer: we do have a shim in place, but that should be mostly opaque. If there bugs, file them on launchpad as usual.
[18:08] <xnox> shadeslayer: lennart didn't write a replacement for logind yet, until that happens it's here to stay.
[18:08] <shadeslayer> xnox: there's just a minor bug, some KDE applications ask systemd for the systemd version, which isn't implemented on the dbus interface in ubuntu
[18:08] <xnox> shadeslayer: (remember that logind is rewrite of consolekit)
[18:08] <xnox> shadeslayer: those applications are wrong, they should be checking for presence of the _logind_ not of _systemd_.
[18:09] <xnox> shadeslayer: loads of packages were fixed by pitti, and the upstrem "sd_*" static files were updated as well.
[18:09] <shadeslayer> xnox: the idea I got was to check if the version is greater than a certain version to check if the interface was implemented
[18:09] <xnox> shadeslayer: at the time all applications were doing a check " if systemd; then do logind stuff; fi" instead of "if logind; then do logind stuff; fi"
[18:10] <xnox> shadeslayer: one should check the interface presence, rather than version numbers.
[18:10] <shadeslayer> *nod*
[18:10] <xnox> shadeslayer: i believe all compatible interfaces are implemented, check with e.g. d-feet if the needed interfaces are implemented.
[18:10] <shadeslayer> I'll try and refactor the code that way
[18:11] <xnox> shadeslayer: do you have example / package? you could ask pitti as he did write/upstream a lot of patches where bad assumptions were made upstream.
[18:11] <slangasek> introducing, duck typing for dbus
[18:11] <shadeslayer> xnox: sure, kde-workspace, powerdevil checks for systemd version
[18:11] <xnox> shadeslayer: or he can better consult which interfaces are available.
[18:12] <xnox> shadeslayer: please open a bug about it & subscribe myself and pitti to it. I'm getting annoyed with this "logind is not a freedesktop specification"
[18:12] <shadeslayer> xnox: actually I'm already fixing it :)
[18:13] <xnox> shadeslayer: good, please upstream it as well =)
[18:13] <slangasek> Laney, cjwatson: the update being built is for which package?
[18:14] <shadeslayer> ofcourse, already had a discussion with upstream, and the question that came out was "Will ubuntu be sticking to logind or will they be implementing something of their own, in which case it makes sense to write a ubuntu specific backend"
[18:14] <shadeslayer> well, s/ubuntu specific/upstart specific/
[18:14] <slangasek> shadeslayer: writing a different interface would be silly; we deliberately made logind work on upstart
[18:15] <slangasek> and even if the logind code base became unmaintainable on top of upstart, there's no reason to implement a distinct API
[18:15] <shadeslayer> *nod*, thanks for that
[19:11] <mcpierce> Hi, all. Looking for some guidance on becoming a Ubuntu packager. I've got experience with packaging on Fedora.
[19:20] <Noskcaj> When can i expect http://qa.ubuntuwire.com/bugs/rcbugs/ to have trusty listed? Is there anything i can do to speed it up?
[19:45] <mlankhorst> mesa 10 in trusty soon, enjoy
[19:45] <Laney> slangasek: webkitgtk
[19:46] <slangasek> Laney: ah, thanks; somehow I thought the problem was in webkit itself
[19:46] <Laney> hrm, that should be removed
[19:46] <Laney> I thought Seb took care of that; will sort it out in the morning
[19:46] <Laney> (webkitgtk supersedes it)
[19:46] <slangasek> ok
[20:10] <hallyn_> could someone push the sru fix for https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1243403 into saucy's qemu?
[20:13] <stgraber> hallyn_: I'll do an SRU round in a few minutes. (unless infinity is planning one, I believe it's his SRU day)
[20:16] <hallyn_> stgraber: thx
[20:57] <slangasek> xnox: so alternatively, we could axe the 'refresh' at the top of http://package-import.ubuntu.com/status/, which would stop the script from trying to graph n million data points every 10 minutes
[21:25] <slangasek> utlemming: hmm, your mail suggests that UEFI support comes in the form of a separate disk image - how come?
[21:26] <utlemming> slangasek: UEFI and BIOS/GPT come together
[21:26] <slangasek> why is that an additional image, instead of changes to the existing image?
[21:27] <slangasek> an image can have both a GPT and an MBR partition table on it
[21:27] <utlemming> a couple of reasons
[21:27] <utlemming> the biggest is that we wanted to preseve root being the first partition. Hybrid images make the difficult
[21:28] <utlemming> the second reason is that there is the question of supporting a hybrid mbr/gpt image
[21:28] <utlemming> after consulting with cjwatson, he strongly advised against going that route
[21:28] <slangasek> hmm, ok
[21:29] <utlemming> for 14.10, we are going to talk about making the UEFI image the cloud image default and droping the BIOS/MBR disk image
[21:57] <slangasek> xnox: the straightforward proposal: https://code.launchpad.net/~vorlon/udd/no-auto-refresh/+merge/198320
[21:58] <xnox> slangasek: ack. will pull and deploy it tomorrow. afk at the moment. =)
[21:58] <slangasek> ;)
[22:55] <infinity> awe_: Why are we adding -dbg packages in Ubuntu deltas when we prefer ddebs? (urfkill, in this case)
[22:55] <infinity> cyphermox: ^
[22:55] <cyphermox> infinity: useful in a ppa
[22:55] <cyphermox> if you feel we really shouldn't ...
[22:55] <cyphermox> I'm sending that to debian too btw
[22:56] <infinity> cyphermox: If it's going to end up in Debian too, fine.  But it seems like a silly delta for us to carry when we'd really rather get rid of all -dbg packages, not have more. :)
[22:56] <cyphermox> infinity: sure :)
[22:57] <cyphermox> I don't feel strongly for it, though it does tend to be useful when you build things in a PPA
[22:57] <infinity> You can get PPAs with ddebs.
[22:57] <cyphermox> you can?
[22:57] <infinity> (To be fair, not a default option, cause we don't want all PPAs having massive ddebs in them)
[22:57] <cyphermox> ah
[22:57] <cyphermox> a matter of asking the right magician
[22:59] <awe_> cyphermox, we probably should fix ofono too
[22:59] <infinity> Anyhow, if you're pushing this delta to Debian and it will, thus, no longer be a delta, I'm fine with processing these from binNEW.
[22:59] <cyphermox> awe_: you mean re: dbg packages?
[22:59] <awe_> yes
[22:59] <cyphermox> infinity: I'll strongly suggest it to the debian maintainer.
[23:00] <cyphermox> (for what my opinion really matters)
[23:00] <cyphermox> awe_: you mean removing them?
[23:00] <infinity> This does remind me that I need to revisit the Debian ddeb proposal, apply some sanity to it, and get them moving in the right direction.
[23:00] <infinity> So we can make -dbg a thing of the past everywhere.
[23:01] <cyphermox> infinity: happy to help. I need more work in Debian to eventually do NM process.
[23:01] <awe_> cyphermox, I actually don't know enough about the problem to speak intelligently about it.  However if getting rid of -dbg packages is a goal, then we should probably do so for ofono too
[23:01] <geofft> infinity: out of curiosity, is that doable without discarding binary uploads, which seems to be a political quagmire?
[23:01] <awe_> right now I'm neck deep in modem power code
[23:01] <cyphermox> awe_: just pull the plug when you feel like it
[23:01] <infinity> awe_: Getting rid of them is a long-term goal, not something we should carry a delta against Debian for, it's not worth the merging effort.
[23:02] <cyphermox> awe_: or I'll fix the debian side of things for ofono
[23:02] <infinity> awe_: Some day, we want them gone from both Debian and Ubuntu, and ddebs to rule the world.
[23:02] <awe_> ok
[23:02] <cyphermox> I think it might already be a delta from us
[23:02] <awe_> yea, pretty sure it is
[23:02] <infinity> geofft: It's doable with binary uploads.
[23:02] <awe_> ( ie. we added the -dbg package for ofono )
[23:02] <infinity> geofft: Though I'm firmly on the "source uploads forever" side of that debate too. :P
[23:02] <geofft> By asking folks to upload ddebs too?
[23:02] <cyphermox> I'll look, and apply the right thing if needed
[23:03] <infinity> geofft: They'd be an artifact of the build process and referenced in .changes, so nothing extra to do.  No different than a package that produces both debs and udebs today.
[23:04] <geofft> Neat.