Re: GPT partlabel support for Mach

2020-06-13 Thread наб
Hi!

On Sat, Jun 13, 2020 at 01:46:02AM +0200, Samuel Thibault wrote:
> I have fixed the issue so the daily image
> should be working again, could you test it?
Yep, the new image works and gets to installing the base system,
which then fails with a mismatched version of vim-tiny vs vim-common
(because src:vim failed to build on the hurd buildds[1]),
and uninstallable rsyslog (because a recent enough src:librelp failed,
so so did src:rsyslog[2]). Not the end of the world on ports arches.

To work around this, I included the following preseed:
  d-i base-installer/excludes string rsyslog vim-common vim-tiny
which got me all the way to kernel selection, which promptly failed,
because:
apt   2.1.6depends libgnutls30 >= 3.6.12,
libgnutls 3.6.12-2 depends libp11-kit0 >= 0.23.18.1,
and no libp11-kit0 exists for hurd, since, quoth the log[3]:
  common/unix-peer.c:133:2: error: #error "Unsupported UNIX variant"

This has the side-effect of apt update not working
(since /usr/lib/apt/methods/http dies during dynamic linking),
trying to delete itself on apt --fix-broken install,
and generally refusing to install any packages.

The latest src:p11-kit build I can see on the buildd website
that worked was 0.23.3-4 from 2017, but,
looking at the pool[4], it *does* have 0.23.18.1-2+hurd.2,
which would match the dep spec, but the Packages file does *not* mention
anything matching /p11-kit/ except for a few Depends: fields.
This feels like a problem with the archive?

After downloading the libp11-kit0 and libffi7 .debs and installin
them manually into the target system the installation proceeded
smoothly, and, after finishing,
the system came up into GRUB, then Hurd, without problems.

наб

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=vim=hurd-i386=2%3A8.2.0716-3=1589376544=0
[2]: 
https://buildd.debian.org/status/fetch.php?pkg=librelp=hurd-i386=1.6.0-1=1589298167=0
[3]: 
https://buildd.debian.org/status/fetch.php?pkg=p11-kit=hurd-i386=0.23.20-1=1580458156=0
[4]: http://deb.debian.org/debian-ports/pool-hurd-i386/main/p/p11-kit/


signature.asc
Description: PGP signature


Bug#838392: marked as done (hurd should not build hurd-dev at stage2)

2020-06-13 Thread Debian Bug Tracking System
Your message dated Sat, 13 Jun 2020 12:57:13 +0200
with message-id <20200613105713.2sqxgiiyhvhezvdh@function>
and subject line Re: Bug#838392: dpkg: should build-depend on hurd-dev
has caused the Debian Bug report #838392,
regarding hurd should not build hurd-dev at stage2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
838392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838392
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.18.10
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hello,

dpkg needs to build-depend on hurd-dev because it uses  and
. It happens that libc0.3-dev depends on it, and thus hurd-dev
gets pulled on a normal system. But when bootstrapping, libc0.3-dev does
not depend on hurd-dev yet. So dpkg should explicitly build-depend on
hurd-dev to be able to be compiled with the bootstrap libc build.

So could you apply the attached patch?

Thanks,
Samuel

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.23-5
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  libselinux1  2.5-3
ii  tar  1.29b-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.3~rc4

-- no debconf information

-- 
Samuel
 bouhouhouh, b il m'a abandonné. Tout ca parce que je regardais plus mon 
emacs que lui !
 s/lui/ses messages irc/
 -+- #ens-mim esseulé -+-
--- debian/control.original 2016-09-20 21:21:36.395188941 +0200
+++ debian/control  2016-09-20 21:21:40.795164587 +0200
@@ -14,6 +14,7 @@
  gettext (>= 0.19), po4a (>= 0.41),
  zlib1g-dev, libbz2-dev, liblzma-dev,
  libselinux1-dev (>= 1.28-4) [linux-any],
+ hurd-dev [hurd-any],
  libncursesw5-dev,
  libio-string-perl 
 
--- End Message ---
--- Begin Message ---
Version: 1:0.9.git20200416-2

Hello,

Helmut Grohne, le mer. 21 sept. 2016 06:09:22 +0200, a ecrit:
>what I'd rather see here is to go the same route as stage1 (which
>doesn't work due to #818618 yet): Rename stage2's hurd-dev to
>something else, have it and the real hurd-dev provide the actual
>functionality and move over the critical rdeps (mainly gcc + glibc).

That was done lately.

Samuel--- End Message ---