DM uploads to experimental (was: Re: CUT rolling release debian)

2015-03-07 Thread Ansgar Burchardt
Hi,

Jaromír Mikeš mira.mi...@gmail.com writes:
 2015-03-06 23:20 GMT+01:00 Rebecca N. Palmer rebecca_pal...@zoho.com:
 DMs can upload to experimental, and Ubuntu will sync from there if you ask
 them to: see e.g. https://tracker.debian.org/pkg/flightgear

 Right DM is not allowed to upload to a suite where there's no package
 already.
 So first you need to ask some DD to upload your package to experimental for
 you than DM can upload too.

That's not strictly true: DMs can only not upload packages that would go
to NEW. This includes uploading packages to the backports suites (if
they were not in backports before).

However unstable and experimental share overrides, that is uploads to
experimental do not have to pass NEW when the package is already in
unstable (and the other way around).

Ansgar


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ioedyyri.fsf...@deep-thought.43-1.org



uploads to experimental

2010-03-18 Thread Brian May
Hello,

How do I make uploads to experimental?

I thought this putting experimental in the changelog was sufficient:

=== cut ===
 heimdal (1.4.0~git20100221.dfsg.1-2) experimental; urgency=low
 .
   * Update debshlibs dependancies. Anything compiled against the
 version of Heimdal in experimental will require the libraries from
 experimental. May not strictly be required for all libraries, but
 better be safe then sorry.
   * This also will resolves a bug for the experimental version that has
 already been solved in stable (closes: 571206).
=== cut ===

However the upload appears to have gone to unstable instead of experimental.

Is this because I used sbuild to build the package against a sid chroot?

How do I fix this mess up?

Thanks
-- 
Brian May br...@microcomaustralia.com.au


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3c5cf5261003181758r2db6b8efs5c9c9978e2380...@mail.gmail.com



Re: uploads to experimental

2010-03-18 Thread Russ Allbery
Brian May br...@microcomaustralia.com.au writes:

 How do I make uploads to experimental?

 I thought this putting experimental in the changelog was sufficient:

 === cut ===
  heimdal (1.4.0~git20100221.dfsg.1-2) experimental; urgency=low
  .
* Update debshlibs dependancies. Anything compiled against the
  version of Heimdal in experimental will require the libraries from
  experimental. May not strictly be required for all libraries, but
  better be safe then sorry.
* This also will resolves a bug for the experimental version that has
  already been solved in stable (closes: 571206).
 === cut ===

 However the upload appears to have gone to unstable instead of experimental.

The only thing that matters to the archive software is what distribution
is listed in the *.changes file.  Normally, this is taken from the
changelog.  I'm not sure why it would have been set to sid in this case,
but looking in the PTS at heimdal, you can see that the *.changes file
associated with the upload says sid.

 How do I fix this mess up?

Unfortunately, to get back to 1.3 in unstable, you have to upload
something with a higher version number than the upload that was supposed
to go to experimental, which means either using an epoch or an artificial
version number that's higher than the one above.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxy5un0m@windlord.stanford.edu



Re: uploads to experimental

2010-03-18 Thread Ryan Niebur
On Thu, Mar 18, 2010 at 06:18:49PM -0700, Russ Allbery wrote:
 Brian May br...@microcomaustralia.com.au writes:
 
  How do I make uploads to experimental?
 
  I thought this putting experimental in the changelog was sufficient:
 
  === cut ===
   heimdal (1.4.0~git20100221.dfsg.1-2) experimental; urgency=low
   .
 * Update debshlibs dependancies. Anything compiled against the
   version of Heimdal in experimental will require the libraries from
   experimental. May not strictly be required for all libraries, but
   better be safe then sorry.
 * This also will resolves a bug for the experimental version that has
   already been solved in stable (closes: 571206).
  === cut ===
 
  However the upload appears to have gone to unstable instead of experimental.
 
 The only thing that matters to the archive software is what distribution
 is listed in the *.changes file.  Normally, this is taken from the
 changelog.  I'm not sure why it would have been set to sid in this case,
 but looking in the PTS at heimdal, you can see that the *.changes file
 associated with the upload says sid.
 

It may have something to do with this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559659

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature


Re: uploads to experimental

2010-03-18 Thread Brian May
On 19 March 2010 12:25, Ryan Niebur r...@debian.org wrote:
 It may have something to do with this:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559659

No, possibly more likely:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529281

Except the justification given is wrong. I want to be able to pick the
schroot manually and have it automatically determine the distribution
for the changes file after building the package.

According to the man page in my version of sbuild:

   -d, --dist=distribution
  Fetch source packages from specified distribution.

However this documentation doesn't say this will also override the
distribution used in the changes file. Maybe it should also complain
if the distribution in the changes file doesn't match that in the log
file.

In this case I want to build against sid but still use experimental.

I see there is a --chroot option to sbuild, however I am not really
sure what it does, it doesn't seem to take an option (???):

   -c, --chroot
  Use  the  specified  chroot.  If  not  specified,  the
default is the first of $distribution-$arch-sbuild, $distribu-
  tion-sbuild, $distribution-$arch or $distribution that exists.

-- 
Brian May br...@microcomaustralia.com.au


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3c5cf5261003181910w7d4bd396p7b629da95e292...@mail.gmail.com



Re: uploads to experimental

2010-03-18 Thread Cyril Brulebois
Brian May br...@microcomaustralia.com.au (19/03/2010):
 According to the man page in my version of sbuild:
-d, --dist=distribution
   Fetch source packages from specified distribution.
 
 However this documentation doesn't say this will also override the
 distribution used in the changes file. Maybe it should also complain
 if the distribution in the changes file doesn't match that in the log
 file.

http://lists.debian.org/debian-devel/2010/02/msg00624.html gives a
slight idea, but indeed, NEWS.Debian + manpage fix would help, I
guess.

 In this case I want to build against sid but still use experimental.
 
 I see there is a --chroot option to sbuild, however I am not really
 sure what it does, it doesn't seem to take an option (???):
 
-c, --chroot
   Use  the  specified  chroot.  If  not  specified,  the
 default is the first of $distribution-$arch-sbuild, $distribu-
   tion-sbuild, $distribution-$arch or $distribution that exists.

It says “specified”, one could think it's specified... as an argument
to this option? But usage probably should be clarified.

Anyway, there you go:
| k...@bowmore:/tmp$ sbuild -c sid-amd64-sbuild -d experimental 
gtk2-engines_2.18.5-2.dsc
| […]
| Chroot Build Dir: 
/opt/sid-amd64-sbuild/build/kibi-gtk2-engines_2.18.5-2-amd64-efx3bT
| […]
| k...@bowmore:/tmp$ grep ^Distribution gtk2-engines_2.18.5-2_amd64.changes
| Distribution: experimental

Mraw,
(kinda-experimental-related-screw-ups-specialist-)KiBi.


signature.asc
Description: Digital signature


Re: uploads to experimental

2010-03-18 Thread Brian May
On 19 March 2010 13:24, Cyril Brulebois k...@debian.org wrote:
 | k...@bowmore:/tmp$ sbuild -c sid-amd64-sbuild -d experimental 
 gtk2-engines_2.18.5-2.dsc

What happens if you omit the -d and only have -c?
-- 
Brian May br...@microcomaustralia.com.au


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3c5cf5261003182028k125c5556mfb3f6ebe33f38...@mail.gmail.com



Re: uploads to experimental

2010-03-18 Thread Cyril Brulebois
Brian May br...@microcomaustralia.com.au (19/03/2010):
 On 19 March 2010 13:24, Cyril Brulebois k...@debian.org wrote:
  | k...@bowmore:/tmp$ sbuild -c sid-amd64-sbuild -d experimental 
  gtk2-engines_2.18.5-2.dsc
 
 What happens if you omit the -d and only have -c?

As already pointed out in [1]: #559659, which resulted in what's
described in the 1st point of [2], which I mentioned in my previous
mail.

 1. http://lists.debian.org/debian-devel/2010/03/msg00597.html
 2. http://lists.debian.org/debian-devel/2010/02/msg00624.html

Anyway, for the sake of completeness: “No distribution defined”.

Mraw,
KiBi.


signature.asc
Description: Digital signature