Bug#1028190: tzdata: Possible bug in postinst

[Niels Thykier]

Package: tzdata
Version: 2022g-1
Severity: normal
X-Debbugs-Cc: ni...@thykier.net

In the postinst, there is the following snippet:

> #! /bin/sh
> set -e
> [...]

# Update the time zone
echo $AREA/$ZONE > "$DPKG_ROOT/etc/timezone"
ln -nsf /usr/share/zoneinfo/$AREA/$ZONE "$DPKG_ROOT/etc/localtime.dpkg-new" 
&& \
mv -f "$DPKG_ROOT/etc/localtime.dpkg-new" "$DPKG_ROOT/etc/localtime"
which restorecon >/dev/null 2>&1 && restorecon 
"$DPKG_ROOT/etc/localtime"



I think there is a bug in the `which restorecon ...` construct that can 
cause termination of the postinst rather than conditional call to 
`restorecon`.


As far as I can tell, the construct will "fail" when restorecon is present:

```
which foo >/dev/null 2>&1 && foo ; echo $?
1
```


With `set -e`, this would trigger the postinst to fail and abort the 
installation.


I think this case calls for a `if ...; then .. fi` construct or a `! 
which ... && ...`.


I feel this ought to be an RC bug. However, given I found this with 
(manual) static analysis and no one else complained, I guess this case 
is basically never triggered.  That is why I have reported as non-RC.


Thanks,
~Niels

Arch qualification for buster: call for DSA, Security, toolchain concerns

[Niels Thykier]

Hi,


As part of the interim architecture qualification for buster, we request
that DSA, the security team and the toolchain maintainers review and
update their list of known concerns for buster release architectures.

Summary of the current concerns and issues:
 * DSA have announced a blocking issue for armel and armhf (see below)
 * Concerns from DSA about ppc64el and s390x have been carried over from
   stretch.
 * Concerns from the GCC maintainers about armel, armhf, mips, mips64el
   and mipsel have been carried over from stretch.

If the issues and concerns from you or your team are not up to date,
then please follow up to this email (keeping debian-release@l.d.o and
debian-ports@l.d.o in CC to ensure both parties are notified).

Whilst porters remain ultimately responsible for ensuring the
architectures are ready for release, we do expect that you / your team
are willing to assist with clarifications of the concerns and to apply
patches/changes in a timely manner to resolve the concerns.


List of blocking issues by architecture
===

The following is a summary from the current architecture qualification
table.

armel/armhf:


 * Undesirable to keep the hardware running beyond 2020.  armhf VM
   support uncertain. (DSA)
   - Source: [DSA Sprint report]


[DSA Sprint report]:
https://lists.debian.org/debian-project/2018/02/msg4.html


List of concerns for architectures
==

The following is a summary from the current architecture qualification
table.

 * Concern for ppc64el and s390x: we are dependent on sponsors for
   hardware.
   (Raised by DSA; carried over from stretch)

 * Concern for armel and armhf: only secondary upstream support in GCC
   (Raised by the GCC maintainer; carried over from stretch)

 * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
   in GCC
   (Raised by the GCC maintainer; carried over from stretch)


Architecture status
===

These are the architectures currently being built for buster:

 * Intel/AMD-based: amd64, i386
 * ARM-based: arm64, armel, armhf
 * MIPS-based: mips, mipsel, mips64el
 * Other: ppc64el, s390x

If the blocking issues cannot be resolved, affected architectures are at
risk of removal from testing before buster is frozen.

We are currently unaware of any new architectures likely to be ready in
time for inclusion in buster.

On behalf of the release team,
Niels Thykier



signature.asc
Description: OpenPGP digital signature

Bug#824442: and conflict needs to be resolved

[Niels Thykier]

On Tue, 14 Feb 2017 20:36:43 +0100 Aurelien Jarno 
wrote:
> [...]
> 
> Now that the change have been done on the kernel side, the bug is not
> really visible anymore, so nobody really cared about this bug.
> 
> I'll see if I can come with a patch in the next days.
> 
> Aurelien
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
> 
> 

Thanks for the reply.  I am looking forward to the patch. :)

Forgot to mention, please CC me on replies :)

Thanks,
~Niels

Bug#824442: and conflict needs to be resolved

[Niels Thykier]

On Mon, 16 May 2016 03:12:51 +0100 Ben Hutchings 
wrote:
> Source: glibc
> Version: 2.22-7
> Severity: serious
> 
> (Continued from bug #822393.)
> 
> glibc's  should check whether  has already been
> included and, if so, avoid making conflicting definitions.
> 
> Including the headers in the opposite order works since this change in
> Linux 4.6:
> https://git.kernel.org/linus/4a91cb61bb995e5571098188092e296192309c77
> 
> Ben.
> 
> -- 
> Ben Hutchings
> 73.46% of all statistics are made up.

Hi,

Any news on this bug?

~Niels

Re: Replacing ldconfig maintscripts with declarative methods

[Niels Thykier]

Hi,

As of debhelper/9.20151004, dh_makeshlibs is now using triggers rather
than maintainer scripts to invoke ldconfig.

 * Lintian in untable + testing is already aware of this
 * Lintian has /not yet/ been backported.  Lintian from backports still
   (incorrectly) reports this an issue.

Please do not hesitate to let me know if you experience any issues with
this change.

Thanks,
~Niels

Re: Replacing ldconfig maintscripts with declarative methods

[Niels Thykier]

On 2015-08-29 23:52, Aurelien Jarno wrote:
[...]

  * The major concern I have, is that activate-triggers are done for
- unpack (is this ok?)
- configure (ok)
- remove (ok, assuming it is post-removal)
- purge (should not be an issue)
- deconfigure (would be a no-op, since the library is not actually
  removed at this point)
 
 As a general rule it should not be a problem to call ldconfig at any
 moment. Therefore I don't see a problem to call ldconfig in the above
 steps.
 

Excellent! :)

 What we should ensure is that if package A depends on package B,
 ldconfig is called *before* starting the postinst of package A to fill
 the cache with info from package B.

Ok.  I was not aware that we had this requirement.  However, the current
setup does not enforce it AFAICT.  It seems that triggers are the very
last thing to happen!


$ aptitude -R install mscgen
[...]
Unpacking libgd3:amd64 (2.1.1-4) ...
Selecting previously unselected package mscgen.
Preparing to unpack .../mscgen_0.20-4_amd64.deb ...
Unpacking mscgen (0.20-4) ...
Setting up libexpat1:amd64 (2.1.0-7) ...
[...]
Setting up mscgen (0.20-4) ...
Processing triggers for libc-bin (2.19-19) ...
$


However, if we move to explicit triggers, then dpkg will now trigger
ldconfig just before running postinst scripts:


$ apt-get install ../mscgen_0.20-4+ddebtest1+triggers1_amd64.deb
[...]
Selecting previously unselected package mscgen.
Preparing to unpack .../mscgen_0.20-4+ddebtest1+triggers1_amd64.deb ...
Unpacking mscgen (0.20-4+ddebtest1+triggers1) ...
*Processing triggers for libc-bin (2.19-19) ...*
Setting up libexpat1:amd64 (2.1.0-7) ...
[...]
Setting up mscgen (0.20-4+ddebtest1+triggers1) ...
Processing triggers for libc-bin (2.19-19) ...


As long as one package have the explicit trigger, dpkg it will now
trigger it correctly.  In my particular test case, I added it to mscgen
(despite it not being a library).

 [...]
 
 On the performance side, ldconfig has a cache mechanism, which makes
 calls to ldconfig very very cheap if nothing has changed. So I don't
 think it would be a problem.
 

Excellent. :)

 Feedback is very welcome.  If this idea is uncontroversial, I move
 forward to update debhelper+lintian as well as file bugs against policy.
 
 We currently have ugly hacks removing ldconfig.real in case it will break
 the system in the preinst script. If we go for this solution, we should
 not forget to change that part also.
 
 Aurelien
 

Ok, currently this is guarded by a:

 if dpkg --compare-versions $libc_bin_version lt 2.18-2; then

AFAICT, what will happen is:

 * libc6 preinst upgrade will disable ldconfig
 * dpkg will unpack stuff incl. libc-bin
   - This will restore ldconfig
 * dpkg will run the trigger (unpack)
   - This will run ldconfig
 * dpkg will configure stuff as usual

This seems to be similar to the old approach, except the trigger will
now be run before configuring packages.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: Replacing ldconfig maintscripts with declarative methods

[Niels Thykier]

On 2015-08-25 15:12, Ian Jackson wrote:
 Niels Thykier writes (Replacing ldconfig maintscripts with declarative 
 methods):
 A possible solution is to replace these scripts with an
 activate-no-await trigger (again, no-await to avoid trigger cycles).
 I would need libc-bin to promote its trigger to part of its API for this
 to work.
 
 I think this is a good idea.
 

Thanks. :)

Also thanks for the feedback - It is not the easiest subject in Debian
packaging, so I am glad to have an extra set of eyes on it. :)

  * The major concern I have, is that activate-triggers are done for
- unpack (is this ok?)
 
 It had better be !  (Ie I think it is OK.)
 

Indeed, I had a hard time finding a case where that could not already
have happen by accident (at least before ldconfig started using
triggers internally).

 
  * Performance-wise we would see up to 5 calls to ldconfig instead of
1-2 per dpkg run (that processes triggers).
 
 OTOH the reduced number of maintscript invocations might well outweigh
 that.
 
 Thanks,
 Ian.
 

One could hope. :)


I will wait a couple of days more for feedback before starting on this.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Replacing ldconfig maintscripts with declarative methods

[Niels Thykier]

Hi,

Currently, all Debian libraries (is required to) have a call ldconfig in
postrm and postinst.  I would like to replace that with a declarative
method somehow.  There are a couple of reasons for this:

 * Packages without postinst scripts do not need to be configured
   explicitly (because dpkg can see there is nothing to do for them).
   This provides two improvements:

   - It means there are fewer constrains for dpkg and APT to solve
 to compute an ordering for install/upgrades[1].

   - dpkg can also safely break dependency cycles at packages without
 postinst scripts, since it knows that the package will not need
 anything from its dependencies to be configured.

 = I know that there are people trying to remove dependency cycles
all together.  This solution does /not/ intend replace that
goal.  It will only improve the chance that dpkg can safely
handle a given cycle.

 * There are also some minor optimisations like:

   - We can remove thousands of postrm+postinst scripts.
   - We can remove the hack in libc-bin to replace ldconfig calls with
 a no-await trigger (see below)

The current state:

 * Packages have the scripts to call ldconfig

 * To reduce install time, libc-bin replaced /sbin/ldconfig with a shell
   script.  This detects whether it should immediately call (the real)
   ldconfig OR (if called from a maintscript) should call dpkg-trigger.

   - ldconfig calls dpkg-trigger with --no-await, so it will not cause
 trigger cycles.


A possible solution is to replace these scripts with an
activate-no-await trigger (again, no-await to avoid trigger cycles).
I would need libc-bin to promote its trigger to part of its API for this
to work.  Also, I need some help understanding some corner cases:

 * The major concern I have, is that activate-triggers are done for
   - unpack (is this ok?)
   - configure (ok)
   - remove (ok, assuming it is post-removal)
   - purge (should not be an issue)
   - deconfigure (would be a no-op, since the library is not actually
 removed at this point)

 * Performance-wise we would see up to 5 calls to ldconfig instead of
   1-2 per dpkg run (that processes triggers).
   - Being no-await, dpkg have freedom to re-order and merge all
 the activations.
   - In the long run, it might make sense to get support for only
 activating triggers at certain states.  Though I doubt the
 performance overhead will be the greatest issue


Feedback is very welcome.  If this idea is uncontroversial, I move
forward to update debhelper+lintian as well as file bugs against policy.

Thanks,
~Niels

[1] Note this applies to the ordering problem and not the dependency
resolution problem.




signature.asc
Description: OpenPGP digital signature

Bug#759530: Patch to fix segfault in ldconfig

[Niels Thykier]

Control: tags -1 patch upstream

On Wed, 25 Feb 2015 13:49:00 -0500 Lennart Sorensen
lsore...@csclub.uwaterloo.ca wrote:
 I looked at ways the aux-cache could cause a segfault, and given the
 file is mmap'd and has data offsets in it that are used as pointers
 without being checked it is not hard to see how a corrupt file could
 cause a segfault.  The following patch makes the segfaults I was able
 to think of and create go away.
 
 I also have included an example corrupted aux-cache file
 (aux-cache-corrupt-soname-offset) which has a bad offset that causes
 a segfault.
 


Excellent, thanks.

I am taking the liberty of adding the patch tag for this one.  If
nothing else, I would greatly appreciate having ldconfig not seg. fault. :)

 There is another problem which I haven't solved but which is not a
 segfault.  If you somehow truncate the aux-cache file by a bit and run
 the previous ldconfig without my patch, then you end up with a corrupted
 aux-cache where some entries do not have soname's even though they should,
 and that causes you to get messages like:
 

Sounds like the aux-cache could do with a checksum or something to catch
obvious corruptions.

 [...]
 
 Using ldconfig -i (and hence ignoring the corrupted aux-cache) makes
 that problem go away.  To solve it would of course mean you have to
 not trust the cache which rather defeats the point of having the cache,
 so I don't know if that is worth trying to solve.  It does not cause a
 segfault however.
 
 Using ldconfig -p to show the cache at that point has entries that are
 clearly wrong such as:
 
 [...]


Or ldconfig needs some method to (fairly) reliably detect corruptions.
If it spits out errors about directories not being links, then something
notices a problem.  Perhaps this could be extended to discarding the
cache (even if just a if (!ignore_cache) execve(argv, -i, null);).

Thanks,
~Niels


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f382fd.7000...@thykier.net

Bug#759530: libc-bin: ldconfig breaks a system

[Niels Thykier]

Hi,

Could this bug be caused by a corrupt aux-cache[1] (possibly, in
addition to a corrupt ld.so.cache)?

A bit of google searching suggests that a broken aux-cache can cause
ldconfig to seg. fault.  With the ld.so.cache itself being corrupt (or
sufficiently outdated?), both ldconfig and most other binaries would
simply just seg. fault fitting the symptoms pretty well so far.

It partly also fits with the removal of libjasper1, as the removed
library would force ldconfig to *not* use its cache for said library.
Though I cannot explain why it seems like stat itself seg. faults.

Assuming my hypothesis is correct, a broken system could be restored by
running[2]:

 $ ldconfig.real --ignore-aux-cache

Failling that:

 $  /var/cache/ldconfig/aux-cache
 $ ldconfig.real

Maybe take a copy of the aux-cache before doing the restore
command(s).  This way we should be able to re-break the system by
re-instating the old aux-cache (and possibly breaking the ld.so.cache).

Thanks,
~Niels

[1] /var/cache/ldconfig/aux-cache

[2] Using ldconfig.real in case /bin/sh got borked by the ld.so.cache as
well.


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e44e19.7040...@thykier.net

On debhelper using ldconfig -X instead of ldconfig in postinst

[Niels Thykier]

Hi,

In bug #549990 (from 2009), we were recommended to have debhelper insert
a call to ldconfig -X instead of ldconfig.  I went ahead and
committed said change (but have not released it yet).  Then I noticed
that /sbin/ldconfig is now a shell script invoking dpkg-trigger when
called with no arguments.

My understanding of the ldconfig code is that passing -X to ldconfig
will now bypass this dpkg-trigger call.  Is this still preferred to a
regular ldconfig call (i.e. trigger)?  Or should I revert the change and
keep the original behaviour?  Alternatively, would you prefer that we
replaced the ldconfig with a call to dpkg-trigger to make things explicit?

Thanks,
~Niels


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54af7f20.2030...@thykier.net

Bug#732233: tzdata: Build-depends on openjdk-6-jre-headless, which is being removed in Jessie

[Niels Thykier]

Package: tzdata
Version: 2013h-1
Severity: serious
Control: block 720911 by -1

Hi,

tzdata has a build-depends-indep on openjdk-6-jre-headless, but
openjdk-6 is scheduled for removal in Jessie (see #720911).  Please
migrate to default-jre-headless or openjdk-7-jre-headless.

~Niels


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131215211952.7677.59777.report...@mangetsu.thykier.net