phillwIt seems like a bug installed by others... every time I ask about beta it falls over. It's okay.. http://iso.qa.ubuntu.com/qatracker/milestones/261/builds is alive. Can you let me know the etherpad link for the respins, thanks00:20
phillwstgraber: do you have the link to ether pad for while we are in beta 1, or is not being used?00:49
cjwatsonI hope we have thrown etherpad in the bin it deserves00:49
phillwcjwatson: so, I guess we do not know what re-spins are planned :(00:49
cjwatsonstgraber may not share my dislike00:50
cjwatsonphillw: as if there are no other means of communication00:50
phillwcjwatson: I'm all ears! how do the iso testers know about what re-spins are due during a 'alpha', 'beta', 'RC' are being scheduled?00:51
stgraberno etherpad00:51
stgraberwhen people want respins they ask for them and I mark them as such on the tracker00:52
cjwatsonpersonally I find chisel on stone more usable than etherpad.  (I like the idea but the implementation is awful.)00:52
phillwcjwatson: stgraber which means also, that the other people actually testing the ISO's can have an ISO respun while they are testing. There is a lack of letting people know if ISO's are due to be re-spun?00:53
cjwatsonOf course they can have an ISO respun while they're testing; that's unavoidable00:53
cjwatsonAnd if they're due to be respun they can be marked as such on the tracker00:54
phillwI liked the ether pad, as there was at least some discussions on what the causes would be. But, you're the boss'es here :)00:54
cjwatsonEditing the etherpad was unusably awful and confusing00:54
* stgraber is out for the next 30min00:55
phillwcjwatson: could you throw me a threw crumbs, we ask people to test the ISO's, they start the sequence and part way through there is a re-spin arrives thus resetting all their tests. This is extremely frustrating for the testers.00:58
cjwatsonThe pad doesn't help with that00:58
cjwatsonIt's reload one page vs. reload a different page00:59
cjwatsonReloading the tracker stands a better chance of being a page they're on anyway00:59
cjwatsonAnd for discussion we can/should use things better suited for discussion - IRC for transient things, maybe a wiki if we need something more persistent01:00
phillwcjwatson: it would at least let them know what was planned? I know it was not perfect. Do we have a better system?01:00
cjwatsonClinging to the pad isn't the answer01:00
cjwatsonPlanning - we very often only decided to respin immediately before actually respinning anyway.  I don't think giving people a false sense of security is especially helpful01:00
phillwcjwatson: indeed, but respinning immediately with no notification?01:01
cjwatsonAnd if we know we're going to respin for something but are batching up a few different problems, we can just do a better job of marking test cases disabled in the tracker in a timely fashion01:01
cjwatsonWhich we didn't necessarily do before01:01
phillwcjwatson: where are such announcments made?01:02
cjwatsonHere, and I'm sure stgraber would be happy to copy them to #ubuntu-testing too01:02
cjwatsonAnd on the tracker01:03
phillwcjwatson: I'm only trying to update the sequence :)01:03
phillwcjwatson: stgraber, so the only pre notification of a 'planned' respin is when the ISO tracker strikes them out for a re-spin?01:05
phillwno prior notification for people part way through the tests?01:05
xnoxphillw: what we are trying to say is that we can push the prior notification directly to iso tracker, well in advance of the respin.01:06
xnoxphillw: as iso tracker is become more and more flexible than it was before.01:06
cjwatsonAnd there's no purpose in waiting further if we know we're going to respin anyway01:06
cjwatsonThat would only waste *more* of testers' time01:06
cjwatsonThe best things we can do are (a) notify as early as possible on the tracker, (b) respin as soon as we can while minimising the total number of respins01:07
phillwxnox: in what way? Honest, guys, I'm not being awkward... I just do not want the ISO testers to test, and then find that their work was for naught.01:07
cjwatson"prior notification" is not a useful goal01:07
* xnox lately is having hard time typing. I should measure the frequency i post a sed commands.01:07
cjwatsonNot in isolation01:07
cjwatsonBecause if we have notified as early as possible on the tracker, then the only way that we can give more prior notification is to artificially push the respin later simply for the purpose of being able to say that testers had more notice, and that helps precisely nobody01:08
xnoxphillw: instead of "etherpad" -> "wait for uploads" -> "publish uploads" -> "rebuild images" -> "iso tracker wipes the results". We know have "Notice on iso tracker that respin will happen (warning dialogs on top that you may have seen in the past)" -> "wait for uploads" -> "publish uploads" -> "respin" -> "iso  tracker updates/wipes"01:09
cjwatsonThe problem in the past is that we've been so busy messing about editing the etherpad that we've forgotten to update the tracker01:09
cjwatsonPartly because the etherpad was so bureaucratically complex to edit01:09
xnoxNote the timeline, it starts with a notice on the iso tracker, such that it will put off people starting tests, and maximise the warning period.01:10
cjwatson(At least, that's been my experience)01:10
phillwcjwatson: I agree, totally, but is http://iso.qa.ubuntu.com/qatracker/milestones/261/builds up to saying 're-spins' are arriving? (I know it can).01:10
cjwatsonI can't speak for any particular URL.  I know the iso.qa front page can and does01:10
cjwatsonAh, yes, that's a milestone front page01:10
phillwcjwatson: xnox I agree with both of you.01:11
cjwatsonThen yes, the products in question show as struck out01:11
xnoxphillw: at the moment. see "notice board" no message, all is good.01:11
cjwatsonAnd as xnox says we have a notice board for brief announcements01:11
xnoxstgraber: can you put a placeholder  (beermug?) message: "current images are being tested as potential candidates, no respins planned at the moment"01:12
phillwxnox cjwatson stgraber are we okay to TELL people testing ISO's to go in that way so that they have the "latest news "?01:12
xnox? =)01:12
cjwatsonphillw: Yes01:12
cjwatsonI'm quite surprised that they aren't being told that already01:12
phillwSo, no short cuts... send them to http://iso.qa.ubuntu.com/qatracker/milestones/261/builds01:12
cjwatsonSince it's the one-stop-shop for recording test results01:13
xnoxphillw: we may have a quick chatter/consensus here first and then onces agreed update tracker straight away to push the message out to the testers. As our testers is always highest priority.01:13
phillwcjwatson: a lot of the testers are using http://iso.qa.ubuntu.com/qatracker/milestones/243/builds01:13
cjwatsonphillw: That's fine for daily build testing, but it will be disregarded for beta prep01:14
cjwatsonphillw: I would actually suggest just telling them to go in through the iso.qa.ubuntu.com front page and select the proper milestone, but YMMV01:14
phillwyou should really have a think... maybe have http://iso.qa.ubuntu.com/qatracker/milestones/243/builds redirect to http://iso.qa.ubuntu.com/qatracker/milestones/261/builds during betas01:14
phillwcjwatson: testers get used to the shortest link to zsync.01:15
cjwatsonThey shouldn't have been told that that was the place to go for all time in the first place01:15
phillwand the one that they use is the one that they use01:15
cjwatsonTell them otherwise01:15
cjwatsonIME testers are not as inflexible as you suggest01:15
cjwatsonxnox: Not to disrespect testers, but testing is a means to an end; the highest-quality release is the highest priority :-)01:16
phillwHey, I can email the lubuntu team as to where everyone else goes for daily builds... pass.01:16
phillwcjwatson: and asking them to change their links for zsycnking all the time does not endear the -release team to the testers :D01:17
cjwatsonphillw: The links on cdimage have been constant for ages.  I can't help it if people keep making trouble for themselves by using more complicated systems01:18
cjwatsonIn other words it's not me who's asking them to change their links, dude01:18
phillwcjwatson:  I suggest you and iso tracker make peace?01:19
cjwatsonI have no problem with the ISO tracker; but if people want constant links for downloads they should go straight to cdimage01:19
xnoxcjwatson: "we value the manual testing a lot and fast-track information to them as best as we can, since manual testing is a scarce resource" | gcc -O301:20
xnoxwe respect everyone =)01:20
cjwatsonxnox: Indeed01:20
phillwI think this a good point for me to tip toe away from the discussion of 'dailies' becoming "RC's"01:23
cjwatsonAnd BTW, it's got very little to do with zsync URLs and much more to do with where to record results01:23
cjwatsonIn any case, we can always just watch the "Raring Daily" milestone to see if there are lots of misrecorded results there, and worry about it then01:24
phillwcjwatson: I know, but some people only come 'on board' for testing when they think we have ironed out most of the bugs..... I know this is wrong in theory, but we can get extra testers on board when it hits Beta.01:25
cjwatsonSorry, you say that as if it contradicts something I said but I don't see what?01:26
phillwI've not had a fail of able to boot on 13.0401:26
cjwatson(And it seems perfectly reasonable to me)01:26
phillwcjwatson: as to reporting from iso-tracker, it is dismal and in effectual. There is a bug raised against it.01:28
cjwatsonYou mean reporting Launchpad bugs starting from iso.qa?  That wasn't what I was talking about.01:29
phillwcjwatson: nah, it was about the ability for a person to actually search for results.01:30
cjwatsonSure, I'm aware that that is poor, but it doesn't seem to have anything to do with the above01:31
phillwcjwatson: it is actually a lot to do with it.  https://bugs.launchpad.net/ubuntu-qa-website/+bug/112644901:32
ubot2Launchpad bug 1126449 in ubuntu-qa-website "Getting a historical results report for a product is difficult" [Undecided,New]01:32
cjwatsonIt's *possible*, it's just not pleasant01:32
cjwatsonBut for this purpose it doesn't have to be pleasant01:32
cjwatson(Existence proof: stgraber can do SQL queries on the database ...)01:33
phillwYou see, they have, a feeling of reporting stuff is just not carried over.01:33
cjwatsonWell, on the daily builds it's not really01:33
phillwcjwatson: ut, heck, we were going to chat about this in UDS-S, and then look what happened :D01:34
cjwatsonRealistically, I don't think iso.qa is a particularly effective way to report daily build problems right now01:34
xnoxphillw: daily milestone is active for products that are not doing beta1, that's why at the moment both milestones are active.01:35
phillwcjwatson: well, it is frozen for beta. but I'm always open to ideas from01:36
cjwatsonWhich is one reason I think it's a little ... ambitious to have directed testers at the daily milestone in the first place01:36
xnoxwhen everything is doing a milestone it will be easier.01:36
phillwxnox: as in rolling release?01:36
xnoxphillw: no, as in beta2 where ubuntu when all images will be doing milestone release.01:37
cjwatsonI mean, I would like it to be usable for daily build reporting, but we're not really there01:37
* phillw please drop future and get 13.04 out01:37
phillwxnox: 13.04 will happen01:37
cjwatsonphillw: I mean specifically the "Raring Daily" milestone, in case that wasn't clear01:37
cjwatsonObviously it's the way to go for the beta01:38
xnoxphillw: i'm not sure you understood me right. We currently have two active milestones: (a) beta1 for all products that are participating in beta1 (b) daily milestone for the rest. And we need both active right now, for everyone to be able to report results against all images.01:39
xnoxJust because lubuntu is doing beta1, it shouldn't stop testers from reporting bugs against daily ubuntu server images =)01:39
phillwcjwatson: I may have lost something, but as we used to hit alpha's we did a freeze, then relax it when the alphas were released. As it got to Beta 1, most stuff was frozen... then we got Beta 2... at which pint even the brass monkey's balss were frozen without special permission?01:40
xnoxonce beta1 is out - we will only have raring daily active, then at beta2 time - only beta2 milestone will be active as I believe at the moment everyone will be participating.01:40
phillwxnox: I recall kubuntu closing down the general releases for an alpha release?01:41
xnoxphillw: we no longer do "full freeze", we only freeze participating products. E.g. stuff that is on ubuntu server images only is not frozen.01:41
stgraberxnox: nope, it's not done that way anymore ;)01:41
stgraberxnox: even for beta-2 and final we'll keep the daily milestone active01:41
cjwatsonWell.  We no longer do full-freeze for milestones; we will still do it leading up to the full release01:42
xnoxstgraber: is that an implementation detail, or we have two sets of images?01:42
phillwstgraber: cjwatson thanks for the update :)01:42
xnox(daily and candidates) ?!01:42
cjwatsonThe daily milestone thing was a change from https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-prior-release-feedback01:42
stgraberxnox: implementation detail. It's just that in the past we couldn't share builds between milestones on the tracker. Since early this cycle we can, so there's no reason to disable the daily milestone.01:43
stgraberxnox: results reported against the daily milestone for products part of a milestone will show up in the milestone view automatically01:43
phillwSo, as lubuntu has chosen beta, you are still going to build dailies?01:43
cjwatsonstgraber: Ah, so there we go, phillw's concern is moot then01:43
cjwatsonphillw: Every single image we ever release is a "daily" in some sense01:44
cjwatsonphillw: The "Raring Daily" vs. "Raring Beta 1" thing on the tracker - think of that just as a tag01:44
cjwatsonThey're the same underlying image01:44
stgraberthough we don't necessarily build "daily" images, well, "daily" :) which may be slightly confusing :)01:44
xnoxphillw: doesn't matter where the bug is reproted (daily or beta1) on the iso tracker, as long as the buildstamp matches it's a bug affecting that image and hence affecting all milestones it's part of.01:44
phillwcjwatson: is daily === beta 101:44
cjwatsonstgraber: Well, sure, same mechanism though01:44
phillwand I mean ===01:44
cjwatsonphillw: The beta will be *a* daily01:45
cjwatsonIt would be extremely foolish of us to have a separate mechanism for building release builds01:45
phillwcjwatson: the beta is already there01:45
cjwatsonphillw: No, candidates for the beta are there01:45
xnoxphillw: ~= there are less images on the beta 1 vs daily, but for those that are in both they are the same.01:45
cjwatsonThose candidates are identical to the current daily build01:45
phillwcontinuing to build dailies would cause confusion?01:46
stgrabermilestone testing is just a matter of building a bunch of "daily" images (but not necessarily at a 24h interval), until one is considered good enough, which becomes the milestone image (by the simple fact of being copied to another directory basically)01:46
cjwatsonThe products that are participating in the beta are on manual-build-only01:47
cjwatsonAny build == a respin01:47
xnoxphillw: we rename daily build to be lubuntu--raring-beta1-amd64.iso once we are happy with that daily build. hence zsync urls, download locations, etc are all the same. it's only the iso tracker that is in "special" mode.01:47
cjwatsonWe have only one mechanism for builds, i.e. "trigger a 'daily' build", so it wouldn't be a good idea to keep on doing cronned builds that aren't necessarily going to be beta01:47
* xnox feels like i'm not helping, but just adding to the confusions and missunderstandings.01:48
* xnox shuts up now.01:48
cjwatsonI don't think it would be helpful for /daily-live/current/ not to point to the images currently being tested01:48
phillwI'm now really confused.... when the daily was plucked to be the mile-stone RC, the daily build (cron job) was turned off. Only a respin would occur manually? I seem to have missed out on what has changed :(01:48
cjwatsonThis is how it's always been01:48
cjwatsonWe disable cron jobs leading up to milestones01:48
stgraberphillw: nothing has really changed. At the moment there are no automated builds for the products participating in beta-1. The only small difference is that if someone asks for a respin, it'll show up under both beta-1 and daily on the ISO tracker (where in the past it'd only show up under beta-1).01:49
cjwatsonThe most important changes this cycle in this general area are essentially (a) the presentation in the ISO tracker (b) most Canonical products not taking part in milestones (c) freezes being a bit more fine-grained01:49
cjwatsonBut the way in which we execute and organise the actual image builds hasn't changed materially01:50
stgraberoh wow, I didn't realise grub was taking so long to build on x86!01:51
stgraberI was expecting it to be done building by the time I got back home01:51
cjwatsoncommon, emu, pc, coreboot, efi-ia32, efi-amd64, ieee1275, firmware-qemu01:52
cjwatsontakes a while01:52
=== knome_ is now known as knome
ScottKcjwatson: Also I think that being able to block transitions vice prevent uploads during freeze periods is a significant change.01:54
cjwatsonno, I think it's stuck in the test suite :-(01:54
cjwatsonScottK: that was (c), I think01:54
cjwatsonI was abbreviating :)01:54
phillwstgraber: thanks for the information.01:57
cjwatsonstgraber: I'll run a test build here - in the meantime I doubt I will be able to fix this before (my) tomorrow as I really need to sleep soon01:59
phillwSo, guys, can i announce that the beta 1 is out and about?01:59
stgrabercjwatson: ok, no worries. Edubuntu 64bit is pretty quick to test and we're pretty used to only getting to testing it late on Wednesday :)01:59
ScottKphillw: Candidate.  Not Beta 1.  It's Beta 1 once it's released.02:01
phillwScottK: sorry, when on this channel, I tend to ignore the RC bit :) I'm asking for the testers to test it :D02:06
ScottKOK.  Just trying to make sure we're clear.02:06
phillwScottK: amongst my many sins, I am the TL for lubuntu-qa and one of the the lubuntu-release-managers ;)02:08
=== Ursinha_ is now known as Ursinha
=== rsalveti_ is now known as rsalveti
xnoxinfinity: hppa build queue is out of control =) 3 jobs in the queue and the builder is off /o\03:27
phillwstgraber: it has taken this long to ask about the difference between the 'Beta 1' and daily builds. Sorry to be a pain, but I still do not get this new system. :'(03:37
xnoxphillw: look at cdimage.ubuntu.com/ notices a few builds of isos. notice that current is a symlink simply pointing to a latest build. check iso tracker - notice how there are two milestones, check the build numbers of the same image in both milestones, notice that they are the same.03:48
xnoxconclude - all roads lead to rome. the last build daily is the current candidate for beta1 milestone and at the same time the last/current built daily.03:48
xnoxthus reporting results against either of the milestones will rightfully affect both of them, as there is only one image.03:50
xnoxphillw: all of the above has always been the case. no change to the system.03:51
xnoxone can figure out that current/ is just a symlink to the last built, by comparing the checksums, they are the same.03:52
phillwxnox: sorry, as we adjoin beta's and I wish to get Iso's installed as secondarily mirror.04:24
phillwxnox: I have them installed as zsync, I then keep them updated.04:25
ScottKphillw: You can just zync current and you'll always have the right one.04:38
infinityxnox: Yeah, we're either going to recover a parisc machine, or just delcare it EOL a tad early, depending on effort required.04:39
infinityxnox: It's technically EOL anyway, since it wasn't a supported arch, so no one's terribly fussed.04:39
micahgI still deny that archs are EOL early due to being unsupported at all, support can be EOL early (armel on lucid), but something like powerpc on lucid was never supported, so to say that it's EOL due to being unsupported seems imprecise04:41
antarushave you tried simply asking debian?04:42
antarusI think they have a bunch of parisc stuff04:42
phillwScottK: with the greatest respect, when testing dailies.. they can be a case of you are 3 /4 tests into the spin and then it gets re-spun (https://wiki.ubuntu.com/Lubuntu/Testing#When_do_they_build.3F )04:43
micahgI would agree that it might not be worth resurrecting the hardware, especially if there aren't any users04:44
phillwxnox: https://wiki.ubuntu.com/Lubuntu/Testing#QA_testing_of_Milestone_releases04:50
phillwnow, do tell me where the link 'magically' changes?04:51
infinityantarus: Not worth sourcing hardware for the last 1.5 months, but I'm working on a duct tape solution right now.04:52
infinitymicahg: No, in general, I'm with you on the "don't count arches out early" thing, but this late in hardy's support cycle, it's not worth resurrecting hppa for its 0.3 users unless it's low-effort.04:52
antarusthe best i got for parisc is a 552mhz PA 860004:52
antarusbut I'd probably have to bribe vapier with free gropes to get you access04:53
infinityantarus: Access to hardware isn't a huge issue, I have a machine in my garage identical to our buildds.04:53
* antarus nods04:54
antarusok then ;)04:54
micahginfinity: I would tend to agree FSVO low effort04:54
antarusprops for having weird kit then04:54
* antarus got rid of all his ;p04:54
infinitymicahg: Yeah, we're putting a tiny bit of effort into it as we speak.  Literally as we speak.04:55
infinitymicahg: Trying to wrap some duct tape around kohnen to get it to survive a month or two, since primero's well and truly dead.04:55
micahginfinity: I'm sure you're doing what you can to revive it04:56
infinitymicahg: I have no hard data to support this, but I suspect that the only users of Ubuntu/hppa were lamont and I, which sort of explains why literally no one cared about it when we stopped caring. :P04:57
phillwxnox: have you managed to get a 10.04 server updated yet?04:57
infinity(There may have been a few other experimenters, but not "users", per se... Like, Carlos had Ubuntu chroots, but runs Debian, etc)04:57
micahginfinity: makes sense, I suppose you could count how many time the hppa Packages file is read on the ports server04:58
antarusyeah Gentoo has the same sort of deal with the weird arches04:58
antarus1 guy maintains them, about 3 people care04:58
antarusthey are always behind at building / stablizing stuff04:58
infinityantarus: Well, given how relatively easy it is to pass the Debian release arch criteria, I think it's pretty telling when a Debian arch flips from official to ports, which parisc did a long while back.04:59
phillwhay, look on the bright side of things, my / partition went 100% when CentOS 6.3 went to CentOS 6.4... I'm sure ubuntu would 'never' fill a 10 GB / area .....05:00
antarushaha hahaha they have 'criteria'05:00
infinityantarus: They do.  It was originally designed (he says bitterly, in an unfair accusaion of conspiracy against his work) as a way to drop m68k, but seems to have become a decent set of guidelines for supportability of an arch.05:01
infinityantarus: http://release.debian.org/wheezy/arch_policy.html05:07
slangasekinfinity: naw, it was designed as a way to drop m68k /and arm/ ;)05:08
infinityslangasek: And then ARM went and became relevant.  Jerks.05:08
slangasekso see, you have the Debian cabal to thank for ARM getting their act together05:08
infinityslangasek: In fact, I suspect that the "only 2 buildds" thing is still not true for ARM.05:08
slangasekif we hadn't demanded faster buildds, nothing would have happened!05:08
ScottKAnd, IIRC, when Debian dropped hppa, it was the last major distro to support it.05:08
infinityslangasek: Though it may be some day.05:08
slangasekinfinity: hmm, I think Debian relaxed the "only 2 buildds" requirement though?05:09
ScottKphillw: I don't see your point.  /current is still always what you want.  If /current gets updated, then test that.05:09
infinityslangasek: It's still in the wheezy list.05:09
slangasekwell, ok05:09
antarusScottK: hey hey hey, Gentoo still supports hppa ;)05:09
ScottKantarus: I stand by my statement.05:09
infinityslangasek: I'm guessing it's just ignored if the rest of the bullet points get hit.05:09
slangasekinfinity: I think generally, it's ignored if DSA don't have to spend large amounts of Quality Time babysitting a dogsled team of buildds05:10
infinityslangasek: Well, back when the proposal was first written, DSA didn't manage many buildds at all.05:10
slangasekinfinity: wasn't it required that the security buildds be DSA-managed?05:11
infinityslangasek: AFAIK, they're all ldaped now, though day-to-day is still handled by porters.05:11
slangasekdunno, my memory is fuzzy05:11
infinityslangasek: Oh, yeah, kullervo was ldapped (though still managed by me, just had DSA access)05:11
* antarus cringes at ldap05:11
infinityantarus: ud-ldap is only ldap in name, really.05:11
infinityantarus: More appropriate to call it libnss-db at the host level.05:12
infinity(Cause it is)05:12
slangasekinfinity: as for hppa moving to ports, ISTR there were some big pthreads problems that may have prompted this05:13
antarusinfinity: thank god05:13
antarusnss_ldap is a sin05:13
antarusand should be burned05:13
infinityslangasek: Yeah, upstream parisc support in glibc was awful for a while.05:13
infinityslangasek: Carlos fixed most of the glaring issues, but I doubt anyone cared/cares enough to re-propose it as an official arch.  I know I don't anymore.05:14
infinityantarus: I tend to think (especially in a distributed network like Debian's) that any auth system that relies on remote machines is a sin.05:15
* antarus was surprised by how many dev machines debian had05:15
antarusgentoo has so few :/05:15
infinityantarus: The ud-ldap setup has a central ldap DB and pushes updates to machines via SSH triggers, which they then build into Db files for libnss-db, so the machines don't neet to rely on a remote network to work.05:16
antarusinfinity: there are always trade-offs ;)05:16
antarusyeah I know how libnss-db works05:16
antaruswe wrote our own thing of course05:16
antarusbecause thats what we do05:16
infinityI think everyone has.05:16
infinityWell, ud-ldap actually got some traction in other places, but every one of those places was because Debian developers had influence (freedesktop.org was my fault, canonical/ubuntu was elmo's fault, etc)05:17
antaruswe built nsscache05:17
antarusand then I gave it to Gentoo05:17
antarusso gentoo uses it05:17
antarusunsure if anyone else did05:17
antarusjust like everyone manages their own bind zonefile mess05:18
* antarus cringes05:18
infinityI admit that I write bind zonefiles by hand, but I also understand why that's entirely untenable for people with millions of zones in constant flux.05:19
infinityNot that the format is hard to write a quick read/write parser for, if you introduce artificial constraints.05:19
antarusThe Gentoo zones are maintained in git, and there is magic to build them and DNSSEC sign them05:20
antarusmagic perl that I do not understand05:20
antarusif the author gets hit by a truck; I will have a bad time :/05:20
infinityTurns out that there are a lot fewer programmer-seeking trucks out there than we generally fear.05:20
ScottKfear/hope in some cases.05:22
antarushey now05:24
micahginfinity: fortunately, there aren't a lot of Agent Smiths' driving around :)05:39
* infinity takes micahg's apostrophe and crushes it under his heel.05:42
=== tkamppeter_ is now known as tkamppeter
tkamppeterinfinity, have you seen my messages about GS 9.07?07:16
infinitytkamppeter: If it's AGPLv3 (or if the license reads "vN or later"), then it should be fine.07:25
infinitytkamppeter: If it's AGPLv1, we have a small problem in that we can't link pure GPL code with it and distribute the result.07:26
infinitytkamppeter: Which would make it a bit difficult to, say, distribute gimp.07:27
tkamppeterinfinity, this is OK, GS is AGPL v3+07:40
infinitytkamppeter: Kay, then just make sure debian/copyright gets a treatment to still be correct, and it should be fine.07:42
tkamppeterinfinity, OK, thanks, waiting for RAOF to fix the bug ...07:42
tkamppeterinfinity, another question, foomatic-db and foomatic-db-engine are still in raring-proposed, what moves them into raring?07:58
infinitytkamppeter: They're in the frozen list for beta-1, they'll migrate after Thursday.08:12
infinitytkamppeter: See http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html08:12
=== agateau_ is now known as agateau
didrockscjwatson: hey, do you know if the LP API enable us to retrieve a source package from a ppa (like downloading it)?10:27
didrockssourceFileUrls maybe…10:27
Davieydidrocks: Yes, we do something for mythbuntu https://github.com/MythTV/packaging/blob/master/deb/debian/LP-get-orig-source.py10:32
didrocksDaviey: oh excellent, thanks for the link!10:32
didrocksyeah, so once I get my getPublishedSources(), just calling sourceFilesUrls and urlretrive it10:32
Davieydidrocks: people seem to be moving away from urllib in favour of python-requets10:34
didrocksDaviey: interesting… never looked at that one. Will definitively give it a look, thanks!10:35
DavieyAs you can't do *.changes signature validation, you probably should do https validation10:35
Daviey(which requests does better than urllib)10:36
tumbleweedby doing it at all...10:41
xnoxtumbleweed: can we have pull-ppa-source please?10:48
* Laney hands emacs ubuntu-dev-tools/pull-ppa-source to xnox10:49
xnoxphillw: i don't understand your argument about "3/4 of tests in and 'daily' arrives". During milestone, images are not triggered/build daily, instead they are build on manual, only when we decide to respin and push the notice to the iso tracker, etc. And yes it will be the same location as usual /current.10:50
cjwatsonHe's offline10:50
* xnox needs to brew coffee.10:54
=== mmrazik is now known as mmrazik|lunch
cjwatsonstgraber: I've screwed up cdimage fairly massively, apparently - bug 1153992, currently trying to figure out full impact11:02
ubot2Launchpad bug 1153992 in debian-installer (Ubuntu) "Raring server and precise d-i installations fail at the clock configuring step" [Undecided,New] https://launchpad.net/bugs/115399211:02
Riddellanyone know why kubuntu-settings isn't getting into -released ?  I can't work out what update_output.txt is saying about it11:30
cjwatsonupdate_excuses.html says "kubuntu-settings-desktop/i386 unsatisfiable Depends: kubuntu-qtquick1-components" which is probably a more immediately useful hinit11:31
cjwatsonNo such package AFAICS11:32
xnoxplease wait for matching tcltk-defaults.11:57
phillwHi folks, has AMD64+Mac been dropped from the ISO's?12:00
cjwatsonphillw: No change there12:06
* cjwatson fixes bug 1153992 and tries to work out what to respin12:07
ubot2Launchpad bug 1153992 in Ubuntu CD Images "Raring server and precise d-i installations fail at the clock configuring step" [Critical,In progress] https://launchpad.net/bugs/115399212:07
=== popey_ is now known as popey
* cjwatson sticks a notice on the iso.qa board12:08
cjwatsonRaring respins as follows: Lubuntu Alternate *, Ubuntu Server * (I think the latter isn't taking part in the beta though)12:39
cjwatsonPrecise respins as follows: Kubuntu Alternate *, Ubuntu Alternate amd64+mac amd64 i386, Ubuntu Server *, Xubuntu Alternate *12:40
cjwatsonAll marked on the tracker.12:41
cjwatsonJackYu: Not quite sure whom to tell about this, but the bugs quoted for UbuntuKylin Desktop i386 on http://iso.qa.ubuntu.com/qatracker/milestones/261/builds are mostly quite broken.  Just hover over them and you'll see what I mean.12:43
=== mmrazik|lunch is now known as mmrazik
phillwcjwatson: I know you're busy, but is https://wiki.ubuntu.com/Lubuntu/Testing#Rebuilding_a_Release_Candidate now correct (I've removed reference to the Ether Pad).12:53
cjwatsonAside from grammar, yes :)12:54
cjwatson(Though I've only checked that entry, not the rest of the page)12:55
phillwcjwatson: thank you grammar nazi :P It now is structured correctly12:57
cjwatsonHey, you asked12:59
phillwno worries, I usually have a guy in Brazil do my grammar checking ;)12:59
lamontinfinity: the buildds also use the hppa bits.  and they get mirrored by a few people (who mirror ports) and yeah, at its high point, I think we may have had 5-endusers (developers/experimenters all) that actually used machines for other than supporting the effort of building the bits in any way13:03
infinitylamont: *nod*13:05
infinitylamont: Anyhow, I just followed up to that ticket (59816) saying that kohnen seems to be chugging/hobbling along reasonably well enough to get us to hardy EOL, so feel free to close it off.13:05
stgrabercjwatson: good thing we don't have that many non-live products then.13:30
JackYucjwatson: thanks, we are dong it:)13:40
xnoxplease denew tcl8.5 together with tcltk-defaults, and if autohinter fails -> hint them together. This is a package split for multiarchification14:01
xnoxinfinity: ^14:01
* xnox hopes i got all the symlinks rights14:01
infinityxnox: If the autohinter fails, it's almost certainly because the packages are broken.14:03
* infinity notes that 99% of the time people ask for a hint, they're really asking me to debug their packaging.14:04
xnoxinfinity: well this is all -> any transition with a split. Last time around, that failed autohinting. Although I may be missing replaces & conflicts on the -lib package, not sure.14:05
infinityxnox: If you're missing replaces, please fix.  britney doesn't look at package *contents*, it won't catch that.14:05
xnoxinfinity: yeah, will test once above is published =) easier that way ;-)14:06
infinityxnox: If the lib package only contains things in a multi-arch path where they never existed previously, you're fine.14:06
xnoxi like that =)14:07
infinityYeah, that looks fine to me.14:07
infinity(Just downloaded the deb to look)14:08
xnoxinfinity: note that tk was not multiarched yet, so at some point in the future there will be tk & tcltk-defaults combo ;-)14:08
infinityxnox: Plus, you get to do this in 8.6 as well (and push to Debian).14:08
jokerdinohi guys. what's the procedure for reviewing new packages in the archive? :)14:09
xnoxphhhh enough of tikle for me for the day.14:09
jokerdinoone of our package is in the new queue for a week now. it kinda feels bothersome.14:09
infinityjokerdino: Which one?14:10
xnoxjokerdino: what's the package name?14:10
xnoxjokerdino: i'd rather see it in myapps to be honest, as unity <=> treak-tool can rapidly break comparability. How do you handle if unity moved on and is not what unity-tweak-tool is expecting? e.g. settings names moved & renamed?14:11
xnoxe.g. last time around a tweak-tool was removed because unity changed and the tweak-tool ended up (a) crashing new unity (b) crashing itself as well and thus ended up at the top of the errors.ubuntu.com14:12
jokerdinoxnox: uhm, myunity was in universe though no?14:12
xnoxkeyword "was"14:13
jokerdinowell, we have done better work than that.14:13
xnoxit kind of also implies that we potentially don't want it in the archive.14:13
tumbleweedxnox: IIRC that was actually removed because it wasn't ported to a newer gambas14:13
xnoxjokerdino: so why not go the myapps route and publish for stable series only, where you know that unity is stable and will not rapidly change?!14:13
tumbleweedbut yes, we want packages in the archive to be actively maintained. and packages like this seem to need more maintainance than most14:14
infinityxnox: Given that it's been getting reviewed by the desktop team, I'm not going to pass "don't want it in the archive" judgement.14:14
jokerdinowe can maintain. i promise.14:14
xnoxjokerdino: also note that I'm nobody, just a bystandard =)))) (I'm not an ArchiveAdmin and really don't have any say as to what gets accepted into archive)14:15
jokerdinoinfinity: it's been passed onto the desktop team?14:15
infinityjokerdino: I was referring to mterry's reviews in the bug.14:15
jokerdinooh, that.14:16
infinityI'm curious about the native packaging without a strong version->commit mapping, but whatever.  Not my package.14:16
infinityAnd, hypocritically, I maintain a similar package with random upstream commits pulled into it.14:17
jokerdinoinfinity: heh, we are using git tags for version -> commit mapping.14:17
infinityjokerdino: Oh, are you?  That didn't seem to be implied from the bug log, where previous reviews were of 0.0.3, and that's the version of the current upload.14:18
jokerdinoinfinity: hm, the one uploaded is 0.0.3 with all the fixes incorporated.14:19
infinityjokerdino: Right, but the earlier ones were also 0.0.314:19
infinityjokerdino: Which seems to contradict the claim that tags match versions. :)14:19
jokerdinoyeah, we were a bit too flexible.14:19
infinityjokerdino: Unless you deleted the tag.14:19
smartboyhwUh oh14:20
infinityjokerdino: (Which is generally a Bad Idea in git)14:20
jokerdinono, the tag was only added after it was uploaded ;_)14:20
cjwatsonAll the respins seem to be done now.  I only hand-checked Lubuntu.14:20
infinityjokerdino: Ahh.  Kay.  That's fair.14:20
cjwatsonThough server amd64 looks fine too.14:20
jokerdinoinfinity: yeah, we are stingy about tags though.14:21
infinityjokerdino: I'll give it a proper review in a bit.  Do keep in mind that if it does end up being problematic and breaking the world, the knee-jerk reaction if it's not fixed fairly promptly will be to tear it out of the distro again.  We've had some pretty bad experience with such things in the past. :/14:21
jokerdinoi can fix it on a daily basis as long as i get sponsors :)14:22
jokerdinoand thanks for reviewing!14:23
infinityjokerdino: Sure, "fixed" doesn't mean "uploaded".  Filing a bug with "oh god, it broke, can someone please sponsor 0.0.5 from git://foo" would be fine.14:23
jokerdinohm, so we are talking about fixing in a developer sense?14:24
jokerdinothat wont be an issue. we got a small team of devs across the time zone :)14:24
infinityjokerdino: Good to know.  If there's a reasonable commitment to keep it not broken, then I'll just review it for general packaging sanity and ignore my fears about tweak tools being evil.14:25
=== ogra_` is now known as ogra_
infinityogra_: Aww, you dropped a pointless character from your nick.14:26
infinityogra_: Does this mean that in another six months, you might actually be "ogra" again?14:26
ogra_yeah, no idea how that got there14:26
jokerdinoinfinity: heh, it's not as evil as you think. it passed at least three MOTU reviews for good.14:27
ogra_i'm to lazy to convince nickserv to play with bip, else i would already14:27
infinityogra_: Ditch bip and use irssi as a proxy.14:27
infinityogra_: Then you have all of irssi's script-fu at your fingertips.14:28
ogra_well, i'm happy with bip ...14:28
jokerdinoand do drop by ask ubuntu as and when you have time. :)14:28
ogra_its just the reconnects that make me grow a tail ...14:28
ogra_i doubt irssi would cope much better with that14:28
tumbleweedyou can script it to cope with it14:29
ogra_if the former ogra is still registered nickserv simply refuses to let me have that nick14:29
jokerdinoghost the ogra out?14:29
ogra_yeah, i know with ghosting etc14:29
jokerdinoghosting makes me feel geek-y. impresses the new folks :P14:29
jokerdinoyou can probably script the ghosting too.14:30
* xnox uses znc, haven't tried any other proxies.14:30
dobeywhat are the exact dates for EOL for Lucid Desktop and Oneiric?14:32
tumbleweeddobey: wiki.ubuntu.com/Releases14:32
dobeytumbleweed: i was just there. it only says "April, 2013" no exact dates14:33
xnoxdobey: https://wiki.ubuntu.com/#Releases14:33
tumbleweeddobey: ah, the same day of the month taht it released on14:33
xnoxdobey: usually towards the end of the month, when it's quiet, not during freeze week for devel release, and when IS is free to like move the archive & cdimages around to old-releases and things like that.14:34
xnoxdobey: usually we try to EOL, before releasing next-devel, so i'd expect those to be EOL before april 22nd.14:35
cjwatsonIS moves the archive, but we (well, usually I) move cdimage14:37
xnoxalso hardy server is going EOL.14:37
infinityxnox: We try to EOL before releasing next-devel?  Really?  I tend to err in the other direction.14:41
infinityOverlaps are better than gaps and all.14:41
tumbleweedI don't think this is going to be a useful overlap for lucid. but possibly for oneiric14:42
xnoxi distincly remember karmic to go a little ahead of it's time.14:42
xnoxdisk space issue maybe at the time?14:43
xnox(not sure if it was archive or cdimages or both though)14:43
infinityThere could have been a cdimage space panic.  We've had a few.14:44
cjwatsonI don't think it really matters - there aren't usually updates happening anyway14:44
infinityShouldn't be an issue currently.14:44
infinityBut yeah, it largely doesn't matter when the EOL announce or the various moves happen, as long as it's about the right time, ish. :P14:44
ogra_rsalveti, well, the phablet sync script would run every hour at :35 *if* not someone had removed it from crontab for whatever reason14:55
* ogra_ knew he should have kept it in his personal crontab instead, i dont even remember the line i used 14:57
cjwatsonI was very careful not to.  I suspect somebody blatted it using the one in bzr14:57
cjwatson# Ubuntu Phablet sync from jenkins (interim solution)14:57
cjwatson35 * * * *      /home/ogra/sync-phablet-images14:57
cjwatsonogra_: ^- I happened to have that in scrollback14:57
ogra_ah, thanks :)14:57
ogra_it didnt feel right to put it into bzr since its a hack14:58
cjwatsonAlso since the code it's calling isn't in bzr14:59
* ogra_ put it in a README.crontab in his home 15:00
infinityMaybe stgraber blatted it when he disabled things for Beta.15:00
ogra_restored ...15:00
infinitystgraber: If it was you, please don't install crontab from bzr without diffing against production.15:01
cjwatsonI tweaked the comment a bit since I preferred the old one :-), and added a line break to try to make it clearer15:11
=== mmrazik is now known as mmrazik|otp
stgraberinfinity: yeah, must have been me. I wrongly assumed that etc/crontab on nusakan would have contained the changes too (as uncommited changes) but I guess that's just how I do things and not how the rest of us do15:43
xnoxinfinity: well I'm getting c-m for tcl-lib, can that be put in main please? =)15:45
xnoxat least something broke, lol =)15:45
cjwatsonEh, that's a c-m saying "move to universe"15:46
cjwatsonIf you want it in main, needs seeding somewhere15:46
cjwatson*if you want it to stay in main15:46
=== mmrazik|otp is now known as mmrazik
infinitycjwatson / xnox: Err, does nothing depend on it?15:52
* infinity is failing to see how this multiarching can possibly work if tcl doesn't depend on tcl-lib.15:52
xnoxinfinity: correct.15:52
* xnox goes to fix it.15:52
xnoxi feel more confident, now that there is finally a bug found in my upload.15:53
=== ev_ is now known as ev
infinityxnox: Why is there a tcl-lib at all, actually?15:54
infinityxnox: I can't fathom why someone would want to install that on their own to have "the default tcl-lib".15:54
infinityxnox: It would be like gcc-defaults producing an unversioned "libgcc" just in case someone wants the "default" one.15:55
infinityxnox: As long as tcl depends on tcl8.5 and tcl8.5 depends on tcl8.5-lib, that all seems sane.15:55
xnoxinfinity: version-less .so file somebody can depend on? (e.g. tcl.so vs tcl8.5.so)15:56
xnoxso tcl-lib ships that symlink.15:56
infinityxnox: Oh, that used to exist in the pre-MA packages?  Icky.15:56
* infinity wonders why that was considered a good idea, but lets it drop.15:57
xnoxwhich seems wrong, as moving the default breaks the world. I'm not sure why pre-MA tcl-dev did that as well. I wonder if the tcl world is broken and did not expect to support multiple co-installable tcl releases.15:57
infinityThe unversioned .so seems like a strange thing, for sure.15:58
xnoxinfinity: I'm no tcl expert by any extend, but i'd consider dropping it in 8.6 transition and will poke debian people about it.15:58
infinityI suppose for people who like to dlopen with reckless abandon.15:58
infinityMaybe there are some weird upstream projects that do such things.15:58
infinityOr, or more likely, upstream build systems that don't expect the versioned .so when searching/linking.15:59
infinitySo, there might be a slightly valid reason for it.15:59
* xnox totally broke that -defaults upload *sigh*15:59
=== Ursinha is now known as Ursinha-afk
stgrabercjwatson: had any luck with grub2 so far?16:05
cjwatsonstgraber: I've yak-shaved my way through that problem to the point where I'm reading the ACPI spec16:05
cjwatson(Don't ask, you really don't want to know)16:05
cjwatsonWhatever it is is triggered by raring's seabios16:06
stgraberhmm, ok. "ACPI spec" is usually enough of an indication that I don't want to know ;)16:06
cjwatsonIt's my first direct exposure16:07
stgraberI've heard mjg59 complain enough about it that I never had any kind of willingness to read it ;)16:10
xnoxcjwatson: pitti: the email is wrong though, it's titled "universe -> main" yet it's actually reverse.16:10
xnoxhence my confusion.16:10
cjwatsonAh, could be.  Patch to lp:ubuntu-archive-tools welcome16:12
=== mmrazik is now known as mmrazik|afk
=== mmrazik|afk is now known as mmrazik
xnoxcjwatson: hm... i see the report generator (and the report is correct), what does "diff" & email notification?16:17
cjwatsonOh, sorry, that's apparently only in lillypilly:~ubuntu-archive/bin/16:17
phillwa quick question.. why is a beta 1 iso pulling in lots of files when it is at the 'configuring apt' stage? (lubuntu alternate AMD64)16:24
cjwatsonIt typically updates from the network archive at that point if it can16:30
cjwatsonIn order that, for example, it can install localisation packages that aren't on the image if it needs to16:30
phillwokies, thanks :)16:34
blitzkrieg3would it be possible for someone to sponsor bug 102550817:00
ubot2Launchpad bug 1025508 in OEM Priority Project precise "Some keys in keyboard layout show duplicate character labels" [Medium,In progress] https://launchpad.net/bugs/102550817:00
Riddellnew ubiquity uploaded17:04
infinityblitzkrieg3: You want #ubuntu-devel, and the patch pilot listed in /topic17:05
blitzkrieg3infinity: thank you17:05
=== yofel_ is now known as yofel
xnoxrelease team, FFe for bug 1148014 pretty please =)17:17
ubot2Launchpad bug 1148014 in mksh (Ubuntu) "FFe: Please merge mksh 44-1 (main) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/114801417:17
=== mmrazik is now known as mmrazik|afk
infinityxnox: changelogs look reasonable to me.17:20
xnoxinfinity: thanks.17:23
=== mmrazik|afk is now known as mmrazik
=== maxb_ is now known as maxb
=== Ursinha-afk is now known as Ursinha
=== bjf is now known as bjf[afk]
=== Ursinha_ is now known as Ursinha
zequenceI marked the ubuntustudio isos for beta1 to be rebuilt, but wondering how that works. It says rebuilding, but when is the build done?20:22
infinityzequence: Marking them doesn't actually respin them, it's just a UI thing that means "don't test these ones, we're respinning".20:37
infinitystgraber: zequence needs a studio respin.  I'm off to nap, so can't babysit.20:37
stgraberzequence: did you confirm the packages you need are all built and ready in the archive?20:39
=== bjf[afk] is now known as bjf
zequencestgraber: Yep20:42
stgraberzequence: ok, building now then20:57
zequencestgraber: Thank you20:57

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!