nety_rule
> > > > From 5a861d19b1610ae82bf95e6c5142a3365436fbd2 Mon Sep 17 00:00:00 2001
> > > > From: Steve Langasek
> > > > Date: Fri, 2 Jun 2023 14:30:20 +
> > > > Subject: [PATCH 1/3] lfs and time64 are no longer "future", call them
> &
Hi,
I wanted to check in on the status of this.
On Fri, Jun 09, 2023 at 03:56:28AM +0200, Guillem Jover wrote:
> On Mon, 2023-06-05 at 21:18:10 -0700, Steve Langasek wrote:
> > Package: dpkg-dev
> > Version: 1.21.22
> > Tags: patch
> > User: ubuntu-de...@lists.ubun
.
I'm not sure whether you were persuaded that i386 should stay with the
current ABI, but anyway thought I would propose the patches and we could
discuss further if necessary.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to s
feature=+time64 should also emit
-Wno-implicit-function-declaration; cc:ing the bug on dpkg regarding
implementation of that interface.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Dev
our patches downstream
in Ubuntu only, and handle new Debian package versions via a manual merge.
There is no need for a third workflow to accommodate improperly-upstreamed
patches and breaking the behavior of dpkg-source.
--
Steve Langasek Give me a lever long enough and a Free O
vendor series files. It's not how any
downstream is actually managing their delta from Debian.
> We are actively working on the relevant processes and tools right now.
> Let's see what things look like once we reach the end of that work
> before escalating this bug anywhere.
--
St
l not be fixed in stretch)
>
> (And the consequential lintian change.)
>
> I am not yet supplying patches for dpkg-source and for policy, because
> I think deprecating this feature will involve some discussion.
Seconded (the sentiment, and specifically the requested policy
1
Er, read the version number. This is trying to configure the *stable*
version of the lmodern package. This has nothing to do with
dpkg-maintscript-helper, which is only applied in the *testing* version of
the package.
--
Steve Langasek Give me a lever lo
er state than if you'd just removed the files
entirely; so it's really only interesting if you're going to stash the
replaced files somewhere that they can be restored when the replacing
package is removed.
> Attached a new patch.
Makes sense to me.
--
Steve L
re
> after lunch.
Right, this should be entirely legitimate. Diverting the PI is an extreme
case (and one we've had to work around differently since we can't rely on
dpkg in previous releases to handle this), but it illustrates why it's
important to be consistent in application o
On Wed, Apr 04, 2012 at 08:53:45AM +0200, Helmut Grohne wrote:
> On Tue, Apr 03, 2012 at 04:23:17PM +, Kamble, Nitin A wrote:
> > Thanks for catching the typo. We use "x86_64-linux-gnux32"
> Thanks for the quick reply.
> On IRC Steve Langasek pointed out that so
On Sun, Oct 09, 2011 at 09:27:14PM +0200, Raphael Hertzog wrote:
> severity 609159 wishlist
> merge 609159 644791
> thanks
> On Sat, 08 Oct 2011, Steve Langasek wrote:
> > It would be helpful if dpkg-shlibdeps supported an environment variable to
> > make this warni
ed
to subdirectories (!$in_public_dir) are handled separately, I would like to
see this made an error by *default* in Debian.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the wor
On Thu, Sep 29, 2011 at 09:28:11PM +0200, Raphael Hertzog wrote:
> On Thu, 29 Sep 2011, Steve Langasek wrote:
> > FWIW, the previous Ubuntu LTS release included tar 1.22, so using a
> > pre-dependency in Debian probably means Ubuntu will have to carry a delta
> > for this f
this for 12.04. A solution that works for both Debian and Ubuntu would
be welcome.
I don't see any reason that this pre-dependency would be a problem for
Debian itself given that the required version of tar is in squeeze.
--
Steve Langasek Give me a lever long enough and a
On Wed, Sep 28, 2011 at 06:16:47AM +0200, Guillem Jover wrote:
> On Tue, 2011-09-27 at 16:26:10 -0700, Steve Langasek wrote:
> > I've recently spent time having to clean up after a package which earlier in
> > its history called update-alternatives --set from a maintainer
think there's any justification for a package ever calling u-a --set
from a maintainer script. Therefore I propose that this command abort if
$DPKG_MAINTSCRIPT_PACKAGE is set.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Sun, Sep 25, 2011 at 07:11:00PM +0200, Raphael Hertzog wrote:
> (Just clarifying a detail)
> On Sat, 24 Sep 2011, Steve Langasek wrote:
> > A patch to make this an optional feature, without some plan for how we can
> > get this turned on by default (either in dpkg-dev, or in
out some plan for how we can
get this turned on by default (either in dpkg-dev, or in debhelper where it
would benefit the majority of packages) is not worth the effort. We've had
an opt-in way of doing this for years:
DEB_CFLAGS_MAINT_APPEND := $(shell getconf LFS_CFLAGS)
And the uptake ha
fully coordinated.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com
t takes longer. (Multiarch in
> general is an example of this).
I don't see either of these to be technically better or worse. The fact is
that we are going to *have* to document multiple points where our directory
strings do not follow naturally from the existing array of GNU triplets; and
tha
lease. If we can (collectively) get our decision made on
the path selection *now*, that's achievable - and we can be rid of ia32-libs
from Debian (unstable) and Ubuntu within a year, and we can bring armhf up
as the first multiarch-from-the-start port in Debian. If we instead
would like to see this
> better addressed in Linaro and/or upstream.
I'm not sure how Linaro could better address this, short of persuading
upstream to allocate a separate triplet for armhf - which has been
explicitly refused on the upstream mailing list. Do you have something else
in
for discussion in Debian? Should I bring this up on the
debian-embedded list? Are there other stakeholders who would have input
regarding the array of available uclibc ABIs and how to specify these?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
De
y.
So even if you persuaded the upstream toolchain folks to specify a new
triplet for armhf after all, I think we should still go ahead with a
separate name mapping table for multiarch.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
reassign 560317 debconf
thanks
On Thu, Dec 10, 2009 at 04:27:28PM +0100, Norbert Preining wrote:
> reassign 560317 dpkg
> retitle 560317 dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
> thanks
> On Do, 10 Dez 2009, Steve Langasek wrote:
> > I think this shoul
for such changes. Otherwise, we end up with maintainers
blindly believing that everything in the LSB init script spec is a good
idea, including things like this gem from 20.8:
Conforming scripts shall not specify the "exit on error" option (i.e. set
-e) when sourcing this file, or ca
undation.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
That one's starting to get up there right next to "our priorities are our
users and free software" on my list of Facile Arguments That Demonstrate The
Poster Has No Clue. :P
--
Steve Langasek
On Sun, Jan 06, 2008 at 02:29:22PM +0100, Raphael Hertzog wrote:
> On Sat, 05 Jan 2008, Steve Langasek wrote:
> > > [EMAIL PROTECTED] 2.2
> [...]
> > Perhaps to limit the possibilities of abuse, wildcards should only be
> > supported in symbol names if there's an a
e upstreams (like glibc or some gcc libs) but I'd like to have
> the opinion of others too.
Perhaps to limit the possibilities of abuse, wildcards should only be
supported in symbol names if there's an accompanying symbol version (with no
wildcard expansion)?
--
Steve Langasek
On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote:
> On Sat, Sep 29, 2007 at 10:09:19PM +0200, Frank Lichtenheld wrote:
> > On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> > > Attached is a patch to dpkg which implements a check for a 'b
On Tue, Jul 03, 2007 at 06:07:54PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep
> targets for lenny?"):
> > Attached is a patch to dpkg which implements a check for a 'build-arch'
> > target using 'm
On Tue, Jul 03, 2007 at 09:54:03AM +0200, Adam Borowski wrote:
> On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> > I believe the attached patch has the following characteristics:
> > - Behavior on systems where 'make' is not GNU make is undefined.
>
version of dpkg-dev introducing these semantics.
Documenting this in policy should be straightforward if these changes to
dpkg are accepted.
Lucas has agreed to doing a full archive rebuild with a modified dpkg-dev,
for comparison with the previous test. A dpkg-dev binary including this
change
job --
unpacking a package -- so I don't think 'serious' is the right severity
here. Indeed, AFAICS this bug doesn't affect the functionality of
dpkg-source at all.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to se
On Mon, Feb 12, 2007 at 05:14:08AM -0500, Mike Frysinger wrote:
> On Sunday 11 February 2007, Steve Langasek wrote:
> > On Sun, Feb 11, 2007 at 08:34:53PM -0500, Mike Frysinger wrote:
> > > Justification: no longer builds from source
> > Huh? This bug doesn't descri
code comparing the results of BZ2_bzerror() to the zlib define
> Z_ERRNO ... that should prob be comparing err to some BZ_ error define.
Probably; but I don't see how that causes a build failure as claimed, the
package is built fine on all Debian architectures.
--
Steve Langasek
inux` -Wl,-Bdynamic
Could you check if changing "-lpthread" to "-pthread" works?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
use, then I think dpkg (I guess) should
> warn the user about downgrades..
Downgrading has never been supported in Debian, and in the general case
there's no way to fix a downgrade path for a package after the fact if there
are bugs. If I were the maintainer I would close this bug, but at
If you don't handle the -l, you won't be able to resolve a full path for
these libs. If you have a package in this situation that's biarch and you
have local libs for both the 32bit and the 64bit targets, how will you know
which shlibs file to use if you don't look up the full
On Tue, Jan 24, 2006 at 06:00:28PM +0100, Frank Lichtenheld wrote:
> On Sat, Nov 12, 2005 at 03:18:01AM -0800, Steve Langasek wrote:
> > # Now: See if it is in this package. See if it is in any other package.
> > sub searchdir {
> > my $dir = shift;
> > if(opend
ch path at all (e.g., objects intended for use with
LD_PRELOAD or something).
The only requirement is that dpkg have an internal representation of the
library search path for the object type -- part of which comes from
/etc/ld.so.conf, part of which is hard-coded in ld.so. Oh... and then
there&#x
k or file
> in dynamic linker search path.
Uh, consequently they are *not* unrelated: the soname specified in NEEDED
*must* be a filename that exists on the system, be it symlink or otherwise,
and per policy this file must be contained in the library package (as
opposed to just being created by ldcon
nction is invoked, a more appropriate implementation may
be:
sub searchdir {
my $dir = shift;
if (opendir(DIR, $dir)) {
my @dirents = readdir(DIR);
closedir(DIR);
for (@dirents) {
if ( -f "$dir/$_/DEBIAN/shlibs" ) {
push(@curshlibs,
ariants of
the biarch systems, it makes better use of archive space, and it appears
to get us at least a little bit closer to multiarch, which I still
believe should be the long-term goal for such systems.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian D
lways installing
> 'amd64-libs' (or 'libc6-amd64') before dpkg-shlibdeps is used for
> a 64-bit binary.
No, that doesn't solve the problem. How are you supposed to invoke a
64-bit linker for a bi-arch build being done on a 32-bit buildd?
--
Steve Langasek
46 matches
Mail list logo
