[00:20] It 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, thanks [00:49] stgraber: do you have the link to ether pad for while we are in beta 1, or is not being used? [00:49] I hope we have thrown etherpad in the bin it deserves [00:49] cjwatson: so, I guess we do not know what re-spins are planned :( [00:50] stgraber may not share my dislike [00:50] phillw: as if there are no other means of communication [00:51] cjwatson: 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] no etherpad [00:52] when people want respins they ask for them and I mark them as such on the tracker [00:52] personally I find chisel on stone more usable than etherpad. (I like the idea but the implementation is awful.) [00:53] cjwatson: 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] Of course they can have an ISO respun while they're testing; that's unavoidable [00:54] And if they're due to be respun they can be marked as such on the tracker [00:54] I 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] Editing the etherpad was unusably awful and confusing [00:55] * stgraber is out for the next 30min [00:58] cjwatson: 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] The pad doesn't help with that [00:59] It's reload one page vs. reload a different page [00:59] Reloading the tracker stands a better chance of being a page they're on anyway [01:00] And for discussion we can/should use things better suited for discussion - IRC for transient things, maybe a wiki if we need something more persistent [01:00] cjwatson: it would at least let them know what was planned? I know it was not perfect. Do we have a better system? [01:00] Clinging to the pad isn't the answer [01:00] Planning - 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 helpful [01:01] cjwatson: indeed, but respinning immediately with no notification? [01:01] And 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 fashion [01:01] Which we didn't necessarily do before [01:02] cjwatson: where are such announcments made? [01:02] Here, and I'm sure stgraber would be happy to copy them to #ubuntu-testing too [01:03] And on the tracker [01:03] cjwatson: I'm only trying to update the sequence :) [01:05] cjwatson: stgraber, so the only pre notification of a 'planned' respin is when the ISO tracker strikes them out for a re-spin? [01:05] no prior notification for people part way through the tests? [01:06] phillw: 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] Indeed [01:06] phillw: as iso tracker is become more and more flexible than it was before. [01:06] And there's no purpose in waiting further if we know we're going to respin anyway [01:06] s/become/becomming/ [01:06] That would only waste *more* of testers' time [01:07] The 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 respins [01:07] xnox: 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] "prior notification" is not a useful goal [01:07] * xnox lately is having hard time typing. I should measure the frequency i post a sed commands. [01:07] Not in isolation [01:08] Because 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 nobody [01:09] phillw: 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] The problem in the past is that we've been so busy messing about editing the etherpad that we've forgotten to update the tracker [01:09] Partly because the etherpad was so bureaucratically complex to edit [01:10] Note 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] (At least, that's been my experience) [01:10] cjwatson: 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] I can't speak for any particular URL. I know the iso.qa front page can and does [01:10] Ah, yes, that's a milestone front page [01:11] cjwatson: xnox I agree with both of you. [01:11] Then yes, the products in question show as struck out [01:11] phillw: at the moment. see "notice board" no message, all is good. [01:11] And as xnox says we have a notice board for brief announcements [01:12] stgraber: can you put a placeholder (beermug?) message: "current images are being tested as potential candidates, no respins planned at the moment" [01:12] xnox 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] ? =) [01:12] phillw: Yes [01:12] I'm quite surprised that they aren't being told that already [01:12] So, no short cuts... send them to http://iso.qa.ubuntu.com/qatracker/milestones/261/builds [01:13] Since it's the one-stop-shop for recording test results [01:13] phillw: 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] cjwatson: a lot of the testers are using http://iso.qa.ubuntu.com/qatracker/milestones/243/builds [01:14] phillw: That's fine for daily build testing, but it will be disregarded for beta prep [01:14] phillw: I would actually suggest just telling them to go in through the iso.qa.ubuntu.com front page and select the proper milestone, but YMMV [01:14] you 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 betas [01:15] cjwatson: testers get used to the shortest link to zsync. [01:15] They shouldn't have been told that that was the place to go for all time in the first place [01:15] and the one that they use is the one that they use [01:15] Tell them otherwise [01:15] IME testers are not as inflexible as you suggest [01:16] xnox: Not to disrespect testers, but testing is a means to an end; the highest-quality release is the highest priority :-) [01:16] Hey, I can email the lubuntu team as to where everyone else goes for daily builds... pass. [01:17] cjwatson: and asking them to change their links for zsycnking all the time does not endear the -release team to the testers :D [01:18] phillw: 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 systems [01:18] In other words it's not me who's asking them to change their links, dude [01:19] cjwatson: I suggest you and iso tracker make peace? [01:19] I have no problem with the ISO tracker; but if people want constant links for downloads they should go straight to cdimage [01:20] cjwatson: "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 -O3 [01:20] we respect everyone =) [01:20] xnox: Indeed [01:23] I think this a good point for me to tip toe away from the discussion of 'dailies' becoming "RC's" [01:23] And BTW, it's got very little to do with zsync URLs and much more to do with where to record results [01:24] In 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 then [01:25] cjwatson: 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:26] Sorry, you say that as if it contradicts something I said but I don't see what? [01:26] I've not had a fail of able to boot on 13.04 [01:26] (And it seems perfectly reasonable to me) [01:28] cjwatson: as to reporting from iso-tracker, it is dismal and in effectual. There is a bug raised against it. [01:29] You mean reporting Launchpad bugs starting from iso.qa? That wasn't what I was talking about. [01:30] cjwatson: nah, it was about the ability for a person to actually search for results. [01:31] Sure, I'm aware that that is poor, but it doesn't seem to have anything to do with the above [01:32] cjwatson: it is actually a lot to do with it. https://bugs.launchpad.net/ubuntu-qa-website/+bug/1126449 [01:32] Launchpad bug 1126449 in ubuntu-qa-website "Getting a historical results report for a product is difficult" [Undecided,New] [01:32] It's *possible*, it's just not pleasant [01:32] But for this purpose it doesn't have to be pleasant [01:33] (Existence proof: stgraber can do SQL queries on the database ...) [01:33] You see, they have, a feeling of reporting stuff is just not carried over. [01:33] Well, on the daily builds it's not really [01:34] cjwatson: ut, heck, we were going to chat about this in UDS-S, and then look what happened :D [01:34] Realistically, I don't think iso.qa is a particularly effective way to report daily build problems right now [01:35] phillw: daily milestone is active for products that are not doing beta1, that's why at the moment both milestones are active. [01:36] cjwatson: well, it is frozen for beta. but I'm always open to ideas from [01:36] Which is one reason I think it's a little ... ambitious to have directed testers at the daily milestone in the first place [01:36] when everything is doing a milestone it will be easier. [01:36] xnox: as in rolling release? [01:37] phillw: no, as in beta2 where ubuntu when all images will be doing milestone release. [01:37] I mean, I would like it to be usable for daily build reporting, but we're not really there [01:37] * phillw please drop future and get 13.04 out [01:37] xnox: 13.04 will happen [01:37] phillw: I mean specifically the "Raring Daily" milestone, in case that wasn't clear [01:38] Obviously it's the way to go for the beta [01:39] phillw: 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] Just because lubuntu is doing beta1, it shouldn't stop testers from reporting bugs against daily ubuntu server images =) [01:40] cjwatson: 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] once 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:41] xnox: I recall kubuntu closing down the general releases for an alpha release? [01:41] phillw: 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] xnox: nope, it's not done that way anymore ;) [01:41] xnox: even for beta-2 and final we'll keep the daily milestone active [01:42] Well. We no longer do full-freeze for milestones; we will still do it leading up to the full release [01:42] stgraber: is that an implementation detail, or we have two sets of images? [01:42] stgraber: cjwatson thanks for the update :) [01:42] (daily and candidates) ?! [01:42] The daily milestone thing was a change from https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-prior-release-feedback [01:43] xnox: 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] xnox: results reported against the daily milestone for products part of a milestone will show up in the milestone view automatically [01:43] So, as lubuntu has chosen beta, you are still going to build dailies? [01:43] stgraber: Ah, so there we go, phillw's concern is moot then [01:44] phillw: Every single image we ever release is a "daily" in some sense [01:44] OMFG [01:44] phillw: The "Raring Daily" vs. "Raring Beta 1" thing on the tracker - think of that just as a tag [01:44] They're the same underlying image [01:44] though we don't necessarily build "daily" images, well, "daily" :) which may be slightly confusing :) [01:44] phillw: 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] cjwatson: is daily === beta 1 [01:44] stgraber: Well, sure, same mechanism though [01:44] and I mean === [01:45] phillw: The beta will be *a* daily [01:45] It would be extremely foolish of us to have a separate mechanism for building release builds [01:45] cjwatson: the beta is already there [01:45] phillw: No, candidates for the beta are there [01:45] phillw: ~= there are less images on the beta 1 vs daily, but for those that are in both they are the same. [01:45] Those candidates are identical to the current daily build [01:46] continuing to build dailies would cause confusion? [01:46] milestone 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:47] The products that are participating in the beta are on manual-build-only [01:47] Any build == a respin [01:47] phillw: 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] We 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 beta [01:48] * xnox feels like i'm not helping, but just adding to the confusions and missunderstandings. [01:48] * xnox shuts up now. [01:48] I don't think it would be helpful for /daily-live/current/ not to point to the images currently being tested [01:48] I'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] This is how it's always been [01:48] brb [01:48] We disable cron jobs leading up to milestones [01:49] phillw: 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] The 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-grained [01:50] But the way in which we execute and organise the actual image builds hasn't changed materially [01:51] oh wow, I didn't realise grub was taking so long to build on x86! [01:51] I was expecting it to be done building by the time I got back home [01:52] common, emu, pc, coreboot, efi-ia32, efi-amd64, ieee1275, firmware-qemu [01:52] takes a while === knome_ is now known as knome [01:54] hmm [01:54] cjwatson: Also I think that being able to block transitions vice prevent uploads during freeze periods is a significant change. [01:54] no, I think it's stuck in the test suite :-( [01:54] ScottK: that was (c), I think [01:54] I was abbreviating :) [01:55] Ah. [01:55] OK. [01:57] stgraber: thanks for the information. [01:59] stgraber: 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 soon [01:59] So, guys, can i announce that the beta 1 is out and about? [01:59] cjwatson: ok, no worries. Edubuntu 64bit is pretty quick to test and we're pretty used to only getting to testing it late on Wednesday :) [02:01] phillw: Candidate. Not Beta 1. It's Beta 1 once it's released. [02:06] ScottK: sorry, when on this channel, I tend to ignore the RC bit :) I'm asking for the testers to test it :D [02:06] OK. Just trying to make sure we're clear. [02:08] ScottK: amongst my many sins, I am the TL for lubuntu-qa and one of the the lubuntu-release-managers ;) === Ursinha_ is now known as Ursinha === rsalveti_ is now known as rsalveti [03:27] infinity: hppa build queue is out of control =) 3 jobs in the queue and the builder is off /o\ [03:37] stgraber: 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:48] phillw: 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] conclude - 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:50] thus reporting results against either of the milestones will rightfully affect both of them, as there is only one image. [03:51] phillw: all of the above has always been the case. no change to the system. [03:52] one can figure out that current/ is just a symlink to the last built, by comparing the checksums, they are the same. [04:24] xnox: sorry, as we adjoin beta's and I wish to get Iso's installed as secondarily mirror. [04:25] xnox: I have them installed as zsync, I then keep them updated. [04:38] phillw: You can just zync current and you'll always have the right one. [04:39] xnox: Yeah, we're either going to recover a parisc machine, or just delcare it EOL a tad early, depending on effort required. [04:39] xnox: It's technically EOL anyway, since it wasn't a supported arch, so no one's terribly fussed. [04:41] I 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 imprecise [04:42] have you tried simply asking debian? [04:42] I think they have a bunch of parisc stuff [04:43] ScottK: 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:44] I would agree that it might not be worth resurrecting the hardware, especially if there aren't any users [04:50] xnox: https://wiki.ubuntu.com/Lubuntu/Testing#QA_testing_of_Milestone_releases [04:51] now, do tell me where the link 'magically' changes? [04:52] antarus: Not worth sourcing hardware for the last 1.5 months, but I'm working on a duct tape solution right now. [04:52] micahg: 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] the best i got for parisc is a 552mhz PA 8600 [04:53] but I'd probably have to bribe vapier with free gropes to get you access [04:53] antarus: Access to hardware isn't a huge issue, I have a machine in my garage identical to our buildds. [04:54] * antarus nods [04:54] ok then ;) [04:54] infinity: I would tend to agree FSVO low effort [04:54] props for having weird kit then [04:54] * antarus got rid of all his ;p [04:55] micahg: Yeah, we're putting a tiny bit of effort into it as we speak. Literally as we speak. [04:55] micahg: 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:56] infinity: I'm sure you're doing what you can to revive it [04:57] micahg: 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. :P [04:57] xnox: have you managed to get a 10.04 server updated yet? [04:57] (There may have been a few other experimenters, but not "users", per se... Like, Carlos had Ubuntu chroots, but runs Debian, etc) [04:58] infinity: makes sense, I suppose you could count how many time the hppa Packages file is read on the ports server [04:58] yeah Gentoo has the same sort of deal with the weird arches [04:58] 1 guy maintains them, about 3 people care [04:58] they are always behind at building / stablizing stuff [04:59] antarus: 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. [05:00] hay, 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] haha hahaha they have 'criteria' [05:01] antarus: 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:07] antarus: http://release.debian.org/wheezy/arch_policy.html [05:08] infinity: naw, it was designed as a way to drop m68k /and arm/ ;) [05:08] slangasek: And then ARM went and became relevant. Jerks. [05:08] so see, you have the Debian cabal to thank for ARM getting their act together [05:08] slangasek: In fact, I suspect that the "only 2 buildds" thing is still not true for ARM. [05:08] if we hadn't demanded faster buildds, nothing would have happened! [05:08] And, IIRC, when Debian dropped hppa, it was the last major distro to support it. [05:08] slangasek: Though it may be some day. [05:09] infinity: hmm, I think Debian relaxed the "only 2 buildds" requirement though? [05:09] phillw: I don't see your point. /current is still always what you want. If /current gets updated, then test that. [05:09] slangasek: It's still in the wheezy list. [05:09] hmm [05:09] well, ok [05:09] ScottK: hey hey hey, Gentoo still supports hppa ;) [05:09] antarus: I stand by my statement. [05:09] slangasek: I'm guessing it's just ignored if the rest of the bullet points get hit. [05:09] ;-) [05:10] infinity: I think generally, it's ignored if DSA don't have to spend large amounts of Quality Time babysitting a dogsled team of buildds [05:10] slangasek: Well, back when the proposal was first written, DSA didn't manage many buildds at all. [05:11] infinity: wasn't it required that the security buildds be DSA-managed? [05:11] slangasek: AFAIK, they're all ldaped now, though day-to-day is still handled by porters. [05:11] dunno, my memory is fuzzy [05:11] slangasek: Oh, yeah, kullervo was ldapped (though still managed by me, just had DSA access) [05:11] * antarus cringes at ldap [05:11] antarus: ud-ldap is only ldap in name, really. [05:12] antarus: More appropriate to call it libnss-db at the host level. [05:12] (Cause it is) [05:13] infinity: as for hppa moving to ports, ISTR there were some big pthreads problems that may have prompted this [05:13] infinity: thank god [05:13] nss_ldap is a sin [05:13] and should be burned [05:13] slangasek: Yeah, upstream parisc support in glibc was awful for a while. [05:14] slangasek: 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:15] antarus: 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 had [05:15] gentoo has so few :/ [05:16] antarus: 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] infinity: there are always trade-offs ;) [05:16] yeah I know how libnss-db works [05:16] we wrote our own thing of course [05:16] because thats what we do [05:16] I think everyone has. [05:17] Well, 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] yeah [05:17] we built nsscache [05:17] and then I gave it to Gentoo [05:17] so gentoo uses it [05:17] unsure if anyone else did [05:18] just like everyone manages their own bind zonefile mess [05:18] * antarus cringes [05:19] I 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] Not that the format is hard to write a quick read/write parser for, if you introduce artificial constraints. [05:20] The Gentoo zones are maintained in git, and there is magic to build them and DNSSEC sign them [05:20] magic perl that I do not understand [05:20] if the author gets hit by a truck; I will have a bad time :/ [05:20] Heh. [05:20] Turns out that there are a lot fewer programmer-seeking trucks out there than we generally fear. [05:22] fear/hope in some cases. [05:22] *cough* [05:24] hey now [05:39] infinity: fortunately, there aren't a lot of Agent Smiths' driving around :) [05:42] * infinity takes micahg's apostrophe and crushes it under his heel. === tkamppeter_ is now known as tkamppeter [07:16] infinity, have you seen my messages about GS 9.07? [07:25] tkamppeter: If it's AGPLv3 (or if the license reads "vN or later"), then it should be fine. [07:26] tkamppeter: 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:27] tkamppeter: Which would make it a bit difficult to, say, distribute gimp. [07:40] infinity, this is OK, GS is AGPL v3+ [07:42] tkamppeter: Kay, then just make sure debian/copyright gets a treatment to still be correct, and it should be fine. [07:42] infinity, OK, thanks, waiting for RAOF to fix the bug ... [07:58] infinity, another question, foomatic-db and foomatic-db-engine are still in raring-proposed, what moves them into raring? [08:12] tkamppeter: They're in the frozen list for beta-1, they'll migrate after Thursday. [08:12] tkamppeter: See http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html === agateau_ is now known as agateau [10:27] cjwatson: hey, do you know if the LP API enable us to retrieve a source package from a ppa (like downloading it)? [10:27] sourceFileUrls maybe… [10:32] didrocks: Yes, we do something for mythbuntu https://github.com/MythTV/packaging/blob/master/deb/debian/LP-get-orig-source.py [10:32] Daviey: oh excellent, thanks for the link! [10:32] yeah, so once I get my getPublishedSources(), just calling sourceFilesUrls and urlretrive it [10:33] urlretreive* [10:34] didrocks: people seem to be moving away from urllib in favour of python-requets [10:35] Daviey: interesting… never looked at that one. Will definitively give it a look, thanks! [10:35] As you can't do *.changes signature validation, you probably should do https validation [10:36] (which requests does better than urllib) [10:41] by doing it at all... [10:48] tumbleweed: can we have pull-ppa-source please? [10:48] =) [10:49] * Laney hands emacs ubuntu-dev-tools/pull-ppa-source to xnox [10:50] phillw: 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] He's offline [10:54] * xnox needs to brew coffee. === mmrazik is now known as mmrazik|lunch [11:02] stgraber: I've screwed up cdimage fairly massively, apparently - bug 1153992, currently trying to figure out full impact [11:02] Launchpad 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/1153992 [11:30] anyone know why kubuntu-settings isn't getting into -released ? I can't work out what update_output.txt is saying about it [11:31] update_excuses.html says "kubuntu-settings-desktop/i386 unsatisfiable Depends: kubuntu-qtquick1-components" which is probably a more immediately useful hinit [11:32] No such package AFAICS [11:57] please wait for matching tcltk-defaults. [12:00] Hi folks, has AMD64+Mac been dropped from the ISO's? [12:06] phillw: No change there [12:07] * cjwatson fixes bug 1153992 and tries to work out what to respin [12:07] Launchpad 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/1153992 === popey_ is now known as popey [12:08] * cjwatson sticks a notice on the iso.qa board [12:39] Raring respins as follows: Lubuntu Alternate *, Ubuntu Server * (I think the latter isn't taking part in the beta though) [12:40] Precise respins as follows: Kubuntu Alternate *, Ubuntu Alternate amd64+mac amd64 i386, Ubuntu Server *, Xubuntu Alternate * [12:41] All marked on the tracker. [12:43] JackYu: 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. === mmrazik|lunch is now known as mmrazik [12:53] cjwatson: 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:54] Aside from grammar, yes :) [12:55] (Though I've only checked that entry, not the rest of the page) [12:57] cjwatson: thank you grammar nazi :P It now is structured correctly [12:59] Hey, you asked [12:59] no worries, I usually have a guy in Brazil do my grammar checking ;) [13:03] infinity: 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 way [13:05] lamont: *nod* [13:05] lamont: 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:30] cjwatson: good thing we don't have that many non-live products then. [13:34] Indeed [13:40] cjwatson: thanks, we are dong it:) [14:01] please denew tcl8.5 together with tcltk-defaults, and if autohinter fails -> hint them together. This is a package split for multiarchification [14:01] infinity: ^ [14:01] * xnox hopes i got all the symlinks rights [14:03] xnox: If the autohinter fails, it's almost certainly because the packages are broken. [14:04] * infinity notes that 99% of the time people ask for a hint, they're really asking me to debug their packaging. [14:05] infinity: 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] xnox: If you're missing replaces, please fix. britney doesn't look at package *contents*, it won't catch that. [14:06] infinity: yeah, will test once above is published =) easier that way ;-) [14:06] xnox: If the lib package only contains things in a multi-arch path where they never existed previously, you're fine. [14:07] true. [14:07] i like that =) [14:07] Yeah, that looks fine to me. [14:08] (Just downloaded the deb to look) [14:08] infinity: note that tk was not multiarched yet, so at some point in the future there will be tk & tcltk-defaults combo ;-) [14:08] xnox: Plus, you get to do this in 8.6 as well (and push to Debian). [14:09] hi guys. what's the procedure for reviewing new packages in the archive? :) [14:09] phhhh enough of tikle for me for the day. [14:09] Heh. [14:09] one of our package is in the new queue for a week now. it kinda feels bothersome. [14:10] jokerdino: Which one? [14:10] jokerdino: what's the package name? [14:10] snap [14:10] unity-tweak-tool [14:10] ^^ [14:11] jokerdino: 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:12] e.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.com [14:12] xnox: uhm, myunity was in universe though no? [14:13] keyword "was" [14:13] well, we have done better work than that. [14:13] it kind of also implies that we potentially don't want it in the archive. [14:13] xnox: IIRC that was actually removed because it wasn't ported to a newer gambas [14:13] jokerdino: 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:14] but yes, we want packages in the archive to be actively maintained. and packages like this seem to need more maintainance than most [14:14] xnox: 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] we can maintain. i promise. [14:15] jokerdino: 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] infinity: it's been passed onto the desktop team? [14:15] s/bystandard/bystander/ [14:15] jokerdino: I was referring to mterry's reviews in the bug. [14:16] oh, that. [14:16] I'm curious about the native packaging without a strong version->commit mapping, but whatever. Not my package. [14:17] And, hypocritically, I maintain a similar package with random upstream commits pulled into it. [14:17] infinity: heh, we are using git tags for version -> commit mapping. [14:18] jokerdino: 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:19] infinity: hm, the one uploaded is 0.0.3 with all the fixes incorporated. [14:19] jokerdino: Right, but the earlier ones were also 0.0.3 [14:19] jokerdino: Which seems to contradict the claim that tags match versions. :) [14:19] yeah, we were a bit too flexible. [14:19] jokerdino: Unless you deleted the tag. [14:20] Uh oh [14:20] jokerdino: (Which is generally a Bad Idea in git) [14:20] no, the tag was only added after it was uploaded ;_) [14:20] All the respins seem to be done now. I only hand-checked Lubuntu. [14:20] jokerdino: Ahh. Kay. That's fair. [14:20] Though server amd64 looks fine too. [14:21] infinity: yeah, we are stingy about tags though. [14:21] jokerdino: 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:22] i can fix it on a daily basis as long as i get sponsors :) [14:23] and thanks for reviewing! [14:23] jokerdino: 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:24] hm, so we are talking about fixing in a developer sense? [14:24] that wont be an issue. we got a small team of devs across the time zone :) [14:25] jokerdino: 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. === ogra_` is now known as ogra_ [14:26] ogra_: Aww, you dropped a pointless character from your nick. [14:26] ogra_: Does this mean that in another six months, you might actually be "ogra" again? [14:26] yeah, no idea how that got there [14:27] infinity: heh, it's not as evil as you think. it passed at least three MOTU reviews for good. [14:27] i'm to lazy to convince nickserv to play with bip, else i would already [14:27] ogra_: Ditch bip and use irssi as a proxy. [14:28] ogra_: Then you have all of irssi's script-fu at your fingertips. [14:28] well, i'm happy with bip ... [14:28] and do drop by ask ubuntu as and when you have time. :) [14:28] its just the reconnects that make me grow a tail ... [14:28] i doubt irssi would cope much better with that [14:29] you can script it to cope with it [14:29] if the former ogra is still registered nickserv simply refuses to let me have that nick [14:29]