[12:23] <anavim> geez, what's with the network today?
[12:51] <BenC> anyone know how to override KERNEL_ARCH in kernel-package rules?
[02:12] <answerguy> What is the current limit on NGROUPS (number of supplemental GIDs per process) in 2.6.x?
[02:12] <answerguy> ... and are reasonably recent versions of glibc able to cope with more then 32 GIDs/proc?
[06:50] <zul> heylo
[06:51] <zul> BenC: ping
[07:47] <BenC> zul: pong
[08:09] <zul> BenC: when are you going to do a pull from me ;)
[08:09] <zul> after 2.6.15?
[08:09] <BenC> as soon as I get everything else kosher :)
[08:09] <zul> ok cool..because i have some interesting stuff in there


[00:36] <cjwatson> Please to be NEWing update-manager awesomeness.
[00:39] <slangasek> reviewinating
[00:42] <slangasek> accepted
[01:29] <stgraber> infinity: thanks
[12:03] <cjwatson> jdstrand: Are you OK with the permissions change proposed in https://lists.ubuntu.com/archives/technical-board/2012-June/001312.html ?
[12:06] <jdstrand> cjwatson: so iiuc, anyone in these teams can upload to their respective pocket, but they still need to be approved via LP? the situation now is what, an upload to -security is outright rejected?
[12:14] <cjwatson> -security is actually somewhat special beyond this, because there's a special hardcoded thing that stops you uploading directly to -security at all rather than going via a staging PPA.
[12:14] <cjwatson> But an attempt to copy a package in main to -security is I believe outright rejected right now if you aren't in -core-dev, yes.
[12:15] <cjwatson> I'm sort of pretending your specialised unembargoing tools don't exist for now because ultimately I want to be able to support it all through Archive.copyPackage.
[12:15] <cjwatson> This is one step.
[12:16] <cjwatson> For -backports, which doesn't have any of this extra complexity - yes, right now a backporter has to be able to upload the package in general or else they get outright rejected
[12:17] <jdstrand> ok, let's pretend (just for a moment, I know it's hard ;) that I don't know exactly what is changing in your commit, or all the special LP stuff. your change allows someone in these groups to upload to their pocket without being rejected from the start. your change allows that initial step to pass for later checks to be performed. is that accurate?
[12:19] <cjwatson> That's correct.
[12:20] <jdstrand> ok, I think the permissions changes are fine then at least for -security. I can't really comment on -backports because I wasn't part of that conversation, but based on your recap, they sound fine too
[12:21] <jdstrand> cjwatson: do you need me to comment in the bug?
[12:21] <cjwatson> No, that's fine, I just wanted to double-check with you before messing about with -security
[12:21] <cjwatson> The LP change is being rolled out either way, since it's harmless by itself
[12:22] <jdstrand> thanks. it doesn't open it up anymore afaics, so it looks good to me
[12:22] <jdstrand> s/anymore/any more/
[12:22] <cjwatson> It would make things a bit easier for micahg, potentially.
[12:22] <cjwatson> Oh, except that he's -core-dev now.
[12:22]  * cjwatson <- paying attention honest
[12:23] <cjwatson> But, you know, future security team members who aren't yet -core-dev.
[12:23] <jdstrand> we still have two
[12:23] <jdstrand> actually 3
[12:23] <cjwatson> Tyler and John?
[12:24] <cjwatson> Oh wow, I didn't know Steve wasn't -core-dev yet.
[12:24] <jdstrand> cjwatson: so with this change, we can use copyPackage to unembargo, then go to the LP unapproved queue to accept them?
[12:24] <cjwatson> Well.
[12:24] <jdstrand> cjwatson: sbeattie too, but we are desperately trying to fix that
[12:24]  * jdstrand pokes sbeattie
[12:24] <jdstrand> :)
[12:24] <cjwatson> In principle I'd like to say yes, but there's funny stuff around making sure stuff gets copied from the restricted librarian to the public one and I don't know if copyPackage handles that yet.
[12:24] <jdstrand> I see
[12:25] <jdstrand> well, it is a step any way, and I appreciate that :)
[12:25] <jdstrand> we added a --copy argument to our unemgardo tool to use copyPackage, so it should be easy enough to test
[12:26] <jdstrand> cjwatson: I've subscribed the team to the bug. when the change is committed, we'll have someone do a copyPackage and see how it goes
[12:26] <jdstrand> err
[12:26] <jdstrand> change is live
[12:29] <cjwatson> Hm, I think I'd kind of like to try it out in the LP test suite (or satisfy myself that it's already there) before trying it on real data :-)
[12:29] <cjwatson> I could add a permission on staging or something and you could try it there, though
[12:30] <cjwatson> That'd be better than production for this
[12:39] <Laney> I'm having a hard time reconciling queue admin and copying permission
[12:41] <cjwatson> Do expand
[12:44] <Laney> I'm not sure entirely, but it feels like the wrong model. Perhaps it's because copying to me is tied to uploading.
[12:44] <cjwatson> It is a bit of a conflation.  The reason I think it makes sense is that copying stuff around within Ubuntu is a bit more of an administrative operation.
[12:44] <cjwatson> Copying stuff from outside Ubuntu, I agree.
[12:44] <cjwatson> (Anyway, I wasn't suggesting making uploaders be unable to copy.)
[12:45] <Laney> I know, but you were suggesting making queue admins always able to copy
[12:45] <cjwatson> Copying stuff from -proposed to -updates and then having to separately go to approve it just seems kind of mad.
[12:45] <cjwatson> Well, that's the other bug, I guess.
[12:45] <Laney> yes, so I'd like bug #1006871 fixed for that
[12:45] <ubot2> Launchpad bug 1006871 in launchpad "Copying packages to -updates always goes through unapproved queue, even when copying user is privileged" [Low,Triaged] https://launchpad.net/bugs/1006871
[12:45] <Laney> and then the SRU team given permissions to manage their queues
[12:46] <Laney> and also to upload to them, which is what I was suggesting
[12:46] <cjwatson> Most of my motivation for queue admins always being able to copy is for automating auto-syncs.
[12:46] <Laney> I guess I don't see the need for this conflation
[12:46] <Laney> the auto-sync account could just be made a core-dev
[12:46] <cjwatson> It could.  It makes me jittery for some reason.
[12:46] <Laney> perhaps that is too much permission though
[12:46] <cjwatson> I know that the package-import account is a core-dev.
[12:47] <Laney> wait.
[12:47] <cjwatson> Slightly less permission would be to give it a separate blanket upload ArchivePermission.
[12:47] <Laney> yes, that
[12:47] <cjwatson> That way it at least wouldn't be able to write to core-dev branches, say.
[12:47] <Laney> to the release pocket in the dev release
[12:47] <Laney> can we express that?
[12:47] <cjwatson> But it's still a root-everything account :-)
[12:47] <cjwatson> Can't do pocket & other stuff, but it can be series-specific, yes.
[12:48] <cjwatson> Would be a bit of a hassle to have to roll it over every series, but nothing too horrible.
[12:49] <cjwatson> Oh, wait.  Better check my assumptionss.
[12:49] <cjwatson> Bah.  Packageset permissions are per-series, but component permissions aren't.
[12:54] <Laney> hmm
[12:55] <cjwatson> Another way I think about it is:
[12:55] <cjwatson>  * you can fairly easily upload stuff to a component you aren't supposed to have access to by accident
[12:56] <cjwatson>  * working around it by uploading to a PPA and then copying, to me, implies more chance of malice
[12:56] <cjwatson> So they're sort of technically equivalent in security terms but the safety-catch nature is different
[12:58] <cjwatson> It's not a massively high priority for me though: fully automating auto-syncs would be nice, but we've got along for eight years without, so meh.
[13:03] <Laney> I see the potential for abuse, but if we're just talking about the one bot account for auto-syncing then I'm not really very concerned. It would be easy enough to keep it fairly locked down.
[13:04] <Laney> Also, I thought that one of the benefits of moving to this new API is that we /wouldn't/ need a bot account for auto-syncing?
[13:04] <Laney> Archive admins just run the script on their own machine.
[13:05] <cjwatson> Well, yes and no
[13:07] <cjwatson> It means we *can* run it on our own machines, it means we don't have to run it as a user with direct Launchpad database access, it means we don't have to have a crazy scheme involving downloading source packages and pushing them through a special back door designed just for it, and it means it's a lot easier for us to improve our own tools
[13:07] <Laney> I see you might want to cron it, in which case this would be required
[13:07] <cjwatson> But it'd still be nice to be able to cron it.  I don't think that should depend on any particular archive admin, and I don't want to grant access to my Launchpad account to a cron job.
[13:08] <cjwatson> Maybe just going with blanket upload AP entries would indeed be the right answer.  I'll meditate some more, I guess.
[13:08] <Laney> So I'd a) Make a new ubuntu-autosync-bot user, b) Give it upload permissions to release (soon to be proposed), c) Give it queue admin to NEW, d) Add API to allow certain copying operations to bypass queues
[13:09] <cjwatson> a) is done, ubuntu-archive-robot
[13:09] <Laney> NEW/devel series, depending on how that goes
[13:09] <cjwatson> Actually, for c), I'd prefer NEW not to be automatic
[13:10] <cjwatson> We do wave through new auto-syncs fairly liberally, but I catch things that I don't want to auto-sync (and blacklist them or whatever) moderately frequently
[13:10] <cjwatson> If we had auto-sync --batch cronned, I'd want to be able to catch stupidity at the NEW queue admin level
[13:10] <cjwatson> Not full review or anything, just an "oh boy that package name looks kind of familiar" sort of thing
[13:11] <Laney> so you wouldn't even need it to be able to queue admin — that's even simpler, surely?
[13:11] <cjwatson> Perhaps I should remove it from ~ubuntu-archive.
[13:11] <cjwatson> I'm not sure it'll never want queue admin for something else in future.
[13:12] <cjwatson> Not for auto-syncs, but there's other stuff I want to cron.
[13:12] <cjwatson> copy-report is the most obvious one.
[13:12] <cjwatson> (Copy stuff from -security to -updates, without going through unapproved.)
[13:13] <cjwatson> But I suppose it could have queue admin AP on -updates.
[13:13] <Laney> maybe you'd want multiple users then, for protection
[13:13] <cjwatson> Possibly.
[13:13] <cjwatson> I don't think any changes set anything much in stone.
[14:32] <hggdh> skaet: shouldn't bug 949641 be re-milestoned?
[14:32] <ubot2> Launchpad bug 949641 in fglrx-installer "Installing both fglrx and fglrx-updates results in: error exit status 1 -"/etc/init.d/atieventsd exists during rc.d purge"" [Critical,Triaged] https://launchpad.net/bugs/949641
[14:33] <skaet> hggdh,  yes,  done now.
[14:34]  * skaet will dig into how that one got overlooked later today.
[14:34] <hggdh> skaet: I could have done it, but I would rather ask
[14:41] <Laney> ScottK: I think you were referring to bug #648611 (as was discussed elsewhere in the thread, and in here)
[14:41] <ubot2> Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611
[14:41] <ScottK> Laney: That's the one.
[14:41] <Laney> But the description is weird, and it doesn't talk about distroseries granularity which you requested
[14:42] <cjwatson> I don't understand why that description wants per-upload-status granularity.  Personally I'd like to avoid that.
[14:42] <cjwatson> Per-series is a bit nasty but I can understand it and it's not that far out of line with packagesets.
[14:42] <cjwatson> Although I suspect it would require a DB constraint change :-(
[14:43] <ScottK> cjwatson: I think it's reasonable to say that only ~ubuntu-archive can process New.
[14:43] <cjwatson> Is the converse also reasonable, though?
[14:43] <Laney> you probably want backporters to be able to do NEW backports
[14:43] <ScottK> True.
[14:44] <ScottK> cjwatson: I think it is.  Since I'm not (yet) in ubuntu-sru, I've go no business accepting stuff to precise-proposed except to work around the current issues where I may do it on behalf of an ~ubuntu-sru member that can't.
[14:45] <cjwatson> Hm, maybe I was unclear
[14:46] <cjwatson> I mean, I agree that it's reasonable to say that only ~ubuntu-archive can process New; but would it also be reasonable to say that anyone with queue admin privileges to some intersection of pocket/series/whatever can process New as well as Unapproved?
[14:46] <cjwatson> I care because the latter is, I think, rather easier to implement.
[14:46] <cjwatson> I could probably do the former if I must.
[14:47] <cjwatson> Anyhow, this is all about future work on queue admin privileges, not about the upload changes that just landed, so let me go and add the latter permissions now
[14:47] <Laney> Personally I think pocket & series would be fine.
[14:48] <cjwatson> Looks like I was wrong that pocket & series would require a DB constraint change.
[14:48] <cjwatson> ALTER TABLE ArchivePermission ADD CONSTRAINT one_target CHECK ((null_count(ARRAY[packageset, component, sourcepackagename, pocket]) = 3));
[14:49] <cjwatson> (Bizarre way of writing "you get only one of these".)
[14:50] <cjwatson>     parser.add_option("-p", "--person", dest="person", action="append")
[14:50] <cjwatson>     parser.add_option("-P", "--packageset", dest="packageset", action="append")
[14:50]  * cjwatson gives up on a short option for --pocket
[14:51] <xnox> cjwatson: - p̂
[14:52] <xnox> we have unicode ;-)
[14:54] <Laney> ρ
[14:54] <ScottK> cjwatson: I don't think I understand what you mean by "some intersection of pocket/series/whatever".  Can you give an example (no rush - as you say, this is about future work)
[14:56] <xnox> Laney: p-hat is visually different from -p -P
[14:57] <Laney> so's rho!
[14:58] <cjwatson> ScottK: Pocket plus zero or more intersected constraints.  Let's say, as an example, if we gave ~ubuntu-sru queue admin on -proposed, would it be reasonable to say that they could process NEW there (e.g. kernel ABI changes)?
[14:59] <ScottK> cjwatson: Yes.  I think it is.
[14:59] <cjwatson> You said the contrapositive, that it would be reasonable to say that only ~ubuntu-archive can process NEW, but you didn't say you thought the opposite was unreasonable; so I'm trying to explore that.
[14:59] <ScottK> I didn't think about that case.
[14:59] <cjwatson> If you see what I mean.
[14:59] <ScottK> Yes.
[14:59] <ScottK> Equally, I think new backports should be OK for backporters.
[14:59] <cjwatson> 'cos that way I don't have to invent some way of embedding the upload status into an archive permission.
[15:00] <cjwatson> Excellent.  I think we are in agreement on that part at least, then. :-)
[15:00] <ScottK> Ideally though in the case of backporters it would only be new for that release, not new to the archive as they aren't supposed to do that.
[15:01] <ScottK> That probably pushes things back into hard though.
[15:01] <cjwatson> I see what you mean.  Hmm.
[15:02] <Laney> We'd get that if it were pocket & series, though?
[15:02] <cjwatson> No.
[15:03] <cjwatson> There isn't sufficient distinction between new to precise-backports because it was backported from quantal and not previously in precise(-backports), and new to precise-backports because it wasn't previously in Ubuntu at all.
[15:03] <cjwatson> Which I think is what ScottK means.
[15:04] <Laney> I don't think NEW captures that at all.
[15:04] <cjwatson> It doesn't.
[15:05] <Laney> That's part of the trust that you grant when you delegate queue admin
[15:07] <Laney> Maybe NEW would also be interesting if we manage to get backports pre-release off the ground
[15:08] <ScottK> Sure, but I'd like to make the technical capability and the policy constrains match as closely as possible.
[15:08] <ScottK> Laney: Even in that case, it would still need an archive admin review.
[15:09] <ScottK> While I'm dreaming, I'd like a secondary LP login that would be the only one that has queue access.
[15:09] <ScottK> Then I could log into that only when actually processing the queue.
[15:09] <Laney> How so (if permissions are just pocket/series)?
[15:09] <cjwatson> $ ./edit_acl.py -p laney -s coreutils -S precise --pocket backports check
[15:09] <cjwatson> Iain Lane (laney) cannot upload coreutils to Precise/Backports
[15:09] <cjwatson> $ ./edit_acl.py -p ubuntu-backporters --pocket backports add
[15:09] <cjwatson> Added:
[15:09] <cjwatson> Archive Upload Rights for ubuntu-backporters: archive 'primary', pocket 'Backports'
[15:10] <cjwatson> $ ./edit_acl.py -p laney -s coreutils -S precise --pocket backports check
[15:10] <cjwatson> Iain Lane (laney) can upload coreutils to Precise/Backports
[15:10] <bdmurray> SpamapS: how far through the precise queue did you get?
[15:10]  * Laney gets to it
[15:10] <cjwatson> You were a handy example from sorted(set(p.name for p in lp.people['ubuntu-backporters'].members) - set(p.name for p in lp.people['ubuntu-core-dev'].members)) :-)
[15:11] <cjwatson> $ ./edit_acl.py -p ubuntu-security --pocket security add
[15:11] <cjwatson> Added:
[15:11] <cjwatson> Archive Upload Rights for ubuntu-security: archive 'primary', pocket 'Security'
[15:13] <Laney> ah, there's a handy main backport ready
[15:13] <cjwatson> I've committed the corresponding edit_acl.py changes now.
[15:14] <xnox> cjwatson: Laney is up with a core-dev application though =)))))
[15:15] <cjwatson> There are two other examples ;-)
[15:17]  * ScottK wonders if Laney's core-dev application should be rejected on the grounds of it being very late.
[15:17] <cjwatson> DENIED: slacker
[15:18] <Laney> I didn't want to deny core-devs the warm internal glow that sponsorship provides :-)
[15:22] <Laney> cjwatson: ^ it works!
[15:22] <ScottK> Where does the sync blacklist live these days?
[15:22] <cjwatson> ScottK: lp:~ubuntu-archive/+junk/sync-blacklist
[15:22] <cjwatson> Laney: yay
[15:22] <ScottK> Thanks.
[15:22] <cjwatson> (Now where's that review-backport tool?)
[15:23] <Laney> /part
[15:23] <cjwatson> haha
[15:24] <ScottK> cjwatson: If an entry is obsolete, can I just remove it  and push (blacklist)?
[15:25] <cjwatson> Sure
[15:26] <ScottK> Thanks.
[15:34] <Riddell> cjwatson: are you planning on moving kubuntu bits to universe any time soon?
[15:34] <cjwatson> Oh, er, yeah could do, let me get a BIG coffee
[15:53] <phillw> hi good people, has http://pad.ubuntu.com/ubuntu-release been retired? I see respins, but no reasons for them, thanks.
[15:54] <Riddell> phillw: there's no current release candidates going on
[15:55] <Riddell> cjwatson: if you happen to be in a channel with sabdfl can you remind him there's a kubuntu meeting in #kubuntu-devel in 5 mins?
[15:55] <cjwatson> You're seeing routine daily builds, not manual respins
[15:55] <phillw> Riddell: thanks, is there any 'pulling together' what is in each respin being logged?
[15:56] <cjwatson> Riddell: He's not on e.g. #canonical
[15:56] <phillw> thanks, cjwatson et all :)
[15:56] <Riddell> ah well
[15:56] <cjwatson> phillw: These are totally automatic builds.
[15:56] <phillw> thanks :)
[15:56] <cjwatson> phillw: So no.  You can use things like the quantal-changes mailing list to see all changes in the archive.
[15:56] <phillw> I don't think I have the skills to decode that :)
[15:57] <cjwatson> Nor does the cron job running the daily builds. ;-)
[15:57] <phillw> lol
[15:57] <phillw> tochee :D
[15:58] <cjwatson> Riddell: Do either of us need to follow up to https://lists.ubuntu.com/archives/kubuntu-devel/2012-June/006135.html
[15:58] <cjwatson> ?
[15:59] <Riddell> cjwatson: I've not thought it much but my feeling is if someone want to upload a package they should check their changes get into the relevent packaging branch
[15:59] <Riddell> and anyone who doesn't isn't doing the task properly
[16:00] <Riddell> ~kubuntu-
[16:00] <Riddell> packagers
[16:00] <Riddell> is easy to add people to
[16:00] <Riddell> no approvals needed
[16:00] <cjwatson> So you're happy with a sort of post-merge review on any changes that turn up in Kubuntu
[16:01] <cjwatson> TBH the problem probably existed occasionally in main too
[16:06] <Riddell> cjwatson: happy enough
[16:06] <Riddell> generally I'd prefer they discuss it with the kubuntu developers if practical
[16:07] <cjwatson> Right, I mean as a recovery-from-error process rather than advertised process IYSWIM
[16:07] <cjwatson> I just want to make sure that I'm not going to do this and then have some set of people shout at me that I need to move gigabytes of data *back* :-)
[16:08] <Riddell> cjwatson: yeah it's fine
[16:08] <cjwatson> ('cos mirrors are probably going to notice this ...)
[16:08]  * infinity notes it's yet another "branches out of sync with archive" complaint, and wishes people would stop pretending branches are authoritative.
[16:08] <cjwatson> Mind you I suppose it won't be anywhere near, say, a release
[16:09] <SpamapS> bdmurray: I got to June 9
[16:09] <Laney> Why don't you just add motu to the team with the branches?
[16:09] <infinity> Laney: I'm sure they could, that doesn't mean the branches will be up to date. :P
[16:10] <Laney> It makes it slightly more likely
[16:10]  * infinity goes to push his change to the calligra branch, so it doesn't get dropped...
[16:10] <skaet> phillw,  have gone in and cleaned it up.  ;)  thanks for flagging
[16:10] <Laney> and quite a lot less irritating for someone who tries to do things the right way
[16:11] <infinity> Laney: I disagree that the "right way" is to create more busy work for someone doing a drive-by fix, but hey. ;)
[16:11] <SpamapS> bdmurray: its probably worth re-checking the ones we've nagged for testcase/regression potential quite regularly. I'm wondering if we should start rejecting things quicker.. like.. 1 week after the nag
[16:11] <Laney> One team's right way … :P
[16:12] <infinity> As long as source packages are authoritative (and they currently are), it will continue to irk me when people don't check the current state of the archive before uploading.
[16:13] <bdmurray> SpamapS: I found myself looking at ones you'd just commented on yesterday though
[16:13] <micahg> infinity: even with authoritative source packages we seem to get collisions (see ubuntu-meta earlier this morning)
[16:14] <SpamapS> bdmurray: shouldn't be too hard to just move to the next... but yeah
[16:14] <SpamapS> bdmurray: need some way to communicate "skip these"
[16:14] <bdmurray> SpamapS: well its the 20 tabs open that need to get closed which takes some time
[16:16] <infinity> micahg: That's the same error, really.  Not checking a debdiff against the previous version before uploading.
[16:16] <infinity> micahg: Though, in the meta case, just hilarious, not damaging.
[16:16] <micahg> heh
[16:17] <infinity> micahg: The problem with people (mistakenly) considering branches authoritative is that they think "bzr diff" is enough to see what changes they've introduced.
[16:17] <micahg> Riddell: IMHO, it's worth a mail when the switch happens to remind people to check the Vcs-* fields when uploading
[16:17] <infinity> micahg: Which isn't even true if they're not reverting something someone else did. :P
[16:17] <cjwatson> bdmurray: I think your recent sru-accept.py change is a much better fix to my "Advertise pending-sru.html in sru-accept comment?" work item than the work item itself proposes.  Can I reassign that WI to you and mark it done?
[16:18] <micahg> infinity: heh, yeah, I've given up on trusting bzr diff on random branches
[16:18] <SpamapS> bdmurray: I isolate my SRU work in a single browser window for that reason. :-P
[16:18] <bdmurray> cjwatson: sure, didn't know about that
[16:18] <cjwatson> (https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-more-agile-sru-process)
[16:19] <cjwatson> all yours
[16:19] <cjwatson> thanks :)
[16:19] <infinity> micahg: I sort of treat them as two entirely different entities.  bzr diff, of course, has its place when I'm actually working in bzr (as I do for some codebases), but I *always* debdiff my final upload against the previous version to cruft-and-reversion-check.
[16:20] <bdmurray> cjwatson: do you have any plans for that last work item?
[16:20] <cjwatson> bdmurray: sorry, which one?
[16:20] <bdmurray> [tb] patch sru-accept to link to .debs for -proposed in comment or the page of the binary package build in launchpad which has all the deb links from the librarian (as the security team does): TODO
[16:20] <cjwatson> oh, the one we hopefully assigned to tb
[16:21] <cjwatson> he suggested it so we voluntold him
[16:21] <cjwatson> I somehow doubt he'll have time to do it
[16:21] <cjwatson> no plans myself though it doesn't sound horribly difficult
[16:21] <bdmurray> right, I might just do it then
[16:21] <infinity> FWIW, I much prefer linking to the build(s) rather than the .debs.
[16:21] <cjwatson> agreed
[16:21] <cjwatson> possibly marginally easier anyway
[16:22] <micahg> I think that was the outcome of the session anyways
[16:22] <cjwatson> though you'll need one per arch of course
[16:22] <infinity> micahg: Yeah, the work item proposes both options.
[16:22] <cjwatson> bdmurray: be my guest
[16:22] <infinity> micahg: So, I thought I'd voice an opinion. ;)
[16:22] <micahg> infinity: just affirming support for you based on historical precedent :)
[16:22] <infinity> I assume the security team has cargo-cultable code here.
[16:23] <bdmurray> infinity: sssh, don't give away how I will do it
[16:23] <infinity> ;)
[16:24] <infinity> bdmurray: When you're done with that, would you like some of my work items too?
[16:25] <cjwatson> I've got more.
[16:26] <bdmurray> infinity: I'll get back to you on that ;-)
[16:26] <infinity> cjwatson: Oh, if you're resurrecting dsync-flist use in the publisher, remind me to resurrect my local project to actually make the code build on a modern OS and get it into the archive.
[16:27] <infinity> cjwatson: Cause, one of these days, elmo's hand-built binary from 1987 will explode. :P
[16:27] <cjwatson> It's not hopelessly slow if it's being run, like, ever.
[16:27] <cjwatson> It took two and a half hours to run generate on a year's worth of changes.
[16:27] <cjwatson> But a no-op run takes 9s.
[16:27] <infinity> Yeah, it's pretty quick when it's being run.
[16:28] <cjwatson> Do you think we could make it emit ls-lR somehow?
[16:28] <infinity> That said, it SHOULD be rolled into apt-ftparchive, IMO, and it could be really fast.
[16:28] <cjwatson> Seems like it should have most of the data.
[16:28] <cjwatson> I'd be totally happy to keep that if it were blindingly fast.
[16:28] <cjwatson> I mean, it can lie about some of the fields or something.
[16:28] <infinity> Hrm, yeah.  If we could make ls-lR not suck, we could keep it.
[16:29]  * xnox adam and colin are discussing archive's black magic again
[16:29] <cjwatson> It can't be that much harder than md5sums.
[16:29] <cjwatson> That's what we do.
[16:29] <infinity> And drink.
[16:29] <cjwatson> And drink.
[16:29] <infinity> But it's a bit early for that.
[16:29] <cjwatson> Sun's well over the yard-arm here.
[16:30] <infinity> cjwatson: Let me dig up the actual dsync source.  It's on some laptop somewhere here.
[16:30] <cjwatson> I've got it if you don't.
[16:30] <cjwatson> -rw-r--r--   1 cjwatson cjwatson 131189 Oct 26  2006 dsync_0.0-0.1.tar.gz
[16:30] <cjwatson> fresh
[16:30] <elmo> infinity: it's not hand built; I have sources!
[16:30] <elmo> there, see
[16:30] <cjwatson> (I suspect that's the time I downloaded it, though
[16:30] <cjwatson> )
[16:30] <infinity> elmo: Sources that don't build anymore. ;)
[16:30] <cjwatson> drwxr-xr-x   9 cjwatson cjwatson   4096 May 16  2005 dsync-0.0
[16:30] <elmo> these filthy accusations shall not stand
[16:30] <infinity> elmo: Hahaha.
[16:30] <cjwatson> dsync (0.0-0.1) experimental; urgency=low
[16:30] <cjwatson>   * Make it build using g++-3.3.
[16:30] <cjwatson>  -- Kurt Roeckx<EMAIL_ADDRESS>Mon, 16 May 2005 16:04:58 +0200
[16:31] <cjwatson> That must be good enough, right?
[16:31] <elmo> WFM
[16:31] <infinity> Close enough.
[16:31]  * xnox adores cjwatson idioms http://en.wikipedia.org/wiki/Yard_(sailing)#.22Sun_over_the_yardarm.22
[16:35]  * micahg thought we added gcc 3.3 back to the archive
[16:35] <cjwatson> Oh, that's all right then. :-P
[16:36] <cjwatson> It's only libstdc++5, not the compilers.
[16:36] <cjwatson> Anyone want to comment on anything in http://paste.ubuntu.com/1041070/ ?
[16:37] <cjwatson> That's what moving Kubuntu to universe would change.
[16:39]  * micahg wonders if the libjpeg stuff is worth seeding or not
[16:39]  * micahg also wonders why a bunch of -dbg packages are now showing up
[16:39] <cjwatson> -progs?  Dunno.  That's only a binary movement so easy enough to revert.
[16:40] <cjwatson> Probably because of different Extra-{Ex,In}cludes between the Ubuntu and Kubuntu supported seeds.
[16:40] <cjwatson> Some of those are probably a mite spurious.
[16:40]  * micahg guesses xscreensaver isn't worth keeping in main either
[16:41] <cjwatson> bzr-doc is odd, what's up there
[16:41] <ScottK> Kubuntu has a development seed that is 'overbroad'.
[16:41] <ScottK> Some of that stuff comes from there.
[16:41] <cjwatson> Right, but bzr should be seeded in Ubuntu and its Extra-Includes should grab bzr-doc.
[16:42] <micahg> libzip is another one that looks like it might be worth keeping
[16:42] <xnox> cjwatson: speech-dispatcher-festival is interesting cause I thought orca works better with that
[16:42] <cjwatson> Mostly I'd rather people investigate what's going on and fix seeds rather than telling me :-)
[16:43]  * micahg isn't sure if these things are actually worthwhile or would do the commits
[16:43] <cjwatson> Ah, some of this is seed madness
[16:43] <cjwatson> supported fails to inherit from server-ship
[16:44]  * cjwatson goes to try to rectify
[16:44] <xnox> myspell going away, we still have something else in main, right? like hunspell?
[16:44]  * xnox doesn't now
[16:45] <xnox> since emacs is in main please keep auctex
[16:45]  * xnox the world will be a better place with more emacs stuff
[16:45] <cjwatson> It doesn't vanish because it's in universe
[16:45] <micahg> xnox: yes, although I thought some dictionaries didn't have hunspeel equivalents, maybe we don't have those languages?
[16:45] <cjwatson> I don't think we can necessarily sanely keep every add-on for everything
[16:47] <cjwatson> Right, I've fixed ubuntu.quantal/STRUCTURE; I'll generate a new version of that diff in a bit which will probably be rather substantially different
[16:47] <xnox> micahg: still seems strange, why so *little* of them moved. I'm suspicious.
[16:48] <cjwatson> Should be possible to investigate this by comparing germinate output on people.c.c
[16:49] <micahg> xnox: right, most likely, we'll need to seed those I think (myspell-he is one example)
[16:49]  * micahg fixes
[16:50] <micahg> hrm, not sure where though
[16:51] <micahg> cjwatson: for any languages we don't ship on the live image, should I add the dictionary to the supported seed?
[16:52] <cjwatson> Are they regexable?  You could put them next to the /^hunspell-[^-]*$/ regex entry.
[16:52] <cjwatson> Which is in supported, yes.
[16:52] <micahg> cjwatson: well, I think we just want the myspell ones when we don't have hunspell equivalents, right (or they are the hunspell equivalents)
[16:54] <cjwatson> micahg: Well, feel free to seed them individually there
[16:54] <micahg> cjwatson: thanks
[16:55] <cjwatson> infinity: dsync-flist md5sums takes 19s or thereabouts
[16:55] <cjwatson> Very tempting to just shove this back into ubuntu-archive-publishing by fiat.
[16:55] <infinity> cjwatson: Kay.  I do wonder if this could be even faster if it could be taught to re-use apt-ftparchive's cache.
[16:55] <infinity> cjwatson: (Given that dsync is a mess of cargo-culted code from apt anyway...)
[16:56] <cjwatson> Except I have enough to do today.  But something like http://paste.ubuntu.com/1041084/
[16:56] <cjwatson> (Which roughly corresponds to the last version of that code before it was removed from Launchpad.)
[16:56] <infinity> I also wonder how that can be so fast, when ls-lR is doing less, and takes much longer...
[16:57] <cjwatson> It uses Packages and Sources, right?
[16:57] <cjwatson> Hmm.  No.
[16:57] <infinity> Neither one does.
[16:58] <cjwatson> I guess it can use getdents and doesn't have to stat everything individually if it's in its cache.
[16:58] <infinity> dsync just walks the tree you give it.  How that's faster than a recursive ls is a mystery. :P
[16:58]  * cjwatson straces
[16:58] <cjwatson> ls -lR has to stat everything.
[16:58] <infinity> Fair point.
[16:59] <infinity> Makes a good argument for figuring out how to make dsync generate a fake ls-lR, if we want to keep it.
[17:00] <infinity> It should have all the appropriate info (except permissions, but who cares?) in its cache.
[17:02] <cjwatson> It actually does seem to do lots of lstats.
[17:03] <cjwatson> Not sure how it's so fast.  Maybe I got lucky with caching and it wouldn't be fast if run after a publisher run?
[17:03] <infinity> Possibly.
[17:04] <cjwatson> It's bloody slow under strace. :-)
[17:06] <infinity> gdb the strace process, that'll speed it right up.
[17:06] <infinity> And then valgrind the gdb.
[17:08]  * cjwatson wonders if dsync is ctrl-c safe, and isn't sure he wants to experiment
[17:11] <xnox> cjwatson: heartbeat move to universe is a bad idea. Expect to break a lot of servers. Ideally this should be under server's team control.
[17:12] <xnox> as many servers use only main.
[17:12] <cjwatson> xnox: Then it should be in a server seed somewhere.
[17:12] <xnox> and it's the only way to do high-availability.
[17:12] <xnox> hmmm how do I request / do that?
[17:12] <cjwatson> The point of the seed system is that I don't have to work it all out myself. :-)
[17:12]  * xnox is off to wiki about archive development
[17:13] <cjwatson> MP into lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.quantal
[17:13] <cjwatson> heartbeat isn't explicitly seeded anywhere right now
[17:13] <xnox> hmmm so how come it ended up in main?
[17:14] <xnox> just because of kubuntu?
[17:14] <cjwatson> build-dep of pacemaker
[17:14] <xnox> yeah, is pacemaker moving as well?!
[17:14] <cjwatson> Which is in Ubuntu, so actually I'm pretty sure this is due to the problem I fixed above
[17:14] <cjwatson> So no need for an MP
[17:14] <cjwatson> You probably might as well stop investigating until I refresh the list
[17:14] <cjwatson> It's wrong
[17:15] <cjwatson> 17:47 <cjwatson> Right, I've fixed ubuntu.quantal/STRUCTURE; I'll generate a new version of that diff in a bit which will probably be rather substantially different
[17:15] <xnox> ok.
[17:15]  * xnox can't find neither pacemaker nor heartbeat in the seeds
[17:16] <cjwatson> Build-dep of ocfs2-tools.
[17:16] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/rdepends/ALL/heartbeat
[17:17] <cjwatson> (Which unfortunately doesn't say why ocfs2-tools is there; minor germinate bug I guess - but it's in the server-ship seed.)
[17:18] <cjwatson> But, you know, if it's that vital, maybe it ought to be explicit.
[17:18] <xnox> well I wonder why ocfs2-tools got added, cause pacemaker by itself should be explicit just in case IMHO.
[17:19] <xnox> pacemaker/hearbeat stuff has more usage than ocfs2-tools thingy
[17:19] <xnox> hmm seems ok
[17:20] <xnox> it looks like the server seed is explicit under cluster sections of everything you ever need to run any time of cluster stuff
[17:20]  * xnox doing merge proposal just in case
[17:24]  * xnox done
[17:25] <cjwatson> I'm sure that dsync-flist could be very much faster by assuming that files in the pool never change contents once created.
[17:25] <cjwatson> Which it doesn't seem to, so I've no idea how it was so fast earlier.
[17:25] <cjwatson> In fact it seems to predate package pools.
[17:26] <infinity> Well, it's format-agnostic.
[17:26] <cjwatson> Yeah, but what do I care.
[17:26] <infinity> I use it on random collections of mp3s and movies. :P
[17:26] <cjwatson> Freak
[17:26] <cjwatson> So maybe it would be faster to shove it in apt-ftparchive.  It'd have to be run later rather than as part of the main a-f run though.
[17:27] <cjwatson> And that would kind of suck if the LP team ever finished getting rid of a-f.
[17:27] <infinity> I'm unconvinced that NMAF will actually work on large archives, personally.
[17:27] <cjwatson> And it would have to deal with the random files on the mirror.
[17:27] <infinity> It drops the local cache in favour of assuming the DB is insanely fast.
[17:27] <cjwatson> The general NMAF approach absolutely blew on dogfood, but then dogfood is horrible
[17:27] <cjwatson> And it's possible my queries were awful too
[17:27] <infinity> The a-f cache is a godsend on any sufficiently large archive.
[17:28] <cjwatson> (I'd been hoping to do germinate-from-db, but it seemed to be impractical)
[17:28] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/germinate-from-db
[17:28] <cjwatson> I don't think I knew about bulk loading then, so that would make a fairly enormous difference.
[17:35] <micahg> ok, dictionaries fixed
[17:35] <micahg> s/fixed/added to supported/
[17:39] <skaet> infinity,  ogra_ - any clue yet why we still don't have arm desktop dailies?
[17:40] <infinity> skaet: Oh, I pinged IS about doing some remote-hands debugging of celbalrai, and I think I must have cause webops on a shift change or something.
[17:40] <infinity> skaet: And then got busy with something else. :P
[17:40] <infinity> skaet: I'll poke harder.
[17:40] <skaet> thanks infinity
[17:41] <ScottK> infinity: You caused a shift change?
[17:42] <infinity> ScottK: caught.  My fingers and brain aren't agreeing.
[17:43] <infinity> The classic case of typing "cau" and having your fingers go "HOLY CRAP, I KNOW THAT WORD" and filling in the rest with nonsense.
[17:43] <ScottK> Right, but it was funnier my way.
[17:57] <cjwatson> http://paste.ubuntu.com/1041164/ - better list of movements to universe due to Kubuntu
[17:59] <ScottK> Some of the binary only demotions seem odd, but it's definitely better.
[17:59] <cjwatson> supported-network-client (at least) still isn't inherited by supported.
[18:00] <cjwatson> Which causes e.g. irssi-dev.
[18:00]  * infinity wonders why lbdb was seeded in Kubuntu...
[18:00] <infinity> Or was that also due to the above?
[18:00] <ScottK> No, it's on the DVD.
[18:00] <cjwatson> I wonder why supported-common fell out.  That was what it was for.
[18:01] <ScottK> Probably the ambitious Kubuntu development seed.
[18:01] <ScottK> No, it's directly seeded in the Kubuntu DVD seed.  No idea why.
[18:01] <cjwatson> Maybe dates from the original Ubuntu supported seed.
[18:02] <ScottK> That or the fact that Riddell is known to use Mutt.
[18:02] <xnox> This move to universe boggles me:
[18:02] <xnox> + o exim4-daemon-heavy-dbg exim4-daemon-light-dbg exim4-dbg exim4-dev eximon4{exim4}
[18:02] <cjwatson> Same cause, missing supported-common in supported's inheritance list.
[18:02] <cjwatson> Will be fixed in the next list.
[18:03] <cjwatson> ScottK: r89 in breezy, so probably just got blindly merged.
[18:03] <xnox> Moving this to universe is strange:
[18:03] <xnox> + o nagios3-dbg                                                       {nagios3}
[18:03] <cjwatson> xnox: Same cause.
[18:04] <xnox> not sure about:
[18:04] <xnox> + o libreiser4-dev                                               {reiser4progs}
[18:04] <infinity> xnox: Might be worth giving up on reviewing the list until there's a new one. :P
[18:04] <bdmurray> our criteria regarding test case for SRU says 'These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem.
[18:04] <cjwatson> xnox: Same cause.
[18:04] <bdmurray> with the possibility of uploader verification is that still the case?
[18:05]  * ScottK would think so.
[18:05] <micahg> bdmurray: as I recall from the session, yes, as it helps crystalize the issue in the mind of the person doing the SRU
[18:05] <xnox> Also concerned about all the speech-dispatcher and festival stuff, it basically will make ubuntu mute
[18:05] <infinity> bdmurray: I think that's a fair statement still for test cases, with an addition that "sometimes, this is very difficult or, indeed, next to impossible to satisfy, so a test-case that can be understood by the uploader or another person familiar with the package is acceptable if the verification will also be done by same".
[18:06] <ScottK> If you can't write it down, then you haven't thought it through.
[18:06] <infinity> ScottK: There are some test cases that I can perfectly reasonably write down, but someone "unfamiliar with the package" will not realistically be able to reproduce.
[18:06] <bdmurray> here's an example https://bugs.launchpad.net/nova/+bug/968843/comments/6
[18:06] <ubot2> Ubuntu bug 968843 in nova "[SRU] connection leak in rpc connection pool" [Undecided,In progress]
[18:06] <infinity> (Or, not without hours/days of learning and setup time)
[18:07]  * xnox prepares e2fsprogs testcase: take a block device larger than 16TB and run fsck against it..... then do this.....
[18:07] <bdmurray> I've no idea where to set small pool size
[18:07] <ScottK> infinity: True.
[18:07] <bdmurray> nor how to cause an rpc response timeout
[18:07] <bdmurray> So I'd consider that insufficient
[18:07] <cjwatson> xnox: Er, that clearly can't be true since that's stuff that isn't in main right now.
[18:08] <cjwatson> xnox: Can we please tone down the hyperbole about how awful everything is going to be? :-)
[18:08] <infinity> bdmurray: That would one could, indeed, be better, but I'd be just as happy with that test case and a commitment that it will be tested by someone who understands it.
[18:08] <infinity> bdmurray: What I don't want is crappy (or no) testcases and an assumption that "Someone Else" will verify it.
[18:09] <xnox> cjwatson: your diff starts with no heading. What's the first heading/diff lines correspond to?
[18:09] <cjwatson> festival is genuinely unseeded in Ubuntu right now (as opposed to Kubuntu, where it was recently depended on by something), and not in main.
[18:09] <bdmurray> infinity: so stuff like "Test Case … None" would concern you?
[18:09] <cjwatson> xnox: it's against http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[18:09] <xnox> cjwatson: ok.
[18:09] <infinity> bdmurray: s/That would one could/Than one could/ ... No idea what's with my brain->finger interconnect today.
[18:09] <cjwatson> The first is "Source and binary movements to main"
[18:10] <xnox> cjwatson: makes sence =)
[18:10]  * xnox stay calm and carry on
[18:10] <cjwatson> I can't regenerate a diff awfully quickly because this relies on the archive's germinate run.
[18:10] <infinity> bdmurray: No test case at all concerns me unless the "test case" is itself the bug (ie: "bug: package fails to ship copyright file, fix: patch that ships copyright file", in that case, "testcase: look at your filesystem" is pointless)
[18:11] <cjwatson> Which I can't really do while the publisher's running.
[18:11] <infinity> bdmurray: But quality of testcases is entirely dependant on who the tester(s) will be.  I just want to know that testcase and test audience seem to be a matched set. :P
[18:11] <infinity> bdmurray: (I certainly have some glibc SRUs coming up where writing "idiot-proof" testcases will be a phenomenal waste of time)
[18:12]  * micahg wasn't under the impression they needed to be idiot proof, just clear enough that someone not intricately involved could decipher
[18:13] <infinity> micahg: The problem is how one draws lines around what defines "not familiar with the package".
[18:14] <infinity> micahg: And a testcase that boils down to having someone just examine output of some commands doesn't mean they're testing that you've fixed the bug, they're testing that you've written the testcase to match the output. ;)
[18:14] <infinity> micahg: (As in, I'd argue that there are bugs where the tester has to understand the problem, period)
[18:17] <ScottK> Fundamentally, the SRU rules are the standard case.  They aren't a suicide pact.  I think the SRU team can use some judgment about what's appropriate on a case by case basis.
[18:17] <infinity> ScottK: Ed Zachary.
[18:17] <ScottK> ?
[18:17] <infinity> ScottK: Sorry.  More formally, "I agree".
[18:18]  * infinity does enjoy that when he uses "Ed Zachary" in online conversation and people don't get it, the first hit on Google is less than flattering.
[18:19] <ScottK> Yes.  Yes it is (first hit on IxQuick anyway)
[18:20] <cjwatson> ooh ooh ooh
[18:20]  * cjwatson consigns type-handling to the flames^W^Wuniverse
[18:20] <cjwatson> Now that gdb's been fixed
[18:23] <cjwatson> Is reverse-depends giving 403 for anyone else?
[18:24] <cjwatson> Oh sod it, it's quitting time.  /me -> pub
[19:59] <hggdh> I just tried a 'do-release-upgrade -d' to quantal -- it fails on 404s from extras.ubuntu.com. Is this expected?
[20:05] <stgraber> no
[20:06] <stgraber> I thought I fixed that one...
[20:06] <stgraber> oh, and I did :) though it looks like the mirroring script IS is running doesn't sync quantal...
[20:21] <stgraber> hggdh: fixed
[20:22] <hggdh> stgraber: you are my hero :-)
[22:20] <micahg> did someone do a giveback of FTBFS in stable releases again?
[22:21]  * micahg is just wondering why chromium in oneiric is building
[22:44] <infinity> micahg: Hrm?
[22:44] <infinity> micahg: Are you sure it wasn't something that failed in one pocket, then got copied?  Or similar?
[22:48] <micahg> infinity: hrm, idk, I thought it was already in -updates and -security
[22:50] <infinity> Dunno.  I never give back things in non-development releases except explicitly.
[22:50] <infinity> And if anyone else does, I'm not aware of it.  And I wish they'd stop. :P
[22:53]  * micahg had some stuff rebuilt last night when he copied some packages to another PPA as a backup
[22:53] <micahg> but that only used 1hr of useful build time
[23:29] <herton> hi, can some AA copy linux-ti-omap4: 3.0.0-1211.23 to -updates (bug 1005455)?
[23:29] <ubot2> Launchpad bug 1005455 in linux-ti-omap4 "linux-ti-omap4: 3.0.0-1211.23 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1005455


[05:55] <Mirv> ok I guess the GCC6 is now causing autopkgtest problems, so long Qt, KDE migration. but unity8 itself would now pass autopkgtests, which was the last blocker before.
[05:57] <flocculant> infinity: doesn't look like yak iso's built last night - or at least those which I'd expect to see a version dated 05 at this time
[05:58] <Mirv> but could you somehow hint that always the latest unity8 would be used for autopkgtest? for example http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src uses the current release pocket version which cannot be installed with the new qtbase.
[05:59] <Mirv> because otherwise even though eg unity-scope-click wouldn't segfault (gcc6? new boost?) the whole excuses page wouldn't be green because of the old unity8 results
[06:00] <Mirv> of course, if you'd think it's acceptable, just allow Qt, KDE migrate to release pocket regardless of the new transition problems
[06:00] <Mirv> among else unity-scope-click did pass before
[06:04] <Mirv> now one of the tests segfault
[06:05] <Mirv> anyway, feedback/help welcome, the Qt/KDE won't migrate by itself ever regardless, some hinting will be required
[06:42] <infinity> flocculant: Oh, right, I need to reenable cron.  I had it off to not mess with my release.
[06:42] <flocculant> :D
[06:43] <flocculant> I thought it might have been something like that
[06:45] <infinity> flocculant: Fixed.
[06:45] <flocculant> infinity: thanks - have a more relaxing day today :)
[06:45] <infinity> flocculant: I'm taking Friday off, so it better be relaxing.
[06:46] <flocculant> \o/
[06:46] <flocculant> infinity: have a great weekend then
[10:44] <LocutusOfBorg> anybody working on ghc transition?
[12:22] <Mirv> hi! Qt and KDE could migrate, but I need archive admin help
[12:22] <jbicha> AAs, you can reject the older numix-gtk-theme
[12:22] <Mirv> 1. qml-module-qtpositioning would need promoted to main so that qtlocation5-examples would work: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtlocation-opensource-src
[12:23] <Mirv> 2. some more s390x binary removals would be needed that pitti was doing a lot because of the upstart problem: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtpurchasing-opensource-src and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
[12:25] <Mirv> seb128: ^ can you help?
[12:26] <Laney> plasma-workspace needs NBS removed too
[12:28] <xnox> Mirv, hm, confused. britney says libpay2 is not satisfyable on s390x, yet it is built there....
[12:28] <xnox> Mirv, it is less work not to remove s390x....
[12:28] <seb128> Mirv, sorry but not atm, using my other laptop/doing some debugging and I don't have easy access to the acl from there, maybe later when I'm back at my desk
[12:29] <xnox> huh, built but not available
[12:29] <Laney> it's been removed
[12:29] <Laney> https://launchpad.net/ubuntu/yakkety/s390x/libpay2
[12:29] <xnox> why?
[12:29] <Mirv> xnox: I remember pitti mentioning something about links, maybe the fact that it was binary copied from a PPA
[12:29] <seb128> whoever decided to delete upstart on s390x would have better fixed the build
[12:30] <xnox> slangasek, what does ANAIS stand for
[12:30] <seb128> it's costing way more effort to deal with the things that keep getting blocked that it would have been to fix the build
[12:30] <Laney> architecture not allowed in source
[12:30] <Mirv> xnox: so there is a big list of reverse dependencies removed (but not all yet as shown), because upstart on s390x did not get fixed but removed instead
[12:31] <Laney> in this case it build-depends on libubuntu-app-launch2-dev
[12:31] <Laney> which is not present on s390x
[12:32] <xnox> to be fair we all do have better things to deal with then chasing ubuntu-app-launch on s390x, but i see how much churn such a removal is causing.
[12:32] <xnox> maybe we (I) should have listened to steve in the beginning and like not compile upstart on s390x at all
[12:32] <Laney> that's just broken because of upstart isn't it?
[12:33] <xnox> Laney, disable upstart testsuite on s390x, upload, live happily ever after?
[12:33] <Laney> heh
[12:33] <seb128> somebody (Steve?) said that the issue was no s390x though but building on xenial builders
[12:34] <Mirv> kernel issue if I recall
[12:34] <xnox> seb128, infinity did
[12:34] <seb128> and that it's going to bite other archs if we need to SRU a fix to xenial
[12:34] <xnox> so maybe we do need to fix upstart
[12:34] <seb128> so somebody needs to fix upstart eventually anyway
[12:34] <Laney> anyway
[12:34] <Laney> the removal hasn't been followed through to the end
[12:34] <Laney> so now we have issues like this
[12:34] <xnox> but i don't get this claim.... aren't our virtual builders running xenial?
[12:35] <seb128> well now, but at the time the xenial upstart was built it was on older builders it seems
[12:35] <xnox> 3.13.0-92-generic
[12:35] <seb128> rebuild today wouldn't work
[12:35]  * Laney tests that claim
[12:36] <Laney> https://launchpad.net/~laney/+archive/ubuntu/ppa/+build/10568298
[12:37] <xnox> i wonder why cloud-builders are not using xenial cloud images as base
[12:37] <xnox> for buildds
[12:37] <xnox> cjwatson, ^ or is the move gonna happen only after trusty is end of live?
[12:37] <xnox> how about using hwe xenial kernel in the trusty cloud image?
[12:39] <Mirv> anyway, it'd be nice if an archive admin could promote the qml-module-qtpositioning , NBS remove plasma-workspace and then remove the packages being discussed if/when upstart isn't going to be fixed soon still
[12:39] <Mirv> that would be removal of libqt5purchasing5 qtpurchasing5-dev ubuntu-system-settings on s390x, or something else/more?
[12:40] <Mirv> I wonder if didrocks would be around if seb128 might not have time at the moment
[12:40] <Laney> Check they have a build-dep which will prevent the binaries coming back the next time
[12:41] <Mirv> ok, checking
[12:45] <Mirv> yes for qtpurchasing packages, they can't be built on s390x anymore thanks to pitti's removals
[12:47] <Mirv> however ubuntu-system-settings would reappear on next build, something would need to be done about that
[12:52] <Mirv> not sure about the preferred action there, could simply state u-s-s not to build on s390x
[12:53] <Laney> add a build-dep on upstart or ual or something
[12:53] <Mirv> right that'd be easiest, I can propose that for the next u-s-s landing
[12:54] <Mirv> I think US archive admins would be online soon, hopefully they can help with those actions above if Europeans don't have time to. I will do the u-s-s MP and check back later if there's anything else to help with, but it'd be a nice present to everyone to get the migration going (or at least closer to being reality)
[13:05] <Mirv> made the MP https://code.launchpad.net/~timo-jyrinki/ubuntu-system-settings/stop_s390x_problems_depend_on_upstart/+merge/302143
[13:14]  * xnox uploaded upstart into PPA with a testsuite fix
[13:16] <Laney> :-o
[13:16] <Laney> is it a fix or a workaround? :P
[13:17] <xnox> let's wait to see if it works
[13:17] <xnox> non-system non-session (so upstart pretending to act like pid 1, but running as pid whatever and non-root) fails to connect to dbus when told so whilst stuck processing and spawning system jobs and generates loads of "failed to start plymouth" and what not
[13:18] <xnox> that test case only tries to call "initctl version" to check that upstart connects to session dbus when asked
[13:18] <xnox> changed test-suite to spawn upstart with "--no-startup-event" such that upstart in such configuration is simply spawned and connects to dbus, but doesn't try to mess with anything else
[13:19] <xnox> makes the tests pass on my machine at least, previously failing.
[13:19] <xnox> https://launchpadlibrarian.net/277265629/upstart_1.13.2-0ubuntu28_1.13.2-0ubuntu29.diff.gz
[13:20] <Mirv> or hmm would apw still be around?
[13:22] <Mirv> anyhow, I'd propose trying to get Qt & KDE migrated today with the actions above, and if there is some hope with upstart start re-enabling the chain of s390x next week
[13:23] <xnox> hm, somethings wrong build on amd64 done, still pending on s390x
[13:25] <xnox> still fails on s390x
[14:17] <slangasek> Mirv: qtpurchasing/s390x binaries removed from yakkety-proposed; qml-module-qtpositioning promoted to main
[14:18] <slangasek> was there anything else?
[14:21] <Laney> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-workspace NBS
[14:22] <slangasek> removed
[14:22] <sil2100> Wooo \o/
[14:22] <sil2100> Let's see if we have more problems down the stack now
[14:24] <Laney> can't imagine this will be the end of the story
[14:25] <Laney> but it'll be clearer
[15:10] <Mirv> slangasek: sil2100: hi, thanks! there was also ubuntu-system-settings/s390x removal http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
[15:10] <Mirv> and then a relook at update_output.txt probably
[15:10] <Mirv> although u-s-s is actually not strictly required for the transition I think
[15:11] <Mirv> since it does not depend on the private Qt ABI. I might be wrong too. more help with parsing excuses&output would be welcome.
[15:14] <slangasek> Mirv: if I delete ubuntu-system-settings/s390x now, what prevents it from coming back again?
[15:14] <slangasek> does it have any build-dependencies on s390x NBS packages?
[15:15] <Laney> he just made a MP to add that
[15:16] <Laney> a synthetic BD on upstart, or equivalent
[15:16] <Laney> slangasek: ^-
[15:16] <slangasek> ok
[15:20] <sil2100> Yeah, I reviewed that change, so it's just a matter of getting that MP released
[15:25] <Mirv> I just think that's not necessarily the current remaining blocker but something else is, as u-s-s should not be a required part of the transition
[15:26]  * Mirv -> shopping
[15:29] <Mirv> (neither is mediascanner, scopes-api etc)
[16:51] <Mirv> sil2100: slangasek: can you check if something should be simple hinted a bit more to migrate together? if I look at update_output.txt and the last occurence of qtbase including Trying easy from autohinter section, it claims relatively little amount of packages "uninstallable" (or the per architecture list), but for example gammaray, plasma-desktop, plasma-workspace can be installed together
[16:52] <Mirv> all of KDE needs to go in, as parts of it depend on Qt private 5.6 ABI and all of Frameworks / Plasma release in proposed depends on each other to go together
[16:53] <Mirv> there are some in the lists though that do not need to migrate together with Qt/KDE
[16:54] <Mirv> the combined set of packages that I know need to mostly go in together is the list of source names at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+packages + https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+packages
[16:54] <Mirv> others not so
[16:56] <Mirv> anyway, even if I would have more time I think I cannot think of anything else myself, I can install everything required in my yakkety-proposed while some unrelated stuff like lubuntu-qt-desktop has problems (lubuntu meta depends on Laney / tedg 's click breaking / packagekit upgrade I think)
[16:58] <Laney> It'll be a bit irksome if you get entangled with that one
[17:01] <Laney> finally ubuntu-release-upgrader is running, now samba has settled down
[17:10] <slangasek> Mirv: looks to me like the current problem is autopkgtests still running for plasma-workspace
[17:58] <k1l_> hi. there is an issue with users wanting to upgrade from the EOL 15.04 right now. regular upgrade doesnt work and EOL upgrade with old-releases isnt activated yet. see bug #1609796
[17:59] <k1l_> running do-release-upgrade -d works, strangely, but i doubt that is the planned way to upgrade the 15.04 now
[18:34] <slangasek> infinity, bdmurray: ^^ I guess that's because 15.10 had the EOL switch flipped?
[18:37] <infinity> Erk, yeah, it's not been mirrored yet.
[18:37] <infinity> I guess I can flip it back until that's sorted.
[18:41] <infinity> slangasek: Reverted.   Will sort it all out on Monday.
[18:43] <infinity> slangasek: Although, the bug report is more than just old-releases mirroring, we really *should* be supporting vivid->xenial, so probably need some SRUs to address that too.
[18:43] <bdmurray> ubuntu-release-upgrader has DistUpgrade.cfg files that allow upgrading from W -> X or T -> X.  We could add more I guess.
[18:44] <infinity> Anyhow, it should be okayish with the revert for now, we can sort the proper solution.
[18:44] <bdmurray> infinity: did you update the changelogs server too?
[18:44] <k1l_> ok, just tested my 15.04 vbox install and the do-release-upgrade now works.
[18:44] <infinity> bdmurray: Yep.
[18:46]  * infinity goes back to not being here, and wondering why he didn't buy a bunch of USB-C cables with his new phone.
[18:46] <k1l_> imho there should be a decision if there should be a non-LTS upgrade path overstepping some releases. iirc there were some issues when 14.10 went EOL, too.
[18:47] <infinity> k1l_: Yes, I think the right answer is that we should always support upgrades to the next LTS directly, but that means testing those upgrade paths, not just flipping a switch and hoping. :)
[18:48] <k1l_> yeah. but when 14.10 goes EOL there is no next LTS :/ imho there are some points of upgrade through that 4 years timeframe that need to have a rethink.
[18:49] <k1l_> we had lots of users in #ubuntu wanting to go from 14.04(.X) to 15.10. but the releases inbetween were EOL already.
[18:52] <bdmurray> I thought the work I did in bug 1497024 should have allowed that.
[18:55] <k1l_> bdmurray: ok. than maybe there is just some needed clarification on what upgrade-path is supported on what situation. in #ubuntu there were a lot of issues with the jumping over releases so most supporters told to do EOL-upgrades.
[19:03] <bdmurray> k1l_: where would you want to see that clarification?
[19:05] <k1l_> bdmurray:  on the upgrade pages in the help or wiki dokumentation? so we have something to show people what the designed and tested upgradeplan is.
[20:20] <slangasek> Mirv: so, plasma-workspace autopkgtests are failing on all archs, that's not going to migrate on its own
[20:21] <slangasek> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-workspace
[21:48] <yofel> slangasek: please badtest those, 2 of those test try to open windows that need to be closed by hand
[21:48] <yofel> I'll patch those out of the next upload
[22:16] <slangasek> yofel: done, thanks


[20:12] <sadmac2> Keybuk: file:///home/rdu/cdahlin/upstate/coverage/state_rb.html
[20:12] <sadmac2> wait
[20:12] <sadmac2> Keybuk: git://fedorapeople.org/~sadmac/upstate.git
[20:12] <sadmac2> too many cut buffers
[20:12] <sadmac2> that
[20:12] <sadmac2> that's the state machine
[20:13] <ion_> Ah, i was just about to open the first URL by exploiting the vulnerability in your sshd.
[20:14] <sadmac2> heh
[20:15] <ion_> Ew, hardcoded ANSI sequences.
[20:17] <ion_> printf "%s%sbold red%s\n" $(tput setaf 1 2>/dev/null) $(tput bold 2>/dev/null) $(tput sgr0 2>/dev/null)
[20:19] <sadmac2> ion_: oic


[02:33] <rick_h_> greg-g: wood pron https://plus.google.com/116120911388966791792/posts/Xx1Ff59sz13
[02:33] <jjesse> nice job
[02:36] <rick_h_> thanks, we'll see how it goes. getting closer and closer
[04:01] <cmaloney> Evening
[13:10] <cmaloney> Good morning
[13:11] <rick_h_> morning and such
[13:11] <rick_h_> 27 on the old temp gauge...I might have to go get shorts
[13:14] <cmaloney> Yeah, it's like a heat-wave.
[14:51] <cmaloney> gotta love Microsoft
[14:51] <cmaloney> Windows Xp comes off support in April and Windows 7 is pretty much impossible to purchase.
[14:51] <cmaloney> unless you want to play OEM roulette or spend +$300
[14:57] <brousch> http://www.newegg.com/Product/Product.aspx?Item=N82E16832116992
[14:57] <cmaloney> I don't want an OEM version
[14:57] <cmaloney> That's the System Builder version right?
[14:57] <brousch> Works for me
[14:58] <brousch> I have a VM running it
[14:59] <cmaloney> Is there anything special to purchasing the OEM version and activating it?
[15:02] <brousch> No
[15:07] <rick_h_> grrr, this target thing is starting to make me angry http://r.bmark.us/u/8844ed92d1cd6e
[15:07] <rick_h_> of course my wife did a bunch of shopping there this holiday season
[15:08] <brousch> scr00d
[15:09] <rick_h_> yea, pretty much
[15:09] <cmaloney> rick_h_: should have gone to Meijer instead. ;)
[15:09] <rick_h_> she hates that place :P
[15:09] <cmaloney> Nobody piches your data tighter than Meijer
[15:09] <rick_h_> well they don't ask for it :)
[15:09] <rick_h_> but yea, this reaction to this crap has been horrible
[15:09] <cmaloney> Yeah they do. It's called MPerks.
[15:09] <rick_h_> at first I didn't care
[15:10]  * rick_h_ has never seen it
[15:10] <cmaloney> MPerks is awesome
[15:10] <cmaloney> It's digital coupons
[15:10] <cmaloney> and cash-back
[15:10] <cmaloney> If you power-shop for your groceries at Meijer it makes some damn good sense.
[15:11] <cmaloney> https://mperks.meijer.com/mperks
[15:11] <cmaloney> Honestly I wish more places would do this
[15:11] <cmaloney> I get a little cranky having to print and clip a coupon
[15:12] <cmaloney> esp. Staples since I already am using my rewards card.
[15:12] <cmaloney> and biggby too
[15:34] <brousch> This looks like fun http://www.kickstarter.com/projects/393053146/powerup-30-smartphone-controlled-paper-airplane
[15:48] <rick_h_> jcastro: ping
[16:06] <greg-g> que es "power-shop"?
[16:06] <jjesse__> Meijer makes me angry
[16:06] <jjesse> i think its the lights they use, seems harsh and makes me feel angry when i walk in
[16:07] <brousch> I love meijer
[16:07] <brousch> I go at 7:30AM each week on Saturday or Sunday.
[16:08] <greg-g> and he's angry for the rest of the day
[16:08] <brousch> At 9:30AM I hate meijer because it is full of asshats
[16:28] <cmaloney> I <3 Meijer as well
[16:28] <cmaloney> though Target has an atmosphere that makes me want to buy things there
[16:29] <cmaloney> like throw-pillows and matching lamps
[16:29] <cmaloney> I have no idea why that is
[16:34] <greg-g> psychology, they know
[16:35] <cmaloney> greg-g: power-shop = go there for just about everything that we need grocery and otherwise.
[16:36] <greg-g> ah, one-stop shopping
[16:37] <cmaloney> greg-g: yeah, I'm a big fan of Meijer
[16:37] <greg-g> I thought power-shopping was more akin to "buy in bulk when the deal is right" aka "super coupon clipping nerds"
[16:37] <cmaloney> That too
[16:37] <cmaloney> but we're not nearly as bad as some folks I know like my parents
[16:37] <greg-g> :)
[16:38] <cmaloney> they're the ones picking up 8 salsas because they're 2/4
[16:38] <greg-g> if you have the pantry space...
[16:38] <cmaloney> they do, and they use it
[16:38] <cmaloney> it's almost like a bunker though
[16:38] <cmaloney> we're not so lucky in the cupboard space.
[16:39] <greg-g> us neither
[16:39] <cmaloney> greg-g: Shit, if you had a pantry that could be sublet for a family of four in CA.
[16:39] <cmaloney> $800 a month. ;)
[16:39] <greg-g> done with roommates
[16:40] <cmaloney> greg-g: yeah, I don't understand how folks do it
[16:40] <cmaloney> it's easier with someone you want to be with, but people you kinda-sorta-like-but-not-really would be a pain in the ass.
[16:40] <greg-g> in certain points in your life and in certain special situations, otherwise, ughhhhh
[16:41] <cmaloney> yeah.
[17:01] <brousch> Seeing these new Android desktop all-in-ones makes me want to take Android dev more seriously
[17:02] <rick_h_> the web runs on everything :P
[17:04] <brousch> But it doesn't do some things well
[17:04] <brousch> I have 2 family emember who like their chromebooks
[17:05] <rick_h_> like?
[17:05] <brousch> Yes, have switched to chromebook and are happy
[17:06] <rick_h_> I meant what things do you want to do that the web doesn't do?
[17:49] <mathomastech> What is the CSS convention in distinguising 3 class names that are identical. My example is this. I have a class called left and can pertain to the header, body, and footer of an object. But each has unique code. Right now I am using left for body, hLeft for header, and fLeft for footer. Is there a CSS convention I should be following or is it a matter of personal taste?
[17:49] <rick_h_> yea, don't do that :)
[17:49] <rick_h_> use left, and it does the common thing
[17:50] <rick_h_> and if they need tweaking setup .left .header {changes}
[17:50] <rick_h_> errr, .left.header {}
[17:50] <rick_h_> using something like sass makes this really nice because the nested structure is obvious and readable
[17:51] <mathomastech> Yea, I read using Less or sass allows me to use variables, which would completely solve the problem. Right now I am just using raw css.
[17:51] <rick_h_> pastebin something specific and can be more specific
[17:51] <mathomastech> can I send you github link?
[17:52] <rick_h_> sure
[17:52] <mathomastech> https://github.com/mathomastech/cardLayout/blob/master/cardLayout.css
[17:52] <mathomastech> btw, I totally borrowed the design idea from the CHC website.
[17:53] <rick_h_> so .hLeft should be .header.left {}
[17:53] <rick_h_> you want .left to mean something, .header to mean something, and the two together to add some extra bits
[17:54] <mathomastech> So then do I need just a single .left with 3 sub classes in it (header, footer, body)
[17:54] <mathomastech> ?
[17:54] <rick_h_> well things should nest and cascade
[17:55] <rick_h_> it's generally bad form to try to do things too custom, but you need what you need
[18:08] <mathomastech> Ahh, I  think I got it figured out. Neat, so when you call a class from html, in this case <p class = "header left"> it only pays attention to the .header.left in CSS.
[18:09] <rick_h_> mathomastech: no, it does threee
[18:09] <rick_h_> .header
[18:09] <rick_h_> .left
[18:09] <rick_h_> and .header.left
[18:12] <brousch> rick_h_: I'm having a hard time coming up with something that can be done on Android that can't on Chromebook. Only storing files, photo, and video editing come to mind. Those can be done on web, but are clumsier
[18:12] <rick_h_> brousch: yea, why i like web dev
[18:12] <rick_h_> unless you need something specific, works on iphone, android, osx, etc
[18:12] <brousch> Doing anything offline
[18:13] <rick_h_> even offline works for some things
[18:13] <brousch> It is ugly
[18:13] <brousch> I'll have to think about this more though
[18:14] <brousch> It may be that I just like the user experience of Android better than a web browser OS so it's tainting my thoughts
[18:15] <mathomastech> rick_h_  Thanks. So I removed the plain .left, and have 3 different className.left classes instead. It's much less ugly now.
[18:19] <rick_h_> mathomastech: coolio
[18:20] <rick_h_> brousch: there are advantages
[18:20] <rick_h_> brousch: the use of intents
[18:20] <rick_h_> derekv has some nice stuff in the bookie android app that we don't/can't have in the web app
[18:21] <cmaloney> http://www.rushbackstage.com/rushbackstage/accessories-etc/index.html
[18:21] <brousch> But it's interaction with the native OS. If the native OS is chromeos, then that goes away
[18:21] <cmaloney> And people say I'm hard to shop for.
[18:21] <rick_h_> brousch: true
[18:22] <rick_h_> cmaloney: heh
[18:22] <cmaloney> Though I'd be hard-pressed to even hit one of those drum heads.
[18:22] <brousch> rick_h_: Although having apps interact with each other is a lot harder in web
[18:23] <brousch> If all your files are stored on Google/Dropbox, you need a service that can interact with those to use your files
[18:23] <rick_h_> brousch: right
[18:23] <rick_h_> have to build in apis
[18:24] <brousch> cmaloney: Rush2012 pendant necklace is heading your way now!
[18:24] <brousch> You're gonna look so gangsta!
[18:25] <cmaloney> brousch: tx. :)
[18:25] <cmaloney> Because pimpin' ain't easy.
[18:25] <brousch> Even better http://www.rushbackstage.com/rushbackstage/accessories-etc/rush-belt-buckle.html
[18:26] <cmaloney> I'd totally wear that. :)
[18:29] <mathomastech> Updated with more prettyness. https://github.com/mathomastech/cardLayout/blob/master/cardLayout.css
[18:29] <mathomastech> Or rather, with less uglyness.
[18:31] <brousch> rick_h_ does it and suddenly everyone else is on board http://hardware.slashdot.org/story/14/01/10/1441210/4k-is-for-programmers
[18:33] <rick_h_> brousch: you should know by know I control all :)
[18:33] <rick_h_> konw by now bah
[18:34] <cmaloney> brousch: rick_h_ isn't a trend setter; he is the trend.
[18:34] <rick_h_> this one was quick though. Usually it takes a few years of calling me names :)
[18:35] <cmaloney> rick_h_: We're moving in internet time. :)
[18:35] <cmaloney> That and I think folks are getting a little tired of two monitors
[18:35] <cmaloney> just for the real-estate
[18:35] <brousch> I would prefer 1 ginormous monitor
[18:35] <rick_h_> I'd like to have this 24 as a 27, but bigger than that and it's too much space to eat up
[18:36] <rick_h_> in the end, you dont' want 10 different apps running giving you feedback at once
[18:36] <rick_h_> you can't concentrate on things
[18:38] <cmaloney> That's the real problem.
[18:38] <cmaloney> I wish workspaces were something I used more.
[18:38] <brousch> Our draftsmen have 27"ers. I find them overwhelming
[18:38] <brousch> But then I found our 24"ers overwhelming for a week
[18:38] <rick_h_> yea, I'm coming from 21's so the 24 is nice since I went from 3 to 1
[18:38] <cmaloney> also wish the issue of NVidia displaying white windows when I switch workspaces would also be fixed.
[18:40]  * rick_h_ stops reading comments on that /. link before he loses the day and get banned
[18:40] <rick_h_> waf can verify, tiling window managers ftw on these high res displays
[18:40] <cmaloney> Yeah, i've started using the windowing under tmux for my ssh sessions
[18:41] <cmaloney> I figure I'll hit lim(rick_h_) within a few years.
[18:42] <cmaloney> but by then the bar will have moved. ;)
[18:46] <brousch> 8k
[18:46] <rick_h_> heh
[18:46] <rick_h_> I'm just glad not every damn monitor/display is stuck at 1920x1024 any more
[18:47] <rick_h_> those were an annoying few years
[18:47] <cmaloney> I just await the point where rick_h_'s monacle becomes sentient.
[18:47] <trevlar> mathomastech: just a thought.. you could rename your master branch to gh-pages so github will automatically serve it.. would be easier to demo
[18:47] <cmaloney> We'll all benefit then. ;)
[18:50] <mathomastech> trevlar: I am using that repository just to host the library. I actually have a live demo copy on my actual website.
[18:50] <mathomastech> http://mathomaste.ch/Projects/cardLayout/index.html
[18:52] <mathomastech> But that actually might be more convenient, to have Github automatically update the demo, rather than me copying over the latest files.
[20:12] <cmaloney> Woo!!! A super-secret package that I hope JoDee hasn't tried to order is winging its way to us
[20:12] <cmaloney> Looks like her birthday is coming earlier than I expected.
[20:19] <rick_h_> lol
[20:23] <brousch> Why I love Django https://devcharm.com/pages/79-must-have-django-packages
[20:38] <rick_h_> because it's python? :P
[20:55] <cmaloney> rick_h_: http://magnatune.com/artists/superdirt2
[20:55] <cmaloney> Not sure if this might be up your alley but I'm liking it
[20:57] <cmaloney> It's like classical electronic music.
[21:00] <cmaloney> rick_h_: Also http://magnatune.com/artists/jag


[13:21] <antono> hi all
[13:21] <antono> charm for statusnet is broken somehow
[13:21] <antono> anyone managed to use it succesfully?
[13:22] <antono> first i belive it's not idemponent... koz it fails on juju resolved --retry statusnet/X trying remove index.html that already was deleted
[13:23] <antono> i think some automatical idemponency check for charms should be performed. otherwise charm store will be full of half-baked half-working charms.
[13:24] <antono> and one question: can i use something other than m1.small on amazon?
[13:30] <antono> oh. there is a bug reported against statusnet charm LP#914851
[13:30] <_mup_> Bug #914851: Fails to configure when title has a space in it <statusnet (Juju Charms Collection):New> < https://launchpad.net/bugs/914851 >
[13:53] <antono> is it possible to install 2 services on 1 machine with juju?
[13:54] <antono> each juju deploy runs new EC2 instance. it does not look smart
[14:08] <_mup_> Bug #952262 was filed: Juju should use XDG directory layout <juju:New> < https://launchpad.net/bugs/952262 >
[14:26] <antono> i found hwo to run other than m1.small! "default-instance-type" in config
[14:58] <SpamapS> antono: actually I think I found that it had some idempotency problems a while back yeah
[14:58] <SpamapS> antono: we do an automated install test right now
[14:58] <antono> SpamapS: cool!
[14:58] <SpamapS> antono: http://charmtests.markmims.com/
[14:58] <antono> i going to create generic rails charm
[14:59] <SpamapS> antono: and a lot were broken by a recent change to config.yaml handling IIRC
[14:59] <SpamapS> antono: there's already a generic rails charm
[14:59] <antono> oh, for real? :)
[14:59] <antono> havent find it yet :)
[15:00] <antono> can i clone all charms in one place with one command?
[15:00] <SpamapS> antono: try 'charm search rails'
[15:00] <antono> i came from git background and not sure how to deal with submodules in bzr
[15:00] <SpamapS> antono: 'charm getall /path/to/charm/root'
[15:01] <antono> wow. cool
[15:01] <SpamapS> oh git.. :-P
[15:01] <SpamapS> antono: note that charm getall is REALLY slow
[15:01] <antono> SpamapS: is it possible to set somehow default repository
[15:01] <antono> ,
[15:02] <antono> SpamapS: oh, bzr
[15:02] <antono> :)
[15:03] <antono> i'd like to get all charms somwhere to ~/.local/share/juju/charms and use it as default repository... unless other location specified
[15:03] <SpamapS> antono: I'd be happy to take a patch to charm-tools to provide a way to get them all branchd from git instead of bzr.
[15:03] <antono> SpamapS: as for me bzr is ok :)
[15:03] <antono> nice to learn something new
[15:04] <SpamapS> antono: a change landed last week that takes the default --repository from $JUJU_REPOSITORYY
[15:04] <SpamapS> bzr is about 5x easier than git to learn
[15:04] <antono> SpamapS: yep. probably yes
[15:04] <SpamapS> It just makes it harder to rewrite history like git, so people get frustrated with it because they're used to that.
[15:05] <antono> SpamapS: i found bzr rebase plugin :)
[15:05] <SpamapS> yeah, which is silly once you realize that the very act of doing 'bzr merge' is just like rebase, except it does not discard history.
[15:06] <antono> SpamapS: does bzr merge put my commits on top of target branch?
[15:07] <SpamapS> antono: if you have branch A, and branch B, and you mege from B->A, then A will get one commit with all the missing changes from B.
[15:07] <antono> SpamapS: and collocated branches is something really useful. i know they are here with bzr 2.5
[15:08] <SpamapS> antono: there's a blugin for that I think now called cobzr
[15:08] <SpamapS> written, oddly enough, by the original architect of juju ;)
[15:08] <SpamapS> antono: http://labix.org/cobzr
[15:08] <antono> SpamapS: not sure why but i'd like to have separate commits after merge
[15:09] <antono> anyway. juju is way to go
[15:09] <antono> i like it
[15:09] <antono> but... some questions to you :)
[15:09] <SpamapS> antono: they're still there.. just wrapped up in a single commit.
[15:10] <antono> does it allow to run some unit on specified machine?
[15:10] <antono> i would like to run 3 app servers and 1 db on single amazon node
[15:10] <SpamapS> antono: two answers for that
[15:10] <SpamapS> antono: either a) use the local provider on that one machine (but this means you cannot scale beyond that one machine)
[15:11] <SpamapS> antono: or b) lets go on an adventure to see if the recent 'constraints' branch allows specifying machine ids..
[15:11] <SpamapS> antono: there's also c) use my new experimental not yet landed 'charm splice' command to splice those 4 things into one charm.
[15:12] <antono> SpamapS: thanks for your answers
[15:12]  * antono afk for 1 hour
[15:18] <marcoceppi> d) all of the above?
[15:30] <SpamapS> marcoceppi: tell that to George Zip!
[15:48] <antono> hmm. why bzr log does not pipe output to pager by default on ubuntu?
[15:49] <SpamapS> antono: because |less is easy?
[15:50] <antono> oh noes. extra typing is totally wrong. same as expricit --repository requirement
[15:54] <SpamapS> antono: --repository is all but gone
[15:55] <antono> SpamapS: nice :)
[15:55] <antono> same |less should go by default
[15:55] <SpamapS> antono: antono |less is optional though.. if you want to search, | less.. if you just want to limit.. -l #
[15:55] <SpamapS> antono: its a different philosophy, but I personally hate things that push me into the pager like that. :-P
[15:56] <antono> i love ubuntu for sane defaults... and i'ts clear why it's not piped by default in bzr. but on linux it could be default behavior. (i should rant in #bzr probably)
[15:59] <marcoceppi> but if it goes to pager, how will I |grep -ri "stupid committer" to find all the dumb things someone did?
[16:00] <marcoceppi> :)
[16:01] <SpamapS> marcoceppi: it would only go to pager if isatty(stdout)
[16:02] <SpamapS> its a valid, but annoying practice imo
[16:02] <antono> and grep  works ok with bzr-pager plugin...
[16:04] <antono> SpamapS: what do you think about charm get lp:some/charm ?
[16:05] <SpamapS> antono: charm get is a bit of a hack...
[16:06] <SpamapS> antono: its mostly for getting charms from the official repo/dev series.. if you want a specific charm.. bzr branch works. :-P
[16:06] <SpamapS> antono: the whole 'charm get*' set of commands is supposed to go away once the full charm store backend service goes live
[16:06] <antono> aha. i saw broken requests to store.charms...
[16:07] <antono> how can i set default environment?
[16:07] <SpamapS> antono: in environments.yaml, you can set a root element 'default: xxxx'
[16:08] <SpamapS> antono: or JUJU_ENVIRONMENT
[16:08] <SpamapS> antono: sorry, JUJU_ENV
[16:09] <SpamapS> which is apparently undocumented. :(
[16:10] <antono> SpamapS: me researching the code :)
[16:13] <SpamapS> At this point we have 2 JUJU_ environment variables affecting the cli.. and 1 in review.. we should probably make a dedicated environment variables document.
[16:14] <antono> SpamapS: i think it should go to man juju
[16:15] <SpamapS> hahahahahaha
[16:15] <SpamapS> man page
[16:15] <SpamapS> thats rich
[16:15] <SpamapS> antono: I wrote a man page once. The dev team rejected it because it wasn't auto-generated :-/
[16:15] <antono> SpamapS: auto generated from source?
[16:16] <antono> Is there any python solutions for such tasks?
[16:16] <SpamapS> yeah.. they want the man page to be generated from all the argparse --help output
[16:16] <SpamapS> nope
[16:16] <SpamapS> I'd have to write it myself
[16:16] <antono> good idea
[16:16] <antono> :)
[16:16] <SpamapS> sat down to
[16:16] <SpamapS> got disgusted with argparse
[16:17] <SpamapS> antono: btw, was the statusnet problem you saw bug 914851 ? I'm about to fix that (and add a test for it)
[16:17] <_mup_> Bug #914851: Fails to configure when title has a space in it <statusnet (Juju Charms Collection):Confirmed> < https://launchpad.net/bugs/914851 >
[16:18] <antono> SpamapS: yes, it is
[16:18] <antono> Also i belive it doesnt clear /var/www on remove-unit
[16:18] <antono> so next add-unit fails
[16:18] <antono> need to check it
[16:19] <antono> fails due to rm /var/www/index
[16:19] <antono> now. it's obvious that just merging charms will not work
[16:19] <antono> i mean just merge charms to run all on single machine
[16:20] <antono> it should be some good conventions/guidlines for each charm
[16:20] <antono> where should it put it's files
[16:20] <SpamapS> antono: what is "remove-unit" ? ;)
[16:20] <antono> statusnet puts all to /var/www
[16:21] <SpamapS> antono: charms were never meant to be more than 1 per server
[16:21] <antono> SpamapS: i can only say it's bad limitation
[16:22] <SpamapS> antono: the dev team wants to use LXC so the charms are completely namespaced from eachother
[16:23] <antono> SpamapS: yeah. thats good idea. in this case it's ok to have charm per machine
[16:23] <antono> and it's certainly will simplyfy things a lot
[16:23] <SpamapS> antono: unfortunately, thats complicated because LXC also namespaces the network.. so you have to figure out a way to make all the charms reachable from all the other nodes. On EC2 that won't work because the network is tightly controlled.
[16:23] <antono> from charm-writer point of view
[16:24] <SpamapS> antono: t1.micro is pretty cheap... ;)
[16:24] <SpamapS> for testing. And for production.. m1.small's are the only sane thing. :)
[16:25] <antono> i use m1.micro for my blog, mail, jabber, git etc
[16:27] <SpamapS> antono: right, none of those would conflict with the splice method. :)
[16:29] <SpamapS> antono: I actually think deploy and add-unit should take a '--machine' argument.. this is agreed upon as a more generick '--placement' option but its implementation is still pending.
[16:35] <jcastro> oh cool, are you deploying status.net with the charm antono?
[16:39] <_mup_> Bug #952355 was filed: Backward incompatible change: existing env boolean values cause total failure <juju:New> < https://launchpad.net/bugs/952355 >
[16:42] <antono> jcastro: yes, just testing juju following instructions in your post
[16:42] <antono> jcastro: probably i'll make a charm for http://rstat.us/
[16:42] <antono> koz it's better than statusnet
[16:43] <jcastro> ah, cool!
[16:43] <antono> and also support ostatus protocol
[16:43] <jcastro> you can enter it in the charm contest! (See topic)
[16:43] <antono> jcastro: yep, i saw
[16:44] <antono> jcastro: you should also make juju documentation contest
[16:44] <antono> i'd like to record some plain/text screencasts for juju
[16:44] <antono> like this one: http://shelr.tv/records/4f53e3df8841ac0001000001
[16:45] <antono> so copy/paste will work and make things easier for newcomers
[16:45] <SpamapS> antono: rstat.us looks nice. :)
[16:46] <antono> one more thing i going to charm is http://gitlabhq.com/
[16:46] <antono> should i put this to google doc before start?
[16:46] <SpamapS> antono: bugs.launchpad.net/charms
[16:46] <jcastro> I have a bug for gitlab
[16:47] <jcastro> gitlab would be quite awesome.
[16:47] <SpamapS> the google doc is not really authoritative.. its just richer and easier to organize than bugs.launchpad.net
[16:47] <jcastro> SpamapS, I have a mind to just kill the gdoc
[16:47] <SpamapS> columns are good...
[16:47] <antono> what do you think guys about obeying XDG spec for juju data?
[16:47] <SpamapS> antono: I saw that. Interesting idea.
[16:47] <antono> i mean ~/.config/juju ~/.local/share/juju etc
[16:47] <jcastro> https://bugs.launchpad.net/charms/+bug/931835
[16:48] <jcastro> here you go ^
[16:48] <_mup_> Bug #931835: Charm needed: Gitlab <Juju Charms Collection:New> < https://launchpad.net/bugs/931835 >
[16:48] <antono> jcastro: so i should just assign me and start?
[16:48] <jcastro> sure!
[16:49] <antono> done :)
[16:49] <antono> i mean assigned ;)
[16:49] <jcastro> hey nice
[16:49] <jcastro> so gitlab needs mysql and ruby
[16:49] <jcastro> we have those charmed already
[16:49] <antono> jcastro: sqlite afaik
[16:49] <antono> it has some slite specific sql for now
[16:50] <jcastro> ah ok
[16:50] <jcastro> no worries, just as easy
[16:50] <antono> yep.
[16:50] <antono> just as easy as git clone + bundle install
[16:50] <antono> + some setup for apache/nginx
[16:50] <jcastro> gitolite would be cool I think because we don't have a charm that is "I want my own git repo hotness"
[16:51] <SpamapS> jcastro: ruby isn't really "charmed"
[16:51] <antono> jcastro: why should it be charmed? :)
[16:52] <antono> i think it should be ok with apt-get install -y ruby1.9.1-full in install hook
[16:52] <SpamapS> antono: that bit.. "+ some setup" .. thats where the charm wins :)
[16:52] <antono> at least such things work in other charms
[16:52] <SpamapS> antono: I don't think jcastro meant what we think he meant ;)
[16:53] <SpamapS> antono: indeed, just installing the components you need in the install hook is all that is needed
[16:53] <jcastro> no I did not mean what you thought I meant
[16:53] <jcastro> sorry
[16:53] <antono> i have some chef experience
[16:53] <jcastro> I was just thinking aloud when I saw their requirements and was like "we have that, that, and that."
[16:53] <antono> it would be nice to reuse it in charms
[16:54] <jcastro> you can absolutely do that
[16:54] <jcastro> I am surprised no one has tried that yet
[16:54] <antono> it has a lot of well tested idemponent recipes
[16:55] <antono> chef/pupet recipes is a way to go for charms
[16:55] <antono> like build blocks. tested. they have good collection of recipes
[16:55] <antono> also it may increase portability of charms
[16:55] <antono> koz for now they are only debian/ubuntu
[16:55] <SpamapS> antono: yeah, do that. :)
[16:56] <SpamapS> antono: there has been *zero* interest in porting juju to other platforms.
[16:56] <SpamapS> antono: people ask if its possible, thats it
[16:56] <jcastro> I'd rather see a gitolite charm first though
[16:57] <jcastro> People need a slick self-hosted alternative to github!
[16:57] <antono> jcastro: right. same i do
[16:57] <antono> i considered gitorious
[16:57] <SpamapS> antono: Maybe we're biased, being canonical people, but I think using juju means you don't have to care about which OS you're running.
[16:57] <antono> but its hard to install
[16:57] <antono> so charm would be nice
[16:57] <antono> later i find gitolite
[16:58] <jcastro> the nice thing is you can keep the charm up to date
[16:58] <jcastro> you don't have to worry about if a package will make the ubuntu release or whatever.
[16:58] <antono> yes. and it's much more hard to resolve all dependency hell in ruby land
[16:59] <antono> is there any plans to push usage of augtool  in charms?
[17:00] <antono> charms in esence are very similar to less strict packaging systems like arch guys have
[17:01] <jcastro> never heard of augtool
[17:01] <jcastro> oh, the augeas thing
[17:01] <antono> augeas, yes
[17:01] <antono> almost silver bullet for configuration management
[17:02] <jcastro> I don't see any reason why you wouldn't use it if you want to in a charm
[17:02] <antono> in all this config zoo it provides unified api at least
[17:03] <antono> hey, all! who participates charms contest?
[17:03] <jcastro> there's been 3 or 4 so fat
[17:03] <jcastro> err, so far
[17:04] <SpamapS> antono: I've used augtool .. I converted to creating files with appending though
[17:05] <SpamapS> antono: augeas is a neat idea.. and useful when you have multiple things influencing a config file that is complicated. But ultimately, its far more predictable to simply control the inputs, and generate the config in its entirety
[17:06] <SpamapS> jcastro: are you able to deploy stuff with r467 ?
[17:09] <jcastro> SpamapS, I only use what you give me in distro bro
[17:09] <SpamapS> ahhhh
[17:11] <antono> SpamapS: you are right. when every charm isolated in it's own container than it's easier to just fill config template with some values
[17:11] <antono> but... augeas also have augtool get
[17:12] <antono> wich is useful... not all this sed | grep | cut stuff
[17:12] <antono> and more reliable than shell one liners...
[17:13] <SpamapS> antono: right, but what would you be extracting from config that you don't know as a charm author?
[17:14] <antono> right, totally predictable...
[17:15] <SpamapS> antono: and even if charms need to both influence a config file, they should both collaborate around that, not try to avoid eachother.
[17:17] <james_w> hey peeps
[17:17] <james_w> where do we stand with subordinate charms?
[17:24] <m_3> james_w: still waiting
[17:24] <SpamapS> james_w: landing
[17:24] <SpamapS> I believe its all in review
[17:25] <SpamapS> m_3: did you run into the new brokenheaded way that juju is verifying *ALL* of the charms in a repository?
[17:25] <SpamapS> m_3: I can't deploy anything right now.. because nearly half of the charm sin my repo have a bad boolean
[17:26] <m_3> SpamapS: still on cli from earlier in the week
[17:27] <SpamapS> stay there
[17:27] <SpamapS> I"m going to raise a Critical bug
[17:27] <SpamapS> this is just *wrong*
[17:27] <m_3> I didn't have time to fix all of the charms this weekend...
[17:27] <m_3> task for next week!
[17:28] <m_3> dude, devopsdays has turned our submitted talks into a panel... juju,chef,puppet,crowbar,cloudformation,pallet,etc
[17:28] <m_3> whoohoo! should be entertaining
[17:29] <SpamapS> yeah sounds like fun
[17:30] <m_3> SpamapS: btw, how was your upgrade process for mactel?  it's time to bump the lappy
[17:30] <_mup_> Bug #952397 was filed: Juju is forcing *ALL* charms in a repo to be perfect to be able to deploy *any* <juju:Triaged> < https://launchpad.net/bugs/952397 >
[17:31] <SpamapS> m_3: I upgraded a *long* time ago
[17:31] <jcastro> m_3, man that sounds awesome
[17:31] <SpamapS> m_3: been working great
[17:31] <m_3> did my desktop earlier, but've been waiting on the laptop b/c of the travel
[17:31] <m_3> jcastro: picked up the gauntlet
[17:31] <SpamapS> m_3: its safe, go for it
[17:32] <m_3> I think I've got a great opener... love to run it by you guys this week
[17:32] <jcastro> for sure!
[17:32] <SpamapS> m_3: tho I recommend unity-2d for battery life. :)
[17:32] <SpamapS> anyway, time to go enjoy my Sunday
[17:32] <jcastro> <-- pool for me, cya guys
[17:32] <m_3> enjoy
[17:32] <m_3> ha nice
[17:33] <SpamapS> if you guys run into weird "ServiceConfigValueError" , its bug 952397
[17:33] <_mup_> Bug #952397: Juju is forcing *ALL* charms in a repo to be perfect to be able to deploy *any* <juju:Triaged> < https://launchpad.net/bugs/952397 >
[17:33] <SpamapS> Hopefully we can get that fixed early tomorrow
[17:34] <m_3> yeah, maybe there's a nicer way to handle type-safety too
[21:14] <antono> Not sure what i doing wrong... but
[21:14] <antono>  juju deploy local:oneiric/mysql --repository .
[21:14] <antono> 2012-03-12 00:13:57,830 INFO Searching for charm
[21:14] <antono> Invalid value for cache: False
[21:14] <antono> 2012-03-12 00:13:57,897 ERROR Invalid value for cache: False
[21:14] <antono>
[21:14] <antono> current repository contains output of charm getall
[21:27] <antono> oh. it seems i was affected by LP#952397
[21:27] <_mup_> Bug #952397: Juju is forcing *ALL* charms in a repo to be perfect to be able to deploy *any* <juju:Triaged> < https://launchpad.net/bugs/952397 >
[21:34] <antono> hmm.. where should i report ami problems? can i use alternative ami?
[21:34] <antono> 2 t1.micro hangs 10 minutes after start. system log shows
[21:34] <antono> [  167.094249] 1 multicall(s) failed: cpu 0


[02:20] <Fudge> is quantal using python3 with orca yet?
[02:41] <TheMuso> Fudge: I am currently working on that right now.
[02:41] <TheMuso> Fudge: Gradually working up the dependency chain, although braille will be disabled for now.
[02:42] <Fudge> sweet
[02:42] <Fudge> ill hold off an install
[02:47] <TheMuso> Fudge: You won't see Orca using python 3 till the end of the week at least, because alpha 2 is currently being prepped and tested, so maybe Saturday at the earliest.
[02:47] <TheMuso> As in, thats when it will likely first appear on images.
[03:20] <Fudge> cool thanks
[05:58] <TheMuso> Fudge: All the pieces are now in quantal-proposed, but there are new packages, so they need an archive admin to approve them. Give it 24 hours or so, and you can grab what you want from quantal-proposed if you are keen to test.
[05:59] <TheMuso> I'm running Orca using python 3 atm, and so far no problems.
[06:49] <Fudge> TheMuso  yep can do that, ill install it tonight and enable proposed or preposed
[06:50] <Fudge> proposed loL, does orca perform any better TheMuso ?
[08:38] <TheMuso> Fudge: no difference really.
[08:47] <Fudge> oh ok TheMuso


[01:58] <bobooscar> hi. all  can we  set  the guest's  password  w
[01:58] <bobooscar> during  its running time?
[01:59] <bobooscar> rather  than when   it's  just  booted
[02:00] <bobooscar> for  example,  when the guest  already  runs  for  1 year, and  we  forget  its  password, then,  we want  to  chsnge its  password  without  rebooting  it
[16:03] <paride> rharper, hi! Should you feel like sponsoring a package I have https://github.com/canonical/cloud-utils/pull/32 pending
[16:05] <rharper> paride: hey
[16:05] <paride> o/
[22:33] <blackboxsw> Ok, new VMware datasource review in. Thanks akutz and falcojr1 https://github.com/canonical/cloud-init/pull/953
[22:58] <blackboxsw> minor changes requested on hotplug CLI hook for tomorrow https://github.com/canonical/cloud-init/pull/952/files