[02:47] <dpb1> Anyone lurking?  Could that awesome ci test result thing post comments to MPs whenever it runs, and not just in failure case?  Or does it already do that and I'm missing it?
[03:45] <tvansteenburgh> dpb1: i think it does, e.g. https://code.launchpad.net/~hloeung/charms/precise/apache2/ssl-security-options/+merge/233877
[03:46] <dpb1> tvansteenburgh: ah cool... just doesn't test everything I guess
[03:46] <tvansteenburgh> dpb1: yeah i think the integration between RevQ and CI isn't fully automated yet
[03:47] <dpb1> tvansteenburgh: ok, thanks.  sure is nice when it happens. :)
[03:47] <tvansteenburgh> dpb1: glad you like :)
[03:57] <jose> tvansteenburgh: want me to fire a test?


[00:00] <Odd_Bloke> jelmer: Are they general changes, or bzr-git specific ones?  (i.e. will they be forwarded upstream?)
[00:00] <a7p> bpeterson, and you do get the progress bar?
[00:00] <bpeterson> yes
[00:00] <a7p> something really seems to be messed up here ...
[00:00] <a7p> :(
[00:01] <jelmer> Odd_Bloke, they're generic
[00:01] <bpeterson> as in [                          ] Transferring ?
[00:03] <Odd_Bloke> jelmer: Do you think it's worth getting the package uploaded and waiting for the patches to make it into mainstream (as bzr-git isn't production-ready yet anyway), or would you prefer them to be included in the packaging and forwarded upstream that way?
[00:03] <a7p> bpeterson, exactly, that's the thing I am talking about.
[00:03] <bpeterson> a7p: it's not doing anything if that's what you mean
[00:05] <a7p> not even [ .. ] get's displayed here ...
[00:05]  * a7p will read the manual and come back in a few minutes
[00:05] <bpeterson> maybe your terminal is messed up
[00:07] <a7p> works fine with anything else ... and I did not change anything from the defaults ...
[00:07] <a7p> but nevertheless, likley ..
[00:08] <a7p> -v also gives me nothing
[00:08] <a7p> ahhh ...
[00:09] <jelmer> Odd_Bloke, I don't think it's worth bothering to include them in the package atm
[00:10] <Odd_Bloke> jelmer: OK, that makes my life easier for the time being. :)
[00:16] <bpeterson> a7p: the branch complete successfully for me
[00:18] <a7p> bpeterson, okay, thanks for your help ... something really seems to be messed up with my MacOS installation ...
[00:20] <Odd_Bloke> jelmer: If you have time, I'd appreciate you giving the package a quick once over, as it's the first package I've created from scratch. :)
[00:20] <jelmer> Odd_Bloke, is there a bzr branch I could review ? (-:
[00:21] <Odd_Bloke> jelmer: I haven't made the jump to using bzr to version my packages.
[00:21] <Odd_Bloke> (So no. ;) )
[01:04] <a7p> mmm ... does not work in xterm either ... so I guess I can exclude terminal-compatibility problems.
[01:12] <Verterok> hi
[01:12] <Verterok> a7p: are you still having problems with bzr-eclipse branch?
[01:17] <Verterok> a7p: I'm upgrading the branch to packs ATM
[01:29] <a7p> Verterok, I'll give it another try
[01:29] <a7p> Verterok, but my MacOS-bzr installation seems to be at least partial guilty ..
[01:30] <Verterok> a7p: it's still upgrading, I'll let you know when it's done
[01:30] <a7p> Verterok, thank you very much.
[01:30] <Verterok> a7p: are using the Tiger DMG?
[01:30] <a7p> no, Leopard
[01:31] <Verterok> a7p: I asked, because I'm the maintainer of  the Tiger DMG :)
[01:32] <a7p> sorry, do not have a tiger at hand.
[01:32] <a7p> Verterok, but your bzr displays the progress bar, doesn't it?
[01:34] <Verterok> a7p: it did the last time I tested it (I'm using bzr.dev ATM)
[01:34] <Verterok> a7p: did you upgraded bzr from a previous dmg install?
[01:35] <a7p> Verterok, nope, fresh install ..
[01:37] <a7p> Verterok, strange the progressbar ist displayed when I co with --lightweight ...
[01:38] <a7p> I'll give the trunk a try, see if my problem is fixed there.
[01:39] <Verterok> a7p: maybe it's a knit<->packs problem (I'll digg the reported bugs)
[01:47] <Odd_Bloke> Is there any chance I could get http://blog.daniel-watkins.co.uk/tags/Planet%20Bazaar?flav=rss added to Planet Bazaar?
[01:51] <jelmer> Odd_Bloke, please mail poolie
[01:56] <awmcclain> I have a remote, read-only SVN repo. I've created a bzr branch from it, made changes, and checked them in. Now, I want to use bzr diff to make a patch of all the changes I've checked in against the HEAD revision of the svn repo; how do I do that?
[01:58] <Odd_Bloke> jelmer: Will do.
[01:58] <Odd_Bloke> Thanks. :)
[01:58] <a7p> Verterok, just gave 1.6b4 a try - it works fine
[01:58] <Verterok> a7p: great to know
[01:58] <a7p> Verterok, am able to checkout bzr-eclipse and the progress-bar gets displayed.
[01:59]  * Verterok wonders if it's time to build a 1.6bx DMG for tiger
[01:59] <Verterok> a7p: the upgrade to packs is still running :P
[02:02] <jelmer> awmcclain, bzr diff -rbranch:svn://....
[02:02] <a7p> thought so, got a warning from the new bzr.
[02:02] <a7p> so, thanks for your help and the trunk-hint ... have to sleep now
[02:03] <awmcclain> jelmer: Ah, of course. Thank you. When you branch off of an svn repo, does it save the original path anywhere?
[02:03] <jelmer> awmcclain: .bzr/branch/branch.conf should contain the original url
[02:03] <awmcclain> Hrm, empty.
[02:04] <a7p> one more thing *g* ... should I file a bug for the nonexitant progress bar and the knit fail of bzr 1.5?
[02:04] <awmcclain> Nm
[02:04] <awmcclain> i'll just look it up again
[02:06] <awmcclain> jelmer: Any way to see what SVN revno I originally branched from?
[02:10] <Verterok> a7p: I assume it'll be marked as fixed, but do it anyway if you think it should be there for ccurrent 1.5 users :)
[02:13] <a7p> okay.
[02:13] <a7p> gn8
[02:15] <jelmer> awmcclain; in newer versions of bzr-svn, the revno is listed in "bzr log"
[03:43] <rocky> is there anything similar to psvn.el for bzr/emacs ?
[03:44] <bob2> does vc-bzr.el count?
[03:45] <rocky> not really ;)
[03:46] <bob2> vc in recentish emacs cvs (or bzr;) has apparently incirporated incorporated some psvn features
[04:04] <rocky> weird... anyone using DVC because i have no idea where to begin with it
[04:17] <mtaylor> rocky: ?
[04:17] <rocky> nvm ;)
[04:17] <rocky> decided i'll stick with cmdline bzr until i get familiar enough with it
[04:18] <mtaylor> fair enough
[04:47] <ToyKeeper> rocky: Bzr has lots of good documentation, plus built-in help.  'bzr help' or 'bzr help commands' is a good place to start.  :)
[07:42] <Ryan52> Can I combine 2 commits somehow?
[07:44] <bob2> you could branch from before the first one, then merge them in together
[07:44] <Ryan52> then will there be no way to tell that it was ever 2 separate commits?
[07:44] <Ryan52> (that's what I'm trying to get...)
[07:44] <bob2> no
[07:46] <luks> if they are the last commits on the branch, you can just uncommit twice and then commit
[07:49]  * Ryan52 will try that next time
[07:49] <Ryan52> thanks
[08:17] <markh> is anyone able to help me diagnose why bzr-svn says "not a branch" for a URL that svn is working fine with?
[08:31] <dwt> Hey guys, I'm having a problem compiling the bzr-svn exgtension on mac os x
[08:31] <dwt> because I't complains that my svn libraries are not fat
[08:31] <dwt> but instead thing (only for i368)
[08:32] <dwt> but I couldn't find a way to teach setup.py to only build i368 binaries
[08:32] <dwt> as a result of this, bzr now always segfaults when loading
[08:32] <dwt> which makes it a bit hard to use...
[08:35] <bob2> markh: is bzr-svn working in general?
[08:36] <markh> bob2: I'm not sure to be honest
[08:36] <markh> I'm trying to find out :)
[08:37] <markh> I'm on windows, but there are no obvious deps missing.
[08:37] <bob2> bzr selftest -s bzrlib.plugins.svn
[08:38] <markh> ouch - "exceptions.ImportError: cannot import name make_file_knit"
[08:38] <markh> hrm
[08:39] <bob2> are you using bzr.dev?
[08:40] <markh> yeah, about a week or so old
[08:41] <bob2> and which version of bzrsvn?
[08:42] <markh> latest I could find - 0.4.10 - but it complains about being too old
[08:42] <bob2> get the bzr-svn 0.4 branch
[08:42] <bob2> I'm pretty sure bzr.dev generally requries dev bzr-svn
[08:43] <markh> ok cool, thanks.  I'm actually trying to package windows binaries, so was trying to stick to "known" versions when I could - I'll give that a go.
[08:43] <bob2> then you'd want bzr 1.5 and bzr-svn 0.4.whatever
[08:44] <markh> trying to package ready for 1.6 ;)
[08:45] <markh> and include the current state of tortoise which I'm working on. I'm hoping to be able to include the svn plugin as a convenience.
[08:45] <markh> and trying to learn how it working in the meantime :)
[08:49] <bob2> you want 0.4.11, which is unreleased
[08:49] <bob2> so 0.4 trunk
[10:01] <dwt> Ping.... can anyone help me with my bzr-svn compile problem?
[10:02] <bob2> !sunday
[10:04] <dwt> bob2: so thats the problem... nobody in. :)
[10:04] <dwt> ?
[10:08] <bob2> it's the weekend, yo'll have better luck during the week or asking on the list
[10:10] <dwt> ah well, probably.
[10:11] <dwt> Thanks for the answer bob2!
[10:15] <AnMaster> well I'm in but I never used bzr-svn
[10:15] <LarstiQ> dwt: I have never seen that error.
[10:16] <LarstiQ> dwt: so I'm not sure what exactly the problem is, could you elaborate on it a bit?
[10:16] <dwt> LarstiQ: Well, I'l paste a complete build log if you like - maybe I'm hunting for completely the wrong thing
[10:16] <LarstiQ> dwt: sure, I can try and look at that.
[10:16] <dwt> uhm, which paste is preffered here?
[10:16] <LarstiQ> dwt: your libsvn is i386 only?
[10:17] <LarstiQ> ubottu: paste?
[10:17] <dwt> jup, installed via fink
[10:17] <LarstiQ> dwt: I don't really care, use rafb.net/paste/ myself
[10:17] <dwt> thx
[10:18] <dwt> http://rafb.net/p/XJZq9w38.html
[10:21] <LarstiQ> I see.
[10:21] <dwt> its a bit strange really, if I look at the backtrace of the crash
[10:21] <dwt> it looks like its really the libsvn that has the error
[10:21] <LarstiQ> dwt: I'd be interested to know where setup.py gets its gcc line from, notably the -arch ppc
[10:21] <dwt> http://rafb.net/p/p4boYu29.html
[10:21] <dwt> yeah, me too.
[10:21] <dwt> :)
[10:22] <dwt> the setup.py file itself doesn't contain a thing in this direction, sadly.
[10:22] <dwt> So it probably is something from distutils.extension
[10:23] <LarstiQ> dwt: what does apr-config give you?
[10:23] <LarstiQ> dwt: apr-config --cflags  I guess
[10:23] <dwt> -g -02
[10:23] <dwt> :/
[10:24] <LarstiQ> ok, that's not it then
[10:25] <LarstiQ> dwt: can you print the repos SvnExtension extra_compile_args?
[10:25] <dwt> just a second
[10:27] <dwt> looks innocent too:
[10:27] <dwt> kwargs: {'libraries': ['svn_client-1', 'svn_subr-1'], 'extra_link_args': ['-L/sw/lib', '-lapr-0'], 'library_dirs': ['/usr/lib'], 'include_dirs': ['/sw/include/apr-0', '/usr/include/subversion-1']}
[10:28]  * LarstiQ dives further into distutils
[10:29] <dwt> is there a way to get those out after distutil did it's magic with them?
[10:30] <LarstiQ> dwt: to test if it is really the fatness of the lib, you can rerun the gcc commands yourself, without -arch ppc
[10:31]  * dwt slaps his head
[10:31] <dwt> why didn't I think of that before?
[10:31]  * LarstiQ still searches on for distutils knowledge
[10:31] <dwt> I'l try that
[10:31] <LarstiQ> dwt: it's early? :)
[10:31] <dwt> true...
[10:32] <dwt> LarstiQ: I did have a nice breakfirst with self-baked bread before though.
[10:32] <dwt> :)
[10:33] <LarstiQ> dwt: also, try: from distutils.sysconfig import get_config_vars; get_config_vars()['CFLAGS']
[10:33] <LarstiQ> dwt: ooh
[10:34]  * LarstiQ skipped breakfast today since he is going to a Nepalese restaurant for lunch in half an hour (and I got up at 11.00)
[10:35] <dwt> :)
[10:35] <dwt> LarstiQ: Well, no luck there either:
[10:35] <dwt> Get Config Vars: -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE
[10:36] <dwt> not even in any of the config vars. :/
[10:39] <LarstiQ> ah, but that does mean it is gcc $CFLAGS -arch stuff etc
[10:41] <dwt> LarstiQ: Sorry, I don't follow...
[10:41] <dwt> ah
[10:41] <dwt> got it
[10:41] <dwt> still unsure where it comes from though
[10:42]  * LarstiQ plods on
[10:49] <LarstiQ> dwt: hmm
[10:49] <LarstiQ> dwt: do you have $CFLAGS set in your env?
[10:50] <dwt> LarstiQ: well, not at all: echo $CFLAGS
[10:50]  * dwt returns nothing
[10:50]  * dwt is currently looking at the distutils source of Extension.py
[10:52] <LarstiQ> dwt: I'm looking at syconfig.py customize_compiler()
[10:53] <LarstiQ> dwt: how about CCSHARED?
[10:53] <dwt> the environment variable?
[10:53] <dwt> no env of that name here
[10:53] <LarstiQ> yes
[10:53] <LarstiQ> hmkay
[10:54] <LarstiQ> dwt: does it still segfault if you build thin by hand?
[10:54]  * LarstiQ starts rounding up to leave the house
[10:54] <dwt> damn, I'm not done with that yet
[10:54] <dwt> I'l hurry
[10:56] <bob2> not using distcc or ccontrol or anything?
[10:58] <dwt> bob2: Not that I know of
[10:58] <dwt> LarstiQ: Compiling it by hand, it still segfaults
[10:58] <dwt> not sure thogh that distutil isn't doing any more commands it doesn't show on the shell
[10:59] <LarstiQ> right
[10:59]  * LarstiQ runs off
[10:59] <LarstiQ> dwt: maybe jelmer has an idea
[10:59] <dwt> He probably has. :)
[10:59] <dwt> Thanks a lot for your help though!
[11:00] <dwt> jelmer: you don't happen to be around?
[11:18] <_amanica_> jelmer: Is the loggerhead and bzr-gtk bundles supposed to show up in bundle buggy?
[11:20] <_amanica_> because I know that bundle buggy can now support multiple projects, but I'm not sure how one is supposed to know from the frontend which bundles are for which project..
[11:29] <jelmer> dwt, Hi
[11:29] <jelmer> dwt, I'm around but I have no idea about Mac OS X
[11:30] <dwt> jelmer: well, first Thanks for answeing
[11:30] <dwt> and second: after investigating this a bit it doesn't seem so much like a problem of building fat binaries vs thin binaries
[11:30] <dwt> burt more like maybe a bug in the bindings
[11:30] <dwt> which causes a null pointer to be used
[11:31] <dwt> jelmer: Maybe you could have a look at the stacktrace after a crash? http://rafb.net/p/p4boYu29.html
[11:31] <dwt> I had a look at initrepos in repos.c - and it did look innocent to me - but I don't know the subversion libraries at all
[11:32] <dwt> so maybe you can see something there
[11:35] <jelmer> dwt: not sure what could be buggy there
[11:36] <jelmer> dwt, so it could indeed be a local issue
[11:37] <dwt> maybe my svn libraries are buggy?
[11:37] <dwt> I'm still on 1.5.0 something
[11:37] <dwt> and not on 1.5.1
[11:37] <dwt> Do you know anything there?
[11:40] <jelmer> dwt, not sure, it seems strange this sort of bug would end up in a release
[11:40] <jelmer> dwt, I would suspect it's related to Mac OS X
[11:40] <dwt> ok, thanks a bunch
[11:40] <dwt> I'l look into this more
[11:40] <dwt> if I see something I'l report it back here
[15:44] <mrZeby> hi all
[15:44] <mrZeby> there is somebody here ?
[15:47] <mrZeby> somebady read me ?
[15:49] <bob2> hello
[15:51] <mrZeby> hello bob2 thanks for answering... i just would to be sure my irc client run correctly :-) have a nice day.
[16:22] <nico-inattendu> Hi, i m a almost newbie on bazaar i try to set up a Distributed development workflow. And i ahave som e questions on the usage? and when to make commits. In the example given in tutorial http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#distributed-development , a branch mirror is created , then each modifications are made in new branches ( features branch). But i don't understand  what action to do when a modification is d
[16:23] <bob2> (truncated after "modification isd")
[16:44] <luks> anyway what's causing this: bzr: ERROR: Directory not empty: "/srv/bazaar.launchpad.net/push-branches/00/00/1d/59/.bzr/repository/lock/lzvfsm4v4t.tmp": [Errno 39] Directory not empty ?
[16:44] <luks> on bzr push
[16:44] <luks> oh, nevermind, it's probably a new "repository locked" message
[17:18] <Peng_> Is it possible to convert a lightweight checkout to a stacked branch?
[17:23] <bob2> reconfigure?
[17:23] <Peng_> Really? Where do you set what it's stached on?
[17:23] <Peng_> stacked*
[17:28] <jelmer> Peng_: i would imagine it would create a new branch that is stacked on the branch your lightweight checkout is using
[17:37] <Peng_> I'm just not seeing this.
[17:38] <Peng_> "bzr reconfigure --tree" obviously turns it into an independent branch. Where do you tell it to stack?
[17:39] <Peng_> Oh, right, isn't stacking on rich-roots broken anyway?
[17:42] <jelmer> Peng_: I would imagine it to be possible to use a --stacked argument to reconfigure
[17:42] <jelmer> not sure if such a argument is there yet though
[17:43] <Peng_> jelmer: There isn't one in the help
[17:44] <Peng_> Yeah, there isn't one.
[17:50] <Peng_> Is it supposed to be possible to run "bzr branch --stacked some_rich_root_pack_url"?
[18:00] <jelmer> Peng_: yes
[18:07] <Peng_> I think there's a bug open about it?
[20:17] <Peng_> jelmer: Is it just me, or is "bzr log" not showing the svn revisions anymore?
[20:17] <jelmer> Peng_, I think it's you :-)
[20:18] <jelmer> Peng_, you mean the "svn revno" entries in bzr log, right?
[20:18] <Peng_> :(
[20:18] <Peng_> jelmer: Yes.
[20:18] <Peng_> Great, it works on one branch, but not another.
[20:19] <Peng_> In fact, it works on one branch of the project, but not another.
[20:19] <Peng_> jelmer: It doesn't show it on new revisions I just pulled, but it does on older revisions.
[20:19] <jelmer> Peng_, it doesn't list them for revisions that have been created with bzr
[20:20] <Peng_> jelmer: They weren't.
[20:20] <jelmer> Peng_, does "bzr log --show-ids" show svn-v3: revids?
[20:20] <Peng_> jelmer: No.
[20:21]  * Peng_ blinks.
[20:21] <jelmer> are you sure that branch was created with bzr-svn?
[20:21] <Peng_> Yes...
[20:22] <Peng_> I've had the branch for months, and I frequently "bzr pull" new revisions from svn.
[20:22] <jelmer> what do the revids look ?
[20:22] <Peng_> Like normal bzr revids.
[20:24] <jelmer> that would suggest the branch you pull from is either a regular bzr branch or the revisions in svn were created with bzr
[20:24] <Peng_> Ahh.
[20:24] <jelmer> or perhaps it's not a bzr-svn branch but a launchpad import ?
[20:24] <Peng_> The developers are transitioning to bzr-svn, so that's probably it.
[20:24] <jelmer> ahh
[20:25] <jelmer> it's not possible to retain the svn revno for that sort of revision since revisions are immutable
[20:26] <Peng_> Yeah, they were made using bzr.
[20:26] <Peng_> Thanks. :)
[20:37] <awilkins> markh: bzr-svn win32?
[21:44] <awilkins> markh: ping?
[23:55] <poolie> hello all


[01:56] <lotuspsychje> good morning
[06:12] <ducasse> good morning
[07:00] <lordievader> Good morning
[19:53] <TJ-> Bashing-om: I re-covered ownership of squoo.sh a while back (accidentially lost it due to a registrar/expiry nmotifcation loss) - might be something we could use to create a 'hackers corner' to test things out and count visitors ?
[19:58] <Bashing-om> TJ-: Sure ! Glad ya re-implemented the channel. Lemme get UWN out and I be back - kinda pushed presently to meet my deadline :P
[19:59] <TJ-> OK, I'm off to bed in a few minutes so there's no rush!
[20:08] <daftykins> TJ-: squoo.sh those bugs!
[20:09] <TJ-> :) With a few of the projects we're working on recently it made me think to revive it in some way, but not for 'free' support :)
[20:16] <Bashing-om> UWN: issue 698 is on the streets: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue698 .
[20:18] <sarnold> woot
[20:21] <TJ-> the biggest problem with the newsletter is ...
[20:21] <TJ-> ... cannot wrap our fish & chips in it!
[20:21] <TJ-> (UK centric joke!)
[20:29] <daftykins> :D
[20:29] <daftykins> i haven't gone to a chippy in ages, cor
[20:30] <sarnold> hmm, have I had fish and chips more recently than daftykins??
[20:31] <daftykins> well i have my home oven variant of course, which the cat takes her tax of... but i've not gotten a takeaway form
[20:31] <daftykins> their chips are just always soggy :(
[20:35] <sarnold> awwwww
[20:35] <sarnold> the place my family went yesterday has *beer battered* fries, so very good
[20:36] <daftykins> :O
[20:37] <TJ-> my chips are famous :) As is my speed-peeling of potatoes fresh from our fields
[20:38]  * daftykins shudders at the manual labour
[20:38] <daftykins> hmm now i'm imagining your saying "chip shortage, not 'round 'ere!" ;)
[20:40] <Bashing-om> TJ-: squoo.sh (#,##) not found - a work yet in progress ?
[21:23] <TJ-> where'd you get that?
[21:27] <Bashing-om> TJ-: " I re-covered ownership of squoo.sh" :D
[21:29] <TJ-> daftykins: no chip shortage here; we pick all the 'cracks' that the factories won't take - over-large potatoes some almost the size of a rugby ball. 1 of those makes a meal for 6
[21:31] <daftykins> ooh, can you take a pic of a huge spud for me sometime? that'd be amusing to see


[01:53] <tsimonq2> So is it intentional that I can't clone bzr branches from https but I can from http?
[01:54] <wgrant> tsimonq2: Yes. It's recommended to use bzr+ssh.
[01:54] <wgrant> HTTPS is supported for git, but the only secure option for bzr is bzr+ssh
[01:54] <tsimonq2> Alright.
[01:55] <tsimonq2> wgrant: See the discussion in #ubuntu-release for why I ask, interesting case :)
[13:39] <rbasak> cjwatson: we're downloading Sources files to work out what source packages exist and what component they're in for mass import purposes (allowing us to ramp up, etc). But these are plain HTTP downloads. Do you have any opinion on whether and how we should validate the downloads? Eg. if we verify gpg signatures, then what keyrings can we use, given we are also pulling historical series?
[13:39] <rbasak> At the moment I think we're only looking at active Ubuntu series and sid, but eventually we'll need to expand that.
[13:40] <rbasak> Or is this overkill? If we're just getting source package names and component names and then hitting Launchpad securely, then we can only be DoS'd I think maybe.
[13:40] <cjwatson> rbasak: The two "Ubuntu Archive Automatic Signing Key" keys in /usr/share/keyrings/ubuntu-archive-keyring.gpg are the only ones that have ever been used to sign the archive.
[13:41] <cjwatson> I'd verify using those.
[13:41] <rbasak> Thanks. Do you happen to know about Debian?
[13:42] <cjwatson> A much larger set.  A current debian-archive-keyring package goes back a fair way at least
[13:42] <cjwatson> You might have to basically union all the debian-archive-keyring versions you can find
[13:42] <rbasak> OK. Is there any tooling we could use to help with the validation?
[13:42] <rbasak> Something easier than setting up chdist would be nice :)
[13:42] <cjwatson> /usr/share/keyrings/debian-archive-removed-keys.gpg goes back to 2004
[13:43] <cjwatson> Not sure, sorry
[13:43] <rbasak> OK. Thanks!
[15:17] <ricotz> cjwatson, hi, is it possible to treat the pending firefox 58 beta builds like the 57.0.4 security builds? they also target "spectre" -- https://launchpad.net/%7Emozillateam/+archive/ubuntu/firefox-next/+packages
[15:41] <Merlijn_S> FYI: I came here to ask if the build farm is disabled. The topic answered my question but are you aware that `launchpad.net/builders` reports 0 disabled, 198 available?
[15:41] <teward> "198 available build machines, 0 disabled and 81 building of a total of 198 registered."
[15:41] <teward> Merlijn_S: i fail to see what's wrong here?
[15:42] <Merlijn_S> Topic is
[15:42] <Merlijn_S> > Build farm disabled for maintenance; no ETA yet
[15:42] <teward> they can put that back to the way it was, but it *looks* like it's 'up'?
[15:43] <Merlijn_S> All my builds are estimated to complete in 1 hour. If I schedule a build, the estimated complete time just keeps incrementing every x minutes
[15:44] <Merlijn_S> Ex: https://code.launchpad.net/~communitheme/+archive/ubuntu/ppa/+recipebuild/1513026
[15:44] <teward> build priority impacts this
[15:44] <Merlijn_S> and https://code.launchpad.net/~communitheme/+archive/ubuntu/ppa/+recipebuild/1513080
[15:45] <acheronuk> sysadmin said yesterday they were putting the builders on 'manual'
[15:45] <teward> acheronuk: are they still on manual?
[15:45] <acheronuk> if you look at what is building, it's archive test rebuild backlog, and security team builds
[15:46] <acheronuk> so I would guess they ahve been judged to be safe
[15:46] <acheronuk> other stuff still seems on hold
[15:47] <acheronuk> cjwatson wgrant: correct?
[15:51] <acheronuk> I could be wrong :P
[15:51] <acheronuk> weird that the test rebuilds now have a priority of > 100,000
[15:51] <acheronuk> normally they are tiny or -ve
[15:53] <acheronuk> maybe giving the canonical stuff stupidly high scores was the best way to selectively re-enable?
[15:53]  * acheronuk shrugs
[15:59] <dobey> i think only trusted things are allowed to build right now
[15:59] <acheronuk> yes. whatever way that is being done, I would say so
[15:59] <dobey> ie PPAs are untrusted
[16:00] <Merlijn_S> ok, thanks for the explanation
[16:01] <Merlijn_S> Is there any place where I can receive updates on the state?
[16:01] <dobey> you can follow the launchpad status account on twitter, or check the topic in here i guess
[16:02] <dobey> https://twitter.com/launchpadstatus/status/948688233029881856
[16:03] <Merlijn_S> thanks, didn't know about that :)
[16:03] <acheronuk> might not be quick to sort: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown
[16:03] <acheronuk> that early disclosure 'bites'
[16:04] <teward> dobey: that's problematic for me, I have an nginx merge I need to build test.
[16:05] <teward> and i usually spin the multiarch build tests via PPA.  I presume it's nontrivial to permit a single thing to build then :/
[16:06] <dobey> teward: well i guess you can build locally with sbuild, or try to hunt down someone with privileges to maybe allow the build. but i'd suggest the people in that latter category would be better spending their time on the task at hand to get things back up and running
[16:06] <teward> dobey: the problem is the oddball archs
[16:06] <teward> sbuild isn't nice with some of the non-arm oddball archs, at least on my system
[16:07] <teward> i'll test locally and hope things don't explode when uploaded to -proposed
[16:07] <teward> i presume also that the proposed uploads (for, say, merges) are also on hold?
[16:07] <dobey> i think so
[16:07] <acheronuk> I would guess so
[16:07] <dobey> all i know is the world exploded
[16:08] <acheronuk> my last uploads to bionic are going no-where
[16:26] <cjwatson> ricotz: I think I'd need to consult on that, since they're non-Canonical uploaders
[16:27] <cjwatson> Merlijn_S: We basically put emergency measures in place so the UI isn't everything it could be
[16:28] <cjwatson> acheronuk: Manually scoring those up as a way to get them to build, yes; it's not that they're urgent, but they're low-risk and we might as well drain the queue while not much else is happening
[16:28] <acheronuk> makes sense :)
[16:28] <ricotz> cjwatson, i think you could consult chrisccoulson
[16:28] <teward> cjwatson: is there details on what exploded?
[16:29] <cjwatson> ricotz: Yeah, just did, will enable in a bit
[16:29] <cjwatson> teward: Well uhhhh you could consult pretty much any of the tech press
[16:29] <ricotz> cjwatson, thank you, firefox-trunk is basically the same if there are free cycles
[16:29] <teward> i'm more or less hunting context (if you mean Spectre and Meltdown, well, that's its own little beast)
[16:30] <teward> cjwatson: i'm a little late to catching up on things ;)
[16:30] <cjwatson> ricotz: I'd like to keep it to a minimum in terms of PPAs; firefox-trunk doesn't seem super-urgent for getting fixes out to users
[16:31] <ricotz> cjwatson, yeah, that is fine, the beta is far more used
[16:31] <dobey> teward: yeah, being able to exfiltate the signing keys from launchpad would not be a good thing
[16:31] <cjwatson> dobey: signing keys are not at risk
[16:32] <cjwatson> (but I'm not going to go into more detail)
[16:33] <cjwatson> ricotz: firefox-next should be building now/soon
[16:34] <ricotz> cjwatson, thank you
[18:02] <tsimonq2> cjwatson: Are livefses for e.g. Lubuntu dailies whitelisted?
[18:04] <tsimonq2> cjwatson: If not, would it be possible to do so, or should we consider dailies no-go for now?
[18:56] <cjwatson> tsimonq2: No-go for now, sorry.
[19:09] <tsimonq2> cjwatson: Alright, understandable, thanks
[19:49] <nacc> cjwatson: hey, so I finally heard back from the keyring folks re: https://github.com/jaraco/keyrings.alt/issues/23, which I think I was triggering with git-ubuntu's launchpadlib and the file keyring. It seems like the keyring backends, at least with Python3, are expecting a unicode string, not a base64 encoded string (a la credentials.py::KeyringCredentialStore.do_save(). Do you want a bug for that?
[20:24] <cjwatson> nacc: Didn't you already file one?  https://bugs.launchpad.net/launchpadlib/+bug/1685962
[20:26] <nacc> cjwatson: ah so i did! :)
[20:26] <nacc> cjwatson: sorry for the noise!
[20:26] <cjwatson> a cross-reference in that bug would be good though
[20:27] <nacc> cjwatson: yep, doing so now
[20:27] <cjwatson> I have the obvious patch in my working tree so can chase that up
[20:27] <nacc> cjwatson: thanks!
[20:57] <mitya57> nacc, cjwatson: there is also bug 1685547, maybe one of them should be marked as duplicate?
[21:16] <nacc> mitya57: thanks, definitely a dupe one way or the other
[21:16] <nacc> mitya57: sorry i did't see that one when i filed
[22:21] <mitya57> It is filed against a different project (Ubuntu vs launchpadlib) so no need to be sorry :)


[11:59] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3898 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[12:18] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3898 Pending binary packages
[12:38] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3898 Successfully built
[15:03] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3883 Diff missing (focal/qemu). Pending binary packages (focal/libvirt)
[15:13] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[15:18] -queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, /: Failed to update local lp:nux cache., disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
[15:22] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[15:34] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[15:39] -queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
[15:43] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[15:43] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3883 Diff missing
[15:46] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3883 Generating diffs
[15:48] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3883 Successfully built
[16:01] -queuebot:#ubuntu-ci-eng- bdmurray, https://bileto.ubuntu.com/#/ticket/3896 Preparing packages
[17:32] -queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3899 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[18:40] -queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3899 Diff missing
[20:36] -queuebot:#ubuntu-ci-eng- bdmurray, https://bileto.ubuntu.com/#/ticket/3896 Successfully built


[01:54] <bullgard5> IntuitiveNipple: ping
[07:19] <kousotu> hey BenC_
[07:21] <kousotu> hey BenC
[07:21] <kousotu> lol
[07:21] <kousotu> playing msical nicks are we?
[08:07] <Mithrandir> BenC: (or somebody else): do we have any idea what the kernel version we'll be wanting for 8.04 is?
[08:07] <BenC> Mithrandir: most likely 2.6.24
[08:08] <Mithrandir> ok
[08:08] <Mithrandir> thanks
[12:34] <verwilst> hellow
[12:35] <verwilst> anyone have an ETA when the amd64 version of the xen kernel will be available?
[12:35] <verwilst> i know it's been patched to include amd64 in git
[12:53] <amitk> verwilst: most probably there will be a new kernel upload by the end of this week or beginning of next
[12:54] <verwilst> sweet
[02:36] <zul> gday
[05:28] <superm1> in the latest gutsy kernel there has been an abundance of unionfs errors, i looked for a bug but didn't see one, so i just wanted to double check if the unionfs maintainer was aware, or if I should still file
[05:28] <superm1> it shows up in the mythbuntu dailies (and also the ubuntu dailies)
[05:29] <zul> i think there is a bug already open but dont quote me on that
[05:29] <superm1> the only one i was finding was https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/138866
[05:29] <superm1> but thats not exactly the same
[05:34] <evand> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/138915
[05:35] <superm1> i'll add a dmesg and syslog to that bug as well
[05:37] <evand> whoops, that was intended for #ubuntu-installer.  Sorry about that.
[05:44] <kousotu> to what channel woul ndiswrapper questions go?
[05:45] <zul> #ubuntu
[05:45] <kousotu> figures...
[05:45] <kousotu> the guy I'm trying to avoid is there
[05:47] <kousotu> but it's a simple enoughquestion, I'm just unsre of the answer
[05:48] <ScottK> If you were running Gutsy, you could as in #ubuntu+1
[05:48] <ScottK> as/ask
[05:49] <kousotu>  I have, and he's there too...
[05:49] <kousotu> always spiitin the same crap at me..
[05:51] <kousotu> wel, and there's thisI justnoticed: 10:21]  <IdleOne> kousotu: you should realy look into buying hardware that is supports/supported by linux
[05:51] <kousotu> I'm on a laptop, the onnly external anything I'm using in my mouse
[05:51] <kousotu> lol
[05:53] <kousotu> [10:26]  <ikonia> kousotu that kernel module is not happy
[05:53] <kousotu> (for my reader)
[05:53] <kousotu> is that a kernel issue?
[05:54] <kousotu> ScottK: I am running gutsy, fiesty doesn't like my hardware, it's too new
[05:54] <kousotu> lol
[05:55] <ScottK> OK.  Then #ubuntu+1 is the channel you want.
[05:55] <kousotu> gutsy is running beatifully, save a few minor prblems
[05:55] <kousotu> I pasted from +1
[05:55] <kousotu> [10:52]  <ikonia> kousotu thats one of the problems with linux in general, you've got to make sure you have good hardware support or you'll have problems at a very low level
[05:55] <kousotu> [10:52]  <ikonia> its jusan unfortuanate truth at the moment
[06:17] <kousotu> ScottK: maybe you cn answer my question?
[06:20] <ScottK> No, sorry.
[06:20] <kousotu> damn..
[09:16] <zul> BenC: having problems? :)
[09:16] <BenC> zul: yeah, mid-week brain farts :)
[09:17] <zul> hehe


[05:55] <acheronuk> yofel: FYI, I renewed kci.pangea.pub ssl certificate which had expired
[05:56] <valorie> aha, that's why I got a random notice that it was "untrusted"
[05:56] <valorie> thanks, yofel!
[05:59] <acheronuk> dunno it it has any autorenewal scheduled. maybe I renewed before that kicked in. anyway, should be fine for 3 more months at least
[06:00] <acheronuk> *if it