gt; thing at a later stage.
>
> Heimdal has a bigger list of programs that will be affected:
>
> So I propose that we completely remove the following packages:
>
> heimdal-clients-x (contains xnlock, kx, tenletxr, rxtelnet, rxterm)
> heimdal-servers-x (contains kxd)
> he
Jelmer Vernooij writes:
> The following three are generic utilities, not particularly specific
> to Kerberos:
> /usr/bin/otp
> /usr/bin/otpprint
> /usr/bin/string2key
string2key is specific to Kerberos in that it provides a command-line
interface to the Kerberos string-to-key operation. That's
ld plan to do the similar thing to
Heimdal at about the same time. To avoid the possibility that people who
used these programs move to Heimdal, and then get annoyed if we do the same
thing at a later stage.
Heimdal has a bigger list of programs that will be affected:
So I propose that we comple
FWIW, I'm not seeing enough demand that I'm interested in maintaining
krb5-appl.
I plan to request removal.
If there's a debian developer who thinks I'm making the wrong call they
should feel free to turn my removal request into a request to adopt the
package.
--Sam
--
To UNSUBSCRIBE, email
Brian May writes:
> I haven't double checked what is supplied with krb5-appl, compared with
> the Heimdal packages.
It's considerably smaller. It provides krb5-clients (ftp, telnet, rsh,
rlogin, and rcp), krb5-ftpd, krb5-rsh-server, and krb5-telnetd.
> My understanding though is there is no ob
On 24 Jan 2014 03:33, "Sam Hartman" wrote:
> My proposal is to drop the package from the archive, but I wanted to
> give others a chance to shout out that I'm wrong and that there's some
> compelling use-case I've missed.
> If someone can convince me that the packages are useful I'm happy to
> spe
with the removal. Debian should really make itself obsolete by
> removing any option to do fast and secure enterprise login. ssh is the
> way to go for all, since all deserve slow and messy login performance.
> Now seriously... think about it: Is it *wise* to remove these utilities?
S
any more.
>
> I agree with the removal. http://www.debian.org/security/2011/dsa-2375 was
> already a sufficiently unpleasant christmas present (exploit was posted on
> on 24th December)
I agree with the removal. Debian should really make itself obsolete by
removing any option to do f
Brian May writes:
> On 28 January 2014 04:08, Russ Allbery wrote:
>> (And, regardless, the telnet implementation really needs to go away.)
> I don't know what problems telnet has, however I suspect you will find
> the Kerberos ftp to be equally as bad.
I believe ftp at least uses GSS-API and h
On 28 January 2014 04:08, Russ Allbery wrote:
> (And, regardless, the telnet implementation really needs to go away.)
>
I don't know what problems telnet has, however I suspect you will find the
Kerberos ftp to be equally as bad.
At one stage, I seem to recall there was a bug in heimdal ftpd th
Simon Toedt writes:
> If courses there is another issue: What still left as "use case" of
> Kerberos5 if krb-rsh and krb-rlogin are no longer available? Typical
> university setup is krb-NFSv3/krb-NFSv4 plus krb-rlogin internally and
> ssh only for external access.
I am quite dubious of this sta
Joshuah Hurst writes:
> Only in cases when Kerberos5 is not available. One major advantage over
> ssh is that krb5-rsh has much lower latency and overhead (in terms of
> used cpu time) when executing a plain /bin/true on a remote host, doing
> that in a loop over 1000 logins can take hours with
On Mon, Jan 27, 2014 at 11:27:52AM +0100, Simon Toedt wrote:
> Hint: Before further claiming the obsolesce of krb-rsh/rlogin vs ssh
> please try ssh on an ARM box (e.g gumstix) vs krb-rsh. ssh takes
> almost 2.6 seconds to complete (even with tuning and using arcfour),
> krb-rsh executes the same i
On Mon, Jan 27, 2014 at 1:05 AM, Philipp Kern wrote:
> On 2014-01-25 20:23, Joshuah Hurst wrote:
>>
>> One major advantage over ssh is that krb5-rsh has much lower latency
>> and overhead (in terms of used cpu time) when executing a plain
>> /bin/true on a remote host, doing that in a loop over 10
On 2014-01-25 20:23, Joshuah Hurst wrote:
One major advantage over ssh is that krb5-rsh has much lower latency
and overhead (in terms of used cpu time) when executing a plain
/bin/true on a remote host, doing that in a loop over 1000 logins can
take hours with ssh but takes minutes with krb-rsh.
On Thu, Jan 23, 2014 at 5:25 PM, Sam Hartman wrote:
>
>
> hi.
> A few months ago, Russ Allberry stepped down from co-maintaining
> krb5-appl.
> I'm reasonably happy to keep maintaining it, although when we thought
> about it, we cannot think of anyone using the package.
> It provides krb5 versions
Brian May schrieb:
> --001a11c1fd62df72e504f0aac077
> Content-Type: text/plain; charset=UTF-8
>
> On 24 January 2014 04:14, Jelmer Vernooij wrote:
>
>> > My proposal is to drop the package from the archive, but I wanted to
>> > give others a chance to shout out that I'm wrong and that there's som
consequence, the
current proposition is to remove the description of the Debian menu from the
Debian policy.
The last part describes how to associate media types with file extensions
through FreeDesktop menu entries, and how this system coexists with the mailcap
system. As the maintainer of the mime
On 24 January 2014 04:14, Jelmer Vernooij wrote:
> > My proposal is to drop the package from the archive, but I wanted to
> > give others a chance to shout out that I'm wrong and that there's some
> > compelling use-case I've missed.
> > If someone can convince me that the packages are useful I'm
On Thu, Jan 23, 2014 at 04:25:52PM +, Sam Hartman wrote:
> A few months ago, Russ Allberry stepped down from co-maintaining
> krb5-appl.
> I'm reasonably happy to keep maintaining it, although when we thought
> about it, we cannot think of anyone using the package.
> It provides krb5 versions o
hi.
A few months ago, Russ Allberry stepped down from co-maintaining
krb5-appl.
I'm reasonably happy to keep maintaining it, although when we thought
about it, we cannot think of anyone using the package.
It provides krb5 versions of rlogin, rsh, ftp and telnet.
The telnet is insecure and should
Guillem Jover writes ("Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to
remove "XS-" ?"):
> On Fri, 2014-01-03 at 19:40:54 +0100, Jakub Wilk wrote:
> > No, it just means that I gave up.
>
> Oh, ok. :/ Personally I see it has similar drawback
On Fri, 2014-01-03 at 19:40:54 +0100, Jakub Wilk wrote:
> * Guillem Jover , 2014-01-03, 13:13:
> >Given that you (at least) seemed to show opposition to the field
> >(AFAIR), and that you've done an independent implementation of the
> >runner; does 692704 mean that you changed mind?
>
> No, it jus
Hi,
On Freitag, 3. Januar 2014, Don Armstrong wrote:
> If I don't keep it somewhere, then someone could potentially upload a
> package named base.
>
> On the other hand, I'm not sure that it actually matters if someone was
> to upload such a package at some time in the future.
I cannot see any p
On Fri, 03 Jan 2014, Holger Levsen wrote:
> On Freitag, 3. Januar 2014, Don Armstrong wrote:
> > Instead of removing it, I'd like to just prominently mark it as
> > deprecated, and coordinate with reportbug to never show it as an option.
>
> why?
>
> and th
Hi Don,
On Freitag, 3. Januar 2014, Don Armstrong wrote:
> Instead of removing it, I'd like to just prominently mark it as
> deprecated, and coordinate with reportbug to never show it as an option.
why?
and then you'd want to remove the base package in 5 years or keep it foreve
On Fri, 03 Jan 2014, Holger Levsen wrote:
> http://qa.debian.org/data/bts/graphs/b/base.png and
> http://qa.debian.org/data/bts/graphs/g/general.png also underline my point.
Instead of removing it, I'd like to just prominently mark it as
deprecated, and coordinate with reportbug to never show it
* Guillem Jover , 2014-01-03, 13:13:
Given that you (at least) seemed to show opposition to the field
(AFAIR), and that you've done an independent implementation of the
runner; does 692704 mean that you changed mind?
No, it just means that I gave up.
--
Jakub Wilk
--
To UNSUBSCRIBE, email t
[ adding autopkgtest-devel to Cc: ]
On Fri, Jan 03, 2014 at 12:36:38PM +, Ian Jackson wrote:
> > FWIW, an old MBF about absent "Testsuite: autopkgtest" is at [1] and
> > looks halfway through completion. Some of the already resolved issues
> > were initially marked wontfix, but have then been
Stefano Zacchiroli writes ("Re: [DEP 8] About "XS-Testsuite: autopkgtest": time
to remove "XS-" ?"):
> To save others the time of doing this, in attachment the results of
> checking for debian/tests/control with apt-file and of grep-dctrl'ing
> Sources
Hi Jakub!
On Fri, 2013-12-27 at 17:35:28 +0100, Guillem Jover wrote:
> On Fri, 2013-12-27 at 17:41:26 +0900, Charles Plessy wrote:
> > the use of autopkgtest as documented in DEP 8 is taking momentum.
> >
> > How about allowing a "Testsuite" field to replace the "XS-Testsuite" field?
>
> Last ti
On Fri, Dec 27, 2013 at 06:09:51PM +0100, Niels Thykier wrote:
> On 2013-12-27 17:35, Guillem Jover wrote:
> > Do you know how many packages are there with autopkgtest support,
> > and how many do not declare the field?
>
> For the former, apt-file search -a source debian/tests/control should
> do
On 2013-12-27 17:35, Guillem Jover wrote:
> Hi!
>
> On Fri, 2013-12-27 at 17:41:26 +0900, Charles Plessy wrote:
>> the use of autopkgtest as documented in DEP 8 is taking momentum.
>>
>> How about allowing a "Testsuite" field to replace the "XS-Testsuite" field?
>
> Last time this came up here, i
On 27 December 2013 16:35, Guillem Jover wrote:
> Hi!
>
> On Fri, 2013-12-27 at 17:41:26 +0900, Charles Plessy wrote:
>> the use of autopkgtest as documented in DEP 8 is taking momentum.
>>
>> How about allowing a "Testsuite" field to replace the "XS-Testsuite" field?
>
> Last time this came up he
Hi!
On Fri, 2013-12-27 at 17:41:26 +0900, Charles Plessy wrote:
> the use of autopkgtest as documented in DEP 8 is taking momentum.
>
> How about allowing a "Testsuite" field to replace the "XS-Testsuite" field?
Last time this came up here, it didn't look like we got consensus on
whether the fie
Hello everybody,
the use of autopkgtest as documented in DEP 8 is taking momentum.
How about allowing a "Testsuite" field to replace the "XS-Testsuite" field?
If people like the idea, I can send a patch to dpkg if needed.
Have a nice day,
--
Charles Plessy
Illkirch-Graffenstaden, France
--
Le samedi 23 novembre 2013 à 14:22 -0500, Michael Gilbert a écrit :
> control: affects -1 src:poppler
>
> On Fri, Nov 22, 2013 at 3:56 AM, Josselin Mouette wrote:
> > I fully agree with Adrian that your “fix” is absolutely incorrect.
>
> Thanks for the feedback. I've canceled the nmu
No proble
control: affects -1 src:poppler
On Fri, Nov 22, 2013 at 3:56 AM, Josselin Mouette wrote:
> I fully agree with Adrian that your “fix” is absolutely incorrect.
Thanks for the feedback. I've canceled the nmu.
> It will temporarily make xpdf work again, and break many other packages
> that have bee
Hi Michael,
First of all, I apologize for not involving sooner. I did the upload
which was long overdue, but failed to check if there were RC bugs the
following days. I just learned about the issue.
Le vendredi 22 novembre 2013 à 06:48 +0200, Adrian Bunk a écrit :
> as I've already explained, th
moment to force your change into the archive
would be highly unfair.
And as I've already explained, there are two RC bugs open in
libfontconfig that actually seem to be bugs in libfontconfig - and
they are not addressed at all in your NMU.
Please remove your NMU from the delayed incoming
cause I wanted the actual firefox. I
> found the actual firefox way to install. It said remove iceweasel, i
> did, i installed firefox. It works, I went back to trying to
> installing wine unstable, well as I was getting usual errors, suddenly
> it says that 295 items are nolonger
Processing control commands:
> reassign -1 ftp.debian.org
Bug #719951 [general] general: Autoremove Wants to remove Entire system
Bug reassigned from package 'general' to 'ftp.debian.org'.
Ignoring request to alter found versions of bug #719951 to the same values
previous
Package: general
Severity: important
Dear Maintainer,
I was uninstalling Iceweasel cause I wanted the actual firefox. I found the
actual firefox way to install. It said remove iceweasel, i did, i installed
firefox. It works, I went back to trying to installing wine unstable, well as
I was
Lang: Perl
Description : module to remove the old module before installing the new
one
Module::Build::CleanInstall is a subclass of Module::Build with one
additional feature, before upgrading the module from and old version to a new
one, it first removes the files installed by the
: Artistic
Programming Lang: Perl
Description : Plugin to remove HTML for the Template Toolkit
This package provides a Template Toolkit plugin which uses HTML::Strip
to remove markup (primarily HTML, but also SGML, XML, etc) from filtered
content during template processing
--
To UNSUBSCRIBE
On 27.12.2012 07:27, piruthiviraj natarajan wrote:
I recently moved from Arch Linux to Debian Wheezy.
Is there any way to clean the apt cache for the packages that I am
not
currently using?
[...]
Is there anything obvious that I am missing here?
Yes - that debian-devel isn't a support list.
I recently moved from Arch Linux to Debian Wheezy.
Is there any way to clean the apt cache for the packages that I am not
currently using?
I tried using this config
root@localhost:~# cat /etc/apt/apt.conf
APT::Clean-Installed "0";
// auto-remove breaks on meta packages
APT::Get::Autom
On Sat, Aug 25, 2012 at 05:18:57PM +0900, Charles Plessy wrote:
> I also considered, but the information of what files are excluded when
> creating
> the Debian source package is not relevant to upstream.
>
> More simply, I think that if debian/watch would radically change its format to
> YAML or
an be specified in debian/gbp.conf. We routinely use it in
the OCaml team (see e.g. why).
I'm not sure whether I understand what you want to tell here. Do
you think git-import-orig should filter out / remove files mentioned
in debian/copyright field Files-Excluded?
I think he was mentioni
On Thu, Sep 06, 2012 at 03:36:11PM +0200, Mehdi Dogguy wrote:
>
> I think he was mentioning another method that helps maintainers to
> automatically clean the imported tarball when importing it. IIRC,
> this method has been added to git-import-orig circa DebConf9. Its
> use is very simple, IMHO. D
ed in debian/gbp.conf. We routinely use it in the OCaml
>> team (see e.g. why).
>
> I'm not sure whether I understand what you want to tell here. Do you
> think git-import-orig should filter out / remove files mentioned in
> debian/copyright field Files-Excluded?
No, I
it-import-orig, which
> can be specified in debian/gbp.conf. We routinely use it in the OCaml
> team (see e.g. why).
I'm not sure whether I understand what you want to tell here. Do you
think git-import-orig should filter out / remove files mentioned in
debian/copyright field Files-Excl
Le 17/08/2012 13:08, Andreas Tille a écrit :
> So we finally have three independently developed solutions (we also have
> several instances of a debian/get-orig-source script in Debian Med
> team) and my suggestion was just to settle with a common and simple
> solution. This should be pretty simpl
--
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/20120830225209.GA6550@pegase
On Sat, Aug 25, 2012 at 02:59:33PM +0200, gregor herrmann wrote:
> > The attached patch does the following:
>
> Attached are some patches based on devscipts+git plus your original
> patch.
I forgot to mention that my patch was also based on devscripts git and I
wonder whether somebody from the de
On Sat, Aug 25, 2012 at 12:34:28PM +0200, Jonas Smedegaard wrote:
> Hi Charles,
>
> On 12-08-25 at 01:03pm, Charles Plessy wrote:
> > a paragraph must not contain multiple instances of the same field.
>
> Interesting. Where is that defined?
Policy, 5.1, "Syntax of control files"
(http://www.deb
Hi Charles,
On 12-08-25 at 01:03pm, Charles Plessy wrote:
> a paragraph must not contain multiple instances of the same field.
Interesting. Where is that defined?
- Jonas
P.S.
I realize now that in this conversations I've wrongly used "section"
when referring to "paragraph", and "paragraph
On 12-08-24 at 01:06pm, Stefano Zacchiroli wrote:
> On Fri, Aug 24, 2012 at 12:33:09PM +0200, Jonas Smedegaard wrote:
> > > Files-Excluded:
> > > # ignore copy of lua
> > > lua_5.1.4/
> […]
> > Above means inventing a *new* syntax for files, instead of reusing
> > the existing one from Fil
Le Sat, Aug 25, 2012 at 07:24:06AM +0200, Andreas Tille a écrit :
> On Sat, Aug 25, 2012 at 01:03:03PM +0900, Charles Plessy wrote:
>
> > I also think that the current proposal would be a good opportunity to
> > transfer
> > the information about source location and excluded files in a separate f
On Sat, Aug 25, 2012 at 12:08:54PM +0900, Charles Plessy wrote:
> Le Fri, Aug 24, 2012 at 04:38:13PM +0200, Andreas Tille a écrit :
> >
> > 1. If (and only if) the debian/copyright file is
> >
> > Format:
> > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>
> I think th
On Sat, Aug 25, 2012 at 01:03:03PM +0900, Charles Plessy wrote:
> > So would be nice to check that the implementation properly includes all
> > of the following items:
> >
> > Format:
> > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> > Source: http://susy.oddbird.net/
> >
> On 12-08-22 at 09:39am, Paul Wise wrote:
> >
> > In comparison to the current method for repacking (debian/rules
> > get-orig-source), this doesn't allow per-file-set comments about why
> > the file-set is being removed. I often use this to document in more
> > detail why I am removing files. So
Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)"):
> On Fri, Aug 24, 2012 at 04:32:05PM +0100, Ian Jackson wrote:
> > Some of the information is machine-readable, and some is not. This is
> > o
Hi,
On Fri, Aug 24, 2012 at 04:32:05PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
> upstream source (Was: Minified javascript files)"):
> > On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
> >
Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)"):
> On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
> > Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
Package: devscripts
Version: 2.10.69+squeeze2
Severity: wishlist
Tags: patch
Hi,
in a (bit longish) thread on debian-devel@l.d.o[1] there was some
discussion about enabling uscan to remove files from upstream archives
according to some information given in some control file. There was no
real
Hi,
On Fri, Aug 24, 2012 at 01:37:18PM +0100, Ian Jackson wrote:
> Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
> upstream source (Was: Minified javascript files)"):
> > 1. The new field Files-Excluded in debian/copyright contains
>
> I
Andreas Tille writes ("Re: Enabling uupdate to simply remove files from
upstream source (Was: Minified javascript files)"):
> 1. The new field Files-Excluded in debian/copyright contains
> a space separated list of regular expressions.
> The deletion process w
On Fri, Aug 24, 2012 at 01:06:14PM +0200, Stefano Zacchiroli wrote:
> > Above means inventing a *new* syntax for files, instead of reusing the
> > existing one from Files: paragraphs.
>
> debian/control, which is 822-like, already supports #-comments. So,
> strictly speaking, we will just reusing
On Fri, Aug 24, 2012 at 12:42:43PM +0200, Jonas Smedegaard wrote:
|| On 12-08-24 at 11:31am, Andreas Tille wrote:
|| > when working on patches for uscan to implement the removal of files I
|| > stumbled upon one problem: What to do with dirty tarballs (which are
|| > unpacking all their files
On Fri, Aug 24, 2012 at 12:33:09PM +0200, Jonas Smedegaard wrote:
> > Files-Excluded:
> > # ignore copy of lua
> > lua_5.1.4/
[…]
> Above means inventing a *new* syntax for files, instead of reusing the
> existing one from Files: paragraphs.
debian/control, which is 822-like, already supp
On 12-08-24 at 11:31am, Andreas Tille wrote:
> when working on patches for uscan to implement the removal of files I
> stumbled upon one problem: What to do with dirty tarballs (which are
> unpacking all their files straight to the unpack directory and do not
> create a subdirectory). When I wr
On 12-08-24 at 11:16am, Andreas Tille wrote:
> Hi Paul,
>
> On Wed, Aug 22, 2012 at 09:39:00AM +0800, Paul Wise wrote:
> > On Tue, Aug 21, 2012 at 6:21 PM, Andreas Tille wrote:
> >
> > > Any further hints / remarks?
> >
> > In comparison to the current method for repacking (debian/rules
> > get-
On Fri, 24 Aug 2012, Andreas Tille wrote:
> do not create a subdirectory). When I write get-orig-source tarballs
> I always create a - directory and unpack the content
> to this. Should this be implemented as well or do you think it is
> better to change as less as possible?
You can always creat
On 12-08-24 at 11:28am, Andreas Tille wrote:
> On Fri, Aug 24, 2012 at 10:59:10AM +0200, Jonas Smedegaard wrote:
> > > Anyway, I thought I wanted a separate file, but then I remembered that
> > > uscan already uses 'debian/watch' for configuration. The syntax of a
> > > watch file is pretty awkw
Hi,
when working on patches for uscan to implement the removal of files
I stumbled upon one problem: What to do with dirty tarballs (which
are unpacking all their files straight to the unpack directory and
do not create a subdirectory). When I write get-orig-source tarballs
I always create a - d
On Fri, Aug 24, 2012 at 10:59:10AM +0200, Jonas Smedegaard wrote:
> > Anyway, I thought I wanted a separate file, but then I remembered that
> > uscan already uses 'debian/watch' for configuration. The syntax of a
> > watch file is pretty awkward, being based on (logical) lines rather
> > than
On Thu, Aug 23, 2012 at 05:15:35PM -0500, Peter Samuelson wrote:
> Well, two reasons not to bundle it into DEP-5 format files. First,
> there may be a lot of people like me who would find value in a
> config-file-driven 'get-orig-source' but who do not find any value in
> maintaining debian/copyri
Hi Paul,
On Wed, Aug 22, 2012 at 09:39:00AM +0800, Paul Wise wrote:
> On Tue, Aug 21, 2012 at 6:21 PM, Andreas Tille wrote:
>
> > Any further hints / remarks?
>
> In comparison to the current method for repacking (debian/rules
> get-orig-source), this doesn't allow per-file-set comments about wh
On 12-08-23 at 05:15pm, Peter Samuelson wrote:
>
> > > Automating get-orig-source is a fine idea, but tying it to DEP-5
> > > would be unfortunate.
>
> [Jonas Smedegaard]
> > You mean that you prefer a separate file for this info?
> >
> > What should be its name? What should be its syntax?
> >
On Thu, Aug 23, 2012 at 12:38:14PM -0500, Peter Samuelson wrote:
> ...Or add the exclude list to a file called 'debian/watch'.
I struggle to see why. I suppose because uscan reads debian/watch, but
the point of that file is to document where to find upstream sources,
the name implies that, and put
> > Automating get-orig-source is a fine idea, but tying it to DEP-5
> > would be unfortunate.
[Jonas Smedegaard]
> You mean that you prefer a separate file for this info?
>
> What should be its name? What should be its syntax?
>
> ...and why start from scratch with this - or does something els
* Jonas Smedegaard , 2012-08-23, 19:47:
This is valid DEP-5 syntax as well:
Format:
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: http://susy.oddbird.net/
Repackaged, excluding non-DFSG licensed fonts and source-less
JavaScript
# Exlude source-less JavaScript
Files-
On 12-08-23 at 12:27pm, Peter Samuelson wrote:
>
> [Jonas Smedegaard]
> > Format:
> > http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> > Source: http://susy.oddbird.net/
> > Repackaged, excluding non-DFSG licensed fonts and source-less
> > JavaScript
> > Files-Excluded:
>
[Peter Samuelson]
> And there is something to be said for the dpkg-source / debhelper
> style, in which each configuration parameter lives in its own tiny
> file (e.g., 'debian/source/format', 'debian/compat',
> 'debian/pyversions') rather than as fields of a larger file that is
> only tangentiall
[Jonas Smedegaard]
> Format:
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Source: http://susy.oddbird.net/
> Repackaged, excluding non-DFSG licensed fonts and source-less
> JavaScript
> Files-Excluded:
> docs/source/javascripts/jquery-1.7.1.min.js
> docs/source/j
On 12-08-21 at 12:21pm, Andreas Tille wrote:
> Regarding the implementation there was some uncertainity about the
> actual Perl module to use. In the attached example script I decided
> to stick to Dpkg::Control and left the code for Parse::DebControl as a
> comment which could pretty easily co
On 12-08-22 at 09:39am, Paul Wise wrote:
> On Tue, Aug 21, 2012 at 6:21 PM, Andreas Tille wrote:
>
> > Any further hints / remarks?
>
> In comparison to the current method for repacking (debian/rules
> get-orig-source), this doesn't allow per-file-set comments about why
> the file-set is being re
On Tue, Aug 21, 2012 at 6:21 PM, Andreas Tille wrote:
> Any further hints / remarks?
In comparison to the current method for repacking (debian/rules
get-orig-source), this doesn't allow per-file-set comments about why
the file-set is being removed. I often use this to document in more
detail why
On Tue, 2012-08-21 at 21:09:12 +0200, Andreas Tille wrote:
> On Tue, Aug 21, 2012 at 05:20:24PM +0200, Guillem Jover wrote:
> > See:
> >
> > /usr/share/doc/libdpkg-perl/README.api
> >
> > $ dpkg -L libdpkg-perl|grep 'Hash\.pm'|xargs grep VERSION
>
> It seems my assumption is not that wrong:
Charles Plessy writes:
> Le Tue, Aug 21, 2012 at 03:48:33PM +0200, Andrew Shadura a écrit :
>> By the way, how about adding something under debian/source/... to allow
>> automatic repacking regardless of Files-Excluded? (Or please tell me
>> how to repack upstream's zipball to targz automatically
Le Tue, Aug 21, 2012 at 03:48:33PM +0200, Andrew Shadura a écrit :
>
> By the way, how about adding something under debian/source/... to allow
> automatic repacking regardless of Files-Excluded? (Or please tell me
> how to repack upstream's zipball to targz automatically without having
> to specif
On Tue, Aug 21, 2012 at 05:20:24PM +0200, Guillem Jover wrote:
> > I don't get what you want to express:
> >
> > $ LANG=C apt-cache policy libparse-debcontrol-perl
> > $ LANG=C apt-cache policy libdpkg-perl
> >
> > Both modules have version >= 1.00.
>
> Module not package, sorry, I thought it w
On Tue, 2012-08-21 at 08:42:39 +0200, Andreas Tille wrote:
> On Tue, Aug 21, 2012 at 03:37:58AM +0200, Guillem Jover wrote:
> > On Mon, 2012-08-20 at 20:50:31 +0200, gregor herrmann wrote:
> > > Not sure how "official" my use of Dpkg::Control::Hash is, so maybe
> > > better stick to Jonas' proposal
On Tue, Aug 21, 2012 at 03:40:41PM +0200, olivier sallou wrote:
>
> Just a remark, it would be nice in this case to get a warning/log that
> some/all glob do not match to track changes in upstream tarballs (exclusion
> in previous release, then not needed anymore).
Yes. Uscan does print several
On Tue, Aug 21, 2012 at 12:21:21PM +0200, Andreas Tille wrote:
> Any further hints / remarks?
... just a big THANKS for helping the discussion in this thread and for
the draft code! I totally agree with Jakub that the main issue here is
that repackaging is a PITA, fixing the tools is the way to go
On Tue, Aug 21, 2012 at 03:48:33PM +0200, Andrew Shadura wrote:
>
> By the way, how about adding something under debian/source/... to allow
> automatic repacking regardless of Files-Excluded? (Or please tell me
> how to repack upstream's zipball to targz automatically without having
> to specify -
Hello,
On Tue, 21 Aug 2012 12:21:21 +0200
Andreas Tille wrote:
> 2. If files matching are contained in the source tarball this will
> be repackaged except if the option --no-exclusion is given at
> uscan command line or if USCAN_NO_EXCLUSION is set in
> /etc/devscripts.conf or ~/.de
2012/8/21 Andreas Tille
> Hi,
>
> third summary of the proposal
>
> 1. The new field Files-Excluded in debian/copyright contains a space
> separated list of globs (as used by find and for specifying file
> lists in machine readable debian/control files). The deletion
> process will l
Andreas Tille writes:
> On Tue, Aug 21, 2012 at 01:25:26PM +0200, Simon Josefsson wrote:
>> How about resolving the empty directory problem by permitting the
>> Files-Excluded to match directories? Thus, if you want to remove the
>> docs/source/fonts/ hierarchy, yo
201 - 300 of 1110 matches
Mail list logo
