[00:01] <doko> micahg, what do you mean to do about bug #838828?
[00:03] <micahg> doko: I think slytherin uploaded something for it, but I think it breaks for me, I think my initial assessment was correct, but have not had time to investigate
[00:04] <doko> micahg, ok, I'll remove it and let the report open
[00:04] <micahg> doko: I think you can safely remove it
[00:07] <doko> micahg, and while you are here ... NBS:
[00:08] <doko> flashplugin-nonfree
[00:08] <doko>    	flashplugin-nonfree-extrasound	multiverse	i386
[00:09]  * micahg looks that up on LP quick
 micahg, and while you are here ... NBS:
 flashplugin-nonfree
     flashplugin-nonfree-extrasound multiverse i386
[00:10] <doko_> * Disconnected (Connection reset by peer).
[00:11] <micahg> doko_: I don't think we need it, but it's in Debian, so should be removed only in concert with them, we dropped the transitional flashplugin-nonfree binary, so that needs to be transitioned to flashplugin-installer I think
[00:12] <micahg> doko: is that the only  NBS for that binary?
[00:13] <doko_> micahg, yes, see http://people.canonical.com/~ubuntu-archive/nbs.html
[00:15] <micahg> doko_: ok, we just need to transition to the new binary, I can do that tonight I guess
[04:03] <pitti> Good morning
[04:04] <pitti> apw: when do the 25% CPU happen of apport-gtk? while it's collecting data? or what does it do at that time?
[04:10] <micahg> pitti: could you give this back please: https://launchpad.net/ubuntu/+source/perl/5.12.4-4/+build/2768379 (doko requested it)
[04:10] <micahg> pitti: and good morning :)
[04:15] <pitti> micahg: done
[04:15] <micahg> pitti: thanks
[05:37] <didrocks> good morning
[05:39] <ScottK> didrocks: I assigned the Qt update to you in anticipation of you getting it packaged.
[05:40] <didrocks> Hey ScottK, it's packaged and in the ubuntu-desktop ppa since Monday. There are serious regression with unity-2d (they are fixing it for Thursday), so, I think pushing it at the same time. I asked for testing on #kubuntu-devel but got no feedback
[05:41] <ScottK> Yeah, we've been focused on KDE 4.7.1 packaging.
[05:41] <ScottK> That should get pushed today.
[05:41] <didrocks> oh nice :)
[05:42] <didrocks> ScottK: the ppa is there (ubuntu-desktop/ppa) if anyone wants to test, amd64 should be built as well now despite the mozilla jump on all available ppa builders :)
[07:15] <dholbach> good morning
[07:19] <madnick> morning
[07:42] <evfool> hi all, how is the power-and-settings indicator officially called?
[07:42] <evfool> what's the official name to use in docs?
[07:50] <FourDollars> Hi, I have a patch for the ibus-chewing package in main. Who can help me?
[07:50] <FourDollars> https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/843619
[07:51] <dholbach> FourDollars, if you subscribed ubuntu-sponsors you should be all set :)
[07:52] <FourDollars> dholbach: I just attach a patch file. Is it enough for ubuntu-sponsors ?
[07:52] <dholbach> yep, it should
[07:53] <dholbach> if the commit is upstream, it would help pointing out a reference to it
[07:53] <FourDollars> Thanks
[07:58] <brendand> has anyone else 'lost' their keyring in oneiric? I'm constantly being bothered by password prompts when ssh'ing
[08:08] <dholbach> FourDollars, was the patch already submitted/accepted upstream? do you know?
[08:09] <FourDollars> dholbach: I just submitted to upstream and wait for his merge or reject to improve.
[08:09] <dholbach> FourDollars, is this the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630331
[08:09] <dholbach> or is it slightly different?
[08:09] <FourDollars> dholbach: no
[08:09] <FourDollars> dholbach: It is different.
[08:09] <dholbach> ok - I was just wondering if this fix would be interesting for Ubuntu too
[08:10] <FourDollars> dholbach: There is another bug may be relative.
[08:10] <dholbach> FourDollars, if you have a link to where you submitted it upstream, could you add it to the bug report?
[08:10] <dholbach> ok
[08:10] <FourDollars> dholbach: https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/838643
[08:11] <FourDollars> dholbach: Could you see https://github.com/definite/ibus-chewing/pull/8 ?
[08:11] <dholbach> yes, thanks
[08:15] <dholbach> FourDollars, so it looks like Debian bug 630331, bug 843619 and bug 838643 would be good to get fixed in oneiric - is that right? if so, I could help put a package together and build it in ppa - could you test it afterwards, because I wouldn't know how to use it
[08:16] <FourDollars> dholbach: Yes. I think it is good to try.
[08:16] <dholbach> great
[08:16] <dholbach> FourDollars, I'll ping you when I uploaded it
[08:16] <FourDollars> dholbach: Roger that
[08:16] <FourDollars> dholbach: Thanks
[08:19] <sabdfl> pitti, any idea why aptitude can't find changelogs at the moment?
[08:19] <pitti> hey sabdfl
[08:19] <sabdfl> howdy :-)
[08:19] <pitti> sabdfl: uh, aptitude.. do you happen to know where it takes them from?
[08:20] <sabdfl> pitti, let me sniff some packetry
[08:20]  * pitti installs aptitude and learns how to use it
[08:20] <pitti> argh, my packages are broken right now, darn multiarch
[08:22] <pitti> sabdfl: just wonder whether it uses changelogs.u.c. properly
[08:22] <pitti> installing now
[08:23] <pitti> $ aptitude changelog gtk+3.0
[08:23] <pitti> Feh Changelog of gtk+3.0
[08:23] <pitti> E: Download des Changelog schlug fehl: Download queue destroyed.
[08:23] <pitti> E: Konnte kein Änderungsprotokoll für »gtk+3.0« finden
[08:23] <pitti> sabdfl: ^ something like this?
[08:23] <sabdfl> pitti, ed zachary, yes
[08:26] <pitti> hm, aptitude changelog gtk+2.0 tries to access http://changelogs.ubuntu.com/changelogs/pool/main/g/gtk+2.0/gtk+2.0_2.24.5-0ubuntu7/changelog, which does exist
[08:27] <pitti> sabdfl: hm, so no obvious reason, and I can't see an obvious failure from strace; so I guess this needs a more thorough gdb/code inspection session
[08:28] <pitti> apt-get changelog seems to work fine, and is pulling from the same server
[08:32] <pitti> seems someone already reported it as bug 824708
[08:33] <doko_> pitti, could you have a look at the libindicate ftbfs on powerpc?
[08:34] <pitti> doko_: very low-priority; I'll add it to my queue, but won't get to it this week
[08:36] <pitti> doko_: -pljava fixed, BTW
[08:36] <doko_> pitti, seen, thanks
[08:36]  * pitti does some further package updates and NBS cleanup
[08:45] <dholbach> FourDollars, https://launchpad.net/~dholbach/+archive/ppa/+builds?build_state=pending
[08:46] <dholbach> it will take a while for them to build, but if you could test and confirm they fix all the issues and you're happy with them, I can sponsor to oneiric
[08:50] <sabdfl> hi pitti, sorry i got disconnected, exploding X
[08:50] <FourDollars> dholbach: Thanks.
[08:54] <pitti> sabdfl: FYI, it is already reported as bug 824708
[09:04] <brendand> for some reason i didn't have gnome-keyring installed. guess i should have had...
[09:38] <cjwatson> @pilot in
[09:39] <Daviey> Good point.
[09:39] <Daviey> @pilot in
[09:52] <dholbach> yeeehaw
[09:53]  * dholbach hugs cjwatson and Daviey
[10:00] <doko> any cmake experts here? how do I convince cmake not to build with -O3, but -O2?
[10:00] <cjwatson> convert to autotools
[10:01]  * cjwatson runs
[10:02] <cjwatson> looks like possibly you need to prod CMAKE_C_FLAGS_RELEASE (guessing slightly)?
[10:02] <seb128> dholbach, half of the sponsoring queue is package importer merge requests
[10:03] <cjwatson> ./Modules/Compiler/GNU.cmake:31:  set(CMAKE_${lang}_FLAGS_RELEASE_INIT "-O3 -DNDEBUG")
[10:03] <seb128> including quite some weird ones with only .pc directory changes
[10:03] <seb128> doko, ask agateau maybe
[10:03] <seb128> he knows quite a bit about cmake ;-)
[10:03] <cjwatson> seb128: I can probably take a pass through those in a bit
[10:03] <agateau> seb128: sshhh don't tell anyone!
[10:03] <seb128> agateau, welcome back! ;-)
[10:04] <seb128> cjwatson, thanks, I'm still confused by things like https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/gnome-desktop3/oneiric-201109060812/+merge/74173 and why that happens
[10:04] <cjwatson> seb128: I have no intention of attempting to solve or even explain the general problem
[10:04] <cjwatson> but I can work through case-by-case
[10:04] <seb128> ok, fair enough ;-)
[10:07] <agateau> doko: the way to set build options with cmake depends on whether you are using a predefined build type
[10:07] <agateau> doko: do you set CMAKE_BUILD_TYPE to something like Release or MinSizeRel?
[10:10] <doko> agateau, I'm looking at insighttoolkit. it starts with -O2, but some/most submodules are built with -O3
[10:11] <agateau> doko: oh weird, maybe they are overriding the flags in the submodules?
[10:11] <doko> beware, the build system is insane, starts from scratch every time :-/
[10:11] <agateau> fun
[10:12] <agateau> downloading the src pkg (will take some time here)
[10:14] <pitti> ok, tbird ppc is building, that should fix the remaining NBS in main
[10:14]  * pitti removes the gnome-media stuff
[10:15] <cjwatson> NBS is almost looking sane!
[10:16] <pitti> mostly due to your heroic libav porting
[10:16] <doko> pitti, I know ... join the party to remove the gnome stuff in universe ;-P
[10:16] <pitti> wrt. indicator-applet, if DX doesn't get to porting that, we'll just remove it all
[10:16] <pitti> (I'd remove it either way, but they asked us to let them some more time)
[10:17] <pitti> doko: yep
[10:17] <pitti> all the old applets should go, I'll slaughter them
[10:17] <pitti> seb128: ^ ok?
[10:17] <pitti> seb128: i. e. everything on http://people.canonical.com/~ubuntu-archive/nbs.html which still depends on libpanel-applet2-0?
[10:18] <cjwatson> are all of those only applets, as opposed to packages which happen to ship an applet along with other stuff?
[10:18] <cjwatson> I saw some examples of the latter which were fixed in Debian by dropping the applet but keeping the other bits
[10:18] <pitti> the two that would be worth keeping are gnote and workrave, AFAICS
[10:18]  * cjwatson tries to figure out how to upload app-install-data-ubuntu in the absence of mvo
[10:18] <seb128> pitti, keep indicator-applet
[10:19] <seb128> pitti, I think ted had a version building, it just needs testing
[10:19] <pitti> seb128: yes, and I'd check if e. g. gnote/workrave have newer upstream versions
[10:19] <seb128> right
[10:19] <pitti> cjwatson: yeah, of course I'll check for new Debian versions first
[10:23] <doko>   * CMakeCache.txt.debian: Set CMAKE_BUILD_TYPE to "RELEASE" so that we
[10:23] <doko>     build with -O3 (not -O2), necessary to optimize the templated code.
[10:23] <doko> agateau, ^^^ :-/
[10:23] <doko> and RELEASE is supposed to build with -O3?
[10:24] <agateau> doko: you can define what RELEASE does
[10:24] <doko> hmm, old changelog entry, the file doesn't exist
[10:24] <seb128> pitti, verbiste-gnome is probably worth keeping as well in this list, should be possible to just turn the applet off for it
[10:25] <agateau> doko: I see one CMakeLists.txt which explicitly set -O3 for one file
[10:26] <agateau> doko: Utilities/vxl/core/vnl/tests/CMakeLists.txt
[10:26] <doko> agateau, right, but this looks like something for the tests
[10:27] <agateau> doko: anyway, you should be able to override things by setting CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to "-O2" I think
[10:28] <ogra_> phew ...
[10:29] <ogra_> when did we get .xz support in dpkg ... i just had to wait over 10min for "dpkg-source: info: unpacking ubiquity_2.7.27.tar.xz" on my armel install
[10:29] <agateau> I see quite a few CMake flags in debian/rules already, including one which sets CMAKE_CXX_FLAGS to -Wno-deprecated
[10:30] <agateau> doko: ^
[10:30] <cjwatson> ogra_: xz support for source packages was added in 1.15.5
[10:30] <doko> agateau, right, I see /usr/bin/g++   -DITKCommon_EXPORTS -Wno-deprecated  -Wno-deprecated  -ftemplate-depth-50 -Wall -Wno-deprecated -O3 -DNDEBUG -fPIC
[10:30] <cjwatson> and that routinely makes a difference to how quickly I can upload ubiquity, so ...
[10:31] <ogra_> well, since its only for source packages its fine, but its (very) noticeable slower
[10:31] <cjwatson> I suspect it's rather memory-dependent
[10:31] <doko> cjwatson, agateau: btw, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640214  I'm wondering how many packages just don't set the debian defaults, and build with undefined/default behaviour
[10:32] <ogra_> ah, that might be an issue here, 512M and no swap
[10:32] <cjwatson> perhaps you should do some benchmarking and contribute to the Debian discussion regarding using it for binaries
[10:32] <ogra_> (and lots of open apps)
[10:32] <cjwatson> (people have already suggested that that should be architecture-dependent, etc.)
[10:33] <cjwatson> doko: does dh get it right?
[10:33] <ogra_> yeah, if it goes into binary debs i fear that would kill some stuff here ... unpacking things like gnome-user-docs already take up to 20min to only unpack here
[10:33] <cjwatson> doko: ... doesn't appear so
[10:33] <doko> cjwatson, I probably should start with a smaller package ;-)
[10:34] <cjwatson> $ grep CMAKE /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm
[10:34] <cjwatson>         push @flags, "-DCMAKE_INSTALL_PREFIX=/usr";
[10:34] <cjwatson>         push @flags, "-DCMAKE_VERBOSE_MAKEFILE=ON";
[10:34] <ogra_> given the ratio i see for ubiquity (1-2min vs more than 10) that would put gnome-u-d to funny unpack times
[10:35] <doko> cjwatson, well, this one is cdbs
[10:35] <doko> cjwatson, ok, neither cdbs
[10:36] <agateau> doko: I would try to remove the line which sets the build type in debian/rules
[10:54] <pitti> seb128: oh, and gnome-desktop-sharp2, I'll try to just drop the panel bits there
[10:55] <agateau> I am still learning about multiarch, I (think I) converted two packages to multiarch, but would like to test it locally. Is there a simple way to build a i386 package from an amd64 machine?
[10:57] <Laney> pitti: please do that in exp if you can to save us doing it again
[10:57] <Laney> you should be able to write to pkg-cli-libs
[10:57] <pitti> Laney: ack
[10:57] <pitti> Laney: I'll finish the package removal fest first, though
[10:57] <Laney> sure
[10:57] <doko> I love debhelper not echoing the commands calling the upstream build system :-/
[10:59] <cjwatson> doko: DH_VERBOSE=1
[11:01] <cjwatson> agateau: proper multiarch cross-building is still in its early stages; I suggest http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#amd64i386
[11:01] <doko> cjwatson, right, hide it in the build logs \o/
[11:02] <agateau> cjwatson: ok thanks
[11:02] <cjwatson> doko: maybe the default verbosity for dh_auto_* should be adjusted
[11:03] <cjwatson> those are a bit different from the rest of dh_*
[11:07] <doko> agateau, removing the line in debian/rules was the right hint. I'll do that for non ix86
[11:08] <agateau> doko: good news!
[11:08] <doko> agateau, however, some subprojects are now built *without* optimization
[11:10] <Daviey> Seriously, how can vnc4 really have an uncompressed 170MB source..
[11:10] <pitti> lamont: do you know what's up with dubnium? It's sitting in "almost finished" state like https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2770676 for over an hour
[11:13] <agateau> doko: there is some ugly CMAKE_*_FLAGS manipulation in Utilities/vxl/core/vnl/algo/tests/CMakeLists.txt (line 107) I wonder if it can affect the whole project or at least other modules
[11:14] <agateau> doko: it is supposed to only happen for gcc 2.95, but I would check nevertheless if you get there
[11:16] <Daviey> pitti: I assume you agree with bug 828537 ?
[11:17] <agateau> doko: you can do printf-like debugging with cmake with the message() function.  I would add a few `message("CMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}")` in that CMakeLists.txt
[11:18] <pitti> Daviey: yep, will do
[11:19] <doko> agateau, cjwatson: passing -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo does work for me. so it looks like this should be passed by default in debhelper/cdbs
[11:19] <agateau> makes sense to me
[11:21] <cjwatson> can we just do that case-by-case for oneiric where it's needed, and file upstream debhelper/cdbs bugs with the aim of changing that across the board for P?
[11:22] <cjwatson> sabdfl: I hope we're getting a name for P soon; we could do with encoding the name in a few places :)
[11:25] <doko> heh, it has to be a Python ;-)
[11:26] <doko> cjwatson, yes, that's my plan, didn't want to change it for oneiric
[11:28] <pitti> seb128: keeping verbiste then; no rdepends, so easy to kill, but if you want to work on it, I'll keep it for a while
[11:29] <pitti> I now went through the old applet rdepends, and removed most of them; I'll work on the others after lunch
[11:29] <seb128> pitti, I don't "want" to work on it, I just said we shouldn't kick it out because the applet is broken
[11:29] <pitti> seb128: *nod* the stuff that I removed were pure applets
[11:30] <seb128> it has a --with-gnome-applet configure flag
[11:30] <seb128> so should be trivial to turn the applet off
[11:59] <debfx> cjwatson: in your mail about data.tar.xz you mentioned that it requires a Pre-Depends on dpkg. what about packages synced from Debian? I hope we don't need to change them.
[12:10] <doko> cjwatson, agateau: so setting CMAKE_BUILD_TYPE seems to be always wrong. using RELEASE, you get no debug info, and with RelWithDebInfo, the flags passed by dpkg-buildflags are overwritten with the hard-coded default in cmake
[12:11] <cjwatson> debfx: IMO dak should be fixed to require that too
[12:12] <cjwatson> unless they've explicitly decided not to since squeeze had the requisite version, I guess
[12:13] <cjwatson> debfx: but lucid doesn't have dpkg 1.15.6, so we have to do this at least until P releases because otherwise we'll cause failures for direct upgrades from lucid to P
[12:13] <cjwatson> debfx: after P releases, I would be willing to drop that check in LP
[12:22] <debfx> ok, in that case let's hope not too many maintainers decide to use xz compression
[12:24] <cjwatson> debfx: a Pre-Depends for a while might not be too hard a sell, at least for those who are receptive to Ubuntu
[12:35] <pitti> seb128: verbiste fix uploaded, FYI
[12:42] <pitti> Laney: do you want me to create an experimental branch for this, or drop it in unstable? NB that in Debian, gnome-panel 3 is still in experimental
[12:42] <pitti> Laney: there are two rdeps, tomboy and drapes; tomboy is fixed in ubuntu
[12:42] <Laney> pitti: in experimental, yeah. Tomboy is fixed in exp too; I'll look at drapes soon (but probably remove it, seems pretty dead)
[12:43] <Laney> if you do it in exp then we can just reupload to unstable when gnome-panel 3 goes
[12:44] <pitti> Laney: want me to create a new experimental branch for this, or just use master?
[12:44] <pitti> I suppose master is fine
[12:44] <pitti> this isn't likely to get another unstable upload anyway, last one was from April 2010
[12:44] <Laney> yeah, doubt it'll see an upload to unstable before then
[12:45] <Laney> there's a bts bug you can close with the upload
[12:45] <pitti> Laney: oh, handy
[12:45] <Laney> good old joss
[12:46] <pitti> yep, doing
[12:46] <Laney> cheers
[12:48] <pitti> Laney: I'm not an uploader, can you upload once I'm one, or want me to mark this as an SRU?
[12:48] <pitti> sorry, NMU
[12:48] <pitti> too many TLAs
[12:48] <Laney> personally don't care if you do it as a maintainer upload
[12:48] <pitti> ok
[12:49] <Laney> part of the reason we allow all DDs write access to the branches
[12:52]  * pitti sighs and installs 171 packages worth of build deps
[12:52] <Laney> it's also why mono is small on the CD :P
[12:53] <pitti> yeah, it's just 30 MB, so not too bad
[12:53] <Laney> (doesn't take much time with a tmpfs overlay for me)
[12:54] <pitti> Laney: oh, this isn't using git-buildpackage?
[12:54] <pitti> at least gbp acts strangely
[12:55] <Laney> yes, it should be
[12:55] <Laney> did you branch upstream and pristine-tar?
[12:56] <pitti> ah, sorry
[12:56] <pitti> but still acting up
[12:57] <pitti> no matter, I'll build it in-tree
[12:58] <jdstrand> dholbach: hi! I need to reschedule my patch pilot today-- several items came up and I don't have enough hours in this day to do it
[12:58] <Laney> erk
[12:58] <directhex> is there a way to do a build of mono on one of the ubuntu buildds without affecting the package currently published for oneiric? upstream have given us a possible fix for the "doesn't build on vernadsky" problem we were having with epoll, but the only machines where it always failed were ubuntu buildds
[12:58] <dholbach> jdstrand, sure, just move it to some other day that's better in the calendar
[12:59] <Laney> pitti: looks like I forgot to push the changelog for -4, give me a second
[12:59] <pitti> Laney: now, that's working nicely
[12:59] <pitti> Laney: ah, just in time
[12:59] <pitti> I'll rebase then
[13:00] <Laney> weird, I even tagged it
[13:00] <Laney> sigh
[13:00] <jdstrand> dholbach: ok thanks. I moved it to next wednesday since this week seems pretty full already
[13:01] <dholbach> jdstrand, whenever is good for you
[13:01] <Laney> what in the world
[13:04] <Laney> pitti: all yours
[13:04] <pitti> Laney: cheers, rebased
[13:11] <pitti> Laney: still a miracle how to build a clean source package -- it always deletes Makefile.in files, even with git-buildpackage -S -us -uc -nc
[13:11] <pitti> regardless of how I build this, it alwasy complains about local changes
[13:12] <pitti> I guess the clean rule gets in the way
[13:12] <Laney> yeah, debian/rules there is pretty ancient
[13:12] <pitti> ah, found a workaround, nevermind
[13:12] <Laney> could do with some dh-autoreconf love at least
[13:14] <pitti> 15998 2011-07-13 14:06 gnome-desktop-sharp2_2.26.0-4.diff.gz
[13:14] <pitti> 15598 2011-09-07 15:13 gnome-desktop-sharp2_2.26.0-5.diff.gz
[13:14] <pitti> wow!
[13:14] <pitti> I managed to remove and add exactly the same number of bytes :)
[13:15] <__z0rt__> in the hundreds column?
[13:15] <pitti> Laney: uploaded/pushed
[13:15] <Laney> great, thanks a lot!
[13:16] <Laney> drapes has a large-ish popcon, i wonder how useful it is without the applet
[13:16] <sabdfl> cjwatson, tell me about it, looks like the longest section in the darn dictionary!
[13:17] <sabdfl> pitti, thanks for the digging, sounds like it's aptitude-specific and not related to our processes
[13:17] <sabdfl> does soyuz publish changelogs now when it publishes packages, or is this still an out of band process?
[13:17] <pitti> sabdfl: yes, it is
[13:18] <pitti> sabdfl: LP has done something like that for quite a while now
[13:18] <sabdfl> i ask because I'm usually most interested in the changelogs for recently updated packages, which are often not yet published
[13:18] <pitti> https://launchpad.net/ubuntu/+source/gtk%2B3.0/+changelog
[13:18] <sabdfl> oh, it is now?
[13:18] <sabdfl> but that's not where apt-get or aptitude look, is it?
[13:18] <pitti> but it's not a pure changelog, and invokes quite a lot of backend processing
[13:18] <pitti> i. e. not just a flat file like changelogs.u.c. is
[13:18] <sabdfl> i don't see why soyuz couldn't produce changelogs.u.c (and do the same for ppa's)
[13:18] <pitti> sabdfl: right, apt-get/update-manager use changelogs.u.c., as these are plain files and thus scale better
[13:19] <sabdfl> and also, why the archive metadata couldn't tell apt/aptitude where to find the cl's
[13:19] <pitti> sabdfl: nothing stopping it in theory
[13:19] <cjwatson> sabdfl: I think wgrant was talking about simplifying +changelog now that the full changelog is in the librarian
[13:20] <sabdfl> that would be great, could even be a redirect
[13:20] <sabdfl> wgrant, what say you to ^?
[13:20] <sabdfl> ppa changelogs would be excellent
[13:23] <wgrant> sabdfl: As of Lucid, update-manager looks in the archive for changelogs and not just on changelogs.u.c, so third-party archives can provide them.
[13:23] <wgrant> My intention was to implement this in Soyuz a year ago, but it turned out to be harder than expected to remove them when the sources were removed.
[13:23] <wgrant> Due to the way pools are divided by component.
[13:23] <sabdfl> ah
[13:23] <wgrant> And then I got hired before solving that.
[13:23] <sabdfl> heh
[13:24] <wgrant> But we have all the changelogs in the librarian now, so we can display them in the web UI easily.
[13:24] <sabdfl> we have an easy way to write files, not to rm them?
[13:24] <sabdfl> i'm more interested in helping apt / aptitude get them right now
[13:24] <wgrant> And once someone works out how to keep them in the right component on the archive disk, we can publish them to update-manager.
[13:24] <sabdfl> changelogs.ubuntu.com could in theory redirect, couldn't it?
[13:25] <wgrant> changelogs.ubuntu.com is a bit of a special case. It could probably redirect, yes.
[13:25] <wgrant> Not sure how much update-manager would like that, though.
[13:25] <wgrant> It may be better to make the update process cheaper, and run it regularly as an LP API client.
[13:26] <wgrant> Since it should just have to watch for recent source publications, and pull down their changelogs.
[13:26] <wgrant> Pretty trivially cheap.
[13:26] <wgrant> I'm not sure the LP API exposes changelogs easily yet, but that's literally a 2-line fix.
[13:32] <__z0rt__> I'm not really new to c coding for the linux platform, per se, but I mainly *worked* with unix. So, I was wondering... is there something similar to fbsd's style (indent guide) for ubuntu?
[13:34] <pitti> doko: I'm confused by https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/840611/comments/1, seems the packages weren't actually removed?
[13:35] <doko> pitti, I just removed the binaries
[13:35] <pitti> ah
[13:41] <cjwatson> __z0rt__: Ubuntu is made up of many packages, and each one tends to have its own preferred style
[13:41] <cjwatson> __z0rt__: it's much more important to adhere to the prevailing style of the code you're editing
[13:41] <__z0rt__> ah, okay. thank you
[13:45] <smoser> kees, if you would, https://code.launchpad.net/~smoser/ubuntu/oneiric/nagios-plugins/lp837085/+merge/74309 nagios-plugins is ready.
[13:47] <cjwatson> @pilot out
[13:54] <apw> pitti, i think what was happening was apport-gtk was crashing while trying to handle a crash
[13:54] <apw> and we were going into a repeated cycle of that, with a new apport-gtk appearing repeatedly (differnt pids)
[13:54] <pitti> apw: can you reproduce this when you run "apport-bug /var/crash/something"? do you get a stack trace on stdout?
[13:55]  * apw will see whats in there
[13:55] <apw> _usr_share_apport_apport-gtk.1000.crash .. i see i have an apport-gtk crash in ther
[13:55] <apw> that seems 'bad'
[13:55] <pitti> apw: can you pastebin the file? (or put on people etc.)
[13:56] <apw> pitti, http://paste.ubuntu.com/684418/
[13:57] <pitti> apw: hm, I fixed that yesterday -- what's yoru apport-gtk version?
[14:12] <jtaylor> what does nbs stand for?
[14:13] <pitti> jtaylor: "not built from source"
[14:13] <pitti> i. e. a binary that is not built by anything
[14:13] <pitti> usually old libraries or renamed packages
[14:13] <jtaylor> ah ok, thx
[14:28] <Daviey> @pilot out
[14:36] <pitti> cjwatson: do you think there's a realistic chance to fix gnash on armel, or sohuld we just remove the armel binaries?
[14:37] <pitti> cjwatson: it seems to be the last rdepends of a whole lot of libav NBS stuff
[14:38] <cjwatson> pitti: http://irclogs.ubuntu.com/2011/09/05/%23ubuntu-devel.html#t11:33 and http://irclogs.ubuntu.com/2011/09/05/%23ubuntu-devel.html#t16:24
[14:39] <pitti> ah, thanks
[14:41] <micahg> if someone feels it's pressing, please feel free to merge gnash, otherwise, I'll take care of it as soon as I have some time (when out of crisis mode)
[14:41] <micahg> it might need an FFe as it's a new version, but should be easy to get approval
[14:41] <pitti> yeah, it's easy enough to test
[14:41] <pitti> micahg: not super-urgent, no
[14:42] <pitti> thanks
[15:07] <seb128> re
[15:07] <seb128> pitti, thanks
[15:27] <ahasenack> hi, can someone please nominate https://bugs.launchpad.net/ubuntu/+source/smart/+bug/244453 for lucid, maverick and natty? I added the SRU request to the bug and 3 debdiff files, one for each distro
[15:27] <ahasenack> it's fixed in oneiric already
[15:28] <stgraber> ahasenack: done
[15:28] <ahasenack> stgraber: thanks!
[15:30] <seb128> cjwatson, pitti, Laney: but the glib multiarch bug has been dupped from bug #835625
[15:30] <seb128> just for info
[15:31] <Laney> ah, cheers
[15:32] <seb128> -but
[16:00] <tedg> Howdy, trying to get flash installed and it's not handling the multi-arch stuff.
[16:00] <tedg> Which I heard was supposed to be fixed now.
[16:00] <tedg> It seems to not go down the stack to install all the i386 libs.
[16:01] <tedg> Is there anything I should try/get debug info?
[16:11] <kees> smoser: hi! okay, looking at it now
[16:13] <dholbach> Ursinha-holiday, enjoy!
[16:37] <muneeb> which app is used to draw these kind of mockups? https://wiki.ubuntu.com/NotifyOSD?action=AttachFile&do=get&target=fallback-alert-mixed.jpg
[16:41] <jcastro> muneeb: those are drawn by hand
[16:53] <bdmurray> pitti: I'd like to add in the version of apport being used to apport bug reports do you have any preference as to where this happens?  The ubuntu general hook or the generic one?
[17:09] <bdmurray> james_w: Do you happen to have a bzr plugin to modify a bug upon a cmmit?
[17:09] <bdmurray> er commit
[17:09] <james_w> bdmurray, I do not
[17:09] <james_w> bdmurray, like set it fix committed or similar?
[17:09] <bdmurray> james_w: well I want one to modify tags and remove a subscriber but yeah
[17:10] <james_w> I don't know of such a thing, sorry
[17:10] <james_w> how would it know which bug to modify?
[17:11] <bdmurray> It'd be in the commit message
[17:11] <bdmurray> or in the diff of the file I'm committing
[17:11] <bdmurray> the latter makes more sense
[17:14] <james_w> bdmurray, the post_commit hook point is likely what you would want. I'm not sure how to look at the diff given what is passed to it, but once you have that the rest should be straightforward if you want to give it a go
[17:14] <bdmurray> james_w: thanks
[17:16] <james_w> it's likely that you would have to generate the diff between the tree you get as an argument and its parent
[17:26] <shnatsel|busy> hello everybody
[17:26] <shnatsel|busy> I'm having trouble with Germinate again
[17:27] <shnatsel|busy> I get "Permission denied (publickey)." error on remote branch checkout, whatever I try. I've managed to work that around using a local branch, but now it attempts to read "platform.oneiric" branch from the same location and can't find it.
[17:28] <shnatsel|busy> man germinate doesn't mention any platforms
[17:28] <shnatsel|busy> neither does the ubuntu-meta package
[17:32] <Chipzz> shnatsel|busy: "Permission denied (publickey)." looks like an SSH error message. The problem very likely is that either a) you simply are not allowed access to the remote server or b) your key isn't properly loaded
[17:37] <infinity> shnatsel|busy: As a quick workaround, you could branch platform.oneiric locally too, but it sounds like it's trying to get a r/w lock on the remote, which you quite likely don't have access to do.  bzr misconfiguration or some such?
[17:38] <shnatsel|busy> Chipzz, infinity: yeah I tried all that, I'm OK with a local branch for now. I'm more concerned about the platform.oneiric thing that seems to be undocumented but required.
[17:39] <infinity> shnatsel|busy: It's just a branch sitting next to ubuntu.oneiric.
[17:39] <shnatsel|busy> infinity: yeah I see, what should it contain?
[17:39] <infinity> shnatsel|busy: ubuntu/xubuntu/kubuntu all depend on it, STRUCTURE defines this.
[17:40] <infinity> shnatsel|busy: It just contains.. More seeds.  Common seeds, so we don't have to change things in 3 places.
[17:40] <shnatsel|busy> yeah, it's looking for STRUCTURE in that branch too...
[17:40] <shnatsel|busy> infinity: OMG
[17:40] <shnatsel|busy> infinity: thanks
[17:51] <shnatsel|busy> huh, I can't even branch  bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.oneiric
[17:51] <shnatsel|busy> same "Permission denied (publickey)."
[17:57] <shnatsel|busy> removing "+ssh" returns timeout error
[18:08] <shnatsel|busy> oh, it's Launchpad. lp: should do it.
[18:08] <infinity> shnatsel|busy: The pubkey denial sounds like your default ssh key is one that LP isn't fond of.  You could just branch over http.
[18:09] <shnatsel|busy> yep, LP did it
[18:09] <shnatsel|busy> infinity: I'm now using 100% clean fresh Ubuntu Oneiric daily
[18:16] <Seq> jdstrand: Thanks for fixing #843552! I reported it at about 0200 local time and was going to submit a patch today after work. You're very speedy.
[18:34] <jdstrand> Seq: :)
[18:57] <shnatsel|busy> hmmm, OK finally I made some seeds work
[18:57] <shnatsel|busy> only locally though
[18:58] <shnatsel|busy> bazaar's SSH drives me nuts
[18:59] <cjwatson> shnatsel|busy: have you (a) run 'bzr launchpad-login' (b) set up ~/.ssh/config appropriately?  https://help.launchpad.net/Code/UploadingABranch has instructions
[18:59] <cjwatson> set this up correctly once and you should not need to do it again
[19:00] <shnatsel|busy> cjwatson: I had a valid LP login, it didn't help
[19:00] <cjwatson> shnatsel|busy: have you specifically done both of the two operations I listed above?
[19:00] <shnatsel|busy> cjwatson: I removed my LP login, it didn't help either
[19:03] <cjwatson> I expect that your local username differs from your Launchpad username, and that you need to tell ~/.ssh/config about this.  As I say, instructions in the URL above.
[19:03] <shnatsel|busy> cjwatson: I have a complex setup so I won't bother you with the details; I think I have enough info to deal with that now. Thanks for your help!
[19:03] <cjwatson> (Either that, or multiple public keys and it's using the wrong one, or you haven't uploaded your public key(s) to Launchpad.)
[19:04] <cjwatson> If it helps decouple things from bzr in your head, your system ought to be set up such that 'sftp bazaar.launchpad.net' works.
[19:25] <hallyn> oneiric i386, when doing apt-get update (well it was a new install) i get Hash Sum Mismatch
[19:26] <hallyn> then i can't install anything (pastebinit, openssh-server, etc)
[19:36] <Daviey> hallyn: I think there is an issue with the archive atm.. it's been update-in-progres for hours
[19:36] <Daviey> hallyn: I threw "91.189.92.170 archive.ubuntu.com" in my hosts which looks like a good mirror atm
[19:36] <Daviey> (part of the a.u.c RR)
[19:37] <hallyn> Daviey: thx!
[20:05] <hallyn> Daviey: (that actually didn't work for me;  hope that'll get fixed soon)
[20:14] <Daviey> hallyn: :(, sorry.