On Mon, Aug 22, 2016 at 03:10:54PM -0700, pdbo...@cernu.us wrote:
> On top my problem- The situation we're encountering is that apt-get (and
> aptitude, fwiw) continuously want to upgrade an installed package that we
> maintain, even when the version, hash, etc., is not changed. This output
> de
Simon Richter wrote:
> On 21.08.2016 11:03, Josh Triplett wrote:
> > Mechanisms like shlibdeps, dh_perl, and other substvars allow packages
> > to compute their Depends at build time. This avoids hard-coding
> > dependencies, simplifies upgrading the package to new versions, and
> > makes transiti
Paul Wise wrote:
> This would be incredibly useful for moving towards a world of
> automatic packaging based on whatever metadata upstream is already
> providing for other package management formats.
>
> https://summit.debconf.org/debconf14/meeting/25/debdry-debian-dont-repeat-yourself/
> http://me
Hi All,
2016-05-28 23:16 GMT+02:00 Bálint Réczey :
> Hi,
>
> 2016-05-18 2:21 GMT+02:00 Guillem Jover :
>> On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote:
>>> I'm not a fan myself for turning on hardening flags in the compiler itself,
>>> but if you do that, then dpkg issues like https:
On 08/22/2016 07:12 PM, Bálint Réczey wrote:
> Hi Guillem,
>
> 2016-08-21 14:02 GMT+02:00 Guillem Jover :
>> Hi!
>>
>> On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>>> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for
>>> all
>>> arches and PIE for amd64, pp
Howdy!
First off, the usual- if this is not the correct list for an inquiry like
this, I sincerely apologize, and would greatly appreciate a pointer to the
correct list.
On top my problem- The situation we're encountering is that apt-get (and
aptitude, fwiw) continuously want to upgrade an ins
On Mon, 2016-08-22 at 13:26 +0100, Wookey wrote:
> I recently noticed that schroot could no longer tidy up chroots it had
> finished with. Much investigation with the help of debian Bug #749897
> revealed that there is a problem with the combination of schroot,
> systemd and demons that use the 'pr
(Cc's welcome.)
Hi,
Philipp Hahn (2016-08-19):
> Looking inside dpkg-name, it tries to evaluate "Package-Type" [1], but
> that is not contained in the control file of the binary package, so
> always evaluates to "deb":
> > 123 my $type = $fields->{'Package-Type'} || 'deb';
This field is onl
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-bioc-metagenomeseq
Version : 1.14.2
Upstream Author : Joseph N. Paulson
* URL :
http://www.bioconductor.org/packages/release/bioc/html/metagenomeSeq.html
* License : Artistic-2.0
Progra
Hi,
On 21.08.2016 11:03, Josh Triplett wrote:
> Mechanisms like shlibdeps, dh_perl, and other substvars allow packages
> to compute their Depends at build time. This avoids hard-coding
> dependencies, simplifies upgrading the package to new versions, and
> makes transitions much easier.
Package
Hi Guillem,
2016-08-21 14:02 GMT+02:00 Guillem Jover :
> Hi!
>
> On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for
>> all
>> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>>
>> My assumption
On Mon, Aug 22, 2016 at 08:10:40PM +0800, Paul Wise wrote:
> On Mon, Aug 22, 2016 at 6:55 PM, Ian Jackson wrote:
> > You're effectively asking for the interface to a Debian source package
> > to be redefined so that every package must be built twice: once to
> > discover its control file, and then
Hi,
Quoting Johannes Schauer (2016-08-22 14:58:36)
> Quoting Ian Jackson (2016-08-22 12:55:48)
> > But even worse is that it would no longer be possible to sensibly
> > compute build orders without pre-building every package in a source
> > archive, because it would not be possible to statically d
Johannes Schauer writes ("We cannot always know which source package to build
to satisfy a given dependency (was: Re: Computing Build-Depends at build time
(and other updates to debian/control)?)"):
> since you are talking about computing build orders and avoiding
> having to pre-build every sour
Package: wnpp
Severity: wishlist
Owner: Riku Voipio
* Package name: skales
Version : 0.20160202
Upstream Author : Stephen Boyd
* URL : git://codeaurora.org/quic/kernel/skales
* License : BSD (3 clause)
Programming Lang: Python and POSIX shel
Description
Hi,
Quoting Ian Jackson (2016-08-22 12:55:48)
> But even worse is that it would no longer be possible to sensibly
> compute build orders without pre-building every package in a source
> archive, because it would not be possible to statically determine
> which binary packages are supposed to come f
I recently noticed that schroot could no longer tidy up chroots it had
finished with. Much investigation with the help of debian Bug #749897
revealed that there is a problem with the combination of schroot,
systemd and demons that use the 'private mount namespace'
feature. (PrivateTmp=yes in the s
On Mon, Aug 22, 2016 at 6:55 PM, Ian Jackson wrote:
> You're effectively asking for the interface to a Debian source package
> to be redefined so that every package must be built twice: once to
> discover its control file, and then again to actually build the
> binaries.
This would be incredibly
On Fri, Aug 19, 2016 at 01:47:15PM +0200, Philipp Hahn wrote:
> Is there some other (preferred) way to identify .udeb packages?
>
> 1. "Section: debian-installer"?
>
> 2. Some pages use the suffix "-udeb" or "-di" in their package names.
>
> 3. If the control file contains a "isinstallable" scr
Ian Jackson writes ("Re: Computing Build-Depends at build time (and other
updates to debian/control)?"):
> If you want to catch failures of the maintainer to do the update, you
> can run your autogenerator in some kind of checking mode during
> debian/rules. The result will be that your package F
Josh Triplett writes ("Re: Computing Build-Depends at build time (and other
updates to debian/control)?"):
> Christoph Egger wrote:
> > Several packages create their control file from control.in during
> > maintainer build. You can have debian/control as a make dependency for
> > the package build
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-cairo
Version : 1.5-9
Upstream Author : Simon Urbanek
* URL : http://cran.r-project.org/web/packages/Cairo
* License : GPL
Programming Lang: GNU R
Description : GNU R graphics
22 matches
Mail list logo
