Re: Plan B for kfreebsd
Christoph Egger wrote: > It means we need a stable release of some sort to keep DSA provided > hardware. That's currently buildds and porterboxes. That's annoying. To provide stable/security support ourselves, it seemed we'd need an unofficial repo, and that doesn't sound like something DSA could use. Although, how is that handled for hurd-i386? I assume it has no security support, there may be some unofficial packages used; are therefore none of their machines DSA? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014120505.gd14...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Hi! Steven Chamberlain writes: > Christoph Egger wrote: >> It means we need a stable release of some sort to keep DSA provided >> hardware. That's currently buildds and porterboxes. > > That's annoying. > > To provide stable/security support ourselves, it seemed we'd need an > unofficial repo, and that doesn't sound like something DSA could use. christoph: the ftp-folks wouldn't mind having a jessie-kfreebsd suite in the main archive. With our own acceptance policy I guess (like backports has different people accepting and stuff) and DSA would sure be willing to use that. All it means is we need to do some release that is close enough to being debian for the infrastructure. It means we can't only do some rolling stuff and expect DSA to run hardware for us for example. > Although, how is that handled for hurd-i386? I assume it has no > security support, there may be some unofficial packages used; are > therefore none of their machines DSA? These are "private" machines Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87389psz04@anonymous.siccegge.de
Re: Plan B for kfreebsd
Steven Chamberlain, le Tue 11 Nov 2014 12:05:06 +, a écrit : > Although, how is that handled for hurd-i386? I assume it has no > security support, there may be some unofficial packages used; are > therefore none of their machines DSA? We are still stuck in the "not released arch => no DSA machine => not released arch" loop. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014123400.gc3...@type.youpi.perso.aquilenet.fr
Re: Plan B for kfreebsd
On Tue, 11 Nov 2014, Samuel Thibault wrote: > Steven Chamberlain, le Tue 11 Nov 2014 12:05:06 +, a écrit : > > Although, how is that handled for hurd-i386? I assume it has no > > security support, there may be some unofficial packages used; are > > therefore none of their machines DSA? > > We are still stuck in the "not released arch => no DSA machine => not > released arch" loop. Except that it's not a loop. DSA has indicated time and time again that if an arch qualifies for a release in all other aspects, we'd be running buildds and porterboxes close to the release. And, TTBOMK, the release team has so far accepted that. IOW the fact that hurd is not being released with jessie is not due to not having d.o systems. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014123902.gk20...@anguilla.noreply.org
Re: Plan B for kfreebsd
Peter Palfrader, le Tue 11 Nov 2014 13:39:02 +0100, a écrit : > On Tue, 11 Nov 2014, Samuel Thibault wrote: > > > Steven Chamberlain, le Tue 11 Nov 2014 12:05:06 +, a écrit : > > > Although, how is that handled for hurd-i386? I assume it has no > > > security support, there may be some unofficial packages used; are > > > therefore none of their machines DSA? > > > > We are still stuck in the "not released arch => no DSA machine => not > > released arch" loop. > > Except that it's not a loop. DSA has indicated time and time again that > if an arch qualifies for a release in all other aspects, we'd be running > buildds and porterboxes close to the release. And, TTBOMK, the release > team has so far accepted that. IOW the fact that hurd is not being > released with jessie is not due to not having d.o systems. Ok, then I don't understand why there are "DSA-admined buildds" and "security buildds" columns in the release qualification sheet. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014125413.gd3...@type.youpi.perso.aquilenet.fr
Re: Plan B for kfreebsd
On Tue, 11 Nov 2014, Samuel Thibault wrote: > Peter Palfrader, le Tue 11 Nov 2014 13:39:02 +0100, a écrit : > > On Tue, 11 Nov 2014, Samuel Thibault wrote: > > > We are still stuck in the "not released arch => no DSA machine => not > > > released arch" loop. > > > > Except that it's not a loop. DSA has indicated time and time again that > > if an arch qualifies for a release in all other aspects, we'd be running > > buildds and porterboxes close to the release. And, TTBOMK, the release > > team has so far accepted that. IOW the fact that hurd is not being > > released with jessie is not due to not having d.o systems. > > Ok, then I don't understand why there are "DSA-admined buildds" and > "security buildds" columns in the release qualification sheet. Because they need to exist for the release. They are necessary, not sufficient. You aren't blocking on them. If/when DSA admined buildds are the only remaining issue and we're close to the release, then we can make them. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014131109.gm20...@anguilla.noreply.org
Re: Plan B for kfreebsd
Peter Palfrader wrote: > On Tue, 11 Nov 2014, Samuel Thibault wrote: > > We are still stuck in the "not released arch => no DSA machine => not > > released arch" loop. > > Except that it's not a loop. DSA has indicated time and time again that > if an arch qualifies for a release in all other aspects, we'd be running > buildds and porterboxes close to the release. Until Christoph quoted your brilliant suggestion on IRC, I did think there were one or more loops here with no obvious way out, for us or many future ports. At least, the release team's decision seemed far-reaching, since: 0. stable RM says 'no' to a port 1.1. if there's not a 'stable' release, the buildds can't be DSA 1.2. without DSA buildds, there can be no security builds either (and vice-versa) 1.3. packages built for sid, on non-DSA buildds are not official? so would need to rebootstrap itself 2.1. testing goes away too 2.2. users/developers are left with only sid, which is obviously more broken; development gets harder, users leave 2.3. port becomes less appealing for maintainers to support, stop trying to building their packages on it 3.1. if there's no testing or stable, FTP team might not see much reason to distribute it; it moves to debian-ports.org and, I suppose never comes back 3.2. mirrors no longer carry it, most QA tools and supporting infrastructure can no longer support it 4. next release qualification, the port seems in pretty bad shape due to all of the above probably receives a 'no' again Anyway, I'm really hopeful now. weasel suggested a 'jessie-kfreebsd' suite could still be supported by FTP team. (Actually, could that be named something more generic like jessie-ports? So that another arch can try something similar? Or would it be confused too much with debian-ports.org?) Porters would try to maintain it like a stable release. Perhaps able to do make improvements that release team policy might not have allowed; like backporting something that particularly benefits that arch. Practically it would be an 'official Debian port', and we'd have all the usual things like install media. If it turns out to be in fact stable, hopefully it would be acceptable to DSA. The remaining obstacles go away. It sounds sustainable, and seems like a model for other ports to follow. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014134118.gf14...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Steven Chamberlain, le Tue 11 Nov 2014 13:41:18 +, a écrit : > Practically it would be an 'official Debian port', and we'd have all the > usual things like install media. I wouldn't call it "official", but I agree on the rest. Getting hurt by sid bugs is always a pain, and you can not have users that way. And having a port in the normal infrastructure flow helps a *lot* to get maintainers at least try to fix their packages, instead of leaving all the tudy to the porter team. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014135228.gg3...@type.youpi.perso.aquilenet.fr
Re: Plan B for kfreebsd
Hello, 2014-11-11 14:41 GMT+01:00 Steven Chamberlain : > Peter Palfrader wrote: >> On Tue, 11 Nov 2014, Samuel Thibault wrote: > Anyway, I'm really hopeful now. weasel suggested a 'jessie-kfreebsd' > suite could still be supported by FTP team. (Actually, could that be > named something more generic like jessie-ports? So that another arch > can try something similar? Or would it be confused too much with > debian-ports.org?) > > Porters would try to maintain it like a stable release. Perhaps able > to do make improvements that release team policy might not have allowed; > like backporting something that particularly benefits that arch. > Practically it would be an 'official Debian port', and we'd have all the > usual things like install media. > > If it turns out to be in fact stable, hopefully it would be acceptable > to DSA. The remaining obstacles go away. It sounds sustainable, and > seems like a model for other ports to follow. I have been thinking adding stable to debian-ports would be great for these kind of cases, but still there are many open ends: * Need for unreleased-stable suite * Keep up with security maintenance * Keep up with point releases * Handling transitions in acceptable time (not directly affecting stable release) * Handle migrations between unstable -> stable(?) suites All that, and maybe more, without release, security, buildd, dsa team support. Not trivial stuff to do, but that might not only help the kfreebsd but all the other debian-ports arches to get an unofficial stable release. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caodfwegbko7gk_mjvsygibceeu_ky6hffwi3rtqnc0+f3ir...@mail.gmail.com
Re: Building glibc-2.19-14~0 with fakeroot-hurd/fakreoot-tcp
Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit : > Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite), > but the latest version does not: glibc-2.19-14~0: But what "previously" is exactly? Did you try to downgrade the libc or hurd installed on your box? Note that I don't think it depends on the version of the glibc that you build, but on the version of the packages which are already installed. Knowing which precise version of installed packages trigger the bug will probably help a lot to determine where the issue comes from. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014230723.gu3...@type.youpi.perso.aquilenet.fr
Re: Building glibc-2.19-14~0 with fakeroot-hurd/fakreoot-tcp
On Wed, 2014-11-12 at 00:07 +0100, Samuel Thibault wrote: > Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit : > > Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite), > > but the latest version does not: glibc-2.19-14~0: > > But what "previously" is exactly? Did you try to downgrade the libc or > hurd installed on your box? Note that I don't think it depends on the > version of the glibc that you build, but on the version of the packages > which are already installed. Knowing which precise version of installed > packages trigger the bug will probably help a lot to determine where the > issue comes from. Bisecting is of course the best method, but downgrading gnumach:x/hurd:y/glibc:z = x^i*y^j*z^k and rebuilding glibc with fakeroot-hurd for each iteration would take weeks in computer time, not even considering personal time. Add to that other packages that can affect the search: binutils, etc? -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415747797.11764.14.ca...@g3620.my.own.domain
Re: Building glibc-2.19-14~0 with fakeroot-hurd/fakreoot-tcp
Svante Signell, le Wed 12 Nov 2014 00:16:37 +0100, a écrit : > On Wed, 2014-11-12 at 00:07 +0100, Samuel Thibault wrote: > > Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit : > > > Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite), > > > but the latest version does not: glibc-2.19-14~0: > > > > But what "previously" is exactly? Did you try to downgrade the libc or > > hurd installed on your box? Note that I don't think it depends on the > > version of the glibc that you build, but on the version of the packages > > which are already installed. Knowing which precise version of installed > > packages trigger the bug will probably help a lot to determine where the > > issue comes from. > > Bisecting is of course the best method, but downgrading > gnumach:x/hurd:y/glibc:z = x^i*y^j*z^k and rebuilding glibc with > fakeroot-hurd for each iteration would take weeks in computer time, not > even considering personal time. Add to that other packages that can > affect the search: binutils, etc? Err, why would you need to rebuild glibc each time? Don't you know exactly the dh_install command which fails? Also, you don't need to try all combinations first: it's probably a bug in just one package, so you just need to try to downgrade the various packages by just one version. That makes just: downgrade libc, reboot, try to run dh_install, downgrade hurd, reboot, try to run dh_install, downgrade gnumach, reboot, try to run dh_install, and repeat up to reaching the versions with which you believe it worked in the patch. That should not take very long. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014232045.gv3...@type.youpi.perso.aquilenet.fr
Bug#769189: isc-dhcp-client: dhclient -6 -r waits 1m, affecting finish-install on !linux
Package: isc-dhcp-client
Version: 4.3.1-5
Severity: important
Hello,
Running
dhclient -6 -r
basically hangs for one minute before returning. Running
dhclient -1 -6 -r
does finish. dhclient.c reads as
if (release mode) {
#ifndef DHCPv6
return 0;
#else
if (local_family == AF_INET6) {
if (onetry)
return 0;
} else
return 0;
#endif /* DHCPv6 */
}
I don't really understand why looking for -1 (onetry) in the inet6 case,
I don't see anything in the documentation, and what I understand from
the source code is that in that case, since -r is specified no request
will be sent, and thus no answer will be received, and thus dhclient
will just wait for the timeout (one minute) without doing anything.
This affects d-i's netcfg finish-install script on !linux ports, where
it runs both dhclient -r and dhclient -6 -r. One way to workaround
the issue for now is adding -1 to netcfg. It happens that it doesn't
hit kfreebsd just because it happens that umount -a in the 95umount
finish-install script manages to kill dhclient for some reason...
Samuel
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'),
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.17.0 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages isc-dhcp-client depends on:
ii debianutils 4.4+b1
ii iproute2 3.16.0-2
ii isc-dhcp-common 4.3.1-5
ii libc6 2.19-12
ii libdns-export100 1:9.9.5.dfsg-5
ii libirs-export91 1:9.9.5.dfsg-5
ii libisc-export95 1:9.9.5.dfsg-5
isc-dhcp-client recommends no packages.
Versions of packages isc-dhcp-client suggests:
pn avahi-autoipd
ii resolvconf 1.76
-- Configuration Files:
/etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes changed [not included]
/etc/dhcp/dhclient.conf changed [not included]
-- no debconf information
--
Samuel
Running Windows on a Pentium is like having a brand new Porsche but only
be able to drive backwards with the handbrake on.
(Unknown source)
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20141112004834.ga20...@type.youpi.perso.aquilenet.fr
Processing of hurd_0.5.git20141108-4_hurd-i386.changes
hurd_0.5.git20141108-4_hurd-i386.changes uploaded successfully to localhost along with the files: hurd_0.5.git20141108-4.dsc hurd_0.5.git20141108-4.debian.tar.bz2 hurd-libs0.3_0.5.git20141108-4_hurd-i386.deb hurd_0.5.git20141108-4_hurd-i386.deb hurd-dev_0.5.git20141108-4_hurd-i386.deb hurd-dbg_0.5.git20141108-4_hurd-i386.deb hurd-doc_0.5.git20141108-4_all.deb hurd-libs0.3-udeb_0.5.git20141108-4_hurd-i386.udeb hurd-udeb_0.5.git20141108-4_hurd-i386.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xomtv-0008as...@franck.debian.org
hurd_0.5.git20141108-4_hurd-i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 11 Nov 2014 23:57:23 + Source: hurd Binary: hurd-libs0.3 hurd hurd-dev hurd-dbg hurd-doc hurd-libs0.3-udeb hurd-udeb Architecture: source hurd-i386 all Version: 1:0.5.git20141108-4 Distribution: unstable Urgency: medium Maintainer: GNU Hurd Maintainers Changed-By: Samuel Thibault Description: hurd - GNU Hurd hurd-dbg - GNU Hurd (debugging files) hurd-dev - GNU Hurd (development files) hurd-doc - GNU Hurd manual hurd-libs0.3 - GNU Hurd (libraries) hurd-libs0.3-udeb - GNU Hurd (libraries) - udeb (udeb) hurd-udeb - GNU Hurd - udeb (udeb) Changes: hurd (1:0.5.git20141108-4) unstable; urgency=medium . * patches/git-proc-mounts.patch: Make procfs appear in /proc/mounts, for d-i. Checksums-Sha1: 5b993c5fe2986971b83cea468fcb53584ec1ee6c 5055 hurd_0.5.git20141108-4.dsc a11ab5458227a1c9355d4709e53a92cf38a74556 105997 hurd_0.5.git20141108-4.debian.tar.bz2 0bf22ff7b88ec095de77c08fdb70d29c0895ec54 262126 hurd-libs0.3_0.5.git20141108-4_hurd-i386.deb b5d79e5eec3a6609e385dde0f35e343383b22fce 1406624 hurd_0.5.git20141108-4_hurd-i386.deb 7ef687a97aa2d514f60db69d8110dfb7ad0db9f0 3188026 hurd-dev_0.5.git20141108-4_hurd-i386.deb 13324bb8195fcb90ba4d9655acf0ff990b35019c 3127802 hurd-dbg_0.5.git20141108-4_hurd-i386.deb d81e1158c71ef9a53d05318204d6c3dfc4cee2e0 164426 hurd-doc_0.5.git20141108-4_all.deb 37dace3ca9e23b0f91a5ca1929343b2fae2cf0c0 240836 hurd-libs0.3-udeb_0.5.git20141108-4_hurd-i386.udeb 6b164cbc257eb1291ae25ce9636a1a24645ebc70 1430660 hurd-udeb_0.5.git20141108-4_hurd-i386.udeb Checksums-Sha256: 6d9fd13d1a7179293eaf4002bdaad10eb254c9ce37b94cc1e977ad18854be69d 5055 hurd_0.5.git20141108-4.dsc 27e15594685a9e6bc7db83bd74d952f6f108b31436d5daea7493424233433470 105997 hurd_0.5.git20141108-4.debian.tar.bz2 0c478d2666b193f93943ac6f83b384a9f9ec998d33db875d0d51244704f773d7 262126 hurd-libs0.3_0.5.git20141108-4_hurd-i386.deb e593481d18cb18f23d3fc3d8559f415511e81fb562b5b7a78fde49907bcd9080 1406624 hurd_0.5.git20141108-4_hurd-i386.deb 8fd7440ffa90bcfca7662f9af7f23fb92cf49c3a894e5b4ef616795f8c7d59f6 3188026 hurd-dev_0.5.git20141108-4_hurd-i386.deb a5c8c462d0f0b6b922133d4643b535f4923ebd40a29c254a6ec3a46f77a29824 3127802 hurd-dbg_0.5.git20141108-4_hurd-i386.deb 131a33beb55b0709582ae8ce268a341bc5507e095db6d4261805043cd32e3def 164426 hurd-doc_0.5.git20141108-4_all.deb f595b42f9b30e3294fd5f19a985206a5bbc5eea0965bb55f8da5bd717eeb3cca 240836 hurd-libs0.3-udeb_0.5.git20141108-4_hurd-i386.udeb 59d92330dd192999d8b2b3311bc0097435f5dac67e52ce5affc38c5db7f0a721 1430660 hurd-udeb_0.5.git20141108-4_hurd-i386.udeb Files: dce523783a4e356d74316df656bc2672 5055 admin required hurd_0.5.git20141108-4.dsc cc2f0f422c7a8d4100a83cf83f9c2ad2 105997 admin required hurd_0.5.git20141108-4.debian.tar.bz2 e6e194ba1a220cd0a781d2b1ea115466 262126 libs required hurd-libs0.3_0.5.git20141108-4_hurd-i386.deb 5941f1b53e3113ec33aa2aace9820f42 1406624 admin required hurd_0.5.git20141108-4_hurd-i386.deb 559355ce8f68e50dfd49636dbdd101e3 3188026 libdevel standard hurd-dev_0.5.git20141108-4_hurd-i386.deb 151b4d0ad0202c07015bd58beb09f9c5 3127802 debug extra hurd-dbg_0.5.git20141108-4_hurd-i386.deb 04a5c7994d308001b16761dac2d31f20 164426 doc optional hurd-doc_0.5.git20141108-4_all.deb e0622d19a68d596a280ceae62d785ab6 240836 debian-installer optional hurd-libs0.3-udeb_0.5.git20141108-4_hurd-i386.udeb 81f1376963bc19e7231b7d23ea11747d 1430660 debian-installer optional hurd-udeb_0.5.git20141108-4_hurd-i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUYrcTAAoJEBH0lP5vGG7NP94P+wdlIbcl+zyoDkg9fW//Piop VcTmlnbBEUBIRwkVJgM2TGUBiLp7M7WGrWxVwOUbHX/OSAlKI9kSIvZOjg9M8fWO Ud1jWqe5SBmU+kMTppXwPU1opz6aFSkiAwSPQPiw2UTc7hvhdZnVaopJ8DqM6F/h ehc0La/bv2C30mZ6P3s5MNJ+NTszqVEMCGvJRrfZapJ3W0lXgth1YrK+F8pVtAGH qLeq2Waz7z6GIMOw+vFDK0jSdSoycxty6PztuJwUNIZpZDN0v0VY/MHfY4xUs9o7 eOGznj1yeGOvZgM656pckGwJVDg+zODMq0rBZeVqhWBEbR3DpiX7qP5LP+yjI7MP bW8R/2QPZ57szWc5+BuMK/i8vimYKzu3ism6+gChV7oHsRRpHOT0EgFl56Csb1Bq kmGvgIdM2UVnc2oo288RqUtzY1xLFdAUeSWBE/DrfoEnLVQ92rXABGDmRKz2O80G XKDgxLkSh4Ek1MWUs/dgkxk+sb8qJmE9rg0AtdKCrvn8DzLg/BrcVtCIs8Hs4/ey mPouYWnwEdif8SkWGCE/yh2Y/lqWFc+v+HPk1afHi6wbL8zQ70zzMRqmcnogvTID B8Tj0Wzj3I1lINA3Epy4Y6bCbFNJYH5seTXRCw3V01uwKGlQTboeP0iyYAyP7X5i 74KXEEaqXEHW3dbA4XFK =Xxly -END PGP SIGNATURE- Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xon3d-000159...@franck.debian.org
