be consumed by humans.
>
> But if you decide not to use dgit you're back to source packages. It might
> be unnecessary to know in five years, in 2025 it is still a must-know and
> must-not-be-confused.
Unfortunately you're right... :)
Joost
Hi,
On Thu, May 29, 2025 at 09:39:01AM +0200, Marc Haber wrote:
> On Thu, May 29, 2025 at 05:26:31AM +0200, Joost van Baal-Ilić wrote:
> > On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
> >
> > > My personal pet peeve is the difference between the source package and the
> > > packagi
On Thu, May 29, 2025 at 09:52:38AM +0200, Joost van Baal-Ilić wrote:
A, indeed. Otoh the dgit-people feel a source package should be treated as an
intermediate build artifact; not something to be consumed by humans.
But if you decide not to use dgit you're back to source packages. It
Hi,
Quoting Steffen Möller (2020-07-04 13:24:36)
> I just skimmed through https://trends.debian.net/ and am impressed. Many
> thanks for these figures.
same from me! :)
> Do you accept wishes for additional graphs? Mine would be on the number of
> build dependencies as a scale for software comp
On 7/6/20 8:04 AM, Lucas Nussbaum wrote:
> Hi,
>
> On 04/07/20 at 13:24 +0200, Steffen Möller wrote:
>> Hello,
>>
>> I just skimmed through https://trends.debian.net/ and am impressed. Many
>> thanks for these figures.
>
> Thanks
>
>> Do you accept wishes for additional graphs?
>
> Sure
>
>>
On Sat, Jul 04, 2020 at 01:24:36PM +0200, Steffen Möller wrote:
> What is right in the open but I do not see discussed in this context is
> the sheer amount of packages that are added to the distribution. It is a
> raise from close to 1 to similarly close to 3 in a bit over 14
> years, so t
Hi,
On 04/07/20 at 13:24 +0200, Steffen Möller wrote:
> Hello,
>
> I just skimmed through https://trends.debian.net/ and am impressed. Many
> thanks for these figures.
Thanks
> Do you accept wishes for additional graphs?
Sure
> Mine would be on the number of build dependencies as a scale for
Hello,
I just skimmed through https://trends.debian.net/ and am impressed. Many
thanks for these figures. Do you accept wishes for additional graphs?
Mine would be on the number of build dependencies as a scale for
software complexity and how this evolved over time. My hunch is that
later softwa
…
>
> I wonder how someone should test their packages when they do
> not build it locally.
> And if they do (as they should), the advantages you line
> out are simply not there.
>
If you use `dpkg-buildpackage -b` to do your local tests, then the
advantage of not having to go near any source packages remains.
--
Sean Whitton
signature.asc
Description: PGP signature
Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was:
Re: [RFC] Proposal for new source format)"):
> I think I'd trust the tag2upload service given the documentation you
> presented about it. I'm less faithful in all dgit installations being
>
Hi Didier
On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> Of course, all of this can only work if we can have, or make the ".git to
> .dsc" conversion reproducible; hence my query.
Now, please read the first mail of this thread again. Yes, maybe parts
of it are unclear,
Hi Ian,
On Tue, Oct 29, 2019 at 12:54:57PM +, Ian Jackson wrote:
> I wonder if I have misunderstood you, because:
>
> The tag2upload proposal is based on dgit, which already provides this.
> dgit indeed defines an isomorphism between source packages and git
> trees, and dgi
Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was:
Re: [RFC] Proposal for new source format)"):
> In other words, I want these formats (source package and tagged git
> tree) to be isomorphic (minus history). This requirement is too strong
> sin
On 2019-10-29 08:32, Tobias Frost wrote:
On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:
(...)
For example, you would not be able to do this:
git clone salsa:something
cd something
make some straightforward change
git tag# } [1]
git push # }
Instead you would
Hi Ian,
On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:
(...)
> For example, you would not be able to do this:
>git clone salsa:something
>cd something
>make some straightforward change
>git tag# } [1]
>git push # }
> Instead you would have to download the
Hi Ian,
On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:
> The sticking point, as I understand it, is that this still does not
> allow dak to verify that the *contents* of the .dsc were as intended
> by the uploading human. [0]
>
> In the tag2upload proposal, the conversion from git t
On October 28, 2019 5:53:00 PM UTC, Ian Jackson
wrote:
>Scott Kitterman writes ("Re: Building Debian source packages
>reproducibly (was: Re: [RFC] Proposal for new source format)"):
>> Effectively tag2upload would replace DAK as the entry point for
>> packages into
Didier 'OdyX' Raboud writes ("Building Debian source packages reproducibly
(was: Re: [RFC] Proposal for new source format)"):
> Where I'm coming from is that we were discussing the tag2upload
> problem at miniDebConf Vaumarcus. [...]
I appreciate your efforts to
Scott Kitterman writes ("Re: Building Debian source packages reproducibly (was:
Re: [RFC] Proposal for new source format)"):
> Effectively tag2upload would replace DAK as the entry point for
> packages into the archive (the equivalent to the current source
> package signature
one by now I think it's reasonable to assume
>> > it's difficult, and thinking that it's so is not excessively
>> > pessimistic.
>>
>> Generating a reproducible source package given a particuar git commit
>> is trivial. All you have to do is use
On Monday, October 28, 2019 9:45:36 AM EDT Theodore Y. Ts'o wrote:
> On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> > Where I'm coming from is that we were discussing the tag2upload problem at
> > miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are
> > (c
On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> Where I'm coming from is that we were discussing the tag2upload problem at
> miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are
> (currently) not going to accept .dscs built reproducibly by a (even trusted
ting a reproducible source package given a particuar git
> > commit
> > is trivial. All you have to do is use "git archive". For example:
>
> When talking about upstream projects, sure.
>
> But generating Debian source packages (.dsc and friends) from a
> `deb
t it's so is not excessively
> > pessimistic.
>
> Generating a reproducible source package given a particuar git commit
> is trivial. All you have to do is use "git archive". For example:
When talking about upstream projects, sure.
But generating Debian source packag
Hi Ansgar,
On Wed, Oct 23, 2019 at 08:32:11AM +0200, Ansgar wrote:
> I believe bugs should always be assigned to source packages as source
> packages are really the unit we use to keep track of packages.
Since the thread seems largly in favour of this, let me strongly
disagree.
I exten
On 2019-10-27, Ansgar wrote:
> We have usertags and other mechanisms that allow grouping bugs in
> maintainer-defined ways. This is also used by pseudo-packages where we
> don't have "binaries" to group bug reports by.
But that moves the "default" work, where users is right at least more
than 50
Sune Vuorela writes:
> On 2019-10-23, Ansgar wrote:
>> So I'm wondering if we should start just filing all bug reports against
>> source packages? Reportbug could probably be easily changed to use
>> `Source: ...` instead of `Package: ...`; more places could follo
Guillem Jover writes:
> On Wed, 2019-10-23 at 08:32:11 +0200, Ansgar wrote:
>> the thread about naming (source) packages reminded me of an other thing:
>> Debian's bug tracking system currently (mostly) tracks bugs against
>> binary packages and (less often) against sou
On Wed, Oct 23, 2019 at 2:32 PM Ansgar wrote:
> It gets confused if a source & binary package with the same name, but
> otherwise unrelated exist; or when the same binary is built from
> different sources on different architectures; or when binary and source
> versions don't match (version trackin
On 10/23/19 11:53 PM, Moritz Mühlenhoff wrote:
> Fully agreed. It's also hard for users to pinpoint the correct binary
> package and they tend to get stale with changes to binary names anyway
> (soname changes to libs etc.)
I think its easier for users to find the binary package name, as the
pa
Hi!
On Wed, 2019-10-23 at 08:32:11 +0200, Ansgar wrote:
> the thread about naming (source) packages reminded me of an other thing:
> Debian's bug tracking system currently (mostly) tracks bugs against
> binary packages and (less often) against source packages.
> It gets con
On 2019-10-23, Ansgar wrote:
> So I'm wondering if we should start just filing all bug reports against
> source packages? Reportbug could probably be easily changed to use
> `Source: ...` instead of `Package: ...`; more places could follow later.
Have you ever maintained source pa
On Mi, 23 oct 19, 08:32:11, Ansgar wrote:
>
> Reportbug could probably be easily changed to use
> `Source: ...` instead of `Package: ...`; more places could follow later.
Beware of #721793, though I'm guessing the reportbug maintainer is aware
that 'Source: ' doesn't do what o
Ansgar schrieb:
> the thread about naming (source) packages reminded me of an other thing:
> Debian's bug tracking system currently (mostly) tracks bugs against
> binary packages and (less often) against source packages.
>
> It gets confused if a source & binary package
Quoting Gianfranco Costamagna (2019-10-24 12:31:51)
> I agree.
>
> With python2 being removed, we will have a lot of
> "src:python-foo" providing only a "bin:python3-foo"
> so this confusion will be even more a problem...
> (will we ever rename also source pa
I agree.
With python2 being removed, we will have a lot of
"src:python-foo" providing only a "bin:python3-foo"
so this confusion will be even more a problem...
(will we ever rename also source packages now that python2 is going to be
removed?)
Gianfranco
On Wed, Oct 23, 2019 at 08:32:11AM +0200, Ansgar wrote:
> So I'm wondering if we should start just filing all bug reports against
> source packages? Reportbug could probably be easily changed to use
> `Source: ...` instead of `Package: ...`; more places could follow later.
I a
Hi,
the thread about naming (source) packages reminded me of an other thing:
Debian's bug tracking system currently (mostly) tracks bugs against
binary packages and (less often) against source packages.
It gets confused if a source & binary package with the same name, but
otherwise
ease use domain-specific names for source packages,
>> to leave names available in generic namespace when possible.
>
> a.) I agree with your proposal, Jonas. Thank you for bringing it up.
> b.) patches for #253511 "provide guideline to keep the package namespace sane"
Hi!
On Tue, 2019-10-22 at 20:05:28 +0200, Jonas Smedegaard wrote:
> Let us please all name new source package same as main binary package
> (not same as upstream project).
I'm not sure, as is, this is a good general rule. I'd reword as, we
should always namespace source packag
On Tue, Oct 22, 2019 at 08:05:28PM +0200, Jonas Smedegaard wrote:
> Let us please all name new source package same as main binary package
> (not same as upstream project).
[...]
> Therefore: Can we please use domain-specific names for source packages,
> to leave names availabl
Hi all,
Let us please all name new source package same as main binary package
(not same as upstream project).
I am concerned about the practice of naming source packages after
upstream projects, seemingly common at least for Python packages.
Problem is needlessly leads to unintuitive package
Daniel Kahn Gillmor writes ("Re: Discussion on eventual transition away from
source packages"):
> On Fri 2019-03-22 09:32:55 +0100, Lucas Nussbaum wrote:
> > I'm probably missing something, but it doesn't sound like a lot of work
> > to me? It's "jus
Daniel Kahn Gillmor writes:
> On Fri 2019-03-22 09:32:55 +0100, Lucas Nussbaum wrote:
>> I'm probably missing something, but it doesn't sound like a lot of work
>> to me? It's "just" a service that:
>> - gets notified of the existence of a git repo + tag to upload
>> - fetches that git repo + tag
On Fri 2019-03-22 09:32:55 +0100, Lucas Nussbaum wrote:
> I'm probably missing something, but it doesn't sound like a lot of work
> to me? It's "just" a service that:
> - gets notified of the existence of a git repo + tag to upload
> - fetches that git repo + tag
> - checks signature / confirm that
> "Alex" == Alex Bennée writes:
Alex> Hi,
Alex> The following bug has come up and we would like some input
Alex> from the multiarch and cross developers on how best to handle
Alex> this case.
Alex> In an ideal world all cross compilers would be available on
Alex> all
Hi,
The following bug has come up and we would like some input from the
multiarch and cross developers on how best to handle this case.
In an ideal world all cross compilers would be available on all release
architectures but I think it will be a while before we get there. My own
efforts to get
Ansgar Burchardt writes ("Maintainer information in source packages (was: Re:
Returning to the requirement that Uploaders: contain humans)"):
> as a more radical change one could also ask the question where to
> maintain the maintainer information. Currently we handle this
Hello,
On Fri, 04 Aug 2017, Ansgar Burchardt wrote:
> So I have been wondering several times whether we should move the
> maintainer information elsewhere. For example, tracker.d.o could be
> extended to record maintainer information. It could also understand
> the concept of "teams" listing tea
Hi,
Ansgar Burchardt wrote:
> as a more radical change one could also ask the question where to
> maintain the maintainer information. Currently we handle this in the
> source package via the Maintainer and Uploaders field, and via team
> memberships.
>
> This has several limitations: for teams,
On Fri, Aug 4, 2017 at 6:10 AM, Ansgar Burchardt wrote:
> So I have been wondering several times whether we should move the
> maintainer information elsewhere. For example, tracker.d.o could be
> extended to record maintainer information. It could also understand
> the concept of "teams" listing
On Fri, 04 Aug 2017 at 12:10:03 +0200, Ansgar Burchardt wrote:
> So I have been wondering several times whether we should move the
> maintainer information elsewhere. For example, tracker.d.o could be
> extended to record maintainer information. It could also understand
> the concept of "teams" l
Hi,
as a more radical change one could also ask the question where to
maintain the maintainer information. Currently we handle this in the
source package via the Maintainer and Uploaders field, and via team
memberships.
This has several limitations: for teams, Uploaders will often be
useless (yo
Z
Sent from my iPhone
Am Samstag, 29. November 2014, 10:49:34 schrieb Martin Steigerwald:
> Am Donnerstag, 27. November 2014, 16:50:12 schrieb Neil Williams:
> > On Thu, 27 Nov 2014 16:24:12 +0100
> >
> > Matthias Urlichs wrote:
> > > Hi,
> > >
> > > Neil William
Am Donnerstag, 27. November 2014, 16:50:12 schrieb Neil Williams:
> On Thu, 27 Nov 2014 16:24:12 +0100
>
> Matthias Urlichs wrote:
> > Hi,
> >
> > Neil Williams:
> > > By having separate source packages, a stable API becomes mandatory.
> >
> > Yo
Hi,
Neil Williams writes:
> Atually, not particularly thinking of systemd at this point, but in
> *general* there is a good technical advantage to this approach:
> migrations & dependency control. It avoids the "fingers in every pie"
> problem common to a number of
On Thu, 27 Nov 2014 16:24:12 +0100
Matthias Urlichs wrote:
> Hi,
>
> Neil Williams:
> > By having separate source packages, a stable API becomes mandatory.
>
> You're correct in that it is easier to keep an API stable when you
> have separate repositories. But t
Hi,
Neil Williams:
> By having separate source packages, a stable API becomes mandatory.
You're correct in that it is easier to keep an API stable when you have
separate repositories. But that is not a hard requirement. There are other
ways to keep APIs stable. Like, for instance, publ
y instead of five,
> but what (technical) problem would having five repos and five Debian
> source packages, instead of one, actually solve?
Actually, not particularly thinking of systemd at this point, but in
*general* there is a good technical advantage to this approach:
migrations & depe
Just installed debian on an old amd32 platform, it booted in 4-5 seconds !:)
debian + GNU base, love it
debian is one of the last dists to create a no fuzz installer, only installer
that is tolerable to me
so I hope the baseinstall will be made even more non-gui in the future
and perhaps apt-ge
On Mon, Jun 9, 2014 at 6:18 AM, Wookey wrote:
> telnet is still very useful for various things.
I use telnet a lot but I would never ever install telnetd. Can you
share some use-cases for telnetd?
> And packages don't
> _have_ to have vcs repositories - they can just have good
> old-fashioned ta
+++ Paul Wise [2014-06-08 11:06 +0800]:
> On Sat, Jun 7, 2014 at 6:59 AM, Pedro DeKeratry wrote:
>
> > Anyway, I can't seem to find where to clone from. help?
>
> Normally one would clone from and send patches to upstream but this
> doesn't appear to have an active upstream and there doesn't appe
On Sat, Jun 7, 2014 at 6:59 AM, Pedro DeKeratry wrote:
> Anyway, I can't seem to find where to clone from. help?
Normally one would clone from and send patches to upstream but this
doesn't appear to have an active upstream and there doesn't appear to
be an upstream repository. Also the telnet pro
On Fri, 06 Jun 2014 20:47:31 -0700
tony mancill wrote:
> You could create a suitable local repo with all of the version history with:
>
> git-import-dscs --debsnap netkit-telnet
Oh, I didn't know about debsnap, it's very very useful to create git
repository. Thanks, tony! (and author David :)
On Jun 7, 2014 9:32 PM, "Pedro DeKeratry"
wrote:
> I really didn't expect there not to be an official maintainer repo :D
>
It's up to the maintainer whether using a public VCS repository or not for
its packaging activities. I'm for somehow enforcing this, but maybe it's
not the case.
Tony,
I'll give the git-import-dscs method a shot. I really didn't expect there
not to be an official maintainer repo :D
Thanks.
On Fri, Jun 6, 2014 at 10:47 PM, tony mancill wrote:
> On 06/06/2014 06:05 PM, Ben Hutchings wrote:
> > On Fri, 2014-06-06 at 17:59 -0500, Pedro DeKeratry wrote:
>
On 06/06/2014 06:05 PM, Ben Hutchings wrote:
> On Fri, 2014-06-06 at 17:59 -0500, Pedro DeKeratry wrote:
>> I wish to rebuild telnetd package with some slight mods for an
>> embedded application, and I want to keep my changes on a branch off
>> the maintainer line.
>>
>> Anyway, I can't seem to fin
On Fri, 2014-06-06 at 17:59 -0500, Pedro DeKeratry wrote:
> I wish to rebuild telnetd package with some slight mods for an
> embedded application, and I want to keep my changes on a branch off
> the maintainer line.
>
> Anyway, I can't seem to find where to clone from. help?
There appears to be n
I wish to rebuild telnetd package with some slight mods for an embedded
application, and I want to keep my changes on a branch off the maintainer
line.
Anyway, I can't seem to find where to clone from. help?
--Pedro
Hi,
Not a very useful fact:
Since 2014-01-25, we have more than 20,000 source packages in Debian
unstable (main only).
(That's with unique source packages names; we had more than 20,000
source packages in unstable/main for a while already, but there were
some duplicate ones with diff
Wookey wookware.org> writes:
> Do I understand this correctly - that it prevents a package
> cross-binutils-0.1 to generate binaries called
> binutils-arm-linux-gnueabi-2.24-3
> binutils-arm-linux-gnueabihf-2.24-3
Actually, these packages will be buggy usually: debhelper uses
the source version
On Mon, 10 Feb 2014 22:13:45 +0100
Wouter Verhelst wrote:
> Sigh.
>
> On Wed, Feb 05, 2014 at 12:59:23PM +, Neil Williams wrote:
> > Using packages to support upstream development is a common problem
/common problem/common source of problems/
> > and this is exactly where things get awkwar
Sigh.
On Wed, Feb 05, 2014 at 12:59:23PM +, Neil Williams wrote:
> Using packages to support upstream development is a common problem and
> this is exactly where things get awkward.
No, it is not a *problem*; it is a *method* of doing things.
It is not your place (nor mine) to question anoth
> "Bernhard" == Bernhard R Link writes:
As I mentioned I have a packaging branch and an upstream branch.
I wish to use debian revisions to reflect packaging changes.
It's slightly more complex than changes to debian directory involve a
debian revision change; changes to other things involve
* Charles Plessy [140205 14:18]:
> Who benefited directly from the change of behavior ? Nobody ? Then please
> revert it; it was not necessary.
Most import are people starting to create Debian packages.
At least with 3.0 source packages they no longer have to care about the
different me
* Sam Hartman [140205 13:27]:
> no, that means I have to maintain the artifact (namely the
> .orig.tar.gz).
> The archive software (both reprepro and dak were I to use that) require
> that the .orig.tar.gz not change checksums.
>
> I don't want my build machines to be able to push back to my mast
its for daily builds is a worse solution than
3.0(native) or not including source packages in the resulting Debian
archive.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http:
Le Wed, Feb 05, 2014 at 12:46:09PM +0100, Andreas Beckmann a écrit :
>
> All this sounds like it can be done with git-buildpackage
Hello everybody,
I have the impression that we are arguing because of solution in search for a
problem.
Some things worked with the previous version of dpkg, with n
On Wed, 5 Feb 2014 12:21:30 +
Sam Hartman wrote:
> > "Andreas" == Andreas Beckmann writes:
>
> Andreas> On 2014-02-05 10:57, Sam Hartman wrote:
> >> tarballs useful; anyone who is likely to want to build this
> >> from source probably has a copy of git and can checkout a tag
> "Andreas" == Andreas Beckmann writes:
Andreas> On 2014-02-05 10:57, Sam Hartman wrote:
>> tarballs useful; anyone who is likely to want to build this from
>> source probably has a copy of git and can checkout a tag.
Andreas> Such a tag corresponds to an upstrema version?
y
On 2014-02-05 10:57, Sam Hartman wrote:
> tarballs useful; anyone who is likely to want to build this from source
> probably has a copy of git and can checkout a tag.
Such a tag corresponds to an upstrema version?
> I'm happy to entertain other options rather than 3.0(native) but my
> requirement
control: subscribe -1
> "Charles" == Charles Plessy writes:
Charles> The 3.0 (native) format is useful when packaging a work
Charles> that is developped and distributed in a Git repository.
Charles> Please leave us this possibility.
Let me describe the use case I have which is
On Wed, Feb 5, 2014 at 12:08 AM, Charles Plessy wrote:
> The 3.0 (native) format is useful when packaging a work that is developped and
> distributed in a Git repository. Please leave us this possibility.
Can you elaborate a bit? From my understanding of your description I'd
consider your (git)
Le Tue, Feb 04, 2014 at 02:05:45PM +, Dimitri John Ledkov a écrit :
> On 4 February 2014 13:38, Jakub Wilk wrote:
> > * Dimitri John Ledkov , 2014-02-04, 13:30:
> >
> >> Enforcing Debian Policy at dpkg-source -b . level, is not a good idea,
> >> especially when it breaks backwards compat for 3
On 4 February 2014 16:20, Wookey wrote:
> +++ Dimitri John Ledkov [2014-02-04 13:30 +]:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
>
> Do I understand this correctly - that it prevents a package
> cross-binutils-0.1 to generate binaries called
No, you can still generate any bi
On Tue, 4 Feb 2014 16:20:28 +, Wookey wrote:
> +++ Dimitri John Ledkov [2014-02-04 13:30 +]:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
>
> Do I understand this correctly - that it prevents a package
> cross-binutils-0.1 to generate binaries called
> binutils-arm-linux-g
+++ Dimitri John Ledkov [2014-02-04 13:30 +]:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
Do I understand this correctly - that it prevents a package
cross-binutils-0.1 to generate binaries called
binutils-arm-linux-gnueabi-2.24-3
binutils-arm-linux-gnueabihf-2.24-3
unless cros
Dimitri John Ledkov writes ("Re: dpkg-dev: please reject native/non-native
version when building native/non-native source packages"):
> Patch is attached to the new bug filed about this issue
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634
> Proposed patch adds &q
Dimitri John Ledkov writes ("RE: dpkg-dev: please reject native/non-native
version when building native/non-native source packages"):
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
...
> Can this be reverted, or dpkg-source option provided to override this
> ne
On 4 February 2014 13:38, Jakub Wilk wrote:
> * Dimitri John Ledkov , 2014-02-04, 13:30:
>
>> Enforcing Debian Policy at dpkg-source -b . level, is not a good idea,
>> especially when it breaks backwards compat for 3rd parties. We have lintian,
>> and ftp-master lintian auto-rejects to clense the
* Dimitri John Ledkov , 2014-02-04, 13:30:
Enforcing Debian Policy at dpkg-source -b . level, is not a good idea,
especially when it breaks backwards compat for 3rd parties. We have
lintian, and ftp-master lintian auto-rejects to clense the archive if
so is desired.
Hear, hear. And I even dou
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
How to override this new behaviour that breaks backwards compatibility
of existing packages that (abuse) these bad version numbers?
It appears to be enforcing a "Debian Project Policy" onto packages
which are not in Debian.
Can this be reve
Thanks for the link.
The numbers I got from Zack are similar.
Jan.
On Tue, Feb 4, 2014 at 12:02 AM, Michael Tautschnig wrote:
> Hi Jan,
>
> >it's a too big a job to do by myself, and maybe the answer already
> exists:
> >
> >When I would download all
Hi Jan,
>it's a too big a job to do by myself, and maybe the answer already exists:
>
>When I would download all Debian source packages, extract them, determine
> of each the programming language it is written in and the SLOC, what would be
> the percentages of each
On Mon, Feb 03, 2014 at 12:57:01PM +0100, Jan de Haan wrote:
>When I would download all Debian source packages, extract them, determine
> of each the programming language it is written in and the SLOC, what would be
> the percentages of each programming language used?
The Debsources
Hi All,
it's a too big a job to do by myself, and maybe the answer already exists:
When I would download all Debian source packages, extract them, determine
of each the programming language it is written in and the SLOC, what would be
the percentages of each programming language
> You can disagree with this approach. However, in my 10+ experience
> setting up security gateways for Internet traffic (mostly for
> HTTP/FTP/SMTP) I've seen only a few vulnerabilities in the gateways
> themselves. Many of the gateways I have deployed are either network
> appliances with a Commo
On 18 October 2013 12:41, Kevin Chadwick wrote:
>> I have to join Marc here and say "me too". In my organisation we
>> actually have those controls in place (antivirus/antimalware) in the
>> Internet gateways and we do not disable them for specific traffic
>> flows unless a detailed risk analysis
On Fri, 18 Oct 2013, Thorsten Glaser wrote:
> On Tue, 15 Oct 2013, Thijs Kinkhorst wrote:
> > I'm still not sure why the virus contained in the source could not be
> > replaced by the EICAR test signature.
>
> Because it’s not testing a virus scanner, but because the
> specific RFC822 message in q
1 - 100 of 470 matches
Mail list logo
