Bug#673505: general: xorg and xserver-xorg 7.6+13 always made X and gnome-shell dead

[Xueqian]

Package: general
Severity: important

Dear Maintainer,

Recently, I have upgrade packages xorg, xserver-xorg, xserver-xorg-input-all 
and 
x11-common from 7.6+12 to 7.6+13. 

After that, my desktop environment was always dead that cpu of X became 70% and 
cpu of gnome-shell occupy the other 30%. 
And I had to forcely shutdown the X service and re-type startx to start the 
gnome-shell.
The reason that I observed to make X dead is mainly due to using ibus 
and operating browsers that includes firefox 12, iceweasel 10, and google 
chrome.
I did not observe that other operating or software result in the same problem.

Since more than half of my gnome packages are version 3.4, while some are 
version 3.2, as well as gnome-shell and gnome-shell-extension.

Thus, I do not know whether the problem results from gnome-shell or xorg.
The reason that I report the title relevant to xorg is that I found sometimes 
the xorg info showed some bugs "Gdk-WARNING: x-session-manager: Fatal IO error 
11 on X server: 0.#012" and sometimes related to kbd (I can not find the error 
info now.)

Thanks

*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20120519062433.28795.37550.reportbug@Studio-14z

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Russ Allbery]

Charles Plessy  writes:

> How about integrating it with the Policy's chapter 5 (thus enlarging its
> scope) instead of having it as a separate document ?  That would help to
> underline when a field is used in the same way or differently as in the
> package control data files.

The primary reason why I'm hesitant to do this is that I don't think the
normal Policy change process is useful for this document.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87zk941z9w@windlord.stanford.edu

About building packages in porterbox

[Liang Guo]

Hi, List,

One of my packages [1] failed to build on armel, kfreebsd and hurd, 
But I don't have such a machine to test my packages. Is it possible
to use debian porterbox to build the package and dig into this 
problem ?

[1] https://buildd.debian.org/status/package.php?p=spice-vdagent

Thanks and Regards,
--
Liang Guo
http://bluestone.cublog.cn


signature.asc
Description: Digital signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Tollef Fog Heen]

]] Roger Leigh 

> I think this is a key point.  The aim of the git format should not be
> provide the entire history, any more than the other formats do (not).
> 
> What should be provided needs to be
> - sufficient to build the package
> - sufficient to determine the changes made between the Upstream
>   release and the Debian upload
> - sufficient to allow further uploads, including NMUs
> - (allow restoration of the full history)

- The source, aka the preferred form for modification.

I think we're failing to provide that in many cases today, since if
you're going to do any serious hacking on a project, you end up cloning
its VCS, you don't just grab a tarball and use that.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87txzcsrc7@qurzaw.varnish-software.com

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Charles Plessy]

Le Fri, May 18, 2012 at 06:49:10PM +0200, Julian Andres Klode a écrit :
> 
> In a few months, I'd like to rework this in DocBook form, and submit it to
> debian-policy for inclusion into official Policy, as a sub-policy like
> copyright-format.

Dear Julian and everybody,

thank you for this documentation effort.  I think it is very useful.

How about integrating it with the Policy's chapter 5 (thus enlarging its scope)
instead of having it as a separate document ?  That would help to underline
when a field is used in the same way or differently as in the package control
data files.

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20120519042845.gd5...@falafel.plessy.net

Re: Bug#642801: ftp.debian.org: Please support dpkg-source format 3.0 (git) in our archive.

[Charles Plessy]

Le Sat, May 19, 2012 at 11:56:07AM +0900, Charles Plessy a écrit :
> 
> In the case of the initial copryight review, which is if I understand well the
> strongest objection, wouldn't it be solved if the first upload to Debian would
> contain as few history as possible ?  Then the quantity of history in the
> source packages could be allowed to grow, for instance up to one or two
> previous stable releases.

Only after sending that email I remembered about #642801.  Sorry for the noise.

Dear FTP team,

is the "wontfix" tag only related to the problem of the copyright review or do
you think other issues are blocking ?

In case of the copyright review, would it be accepteable if the first upload of
a package in 3.0 (git) package would contain as little history as possible,
that is, either one revision, or multiple when they correspond to the equivalent
of Debian-specific patches ?

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20120519034159.gc5...@falafel.plessy.net

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Charles Plessy]

Le Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery a écrit :
> Charles Plessy  writes:
> 
> > Also, it is very sad that, as a project, we can not decide whether we go
> > for 3.0 (git) or not, or have a concrete list of resolvable objections
> > from the people whose work is direclty impacted by the use of this
> > format.
> 
> We know what a primary concrete objection is.  We discussed it at length
> at DebConf two years ago, and then on debian-devel afterwards.  Uploading
> a Git archive requires reviewing the entire contents of the archive, not
> just the current code, for licensing issues, which is pretty painful from
> the ftp-master perspective.
> 
> There was never really a satisfactory resolution to that discussion.

Hi Russ and everybody,

it is indeed hard to reach conclusions when discussing on high-traffic mailing
lists.

I have attempted to summarise some elements of discussion on wiki.debian.org.
Please let me know if I have misunderstood or misrepresented people's
contributions, and I will correct.  Please of course feel free to correct or
update by yourself.

  http://wiki.debian.org/GitSrc#Discussion

In the case of the initial copryight review, which is if I understand well the
strongest objection, wouldn't it be solved if the first upload to Debian would
contain as few history as possible ?  Then the quantity of history in the
source packages could be allowed to grow, for instance up to one or two
previous stable releases.

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20120519025607.ga5...@falafel.plessy.net

Re: on the use of chmod/chown in maintainer scripts

[Raphael Geissert]

Hi Peter,

Thanks for bringing up this issue again. Admittedly, there hasn't been much 
progress since it was discussed last year.

Hopefully, the discussion has focused on a solution to completely avoid the 
problem during upgrades.
For the general issue, the only progress I made was in the form of #608623, 
but I haven't spent any time trying to implement lchmod in the kernel.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/jp6rda$8st$1...@dough.gmane.org

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Paul Wise]

On Sat, May 19, 2012 at 12:58 AM, Julian Andres Klode wrote:

> What's the opinion about the flat repository format, where you
> just have one directory with Release, Packages, Sources, and
> friends and no sub-directories?
>
> Should they be documented as well then? We would then have two
> kind of documented repository formats:
>
>        1. Debian-style, with a pool (or similar) and a dists directory
>        2. Flat-style, with just one directory
>
> This should cover everything we currently support. Although I don't
> know much about how much stuff we support in flat directories WRT
> Translation, Contents, and diffs.

I would like to see the flat-style repository documented too, since
some of the derivatives in the Debian derivatives census use it and I
would like to lint their apt repositories.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/caktje6gw9k_p_7ch-kzwnsxnpiwdbs3hxu1cyw_qjmgaydh...@mail.gmail.com

Re: Wheezy release: CDs are not big enough any more...

[Adam Borowski]

On Fri, May 18, 2012 at 12:27:15PM -0400, Joey Hess wrote:
> Guillem Jover wrote:
> > Only as long as the debian/control information matches the one from
> > the archive override.
> 
> I checked, and currently the only base package with an overridden priority
> is libsigc++-2.0-0c2a

So, would it be safe to make dpkg-deb default to xz if priority is <
important for wheezy?

My point is, the sooner this change is made, the more of the pre-release
upload spike will benefit from reduced package size.  It can be then changed
by either improving debootstrap (unlikely due to old versions) or the
base-ness check.

Also, lintian currently doesn't complain if a base package uses xz.  Should
it?  This check wouldn't be very useful since priority override is the only
interesting case, though.

-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon


signature.asc
Description: Digital signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Russ Allbery]

Henrique de Moraes Holschuh  writes:

> When it is time to release/upload, the branch gets git format-patch'd,
> and makes its way to debian/patches for 3.0(quilt) to handle.  That
> branch is never published.  git-pq can automate this stuff in an even
> better way that is rebase-less if you want, but I don't bother.

I do this work in cases where keeping the patches separate is useful for
some reason, but mostly it's not.  I therefore use single-debian-patch for
most of my packages, and only use this sort of automation for a very few
where there are lots of upstream changes and some benefit to keeping them
separate.

I'm unwilling to do all this extra work for a theoretical marginal benefit
that only applies to people who aren't using Git.  I'm only willing to do
it when the benefit is not theoretical.  For most of my packages, no one
is going to care, particularly for those where I'm also upstream.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87r4uhcmi8@windlord.stanford.edu

Re: What to do with bug reports against non-existing/removed packages

[Alexander Reichle-Schmehl]

Hi!

On 18.05.2012 10:50, Paul Wise wrote:


Our bug tracker contains items for packages, which do (not longer) exist. What 
should happen to them? I see, that it might be a good idea to keep them for the 
case, a package is re-introduced. But this might happen only for a few 
packages. Most of them got removed because newer versions were released. What 
about closing those reports, if an RM-request is filed?


ftpmaster already close bugs automatically when processing RM requests.


Not always.  IIRC we only close bugs on removal if:

a) BTS is up and running.
b) source and binary are removed.
c) The package is removed from unstable.
d) The removed package is on sync on all arches. (Because otherwise we 
won't know with which version we'd like to close the bug.)


d) also affects binNMUed packages.


Best regards,
  Alexander


--
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/4fb6a0d2.6000...@schmehl.info

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Michal Suchanek]

Excerpts from Julian Andres Klode's message of Fri May 18 18:49:10 +0200 2012:
> On Fri, May 18, 2012 at 04:06:23PM +0200, Michal Suchanek wrote:
> > FWIW
> > 
> > posted on the wiki: http://wiki.debian.org/RepositoryFormat
> > 
> > Thanks
> > 
> > Michal
> 
> I have now documented the Contents indices and the diffs
> as well, mostly (sans the exact format we use for the
> patches), and Translation indices. Now we're basically
> only missing details, it is fairly complete otherwise
> (i.e. we should have mentioned every file and field
> currently in use, but may not have explained all of
> them completely).
> 
> We now have documented
> 
> dists/$DIST/Release (and InRelease, Release.gpg)
> dists/$DIST/$COMP/binary-$ARCH/Packages
> dists/$DIST/$COMP/source/Sources
> dists/$DIST/$COMP/Contents-$ARCH.gz
> dists/$DIST/$COMP/i18n/{Index,Translation-*.bz2}
> *.diff/Index *.diff/%Y-%m-%d-%H%M.%S.gz
> 
> The other Release files have been omitted, as they are not
> used anywhere. We are only missing udeb content files and
> packages files now, which are just small subsentences.
> 
> In a few months, I'd like to rework this in DocBook form,
> and submit it to debian-policy for inclusion into official
> Policy, as a sub-policy like copyright-format.
> 

Yes, looks fairly complete.

The formatting is not consistent but that will have to be changed for
docbook anyway.

Also would need some proof-reading. If nothing else somebody should look
in a few weeks from now if it still makes sense ;-)

I put a link on the RepositoryHowto page for more exposure.

I am not so sure documenting Debian installer files is tremendously
useful. I don't think anyone outside Debian Installer team makes Debian
Installer repositories and there are other aspects of Debian Installer
that would need to be documented in order for it to be usable for
'outside' people in non-default configurations.

Thanks

Michal


-- 
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/1337363087-sup-4...@virtual.ruk.cuni.cz

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Julian Andres Klode]

On Fri, May 18, 2012 at 08:12:16PM +0200, Michal Suchanek wrote:
> The formatting is not consistent but that will have to be changed for
> docbook anyway.

Yes, and it will also be more readable then, than the current wiki
version.

> 
> Also would need some proof-reading. If nothing else somebody should look
> in a few weeks from now if it still makes sense ;-)

I'd also like to hear bits from the launchpad team about their
implementation and see whether they agree with everything then.


> 
> I put a link on the RepositoryHowto page for more exposure.
> 
> I am not so sure documenting Debian installer files is tremendously
> useful. I don't think anyone outside Debian Installer team makes Debian
> Installer repositories and there are other aspects of Debian Installer
> that would need to be documented in order for it to be usable for
> 'outside' people in non-default configurations.

We still need to at least document the udeb stuff, the images and
other stuff is not relevant to the core format and probably defined
by the d-i team anyway (and installed by-hand).

The udeb stuff is relatively easy to document, as it just adds one
new directory and one new filename for Contents files, so can be
done in about two sentences (and udebs are uploaded by standard
.changes with the rest of the package, and are thus standard).

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


-- 
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/20120518201701.ga17...@debian.org

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Wookey]

+++ Julian Andres Klode [2012-05-18 13:38 +0200]:

> We currently have three independent implementations of the repository
> format in the archive: APT, cupt, smartpm. 

I think reprepro is another?

/usr/share/doc/reprepro/manual.html contains a 'repository basics'
section which includes useful layout/format information.

Wookey


-- 
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/20120518174500.gf11...@stoneboat.aleph1.co.uk

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Julian Andres Klode]

On Fri, May 18, 2012 at 06:45:00PM +0100, Wookey wrote:
> +++ Julian Andres Klode [2012-05-18 13:38 +0200]:
> 
> > We currently have three independent implementations of the repository
> > format in the archive: APT, cupt, smartpm. 
> 
> I think reprepro is another?

Of course, I was just only talking about clients. When it comes to
creating we probably have much more than 3 programs needing some
knowledge of the repository format. We have dak, apt-ftparchive,
reprepro, debian-cd, everyone's small script, mini-dinstall (the
latter using flat repositories, if I am not mistaken).
-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


pgpLQZvyw4KlE.pgp
Description: PGP signature

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Julian Andres Klode]

On Fri, May 18, 2012 at 04:06:23PM +0200, Michal Suchanek wrote:
> FWIW
> 
> posted on the wiki: http://wiki.debian.org/RepositoryFormat

What's the opinion about the flat repository format, where you
just have one directory with Release, Packages, Sources, and
friends and no sub-directories?

Should they be documented as well then? We would then have two
kind of documented repository formats:

1. Debian-style, with a pool (or similar) and a dists directory
2. Flat-style, with just one directory

This should cover everything we currently support. Although I don't
know much about how much stuff we support in flat directories WRT
Translation, Contents, and diffs.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


-- 
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/20120518185407.ga15...@debian.org

Re: Wheezy release: CDs are not big enough any more...

[Joey Hess]

While this has been an interesting thread, it may be predicated on a
false premise. I examined the latest weekly CD build, and the reason no
desktop tasks at all (even lxde or xfce) appear on their respective CDs
is because debian-cd is simply not including tasksel's new task-*
packages, at all. 

The packages on the CD seem fairly random, including things not in any
task like wmaker, alien, and, on the lxde+xfce CD, lots of KDE, but no
ldxe or xfce.

Even DVD #1 seems broken, containing task-desktop, but not
task-gnome-desktop. I'm sure gnome still fits on a DVD.

Seems likely that things are badly broken in debian-cd's task handling.
Likely related to tasksel's new task-* packages.

The way debian-cd needs to handle the new task packages is this:

* Put task-gnome-desktop on CD#1, task-kde-dekstop on KDE CD #1, etc.
  (No need to use /usr/share/tasksel/descs/debian-tasks.desc anymore.)
* Try to include at all Recommends of task-* packages, not only their
  dependencies, as this is used to pull in the majority of packages for
  tasks. Do this even when normal Recommends inclusion is disabled.
* If space is tight, drop some of the task-* Recommends. And, since
  this needs to be special cased anyway, it would be nice to have an
  option to abort the build, and/or warn if they don't fully fit.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Julian Andres Klode]

On Fri, May 18, 2012 at 04:06:23PM +0200, Michal Suchanek wrote:
> FWIW
> 
> posted on the wiki: http://wiki.debian.org/RepositoryFormat
> 
> Thanks
> 
> Michal

I have now documented the Contents indices and the diffs
as well, mostly (sans the exact format we use for the
patches), and Translation indices. Now we're basically
only missing details, it is fairly complete otherwise
(i.e. we should have mentioned every file and field
currently in use, but may not have explained all of
them completely).

We now have documented

dists/$DIST/Release (and InRelease, Release.gpg)
dists/$DIST/$COMP/binary-$ARCH/Packages
dists/$DIST/$COMP/source/Sources
dists/$DIST/$COMP/Contents-$ARCH.gz
dists/$DIST/$COMP/i18n/{Index,Translation-*.bz2}
*.diff/Index *.diff/%Y-%m-%d-%H%M.%S.gz

The other Release files have been omitted, as they are not
used anywhere. We are only missing udeb content files and
packages files now, which are just small subsentences.

In a few months, I'd like to rework this in DocBook form,
and submit it to debian-policy for inclusion into official
Policy, as a sub-policy like copyright-format.


-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


pgpvMrHdLCzhm.pgp
Description: PGP signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/18/2012 11:37 AM, Adam Borowski wrote:
> On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote:
>> On 05/17/2012 04:52 PM, Gergely Nagy wrote:
 I'm confused concerning the above; the point of a VCS in this context
 is to track changes to the source package, and the patches are
 themselves important changes to the source package.  If you have Git
 ignore the patches then Git doesn't have a complete view of the
 source package anymore.  Why would you want to do that?
>>> 
>>> Git does have a complete view. What the above does, is tell
>>> dpkg-source to fold any changes made to the upstream sources into a
>>> single patch. Since the git tree already has the patches applied (with
>>> upstream sources on a different branch, most probably), it has a full
>>> view.
>>> 
>>> This basically folds whatever patches the git tree has over upstream, 
>>> outside of debian/ into a single file. That's about it. Since that
>>> file is generated, it has no business staying in git.
>> 
>> Doing that is the most stupid idea ever. All it does is to ensure that
>> you package can't be NMUed sanely and that people who need to work with
>> the sources and your patches for whatever reason have to clone your git,
>> which might be not available or just too large for them to download - so
>> at the end changes are high that they end up with a largish unreadable
>> patch, similar to the mess we get from Ubuntu sometimes. The only thing
>> that makes sense would be to use git-format-patch to export your patches
>> to debian/patches and list them in the series file. Or use gbp-pq, which 
>> was made exactly for that.
> 
> Uhm, please switch around "git" and "quilt", and say that again.

No.

> Quilt is a kind of really primitive VCS.  It does not make sense to use
> both it and a modern one, and when someone tries, this ends up with no end
> of woe.  Quilt sprinkles its modifications around the source, breaks
> timestamps causing unnecessary rebuilds, breaks basic VCS abilities like
> bisection, makes it really hard to even review history, and so on.

If you get a cd image with sources nobody cares what the maintainer used to
manage the package. A developer without internet access cares about usable
patches in debian/patches instead of a big, uncommented blob. Quilt is not a
VCS at all, it is a system to apply and unapply a list of patches, nothing more.


> You complain about forcing people to use git, while you push quilt onto 
> everyone else.  And while git can do every single thing quilt can do, the 
> reverse is thoroughly untrue.

See above. To use patches in debian/patches you don't even need quilt. People
might not have access to your famous git repository.


> I really wish there was a "3.0" format besides "3.0 (quilt)", so people
> are not mislead into thinking they have to (or even, would gain anything)
> from writing patches in quilt's format.

Quilt doesn't us a special format. You can just go and run git-format-patch to
export patches from git.

If you want people to be able to work with your patches *AND* you don't like
to ship a proper (quilt) set of patches, figure out what needs to be done to
get 3.0 (git) accepted (like automatic removal of branches which are not part
of the packaging, ensuring that source versions which were not distributable
were removed from the repository, and so on...) - then you can happily assume
that people are able to use your git repository as they actually get a copy on 
CD.



- -- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPtnjHAAoJEOs2Fxpv+UNfQREP/A9Y2Cy6zzd+kQeje8AvjtSQ
VrWJEFwNDcWM/Sf5K6NvccSg+G+8dMjb8XXv9HOJKf9wnSXLLpHTbIAUpTTms71a
HHis4lCIrm6t1HAU7GmQAHwhJKW+z1G52xzzEXC9SHfECCaMERDPgUwrHsO2mujx
qN9ormQufui0SmWUlIvRyNp9S5UtY7Qvq1iNzquK+D/9l8U5sCx8TcxhBmR7L8ZO
8Ncby9dIzvYVUahGXwpOB4am/1VPPJkMIMW+IrpJIXKrpjg8KWXJ5JC1eFOu3PHs
vUBoqm42M9LeFhmcCO2H20aCF9JhoMQkPkqTmQBJEpvtIvo3xm9/SQIm296aGtKS
dWA3Vs3XZCL0+OOxfo0pE46kwxb3M7m327dg2O0mdMtq+NPTh8Xon1E2k4yHVSEe
BBl4o2JRrXEVKj3NnJbT9PbajwzOMzZYuIk0APyWePPfi1j5j6kaZXFBblz6x4H/
+R5PshcVoiX0ZQKmXcOmr1QNDc6XygiS2PCapeQbFURcVBqEvf1ePtqHAendYP+F
1QmIYh5HbKVI+Tkr9962Kd782zJuT2Ja9GeZE40XpxxXiKKI84mVdlNTuUzHXixl
8MIg97VsEOp0LC6K9Oa3vOEObJ+4ln3ZCKUn9npWDZ59+Yt9Fmkw1K3V/NuJFsTS
uYhgNlkRtgPojwfw+L5t
=oQ0Y
-END PGP SIGNATURE-


-- 
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/4fb678d5.8040...@bzed.de

Re: Wheezy release: CDs are not big enough any more...

[Joey Hess]

Guillem Jover wrote:
> Only as long as the debian/control information matches the one from
> the archive override.

I checked, and currently the only base package with an overridden priority
is libsigc++-2.0-0c2a

-- 
see shy jo


signature.asc
Description: Digital signature

Re: What to do with bug reports against non-existing/removed packages

[Neil Williams]

On Fri, 18 May 2012 16:41:55 +0100
"Manuel A. Fernandez Montecelo"  wrote:

> Another question, perhaps unrelated is, what happens with the bugs
> closed from egroupware or salome (removed from unstable/testing but
> still present in stable releases) when their users look for them in
> the BTS?  They would be closed and archived, I suppose, and users of
> stable wouldn't be able to find them easily -- and them maybe report
> them again.

Depends on the found version of the bugs. If the bug isn't found in any
version currently in Debian, the bug needs to be closed. It could be
triaged in the previous versions, if people have the time, but that may
well have already happened or someone may have added a comment to the
bug that it affects old releases too.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpRfWwcshipn.pgp
Description: PGP signature

Re: What to do with bug reports against non-existing/removed packages

[Manuel A. Fernandez Montecelo]

2012/5/18 Thomas Preud'homme :
> According to [1] salome is not part of any debian release now. Did I miss
> something? IIRW, for package still in stable, if the -done mail contains the
> right version then the bug will still be visible as long as it affects stable.

Oh yes, egroupware only in oldstable... and I saw some entries of
salome [1] and mistakenly took them for "oldstable", not "unstable in
some architectures".

http://packages.debian.org/search?keywords=salome

Cheers.


-- 
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/CAPQ4b8=b+SZScVmv+DU_vtVWg+_-q-GbcbJLbQ5tE6Lk=zu...@mail.gmail.com

Re: What to do with bug reports against non-existing/removed packages

[Thomas Preud'homme]

Le vendredi 18 mai 2012 17:41:55, Manuel A. Fernandez Montecelo a écrit :
> 2012/5/18 Neil Williams :
> > There's a big difference between these bugs and the rest - here there
> > are clear migration paths to later packages which can be used to triage
> > the bug reports in order not to lose reports. A lot of the rest *can*
> > be closed without more triage work because the package was removed, not
> > replaced. e.g. gcc-4.4 bugs may be applicable with gcc-4.7 and need to
> > be triaged. The opensync/multisync bugs just had to be closed without
> > even looking at any of them.
> 
> Yes, I fully agree with that for the packages-removed-for-good.
> 
> The thing is that a big % of the initial bugs (1500+ when I brought
> this up, 1200+ now) is made up of the "gcc like" cases: gcc, emacs,
> linux, libdb, python2.4, various java stuff, tomcat5.5...
> 
> I don't know if they're 30, 50 or 80%, but definitely there is a big
> amount of real bugs still related to current software shipped in
> Debian.
> 
> Another question, perhaps unrelated is, what happens with the bugs
> closed from egroupware or salome (removed from unstable/testing but
> still present in stable releases) when their users look for them in
> the BTS?  They would be closed and archived, I suppose, and users of
> stable wouldn't be able to find them easily -- and them maybe report
> them again.

According to [1] salome is not part of any debian release now. Did I miss 
something? IIRW, for package still in stable, if the -done mail contains the 
right version then the bug will still be visible as long as it affects stable.

[1] http://packages.qa.debian.org/s/salome.html

> 
> So at the moment I left those bugs alone.  I assume that they will be
> autodeleted by some process when they're not present in stable
> anymore, but perhaps are wrong and that's why there are such high
> number of orphan bugs.
> 
> 
> Cheers.

Cheers.


signature.asc
Description: This is a digitally signed message part.

Re: What to do with bug reports against non-existing/removed packages

[Manuel A. Fernandez Montecelo]

2012/5/18 Neil Williams :
> There's a big difference between these bugs and the rest - here there
> are clear migration paths to later packages which can be used to triage
> the bug reports in order not to lose reports. A lot of the rest *can*
> be closed without more triage work because the package was removed, not
> replaced. e.g. gcc-4.4 bugs may be applicable with gcc-4.7 and need to
> be triaged. The opensync/multisync bugs just had to be closed without
> even looking at any of them.

Yes, I fully agree with that for the packages-removed-for-good.

The thing is that a big % of the initial bugs (1500+ when I brought
this up, 1200+ now) is made up of the "gcc like" cases: gcc, emacs,
linux, libdb, python2.4, various java stuff, tomcat5.5...

I don't know if they're 30, 50 or 80%, but definitely there is a big
amount of real bugs still related to current software shipped in
Debian.

Another question, perhaps unrelated is, what happens with the bugs
closed from egroupware or salome (removed from unstable/testing but
still present in stable releases) when their users look for them in
the BTS?  They would be closed and archived, I suppose, and users of
stable wouldn't be able to find them easily -- and them maybe report
them again.

So at the moment I left those bugs alone.  I assume that they will be
autodeleted by some process when they're not present in stable
anymore, but perhaps are wrong and that's why there are such high
number of orphan bugs.


Cheers.


-- 
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/capq4b8nh+urvcoyz10vpahavoataw5em_1n6y2n-utdpmje...@mail.gmail.com

Re: What to do with bug reports against non-existing/removed packages

[Neil Williams]

On Fri, 18 May 2012 14:34:40 +0100
"Manuel A. Fernandez Montecelo"  wrote:

> Hi,
> 
> 2012/5/18 Daniel Leidert :
> > Hi,
> >
> > Our bug tracker contains items for packages, which do (not longer) exist. 
> > What should happen to them? I see, that it might be a good idea to keep 
> > them for the case, a package is re-introduced. But this might happen only 
> > for a few packages. Most of them got removed because newer versions were 
> > released. What about closing those reports, if an RM-request is filed?
> >
> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=
> 
> As others have said, I asked the question only a few weeks ago:
> 
>   http://lists.debian.org/debian-devel/2012/03/msg00946.html
> 
> Reassigning 300 bugs from emacsX (X<23) to current emacs packages is
> not very helpful, really.  What I did is to notify the maintainers (or
> related mailing lists) of the three biggest groups (linux, gcc, emacs)
> to decide what to do.

There's a big difference between these bugs and the rest - here there
are clear migration paths to later packages which can be used to triage
the bug reports in order not to lose reports. A lot of the rest *can*
be closed without more triage work because the package was removed, not
replaced. e.g. gcc-4.4 bugs may be applicable with gcc-4.7 and need to
be triaged. The opensync/multisync bugs just had to be closed without
even looking at any of them.

Identifying this subset (which could be quite large) which apply only
to packages which have no appropriate replacement packages would be a
very useful QA step and dramatically improve the total number of bugs
in this situation.

Simplest safeguard here is to ensure that the list of bugs closed in
this way is fed back to a comment in the original bug report against
ftp.debian.org which got the package removed in the first place and
which is the permanent record of the removal.

> Don't know what to suggest, really, but it's a shame that some very
> helpful bug reports are lost in this process for Debian.  The are many
> good bug reports about GCC, e.g. incorrect optimisations or wrong code
> in some architectures that were closed so close as 1 month ago (so
> they are not part of 4.7, they will be in 4.8), and which were
> reported in Debian (and forwarded upstream by Debian maintainers) many
> many years ago.  Some similar ones reported years ago are still not
> forwarded, but I haven't yet handled them to see if they are valid,
> reproducible or what (#448370, #470557).
> 
> So I wouldn't blindly close those bug reports, and that's why I'm
> triaging and handling them in my spare time.

Where there are replacement packages, there is work to do. Otherwise,
the bugs need to be closed. The very small number of packages which get
re-introduced after ftpmaster removal don't merit special treatment in
this regard - as long as when the orphaned bugs are closed, some
mention is made of the bug numbers in the bug report at ftp.debian.org.

(If ftp.debian.org gets removed we will have larger problems, or no
problems at all, depending on your perspective.)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpeomPNC6faJ.pgp
Description: PGP signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Bernhard R. Link]

* Adam Borowski  [120518 11:37]:
> You complain about forcing people to use git, while you push quilt onto
> everyone else.
> [...]
>
> I really wish there was a "3.0" format besides "3.0 (quilt)", so people are
> not mislead into thinking they have to (or even, would gain anything) from
> writing patches in quilt's format.

Noone is forcing quilt on anyone.

We need a source format that can properly represent changes to the
upstream source code and that is best done as some series of patches.
Using a format that is a subset of quilt without all the magic makes
sense as that makes it easy for anyone to write or read.
(It's just a set of patches to be applied with -p1 and a file to list
the names of those patches line by line, i.e. no special sort algorithm
for filesnames needs to be defined).

One of the biggest faults of "3.0 (quilt)" is its name. It should really
have been called "3.0 (patches)" or even better "3.0 (non-native)".

A proper package should either have no upstream changes or broken down
changeset that can actually be applied. If you have those changes it is
trivial to create a "3.0 (quilt)" source package out of that.

And yes, git is the better quilt for managing a source tree. Which is
why I use it exclusively to work on my "3.0 (quilt)" packages.

Bernhard R. Link


-- 
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/20120518145644.gb2...@client.brlink.eu

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Michal Suchanek]

FWIW

posted on the wiki: http://wiki.debian.org/RepositoryFormat

Thanks

Michal


-- 
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/1337349939-sup-8...@virtual.ruk.cuni.cz

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Henrique de Moraes Holschuh]

On Fri, 18 May 2012, Adam Borowski wrote:
> On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote:
> > On Fri, 18 May 2012 11:37:08 +0200
> > Adam Borowski  wrote:
> > > Quilt is a kind of really primitive VCS.  It does not make sense to
> > > use both it and a modern one, and when someone tries,
> > 
> > I'm sorry to disappoint you, but quilt isn't a VCS at all. It's a patch
> > queue management system, and it does its job well. And, by the way, git
> > can't do it better at the moment as guilt seems to be dead, and stgit
> > is buggy (mq in mercurial is better than quilt, but we speak of git
> > atm).
> 
> What would you need guilt or stgit for?  Various invocations of git-rebase
> can already do all of that.  -i in particular can do most of that in an
> user-friendly way.

You rebase, that branch is crap that cannot possibly be used by others in
any way that is not (1) error-prone; (2) annoying; (3) at least as
troublesome as quilt (IMHO it is much worse than quilt).  Have you ever been
downstream from someone that publishes branches that are rebased all the
time?

But yes, git is *MUCH* better at merging than patch, which would be the
reason why I work on development of patch-based deliverables (anything for
the Linux kernel, and anything that is supposed to make its way upstream)
using the latest development shapshot of stgit instead of quilt.

When it is time to release/upload, the branch gets git format-patch'd, and
makes its way to debian/patches for 3.0(quilt) to handle.  That branch is
never published.  git-pq can automate this stuff in an even better way that
is rebase-less if you want, but I don't bother.

> I'm sorry but I fail to see any core differences between quilt and a series
> of patches rebased on top of the latest upstream tag.  Except that git's

3.0(quilt) doesn't need a full git repository to actually be manipulated.
Since we cannot use 3.0(git) with the full git repository in Debian, IMO
that makes 3.0(git) useless if you're going to use it like that.

You're free to propose that we change the way 3.0(git) is supposed to be
used, and maybe that will require a 3.1(git), or maybe not.  That's probably
where we'll get some value out of this necrotic thread.  Damn, I hate the
stink of dead horse corpses...

It would certainly be possible to define that all that can go in the git
repository is the snapshots uploaded to Debian/Ubuntu.  That DOES mean you
CANNOT use git directly with the upstream repository, you'll need to
transport changes using git format-patch and git-am, or maybe git
cherry-pick from a remote.  I think this will actually be worse for people
to understand than 3.0(quilt), but it does have the advantage that you will
be using git instead of quilt to manipulate the changes.   We'd need a
procedure to deal with uploads fixing "cannot be distributed, but it was"
problems, and THAT will require rewriting history to get rid of the
offending data.  Which is rather nasty, but doable.

> A rebased series is just one way to work with git, but it alone can do
> everything quilt can.

Indeed.  But shallow clones are not the way (we've debated this already on
a huge technical thread, at least twice).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120518140907.ge...@khazad-dum.debian.net

Re: switching from exim to postfix

[Henrique de Moraes Holschuh]

On Thu, 17 May 2012, Thomas Goirand wrote:
> On 05/03/2012 07:23 AM, Henrique de Moraes Holschuh wrote:
> > Well, FWIW postfix allows you to override all MTA notifications, not just
> > bounce messages, but the full set.  We do that at work.
> >   
> Interesting. Can you post an example here?

man bounce(8postfix).  You need recent postfix, so that means backports,
testing or unstable.

We keep the original text in english at the bottom, but add text in
portuguese on top.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120518134839.gd...@khazad-dum.debian.net

Re: What to do with bug reports against non-existing/removed packages

[Manuel A. Fernandez Montecelo]

Hi,

2012/5/18 Daniel Leidert :
> Hi,
>
> Our bug tracker contains items for packages, which do (not longer) exist. 
> What should happen to them? I see, that it might be a good idea to keep them 
> for the case, a package is re-introduced. But this might happen only for a 
> few packages. Most of them got removed because newer versions were released. 
> What about closing those reports, if an RM-request is filed?
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=

As others have said, I asked the question only a few weeks ago:

  http://lists.debian.org/debian-devel/2012/03/msg00946.html

Reassigning 300 bugs from emacsX (X<23) to current emacs packages is
not very helpful, really.  What I did is to notify the maintainers (or
related mailing lists) of the three biggest groups (linux, gcc, emacs)
to decide what to do.

Ben Hutchings took care of the ones of the kernel, I'm especially
focusing on the ones of GCC right now (trying to reproduce, closing or
reassigning when appropriate), and the same with emacs ones (but I did
only one session of those or so, closing some tagged fixed-upstream).
I also handled other reports here and there from other packages.

I'm thinking that the "fix one orphan bug before posting to
debian-devel@ flame threads" would be helpful here :-)

Don't know what to suggest, really, but it's a shame that some very
helpful bug reports are lost in this process for Debian.  The are many
good bug reports about GCC, e.g. incorrect optimisations or wrong code
in some architectures that were closed so close as 1 month ago (so
they are not part of 4.7, they will be in 4.8), and which were
reported in Debian (and forwarded upstream by Debian maintainers) many
many years ago.  Some similar ones reported years ago are still not
forwarded, but I haven't yet handled them to see if they are valid,
reproducible or what (#448370, #470557).

So I wouldn't blindly close those bug reports, and that's why I'm
triaging and handling them in my spare time.

Cheers.


--
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/CAPQ4b8mZzsSt=mfgko-3jsqtvsprd7kay57vwkdvktgvfnh...@mail.gmail.com

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Julian Andres Klode]

On Fri, May 18, 2012 at 01:38:40PM +0200, Julian Andres Klode wrote:
> I do not think that APT is responsible for the repository format. The
> repository format is defined by ftpmaster, not by APT. APT has to my
> knowledge not defined anything new, but only implemented changes to
> the repository format after they were introduced by ftpmaster (see
> InRelease files).

OK, we actually do have some more extensions not used by Debian or
Ubuntu. One of those is the "Important: yes" field, which is like
Essential, but does not force installation of the package like
Essential would do (and does not force immediate configuration
nowadays, so that we can use it for custom meta packages [so
that users cannot accidentally remove the meta package that
configures the complete system]).

I don't know of any other extensions, though. In any case,
they should probably not be part of an official specification,
but rather documented in APT.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


-- 
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/20120518144739.ga21...@debian.org

Re: debuild/dpkg-buildpackage behaves not as expected

[Olе Streicher]

Goswin von Brederlow  writes:
> debian-de...@liska.ath.cx (Olе Streicher) writes:
>> James McCoy  writes:
>>> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
 Unpatching the sources *before* the build process was cleaned up makes
 no sense to me at all. Could you provide a use case for that?
>>> As was described in #649531:
>>>
>>>   vcs clone 
>>>   cd repo
>>>   ... tweak a little ...
>>>   dpkg-buildpackage; # applies patches, builds, and unapplies patches
>>>   vcs diff; # looks good?
>>>   vcs commit
>>
>> This works only for the special case that "build" does not change any
>> source file. Otherwise you would also commit the changed source files.
>
> And it better not. There is no excuse for changing source files during
> build. 

Welcome to reality. Usually, "configure" scripts are distributed with
(upstream) source on purpose (since they shall provide an easy adoption
to the current enviroment without the need of additional packages), but
they are going to be changed during the packaging.

Another examples are convienence copies of generated files from a parser
generator. Or, sometimes Makefiles are going to be *changed* (not even
regenerated!) by adding/changing dependencies at their end.

Would you really require for all packages using autoconf that they
repackage upstream source in order to get rid of the regenerated files?
And how would you handle the case that a "Makefile" gets a system
dependent dependency extension?

> If you need to change a file then that means that file isn't source
> anymore but generated. Try switching to out-of-tree builds if you have
> something like that.

What is the advantage of that? From the Debian policy, I don't see a
need why sources should kept untouched during the build process.

>> "patch" was meant as a target that *applies* the patches. Therefore,
>> it does not leave the sources in the same state (since it applies the
>> patches).

> I ment: It leaves the source in the same state it found it other than
> the side effects the called target(s) have themself.

Why would you need to have a local "patch" target? If it is somehow
generally useful, it should be common to all packages -- and than it
could just be builtin as an option into dpkg-buildpackage. Or just use
quilt directly.

> My main point, which I didn't explicitly state, is this:
>
> The way debuild/dpkg-buildpackage/dpkg-source currently behave allow
> maintainers to modify the behaviour by adding something to
> debian/rules. If the clean target needs the patches applied then
> debian/rules can easily make sure that they are.

Since "clean" usually calls the upstream cleanup, its work depends on
whether the upstream cleanup would actually work on the unchanged
package. Trying to apply the "clean" target from the unpatched source on
a directory that is built by the patched source seems to me buggy by
design and just works on accident.

> On the other hand if the clean target doesn't need the patches applied,
> as is the case for 99.9% of all packages then applying them would be
> wastefull.

It is just the better design: the package was built with a patched
source, so only the patched version knows for sure how to clean it up. 

> Personaly I try to set up all my packages in such a way that clean or
> no clean I can simply commit changes. That means that the build MUST
> not modify any source files (which is simply evil to begin with) and
> that you add a bunch of stuff to the ignore file (e.g. debian/files,
> debian//, debian/*.debhelper.log, debian/*.substvars, stamp
> files, ...). That is something you do once and after that clean or no
> clean you can simply commit. But that requires that patches are
> unapplied after build (unapply-patches in debian/source/local-options
> to enforce this).

It does not, as long as you commit just the debian/ subdirectory. Since
*all* changes you make are in this directory, I don't see why this is a
limitation. 

Best regards

Ole

P.S. Would you please not Cc: me as long as you reply to the list?



-- 
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/87txzdlkiv@news.ole.ath.cx

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Roger Leigh]

On Fri, May 18, 2012 at 01:27:50PM +0200, Adam Borowski wrote:
> On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
> > Charles Plessy  writes:
> > 
> > > Also, it is very sad that, as a project, we can not decide whether we go
> > > for 3.0 (git) or not, or have a concrete list of resolvable objections
> > > from the people whose work is direclty impacted by the use of this
> > > format.
> > 
> > We know what a primary concrete objection is.  We discussed it at length
> > at DebConf two years ago, and then on debian-devel afterwards.  Uploading
> > a Git archive requires reviewing the entire contents of the archive, not
> > just the current code, for licensing issues, which is pretty painful from
> > the ftp-master perspective.
> 
> How come?  If the .git directory shipped in the package is pruned, there is
> no hidden data.  All you have to review are commits that are present there,
> which is exactly the same as with quilt: you need to review the tarball and
> every single patch.

I think this is a key point.  The aim of the git format should not be
provide the entire history, any more than the other formats do (not).

What should be provided needs to be
- sufficient to build the package
- sufficient to determine the changes made between the Upstream
  release and the Debian upload
- sufficient to allow further uploads, including NMUs
- (allow restoration of the full history)

> > There was never really a satisfactory resolution to that discussion.  We
> > can upload very shallow clones, but they end up looking a lot like the
> > existing quilt format with single-debian-patch,
> 
> There's a whole world between shallow clones and complete ones.  While
> existing git porcelain provides no convenient tools to selectively
> shallowify a repository, this is because no one had that need before.
> 
> If we allow non-linear Debian changes (ie, merged not rebased, etc), there
> is indeed a complex question: where to cut[2].  But even then, a given commit
> is either present or not.  If too much old history is there, that's no
> different from the upstream shipping an old tarball and a pile of patches
> upon it (like ancient apache or qmail).

If the git repo contain two tags, maybe signed, one which uniquely
referenced the upstream version, and one which referenced the debian
version, then all commits not part of the graph between these two
commits could be dropped.  This would preserve all history of
branching and merging between these two points.  Tools used for
importing upstream tarballs could automatically create such tags;
native git projects can do this themselves.  These tags could be
put in the .dsc, so that projects can use their own naming rules,
or dpkg-source could use a specific method. [As an upstream who uses
signed tags for all releases, the flexibility to use the project-
specific tags would be useful.]

dak could check that the upstream tag referenced the same commit
between uploads, as well as maybe also verifying the tag signature.
This would ensure that the upstream source couldn't be altered in
an upload, the same as is enforced for orig.tar right now.
dak could also check the debian tag if required; though the .dsc
signature would presumably be sufficient, signed tag verification
would be useful for a potential git-only workflow in the future.

Providing that the packaged repo contains links to the public
git repo, and we can get this from debian/control (in case the
developer is using a private or git+ssh repo), the end user
should be able to do a simple "git fetch origin" to restore the
full history.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120518124912.gi22...@codelibre.net

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Julian Andres Klode]

On Fri, May 18, 2012 at 01:38:40PM +0200, Julian Andres Klode wrote:
> On Fri, May 18, 2012 at 12:02:47PM +0100, Ian Jackson wrote:
> > CC'ing the apt list de...@lists.debian.org.
> > 
> > Goswin von Brederlow writes ("Re: Bug#481129: Bug#671503: general: APT 
> > repository format is not documented"):
> > > Michal Suchanek  writes:
> > > > [ discussions regarding documenting the apt repository format ]
> > > 
> > > I would suggest you look at existing repositories, whatever scraps of
> > > information is in the manuals and maybe a bit at the source and start to
> > > write a documentation. Once you have that offer it for review and other
> > > people can pitch in their bits of knowledge. Getting the current format
> > > documented right shouldn't be that hard if someone just starts.
> > 
> > Right.
> > 
> > > And once such a document exists it is much easier to get people do
> > > document changes or hit them over the head if they don't.
> > 
> > Can the apt maintainers confirm that once such a document exists, they
> > will insist that future contributions to apt which change the
> > repository format update the document ?
> > 
> > What form do the apt maintainers think the document should take ?
> > Should it eventually be in the apt source package or somewhere else ?
> 
> I do not think that APT is responsible for the repository format. The
> repository format is defined by ftpmaster, not by APT. APT has to my
> knowledge not defined anything new, but only implemented changes to
> the repository format after they were introduced by ftpmaster (see
> InRelease files).
> 
> We currently have three independent implementations of the repository
> format in the archive: APT, cupt, smartpm. Furthermore, tools like
> debian-cd probably also have some knowledge about the repository
> format.
> 
> The repository format should thus be part of Policy, not part of
> APT. APT is one of the users of that format, not the one defining
> it (it might just get stricter in behavior from time to time, just
> like compilers). Changes to the format should require approval of
> ftpmaster, as they have to implement them on the server-side.
> 

A working draft could be something like the following. It mostly
describes the current format for Release, Packages, and Sources
files. It's thus missing Contents and Translations, pdiffs, and
stuff, but it's a beginning.

It specifies different requirements for servers and clients,
in order to have clients be backwards compatible with more
repositories, and forcing servers to be stricter. Don't know
how good that is, though.



= Debian Repository Format =


This documents a subset of the Debian repository format. This is a work
in progress.

"Release" files
===
The file "dists/$DIST/Release" shall contain meta-information about the
distribution and checksums for the indices. The file "dists/$DIST/Release.gpg"
shall be an GPG signature of the "Release" file, compatible with the format
used by the GPG options "-a -b -s". The file "dists/$DIST/InRelease" shall be
the "Release" file with a GPG clearsign signature  compatible with the format
used by the GPG options "-a -s --clearsign".

The following fields might be available:

- Origin
- Label
- Suite
- Codename
- Date
- Valid-Until
- Architectures
- Components
- Description
- MD5sum, SHA1, SHA256
- NotAutomatic and ButAutomaticUpgrades

Servers shall provide the Release file, and its signed counterparts with at
least the following keys:

- SHA256
- Origin
- Suite and/or Codename
- Architectures

Clients shall accept missing Release files, and Release files without the
fields required for servers. They might reject Release files that do not
contain at least one of the fields defined herein.

Architectures
-
Whitespace separated unique single words identifying Debian machine 
architectures
as described in Architecture specification strings, Section 11.1.

Origin
--
Shall indicate the origin of the repository.

Label
-
Optional field including some kind of label.

Suite
-
The Suite field shall describe the suite. In Debian, this shall be one of
oldstable, stable, testing, unstable, or experimental; with optional suffixes
separated by "-" (such as "stable-updates").

Codename

The Suite field shall describe the codename of the release. This is mostly
a free-form string used to give a name to a release.

Date, Valid-Until
-
The Date field shall specify the time at which the Release file was created. The
Valid-Until field shall specify at which time the Release file should be
considered expired by the client. Client behaviour on expired Release files
is unspecified.

Components
---
A whitespace separated list of areas.

Example:
Components: main contrib non-free

MD5sum, SHA1, SHA256

Those fields shall b

Enforce clean before unpatch (was: Re: debuild/dpkg-buildpackage behaves not as expected)

[Thibaut Paumard]

Hi,

Le 18/05/12 13:46, Goswin von Brederlow a écrit :
>> This works only for the special case that "build" does not change any
>> source file. Otherwise you would also commit the changed source files.
> 
> And it better not. There is no excuse for changing source files during
> build. If you need to change a file then that means that file isn't
> source anymore but generated. Try switching to out-of-tree builds if you
> have something like that.

In an ideal world, every file should be either source or generated.
Unfortunately in the real world some build systems modify some "source"
files. Even though, from our point of view, it would be best to get
upstream fixing this, this is not a reasonable assumption to think that
we can force them to.

Policy states that clean must revert any changes made during build, but
no policy states that no source file must be modified during build.

This is therefore not a reasonable assumption to expect that you can
unpatch before cleaning in the general case.

[...]

> I ment: It leaves the source in the same state it found it other than
> the side effects the called target(s) have themself.

And it's the role of the clean target to revert the changes introduced
by the "build" and "binary" targets...

> [...]
> My main point, which I didn't explicitly state, is this:
> 
> The way debuild/dpkg-buildpackage/dpkg-source currently behave allow
> maintainers to modify the behaviour by adding something to
> debian/rules. If the clean target needs the patches applied then
> debian/rules can easily make sure that they are.

Tanks, that's certainly the point: Ole and I must have missed the
documentation on this feature. Is it sufficient to make the clean target
depend on "patch"?

It's also possible that we simply have to dump a line in
debian/source/option to get the "-tc" option by default. Any pointer to
the right option would be welcome. I did look for it, but then: I can't
even find the butter in the fridge :-)

> [...] That means that the build MUST not
> modify any source files (which is simply evil to begin with) 

"Evil" is part of this world.

> [...]

Regards, Thibaut.


-- 
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/4fb64390.8040...@free.fr

Re: Wheezy release: CDs are not big enough any more...

[Wookey]

+++ Mehdi Dogguy [2012-05-16 16:24 +0200]:
> On 16/05/12 13:41, Wookey wrote:
> >is there any reason not to just upload this to Debian?
> 
> There are ITPs filed for it:
> - http://bugs.debian.org/582884
> - http://bugs.debian.org/576359

Yes. I discovered that when I went to file an ITP :-)

It turns out that there is a problem preventing upload. The rather
generic name 'usb-creator' was objected-to and a request made to
change it to 'startup-disk-creator' (The name the app shows).

Upload seems to be stalled on changing the name of the launchpad
project to give matching source and binary names. This seems
well-meaning but has the unfortunate effect that nothign has happened
for a year, despite several people expressing an interst in uploading.

I also tested it with a debian installer image and found that it is
bust due to a load of ugly code dealing with the syslinux transition
from 2.3x to 2.4x around Ubuntu 10.04->10.10 (generating old images
whilst running on a new machine, and vice versa, different package and
different syntax). It blows up on debian due to 'GNU/Linux' not being
a valid version. As we don't even have syslinux-legacy in Debian all
this mess should probably just be thrown away.
https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1000527

My python-foo wasn't up to actually fixing it myself. Nor do I know
how important it is to keep this sort of old-release compatibility
(how old?).

Anyone with the enthusiasm to fix the upstream-renaming thing, or this
code (not hard, just fiddly) could get this into Debian promptly I
think. 

Wookey


-- 
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/20120518121724.gu11...@stoneboat.aleph1.co.uk

Re: What to do with bug reports against non-existing/removed packages

[Goswin von Brederlow]

"Daniel Leidert"  writes:

> Hi,
>
> Our bug tracker contains items for packages, which do (not longer) exist. 
> What should happen to them? I see, that it might be a good idea to keep them 
> for the case, a package is re-introduced. But this might happen only for a 
> few packages. Most of them got removed because newer versions were released. 
> What about closing those reports, if an RM-request is filed?
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=
>
> Regards, Daniel

I think for binary packages the bugs should be reassigned to (or at least
keep showing up for) the source package.

For the rest see other replies.

MfG
Goswin


-- 
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/87wr49k8q0.fsf@frosties.localnet

Re: on the use of chmod/chown in maintainer scripts

[Goswin von Brederlow]

Roger Leigh  writes:

> On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote:
>> That just leaves the question of wether dpkg uses uid/gid or symbolic
>> names when unpacking debs.
>
> I think this one is clear: it must be symbolic since the uids/gids
> aren't static.  Unless you want to provide a package-specific
> mapping in the control data, and I can't see that gains much, since
> it makes unpacking unnecessarily complex.  If it's symbolic, you
> simply just extract it.

Full ACK on symbolic. The question is what dpkg currently does. Do we
need to fix dpkg or is dpkg already ready for this?

MfG
Goswin


-- 
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/871umhlneo.fsf@frosties.localnet

Re: debuild/dpkg-buildpackage behaves not as expected

[Goswin von Brederlow]

debian-de...@liska.ath.cx (Olе Streicher) writes:

> James McCoy  writes:
>> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
>>> Unpatching the sources *before* the build process was cleaned up makes
>>> no sense to me at all. Could you provide a use case for that?
>> As was described in #649531:
>>
>>   vcs clone 
>>   cd repo
>>   ... tweak a little ...
>>   dpkg-buildpackage; # applies patches, builds, and unapplies patches
>>   vcs diff; # looks good?
>>   vcs commit
>
> This works only for the special case that "build" does not change any
> source file. Otherwise you would also commit the changed source files.

And it better not. There is no excuse for changing source files during
build. If you need to change a file then that means that file isn't
source anymore but generated. Try switching to out-of-tree builds if you
have something like that.

> Since for Debian you have only changes in the debian/ subdirectory, you
> may do the following:
>
> vcs clone 
> cd repo
>  tweak a little ...
> dpkg-buildpackage; # applies patches, builds, and unapplies patches
> vcs diff debian
> vcs commit debian
>
> this does not require unpatching, since it commits only the "debian"
> subdirectory, which is not affected by any patches.
>
> Therefore, I don't see that the workflow you mentioned is a use case
> that would require unpatching.
>
> [Quoting restored: Goswin wrote]
 What happens if you now call
 debuild patch
 to apply the patches in a 3.0 (quilt) package that has patch/unpatch
 targets?
>
>>> because it does *not* leave the sources in the same state.
>
>> Yes, it does.  
>
> He wrote it himself: "patch" was meant as a target that *applies* the
> patches. Therefore, it does not leave the sources in the same state
> (since it applies the patches).

I ment: It leaves the source in the same state it found it other than
the side effects the called target(s) have themself.

>> If you started with patches applied, then they will still be applied
>> after calling "dpkg-buildpackage".  If you didn't have patches
>> applied, then "dpkg-buildpackage" will apply the patches, build and
>> unapply the patches.
>
> We discussed the "debuild patch" option here which was introduced by
> Goswin. 
>
> Best
>
> Ole

My main point, which I didn't explicitly state, is this:

The way debuild/dpkg-buildpackage/dpkg-source currently behave allow
maintainers to modify the behaviour by adding something to
debian/rules. If the clean target needs the patches applied then
debian/rules can easily make sure that they are.

On the other hand if the clean target doesn't need the patches applied,
as is the case for 99.9% of all packages then applying them would be
wastefull.


Personaly I try to set up all my packages in such a way that clean or no
clean I can simply commit changes. That means that the build MUST not
modify any source files (which is simply evil to begin with) and that
you add a bunch of stuff to the ignore file (e.g. debian/files,
debian//, debian/*.debhelper.log, debian/*.substvars, stamp files,
...). That is something you do once and after that clean or no clean you
can simply commit. But that requires that patches are unapplied after
build (unapply-patches in debian/source/local-options to enforce
this). I usualy never call clean directly so the above problem can't
even arise.

MfG
Goswin


-- 
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/8762btlniv.fsf@frosties.localnet

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Adam Borowski]

On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote:
> On Fri, 18 May 2012 11:37:08 +0200
> Adam Borowski  wrote:
> > Quilt is a kind of really primitive VCS.  It does not make sense to
> > use both it and a modern one, and when someone tries,
> 
> I'm sorry to disappoint you, but quilt isn't a VCS at all. It's a patch
> queue management system, and it does its job well. And, by the way, git
> can't do it better at the moment as guilt seems to be dead, and stgit
> is buggy (mq in mercurial is better than quilt, but we speak of git
> atm).

What would you need guilt or stgit for?  Various invocations of git-rebase
can already do all of that.  -i in particular can do most of that in an
user-friendly way.

> Keeping patches in git makes thing less transparent and more
> complicated. You have to inspect all the history just to find out what
> changes did maintainer do to the original source.

I'm sorry but I fail to see any core differences between quilt and a series
of patches rebased on top of the latest upstream tag.  Except that git's
porcelain has better tools to do that -- just recall recent complains about
unfuzzying patches.  Git will do a 3-way merge during rebasing, which is
more powerful than just copying a patch over as it has more context
(especially, old context vs new context) to work with.

A rebased series is just one way to work with git, but it alone can do
everything quilt can.

> And, of course, you need to have a clone of the repo.

A semi-shallow clone of [upstream_tag .. HEAD] ships exactly as much as
tarball + quilt series.

-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon


signature.asc
Description: Digital signature

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Julian Andres Klode]

On Fri, May 18, 2012 at 12:02:47PM +0100, Ian Jackson wrote:
> CC'ing the apt list de...@lists.debian.org.
> 
> Goswin von Brederlow writes ("Re: Bug#481129: Bug#671503: general: APT 
> repository format is not documented"):
> > Michal Suchanek  writes:
> > > [ discussions regarding documenting the apt repository format ]
> > 
> > I would suggest you look at existing repositories, whatever scraps of
> > information is in the manuals and maybe a bit at the source and start to
> > write a documentation. Once you have that offer it for review and other
> > people can pitch in their bits of knowledge. Getting the current format
> > documented right shouldn't be that hard if someone just starts.
> 
> Right.
> 
> > And once such a document exists it is much easier to get people do
> > document changes or hit them over the head if they don't.
> 
> Can the apt maintainers confirm that once such a document exists, they
> will insist that future contributions to apt which change the
> repository format update the document ?
> 
> What form do the apt maintainers think the document should take ?
> Should it eventually be in the apt source package or somewhere else ?

I do not think that APT is responsible for the repository format. The
repository format is defined by ftpmaster, not by APT. APT has to my
knowledge not defined anything new, but only implemented changes to
the repository format after they were introduced by ftpmaster (see
InRelease files).

We currently have three independent implementations of the repository
format in the archive: APT, cupt, smartpm. Furthermore, tools like
debian-cd probably also have some knowledge about the repository
format.

The repository format should thus be part of Policy, not part of
APT. APT is one of the users of that format, not the one defining
it (it might just get stricter in behavior from time to time, just
like compilers). Changes to the format should require approval of
ftpmaster, as they have to implement them on the server-side.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.



pgpWPZByoczjc.pgp
Description: PGP signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Goswin von Brederlow]

Chris Knadle  writes:

> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
>> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> > > No, I hereby start saying good by to 3.0
>> > 
>> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
>> > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
>> > few packages.
>> 
>> I can't see any reason to use 1.0 anymore, ever.
>> 
>> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
>> has a number of upsides.  And working around quilt is simple:
>> 
>> echo "single-debian-patch" >debian/source/options
>> echo "/.pc" >>.gitignore
>> echo "/debian/patches" >>.gitignore
>
> I'm confused concerning the above; the point of a VCS in this context is to 
> track changes to the source package, and the patches are themselves important 
> changes to the source package.  If you have Git ignore the patches then Git 
> doesn't have a complete view of the source package anymore.  Why would you 
> want to do that?

You're source VCS would be with the patches applied already. When
building the source package dpkg-source will simply create
debian/patches/debian-changes as the diff between your working directory
and the orig tarball every time. Same as it did create a diff.gz file
with 1.0 format.

>> and perhaps "rm -rf .pc debian/patches" in the clean target if those bother
>> you -- and you have all the goodies that come with the 3.0 format, with
>> getting none of quilt brain damage onto you.  Suddenly, nothing conflicts
>> with the VCS you're using, nothing breaks bisects, nothing causes spurious
>> recompiles, etc.
>> 
>> Except for nuking upstream debian/ dir which can mean a bit of lost work if
>> the upstream is sane (and can save some if they're not), the 3.0 format is
>> strictly better than 1.0.
>
> If debian/ is nuked then so is debian/patches, and if Git has been told to 
> ignore debian/patches then it cannot bring those files back.  Patching the 
> source can be an effort especially concerning documenting why the patches 
> were 
> done and the source of the patches, so these seem like they'd be important to 
> track rather than something to ignore.

Small misunderstanding here.

If you have a 1.0 format package that contains debian/ in the orig
tarball then the diff.gz will contain only the changes to the debian
dir.

In 3.0 (quilt) the debian dir is ignored when unpacking an orig tarball
and the debian tarball contains the full debian dir. The benefit is that
you do no longer need to repack the orig tarball to remove files from
the debian dir and changes upstream does to the debian dir are
ignored. The drawback is that changes upstream does to the debian dir
are ignored.

MfG
Goswin


-- 
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/87aa15lodn.fsf@frosties.localnet

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Adam Borowski]

On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
> Charles Plessy  writes:
> 
> > Also, it is very sad that, as a project, we can not decide whether we go
> > for 3.0 (git) or not, or have a concrete list of resolvable objections
> > from the people whose work is direclty impacted by the use of this
> > format.
> 
> We know what a primary concrete objection is.  We discussed it at length
> at DebConf two years ago, and then on debian-devel afterwards.  Uploading
> a Git archive requires reviewing the entire contents of the archive, not
> just the current code, for licensing issues, which is pretty painful from
> the ftp-master perspective.

How come?  If the .git directory shipped in the package is pruned, there is
no hidden data.  All you have to review are commits that are present there,
which is exactly the same as with quilt: you need to review the tarball and
every single patch.

> There was never really a satisfactory resolution to that discussion.  We
> can upload very shallow clones, but they end up looking a lot like the
> existing quilt format with single-debian-patch,

There's a whole world between shallow clones and complete ones.  While
existing git porcelain provides no convenient tools to selectively
shallowify a repository, this is because no one had that need before.

For example, if you limit yourself to a bunch of linear rebased commits atop
of the newest upstream tag, you can exactly emulate quilt workflow except
for not having to deal with quilt's peculiarities.  This goes to the point
of shipping EXACTLY the same data as quilt would, with only metadata
different[1].  And unlike what you say, commits are not flattened in any
way.

If we allow non-linear Debian changes (ie, merged not rebased, etc), there
is indeed a complex question: where to cut[2].  But even then, a given commit
is either present or not.  If too much old history is there, that's no
different from the upstream shipping an old tarball and a pile of patches
upon it (like ancient apache or qmail).

And besides, what's the reason behind enforcing exactly one upstream and
exactly one "Debian"?  This just leads to problems if either side has
multiple layers.

> and it's not horribly
> clear what the advantages of 3.0 (git) are at that point.  Many of the
> really compelling use cases for 3.0 (git), neat stuff like possibly being
> able to just push a signed tag instead of uploading or having the package
> history when you get the source package, aren't very interesting with
> shallow clones.

It's more a psychological issue: while you can use 3.0 (quilt) to emulate
1.0, people don't know about that.  Even though 6500 of packages in Debian
store their packaging in git, they typically fight with quilt, while that
shallow copy = single-debian-patch would at least remove that concern.


[1]. Git keeps references to commits not present in the shallow repository.
3.0 (quilt) in turn partially and inconsistently preserves timestamps, but
only on files that haven't been modified in any of the patches.  Also, the
tarball may ship an empty directory, device nodes, named pipes, etc --
again, only as long as no patch touches them.

[2]. One way: cut all commits which don't have one of current upstream
"tarballs" as an ancestor.  This can sometimes cut more than one would want,
but is strictly better than a shallow copy.

-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon


signature.asc
Description: Digital signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Goswin von Brederlow]

Jon Dowland  writes:

> On Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski wrote:
>> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
>> has a number of upsides.  And working around quilt is simple:
>> 
>> echo "single-debian-patch" >debian/source/options
>> echo "/.pc" >>.gitignore
>> echo "/debian/patches" >>.gitignore
>
> Thanks for the recipes for avoiding the quilt stuff; whilst still more work
> than "just use 1.0", but perhaps the advantages are indeed worth it. (Esp.
> in light of the talk re: xz compression.)

For me a huge advantage is that .hg and .git files are properly ignored
when building source packages. Not to mention multiple upstream
tarballs and support for adding binary files (think debian icon).

>> Except for nuking upstream debian/ dir which can mean a bit of lost work if
>> the upstream is sane (and can save some if they're not), the 3.0 format is
>> strictly better than 1.0.
>
> I had to go away and read up on the other things 3.0 brings to the table.
> Indeed they are nice-to-haves, which I am not benefiting from precisely 
> because
> they are presently only available in Debian via 3.0 (quilt).  This is a bit of
> a marketing fail for 3.0., in hindsight.

I think one large problem is that people don't know how to make 3.0
(quilt) format play nice with RCS systems and their own worflows. This
is something that has only evolved recently as more people have used 3.0
(quilt) format with their favourite RCS and workflow and the surrounding
tools have adapted.

MfG
Goswin


-- 
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/87ehqhlor2.fsf@frosties.localnet

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Ian Jackson]

CC'ing the apt list de...@lists.debian.org.

Goswin von Brederlow writes ("Re: Bug#481129: Bug#671503: general: APT 
repository format is not documented"):
> Michal Suchanek  writes:
> > [ discussions regarding documenting the apt repository format ]
> 
> I would suggest you look at existing repositories, whatever scraps of
> information is in the manuals and maybe a bit at the source and start to
> write a documentation. Once you have that offer it for review and other
> people can pitch in their bits of knowledge. Getting the current format
> documented right shouldn't be that hard if someone just starts.

Right.

> And once such a document exists it is much easier to get people do
> document changes or hit them over the head if they don't.

Can the apt maintainers confirm that once such a document exists, they
will insist that future contributions to apt which change the
repository format update the document ?

What form do the apt maintainers think the document should take ?
Should it eventually be in the apt source package or somewhere else ?

> Remember that you don't have to be 100% right in what you write. You
> only need to write a draft to start the process. Getting people to
> comment and correct any mistakes you simply don't know about is much
> much easier than getting someone else to write the whole thing.

Indeed so.

Thanks,
Ian.


-- 
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/20406.11351.808519.174...@chiark.greenend.org.uk

Re: What to do with bug reports against non-existing/removed packages

[Gergely Nagy]

"Daniel Leidert"  writes:

> Hi,
>
> Our bug tracker contains items for packages, which do (not longer)
> exist. What should happen to them? I see, that it might be a good idea
> to keep them for the case, a package is re-introduced. But this might
> happen only for a few packages. Most of them got removed because newer
> versions were released. What about closing those reports, if an
> RM-request is filed?

This is a hard task, as there's no simple set of rules that would apply
to all bugs. Some were filed against packages that existed at a time,
but got removed without the bug being closed (this often happens when
the source remains, it just stops building a particular binary
package). In this case, the bug should be examined, and either
reassigned if it still applies, or closed (preferably with a version) if
it does not.

Then there are the case of misfiled bugs: bugs filed against packages
that never existed, but were installed from a third party repository
(these should be closed with an appropriate message, urging the
submitter to either contact the third party repo's maintainer, or
upstream, whichever is more applicable); typos in package names, where a
reapply would be best; bugs against packages not yet in the archive (but
either in NEW, or in the archive, but so fresh its not known to the BTS
yet): these should be left alone most of the time, but in certain cases,
it might be a good idea to contact the maintainer, so he'll know about
these reports, as the BTS will not notify him when the package enters
the archive. If he doesn't check the BTS page, but relies on email, he
won't know about the reports.

There are probably a few other corner cases, but as you can see, it's
not simple. That's why the list is so long still. On and off, a few
people (myself included) try to shorten a bit, and so far, it seems we
can handle the newly misfiled bugs.

Any help with getting the backlog down to a much smaller number would be
greatly appreciated. Updating the wiki[1] with guidelines and HOWTOs on
how to handle specific cases would also be desirable, and I'm happy to
help with either.

 [1]: http://wiki.debian.org/Teams/unknown-package/TODO

-- 
|8]


-- 
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/87mx55n5ho.fsf@algernon.balabit

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Goswin von Brederlow]

Michal Suchanek  writes:

> Excerpts from Ian Jackson's message of Thu May 17 14:53:30 +0200 2012:
>> Michal Suchanek writes ("Re: Bug#671503: general: APT repository format is 
>> not documented"):
>> > Excerpts from Filipus Klutiero's message of Wed May 16 18:44:21 +0200 2012:
>> > > Could you clarify how this differs from #481129?
>> > 
>> > It's 4 years later.
>> > 
>> > Sorry, forgot that I filed the bug already. It's quite some time.
>> > 
>> > Given there is no feedback in 4 years I guess it is futile reporting
>> > this.
>> 
>> Well, it's useful to bring it up again.
>> 
>> > Admittedly there is no text in social contract about using
>> > Debian-proprietary formats. And a format only defined by "apt can read
>> > that" is definitely Debian-proprietary there is no better term for that.
>> 
>> Everyone agrees that it would be better if this were documented.
>> (I have struggled on occasion myself due to the lack of
>> documentation.)
>> 
>> But I think the use of the word "proprietary" is going too far.  It's
>> certainly a special Debian format, but that wouldn't be changed if it
>> were documented.  But it's not secret and we publish at least two
>> writer implementations and one reader implementation AFAIK, with
>> proper Free licences.
>
> However, it's easier to reverse-engineer  an existing repository than
> the source code so for all practical purposes it's the same as if it
> were closed source.
>
>> 
>> > I'd say it's slightly discriminatory against software not part of Debian
>> > that cannot rely on getting notified when "apt can read that" silently
>> > changes, there is no document defining what apt should be able to read
>> > that software authors can rely on to interoperate with apt, one of the
>> > core Debian tools. Apt in turn relies on open standards like HTTP and
>> > FTP to interoperate with the rest of the world.
>> 
>> I think this is not an appropriate use of the social contract or its
>> concepts.
>> 
>> Rather than complaining that this documentation doesn't exist, how
>> about writing the document yourself ?  It's not a trivial job but it
>> should be feasible by looking at the apt source code.
>
> For me it is not feasible at all.
>
> I can, of course, describe what current repositories look like or what
> the current apt code accepts.
>
> However, that has silently changed in the past and is considered apt
> feature, not a bug.
>
>> 
>> Once such a document exists, even if it's a bit sketchy or perhaps not
>> entirely accurate, it will be much easier to insist that future
>> changes are likewise documented.
>
> I am not so sure about that.
>
> So long as the document merely describes what apt happens to do at the
> moment rather than apt implementing what the document says there is no
> saying this document has any value.
>
> The status was 'documented' by existing repositories which stopped
> working.
>
> Thanks
>
> Michal

I would suggest you look at existing repositories, whatever scraps of
information is in the manuals and maybe a bit at the source and start to
write a documentation. Once you have that offer it for review and other
people can pitch in their bits of knowledge. Getting the current format
documented right shouldn't be that hard if someone just starts.

And once such a document exists it is much easier to get people do
document changes or hit them over the head if they don't.

Remember that you don't have to be 100% right in what you write. You
only need to write a draft to start the process. Getting people to
comment and correct any mistakes you simply don't know about is much
much easier than getting someone else to write the whole thing.

MfG
Goswin


-- 
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/87mx55lqbo.fsf@frosties.localnet

Re: Bug#481129: Bug#671503: general: APT repository format is not documented

[Michal Suchanek]

Excerpts from David Kalnischkies's message of Thu May 17 18:21:59 +0200 2012:
> On Thu, May 17, 2012 at 3:16 PM, Michal Suchanek
>  wrote:
> > Excerpts from Ian Jackson's message of Thu May 17 14:53:30 +0200 2012:
> >> Michal Suchanek writes ("Re: Bug#671503: general: APT repository format is 
> >> not documented"):
> >> > Excerpts from Filipus Klutiero's message of Wed May 16 18:44:21 +0200 
> >> > 2012:
> >> > > Could you clarify how this differs from #481129?
> >> >
> >> > It's 4 years later.
> >> >
> >> > Sorry, forgot that I filed the bug already. It's quite some time.
> >> >
> >> > Given there is no feedback in 4 years I guess it is futile reporting
> >> > this.
> >>
> >> Well, it's useful to bring it up again.
> >>
> >> > Admittedly there is no text in social contract about using
> >> > Debian-proprietary formats. And a format only defined by "apt can read
> >> > that" is definitely Debian-proprietary there is no better term for that.
> >>
> >> Everyone agrees that it would be better if this were documented.
> >> (I have struggled on occasion myself due to the lack of
> >> documentation.)
> >>
> >> But I think the use of the word "proprietary" is going too far.  It's
> >> certainly a special Debian format, but that wouldn't be changed if it
> >> were documented.  But it's not secret and we publish at least two
> >> writer implementations and one reader implementation AFAIK, with
> >> proper Free licences.
> >
> > However, it's easier to reverse-engineer  an existing repository than
> > the source code so for all practical purposes it's the same as if it
> > were closed source.
> 
> That is non-sense. You said yourself that the repository is not sufficient
> to understand it, yet you say that it is easier to understand with it than
> with looking at the source (and the various bits and pieces where parts
> are documented).

No, understanding the repository (or current apt source) is not
sufficient to ensure that your repository will be readable by future apt
or that future repositories will not become unreadable by your apt
without any warning or explanation.

Both has happened.

> But I don't know why we are still talking here. Russ already said he would
> like to have it as a subpolicy in the debian-policy. ftpmasters already said
> they would accept maintaining it. Everything left is writing this goddamn
> piece of documentation. So, maybe you should just write it…
> If you want to be extra fancy, start a wikipage in the debian wiki,
> but start typing. Go to debian-dak@l.d.o and discuss your work there.

That would be awesome.

Maybe he just forgot to CC this bug as well?

> 
> Would be way more productive than talking about that this document is missing…
> Everbody knows that. Everybody doesn't like it. Now go and fix that.
> That everyone would like to have such a document but nobody has it so far
> is a strong indication that the current people are busy with other stuff.
> An opportunity to get involved, I would say.
> 

As said earlier, just writing a random document does not make apt not
diverging from it.

> >> > I'd say it's slightly discriminatory against software not part of Debian
> >> > that cannot rely on getting notified when "apt can read that" silently
> >> > changes, there is no document defining what apt should be able to read
> >> > that software authors can rely on to interoperate with apt, one of the
> >> > core Debian tools. Apt in turn relies on open standards like HTTP and
> >> > FTP to interoperate with the rest of the world.
> >>
> >> I think this is not an appropriate use of the social contract or its
> >> concepts.
> >>
> >> Rather than complaining that this documentation doesn't exist, how
> >> about writing the document yourself ?  It's not a trivial job but it
> >> should be feasible by looking at the apt source code.
> >
> > For me it is not feasible at all.
> >
> > I can, of course, describe what current repositories look like or what
> > the current apt code accepts.
> >
> > However, that has silently changed in the past and is considered apt
> > feature, not a bug.
> 
> It hasn't silently changed. It was and is still the same. Your script was
> just horribly wrong and older APT versions just happened to work with
> that brokenness a little better. What you created with that script was NEVER
> intended to work, it just happened to be working out of complete luck
> (A Release file is supposed to include current data, not non-existent
>  data, this conclusion is reachable even without too much guessing.
>  Beside that this is actually documented in apt-secure and co, but that is
>  the problem with most of the documentation, nobody really reads it even
>  if it exists… which in the specific case of the Release file is even
>  translated to a few languages -- i am to lazy to look it up now…).

My script did exactly what apt-secure says. Well, at least so much as
apt-secure is specific bout it. And the data was existing and well
recognized by apt so it passed all avai

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Andrew Shadura]

Hello,

On Fri, 18 May 2012 11:37:08 +0200
Adam Borowski  wrote:

> Quilt is a kind of really primitive VCS.  It does not make sense to
> use both it and a modern one, and when someone tries, this ends up
> with no end of woe.  Quilt sprinkles its modifications around the
> source, breaks timestamps causing unnecessary rebuilds, breaks basic
> VCS abilities like bisection, makes it really hard to even review
> history, and so on.

I'm sorry to disappoint you, but quilt isn't a VCS at all. It's a patch
queue management system, and it does its job well. And, by the way, git
can't do it better at the moment as guilt seems to be dead, and stgit
is buggy (mq in mercurial is better than quilt, but we speak of git
atm).

Keeping patches in git makes thing less transparent and more
complicated. You have to inspect all the history just to find out what
changes did maintainer do to the original source. And, of course, you
need to have a clone of the repo.

> You complain about forcing people to use git, while you push quilt
> onto everyone else.  And while git can do every single thing quilt
> can do, the reverse is thoroughly untrue.

No, it can't. Please check what git, and what quilt is. They are
different tools for different purposes and they can't do each other's
job well enough.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Tollef Fog Heen]

]] Igor Pashev 

> What about stable release? Git branches?

Sure.  Branches are cheap.

> What about users who want rebuild a package (probably with new patches)?

They'll then just grab the git tree, apply their patches, build their
package.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87y5opssq1@qurzaw.varnish-software.com

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Adam Borowski]

On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote:
> On 05/17/2012 04:52 PM, Gergely Nagy wrote:
> >> I'm confused concerning the above; the point of a VCS in this context is 
> >> to 
> >> track changes to the source package, and the patches are themselves 
> >> important 
> >> changes to the source package.  If you have Git ignore the patches then 
> >> Git 
> >> doesn't have a complete view of the source package anymore.  Why would you 
> >> want to do that?
> > 
> > Git does have a complete view. What the above does, is tell dpkg-source
> > to fold any changes made to the upstream sources into a single
> > patch. Since the git tree already has the patches applied (with upstream
> > sources on a different branch, most probably), it has a full view.
> > 
> > This basically folds whatever patches the git tree has over upstream,
> > outside of debian/ into a single file. That's about it. Since that file
> > is generated, it has no business staying in git.
> 
> Doing that is the most stupid idea ever. All it does is to ensure that you
> package can't be NMUed sanely and that people who need to work with the 
> sources
> and your patches for whatever reason have to clone your git, which might be 
> not
> available or just too large for them to download - so at the end changes are
> high that they end up with a largish unreadable patch, similar to the mess we
> get from Ubuntu sometimes.
> The only thing that makes sense would be to use git-format-patch to export 
> your
> patches to debian/patches and list them in the series file. Or use gbp-pq, 
> which
> was made exactly for that.

Uhm, please switch around "git" and "quilt", and say that again.

Quilt is a kind of really primitive VCS.  It does not make sense to use both
it and a modern one, and when someone tries, this ends up with no end of
woe.  Quilt sprinkles its modifications around the source, breaks timestamps
causing unnecessary rebuilds, breaks basic VCS abilities like bisection,
makes it really hard to even review history, and so on.

You complain about forcing people to use git, while you push quilt onto
everyone else.  And while git can do every single thing quilt can do, the
reverse is thoroughly untrue.

I really wish there was a "3.0" format besides "3.0 (quilt)", so people are
not mislead into thinking they have to (or even, would gain anything) from
writing patches in quilt's format.

-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon


signature.asc
Description: Digital signature

Re: What to do with bug reports against non-existing/removed packages

[Cyril Brulebois]

Daniel Leidert  (18/05/2012):
> Our bug tracker contains items for packages, which do (not longer)
> exist. What should happen to them? I see, that it might be a good idea
> to keep them for the case, a package is re-introduced. But this might
> happen only for a few packages. Most of them got removed because newer
> versions were released. What about closing those reports, if an
> RM-request is filed?

AFAICT, bugs are closed with “Version: $lastversion+rm” when removals
happen. That hasn't always been the case, though.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: What to do with bug reports against non-existing/removed packages

[Neil Williams]

On Fri, 18 May 2012 16:50:12 +0800
Paul Wise  wrote:

> On Fri, May 18, 2012 at 4:45 PM, Daniel Leidert wrote:
> 
> > Our bug tracker contains items for packages, which do (not longer) exist. 
> > What should happen to them? I see, that it might be a good idea to keep 
> > them for the case, a package is re-introduced. But this might happen only 
> > for a few packages. Most of them got removed because newer versions were 
> > released. What about closing those reports, if an RM-request is filed?
> 
> ftpmaster already close bugs automatically when processing RM requests.

... although there are bugs in that process, especially if the request
is to remove more than one package in a single bug report or if the
package in question has had a change of source package name.

> 
> My thoughts are the same as last time this question got asked:
> 
> http://lists.debian.org/debian-devel/2012/04/msg4.html

As is that of the QA team in general:

http://wiki.debian.org/Teams/unknown-package/TODO

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpa4gGwolAc6.pgp
Description: PGP signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Jon Dowland]

On Thu, May 17, 2012 at 06:23:49PM -0400, Chris Knadle wrote:
> Another thing I've seen with another package I'm working on in collaboration 
> is using a Git repo in which the only contents are the debian/ files and not 
> the original source tarball nor source files at all.  To do a built the 
> source 
> is then downloaded via uscan, expanded, and the debian/ directory is copied 
> into the expanded source directory, and then built.  With this kind of 
> configuration no source files are tracked in Git, so instead it's necessary 
> to 
> track debian/patches so that patches can be applied to the "pristine" source.
> 
> At the moment I'm following the latter methodology to see how well it works 
> out and whether I like it.  If anyone else has used this method and has 
> comments on it, I'd be interested in reading them.

I've never used it with git, but I used to use it with svn as part of the
Debian games team.  For some (1 in 1000) packages, it may be necessary due to
the sheer size of the orig source (esp. with svn which wasn't efficient with
storage); but IMHO it's an incredible pain in the arse.  When I moved those
packages to git I gleefully stitched the VCS history together with the upstream
sources via git-filter-branch.


-- 
Jon Dowland


-- 
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/20120518085508.GA27744@debian

Re: What to do with bug reports against non-existing/removed packages

[Paul Wise]

On Fri, May 18, 2012 at 4:45 PM, Daniel Leidert wrote:

> Our bug tracker contains items for packages, which do (not longer) exist. 
> What should happen to them? I see, that it might be a good idea to keep them 
> for the case, a package is re-introduced. But this might happen only for a 
> few packages. Most of them got removed because newer versions were released. 
> What about closing those reports, if an RM-request is filed?

ftpmaster already close bugs automatically when processing RM requests.

My thoughts are the same as last time this question got asked:

http://lists.debian.org/debian-devel/2012/04/msg4.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/caktje6ebmzqwxk8+73v2ansm3d3smbrmlf4jgqu3xibyksb...@mail.gmail.com

What to do with bug reports against non-existing/removed packages

[Daniel Leidert]

Hi,

Our bug tracker contains items for packages, which do (not longer) exist. What 
should happen to them? I see, that it might be a good idea to keep them for the 
case, a package is re-introduced. But this might happen only for a few 
packages. Most of them got removed because newer versions were released. What 
about closing those reports, if an RM-request is filed?

http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=

Regards, Daniel
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!  

Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a


-- 
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/20120518084529.109...@gmx.net

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Igor Pashev]

18.05.2012 00:11, Russ Allbery пишет:
> Tollef Fog Heen  writes:
>> ]] Russ Allbery 
> 
>>> If I were to pick between the enhancements to Debian in this area, none
>>> of which I have time to work on and therefore can't vote on via
>>> implementation, I'd be way more interested in avoiding the entire
>>> source package upload process entirely and be able to just push signed
>>> Git tags to a trusted host that stores Git repositories for our
>>> packages.  Even if those repositories were only accessible to Debian
>>> maintainers because they're not license-reviewed.
> 
>> As always, it's easier to add another abstraction layer and so generate
>> the (somewhat pointless) source package and upload that, rather than
>> modifying dak (and/or buildd) to handle two kinds of sources and source
>> tools.
> 
>> I do agree it'd be better if we could just get rid of source packages,
>> but we're far from there yet, sadly.
> 
> Oh, sure.  And I'd be fine with that.  I just really like the idea of
> having everything about the package build automated, including generation
> of the source package, so that we no longer have problems where the
> maintainer does something weird on their local system.  I'm fine with it
> being optional for those who want to use it, but I'd like to use it.  One
> would test the build locally and then just push the tag, and the whole
> process would be reproduced in our infrastructure with a known
> configuration and we'd identify problems much faster.
> 
> It would also mean that any Debian maintainer could easily clone the
> canonical source for a package that's using Git and that infrastructure,
> which we sort of have with debcheckout but a bit awkwardly, and NMUs could
> always be pushed to the same place, with the security handled via regular
> upload rights checking instead of the more ad hoc git.debian.org
> permission approach.
> 
> It feels like the sort of direction in which software development is
> moving, and it feels like embracing our tools in ways that we're not yet
> doing.
> 


What about stable release? Git branches?
What about users who want rebuild a package (probably with new patches)?
dget functionality is really good for me.


-- 
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/4fb60a9e.5010...@gmail.com

Re: problems with quilt and 3.0 (quilt) format again

[Luca Capello]

Hi there!

On Tue, 15 May 2012 01:10:19 +0200, Norbert Preining wrote:
> On Mo, 14 Mai 2012, Clint Adams wrote:
>> dpkg-source is more intolerant of fuzz than quilt itself.
>> Run quilt refresh on the patch and it should be happier.
>
> Ar ...  is this on purpose? Or by chance? Or to drive 
> developers crazy?
>
> No, an answer "it is written down there on page 17 of the man page"
> is *not* acceptable.

JFTR, the documentation bug was fixed in dpkg_1.16.3:

  

Thx, bye,
Gismo / Luca


pgpGowdrauvkJ.pgp
Description: PGP signature

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Bernd Zeimetz]

On 05/17/2012 04:52 PM, Gergely Nagy wrote:
> Chris Knadle  writes:
> 
>> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
 On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> No, I hereby start saying good by to 3.0

 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
 found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
 few packages.
>>>
>>> I can't see any reason to use 1.0 anymore, ever.
>>>
>>> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
>>> has a number of upsides.  And working around quilt is simple:
>>>
>>> echo "single-debian-patch" >debian/source/options
>>> echo "/.pc" >>.gitignore
>>> echo "/debian/patches" >>.gitignore
>>
>> I'm confused concerning the above; the point of a VCS in this context is to 
>> track changes to the source package, and the patches are themselves 
>> important 
>> changes to the source package.  If you have Git ignore the patches then Git 
>> doesn't have a complete view of the source package anymore.  Why would you 
>> want to do that?
> 
> Git does have a complete view. What the above does, is tell dpkg-source
> to fold any changes made to the upstream sources into a single
> patch. Since the git tree already has the patches applied (with upstream
> sources on a different branch, most probably), it has a full view.
> 
> This basically folds whatever patches the git tree has over upstream,
> outside of debian/ into a single file. That's about it. Since that file
> is generated, it has no business staying in git.

Doing that is the most stupid idea ever. All it does is to ensure that you
package can't be NMUed sanely and that people who need to work with the sources
and your patches for whatever reason have to clone your git, which might be not
available or just too large for them to download - so at the end changes are
high that they end up with a largish unreadable patch, similar to the mess we
get from Ubuntu sometimes.
The only thing that makes sense would be to use git-format-patch to export your
patches to debian/patches and list them in the series file. Or use gbp-pq, which
was made exactly for that.

[...]

>> Patching the source can be an effort especially concerning documenting
>> why the patches were done and the source of the patches, so these seem
>> like they'd be important to track rather than something to ignore.
> 
> The reasons can - and should be - documented in git. Granted, that does
> not transfer to the debianized source package, which is unfortunate, but
> it's still better than fighting with integrating quilt with a VCS (in
> which case, everyone with a higher number of patches would go back to
> 1.0 and custom patching systems and ignore every other benefit of 3.0,
> because quilt and VCS generally don't play nice together).


Which again requires people to find and clone the git instead of just looking
what we ship on our mirrors and discs. Remember, there are people without (fast)
internet, they might not be able to clone your git, or not be allowed to do so
for whatever reasons.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4fb5f914.8050...@bzed.de