FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-13-2008, 03:54 PM
Kapil Hari Paranjape
 
Default Meaning of the "Altering package upload rules"

Hello,

I was wondering how to interpret the GR altering upload rules
(http://www.debian.org/vote/2007/vote_002) in practical terms.

I suppose this means that one can upload a <pkg-ver>_multi.changes
file containing <pkg-ver>_<arch>.deb for multiple values
of <arch> providing one has access to all these architectures.

Does it also mean that one can (later) do a binary-only upload
of a <pkg-ver>_<arch>.changes providing that the package
has not yet been built on the buildd's for <arch>? (Providing
that one is building from the same sources, of course!)

I looked for answers in the usual places but could not find an
answer and would be glad if someone could send a pointer.

Thanks and regards,

Kapil
(who is not subscribed to debian-devel but reads the archives).
--
 
Old 02-13-2008, 04:41 PM
David Paleino
 
Default Meaning of the "Altering package upload rules"

Il giorno Wed, 13 Feb 2008 22:24:15 +0530
Kapil Hari Paranjape <kapil@imsc.res.in> ha scritto:

> Hello,
>
> I was wondering how to interpret the GR altering upload rules
> (http://www.debian.org/vote/2007/vote_002) in practical terms.

Hi can't even find the text of this GR.

This is the relevant bit, I think:

/---
| Text
|
| Choice 1.
| The actual text of the resolution is as follows. Please note that
| this does not include preludes, prologues, any preambles to the
| resolution, post-ambles to the resolution, abstracts, fore-words,
| after-words, rationales, supporting documents, opinion polls,
| arguments for and against, and any of the other important material
| you will find on the mailing list archives. Please read the
| debian-vote mailing list archives for details.
|
| General Resolution: Altering package upload rules
|
| The Debian project resolves that Debian developers allowed to
| perform combined source and binary packages uploads should be
| allowed to perform binary-only packages uploads for the same set
| of architectures.
---

But... where is the "actual text of the resolution" mentioned? I can't even
find that.

> I suppose this means that one can upload a <pkg-ver>_multi.changes
> file containing <pkg-ver>_<arch>.deb for multiple values
> of <arch> providing one has access to all these architectures.
>
> Does it also mean that one can (later) do a binary-only upload
> of a <pkg-ver>_<arch>.changes providing that the package
> has not yet been built on the buildd's for <arch>? (Providing
> that one is building from the same sources, of course!)

Interpreting the paragraph cited above ("The Debian project resolves..."), I
believe you saw it right. But I'd like to know where is the full text of the GR
(or probably I'm just missing the obvious location).

Kindly,
David

(I'm CCing you because you said you're not subscribed; please tell me if you
wish otherwise)

--
. '`. Debian maintainer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
 
Old 02-13-2008, 05:14 PM
Raphael Hertzog
 
Default Meaning of the "Altering package upload rules"

Hi,

On Wed, 13 Feb 2008, Kapil Hari Paranjape wrote:
> I was wondering how to interpret the GR altering upload rules
> (http://www.debian.org/vote/2007/vote_002) in practical terms.
>
> I suppose this means that one can upload a <pkg-ver>_multi.changes
> file containing <pkg-ver>_<arch>.deb for multiple values
> of <arch> providing one has access to all these architectures.
>
> Does it also mean that one can (later) do a binary-only upload
> of a <pkg-ver>_<arch>.changes providing that the package
> has not yet been built on the buildd's for <arch>? (Providing
> that one is building from the same sources, of course!)

Yes. The full story was that some DD did setup non-official buildd
for some arch where the official buildd weren't keeping up (or were badly
managed). Thus they started to do many binary-only uploads. In response to
this, the buildd maintainers/ftpmasters (elmo/neuro) blocked their
privileges to do binary-only uploads.

This GR reverse the decision of buildd maintainers/ftpmasters and allows
them to do binary-only uploads.

That said, there are good reasons why one shouldn't do (massive)
binary-uploads (reproducibility of builds on official buildd => important
for the security team which will have to make builds of packages on the
official buildd during lifetime of the stable release, availability of
logs in buildd.debian.org). Thus refrain from doing this unless it's
really needed and only if you didn't manage to solve the problem by
communicating with the official buildd maintainer.

Cheers,
--
RaphaŽl Hertzog

Le best-seller franÁais mis ŗ jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-13-2008, 05:23 PM
Bas Wijnen
 
Default Meaning of the "Altering package upload rules"

On Wed, Feb 13, 2008 at 06:41:57PM +0100, David Paleino wrote:
> Kapil Hari Paranjape <kapil@imsc.res.in> ha scritto:
> > I was wondering how to interpret the GR altering upload rules
> > (http://www.debian.org/vote/2007/vote_002) in practical terms.
>
> This is the relevant bit, I think:
>
> /---
> | Text
> |
> | Choice 1.
> | The actual text of the resolution is as follows. Please note that
> | this does not include preludes, prologues, any preambles to the
> | resolution, post-ambles to the resolution, abstracts, fore-words,
> | after-words, rationales, supporting documents, opinion polls,
> | arguments for and against, and any of the other important material
> | you will find on the mailing list archives. Please read the
> | debian-vote mailing list archives for details.
> |
> | General Resolution: Altering package upload rules
> |
> | The Debian project resolves that Debian developers allowed to
> | perform combined source and binary packages uploads should be
> | allowed to perform binary-only packages uploads for the same set
> | of architectures.
> ---
>
> But... where is the "actual text of the resolution" mentioned? I can't even
> find that.

It's "as follows", meaning it's the paragraph directly after that one.
In other words, it's the one you also quoted.

> > I suppose this means that one can upload a <pkg-ver>_multi.changes
> > file containing <pkg-ver>_<arch>.deb for multiple values
> > of <arch> providing one has access to all these architectures.

No. Whether that is possible is a technical thing. It only says that
the fact that I am allowed to upload a source+some_arch package means that I
should also be allowed to do a some_arch bin-only upload.

> > Does it also mean that one can (later) do a binary-only upload
> > of a <pkg-ver>_<arch>.changes providing that the package
> > has not yet been built on the buildd's for <arch>? (Providing
> > that one is building from the same sources, of course!)

Yes, it effectively means that developers should be allowed to use their
own machines as buildds if they want.

> But I'd like to know where is the full text of the GR (or probably I'm
> just missing the obvious location).

You quoted it. It wasn't very long. :-)

> (I'm CCing you because you said you're not subscribed; please tell me if you
> wish otherwise)

I told mutt to do a list-reply, and appearantly there were no headers
telling it to keep that Cc, so I'll assume he's reading the archives (as
he said). :-)

Thanks,
Bas

--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
 
Old 02-13-2008, 05:28 PM
Russ Allbery
 
Default Meaning of the "Altering package upload rules"

Kapil Hari Paranjape <kapil@imsc.res.in> writes:

> Hello,
>
> I was wondering how to interpret the GR altering upload rules
> (http://www.debian.org/vote/2007/vote_002) in practical terms.

Basically, the intent of the GR is to say that any developer who can do
regular uploads for an architecture can also do porter uploads as
described in the Debian Developer's Reference 5.10.2.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-13-2008, 08:21 PM
Stefano Zacchiroli
 
Default Meaning of the "Altering package upload rules"

On Wed, Feb 13, 2008 at 07:14:21PM +0100, Raphael Hertzog wrote:
> That said, there are good reasons why one shouldn't do (massive)
> binary-uploads (reproducibility of builds on official buildd => important
> for the security team which will have to make builds of packages on the
> official buildd during lifetime of the stable release, availability of
> logs in buildd.debian.org).

The architecture for which a DD is initially uploading a package is
already lacking a build log on buildd.debian.org and the corresponding
build has no guarantee to be reproducible.

So if these are good arguments for not doing (massive) binary uploads,
they are also good arguments for not allowing binary-uploads at all
(thousands DDs making binary uploads are hardly worst than 1 DD doing
massive binary uploads). Or, if you prefer, they are good arguments for
throwing away the .debs uploaded by DDs and rebuilding them from
scratch.

SCNR, really.

--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/
(15:56:48) Zack: e la demo dema ? / All one has to do is hit the
(15:57:15) Bac: no, la demo scema / right keys at the right time
 
Old 02-13-2008, 08:28 PM
Cyril Brulebois
 
Default Meaning of the "Altering package upload rules"

On 13/02/2008, Stefano Zacchiroli wrote:
> The architecture for which a DD is initially uploading a package is
> already lacking a build log on buildd.debian.org and the
> corresponding build has no guarantee to be reproducible.
>
> So if these are good arguments for not doing (massive) binary
> uploads, they are also good arguments for not allowing
> binary-uploads at all (thousands DDs making binary uploads are
> hardly worst than 1 DD doing massive binary uploads). Or, if you
> prefer, they are good arguments for throwing away the .debs uploaded
> by DDs and rebuilding them from scratch.
>
> SCNR, really.

I just made the same remark to RaphaŽl on IRC, thanks for summing it
up here.

Cheers,

--
Cyril Brulebois
 
Old 02-13-2008, 09:07 PM
Lucas Nussbaum
 
Default Meaning of the "Altering package upload rules"

On 13/02/08 at 22:21 +0100, Stefano Zacchiroli wrote:
> So if these are good arguments for not doing (massive) binary uploads,
> they are also good arguments for not allowing binary-uploads at all
> (thousands DDs making binary uploads are hardly worst than 1 DD doing
> massive binary uploads). Or, if you prefer, they are good arguments for
> throwing away the .debs uploaded by DDs and rebuilding them from
> scratch.

I never saw the point of binaries+source uploads where you throw away the
binaries. The only point of this is to force DDs to check that the
package actually builds. If some DDs upload stuff that they don't know
to work, that's a social issue, not a technical one.

Currently, we already have several DDs building their packages without
using an up-to-date, clean sid chroot. If we start throwing away the
binaries that are uploaded, there won't be any point in using a clean
chroot, or even to upload the real binary packages: small fake binary
packages would be much more cpu- and bandwidth-friendly
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
 
Old 02-14-2008, 06:45 AM
Stefano Zacchiroli
 
Default Meaning of the "Altering package upload rules"

On Wed, Feb 13, 2008 at 11:07:22PM +0100, Lucas Nussbaum wrote:
> I never saw the point of binaries+source uploads where you throw away the
> binaries. The only point of this is to force DDs to check that the
> package actually builds. If some DDs upload stuff that they don't know
> to work, that's a social issue, not a technical one.

Indeed it is the only point. It is social, the technical "solution" of
ensuring .debs are actually there is just an attempt to diminish its
impact. Instead of "throwing them away", since we are all using tools
such as dput and dupload, just having those tools check the .debs are
there, performing some basic sanity checks on them, and then avoiding
their upload would probably achieve the same effect.

But of course, this was not the main point of my post. It was rather
against the current situation of treating specially some architecture
only because it is the one owned by a DD.

Cheers.

--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/
(15:56:48) Zack: e la demo dema ? / All one has to do is hit the
(15:57:15) Bac: no, la demo scema / right keys at the right time
 
Old 02-14-2008, 11:12 AM
Enrico Tassi
 
Default Meaning of the "Altering package upload rules"

On Wed, Feb 13, 2008 at 11:07:22PM +0100, Lucas Nussbaum wrote:
> On 13/02/08 at 22:21 +0100, Stefano Zacchiroli wrote:
> Currently, we already have several DDs building their packages without
> using an up-to-date, clean sid chroot. If we start throwing away the

Even if the package is rebuilt, the uploaded debs are not useless.
You may debdiff them and eventually informe the developer that:
- his build environment is corrupted (or the buildd's one)
- his package build process is installation sensitive (behaves
differently on a different installation).

Cheers
--
Enrico Tassi
 

Thread Tools




All times are GMT. The time now is 07:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org