Re: big .debian.tar.xz - EG Wordpress

[Paul Wise]

On Thu, May 17, 2012 at 2:20 PM, Thomas Goirand wrote:

> Unfortunately, swfupload *cannot* be packaged in Debian because we have
> no ways of building it (unless the situation changed with adobe tools... in
> which case, I would really like to hear about it!). The only thing you could 
> package
> would be a very old version of it.

Now that we have an AS3 compiler in Debian (as3compile in swftools)
maybe that would work?

-- 
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/CAKTje6HMUX3RsB9kUXt5m2uC7qQU_+W-=f7r+mgyjupjxvk...@mail.gmail.com

Re: big .debian.tar.xz - EG Wordpress

[Yves-Alexis Perez]

On mer., 2012-05-16 at 19:45 +1000, Russell Coker wrote:
> I just downloaded the source to Wordpress from Squeeze, it's got a 14M 
> .debian.tar.xz which is mostly sources for things that are included in the 
> upstream tarball.  The build process appears to only use the upstream tarball 
> code so the 13MB of data in the debian/missing-sources directory isn't used 
> for building.
> 
> It is a really good thing to have upstream sources available as dictated by 
> the GPL (well done to whoever did that).  But that availability doesn't 
> require that they be in the source package.
> 
> Would it be possible to have somewhere on the Debian servers for storing such 
> files so that they can be referenced in a README file or something rather 
> than 
> sent to everyone?  I'm sure that most people who build a Wordpress package 
> won't use them.
> 
Any reason you didn't CC: wordpress maintainers? (I guess they are
subscribed to -devel but considering the current mail rate, I'm unsure
they'll read everything so it might make sense to CC: them at first…)

Regards,
-- 
Yves-Alexis


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

Re: big .debian.tar.xz - EG Wordpress

[Jon Dowland]

On Thu, May 17, 2012 at 02:20:48PM +0800, Thomas Goirand wrote:
> Unfortunately, swfupload *cannot* be packaged in Debian because we have no
> ways of building it (unless the situation changed with adobe tools... in
> which case, I would really like to hear about it!). The only thing you could
> package would be a very old version of it.

So if I understand the situation correctly; wordpress ships a pre-build binary
which cannot be generated in Debian?  Whether the source is in a separate
package or not, this does not feel right.


-- 
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/20120517083808.GA32082@debian

Bug#673238: ITP: ceres-solver -- nonlinear least square minimizer

[Koichi Akabe]

Package: wnpp
Severity: wishlist
Owner: Koichi Akabe 

* Package name: ceres-solver
  Version : 1.1.1
  Upstream Author : Google Inc.
* URL : http://code.google.com/p/ceres-solver/
* License : BSD-3-clause
  Programming Lang: C++
  Description : nonlinear least square minimizer

Ceres Solver solves nonlinear least squares problems comes up
in a broad range of areas across science and engineering.



-- 
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/20120517084353.4478.26415.reportbug@debian

Re: debuild/dpkg-buildpackage behaves not as expected

[James McCoy]

On Thu, May 17, 2012 at 08:21:23AM +0200, Thibaut Paumard wrote:
> Le 17/05/12 00:25, James McCoy a écrit :
> > 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
> 
> Precisely, the point is that should be:
> applies patches, builds, *cleans* and unapplies patches

So, you would want dpkg-buildpackage to be an expensive no-op?  Running
the clean target means that you no longer have the artifacts produced by
the build.

-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Bug#673241: ITP: glog -- logging library for C++

[Koichi Akabe]

Package: wnpp
Severity: wishlist
Owner: Koichi Akabe 

* Package name: glog
  Version : 0.3.2
  Upstream Author : Google Inc.
* URL : http://code.google.com/p/google-glog/
* License : BSD-3-clause
  Programming Lang: C++
  Description : logging library for C++

The glog library implements application-level logging. This
library provides logging APIs based on C++-style streams and
various helper macros.



-- 
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/20120517085849.4638.67049.reportbug@debian

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

[Adam D. Barratt]

On 17.05.2012 07:54, Neil Williams wrote:

On Thu, 17 May 2012 04:36:40 +0200
Adam Borowski  wrote:

On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow 
wrote:
> Can someone set the default to xz and recompile all of Debian or 
at

> least base and create a repository from that for install tests?

There's no need to recompile anything.  You can recompress existing 
packages

using the attached script.


What about
packages which are the same version in wheezy and in squeeze - now
you're looking at making a new point release with all packages across
all suites changing checksums.


SRM would need an awful lot of convincing that doing that was anything 
other than a really bad idea.


Regards,

Adam


--
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/edd7c0607eeb8483c213f32dda8af...@mail.adsl.funky-badger.org

Re: big .debian.tar.xz - EG Wordpress

[Toni Mueller]

On Wed, May 16, 2012 at 05:53:11PM +0800, Paul Wise wrote:
> On Wed, May 16, 2012 at 5:45 PM, Russell Coker wrote:
> > Would it be possible to have somewhere on the Debian servers for storing 
> > such
> > files so that they can be referenced in a README file or something rather 
> > than
> > sent to everyone?  I'm sure that most people who build a Wordpress package
> > won't use them.
> 
> If I downloaded a source package and didn't get source I would be most
> unimpressed.

Seconded!

If you say "download some, and ignore the others in most cases", please
consider that in the case you really find out that you need the source,
you'll most likely be offline, and cannot do much about it (Murphy's
laws apply generously).

So I'd say, better get the whole chunk in one go to be safe.

Imho, much of the value of being entitled to have source is in actually
having it, instantanously, as opposed to merely having a legal option to
get it somehow, sometime.

Of course, YMMV.


Kind regards,
--Toni++


-- 
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/20120517101054.ga10...@spruce.wiehl.oeko.net

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

[Adam Borowski]

On Thu, May 17, 2012 at 07:54:17AM +0100, Neil Williams wrote:
> On Thu, 17 May 2012 04:36:40 +0200
> Adam Borowski  wrote:
> 
> > On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote:
> > > Can someone set the default to xz and recompile all of Debian or at
> > > least base and create a repository from that for install tests?
> > 
> > There's no need to recompile anything.  You can recompress existing packages
> > using the attached script.
> 
> .. and then spend a huge amount of time rebuilding your now broken
> pool/ and archive because none of the checksums match ...
> 
> Do you have a patch for dak to go alongside your script to update all
> checksums for all binaries across all architectures? What about
> packages which are the same version in wheezy and in squeeze

Goswin asked for a way to test d-i and friends with xz .debs, and this
script works well for that task, removing the need for recompiling.

No one proposes replacing packages in the archive without bumping the
version number, that'd be a recipe for disaster.

Although, if I understand what David Kalnischkies says in
https://lists.debian.org/debian-devel/2012/05/msg00706.html, having
packages with different size/global checksum but identical contents
(control.tar, data.tar) in local repositories (apt-cdrom, reprepro, ...)
shouldn't be a problem as well.

> Stop investing time in stop gap measures

How exactly is greatly reducing download sizes a "stop gap measure"? 
Obviously, several releases later the savings will be eaten, but without
them the bloat will be that much bigger.  That's the long-term benefit, and
that it also solves a short-term problem (CD1) is a reason to switch to xz
before wheezy.

> we need a durable solution and that is likely to mean dropping GNOME and
> KDE as an option for CD#1.

While dropping GNOME3 is a very sweet idea -- its main mode fails to work
on a good part of, even new, machines, not degrading gracefully; its
fallback mode is a bad joke, it Depends: network-manager (ie, Conflicts:
working networking), and so on, not to even start about more subjective
opinions about changes to the UI -- reducing the size of CD1 to 2/3 would
easily solve the problem for now and last for a few Debian releases, and
by then, CDs will go away the way floppies did.

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


signature.asc
Description: Digital signature

Re: debuild/dpkg-buildpackage behaves not as expected

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 17/05/12 11:39, James McCoy a écrit :
> On Thu, May 17, 2012 at 08:21:23AM +0200, Thibaut Paumard wrote:
>> Le 17/05/12 00:25, James McCoy a écrit :
>>> 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
>> 
>> Precisely, the point is that should be: applies patches, builds,
>> *cleans* and unapplies patches
> 
> So, you would want dpkg-buildpackage to be an expensive no-op?
> Running the clean target means that you no longer have the
> artifacts produced by the build.
> 

Except the built packages in the parent directory, of course.

I see two reasonable choices:

1- don't clean, don't unpatch
2- clean, unpatch (like with -tc)

The current default (don't clean, unpatch) doesn't sound as a very
good choice to me, but again I may fail to see a use case that is
obvious to someone else.

Regards, Thibaut.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+00NQACgkQ+37NkUuUiPF1uACfTk/GvlAIJ7qLNmFzh2Xml/KP
0swAniYd9cOJJmbDkAa1gvqfS+CSRRdM
=sokZ
-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/4fb4d0d4.2030...@users.sourceforge.net

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

[Michal Suchanek]

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.

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.

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.

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

Re: debuild/dpkg-buildpackage behaves not as expected

[Olе Streicher]

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.

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).

> 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


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

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

[Ian Jackson]

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.

> 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.

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.

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

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

[Eugene V. Lyubimkin]

Hello,

On 2012-05-17 13:48, Michal Suchanek wrote:
> 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.
> 
> 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.

As someone who had to reverse-engineer APT repository format I fully
agree with the above. With one minor addition that some software which
is (non-core) part of Debian suffer from the same problem.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


-- 
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/20120517132412.GA23563@r500-debian

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

[Michal Suchanek]

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


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

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

[Chris Knadle]

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?

> 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.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

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

[Jon Dowland]

On Thu, May 17, 2012 at 10:41:37AM -0400, Chris Knadle 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?

It's the other way around. You manage changes to the source package as commits
in the VCS; perhaps tracked on separate branches, perhaps not. The source
package ends up being a flattened version of all of these commits.  So the
'preferred form for modification' is the VCS archive; the source package is a
second class citizen.

So to follow Adam's instructions you would first apply each of the patches as a
commit in your VCS, then delete them, then ignore debian/patches going forward
(treating it as an implementation detail of a legacy source archive format)

Yes, I think it's a shame if the preferred form for modification wasn't the
source package.  I also think it's turning a blind eye to say putting git
repos in as source packages would be not worth the work to audit them; but we
can keep hosting them at git.debian.org just fine.


-- 
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/20120517145410.GB7703@debian

Re: big .debian.tar.xz - EG Wordpress

[Jon Dowland]

On Thu, May 17, 2012 at 12:10:55PM +0200, Toni Mueller wrote:
> If you say "download some, and ignore the others in most cases", please
> consider that in the case you really find out that you need the source,
> you'll most likely be offline, and cannot do much about it (Murphy's
> laws apply generously).

Hopefully you've got the build-dependencies too. Which, if the source packages
were split off into other packages, you'd then pull in.


-- 
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/20120517145625.GC7703@debian

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

[Gergely Nagy]

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.

>> 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.

You're misreading this. "Nuking upstream debian/" means ignoring any
debian/ directory upstream may have had. That is generally a Good
Thing(tm), as we want to have our own packaging.

The original is still available in both the upstream tarball, and the
upstream branch. debian/patches in this case is irrelevant, as that is
automatically generated by diffing the upstream tree against the current
(git) tree and folding it into a single patch file.

> 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).

-- 
|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/871umioo6l.fsf@algernon.balabit

Lintian warning hardening-no-stackprotector although compiled with hardening options

[Daniel Leidert]

Hi,

The html-xml-utils package contains a bunch of small helper programs.
I've chosen dh 9 compatibility level recently to enable hardening.
However, I still get lintian warnings for 3 binaries. However all
binaries are compiled and linked with the same flags. The only
difference I see is, that the 3 binaries in question are made of only
one object file, whereas all other binaries are linked together by two
or more object files.

So why does lintian give me those warnings and how can it be fixed?

The log file is attached.

TIA
Regards, Daniel
I: Using pkgname logfile
I: Current time: Thu May 17 17:07:09 CEST 2012
I: pbuilder-time-stamp: 1337267229
I: Obtaining the cached apt archive contents
I: Setting up ccache
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: bison, debhelper (>> 9), flex, gperf, libcurl4-gnutls-dev (>> 7.9.7) | 
libcurl-dev (>> 7.9.7), man2html
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in 
`/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 11221 files and directories currently installed.)
Unpacking pbuilder-satisfydepends-dummy (from 
.../pbuilder-satisfydepends-dummy.deb) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on bison; however:
  Package bison is not installed.
 pbuilder-satisfydepends-dummy depends on debhelper (>> 9); however:
  Package debhelper is not installed.
 pbuilder-satisfydepends-dummy depends on flex; however:
  Package flex is not installed.
 pbuilder-satisfydepends-dummy depends on gperf; however:
  Package gperf is not installed.
 pbuilder-satisfydepends-dummy depends on libcurl4-gnutls-dev (>> 7.9.7) | 
libcurl-dev (>> 7.9.7); however:
  Package libcurl4-gnutls-dev is not installed.
  Package libcurl-dev is not installed.
 pbuilder-satisfydepends-dummy depends on man2html; however:
  Package man2html is not installed.
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
  apache2{a} apache2-mpm-worker{a} apache2-utils{a} apache2.2-bin{a} 
  apache2.2-common{a} bison{a} bsdmainutils{a} comerr-dev{a} debhelper{a} 
  file{a} flex{a} gawk{a} gettext{a} gettext-base{a} gperf{a} groff-base{a} 
  html2text{a} intltool-debian{a} krb5-multidev{a} libapr1{a} 
  libaprutil1{a} libaprutil1-dbd-sqlite3{a} libaprutil1-ldap{a} 
  libasprintf0c2{a} libbison-dev{a} libcap2{a} libcroco3{a} 
  libcurl3-gnutls{a} libcurl4-gnutls-dev{a} libexpat1{a} libffi5{a} 
  libgcrypt11{a} libgcrypt11-dev{a} libgettextpo0{a} libglib2.0-0{a} 
  libgnutls-dev{a} libgnutls-openssl27{a} libgnutls26{a} libgnutlsxx27{a} 
  libgpg-error-dev{a} libgpg-error0{a} libgssapi-krb5-2{a} libgssrpc4{a} 
  libidn11{a} libidn11-dev{a} libk5crypto3{a} libkadm5clnt-mit8{a} 
  libkadm5srv-mit8{a} libkdb5-6{a} libkeyutils1{a} libkrb5-3{a} 
  libkrb5-dev{a} libkrb5support0{a} libldap-2.4-2{a} libldap2-dev{a} 
  libmagic1{a} libp11-kit-dev{a} libp11-kit0{a} libpcre3{a} libpipeline1{a} 
  libpopt0{a} libprocps0{a} librtmp-dev{a} librtmp0{a} libsasl2-2{a} 
  libsigsegv2{a} libssh2-1{a} libssh2-1-dev{a} libssl1.0.0{a} libtasn1-3{a} 
  libtasn1-3-dev{a} libunistring0{a} libxml2{a} m4{a} man-db{a} man2html{a} 
  man2html-base{a} mime-support{a} pkg-config{a} po-debconf{a} procps{a} 
  zlib1g-dev{a} 
0 paThe following NEW packages will be installed:
  apache2{a} apache2-mpm-worker{a} apache2-utils{a} apache2.2-bin{a} 
  apache2.2-common{a} bison{a} bsdmainutils{a} comerr-dev{a} debhe
Extracting templates from packages: 36%
Extracting templates from packages: 73%
Extracting templates from packages: 100%
Preconfiguring packages ...
Selecting previously unselected package libpipeline1:amd64.
(Reading database ... 11221 files and directories currently installed.)
Unpacking libpipeline1:amd64 (from .../libpipeline1_1.2.1-1_amd64.deb) ...
Selecting previously unselected package libpopt0:amd64.
Unpacking libpopt0:amd64 (from .../libpopt0_1.16-5_amd64.deb) ...
Selecting previously unselected package libprocps0:amd64.
Unpacking libprocps0:amd64 (from .../libprocps0_1%3a3.3.2-3_amd64.deb) ...
Selecting previously unselected package libssl1.0.0:amd64.
Unpacking libssl1.0.0:amd64 (from .../libssl1.0.0_1.0.1c-1_amd64.deb) ...
Selecting previously unselected package libasprintf0c2:amd64.
Unpacking libasprintf0c2:amd

Re: Lintian warning hardening-no-stackprotector although compiled with hardening options

[Sven Joachim]

On 2012-05-17 17:25 +0200, Daniel Leidert wrote:

> The html-xml-utils package contains a bunch of small helper programs.
> I've chosen dh 9 compatibility level recently to enable hardening.
> However, I still get lintian warnings for 3 binaries. However all
> binaries are compiled and linked with the same flags. The only
> difference I see is, that the 3 binaries in question are made of only
> one object file, whereas all other binaries are linked together by two
> or more object files.
>
> So why does lintian give me those warnings

Probably your package does not allocate any character arrays on the
stack.  See "lintian-info -t hardening-no-stackprotector" and
hardening-check(1).

> and how can it be fixed?

There needs to be a better way to detect if a program was built with
-fstack-protector, or the warning should be made experimental.
See also #673112.

Cheers,
   Sven


-- 
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/87likq24rg@turtle.gmx.de

Re: Lintian warning hardening-no-stackprotector although compiled with hardening options

[Joachim Wiedorn]

Hello Daniel,

[the appended logfile wasn't complete!]

Daniel Leidert wrote on 2012-05-17 17:25:

> So why does lintian give me those warnings and how can it be fixed?

I had the same problem with fox1.6. Please check your build log file
wether "-fstack-protector" is really inside.

I had found that in configure.ac CXXFLAGS will be reset at first.
Now I use this solution in configure.ac:

   CXXFLAGS=${CXXFLAGS}
   LDFLAGS=${LDFLAGS}

Perhaps you can use a similar solution.

---
Have a nice day.

Joachim (Germany)


-- 
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/20120517173943.4a36f...@jupiter.home

Re: big .debian.tar.xz - EG Wordpress

[Toni Mueller]

On Thu, May 17, 2012 at 03:56:25PM +0100, Jon Dowland wrote:
> Hopefully you've got the build-dependencies too. Which, if the source packages
> were split off into other packages, you'd then pull in.

Being able to read the source code can often get you quite far already,
but yes, usually, I want all the build dependencies and a locally
runnable copy, too.


-- 
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/20120517161426.gb10...@spruce.wiehl.oeko.net

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

[David Kalnischkies]

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).

Even if you don't like apt sources, debian has a lot of other tools working
with the same repository in a bunch of different languages, so choose
which you like most and you will properly find a tool in that language to
either download from repositories or to create them.



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.

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.


>> > 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…).

At the time you reported that bug i also told you what was wrong in that
script and how to fix it if you want to continue to use that script, so
please don't keep up the myth that we changed everything and nobody told
you why and how and what not.


If you are really that unsatisfied with apt, feel free to use something else,
we have enough tools to choose from, it not like apt would be the only
package manager in existence. It might be the most used one, but that
doesn't say anything about documentation or available manpower.


> The status was 'documented' by existing

Duplicate

[Filipus Klutiero]

reassign 481129 debian-policy
merge 481129 671503
thanks

On 2012-05-17 07:48, Michal Suchanek wrote:

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.



Merging the reports then.


--
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/4fb52bc3.4090...@gmail.com

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

[Russ Allbery]

Tollef Fog Heen  writes:

> Pushing a signed tag and having source packages and binaries built from
> that doesn't rely on 3.0 (git), though.  «Just» a repository somewhere
> with hooks that go «oh, a signed tag, let me build a source package and
> upload that».  Might fire it off as a job to a separate process so
> pushing to big repos doesn't take a winter and a day, but that's really
> an implementation detail.

Good point.

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.

-- 
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/871umiy9r8@windlord.stanford.edu

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

[Andreas Barth]

* Russ Allbery (r...@debian.org) [120517 19:53]:
> Tollef Fog Heen  writes:
> 
> > Pushing a signed tag and having source packages and binaries built from
> > that doesn't rely on 3.0 (git), though.  «Just» a repository somewhere
> > with hooks that go «oh, a signed tag, let me build a source package and
> > upload that».  Might fire it off as a job to a separate process so
> > pushing to big repos doesn't take a winter and a day, but that's really
> > an implementation detail.
> 
> Good point.
> 
> 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.

git.debian.org isn't license-reviewed either, so could be the same
level of being public. Having special form of git-tags on git.d.o
automatically uploaded to ftp-master (and having there the usual
checks) would sound a good idea (of course, also for svn and other
vcs). However, this package format would still need to allow NMUs
(and/or having the vcs in question having support for NMUs).


Andi


-- 
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/20120517181917.ga2...@mails.so.argh.org

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

[Tollef Fog Heen]

]] 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.

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

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

[Chris Knadle]

On Thursday, May 17, 2012 10:52:02, 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.

So essentially this uses Git to create the 3.0 (quilt) format without actually 
using quilt, yet acts similar to the original 1.0 format of making a single 
patch.   That's pretty interesting.  Thanks for the explanation.

> >> 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.
> 
> You're misreading this. "Nuking upstream debian/" means ignoring any
> debian/ directory upstream may have had. That is generally a Good
> Thing(tm), as we want to have our own packaging.

Okay.  I don't commonly see debian/ directories in the upstream sources 
themselves, so I couldn't tell that's what you had meant.

> The original is still available in both the upstream tarball, and the
> upstream branch. debian/patches in this case is irrelevant, as that is
> automatically generated by diffing the upstream tree against the current
> (git) tree and folding it into a single patch file.

Yes I see.

> > 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).

One of the problems I'm running into is in working on updating a package that 
has been abandoned and is now three years older than upstream, and which has a 
single (1.0 format) patch with no notes in the files themselves, and no VCS 
location.  I can look through the changelog in the package, but without any 
way of matching up dates due to the patch being bundled into a single file, I 
cannot seem to match up what changes within the patch match up with the 
changelog, so I cannot tell which elements of the patch may still be relevent 
today with a new upstream version of the software.

If Git had been used it would be possible to figure out which commit made what 
change, but it would still be a lenthy process.  Quilt patches with annotated 
headers to describe each patch still seems like they have an advantage in that 
the annotated headers are in the patch files themselves.

I'm not sure which is better at this point (and it may depend on the 
situation) but either way it's nice to know about both options.

Thanks.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

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

[Yves-Alexis Perez]

On mar., 2012-05-15 at 14:32 +0900, Norbert Preining wrote:
> Hi dpkg-* maintainers,

I think you missed the correct mailing list to reach the dpkg-*
maintainers.
-- 
Yves-Alexis


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

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

[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.

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

Re: Lintian warning hardening-no-stackprotector although compiled with hardening options

[Russ Allbery]

Daniel Leidert  writes:

> The html-xml-utils package contains a bunch of small helper programs.
> I've chosen dh 9 compatibility level recently to enable hardening.
> However, I still get lintian warnings for 3 binaries. However all
> binaries are compiled and linked with the same flags. The only
> difference I see is, that the 3 binaries in question are made of only
> one object file, whereas all other binaries are linked together by two
> or more object files.

> So why does lintian give me those warnings and how can it be fixed?

I think we may have to disable that check.  There are just too many false
positives.  Stack protection only happens if you allocate "large"
character arrays off the stack, and a lot of software just doesn't do
that.  (One could argue that doing so is frequently bad coding style
compared to using dynamically allocated memory from the start.  While not
all software that does this has arbitrary limits on things like input line
sizes, a lot of it does.)

-- 
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/878vgqva5y@windlord.stanford.edu

Bug#673318: ITP: mwrap -- Octave/Matlab mex generator

[Nicolas Bourdaud]

Package: wnpp
Severity: wishlist
Owner: Nicolas Bourdaud 

* Package name: mwrap
  Version : 0.33
  Upstream Author : David Bindel 
* URL : http://www.cs.cornell.edu/~bindel/sw/mwrap/
* License : BSD
  Programming Lang: C++
  Description : Octave/Matlab mex generator

MWrap is an interface generation system in the spirit of SWIG or matwrap. From
a set of augmented MATLAB script files, MWrap will generate a MEX gateway to
desired C/C++ and FORTRAN function calls and MATLAB function files to access
that gateway. MWrap takes care of the details of converting to and from
MATLAB's data structures, allocating and freeing temporary storage, handling
object upcasts (even in the presence of multiple inheritance), and catching C++
exceptions. The gateway functions also work with recent versions of Octave.



-- 
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/20120517202141.3652.75629.reportbug@petisuix

Bug#673322: ITP: sankore -- interactive digital whiteboard software for teaching

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz 

* Package name: sankore
  Version : 3.1
  Upstream Author : Open-Sankoré Developers team 
* URL : http://dev.open-sankore.org/
* License : GPL-3+
  Programming Lang: C++
  Description : interactive digital whiteboard software for teaching

 Open-Sankoré is a free and open-source interactive whiteboard (IWB)
 software compatible with any projector and pointing device. It is
 based on the Uniboard software originally developed at the University
 of Lausanne, Switzerland.



-- 
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/20120517204046.12472.67714.reportbug@inanna

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

[Holger Wansing]

Hi,

Steve McIntyre  wrote:
> Remembering the fun that we had during the Squeeze release with trying
> to make single-CD installations work well, it's time to consider what
> we're going to *claim* to support in Wheezy. We've had a history of
> supporting the following single-CD installations:
> 
>  * Gnome desktop from CD#1
>  * KDE desktop from "KDE CD#1"
>  * XFCE desktop from "light CD#1"
>  * LXDE desktop from "light CD#1"
>  * base system only from netinst CD

FYI: With the alpha1 images, it is not possible, to do an installation
from only one CD image and without internet access, getting an X system
as result.
When using  Alpha1 Binary-CD #1
Alpha1 KDE CD
Alpha1 xfce-lxde CD
and, as said before, having no internet access while installing, you are
only provided the "Standard system tools" task, no "Desktop environment" 
is provided.

See #673200.

If you knew this already, sorry for the noise.


Holger


-- 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Powered by Sylpheed 3.0.2 under
Debian GNU/ / _  _  _  _  _ __  __
 / /__  / / / \// //_// \ \/ /
// /_/ /_/\/ /___/  /_/\_\6.0 / Squeeze.
Registered LinuxUser #311290 - http://counter.li.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/20120517224902.9a3a4552.li...@wansing-online.de

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

[Chris Knadle]

On Thursday, May 17, 2012 10:54:15, Jon Dowland wrote:
> On Thu, May 17, 2012 at 10:41:37AM -0400, Chris Knadle 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?
> 
> It's the other way around. You manage changes to the source package as
> commits in the VCS; perhaps tracked on separate branches, perhaps not. The
> source package ends up being a flattened version of all of these commits. 
> So the 'preferred form for modification' is the VCS archive; the source
> package is a second class citizen.
> 
> So to follow Adam's instructions you would first apply each of the patches
> as a commit in your VCS, then delete them, then ignore debian/patches
> going forward (treating it as an implementation detail of a legacy source
> archive format)
> 
> Yes, I think it's a shame if the preferred form for modification wasn't the
> source package.  I also think it's turning a blind eye to say putting git
> repos in as source packages would be not worth the work to audit them; but
> we can keep hosting them at git.debian.org just fine.

Although I like the /idea/ of being able to modify the source package directly 
via Git as if there were a "3.0 (Git)" source format, I also think it's 
important to be able to verify the source download that came from upstream.  
Including the original source tarball isn't enough because that is then being 
modified.  Doing something like 'git diff ..HEAD' to 
find out how the source has been changed would presumably also contain diffs 
from debian/ files not related to the source.   Looking at the manpage for 
'git diff' it isn't immediately clear to me how you'd filter those out.  
[Although I'm sure there's a way.]

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.

Thanks.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

Bug#673332: ITP: etk.docking -- PyGTK Docking Widgets

[Dmitry Borodaenko]

Package: wnpp
Severity: wishlist
Owner: Dmitry Borodaenko 

* Package name: etk.docking
  Version : 0.2
  Upstream Author : Dieter Verfaillie , Arjan 
Molenaar 
* URL : http://pypi.python.org/pypi/etk.docking
* License : LGPL3+
  Programming Lang: Python
  Description : PyGTK Docking Widgets

etk.docking provides GTK+ docking widgets for use in Python
applications.



-- 
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/20120517215744.GA30561@localhost

Bug#673342: ITP: ciderwebmail -- IMAP webmail service

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: ciderwebmail
  Version : 1.03
  Upstream Author : Stefan Seifert
* URL : http://ciderwebmail.org/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : webmail that suck less

 CiderWebmail is a modern, user friendly and maintenance free webmail
 application. It's targeted at mailserver administrators who need to
 provide web access for their user's mailboxes and individuals wanting
 to access their mailboxes via an always available web application.
 .
 It currently supports all the basic mail handling features one would
 expect from such an application:
 .
  * Listing your emails with selectable sort order and grouping.
  * Moving emails between folders and deleting using drag & drop.
  * Displaying text and HTML emails even if their code is completely
broken (which happens quite often in reality)
  * Keyboard bindings for switching through emails, moving, deleting,
replying and forwarding.
  * Reply to and forward existing emails or write new emails, add
attachments and have a copy saved in your "Sent" folder.
 .
 As an application written deep in the 21st century, CiderWebmail
 supports only IMAP mail servers.



-- 
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/20120517231131.30038.15668.report...@auryn.jones.dk

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

[Adam Borowski]

On Wed, May 16, 2012 at 02:47:54PM +0200, Goswin von Brederlow wrote:
> Can someone set the default to xz and recompile all of Debian or at
> least base and create a repository from that for install tests?

I tested it a bit, both with bare debootstrap into a chroot, and by
recompressing all debs on a d-i CD (netinst i386, CD1 amd64).  All went ok.

I did not test fancy options in d-i (probably pointless, either unpacking
debs works or not), nor special firmwares (what hardware requires those?  Do
they come from udebs or debs?).

And of course, this doesn't solve the issue of first stage of debootstrap on
foreign systems without xz.  Are those ever going to touch packages with
priority 

signature.asc
Description: Digital signature

Work-needing packages report for May 18, 2012

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 391 (new: 1)
Total number of packages offered up for adoption: 171 (new: 3)
Total number of packages requested help for: 60 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   aaphoto (#673231), orphaned today
 Description: Auto Adjust Photo, automatic color correction of photos
 Installations reported by Popcon: 177

390 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   birthday (#673226), offered today
 Description: Display information about pending events on login
 Installations reported by Popcon: 110

   snd (#673203), offered yesterday
 Installations reported by Popcon: 533

   wmifs (#672846), offered 3 days ago
 Description: WindowMaker dock app for monitoring network traffic
 Installations reported by Popcon: 163

168 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] par2cmdline (#673225), requested today
 Description: Parity Archive Volume Set, for checking and repair of
   files
 Installations reported by Popcon: 2200

   apt-xapian-index (#567955), requested 836 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 55901

   asymptote (#517342), requested 1175 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3291

   athcool (#278442), requested 2760 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 87

   balsa (#642906), requested 235 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 259

   bastille (#592137), requested 649 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 222

   boinc (#511243), requested 1225 days ago
 Description: BOINC distributed computing
 Installations reported by Popcon: 1820

   cardstories (#624100), requested 388 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 6

   chromium-browser (#583826), requested 718 days ago
 Description: Chromium browser
 Installations reported by Popcon: 10644

   cryptsetup (#600777), requested 575 days ago
 Description: configures encrypted block devices
 Installations reported by Popcon: 7866

   debtags (#567954), requested 836 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2539

   doc-central (#566364), requested 845 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 204

   elvis (#432298), requested 1774 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Installations reported by Popcon: 370

   fbcat (#565156), requested 855 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 164

   flightgear (#487388), requested 1426 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 840

   freeipmi (#628062), requested 357 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 1300

   gnat-4.4 (#539633), requested 1493 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 1678

   gnat-gps (#496905), requested 1358 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 432

   gnupg (#660685), requested 87 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 124050

   golang (#668870), requested 32 days ago
 Installations reported by Popcon: 206

   grub2 (#248397), requested 2929 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 114099

   hfsprogs (#557892), requested 904 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1155

   hotkey-setup (#483107), requested 1451 days ago
 Description: auto-configures laptop hotkeys
 Installations reported by Popcon: 3925

   irssi-scripts (#663577), requested 66 days ago
 Description: collection of 

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

[Guillem Jover]

On Sun, 2012-05-13 at 18:47:01 -0400, Joey Hess wrote:
> Adam Borowski wrote:
> > Special-casing base packages would be a lot of complexity, let's avoid that
> > if possible -- but still preferred to letting gzip stay.
> 
> Base packages can be identified at build time by their priority.
> if ($priority ne 'important' && $priority ne 'required') {
> }

Only as long as the debian/control information matches the one from
the archive override. And if we have to keep changing the packages
anyway to make sure they match changing priorities, we might as well
just set the compressor (to gzip) explicitly for base packages.

regards,
guillem


-- 
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/20120518024612.ga20...@gaara.hadrons.org

Participe da 6ª Edição da SEC - Semana de Encontro de Coordenadores

[Escola Paulista de Direito - EPD]

Olá debian-devel.lists.debian,

Este programa não permite a visualização de mensagens formatadas (com cores, 
imagens e links), portanto solicitamos que você copie o texto abaixo, e cole no 
campo "Endereço" do seu navegador.
http://emkt.epd.edu.br/emkt/tracer/?1,846080,c4b71992,b4d8

Para garantir que nossas mensagens cheguem em sua caixa de entrada, adicione o 
email epdm...@epd.edu.br ao seu catálogo de endereços.
Não deseja mais receber nossas mensagens? Cancele sua inscrição aqui:
http://emkt.epd.edu.br/emkt/tracer/?9,846080,c4b71992,b4d8

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

[Andrew Shadura]

Hello,

On Thu, 17 May 2012 16:52:02 +0200
Gergely Nagy  wrote:

> 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.

I find it a very bad idea, as then it's very hard to track what patches
we have applied. And no, VCS history doesn't help at all as we see
*all* the patches ever applied or not, and also upstream changes
sometimes. For that reason I prefer keeping patches themselves tracked
as well, or I even (mostly) unapply them so the source in the VCS is
clean.

-- 
WBR, Andrew


signature.asc
Description: PGP signature