[05:36] <dylan-m> Hey, does anyone know what became of patching libsoup to have a default SSL CA file?
[05:36] <dylan-m> Looks like MVO sent a patch upstream from this bug: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/874242
[05:38] <dylan-m> And it was wontfixed, but reading the comment (though I could be misunderstanding)  it sounds like libsoup already has a similar compile flag
[07:03] <dholbach> good morning
[07:03] <dylan-m> Good morning!
[07:03] <dylan-m> :o I'd better go to sleep
[09:52] <lenios_> hey, just asking: i've reported a bug, someone wrote a patch and now it's pending for review. Who is responsible for review? package maintainer, reviewer team, me?
[10:08] <geser> lenios_: do you have the bug number?
[10:11] <jdrab> hi guys, is there something like ubuntu HIG or some sort of guidelines for developing applications in ubuntu/unity?
[10:19] <Riddell> jcastro: uds sponsorship broken? http://summit.ubuntu.com/uds-r/sponsorship/
[10:32] <Peace-> how sweet is this ? avconv doens't work to grab screen
[10:32] <Peace-> and even the fake version of ffmpeg
[10:33] <Peace-> 12.10 of course
[11:06] <doko> apw: is CONFIG_X86_X32=y set for our kernel builds on amd64?
[11:07] <apw> doko, nope not set anywhere currently
[11:07] <apw> doko, something you need there ?
[11:08] <apw>           You will need a recent binutils (2.22 or later) with
[11:08] <apw>           elf32_x86_64 support enabled to compile a kernel with this
[11:08] <apw>           option set.
[11:08] <doko> apw: can you set it, afaik it should be possible to set it. well, it's not "needed", however to experiment with x32, it would be nice to have it set, if doesn't influence the amd64 build
[11:08] <apw> doko, is our binutils new enough do you know ?
[11:09] <doko> apw: it's 2.23 for quantal
[11:09] <apw> doko, i don't see any issue having it set in quantal before release, security may whine if its on for release
[11:09] <apw> doko, i'll go see if it turns on easy
[11:09] <doko> let them whine =)
[11:10] <infinity> apw: The master plan for this release was to flip it on for the kernel and get the toolchain bits vaguely ready enough for people to play with it.
[11:10] <seb128> apw, hey, do you still plan to upload kmod? pitti said you were about to upload it before he left for holidays
[11:11] <infinity> apw: That said, there are still commits every day to glibc upstream for x32, so it's clearly not "done" yet. :P
[11:16] <cjwatson> seb128: robert_ancell did updated versions of libburn and libisofs recently; I don't suppose you know if he's planning to do a new libisoburn as well to go with them?
[11:16] <cjwatson> if not, I might, as part of killing the amd64+mac images
[11:16] <seb128> cjwatson, I doubt he is
[11:17] <seb128> cjwatson, he's usually trying to tackle red lines on http://people.canonical.com/~platform/desktop/versions.html
[11:30] <lenios_> geser, took a long time but #1025652
[11:31] <lenios_> that's funny there's a new version of unity-greeter today, but the bug is still present
[11:40] <geser> lenios_: in this case the patch is waiting on review by upstream (Unity Greeter devs), you don't need to do anything
[11:41] <lenios_> ok thanks
[11:42] <lenios_> i hope it will be fixed by the beta
[11:48] <xnox> bug 1025652
[12:04] <tjaalton> should dpkg in precise support handling xz tarballs?
[12:05] <debfx> tjaalton: yes
[12:06] <tjaalton> dpkg-buildpackage insists on creating a tar.gz even when there is a .xz available..
[12:06] <tjaalton> ie. makes a native package
[12:07] <Laney> you mean orig.tar.xz?
[12:07] <tjaalton> yes
[12:07] <Laney> is it correctly set to 3.0 (quilt)?
[12:07] <tjaalton> 1.0 doesn't support it?
[12:08] <siretart> tjaalton: no, you need 3.0 for xz AFAIR
[12:08] <Laney> indeed
[12:08] <tjaalton> oh gah..
[12:08] <tjaalton> very well then
[12:09] <siretart> yes, that's even documented in dpkg-source(1)
[12:10] <tjaalton> ok
[12:10] <tjaalton> 3.0 hates git
[12:12] <Laney> what?
[12:13] <tjaalton> trying to avoid it where possible
[12:13] <tjaalton> and in this case looks like I need to do tricks in order to build from git
[12:13] <tjaalton> dpkg-source: error: cannot represent change to wayland/spec/wayland-architecture.png: binary file contents changed
[12:14] <tjaalton> etc..
[12:14] <tjaalton> hmm something else going on, looks really weird
[12:33] <siretart> tjaalton: seems that your tree content does not match the contents of the orig.tar.gz. check the version numbers in debian/changelog with the filename you try to use
[12:34] <siretart> tjaalton: as a workaround, you can use 'dpkg-buildpackage -b' to avoid building a source package.
[12:35] <tjaalton> siretart: I know where it came from. for some reason upstream git has files the tarballs don't, so in this case had to just remove them and live with it
[12:35] <tjaalton> no ChangeLog then :)
[12:35] <siretart> tjaalton: oh, yeah, I also have some upstreams that generate the tarballs with some scripts that causes the contents to be different to what is in git
[12:36] <siretart> tjaalton: there are two approaches: import the upstream tarballs or screw them :-)
[12:36] <siretart> (i mean the tarballs)
[12:36] <tjaalton> yes, and pkg-xorg has the habit of doing 'git log <tag> > ChangeLog' every time a new version is merged, so the diff would normally have that
[12:37] <siretart> that shouldn't cause issues with some random .png files, though...
[12:38] <tjaalton> they're not in the tarballs -> nagging
[12:40] <siretart> afaiui, missing files are not a problem at all, they just cause warning "file is missing". only files with different contents are problematic
[12:41] <tjaalton> it ignores files that are deleted, ie. missing from the git branch (like autotool files)
[12:41] <tjaalton> the other way around means problems
[12:49] <cjwatson> tjaalton: there's always debian/source/include-binaries
[12:50] <tjaalton> cjwatson: hmm, thanks
[13:06] <mpt> "It's not just you! http://status.ubuntu.com looks down from here." http://www.downforeveryoneorjustme.com/status.ubuntu.com
[14:11] <toggles> Is there a way to get a ppa to automatically build for the next version? Or do I need to change the changelog and submit it again?
[14:13] <geser> if no rebuild is needed, then you can copy it forward otherwise (needs a rebuild) you need to reupload
[14:14] <toggles> geser: thanks, what do you mean "copy it forward"?
[14:14] <ev> mpt_:  whenever you have time for it, I think we'll need a small design for incorporating "problems my team is responsible for" on the most common problems table
[14:14] <ev> vs "all problems"
[14:15] <ev> the data coming from here: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AhTVBLlLWapNdHRpM2QyRGQ5NGFzZmF3ODNpZ2E3d1E&authkey=CJzt1xo&authkey=CJzt1xo#gid=0
[14:15] <geser> toggles: Launchpad has the feature to copy (source and binary packages) from one series to an other
[14:16] <mpt_> ev, that's already on my list for <https://blueprints.launchpad.net/ubuntu/+spec/other-q-defects-dashboard>
[14:16] <ev> oh, of course
[14:16] <ev> excellent
[14:17] <toggles> geser: thanks, I'll see if I can figure it out, much appreciated
[14:17] <didrocks> ev: thanks for the openid change, I'm crossing my fingers :)
[14:17] <ev> didrocks: sure thing
[14:18] <ev> apologies it took so long - the correct solution required us pulling in postgres, which I wasn't particularly keen on. I had hoped we could find a decent way of bolting the django auth model to cassandra, but that looks quite difficult
[14:19] <ev> and using a separate database just for login and session caching isn't really that bad an idea
[14:48] <bdmurray> infinity: what were you saying about bug 1036794 yesterday regarding it being reported about update-manager and not the package?
[14:56] <ev> mpt_: I can't recall what the outcome was, but if you have thoughts on how we can do a better present the information in the most common errors table than by the current confusing colour system, do let me know.
[14:58] <mpt_> ev, I think step 1 is to list the variables you're trying to present. Apparently regressed vs. fixed vs. never fixed, reported in latest version vs. not, what else?
[15:01] <ev> mpt_: there's the 'last seen' version is not the most recent -> greyed out last seen, the linked bug is marked as complete -> greyed out line, the last seen version is the most recent version and the linked bug is marked as complete -> red last seen.
[15:01] <ev> and of course, links you've clicked on are blue
[15:01] <seb128> ev, I find it weird that errors.ubuntu.com has no error ever on gconf2 about gsettings-data-convert where we regularly have bugs in convert scripts and quite some reports on launchpad about those
[15:01] <mpt_> ev, What does "complete" include?
[15:02] <seb128> ev, do you know how we could figure out why that's so?
[15:03] <ev> mpt_: whatever launchpad considers a complete bug. I believe that's Invalid, Wont Fix, and Fix Released
[15:03] <ev> seb128: looking
[15:04] <xnox> ev: Opinion?!
[15:04] <ev> that too
[15:19] <xnox> cjwatson: do you have the link to task for opening archive... again... me and micahg can't find it again =)
[15:19] <xnox> found it
[15:19] <xnox> micahg: https://wiki.ubuntu.com/NewReleaseCycleProcess
[15:20] <micahg> xnox: thanks, bookmarked
[15:21] <xnox> probably needs a new sections of "Things to do for Radiant Raccoon"
[15:21] <Laney> you expect something special?
[15:21] <xnox> Laney: yes we do =)
[15:24] <Laney> sinister...
[15:26] <cjwatson> xnox: Is this just misc changes we need to remember to make to various packages?
[15:27] <xnox> cjwatson: aha
[15:42] <shadeslayer> cjwatson: I wanted to add a custom task for my derivative, can I just edit /usr/share/tasksel/ubuntu-tasks.desc and go with that? or should I modify the tasksel package?
[15:42] <shadeslayer> ( I've tried the former and it doesn't seem to work, probably I'm doing something wrong )
[15:42] <cjwatson> shadeslayer: If you can modify tasksel in your derivative, you should
[15:43] <shadeslayer> awesome
[15:43]  * shadeslayer modifies tasksel
[15:43] <cjwatson> shadeslayer: But you also need to arrange to have appropriate Task fields in your archive's Packages files
[15:43] <shadeslayer> ah
[15:43] <cjwatson> The usual arrangement is to use "extra overrides" in apt-ftparchive
[15:43] <cjwatson> But it will depend a bit on your archive software
[15:43] <shadeslayer> hmm .. I'm using reprepro
[16:04] <shadeslayer> cjwatson: the files in indicies are exported by tasksel right?
[16:22] <mterry> barry, hello!  I'm looking at pycurl right now and note it doesn't have a python3 port.  There are patches floating around, any objection to me applying one?
[16:23] <infinity> bdmurray: I was saying that it would be nice if apport/errors didn't get it wrong. :P
[16:23] <mterry> Er, not just one of them, but the one pointed at by the python3 spreadsheet
[16:34] <bdmurray> infinity: right, and how I can help make it right?
[16:36] <cjwatson> shadeslayer: no, they're generated by the archive machinery
[16:36] <shadeslayer> hmm
[16:36] <cjwatson> I'm afraid they're your problem to deal with - I can only support the Ubuntu archive here :)
[16:36] <shadeslayer> then something is wrong with the way I've setup reprepro
[16:37] <shadeslayer> cjwatson: yeah, I understand :)
[16:37] <cjwatson> indices/ output isn't mandatory
[16:37] <cjwatson> it's basically informational and to help people do matching apt-ftparchive runs and the like
[16:37] <cjwatson> the important bits are the Task: fields in Packages
[16:37] <shadeslayer> ah ok
[16:38] <infinity> bdmurray: I dunno, do something programmy to it? ;)
[16:38] <TJ-> When I "bzr push lp:~tj/gnome-control-center/fix-123456" to my LP, should it be sending the entire local repo or just the diff (originally got using bzr branch lp:ubuntu/precise-updates/gnome-control-center) ?
[16:39] <infinity> bdmurray: The error in question, I think, was "clearly" an issue with either libnspr4 (or one of its dependencies) and, while it's not foolproof to do so, still seems like a regex to try to sort out to blame the package that can't be installed makes more sense than blaming the package manager.
[16:49] <cjwatson> TJ-: Branches pushed to LP are generally "stacked", which saves pushing the whole thing.  However, what they're stacked on depends on where you push it.  In this case you're pushing it to an upstream-type location which will mean it'll stack on lp:gnome-control-center, whatever that may be, and very likely not having anything in common with your branch.
[16:49] <cjwatson> TJ-: You should probably push to lp:~tj/ubuntu/precise-updates/gnome-control-center/fix-123456 instead.
[16:50] <TJ-> cjwatson: Yeah, I tried "precise-updates" and got "Denied" which is why I asked. However, mgz in #bzr has sorted me out so I'm now just pushing the delta between 'precise' and my fix
[16:51] <TJ-> cjwatson: My 'git' head still has trouble grok-ing bzr and launchpad integration. Thanks for the heads-up.
[16:58] <killown> THANKS AGAIN by messing with ubuntu, now it's opengl things wine game screens doesn't work after the last update that bring mesa, compiz and opengl things, "THANKS AGAIN"
[16:59] <killown> sudo apt-get upgrade it far more dangerous than rm -rf /
[16:59] <mdeslaur> killown: how about filing a bug instead of coming here to rant?
[16:59] <killown> every upgrade more bizarre bugs comes
[16:59] <killown> I am tired from filling bugs, what about don't touch on what already is working?
[17:03] <seb128> killown, what about you just stay on a stable version where thing don't change so often?
[17:03] <killown> am I not on a stable distro?
[17:03] <killown> 12.04
[17:03] <killown> NO PPA's
[17:03] <seb128> nothing brigs compiz and opengl in 12.04
[17:04] <cjwatson> seb128: compiz had a new version in precise-updates 21 hours ago, according to LP
[17:05] <seb128> cjwatson, it doesn't has any new requirement
[17:05] <seb128> cjwatson, that new compiz doesn't bring any opengl over what the previous one did
[17:05] <seb128> but maybe I misread the statement
[17:06] <killown> brings a new bug
[17:06] <seb128> what mdeslaur said then
[17:06] <seb128> open a bug
[17:07] <shadeslayer> cjwatson: ok, I'm trying to understand what ubuntu-seeds.pl does, but I'm a bit confused, it branches the seeds, and then ... what does it do?
[17:07] <killown> while that I can't play my steam games, it's cool
[17:07] <cjwatson> shadeslayer: I would be very surprised if it did anything that's appropriate for you ...
[17:07] <shadeslayer> yeah .. I think using tasksel would be overkill
[17:07] <seb128> killown, log into unity2d to play
[17:08] <cjwatson> shadeslayer: no, that wasn't my point
[17:08] <seb128> killown, or downgrade whatever you upgraded
[17:08] <cjwatson> shadeslayer: ubuntu-seeds.pl generates the files in ubuntu-tasks/ based on the Ubuntu seeds
[17:08] <shadeslayer> oh ok
[17:08] <cjwatson> shadeslayer: but there's no reason you can't just edit those files directly as long as your changes aren't directed at the Ubuntu archive
[17:08] <shadeslayer> right
[17:08] <cjwatson> it's just to help us maintain them
[17:08] <killown> seb128, even on kde disabling the effects doesn't fix this
[17:08] <shadeslayer> makes sense, I'll skip using ubuntu-seeds.pl then
[17:08] <seb128> killown, so it's not compiz
[17:09] <seb128> KDE doesn't use compiz
[17:09] <killown> seb128, its not
[17:09] <killown> the upgrade list comes with alot opengl things and mesa
[17:09] <killown> compiz is one of those
[17:09] <seb128> well, try to downgrade until you figure which one created your issue?
[17:09] <stgraber> mesa was indeed updated but unless you're using an i3 ivy bridge CPU, you won't get any difference
[17:10] <stgraber> the only diff in mesa was reducing the number of threds on i3 ivy bridge GPUs to fix pretty bad screen corruptions
[17:10] <shadeslayer> cjwatson: the other question I had was, I don't see anything remotely related to the Task field in the debian policy manual
[17:10] <cjwatson> shadeslayer: I wouldn't expect you to
[17:10] <shadeslayer> oh ...
[17:10] <cjwatson> shadeslayer: the Packages format is extensible ...
[17:10] <cjwatson> shadeslayer: it's not required for every field there to be specified in policy
[17:11] <cjwatson> shadeslayer: only the ones that generally need to be assigned values by individual packages, which this doesn't
[17:11] <cjwatson> even then, only the ones that need widespread cooperation
[17:12] <cjwatson> the policy manual is basically there to document the things required of individual packages for interoperability, rather than a detailed guide to the entire system
[17:12] <shadeslayer> alright ...
[17:16] <shadeslayer> cjwatson: thanks for all the help so far, I hope I wasn't too annoying ;)
[17:16] <cjwatson> that's ok
[17:16] <killown> take a look http://i.imgur.com/aOzF5.jpg
[17:42] <bryceh> @pilot in
[17:48] <barry> mterry: go for it!  and thanks.
[17:48] <mterry> barry, awesome
[17:51] <killown> any developer needs downgrade the last packages updates, I tested with wine1.4, wine1.5 AND it's what I get http://i.imgur.com/aOzF5.jpg?  how I can filling a bug for that? this screen is all what I get, wine output doesn't tell where this opengl error is from
[17:55] <killown> http://paste.ubuntu.com/1151115/
[17:57] <cjwatson> there's no reason you can't file a bug with what you have so far - any change to a stable release would require a bug report anyway for tracking
[17:57] <cjwatson> people aren't saying "file a bug" to get rid of you, but because that's how we track problems
[17:58] <lborda> cjwatson, hi
[17:58] <cjwatson> lborda: hello.  your previous comments in my direction were lost in the IRC client I closed down a while ago when shuffling network connections
[17:59] <lborda> cjwatson, no problem... tks anyway... I am having some weird problems when preseeding 12.04 and using ONLY a local mirror... no internet access
[18:00] <killown> cjwatson, but how can one distro be called stable with this kind of bug? this impede me from use wine, and more now  that valve is coming for linux this kind of thing can't happen with linux, this is a shame
[18:00] <cjwatson> killown: I'm not going to engage with rants, I'm afraid - too much work to do
[18:00] <cjwatson> lborda: ok, can you show me logs and the preseed file in question?
[18:01] <lborda> cjwatson, yes here is the preseed: https://pastebin.canonical.com/72357/
[18:01]  * rmk_ finds a bug in precise's vlc xv backend
[18:01] <rmk_> it appears that it remembers the wrong fourcc code to pass back into PutImage
[18:02] <rmk_> and with the additional check that xorg >= 1.9.99 does, it gets a BadMatch error back
[18:02] <lborda> cjwatson, it follows the logs too: https://pastebin.canonical.com/72359/
[18:03] <lborda> cjwatson, it looks like debian-installer is not able to fetch from the local mirror. there is no internet access on the environment...
[18:03] <lborda> cjwatson, i am using 12.04.1 latest netboot files
[18:03] <killown> ok, so now I fill a bug with that wait for a week without can use wine and last upgrade some new bugs that impede me from use other programs? ok enough, I am going to look for another distro, thanks you all.
[18:03] <cjwatson> lborda: did you remember to include the debian-installer Packages files?
[18:04] <cjwatson> lborda: in the local mirror, I mean
[18:05] <cjwatson> lborda: i.e. dists/precise/main/debian-installer/binary-amd64/
[18:05] <TJ-> Anyone familiar with gnome-control-center source? I have an FTBS issue that is confusing me
[18:06] <lborda> cjwatson, haaaaaaaaaaaaa.... no i didn't...
[18:06] <cjwatson> lborda: it's not ideal that the missing URLs aren't displayed in the logs; that's worth a bug report
[18:07] <lborda> cjwatson, yeah ... i noticed that too...
[18:08] <shadeslayer> cjwatson: weird, even after modifying tasksel ( added a custom task to ubuntu-tasks ), live build doesn't seem to pick it up
[18:09] <lborda> cjwatson, , I will open up a bug on this one
[18:09] <cjwatson> I think you're confused about what tasksel's for :)
[18:09] <cjwatson> anyway, I'd need more detail on how it's not picking it up
[18:09] <cjwatson> tasksel needs to be updated because otherwise tasksel won't show the right tasks.  but it has roughly nothing to do with live-build.
[18:10] <shadeslayer> uh .... ok .... so something is wrong with my meta package then? ( it doesn't have a Task entry in the control file atm )
[18:10] <cjwatson> typically live-build gets its notion of tasks from the Packages files.
[18:10] <cjwatson> Task does not belong in debian/control.
[18:10] <cjwatson> It is supposed to be autogenerated by the archive software.
[18:10] <cjwatson> If this is all too hard then you should just tell live-build to use metapackages rather than tasks.
[18:10] <shadeslayer> hm
[18:11] <shadeslayer> cjwatson: the problem with that is that it's generating a huge poo
[18:11] <shadeslayer> *pool
[18:11] <cjwatson> being shouted at here.  cannot help you now.
[18:12] <shadeslayer> uhh ... I'm not sure how I shouted at you 0.o
[18:12] <Laney> I suspect the shouting is IRL
[18:13] <shadeslayer> oh ... ok
[18:14] <cjwatson> yes, I have children and it's dinnertime.
[18:14] <cjwatson> anyway, I have no idea why using metapackages might be related to generating a huge pool; you're probably in the best position to dig into that
[18:15] <cjwatson> when you're responsible for image building for a distribution you kind of get used to diagnosing this kind of thing :)
[18:15] <cjwatson> but it's very hard to do without being in front of the failing build
[18:17] <shadeslayer> cjwatson: understandable :)
[18:17] <shadeslayer> anywho, still looking into it
[18:17] <cjwatson> you could dig up the old cron.germinate from Launchpad from before it was converted to be a more native Launchpad script, I suppose, and wire that in to generate Task fields
[18:18] <cjwatson> but if you aren't already familiar with it I suspect that would be a fair bit of work ...
[18:18] <cjwatson> and it's not obvious it makes sense unless you're operating at an Ubuntu kind of scale
[18:19] <shadeslayer> :)
[18:19] <shadeslayer> afaictl, add_package pulls the meta package during the binary stage of the ISO build as well
[18:20] <shadeslayer> so all the debs get downloaded again, and you get a huge pool of packages on the CD
[18:20] <shadeslayer> right now, I've done a bit of hackery to check if that works
[18:23]  * shadeslayer might switch to apt-ftparchive if he can't figure out what's wrong with reprepro
[18:23] <lborda> cjwatson, where do I get the debian-installer packages files?
[18:23] <lborda> cjohnston, I do have inside main this: ubuntu/dists/precise/main/binary-amd64/
[18:24] <lborda> cjwatson, I do have inside main this: ubuntu/dists/precise/main/binary-amd64/
[18:37] <TJ-> Anyone help with FTBS gnome-control-center: "error: ‘cc_shell_marshal_VOID__VOID’ undeclared" ... there's a weird cc-shell-marshal.list containing "VOID:VOID" which seems related but I cannot find any way to build a header file from it using the debian/rules
[18:39] <dobey> TJ-: there should be a cc-shell-marshal.[ch] which get built automatically during the build; glib-genmarshal gets run to generate them
[18:40] <TJ-> dobey: Yeah, that's the problem. It's not compiling those afresh. The Makefile seems to show they should be included in the target gnome_control_center_SOURCES
[18:41] <stokachu> hi, could i get someone to approve series nomination for http://pad.lv/1036834
[18:43] <stokachu> hi, could i get someone to approve series nomination for http://pad.lv/1036834 (sorry if double post, lagged out)
[18:43] <stokachu> bryceh: are you willing to review some multi-arch patches?
[18:44] <dobey> TJ-: right, and it should also have a rule to build them
[18:47] <micahg> stokachu: I don't know that :any is allowed in binary dependencies  in precise
[18:48] <micahg> ISTR that being limited to a few packages as a build dependency only
[18:50] <TJ-> dobey: I've followed the rules from the "cc-shell-marshal.c: cc-shell-marshal.list" > MARSHAL_FILES > gnome_control_center_SOURCES >  SOURCES | DIST_SOURCES > ID | TAGS | CTAGS ... got lost there!
[18:50] <stokachu> slangasek: can you clarify micah's comment for precise?
[18:57] <TJ-> dobey: strange. Working from the bzr branch. I had to "touch shell/cc-shell-marshal.list" to get it to rebuild
[19:22] <TJ-> With gnome-control-center doing "bzr builddeb -S" results in "OSError: [Errno 2] No such file or directory: '<path>/INSTALL'". I'm trying to figure out why since that file isn't in the original bzr branch. However, it is listed in Makefile.am "MAINTAINERCLEANFILES="
[19:22] <TJ-> Does this require a patch to Makefile.am too, in order to successfully build the source package ready for uploading?
[19:25] <lborda> cjwatson, yes it works now! I am using apt-mirror for doing that! tks!
[19:26] <bryceh> stokachu, I'm not the best to review multi-arch srus.  the few I've dealt with I've run by slangasek.
[19:27] <stokachu> bryceh: ok np, thanks for the quick reply
[19:27] <bryceh> stokachu, but I can definitely help with the sru mechanics if you get the multiarch bits squared with him
[19:28] <stokachu> bryceh: ok sounds good ill talk with him to see when he has some free time
[19:29] <stokachu> micahg: wouldn't allowed mean either or?
[19:42] <micahg> stokachu: it's your premise that I had an issue with, not allowed per se, anyways, I have to go, but will check scrollback later
[19:44] <stokachu> micahg: sorry i wasn't suggesting anything was just trying to understand
[20:16] <trism> TJ-: your branch builds fine here, might just need a bzr revert to restore the deleted files
[20:18] <TJ-> trism: Thanks, yes. I had my git head on and was trying to do "bzr checkout" to restore the working tree... what foxed me was "bzr log -n 0 INSTALL" wasn't showing any history for that file, which made me think it had never been in bzr
[20:19] <TJ-> trism:  and a previous fakeroot debian/clean had invoked the maintainer_clean which had removed that file, grrr
[22:53] <cjwatson> lborda: glad to hear it
[22:55] <infinity> cjwatson: *nudge*
[22:58] <cjwatson> infinity: you'll have to wait a bit ...
[22:58] <infinity> cjwatson: S'all good.  elmo found himself a workaround.
[23:58] <bryceh> @pilot out