Re: Every single package failing
On 07/14/2013 04:25 PM, Logan Rosen wrote: > Every single package import appears to be failing: > > * with key > > lazr.restfulclient.errors.Unauthorized::main:_import_package:push_branches_back:set_official:lp_call:__call__:_request > > Any insight on this? > > http://package-import.ubuntu.com/status/ > This was due to the package importer losing the right to push to branches. This has been fixed. I'm not sure if someone needs to push a button to retry branch pushes for missed ones. Micah -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Switching over to Quantal
On 04/30/2012 04:45 PM, Max Bowsher wrote:
> On 30/04/12 18:44, Micah Gersten wrote:
>> On 04/30/2012 10:33 AM, Barry Warsaw wrote:
>>> Now that Quantal is open for development, what do we need to do to get
>>> things
>>> switched over, and UDD all happy-like?
>>>
>>> $ bzr branch ubuntu:precise/debootstrap precise
>>> bzr: ERROR: Revision
>>> {package-imp...@ubuntu.com-2021132053-gkdptiozkkmpd7p4} not present in
>>> "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)],
>>> []".
>>> $ bzr branch ubuntu:debootstrap precise
>>> Most recent Ubuntu version: 1.0.40
>>> Packaging branch version: 1.0.38
>>> Packaging branch status: OUT-OF-DATE
> I've filed https://bugs.launchpad.net/bzr/+bug/992245 for this.
>
>> This looks like an inherent bug. I don't believe bzr branch
>> ubuntu:$RELEASE/foo should ever look at backports. This might adversely
>> affect someone using this workflow to prepare SRUs.
> Er, backports? Where?
>
> Barry's second command is misleading because he's written
> "bzr branch ubuntu:debootstrap precise" when ubuntu: now
> denotes the quantal branch.
>
> Max.
Sorry, I was under the impression that the bzr branch failure was due to
the backports repo trying to stack on a non-existent branch. My
imagination might have been running astray.
Micah
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Switching over to Quantal
On 04/30/2012 10:33 AM, Barry Warsaw wrote:
> Now that Quantal is open for development, what do we need to do to get things
> switched over, and UDD all happy-like?
>
> $ bzr branch ubuntu:precise/debootstrap precise
> bzr: ERROR: Revision
> {package-imp...@ubuntu.com-2021132053-gkdptiozkkmpd7p4} not present in
> "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)],
> []".
> $ bzr branch ubuntu:debootstrap precise
> Most recent Ubuntu version: 1.0.40
> Packaging branch version: 1.0.38
> Packaging branch status: OUT-OF-DATE
>
> -Barry
>
>
This looks like an inherent bug. I don't believe bzr branch
ubuntu:$RELEASE/foo should ever look at backports. This might adversely
affect someone using this workflow to prepare SRUs.
Thanks,
Micah
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: UDD with new upstream version
On 04/14/2011 02:00 PM, Scott Kitterman wrote: > I decided to try UDD again for a new upstream version that was just released. > > I was following the documentation here: > > https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamVersion > > I got to this step: > > bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz > > and after considering this would require me to look up the exact download > address on sourceforge, decided to back up and do: > > apt-get source opendkim > cd opendkim-2.3.1 > uscan > > instead. > > I don't know if this is a documentation shortfall or it's really that much > more complicated, but documenting/updating so this works easily with watch > files would be a big win. > > Scott K Why can't you just run uscan on the bzr branch? Micah -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Import layout of Quilt v3 packages
On 02/08/2011 08:23 AM, Max Bowsher wrote: > On 08/02/11 13:52, James Westby wrote: >> On Tue, 08 Feb 2011 08:00:25 +, Max Bowsher wrote: >>> Therefore, what about checking in the patched code, without any quilt >>> metadata (.pc dir) but with a flag file that triggers bzr-builddeb to >>> write out the appropriate metadata whenever a working tree is built for >>> such a branch? >>> >>> (Writing out the metadata would consist of copying the series file to >>> .pc/applied-patches, and reverse-applying each patch in reverse order, >>> stashing the resultant modified file in .pc// for >>> each patch) >> This would work for checkout. What are the implications for merge etc? > On consideration, the implications for merge are not pleasant. > > You'd need to quilt pop -a, merge the upstream (despite now having local > modifications from popping), resolve conflicts, don't commit, quilt > push, resolving conflicts in pushing the patches, and finally commit. Yuck. > > So, now I've realized the above, I'd go so far as to suggest that there > is no reasonable branch format in between "patches as quilt series, > *not* applied" and "full loomification". > > I think we should go ahead and change the package importer _now_ to > revert to importing 3.0 (quilt) source packages with patches *not* > applied. When it does so, it should probably write a > "debian/source/local-options" file containing "unapply-patches". This > will give us import branches that are actually usable for UDD-style > development *now*, which I think we currently do not have for 3.0 > (quilt) packages. > > Once the problems surrounding ubiquitous looms have been solved, we can > think about switching the import format again, but at least we will then > have usable UDD between now and when we reach that point. > > Max. > I don't see quilt pop -a working without a .pc directory. Isn't the .pc directory part of the source upload in source format 3? Micah -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: UDD stakeholders meeting minutes 2011-01-26
On 01/27/2011 03:04 PM, John Arbash Meinel wrote: > On 1/27/2011 2:57 PM, Micah Gersten wrote: >> On 01/27/2011 02:50 PM, Barry Warsaw wrote: >>> Minutes of the UDD stakeholders meeting 2011-01-26 2100 UTC are now >>> available >>> here: >>> >>> https://wiki.ubuntu.com/DistributedDevelopment/20110126 >>> >>> There's been lots of excellent progress, so please do read the page. And >>> remember, all are welcome to join us in #ubuntu-meeting. >>> >>> -Barry > >> Would it be possible to get this meeting scheduled on the Fridge, if >> it's recurring? > >> Thanks, >> Micah > > > It happens every 2 weeks. I don't know how to schedule anything on the > Fridge, though. > > John > =:-> https://wiki.ubuntu.com/Fridge/Calendar -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: UDD stakeholders meeting minutes 2011-01-26
On 01/27/2011 02:50 PM, Barry Warsaw wrote: > Minutes of the UDD stakeholders meeting 2011-01-26 2100 UTC are now available > here: > > https://wiki.ubuntu.com/DistributedDevelopment/20110126 > > There's been lots of excellent progress, so please do read the page. And > remember, all are welcome to join us in #ubuntu-meeting. > > -Barry Would it be possible to get this meeting scheduled on the Fridge, if it's recurring? Thanks, Micah -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Making bzr commit more like debcommit
On 01/24/2011 10:16 AM, Barry Warsaw wrote: > On Jan 24, 2011, at 10:09 AM, Micah Gersten wrote: > >> I actually wanted to add more features to debcommit like passing an >> author name. It might be easier to try to standardize on debcommit so >> that it's portable across multiple VCSs. Making bzr commit call >> --fixes also sounds good for those that strictly use bzr. > > One of the reasons why I want to improve and recommend 'bzr commit' is that > when using UDD, bzr is your front-end for most of the work. It seems jarring > to have to remember to switch to debcommit for a step. Perhaps OTOH, > debcommit should be recommended everywhere, but then, that seems jarring to > someone used to using bzr. (We already recommended dch but that doesn't seem > as bad because it doesn't really mirror a standard bzr command.) > > -Barry Right, but debcommit is the same as with any other VCS. You run VCS foo, dch, and debcommit. <-- I wonder if debcommit is actually used like this, I know that's what it's intended for, but it would be interesting to know if it's actually used like that, especially with git. Micah -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Making bzr commit more like debcommit
On 01/24/2011 09:54 AM, Barry Warsaw wrote: > We have 'bzr commit' and we have 'debcommit'. Currently, the UDD guidelines > talk about both, but for consistency, I'd like to standardize on recommending > 'bzr commit'. One feature that debcommit has: > > DEBCOMMIT(1) DEBCOMMIT(1) > > NAME > debcommit - commit changes to a package > > ... > > VCS SPECIFIC FEATURES > ... > bzr If the changelog entry used for the commit message closes any bugs > then --fixes options to "bzr commit" will be generated to > associate the revision and the bugs. > > I know we can just do 'bzr commit --fixes lp:12345', though I often forget to > do that until after my last commit, so I tend to add --unchanged, which leads > to an empty revision. > > What do you think about making 'bzr commit' act more like debcommit when > there's a new debian/changelog entry? > > -Barry I actually wanted to add more features to debcommit like passing an author name. It might be easier to try to standardize on debcommit so that it's portable across multiple VCSs. Making bzr commit call --fixes also sounds good for those that strictly use bzr. Micah -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
