[00:15] I had a bzr upgrade of a branch on Launchpad go bad on me ... what should I do? [00:35] bdmurray, you can delete the bzr.backup dir via sftp iirc [00:35] actually [00:35] don't delete it [00:35] you actually want to delete .bzr [00:35] and rename bzr.backup :) [00:35] bzr.backup -> .bzr [00:35] to restore the branch [00:36] so actually, it didn't go bad but the bzr upgrade process timedout [00:36] bdmurray, what's the link to the branch? [00:37] lp:~brian-murray/update-manager/brian [00:38] * beuno checks the branch [00:39] bdmurray, I'd delete .bzr, and rename bzr.backup -> .bzr [00:39] and do the upgrade again [00:40] beuno: okay, thanks I'll give that a shot [00:40] beuno@beuno-laptop:~$ bzr info sftp://bazaar.launchpad.net/~brian-murray/update-manager/brian [00:40] Standalone branch (format: unnamed) [00:40] unnamed isn't a very good format to have [00:43] Yeah, fully upgraded branch shouldn't ever say "unnamed" over SFTP. (bzr+ssh unfortunately reports formats as 'unnamed', and also it's possible to have combinations like an old branch format in a current repo format which would also be reported as 'unnamed') [00:49] So, just to be clear I want to sftp to bazaar.launchpad.net? [00:49] bdmurray, yeap, and go to your branch [00:49] you may want to use lftp [00:50] I hear it's nicer [00:50] I'm familiar with sftp but with ls nothing is returned [00:50] Couldn't stat remote file: No such file or directory [00:52] yeah, it's weird that way [00:52] mwhudson, what was the procedure in these cases? [00:52] i guess probably the easiest thing to do is for me to fix it on the server [00:53] bdmurray: you' [00:53] probably, but we should really find a way for people to solve this on their own. Failed upgrades happen with certain frequency [00:53] I wonder if we should have a "restore backup" button on the UI [00:54] we should certainly have an 'upgrade' button on the ui [00:54] that too :) [00:55] would save billion of gigwats of bw [00:55] is there a bug filed for that? [00:55] bdmurray: in the next release (on thursday) you'll be able to use a regular sftp client much more easily [00:57] bdmurray: looks like the branch is in fact mostly updated [00:57] bdmurray: what are you after, just an upgrade to packs? [00:58] mwhudson: right, just a standard upgrade [01:00] beuno: that's a good question [01:01] beuno: bug 254135 [01:01] Launchpad bug 254135 in launchpad-bazaar "Add UI to upgrade a hosted bzr branch" [Medium,Triaged] https://launchpad.net/bugs/254135 [01:02] bdmurray: done [01:02] jml, thanks! I'll add a "me too" to that [01:05] mwhudson: great, thanks! === kiko is now known as kiko-zzz === abentley1 is now known as abentley [02:18] man.. I used to hate BZR, now I love it [02:19] * beuno hugs bzr [02:19] Yes :D [02:40] how do I get OpenID with my launchpad account [03:16] elmo, thank you. [03:16] coppro, you need to be part of the beta team [03:16] although, I think, it's going to be release soon-ish to everyone [03:17] you can request to join the beta team if you'd like: https://launchpad.net/~bzr-beta-ppa [03:17] uhm, wrong url [03:18] https://launchpad.net/~launchpad-beta-testers [03:18] that's the one === persia_ is now known as persia [04:30] Is there a way to reupload something to my PPA? I am getting rejected emails saying "MD5 sum of uploaded file does not match existing file in archive" [04:35] tgm4883_laptop: Don't modify orig.tar.gz, and don't use -sa unless you bump the upstream version. [04:37] persia, hmm, I didn't think I was modifying the orig.tar.gz. I am using -sa, but I did think I was bumping the upstream version (I went from 6~svn145-0ubuntu1 to 6~svn170-0ubuntu1) [04:38] tgm4883_laptop: That should be an upstream version bump. In that case, I have no idea. Sorry. [04:39] my only thought is that it somehow conflicts with the other upload that i'm doing [04:39] which is [04:39] which is the same package, but one for hardy and one for intrepid. the hardy one has ~hardy at the end of the version [04:39] hey, I don't think any admin is around but when one will can he please cancel all the vcs-imports for: https://code.launchpad.net/ltsp-cluster [04:40] as we need to clear our code, I prefer to do the cleaning in SVN, the use bzr-svn and push to LP myself [04:40] it's strange, as it seems whichever release version gets there first is ok, but the other one fails [05:22] tgm4883_laptop: do the hardy and intrepid uploads have identical orig.tar.gz files? [05:22] jamesh, yes [05:22] for this sort of case, you should have a single orig.tar.gz and different diff.gz files [05:23] ok, I have a development dir for hardy stuff and one for intrepid. Should I then not do get-orig-source stuff for the hardy stuff? [05:23] tgm4883_laptop: the error you got suggests that they aren't identical. Are you sure their MD5 sums match? [05:24] jamesh, it might be slightly different, as the time is different when I do the svn pull for g-o-s, but it pulls the same svn revision [05:24] tgm4883_laptop: that is your problem. [05:25] ok, should I just use the same orig.tar.gz then from the intrepid build? [05:25] yes. [05:25] ok [05:25] one more question then [05:25] actually, nm, I think it's the same issue [05:25] i'll do that and report back, thanks [05:26] tgm4883_laptop: the files for all the distro releases are served from a single directory, so if files have the same name they need to be identical [05:27] jamesh, ok, then is there a way to re-upload the package to ppa? [05:27] cause it says it's already uploaded [05:27] tgm4883_laptop: removing the .upload file will probably do the trick [05:27] tgm4883_laptop: but you probably need to regenerate the .dsc and .changes files [05:28] since they contain checksums for the .orig.tar.gz [05:28] will do [05:28] thanks [05:40] tgm4883_laptop: If you've an automated construction of your orig.tar.gz, you may want to consider gzip -9nf to reduce the chances of md5sum skew for unmodified contents. [05:49] I wonder if "bzr export" does repeatable tarballs? [05:49] jamesh: i don't think it does, iirc there's a bug report about that somewhere [05:50] it could grab file timestamps from the "last changed revision" in the inventory [05:52] jamesh: mwhudson: No. For two reasons: firstly, the timestamps, and secondly that most people just tar & gzip without the right arguments to not include md5sum adjustments as part of the tar & gzip process. [05:52] Also note that it breaks some VCS workflows if you preserve repo timestamps. Consider the case of `bzr revert foo; make` [05:52] persia: "bzr export" can generate a .tar.gz from a bzr revision [05:53] persia: and it should be possible to make the output only depend on the input revision [05:53] rather than the time you ran the command or any other changes [05:53] jamesh: I'm absolutely certain that it does so in a manner that doesn't call the special hooks in tar and gzip to not track either the original (temporary) tarfile name, nor the timestamp thereof. Further, I suspect it doesn't force compression of everything (when it does not preseve space), so one gets different sets of compression in different environments. [05:54] * mwhudson__ applied the windows solution [05:54] jamesh: Right, but for the "create tar.gz" case, I want the timestamp at which the file was last committed, and for the working directory case, I want the timestamp when the file was last modified for any reason. [05:54] persia: it uses the Python tarfile module to create the tarball [05:54] so on-disk timestamps don't come into the equation for that part of the process [05:55] jamesh: OK. Then it's certainly broken, since that's known to not preserve md5sums. [05:55] how so? === mwhudson__ is now known as mwhudson [05:56] The way the compression is done by that module will generate a different md5sum for each creation, because the time the tarfile is created ends up being in the tarfile. [05:56] Note that there are plenty of use cases where this is a good thing, just not for md5sum preservation for Debian-format packaging. [05:57] I suspect there is a way to hint it, but haven't dug through that code to determine the right set of hints. [05:57] hmm. Looks like it writes the current timestamp into the gzip header [06:00] jamesh: Precisely :) [06:01] For command-line gzip, calling with -9nf both skips the current timestamp inclusion, forces compression of everything, avoiding possible platform-based variance. [06:06] persia: I agree that "bzr export" as it is now won't produce repeatable archives, but that doesn't mean that it couldn't. [06:07] jamesh: True. I'm just not sure if it should. [06:07] persia: the problems seem to be (1) the gzip header, and (2) the tarfile entries it creates use current time (with a TODO comment indicating that it'd be good to do otherwise ...) [06:07] jamesh: Essentially, while it makes life significantly easier for those using bzr export to generate orig.tar.gz files for Debian-format packaging, I'm not convinced it doesn't break some other workflow. [06:08] jamesh: Yep. Those are the two places where one needs to adjust things to get repeatable md5sums. [06:17] I'm still not quite sure why this would cause problems elsewhere. [06:33] jamesh: Sorry. Distracted. [06:33] Imagine the case where one wants to know *when* the orig.tar.gz was constructed. For example, one is upstream, and one has this tarball, and one wonders if it's accurate. [06:34] Well, that's probably more useful for foo.tar.gz (no *orig*), but still. [06:34] persia: if the idea is to produce an accurate representation of a revision, why does it matter when it was created? [06:34] if you know that the command to generate it produces repeatable, accurate results [06:35] jamesh: Hrm. Perhaps not. Is there any possibility that you and I could have different branches with the same revision number and generate two tarballs that appear to be the same revision? [06:35] persia: revision numbers are not globally unique, so that is a distinct possibility [06:35] but timestamps will be the least of your worries in that case. [06:35] Yeah :) [06:36] I'm just trying to think of various ways that having it generate something suitable for orig.tar.gz might break the case for tar.gz. [06:36] Mind you, I'm an avid user of orig.tar.gz, and am not upstream for anything, so perhaps I'm not the ideal person to identify possible regressions. [06:42] is this an ok place to ask about the launchpad api? [06:49] maco: There isn't a better one :) [06:50] persia: ok [06:51] if i do bug_filter.add_option("bugnumber", int(bug.strip())) why does it give a ValueError on that line? i thought it was because i was using a string and it says bugnumber will be an int, but trying it as an int also gives the error [06:52] er, hrm maybe that doesn't make sense [06:52] um, i'm using the python-launchpad-bugs package and trying to query launchpad through the api [06:52] persia, jamesh using the same orig.tar.gz fixed it. Thanks again [07:28] is there a field.something to search for bug numbers? [07:28] it turns out the python bug search package for launchpad doesn't have that as a search option, so i'm wondering if there's a way to add that field as a search parameter [07:30] maco: no, there isn't. [07:30] hello BjornT [07:30] hi jml [07:37] BjornT: i found how to get a bug by number on one of the other wiki pages [08:01] hi, what's the best place to report API bugs, is there a subproject or are you using tags? [08:18] thekorn: https://bugs.launchpad.net/launchpadlib might be appropriate [08:20] jamesh, ok, but what's the best target for bugs I can also reproduce with 'raw' http request, without using launchpadlib [08:21] thekorn: dunno. But filing bugs against launchpadlib will probably get the attention of the right people [08:21] I guess it depends on what the bug is exactly. [08:21] jamesh, ok, thanks, will file it there [08:24] well, I get an 503 error for any operation on huge objects, like requesting https://api.staging.launchpad.net/beta/bugs/1/messages [08:24] Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,In progress] === warp10_ is now known as warp10 === geser_ is now known as geser [09:35] Hi everyone! [09:36] I don't understand why I was rejected in my PPA: "PPA uploads must be for the RELEASE pocket" trying to upload to it my iptables backport for hardy [09:36] I have "Distribution: hardy-backports" [09:36] didrocks: "hardy-backports" is not a RELEASE pocket. You need "hardy". [09:37] should be just "hardy" [09:37] you can only have "hardy", ie: no -backports [09:37] (And yes, this means that the result is wholly unsuitable for later upload to hardy-backports, but that's a different issue) [09:37] we're thinking about adding pocket support back to PPAs, FWIW [09:38] ok, so, for testing I can just put hardy. But when I have to change it for real backporting, I have to change it to ...-backports [09:38] oki bigjools :) [09:39] thx to everyone [09:40] bigjools: So that one has separate PPAs for e.g. hardy vs. hardy-backports? And one can have an e.g. hardy-proposed PPA? [09:40] persia: pretty much. But we're still at the "thinking about it" stage so don't get your hopes up too much :) [09:41] bigjools: Aside from the use case of package review through PPAs (which is missing too many bits to be very useful), for what would this be used? [09:41] * wgrant is more hoping that multiple PPAs and/or flexible components reappear. [09:41] Pockets aren't so useful. [09:42] it uncomplicates a lot of specialised processing for us internally in addition to what you said (which is high on our prioritry list BTW) [09:42] multiple PPAs are also on our list [09:42] I guess P3As have to special-case that for the security PPA among others? [09:43] cough, yes :) [09:43] s/PPA/P3A/ [09:47] bigjools: Creating a review process is high on your priority list? Are there specs available? This has been widely discussed, and there is a known set of 25 or so requirements that might be a good input. [09:48] persia: no specs yet, but I would be very pleased to get your input [09:48] bigjools: How about a session at UDS? [09:49] might be a bit late by then, although it could be discussed. I am not going but Celso and Muharem will be there [09:49] I know several other people would also have input, and announcing that might be a good way to get people to bring their thoughts to the room. [09:49] bigjools: Surely you'll be attending remotely, no? [09:50] we're thinking explicitly about package sync reviews right now, but adding PPAs into the mix is also good [09:50] persia: the time difference would make it hard but if there's a specific session that's of interest I would listen in [09:50] Actually, the case for syncs and updates is far more interesting to me. Whether PPAs are part of it is an implementation detail. [09:51] bigjools: Unless you're limited somehow, I'll recommend adjusting your sleep schedule for the week. I've generally found it advantageous to attend remotely when I couldn't be there in person. [09:51] persia: try telling my kids to adjust their sleep schedule :) [09:52] Perhaps we could try to schedule for the early morning / late evening to better match your needs? [09:52] bigjools: Well, that's harder :) [09:52] persia: yeah, if it's early in the day in CA then it's easier for me [09:55] bigjools: In that case, I'd recommend asking for whoever is coordinating LP-oriented sessions to have it earliest. I'm not sure what the tracks will be this time, but having it in a MOTU-type track will probably expose the majority of the blind reviewers (who need the UI support more) [09:55] btw I don't think PPAs are an implementation detail, they are an additional part of the interaction to think about. You could consider them as little upload queues for Ubuntu (which is what is happening for security) [09:56] I think that is an interesting idea for a workflow change. [09:57] persia: ok, thanks, I'll try and fix that. BTW if you could let me have any input you have on this topic ahead of time it would be very useful. [09:57] bigjools: While it might make the use case for -security better, having been involved in two flavours working out of PPAs and trying to get into the main archive, I'll say it's *extremely* poor for an upload queue. [09:58] persia: is that because the tools were bad though? [09:58] bigjools: Sure. I'm not sure how much time I'll have beforehand, but I'll send you some stuff if I get it together. [09:58] awesome, thanks [09:58] bigjools: The large issue is that a PPA allows interdependencies between packages that don't match the archives, which can complicate things. [09:59] true [09:59] The medium issue is that a PPA encourages multiple revisions to address issues, and often the changelog needs to be elided when merging to the primary repositories. [09:59] The small issue is that the PPA UI breaks at about 60 packages. [10:00] The small issue is fairly easy to fix with some thought. [10:01] The medium issue could maybe be addressed, if it is decided that PPAs are for review, rather than user distribution, but that breaks many current PPA use cases. [10:01] pocket support could help the former maybe? [10:01] The large issue is just difficult. [10:01] Which is "the former"? [10:01] "medium issue" [10:02] what is the problem with the UI at 60 packages? [10:02] persia: why should changelog entries be elided/removed? [10:02] It's not batched, so if there are > 60 packages, one cannot operate on the alphabetically large packages without specifically searching for them by name. [10:03] most package changelogs mention shitloads of releases that have never been in Ubuntu archives [10:03] due to Debian heritage [10:03] why should PPAs be different? [10:03] jamesh: Because 1) we don't want to jump from -3ubuntu1 to -3ubuntu18 unless we need, and 2) because often changes get tested and reverted, and it's just embarassing noise. [10:03] * wgrant wishes that debian/changelog would crawl away into a corner and die. [10:03] heh [10:03] * persia likes debian/changelog [10:04] It's being obsoleted by real VCSes. [10:04] persia: so get people to use version numbers that fit between -3ubuntu1 and -3ubuntu2 for their testing packages? [10:05] this seems disconnected to maintaining the change history [10:06] jamesh: Yes, but that then means that one needs to perform special operations before pocket-copying, which takes us back to PPAs not having packages suitable for direct upload to Ubuntu (see the initiating discussion about use of hardy-backports) [10:07] persia: I guess I see the problem as a social one rather than a technical one [10:07] [not that my opinion matters much in this case] [10:07] wgrant: Well, I guess. If everything was in a real VCS, and the infrastructure was in place, and it worked, I could probably live with autogenerated debian/changelog, but I like to read it as a user. [10:08] persia: you mean, you like to read it as a developer [10:08] jamesh: Well, maybe social, or maybe policy, but it's essentially that if we wish to use PPAs as a upload queue with pocket-copying into the primary archive, we either give up on the conventions for revision numbering, or we allow them to be clobbered in PPAs, and give up on using PPAs for end-user distribution [10:09] mok0: No. I mean I like to read it as a user. I was reading debian/changelog for each package update *long* before I was a developer. [10:09] persia: Not many users care about changelog, though... [10:10] persia: so, if you weren't using a PPA there would be rules that say "if you don't do X, your package will be rejected" [10:10] persia: If you want to know about new features in a package, it wont help you [10:10] persia: if we have -proposed in PPAs O don't think that's a problem [10:10] mok0: Well, it depends. I venture to say that many users do, and those that do are often proxy for larger groups of users (administrators of larger deployments, etc.) [10:10] s/O/I/ [10:10] why can't you use those same rules when deciding whether to copy a PPA package to the main distribution? [10:10] mok0: Why won't it help me? [10:10] jamesh: precisely. [10:11] persia: because those new features are not described there [10:11] (usually) [10:11] bigjools: Huh? I'm not sure I understand how the presence or absence of -proposed affects the revision nomenclature issue. [10:11] you'll have some PPAs that contain crap that will never be appropriate to copy, and some that are great [10:11] mok0: Typically either they are described there, or there is a mention of a new upstream release, and I can read /usr/share/docs/$(package)/changelog.gz [10:12] the presence of crap doesn't really matter though, provided it is contained in its own unsupported PPA [10:12] (and yes, this means that every day when I upgrade Ubuntu I need to go to extra effort downloading sources now, but I consider that a bug) [10:12] persia: Right, upstream changelog is where you look for features [10:12] persia: I'm talking about the clash between "end-user distribution" and "revision numbering" [10:12] jamesh: right [10:12] mok0: Depends on the feature. Not always, and *extremely* rarely for stable instalaltions. [10:12] bigjools: you are right, release info does not logically belong in changelog [10:13] bigjools: Ah, so the -proposed PPA might not enforce revision numbering rules, and the $(RELEASE) PPA would enforce them? That sounds like a workable solution. [10:13] bigjools: it's not logical to put build information in the changelog [10:13] bigjools: and it wouldn't appear in a VCS either [10:14] persia: how does this process work right now in Ubuntu? can we better it? [10:14] bigjools: Which process? Package review? [10:15] persia: testing and versions etc. [10:15] bigjools: Are you still about in ~30 minutes? I'm trying to multitask just now, and while I'd be very happy to explain, I'll do better then. [10:16] (unless someone else wants to explain it) [10:16] persia: yeah no problem [10:16] bigjools: Thanks :) [10:16] I know what it's like :) [10:51] bigjools: Sorry about that. [10:51] So, for reference, bug #179857 was filed a while back, because the way it's done is very awkward, but I'll try to explain. [10:51] Launchpad bug 179857 in malone "Package sponsorships involve awkward bugtracker machinations" [Undecided,New] https://launchpad.net/bugs/179857 [10:52] There are essentially 7 different sorts of workflows, which fall into a few categories. [10:52] There's NEW packages, which go through REVU, get approved by two developers, and get uploaded into the NEW queue. [10:53] For NEW packages, a bug is filed against "Ubuntu". It gets assigned to someone, and that person pushes the package through REVU. [10:53] When the package is accepted, as bug isn't against a package (the package didn't exist at the time the bug was opened), the bug doesn't get closed, although the changelog specifies the bug closure. [10:54] The packager than manually closes the bug. [10:54] Whilst the package is on REVU, it goes through several iterations, fixing various issues pointed out by the reviewers. [10:55] Often these changes include changes to the upstream version numbering scheme, the revision numbering scheme, whole and entire replacement of various sections of the package, sweeping changes to orig.tar.gz, inadvertant switching between native packaging and non-native packaging, etc. [10:55] As such, it's fairly safe to say that the first revision uploaded to REVU is likely not something that if distributed to end-users would upgrade safely. [10:56] Sometimes people put one or more REVU revisions also in a PPA, but those are typically deleted, as they are often not the final version, and subsequent changes break the current PPA model. [10:57] There's updating packages with some new upstream code. [10:57] (and perhaps I can't count: I'm suddenly unsure from where I got seven). [10:57] :) [10:57] Wow [10:58] For these, the updater pulls in the new code from upstream, and merges with the existing debian packaging. The diff.gz file is then attached to a bug, and either ubuntu-main-sponsors or ubuntu-universe-sponsors subscribed. [10:59] Each of these sponsoring groups has a slightly different internal workflow, but generally it involves pulling the orig.tar.gz from somewhere (to avoid sneaky people from submitting a subverted orig.tar.gz), reconstructing the package, and testing. Comments are done in the bug, and new diff.gz files uploaded. Eventually some candidate is deemed sufficiently good, and the developer uploads the reconstructed pacakge, closing the bug from the chang [10:59] elog. [11:00] There's processing merges with Debian (or some other external apt-source from which we sync or merge) [11:01] For these, the merger will prepare a candidate package, create a debdiff against the merge source, and submit this in a bug to one of the sponsoring queues. [11:01] The sponsor will pull from the source directly, apply the debdiff, and investigate the resulting package. As with updates, discussion happens in a bug, and new revisions are prepared. === siretart_ is now known as siretart [11:02] There's syncs: generally the sync requestor only files a bug for these, and the sponsor is expected to download the current and candidate sources, compare and review, and determine if the sync is appropriate. Discussion in sync requests in minimized, as these will be presented to the archive-admins, who prefer short bugs. [11:03] (having a button to allow anyone who can upload to a given pocket be able to sync to that pocket would be a huge win here) [11:03] that's the plan [11:04] s/pocket/component or package set/ [11:04] There's bugfix updates, in which the bug fixer will prepare a candidate debdiff fixing a specific bug (often just wrapping a patch from upstream, from another distro, or from a user), and attach that the the bug that would be fixed. This bug gets pushed to one of the sponsor queues for review, and discussion within the bug. [11:05] There's also multiple-bugfix updates, in which someone will prepare a debdiff fixing several bugs, attach it to a new bug, reference the new bug in the old bugs, and subscribe the new bug to the sponsors queue for review and discussion. [11:06] And I'm sure I've lost count, because those 6 are the only ones that come to mind. There are alternate workflows in place, but not official. [11:06] ok that's great info, thanks very much [11:06] These include both people putting a candidate package somewhere a developer can pull it with dget, and people submitting bzr branches. Some developers will accept those, but one's chances for packages not maintained by some specific person are low in either case. [11:07] For the universe sponsors queue, there's also a bit of a bug status dance, as described at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue [11:08] So it gets put as "In-Progress" while the candidate is being prepared, and back to "Confirmed" when submitting for review. There's no published process for the Main sponsors queue, but many preparing candidate revisions will apply the same guidelines used for Universe to Main. [11:08] Info dump complete. Now accepting questions. [11:09] And yes, "component" is better. Sorry for the misuse of the term. [11:10] Is there a bug number for uploader-has-access-to-sync-button? I'd like to subscribe. [11:10] I need time to digest that [11:11] Understood. I'm about a fair amount. At least wgrant and siretart have been involved in various previous discussions, and may also be able to answer questions. [11:11] let me find the spec [11:13] persia: I didn't read the beginning of the discussion, what are you currently discussing? [11:13] (was changing servers) [11:15] siretart: Overview of the six different sorts of workflows (or 11 if you distinguish universe from main) used to accept updates from those without direct upload permission, and mention of the two alternate workflows (one deprecated, one experimental). Alll in reference to bug #179857 [11:15] Launchpad bug 179857 in malone "Package sponsorships involve awkward bugtracker machinations" [Undecided,New] https://launchpad.net/bugs/179857 [11:16] siretart: http://pastebin.ubuntu.com/47393/ has a transcript of my summary, if that's any help. [11:17] persia: ah, I see. thanks [11:18] persia: you're already subscribed to the spec for this [11:18] siretart: I mostly mentioned you because you're often in this channel, and I know you attended the session in Boston about that. [11:18] persia: feel free to hilight me even more often :) [11:18] https://blueprints.edge.launchpad.net/soyuz/+spec/sync-workflows [11:18] bigjools: heh. I guess it just doesn't get a lot of traffic then :) [11:18] it's new :)( [11:19] I am going to paste your comments above into it if that's ok? [11:20] bigjools: The majority of what I've just said isn't that relevant to that spec, but you're welcome to put it there if you've nowhere else to capture it. [11:20] umm right, brain fart [11:20] bigjools: Also, any chance that a copy of that spec could go to wiki.ubuntu.com? I suspect most of the subscribers can't currently read it. [11:21] I will check on that and get back to you [11:21] perhaps the spec should be moved to wiki.ubuntu.com, since it seems to involve discussing this with MOTUs [11:21] not only copied [11:22] That would be nifty, if it doesn't break some internal mapping of specs on the launchpad wiki. [11:23] the problem is that they tend to discuss code changes, and until the day LP is OSS that's a bit sensitive :) [11:23] FWIW, I think that 'distributed-development' and 'native-source-syncs' will change the situation quite a bit. [11:24] bigjools: well, perhaps you can split the spec in two parts: the workflow discussion and the implementation details? people won't be interested that much in the latter anyways.. [11:25] yeah, I will bring this up in our meetings [11:25] native-source-syncs would be a prereq for sync-workflows, wouldn't it? [11:25] bigjools: Aha, this must be the first good reason that I've seen for keeping specs private. [11:26] I think we ought keep distributed-development separate from other things, where possible. While I'd like to see it sooner, I'm not sure it's a direct dependency of anything, and don't want to either delay it or other things because of a false dependency. [11:26] it's probably the only reason [11:26] bigjools: All I've heard previously is "No." [11:27] Actually, it's probably interesting for a lot of specs to be published more widely, if only the proposed workflow and use cases. Having closed implementation for closed-source makes sense. [11:27] (setting aside the open/closed source issue) [11:29] wgrant: re. n-s-s and s-w, yeah, the lines are blurred across those two anyway [11:29] One seems fairly useless without the other. [11:30] n-s-s is nearly complete anyway [11:30] This is good. [11:31] Is gina almost in a state to make n-s-s useful? [11:32] getting there! [11:33] * siretart still wonders if n-s-s will be able to sync packages that have not been imported into launchpad yet [11:33] BjornT: ping [11:33] no it won't [11:34] meh, so how are we supposed to sync packages from debian then? [11:35] because debian will be in LP :) [11:36] BjornT: i sent another test (https://bugs.staging.launchpad.net/gnumed/+bug/270704) which went through and it looks it is the same case as the one from yesterday - both were signed with mimegpg and that's why they are correct - the whole message is signed. however, this is the case we need: gpg-signing & forwarding automatic-reports. still having the bug fixed would be nice [11:36] Launchpad bug 270704 in ubuntu "[needs-packaging] powerdevil" [Wishlist,Confirmed] [11:37] * gour thinks it would be nice that bot could discern staging from 'real' bugs [11:39] bigjools: do you have any estimate or guess how big will be the delay between a DD (e.g. me) uploading a package to debian/experimental and the package becoming available in lp to sync? [11:40] bigjools: and do you intend to sync http://debian-multimedia.org or http://e-tobi.net (or whatelse not) as well? [11:40] actually, having an official list of sync/merge sources for oversight by the archive-admins would resolve a fair number of discussions. [11:41] Especially if one could identify the source of a given package, rather than always assuming it to be Debian [11:41] siretart: I can't say for certain on either question yet, but I can let you know [11:41] * wgrant tries to think of how those could be represented in the data model. [11:41] wgrant: Wouldn't you need Origin for each orig.tar.gz? [11:42] persia: I'm not seeing the relevance. [11:42] Err, no, that wouldn't work, because Origin: can change. [11:43] wgrant: Erm. Just thinking about things about which I have too little information :) I'll go be a user somewhere else for a bit, and look forward to someone knowledgeable having an idea :) [11:43] Deferring to bigjools sounds good, yes. [12:07] does PPA handle Debian packages? [12:08] gnomefreak: PPAs only build for Ubuntu distroseries. [12:08] wgrant: thanks thought so but had to ask [12:09] pulling from bazaar here in Singapore seems to be extremely slow, does launchpad have a local asian mirror? [12:10] sadly, no [12:10] * mwhudson is in new zealand [12:10] * wgrant also feels the pain in .au [12:10] Ziroday: is the branch in packs format? [12:11] packs >> knits for high latency links [12:11] mwhudson: not to sure [12:11] Ziroday: it should say on the branch page [12:11] hmm where is the closest server then? [12:12] mwhudson: yes its in knits [12:12] is there a way to see how many kB/s you're getting when pulling? [12:13] Ziroday: there are no mirrors of the launchpad branches [12:13] mwhudson: still very new to all of this https://launchpad.net/entertainer, not sure [12:14] thats the program I am trying to pull [12:14] oh heh [12:14] paul hummer == rockstar, another launchpad dev... [12:14] haha [12:15] Ziroday: this branch? https://code.edge.launchpad.net/~entertainer-releases/entertainer/trunk [12:15] it's actually packs [12:15] ("packs containing knits" is confusing, yes) [12:15] mwhudson: yeah that one [12:15] woops, sorry saw knits thought it was in knits [12:16] anyway, the way i usually try to follow progress is just with 'du -sh' in the branch dir :/ [12:16] I wonder if it would be more efficient to allow one to download a tarball of large branches. [12:17] mwhudson: thats a neat trick [12:17] The problem with a single large file is that it gets hit by the TCP ACK window issue. Having lots of small files in parallel can be faster for many environments. [12:18] how can you find out how large a branch is? [12:18] wgrant: not massively, i think [12:20] Ziroday: "bzr info -v URL" will tell you. [12:20] spiv: thanks [12:21] Or just in this case you could glance at http://bazaar.launchpad.net/~entertainer-releases/entertainer/trunk/.bzr/repository/packs/ and add up the file sizes ;) === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [14:25] Who is the right person to contact about vcs-import failures on Launchpad? [14:26] The Webkit vcs import has failed numerous times already: https://code.launchpad.net/~vcs-imports/webkit-open-source/trunk [14:26] upstream SVN is a beast, so the initial import takes ages. [14:26] however, I have a working branch at https://code.launchpad.net/~uws/webkit-open-source/webkit.trunk [14:27] the vcs-import maintainer may want to branch of my branch first, and have vcs-import update from there onwards (that works fine and doesn't take ages) [14:27] uws: mwhudson or abentley I think [14:27] mwhudson, abentley: ^ see my comments about webkit vcs mirror [14:27] uws: which tool did you use to make the import? [14:27] spiv: bzr-svn [14:27] took ages [14:28] updating it is doable though [14:28] at least with bzr-svn 0.4.12 which had a performance killer bug fixed [14:28] Yeah, recent bzr-svn releases have been getting much faster. [14:28] if you branch my webkit bzr mirror, you can happily bzr pull http://upstream-webkit-svn/.../trunk/ [14:29] uws: looks like it's due to a timeout. Stinky. [14:29] abentley: Yeah, I had the same issues, but I now have a fully up to date branch you might want to use for bootstrapping [14:29] I pasted the url above [14:30] uws: So you've effectively created an svn mirror? [14:31] abentley: Yes, using bzr-svn. Took days, had to restart it several times, but is fully up-to-date now [14:31] and pushed into lp already [14:31] I'm offering it to you so you can reuse it, and then have vcs-mirror update it [14:31] that would mean I wouldn't have to to that myself anymore ;) [14:31] uws: We can't use bazaar as a starting point, because we don't use bzr-svn. We use a different converter. [14:32] But what's this http://upstream-webkit-svn/.../trunk/ URL? [14:33] hold on [14:33] Oh, shorthand for the real upstream. [14:33] abentley: http://svn.webkit.org/repository/webkit/trunk [14:33] yeah [14:33] that's where I "bzr pull" from [14:34] So, we can't start from bzr-- we need to start from svn. If there were a subversion mirror, we could use that instead of the real upstream. I think. [14:34]