[03:21] <ilim> Hey, I would like to learn how I may contribute to the development of Ubuntu. I have some experience in C and C++ programming and I would like to be a part of Ubuntu community. Any advices where to start? (apologies if the channel is unrelated, but this was the only one that seemed relevant)
[03:27] <porthose> ilim, https://wiki.ubuntu.com/MOTU/Contributing
[06:07] <pitti> Good morning
[06:07] <pitti> smoser: ok
[06:41] <pitti> wendar: hi! do you intend to draft https://blueprints.launchpad.net/ubuntu/+spec/appdevs-desktop-n-app-sandbox still, or was this absorbed by something else or postponed?
[07:22] <acbot_> guys is this the channel for asking why the ubuntu one plugin for rhythmbox connects to a korean IP address over http to a password POST form?
[07:22] <acbot_> if not pls point me to the right place
[07:26] <hyperair> try #ubuntuone
[07:26] <hyperair> acbot_: could you give me the ip address?
[07:27] <acbot_> hyperair, 119.31.248.90
[07:28] <hyperair> hmm
[07:28] <acbot_> pretty damn dodgy if you ask me
[07:28] <hyperair> it is pretty dodgy
[07:29] <hyperair> there's no reverse lookup
[07:29] <acbot_> unless canonical moved to korean
[07:29] <acbot_> korea*
[07:29] <hyperair> nah, one.ubuntu.com resolves to a GB address.
[07:29] <acbot_> yeh no doubt
[07:31] <hyperair> acbot_: yeah so drop by #ubuntuone and ask
[07:34] <acbot_> yeh have done.. thanks.. no reply :(
[07:34] <ebroder> acbot_: It's early morning in Europe and late evening in the US. Be patient
[07:37] <hyperair> acbot_: are you sure it's the rhythmbox plugin doing it, though?
[07:39] <acbot_> hyperair.. 100%
[07:40] <hyperair> acbot_: how did you check?
[07:41] <acbot_> hyperair netstat with the plugin on/off shows that it makes the connection when plugin is on and not when plugin is off
[07:41] <acbot_> can reproduce on multiple machines
[07:42] <hyperair> acbot_: try netstat -anp to get the pid
[07:42] <hyperair> acbot_: and get a tcpdump of the communication
[07:44] <acbot_> hyperair.. yeh speaking to someone in ubuntuone now
[08:25] <dholbach> good morning!
[08:33] <mvo> hey dholbach
[08:33] <dholbach> hey mvo
[08:56] <dholbach> what could be the reason that I have a scp command sitting at "channel 0: open confirm rwindow 0 rmax 32768" for ages and not doing anything? :)
[09:27] <Daviey> @pilot in
[09:29] <dholbach> yeeeehaw
[09:29]  * dholbach hugs Daviey
[09:29] <Daviey> heh
[09:31] <lucas_> hi
[09:31] <lucas_> could someone take care of commenting on debian-devel@ about the major reasons for FTBFS in Ubuntu in my latest rebuild? (like: what is different in Ubuntu and could cause failures)
[09:35] <Daviey> lucas_: We are seeing many FTBFS due to the toolchain changes in natty, is that likely the cause?
[09:36] <Daviey> lucas_: A few packages i've worked on have been bitten by the linking behaviour change -  https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-October/000772.html
[09:36] <lucas_> Daviey: possibly ; it would be great if someone could summarize the common causes for the Debian community as well
[09:37] <Daviey> lucas_: doko_ would be the best person to comment i think.
[10:14] <beerpages> Schaut mal auf www.beerpages.de vorbei, dort könnt ihr eigene Umfragen erstellen - Beispiel: http://www.beerpages.de/view/1K/Was%20sagt%20ihr%20zum%20Thema%20Anal-SEX%3F
[10:15] <cjwatson> lucas_: have you already seen http://wiki.debian.org/ToolChain/DSOLinking?
[10:16] <lucas_> cjwatson: yup, saw it, thanks; it was linked from doko's u-d-a email
[10:45] <philbull> Hi guys, I'm at the GNOME DevDocTools hackfest in Berlin
[10:46] <philbull> We're talking about Anjuta and packaging
[10:46] <philbull> It'd be nice to have Anjuta be able to easily build DEBs
[10:47] <philbull> Is anyone familiar with packaging? Can we talk?
[10:47] <Daviey> rsalveti: Hi, can you comment on https://code.launchpad.net/~rsalveti/ubuntu/maverick/ureadahead/fix-600359/+merge/32955 please?
[10:48] <rsalveti> Daviey: sure, don't need it anymore, we can remove the request
[10:49] <Daviey> rsalveti: thanks!
[10:49] <Daviey> (updated)
[10:49] <rsalveti> thanks
[10:52] <Daviey> dholbach: Should bugs such as bug #36812, really show on the sponsoring queue?
[10:52] <Daviey> seems like have a patch attached to bug #1, and asking for sponsorship :)
[10:56] <dholbach> Daviey, seems like http://launchpadlibrarian.net/38870942/switch_on_release.diff is up for sponsoring?
[10:58] <Daviey> dholbach: Yeah, that patch has been there since Feb
[11:00] <dholbach> I can't comment on the patch :)
[11:01] <dholbach> Daviey, if nobody can comment it might be worth waiting for the upstream go-ahead
[11:01] <Daviey> Anyone from Desktop able to update that bug, to see if it is suitable for Natty please?
[11:01] <Daviey> dholbach: ack
[11:01] <dholbach> RAOF, bryceh, tjaalton probably
[11:18] <bryceh> dholbach, Daviey, NFI.  Sending upstream not a bad idea.
[11:21] <bryceh> Daviey, fwiw, most of the X.org patches in the sponsor queue I'm not really sure how we should handle them.  Many of them yeah probably should just go upstream.  Others could use some review on our end.
[11:23] <bryceh> pre-pilots, I'd usually just forward Xorg patches upstream if it wasn't obvious.
[11:24] <jdstrand> @pilot in
[11:25]  * dholbach hugs jdstrand
[11:25] <jdstrand> dholbach: thanks for the reminder-- I didn't see that the schedule changed for me
[11:25] <dholbach> it did?
[11:26] <jdstrand> dholbach: yes, I was last friday (but on vacation)
[11:26] <dholbach> ehhhhh?
[11:26] <jdstrand> dholbach: that got moved to today apparently (see December)
[11:27]  * jdstrand subscribes to https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews so there will be no surprises
[11:28] <dholbach> it's a bit hard to triage the schedule history now
[11:28] <dholbach> but it seems that daviey and you have been on the same day for quite a while now
[11:28] <dholbach> hm
[11:28] <jdstrand> I'm not complaining. I just didn't know I was on today
[11:28]  * dholbach hugs jdstrand
[11:28] <dholbach> glad it still works out :)
[11:29] <jdstrand> I also haven't looked at the schedule for a few weeks (not since the december canonical holidays were worked out)
[11:36] <bryceh> Daviey, jdstrand, sorry a lot of the remaining X.org patches are not obvious what to do with them (the obvious ones I already did 'cause they're easy)
[11:37] <Daviey> bryceh: yeah... i totally understand the position.  We don't want them lingering in the queue, but equally, i appreciate you want them upstream first.
[11:38] <bryceh> Daviey, jdstrand, fortunately many are pretty straightforward once you study them a bit.  Of course "study" can take time...
[11:38] <cjwatson> lool: bug 669361 seems to be unblocked now ...?
[11:39] <bryceh> Daviey, jdstrand, if nothing else, if you can just review all the comments and summarize the current status and next-step-action, that can be a big help
[11:40] <Daviey> bryceh: yeah, i just sent a request to the upstream bug tracker asking for an update.... been ~2 months since the last comment
[11:40]  * jdstrand looks at bug #682549 first
[11:41] <Daviey> jdstrand: Actually, i might ask you to sponsor a security upload to Maverick later today :)
[11:42] <bryceh> Daviey, yeah sad there's so many bugs in that state
[11:42] <jdstrand> Daviey: in what? is it what we have already been coordinating in email?
[11:42] <Daviey> jdstrand: yes
[11:43] <jdstrand> Daviey: ok. depending on when that hits, that isn't patch piloty, so anyone on the ubuntu-security team can do it (and kees is off today)
[11:43] <Daviey> jdstrand: ack
[11:43] <jdstrand> (I think most correspondence was with kees prior to today)
[11:44] <jdstrand> kees: you stay away-- you're on holiday! :)
[11:55] <doko> lucas_, Daviey: any special/new build failure?
[11:58] <Daviey> doko: I know of 3 that have been resolved, one of the ones i dealt with was because it was using libssl rather than openssl... libssl worked with Debian, but failed to link due to DSO..  Fixed upstream now.
[11:59] <Daviey> bryceh: would you be available to sponsor https://code.launchpad.net/~james-page/ubuntu/natty/xorg-docs/fix-682621/+merge/42214 please?
[12:11] <lucas_> doko: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[12:15] <doko> lucas_: did you investigate failures such as apport's that's unreproducible
[12:17] <lucas_> doko: not at all
[12:18] <lucas_> doko: given that it failed twice on both i386 and amd64, it's reproducible at least by me ;)
[12:18] <ScottK> doko: Now that Alpha 1 is out, would it be possible to get gcc-4.5 to default to "-fno-strict-volatile-bitfields" for now (as it did until the most recent Linaro update) so we can at least get arm built for Qt/KDE.  I don't see a lot of action upstream and I'd prefer to get moving forward.
[12:18] <doko> lucas_: but neither by pitti, me, nor on the ubuntu test rebuilds ...
[12:19] <lucas_> doko: could you diff your log with mine to see if something interesting shows up?
[12:19] <Daviey> cjwatson: I noticed you proposed the fix for update-inetd on Debian, would you be comfortable sponsoring a Lucid SRU for the same... https://code.launchpad.net/~broder/ubuntu/lucid/update-inetd/fix-601732/+merge/40737  Thanks :)
[12:21] <doko> ScottK: why? is debian/patches/revert-issue1259.diff not enough?
[12:21]  * ScottK looks
[12:25] <ScottK> doko: It probably is.  We had no idea you'd done that.  In the future, debian/changelog entries slightly less opaque than "  * Revert Linaro issue #1259." would be helpful (I had actually read the changelog when you uploaded it).
[12:25] <cjwatson> Daviey: I already di
[12:25] <cjwatson> d
[12:25]  * ScottK will retry Qt and see what happens.
[12:25] <cjwatson> Daviey: it's waiting in the lucid-proposed unapproved queue
[12:26] <ScottK> Retried.
[12:27] <Daviey> cjwatson: Dammit... i was just looking at the queue for another package, and that one didn't jump at me... whoops
[12:28] <Daviey> dholbach: Some feedback, it would be nice if the sponsoring queue checked the archive queue (NEW and Unapproved) to see if it exists.
[12:29] <Daviey> would make patch pilot task easier IMO.
[12:29] <doko> lucas: is ruby1.9 now the preferred version?
[12:30] <lucas> doko: no
[12:30] <lucas> doko: the upstream community is slowly moving to 1.9 as recommended version. but there's still quite a lot of work to do
[12:31] <doko> lucas: just looking at xapian-bindings ... so I'll have to disable the 1.9 part
[12:31] <lucas> doko: I will try to work on improving support for multiple ruby versions early in the wheezy cycle, but I have been having limited free time lately
[12:32] <lucas> it's probably wise to disable 1.9 bindings when they cause problems
[12:32] <doko> not in main ...
[12:33] <lucas> ah right
[12:38] <ScottK> doko: Since that's apparently sorted, on to different symbols per arch on many C++ packages.  See kdegraphics for an example - They are different on i386, amd64, and powerpc.  This doesn't seem helpful.
[12:38] <ScottK> It'll require test building on all archs before upload to get the symbols files right.
[12:39] <doko> somebody wanted to submit a bug report for this. is the symbol generation changed?
[12:45] <ScottK> The results are different.  I can submit a bug.
[12:50] <jdstrand> lool: hi! I'm hitting http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602571. I know you fixed natty's build-essential but that obviously doesn't work for older releases (eg for security updates and SRU). What do you think of this debdiff: http://paste.ubuntu.com/539375/ . It just removes 'sysvinit' from the list of packages if this is an Ubuntu chroot
[12:52] <fta> pitti, mvo: hi, I found the problem with update-apt-xapian-index (bug 669430), it's the libqt4-dev-dbgsym entry in the ddebs.u.c Packages file (it's corrupted)
[12:53] <doko> TheMuso: is #615187 still needed? I don't see it in component-mismatches
[12:54] <pitti> fta: oh, thanks! I'll have a look at this then
[12:55] <lool> cjwatson: I think I committed a fix for LP #669361 in the eglibc UDD bzr branch
[12:55] <lool> cjwatson: So with a new eglibc upload, it should be fixed
[12:56] <lool> cjwatson:     - Remove manpages now provided by manpages-dev; Debian #595194);
[12:56] <lool>       LP: #669361.
[13:02] <doko> mterry: ahh ... cheetah was merged without looking at python-markdown (universe) ...
[13:04] <mvo> thanks fta
[13:09] <mterry> doko, yeah, got your email. my bad.  will look at it
[13:13] <ScottK> doko: Bug #684703 filed.
[13:17] <doko> ScottK: are these different symbols, when built in maverick?
[13:17] <ScottK> doko: That package had all the same symbols on different archs in Maverick.  It's a different version of the package though.
[13:18] <ScottK> We have that in a PPA for Maverick, let me double check.
[13:18] <doko> ScottK: same version?
[13:18] <ScottK> in the PPA, yes
[13:18] <doko> and thanks for the reduced testcase :-/
[13:19] <ScottK> doko: Same package on maverick in PPA: http://launchpadlibrarian.net/59837989/buildlog_ubuntu-maverick-amd64.kdegraphics_4:4.5.80-0ubuntu1~maverick1~ppa1_BUILDING.txt.gz
[13:20] <ScottK> (no symbol diff on amd64)
[13:28] <jdstrand> dholbach: looking at bug #626352, I noticed it is still in the http://reports.qa.ubuntu.com/reports/sponsoring/index.html, presumably because ubuntu-main-sponsors is subscribed. they should not be based on comment #7. I am not a member of ubuntu-main-sponsors-- is this something you can do?
[13:34] <dholbach> jdstrand: done - I'll have a look at all the others where the team is subscribed
[13:34] <jdstrand> dholbach: thanks!
[13:42] <jdstrand> dholbach: question for you-- https://code.launchpad.net/~bilalakhtar/nautilus-sendto/ubuntugtk3-update/+merge/42602 is marked as needingreview from the Ubuntu Sponsors Team, but it says very clearly in the 'Description of the Change' that it is not intended for Ubuntu, only the GNOME3 PPA.
[13:43] <jdstrand> dholbach: I'd like to unsubscribe ubuntu-sponsors from the merge, but I don't see how to do that. is it possible?
[13:43] <jdstrand> (trying to clean up the http://reports.qa.ubuntu.com/reports/sponsoring/index.html list if you can't tell :)
[13:44] <dholbach> james_w, didrocks: ^
[13:44] <jdstrand> dholbach: if we can't unsubscribe ubuntu-sponsors, I'll just leave a note
[13:45] <dholbach> jdstrand: I have no idea
[13:45] <jdstrand> dholbach: ok, maybe who you pinged will. thanks!
[13:46] <dholbach> thank you
[13:46] <didrocks> jdstrand: dholbach: subscribe the ubuntu-desktop team please
[13:46] <didrocks> and the unsubscribe the sponsor team
[13:46] <mterry_> doko, OK, I uploaded a new cheetah without the build-depends on python-markup (only used for an optional test).  The binary package still suggests it, but that shouldn't be a problem
[13:47] <mterry_> doko, thanks for the catch
[13:47] <didrocks> dholbach: btw, did you find a bug for nvidia vs grub?
[13:47] <jdstrand> didrocks: how do I do that? there is no bug and nothing in the merge page showing how I can do that
[13:47] <jdstrand> didrocks: (and ubuntu-desktop is already subscribed)
[13:47] <dholbach> didrocks, no, I'm afraid I didn't
[13:47] <didrocks> jdstrand: I think you need to be part of the team to unsubscribe it
[13:48] <jdstrand> didrocks: I am a member of ubuntu-sponsors
[13:49] <didrocks> oh weird?
[13:49] <fta> jdstrand, my chromium security updates for maverick and lucid are ready: http://people.ubuntu.com/~fta/chromium/8.0.552.215~r67652/ & bug 684502
[13:50] <jdstrand> didrocks: I just added a comment to the merge asking the submitter to unsubscribe us
[13:50] <didrocks> ok :)
[13:50] <didrocks> thanks jdstrand
[13:50] <jdstrand> fta: ack. I'm patch piloting now so will get right on it. thanks!
[13:50] <fta> excellent
[13:57] <ScottK> doko: qt4-x11 is past where it FTBFS on armel before, so that's a good sign.
[13:58] <ogra_ac> \o/
[13:58] <rsalveti> nice
[13:59] <doko> ScottK: I think you did target #661901 for alpha1
[14:01] <ScottK> doko: I did.  I agree it's incomplete (it lacks the build-depends that need repromotion too).
[14:03] <ScottK> I'll fix it.
[14:14] <Daviey> @pilot out
[14:43] <james_w> jdstrand, it's not possible to un-request a review I don't think. I just voted "abstain" which is the closest there is I think
[14:44] <jdstrand> james_w: oh, how did you do that?
[14:44] <jdstrand> I didn't see that either
[14:44]  * jdstrand goes to look again
[14:44] <james_w> jdstrand, clicked the [review] link next to ubuntu-sponsors and voted on the next page
[14:44] <james_w> it may have disappeared now that I have done that though
[14:45] <jdstrand> james_w: I see. ok, good to know. thanks
[14:45] <jdstrand> james_w: I was afraid if I claimed the review I would be on the hook! :)
[14:45] <mok0> Man source package format 3.0 (quilt) is TERRIBLE
[14:46]  * ScottK waves to mok0.
[14:46] <mok0> Hi ScottK
[14:51] <mok0> I am going back to 1.0 :-(
[15:06] <jdstrand> pitti: thanks for your comments in ArchiveAdministration. I'd like to mention that I had no intention of actually processing kernel SRUs until the process was defined (like you did in your wiki change) and the AAs were told they could do so via an ubuntu-sru ACK. The wording is rather strong in your last note. It isn't fundamentally any different from the security team using the ubuntu-security-proposed ppa ala chromium-browser. I'm not sure i
[15:06] <pitti> jdstrand: ah, thanks for the clarification
[15:06] <pitti> jdstrand: (your comment was cut off, BTW)
[15:07] <jdstrand> pitti: what was the last part you saw?
[15:07] <pitti> jdstrand: it does break the review process quite hard, though
[15:07] <pitti> jdstrand: "I'm not sure i"
[15:07] <jdstrand> I'm not sure it would need TB approval, but  I am not on the ubuntu-sru team.
[15:08] <jdstrand> pitti: I talked to sconklin and others on the kernel stable team letting them know that AAs would not process these things without a clear process
[15:08] <jdstrand> pitti: defined ideally by you and them
[15:08] <pitti> jdstrand: right, I fixed the tone of that comment; sorry about that
[15:08] <pitti> jdstrand: Steve's mail sounded like "we are doing that right now", so I guess I freaked out a bit
[15:09] <jdstrand> pitti: I just wanted to make sure that since they are keen on the ppa approach, the commands for actually getting the kernel into -proposed were available
[15:09] <jdstrand> pitti: and I seemed the right AA to do it since I am always copying things around from ppas :)
[15:09] <pitti> right
[15:31] <jdstrand> @pilot out
[16:01] <achiang> pitti: hi, you about?
[16:01] <pitti> achiang: yes (but in meeting)
[16:01] <achiang> pitti: ok, if you get a chance, can you point me in the direction of someone that is familiar with glib2.0? i'm trying to backport the maverick version to natty and ran into some issues
[16:01] <achiang> uh
[16:01] <achiang> backport maverick -> lucid
[16:02] <pitti> achiang: that's a bit too unspecific, I'm afraid
[16:02] <pitti> many people know certain parts of glib
[16:03] <achiang> pitti: ok, well, the backport was pretty trivial, actually, and the package seems to build, all internal tests pass, etc. however, when actually installing the package, i am encountering errors that say, "Setting up libglib2.0-0 (2.26.0-0ubuntu1charlotte2) ...
[16:03] <achiang> No schema files found: doing nothing."
[16:04] <pitti> achiang: is that actually an error? it sounds like a message from gsettings
[16:04] <pitti> achiang: seb128 should be familiar with that
[16:04] <achiang> pitti: i don't know if it's actually an error or not, but i can't build other packages because my pbuilder always exits at that point
[16:05] <pitti> achiang: hm, weird
[16:05] <pitti>            /usr/lib/glib-2.0/glib-compile-schemas /usr/share/glib-2.0/schemas || true
[16:05] <pitti> ^ from /var/lib/dpkg/info/libglib2.0-0.postinst
[16:05] <pitti> i. e. it sholdn't abort
[16:06] <achiang> pitti: hm, wait, i think i see something else, one sec, i'll check
[16:07] <achiang> pitti: i guess i get to wear the brown paper bag. there was another unresolved dependency in my pbuild that i missed and need to go fix. sorry for the noise
[16:10] <pitti> achiang: ah, good :)
[16:37] <jdstrand> cjwatson: am I remembering correctly that you have scripted much of the autosyncs so NEW processing is more or less ubuntu deltas in this part of the cycle?
[16:40] <cjwatson> jdstrand: mostly, if I'm understanding your question correctly
[16:42] <jdstrand> cjwatson: I'll take that as a 'yes' for now and ask if I have any other questions later. While I'm processing NEW now, there is quite a backlog so I won't hit any new NEW stuff for some time anyway
[16:42] <cjwatson> doko: gcj-4.4 sync fails because it clashes with libgcj-doc which is now from gcj-4.5.  perhaps we need an Ubuntu upload of gcj-4.4 which stops producing that package?
[16:43] <doko> cjwatson: will do, thanks for the notice
[16:44] <cjwatson> (actually, the current version in Ubuntu doesn't build libgcj-doc, I guess that changed between then and the current version in unstable - but at any rate the delta means we need an *ubuntu* version, I think)
[16:44] <cjwatson> I sync-blacklisted it in the meantime
[16:47] <pitti> doko: python2.7 and langpacks -- that should keep the buildds warm over the long cold weekend :-P
[16:47] <doko> I hope so ...
[16:47] <doko> pitti: btw, are changelogs only removed for packages on the cd?
[16:48] <pitti> doko: no, for all packages
[16:48] <doko> I still think this is bad ...
[16:48] <pitti> doko: the Debian changelogs are truncated, not removed, btw
[16:49] <doko> right, but no chance to look at upstream changelogs
[16:49] <pitti> I know, but it's a change that hurts users least; I'm always open for other suggestions what to take off the CDs
[16:50] <doko> pitti: easy: fix packaging to include upstream changelogs in every binary package, and move upstream changelogs in -dev packages
[16:51] <pitti> and remove them if there isn't a -dev?
[16:51] <pitti> well, we can certainly not strip them from -dev
[16:51] <pitti> I mean, "we can certainly leave them in *-dev"
[16:59] <geser> importing "removals" from Debian still happens occasionally, right? and no need to file removals bugs (yet)
[17:05] <mvo> I change the way changelogs are extracted on changelogs.ubuntu.com, its now launchpadlib based and should be *much* speedier than the old one (within the rnage of 15min after publication). I will send out a mail too, but please let me know if you notice anything odd/missing
[17:08] <pitti> jdstrand: hm, bug 626451 is said to be fixed by the lucid SRU, but is still open in natty?
[17:08]  * jdstrand looks
[17:11] <pitti> jdstrand: I added the missing lucid tasks to the other ones; seems this is the only strange one
[17:12] <jdstrand> pitti: that patch is not in lucid
[17:12] <pitti> jdstrand: hm, the .changes refers to it
[17:12] <jdstrand> pitti: it is part of the 0004-ubuntu-abstractions-updates.patch patch that was backed out of the lucid sru
[17:12] <jdstrand> pitti: yes, but at the top of the changes it says that 0004-ubuntu-abstractions-updates.patch was backed out
[17:12] <pitti> jdstrand: ah, ok; changelog error then; I'll ignore that one then, thanks
[17:13] <jdstrand> pitti: well, error, sorta-- I tried to be clear with:
[17:13] <jdstrand>   * remove the following patches (features not appropriate for SRU):
[17:13] <jdstrand>     - 0002-add-chromium-browser.patch
[17:13] <jdstrand>     - 0003-local-includes.patch
[17:13] <jdstrand>     - 0004-ubuntu-abstractions-updates.patch
[17:13] <pitti> jdstrand: right, but the review script isn't clever enough to figure that out
[17:13] <jdstrand> sure
[17:14] <pitti> (not that I could do it any better with 30 bugs.. :) )
[17:14]  * jdstrand wonders if the added tasks in other bugs are the same sort of thing
[17:14] <jdstrand> pitti: I tried to detail all that in the email
[17:14]  * jdstrand goes to look
[17:14] <jdstrand> I might have missed one, but I tried *real hard* not to :)
[17:15]  * pitti sends it proposedwards
[17:15] <jdstrand> \o/
[17:15] <doko> pitti: would about of getting rid of sqlite1 and 2 this cycle?
[17:15] <jdstrand> sbeattie: ^ put your testing cap on :)
[17:16] <jdstrand> pitti: huge thanks. I know it was a bear to review. Please know we will be testing it extremely thoroughly
[17:17] <jdstrand> sbeattie: so we may want to coordinate some of our testing of apparmor. I was planning on running through all of qrt for anything related to apparmor
[17:17] <micahg> pitti: Did I do something wrong on the SRU for testdrive?
[17:18] <pitti> micahg: I had to reject some packages, I commented in the bugs
[17:18] <sbeattie> jdstrand: sure, that's fine. I'm not going to be able to get to it until next week.
[17:18] <pitti> it might have been amongst them
[17:18] <jdstrand> sbeattie: yeah, me other. let's coordinate in the meeting
[17:18] <pitti> doko: actually, what's the source for sqlite2? I only see libdbd-sqlite2-perl
[17:18] <jdstrand> though, I will install it in all my lucid machines
[17:18] <jdstrand> (in the meantime)
[17:19] <micahg> pitti: no, AFAICT it wasn't rejected, you just commented please upload even though I uploaded
[17:19] <pitti> micahg: ah, I reviewed the bug mail before I reviewed the queues
[17:19] <micahg> pitti: ah, ok, so subscribing ubuntu-sru after upload is correct though, right?
[17:19] <pitti> right
[17:19] <doko> pitti: I still see python-pysqlite1.1, python-pysqlite2
[17:20] <micahg> pitti: ok, thanks
[17:20] <pitti> doko: python-pysqlite1.1 seems easy, I don't see rdepends
[17:20] <pitti> doko: want me to remove it right away?
[17:20] <pitti> (and blacklist)
[17:21] <pitti> doko: but it depends on libsqlite3-0, so it basically just seems to be an adapter for an old API
[17:21] <doko> pitti: please do
[17:22] <doko> pitti: yes, we had this discussion before lucid too, and that we had to keep it for compatibility. but even now?
[17:22] <pitti> I don't see a reason to keep it; python has it built in
[17:24] <pitti> doko: python-pysqlite1.1 killed; I'd like to blacklist it, but it seems someone else (cjwatson?) is editing blacklist.txt
[17:24] <cjwatson> no longer, go ahead
[17:25] <pitti> doko: python-pysqlite2 still has a ton of rdepends, though, so I can't remove it right away
[17:26] <pitti> cjwatson: thanks, done
[17:26] <doko> pitti: aren't these just alternatives?
[17:26] <pitti> I grabbed a random example, python-axiom
[17:27] <pitti> python-turbogears2 has an alternative-less recommends
[17:28] <doko> because that's in the stdlib in 2.6 and up
[17:28] <pitti> trac got it right, it's an alternative
[17:28] <pitti> anyway, need to leave; have a good weekend everyone!
[17:42] <jdstrand> pitti: I know you are gone, but this is just an fyi
[17:43] <jdstrand> pitti: all those bugs you added Lucid tasks for in the apparmor SRU I mentioned in the AppArmor ABI email. none of them were actually bugs in Lucid, but the fixes are harmless abstraction updates. I will comment in the bugs accordingly in testing
[17:43] <jdstrand> pitti: and you have a good weekend too! :)
[17:44] <jdstrand> sbeattie: I am going to forward you that email ^ for background info
[17:44] <jdstrand> sbeattie: oh, nm, I already sent it to you :)
[18:29] <SpamapS> is there a queue somewhere of bug nominations for SRU, or should I bump those with powers to accept them whenever I nominate a bug?
[18:30] <ScottK> SpamapS: Subscribing ~ubuntu-sru to the bug should be sufficient.
[18:37] <SpamapS> ScottK: ty
[19:00] <Daviey> SpamapS: If it's a specific server SRU.... throw it to zul
[19:00] <Daviey> zul looks after the SRU nominations for server list, right zul? :)
[19:00] <zul> yep
[19:01] <Daviey> zul: Did the newish server SRU process get documented?
[19:02] <zul> Daviey: not yet...talking to hgddh on monday
[19:03] <SpamapS> Daviey: did you forget to tell the bot you're patch piloting? cause, you seem to be patch piloting. ;)
[19:05] <SpamapS> zul: btw, bug #684398 needs to be accepted for Lucid (and probably Karmic)
[19:05] <zul> SpamapS: done
[19:06]  * zul wanders off
[19:06] <Daviey> SpamapS: I did tell the bot earlier, following up with you about that branch was just cleaning up the things i started :)
[19:09] <SpamapS> Daviey: ah ok. :) thanks btw
[19:19] <kees> jdstrand: hi! can you promote msr-tools? bug 684778 is approved now
[19:29] <smoser> wondering if anyone has suggestions...
[19:30] <smoser> i've got a partition image (uec-images.ubuntu.com) and want to put that inside a disk image
[19:30] <ebroder> As in you want that image to become a partition on another image?
[19:30] <smoser> and then get grub-pc written into the mbr so that it will load (/boot/grub/core.img and the lot already exist inside the image)
[19:30] <smoser> ebroder, yes.
[19:31] <smoser> really i just need to put (i think) like 2 512 byte blocks in front, one for MBR and one for partition header
[19:31] <smoser> (i think)
[19:31] <ebroder> smoser: Create the second disk image (make sure it's big enough). losetup --show --find whole_disk.img; fdisk /dev/loop0; kpartx -a /dev/loop0; dd if=partition.img of=/dev/mapper/loop0p1
[19:31] <ebroder> Roughly
[19:32] <smoser> and what about grub?
[19:33] <ebroder> I did a writeup for GRUB legacy at <http://ebroder.net/2009/08/04/installing-grub-onto-a-disk-image/>. There's some awesome device-mapper hackery involved. Don't know if it works with GRUB 2, but I bet it would
[19:36] <ebroder> Hmm,, actually there's a comment I had forgotten about that says it didn't work with GRUB 2 from squeeze, so I'm not sure
[19:36] <lifeless> kees: hows your script looking now ?
[19:36] <smoser> well, i dont need to actually run grub-install i dont think
[19:37] <smoser> as that is already run inside the image (i've done that hackery). i just need to get grub2 into mbr
[19:37] <ebroder> smoser: Hmm, is that just /boot/grub/boot.img or something?
[19:38] <smoser> i dont know.l...
[19:39] <ebroder> Looks like boot.img isn't quite the same as my MBR
[19:50] <kees> lifeless: dunno, can try again in a bit
[19:51] <RoAkSoAx> mterry: ping?
[19:51] <lifeless> kees: I just want to see you going 'awesome' again :)
[19:52] <RoAkSoAx> Can any please take a look to bug #527142 and bug #527195
[19:58] <jdstrand> kees: sure thing
[20:00] <jdstrand> done
[20:01] <mterry> RoAkSoAx, hi
[20:01] <RoAkSoAx> mterry: howdy!! Do you think you can take car of bug #527142 when you have the time please?
[20:03] <mterry> RoAkSoAx, oh interesting.  did debian make the split after all?
[20:06] <RoAkSoAx> mterry: yeah!! the maintainer realized that it was a blocker in Ubuntu and decided to go ahead and do it. So I just took the changes related to the split for Ubuntu, given that the current package in Debian breaks the cluster
[20:07] <mterry> RoAkSoAx, nice.  ok, will look in a bit
[20:07] <mterry> RoAkSoAx, thanks for your work!
[20:08] <RoAkSoAx> mterry: thank you!! and if you have the time, bug #527195 would be nice aswell :)
[20:08] <ari-tczew> do we have to keep special maintainer field? rabbitmq-server has got Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[20:08] <ScottK> ari-tczew: It just needs to be updates.  That's what we used to use for Main packages.
[20:08] <ScottK> updates/updated
[20:09] <ari-tczew> ScottK: so, can I let update-maintainer to change it?
[20:10] <ScottK> ari-tczew: As long as it makes it correct.
[20:10] <ebroder> ari-tczew: I don't think update-maintainer will fix it without you first resetting Original-Maintainer -> maintainer
[20:13] <ari-tczew> ebroder: I'll run update-maintainer on package from unstable. (doing merge)
[20:15] <ScottK> ari-tczew: The thing that matters is the correct result, not how you get there.
[20:16] <ari-tczew> ScottK: what's the conclusion?
[20:16] <ScottK> You tell me?
[20:18] <ari-tczew> ScottK: don't touch maintainer field?
[20:18] <ScottK> No.
[20:19] <ari-tczew> ScottK: touch or not?
[20:19] <ScottK> Touch
[20:19] <ari-tczew> ufff
[20:51] <doko> ScottK: an easier workaround for the symbols file might be to use: (c++)"<demangled symbol>"
[20:52] <ScottK> doko: OK.  How would we go about doing that (point me at some docs and I'll look into it)
[20:52] <doko> dpkg-gensymbols(1)
[21:14] <ScottK> Sigh
[22:06] <ebroder> Does deleting autogenerated files in the clean target work with 3.0 (quilt) packages like it did with old source format?
[22:47] <cokegen> hi, I don't know if my question should go to the #ubuntu channel, is that I just think that could fit here
[22:47] <cokegen> need to know if the alternate installer has wireless support
[22:51] <slangasek> cyphermox: bug #683994> so I have some code in bzr for the plymouth package to split the text strings out of the binary; any chance you'd like to come up with a solution for us to automatically update the displayed string based on lsb_release?
[22:52] <cyphermox> slangasek, oh, sure, why not
[22:52] <slangasek> :)
[22:52] <slangasek> in the meantime I'm uploading the static change to 11.04
[22:52] <cyphermox> did you see my branch?
[22:53] <slangasek> hmm no
[22:53] <slangasek> where should I have looked?
[22:53] <cyphermox> ah, I was just wondering if editing the plymouth file (through the one large patch) was the right thing to do
[22:53] <cyphermox> don't bother ;)
[22:54] <cyphermox> afaict, the title= entry was the only place where the version number was
[22:54] <slangasek> within the branch, both debian-changes and the plymouth files should be updated (dpkg 3.0 quilt)
[22:55] <cyphermox> ah, so that's probably why testing with just debian-changes updated didn't work
[22:57] <cyphermox> slangasek, fwiw, I didn't forget you for NM touching /etc/hosts, mbiebl is also concerned about changing it for no reason. I just haven't been able to get to it yet, nm-applet has been distracting me ;)
[22:57] <slangasek> cyphermox: I think I was supposed to file a bug report somewhere, wasn't I?
[22:57] <slangasek> I seem to not be good at remembering to do that
[22:58] <cyphermox> if you could, so I have documentation about exactly what you want, it would be nice. I seem to not be good about remembering all the details
[22:58] <slangasek> ack, will try :)