[DNG] Debian/Buster-to-Devuan/Beowulf : Version 2

Hello, The following instructions is the first version of how to migrate from Debian/Buster to Devuan/Beowulf. Note that this description does use a fixed network interface. For wireless connections additional tips should be made. The following text file describes the procedure: (replacing

[DNG] Debian/Buster-to-Devuan/Beowulf : Version 1

Hello, The following instructions is the first version of how to migrate from Debian/Buster to Devuan/Beowulf. This description is a complement to the description at: https://www.devuan.org/os/documentation/dev1fanboy/en/buster-to-beowulf which is known to not work any longer. Note that this

Bug#985645: hurd: Hurd creates buggy core files or gdb cannot read core files properly

Source: hurd Version: 1:0.9.git20201127-7 Severity: important Tags: upstream User: debian-h...@lists.debian.org Usertags: hurd Hello, When hurd dumps a core file it cannot be read properly in gdb. This is either due to a bug in the Hurd package itself or a bug in gdb. The core dump code in Hurd

Bug#985645: hurd: Hurd creates buggy core files or gdb cannot read core files properly

Source: hurd Version: 1:0.9.git20201127-7 Severity: important Tags: upstream User: debian-hurd@lists.debian.org Usertags: hurd Hello, When hurd dumps a core file it cannot be read properly in gdb. This is either due to a bug in the Hurd package itself or a bug in gdb. The core dump code in Hurd

Re: Hurd substitute availability (27.5%) and next steps?

On Mon, 2021-03-08 at 22:47 +, Christopher Baines wrote: > Vincent Legoll writes: > > > often I'll be unable to SSH in > > > > Couldn't you get a console from a virtual serial port from the VM ? > > Maybe, I also want to look at getting the serial port output logged > to a file (if that's

Bug#975585: vsftpd: #975585: Reopen due to debian_vsftpd.init.patch not applied

reopen 975585 3.0.3-13 thanks Hello, Reopening #975585 due to that the patch debian_vsftpd.init.patch was not applied. The package is still not installable on GNU/Hurd. Thanks!

Bug#951834: php7.4: FTBFS on hurd-i386

found 951834 7.4.15-2 retitle 951834 php7.4 FTBFS on hurd-i386 owner 951834 svante.sign...@gmail.com tags 951834 ftbfs, patch user 951834 debian-h...@lists.debian.org usertag 951834 hurd thanks Hello, Trying to build php7.4 for GNU/Hurd revealed that in addition of the patch in this bug report,

Re: go issues

On Thu, 2021-02-04 at 10:44 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 04 févr. 2021 10:39:32 +0100, a ecrit: > > I just found out about the patched gcc-10 package. Then this patch > > has to be applied also for gcc-11 and gcc-snapshot, right? > > As I said, it

Re: go issues

On Thu, 2021-02-04 at 10:35 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 04 févr. 2021 10:30:57 +0100, a ecrit: > > On Wed, 2021-02-03 at 18:52 +0100, Samuel Thibault wrote: > > > It seems that the go issues that we were meeting (segfaults etc.) > > > were

Re: go issues

On Wed, 2021-02-03 at 18:52 +0100, Samuel Thibault wrote: > Hello, > > It seems that the go issues that we were meeting (segfaults etc.) > were due to the missing support for unwinding over signal handling > with siginfo support. The fix is already committed upstream, I am > uploading a fixed

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #29, sr #110199 (project administration): Hello, Thanks for the heads up. A new tarball will be uploaded soon. Thanks! ___ Reply to this item at:

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #29, sr #110199 (project administration): Hello, Thanks for the heads up. A new tarball will be uploaded soon. Thanks! ___ Reply to this item at:

Re: WEXITED/WCONTINUED

On Sun, 2020-12-27 at 01:13 +0100, Samuel Thibault wrote: > Hello, > > For information, I am currently landing patches to implemented > waitid's > WEXITED/WCONTINUED/etc. Linux has in /usr/include/x86_64-linux-gnu/bits/waitflags.h: # define WEXITED4 /* Report dead child. */ #

Re: WEXITED/WCONTINUED

On Sun, 2020-12-27 at 02:24 +, jbra...@dismail.de wrote: > That's pretty cool! I wonder what applications will benefit from > that. I would imagine quite a few. > > December 26, 2020 7:13 PM, "Samuel Thibault" > wrote: > > > Hello, > > > > For information, I am currently landing patches

Re: Please comment out constants in header files for features not being supported yet. And remove stubs??

On Fri, 2020-12-18 at 14:02 +0100, Samuel Thibault wrote: > Svante Signell, le ven. 18 déc. 2020 13:22:12 +0100, a ecrit: > > > > It is a crash: Without gdb: > > host ftp.sunet.se > > ftp.sunet.se is an alias for sunet.ftp.acc.umu.se. > > sunet.ftp.acc

Re: Please comment out constants in header files for features not being supported yet. And remove stubs??

On Fri, 2020-12-18 at 12:12 +0100, Samuel Thibault wrote: > Svante Signell, le ven. 18 déc. 2020 11:58:53 +0100, a ecrit: > > On Thu, 2020-12-17 at 17:11 +0100, Samuel Thibault wrote: > > > BTW: Any ideas about the second crash written about in my previous > > mail that yo

Re: Please comment out constants in header files for features not being supported yet. And remove stubs??

On Thu, 2020-12-17 at 17:11 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 17 déc. 2020 15:54:28 +0100, a ecrit: > > # define CLOCK_REALTIME_COARSE 5 > > > > The problem with that option is that it is not yet supported, > > resulting in EINVAL and a c

Please comment out constants in header files for features not being supported yet. And remove stubs??

Hello, Testing the command host results in time.c:118: Invalid argument timer.c:634: fatal error: RUNTIME_CHECK(isc_time_now(()) == 0) failed Aborted (core dumped) Looking into the problem reveals that bind9 is built with the wrong option clk_id for clock_gettime(): CLOCK_REALTIME_COARSE is

Please build gcc-9 + gcc-10 w/o tests.

Hello, Unfortunately gcc-9 (and gcc-10, gcc-snapshot) fails when tests are enabled, due to "make -C build/gotools/ check" fails with one test hanging forever (and all 5 tests fails when killing the hanged process). A fix for that problem is still needed. Note that "make -C build/i686-gnu/libgo

Re: PHP 7.4 on Debian GNU/Hurd

On Tue, 2020-12-01 at 12:51 +0100, Svante Signell wrote: > On Tue, 2020-12-01 at 12:29 +0100, Richard Braun wrote: > > Hello, > > > > The php7.4 package and all that depend on it cannot be built > > because > > of > > a dependency from php7.4 on systemd.

Re: PHP 7.4 on Debian GNU/Hurd

On Tue, 2020-12-01 at 12:29 +0100, Richard Braun wrote: > Hello, > > The php7.4 package and all that depend on it cannot be built because > of > a dependency from php7.4 on systemd. Is there anything that can be > done > about it ? See #951834 for patches. The only dependent package on systemd

Re: Boot issue with e1000 netdde driver

On Sun, 2020-11-29 at 20:31 +0100, Samuel Thibault wrote: > Svante Signell, le dim. 29 nov. 2020 18:01:51 +0100, a ecrit: > > On Sun, 2020-11-29 at 14:37 +0100, Samuel Thibault wrote: > > > Richard Braun, le dim. 29 nov. 2020 14:09:56 +0100, a ecrit: > > > > Actuall

Re: Boot issue with e1000 netdde driver

On Sun, 2020-11-29 at 14:37 +0100, Samuel Thibault wrote: > Richard Braun, le dim. 29 nov. 2020 14:09:56 +0100, a ecrit: > > > > Actually, with the e1000 driver, very often, network is not > > functional at boot time and I have to manually kill netdde and > > trigger some activity > Oh? > > I'm

Installing sbuild failed, a lot of passive translators? still running.

Hi, After installing and running sbuild+sbuild-createchroot it failed and a lot of passive translators? are still running at /tmp/*, e.g. \rm -rf /tmp/* rm: cannot remove '/tmp/tmp.6hFFgM37Tt/dev/fd': Device or resource busy rm: cannot remove '/tmp/tmp.6hFFgM37Tt/dev/vcs': Device or resource

Bug#951834: php7.4-7.4.11-1: FTBFS on non-linux, #951834

found 951834 7.4.11-1 tags 951834 ftbfs user 951834 debian-h...@lists.debian.org usertags 951834 hurd kfreebsd thanks Hello, Trying to build php7.4 for GNU/Hurd revealed that in addition of the patch in this bug report, another one is needed and attached: ext_standard_hrtime.h.patch. Thanks!

Bug#975585: vsftpd: FTBFS on hurd-i386 #975585

Hi again, Sorry for this. The patch for debian/control should add sysvinit-utils to Depends: not Build-Depends:. New patch attached. Thanks! --- a/debian/control 2020-11-24 09:07:54.0 +0100 +++ b/debian/control 2020-11-24 09:08:36.0 +0100 @@ -21,6 +21,7 @@ lsb-base (>= 3.0-6),

Bug#975585: vsftpd: FTBFS on hurd-i386

Source: vsftpd Version: 3.0.3-12 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, vsftpd fails to install due to usage of a ps -C in vsftpd.init, which does not exist for GNU/Hurd. The attached patch, debian_vsftpd.init.patch, fixes this problem.

Bug#975100: zeromq3: FTBFS on hurd-i386

Source: zeromq3 Version: 4.3.3-3 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, zeromq3 fails to build from source due to a PATH_MAX issue in tests/testutil.cpp, and a missing declaration of make_random_ipc_endpoint in

Bug#975054: libva: FTBFS on !linux

Source: libva Version: 2.9.0-1 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org debian-k...@lists.debian.org Usertags: hurd kfreebsd Hello, libva fails to build due to usage of a linux-specific usage of syscall(__NR_gettid) in va/va_trace.c. The attached patch,

Bug#975054: libva: FTBFS on !linux

Source: libva Version: 2.9.0-1 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org debian-k...@lists.debian.org Usertags: hurd kfreebsd Hello, libva fails to build due to usage of a linux-specific usage of syscall(__NR_gettid) in va/va_trace.c. The attached patch,

Re: Testing direct rendering/more video cards with qemu?

On Tue, 2020-11-17 at 22:51 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 22:47:04 +0100, a ecrit: > > On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote: > > > Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit: > > > > G

Re: Testing direct rendering/more video cards with qemu?

On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit: > > Got it. Can some of the drivers be tested with software rendering, > > like swrast? > > software rendering does not use drm/dri. That's alread

Re: Testing direct rendering/more video cards with qemu?

On Tue, 2020-11-17 at 15:32 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 15:31:03 +0100, a ecrit: > > > > > dri cannot work. You changes in libdrm only introduced some > > > > > stub interface. Actual drm implementation is needed to

Re: Testing direct rendering/more video cards with qemu?

On Tue, 2020-11-17 at 15:22 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 15:22:02 +0100, a ecrit: > > On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote: > > > Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit: > > > > > >

Re: Testing direct rendering/more video cards with qemu?

On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit: > > > > Which of these (and xorg* packages) are needed? > > > > > > Needed for what? > > > > For testing if some of the dri/drv

Re: Testing direct rendering/more video cards with qemu?

On Tue, 2020-11-17 at 14:22 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 11:41:52 +0100, a ecrit: > > I managed to build more packages from mesa based on that libdrm is > > now available. Is there any way to test these packages with qemu? > >

Testing direct rendering/more video cards with qemu?

Hello, I managed to build more packages from mesa based on that libdrm is now available. Is there any way to test these packages with qemu? qemu-system-x86_64 --help shows -vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none] select video card type (or is it only possible with

[PATCH] New patch for the port of gccgo to GNU/Hurd

Hello, Latest Debian snapshot of gcc (20200917-1) FTBFS due to a missing hurd entry in the // +build line of libgo/go/net/fd_posix.go. Attached is a patch for that missing entry. With it the latest Debian snapshot has been successfully built. Test results for libgo and go are:

Bug#970673: nspr: Some tests are not run due to a bug in debian/rules

Source: nspr Version: 4.28-1 Severity: important Tags: patch User: n...@packages.debian.org Usertags: linux-any Hello, In debian/rules the runtests.sh script is not run properly. The line cd nspr/pr/tests && grep -v '^\(fdcach\|gethost\|getproto\|nblayer\|peek\|socket\|vercheck\)$$'

Bug#970659: nspr: FTBFS on hurd-i386

Source: nspr Version: 4.28-1 Severity: Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Currently libdrm FTBFS GNU/Hurd due to a parenthesis bug in ptsync.c. Attached is a patch to fix this: nspr_pr_src_pthreads_ptsynch.c.diff. Furthermore for the tests to succeed on

Bug#970614: gcc-10: Please disable systemtap-sdt-dev build-dep on non-Linux

On Sat, 2020-09-19 at 22:05 +0200, Samuel Thibault wrote: > Package: gcc-10 > Version: 10.2.0-7 > Severity: important > Tags: patch > > Hello, > > systemtap is a Linux thing, and doesn't currently build on non-Linux > ports, could you disable the dependency as the attached patch does? Hi

Re: Bug#970614: gcc-10: Please disable systemtap-sdt-dev build-dep on non-Linux

On Sat, 2020-09-19 at 22:05 +0200, Samuel Thibault wrote: > Package: gcc-10 > Version: 10.2.0-7 > Severity: important > Tags: patch > > Hello, > > systemtap is a Linux thing, and doesn't currently build on non-Linux > ports, could you disable the dependency as the attached patch does? Hi

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

On Wed, 2020-09-16 at 17:14 +0300, Timo Aaltonen wrote: > On 16.9.2020 10.53, Svante Signell wrote: > > On Tue, 2020-09-15 at 23:49 +0300, Timo Aaltonen wrote: > > > On 15.9.2020 19.50, Svante Signell wrote: > > > > Both patches (somewhat modified) submitted upst

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

On Wed, 2020-09-16 at 17:14 +0300, Timo Aaltonen wrote: > On 16.9.2020 10.53, Svante Signell wrote: > > On Tue, 2020-09-15 at 23:49 +0300, Timo Aaltonen wrote: > > > On 15.9.2020 19.50, Svante Signell wrote: > > > > Both patches (somewhat modified) submitted upst

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

On Tue, 2020-09-15 at 23:49 +0300, Timo Aaltonen wrote: > On 15.9.2020 19.50, Svante Signell wrote: > > > > Both patches (somewhat modified) submitted upstream to the old > > issues: > > https://gitlab.freedesktop.org/mesa/drm/-/issues/23 > > https://gitlab.fre

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

On Tue, 2020-09-15 at 23:49 +0300, Timo Aaltonen wrote: > On 15.9.2020 19.50, Svante Signell wrote: > > > > Both patches (somewhat modified) submitted upstream to the old > > issues: > > https://gitlab.freedesktop.org/mesa/drm/-/issues/23 > > https://gitlab.fre

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

On Mon, 2020-09-14 at 20:52 +0300, Timo Aaltonen wrote: > On 14.9.2020 18.44, Svante Signell wrote: > > found 909436 2.4.102-1 > > thanks > > > > Hello again, > > > > libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still > > missing supp

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

On Mon, 2020-09-14 at 20:52 +0300, Timo Aaltonen wrote: > On 14.9.2020 18.44, Svante Signell wrote: > > found 909436 2.4.102-1 > > thanks > > > > Hello again, > > > > libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still > > missing supp

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

found 909436 2.4.102-1 thanks Hello again, libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still missing support for Hurd in drm.h and xf86drm.h. Attached is a patch, hurd- port.diff, to fix this. The rest of that patch address PATH_MAX issues in xf86dri.c as PATH_MAX is not defined

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

found 909436 2.4.102-1 thanks Hello again, libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still missing support for Hurd in drm.h and xf86drm.h. Attached is a patch, hurd- port.diff, to fix this. The rest of that patch address PATH_MAX issues in xf86dri.c as PATH_MAX is not defined

Bug#970304: libdrm: FTBFS on kfreebsd-any

Source: libdrm Version: 2.4.102-1 Severity: important Tags: ftbfs, patch User: debian-k...@lists.debian.org Usertags: kfreebsd Hello, Currently libdrm FTBFS GNU/kFreeBSD (and GNU/Hurd) due to usage of #elif __FreeBSD__ instead of #elif defined(__FreeBSD__) in xf86drm.c. Attached is a patch to

Bug#970304: libdrm: FTBFS on kfreebsd-any

Source: libdrm Version: 2.4.102-1 Severity: important Tags: ftbfs, patch User: debian-k...@lists.debian.org Usertags: kfreebsd Hello, Currently libdrm FTBFS GNU/kFreeBSD (and GNU/Hurd) due to usage of #elif __FreeBSD__ instead of #elif defined(__FreeBSD__) in xf86drm.c. Attached is a patch to

Bug#969968: systemtap: FTBFS on non-linux architectures

Source: systemtap Version: 4.3-2 Severity: important Tags: patch Usertags: hurd-i386, kfreebsd-any User: debian-h...@lists.debian.org, debian-k...@lists.debian.org Hello, Currently systemtap FTBFS on GNU/Hurd and GNU/kFreeBSD-any due to several linux-specific includes in some .cxx-files and

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #25, sr #110199 (project administration): Hi Ineiev, Any results from your discussions with Samuel? ___ Reply to this item at:

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #25, sr #110199 (project administration): Hi Ineiev, Any results from your discussions with Samuel? ___ Reply to this item at:

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #23, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #23, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #22, sr #110199 (project administration): Hi again. I don't really understand what you mean by "confirm your commitment to maintain these notices in the long run". If a patch for example does not change the copyright and license information does not have to change at all. Or do

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #22, sr #110199 (project administration): Hi again. I don't really understand what you mean by "confirm your commitment to maintain these notices in the long run". If a patch for example does not change the copyright and license information does not have to change at all. Or do

Bug#909436: 909436: libdrm FTBFS on GNU/Hurd

ping

Bug#909436: 909436: libdrm FTBFS on GNU/Hurd

ping

Bug#960197: mesa: FTBFS on hurd-i386

Source: mesa Version: 20.0.6-3 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Currently mesa FTBFS on GNU/Hurd due to a missing struct definition. The NEW attached patch src_glx_dri_common.h.diff fixes that problem. Strangely this problem does not

Bug#960197: mesa: FTBFS on hurd-i386

Source: mesa Version: 20.0.6-3 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Currently mesa FTBFS on GNU/Hurd due to a missing struct definition. The NEW attached patch src_glx_dri_common.h.diff fixes that problem. Strangely this problem does not

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #20, sr #110199 (project administration): Hi again. I have now added Copyright and License information to all files where it is needed. Hopefully I have not missed any. Please let me know if I did or if there is still something missing or in need of correction. Thanks! (file

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #20, sr #110199 (project administration): Hi again. I have now added Copyright and License information to all files where it is needed. Hopefully I have not missed any. Please let me know if I did or if there is still something missing or in need of correction. Thanks! (file

Bug#959975: mesa: FTBFS on hurd-i386

Source: mesa Version: 20.0.6-1 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Currently mesa FTBFS on GNU/Hurd due to a missing struct definition. Version 20-0.4-2 built successfully earlier. The attached patch src_glx_dri_common.h.diff fixes

Bug#959975: mesa: FTBFS on hurd-i386

Source: mesa Version: 20.0.6-1 Severity: important Tags: ftbfs, patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Currently mesa FTBFS on GNU/Hurd due to a missing struct definition. Version 20-0.4-2 built successfully earlier. The attached patch src_glx_dri_common.h.diff fixes

Bug#956414: RFS: eudev/3.2.9-7+debian2: [ITP] /dev/ and hotplug management daemon

On Sat, 2020-05-02 at 18:27 -0400, Boyuan Yang wrote: > Hi Svante, > > (see bottom) > > On Sat, 02 May 2020 18:18:26 +0200 Svante Signell < > svante.sign...@gmail.com> > wrote: > > Hi again, > > > > I uploaded a new version, 3.2.9-7+debian2 which fi

Bug#956414: RFS: eudev/3.2.9-7+debian2: [ITP] /dev/ and hotplug management daemon

Hi again, I uploaded a new version, 3.2.9-7+debian2 which fixes many lintian warnings: * binary-control-field-duplicates-source * out-of-date-standards-version * package-uses-old-debhelper-compat-version * xc-package-type-in-debian-control * rules-requires-root-missing *

Bug#956414: RFS: eudev/3.2.9-7+debian2: [ITP] /dev/ and hotplug management daemon

Hi again, I uploaded a new version, 3.2.9-7+debian2 which fixes many lintian warnings: * binary-control-field-duplicates-source * out-of-date-standards-version * package-uses-old-debhelper-compat-version * xc-package-type-in-debian-control * rules-requires-root-missing *

Bug#956414: #956414: Upload a partially fixed version?

On Mon, 2020-04-13 at 00:36 +0200, Svante Signell wrote: > Hi again, > > I saw that there was some complaints from lintian of the uploaded > version. I've fixed some of them. Upload again? > > BTW: running lintian with the --pedantic flag does not show all > issues as 9

Bug#956414: #956414: Upload a partially fixed version?

On Mon, 2020-04-13 at 00:36 +0200, Svante Signell wrote: > Hi again, > > I saw that there was some complaints from lintian of the uploaded > version. I've fixed some of them. Upload again? > > BTW: running lintian with the --pedantic flag does not show all > issues as 9

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #18, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #18, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

Bug#909436: libdrm: Found 909436 2.4.101-2

found 909436 2.4.101-2 thanks

Bug#909436: libdrm: Found 909436 2.4.101-2

found 909436 2.4.101-2 thanks

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #17, sr #110199 (project administration): Thanks for reopening #110199. I don't really understand your comment #16. Do you mean that I should add copyright and license information to all files in the patches directory? Or the ones larger than 10 lines? If that is what you mean

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #17, sr #110199 (project administration): Thanks for reopening #110199. I don't really understand your comment #16. Do you mean that I should add copyright and license information to all files in the patches directory? Or the ones larger than 10 lines? If that is what you mean

[sr #110224] Cross-building of GNU/Hurd and additional packages

URL: Summary: Cross-building of GNU/Hurd and additional packages Project: Savannah Administration Submitted by: gnu_srs Submitted on: Sun 19 Apr 2020 10:24:55 PM UTC Category:

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #15, sr #110199 (project administration): Please, I did submit a new tarball after sending that message. And commented on your feedback. Please reopen this issue. Thanks! ___ Reply to this item at:

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #15, sr #110199 (project administration): Please, I did submit a new tarball after sending that message. And commented on your feedback. Please reopen this issue. Thanks! ___ Reply to this item at:

Bug#956820: gccgo does not implement syscall in hurd-i386

Hi Praveen, Which packages in Debian GNU/Hurd did you install to build golang- github-nsf-termbox-go? I can maybe try out the build to find out where it fials. Thanks! On Wed, 2020-04-15 at 22:34 +0530, Pirate Praveen wrote: > Package: gccgo-9 > Version: 9.3.0-9 > Severity: important >

Bug#956820: gccgo does not implement syscall in hurd-i386

Hi Praveen, Which packages in Debian GNU/Hurd did you install to build golang- github-nsf-termbox-go? I can maybe try out the build to find out where it fials. Thanks! On Wed, 2020-04-15 at 22:34 +0530, Pirate Praveen wrote: > Package: gccgo-9 > Version: 9.3.0-9 > Severity: important >

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #13, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #13, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

Re: Expired ports archive key on current-hurd-i386 image

On Wed, 2020-04-15 at 18:50 +0530, Pirate Praveen wrote: > > On Tue, Apr 14, 2020 at 8:30 pm, Svante Signell > wrote: > > On Tue, 2020-04-14 at 23:34 +0530, Pirate Praveen wrote: > > > > Pirate Praveen, le mar. 14 avril 2020 21:48:17 +0530, a ecrit: > > >

Re: Expired ports archive key on current-hurd-i386 image

On Tue, 2020-04-14 at 23:34 +0530, Pirate Praveen wrote: > > > Pirate Praveen, le mar. 14 avril 2020 21:48:17 +0530, a ecrit: > > Since I can't ssh into it yet, I can't share the logs. I have > > installed openssh-server on the vm but I can't ssh into vm from my > > host. > > I'm trying to ssh

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #12, sr #110199 (project administration): You are right, coreutils/coreutils-8.23-noman-1.patch does not have a license. Looking more closely at applied patches I found out that it is not needed. Just remove it from the tarball. Regrading the patches for glibc README.patches

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #12, sr #110199 (project administration): You are right, coreutils/coreutils-8.23-noman-1.patch does not have a license. Looking more closely at applied patches I found out that it is not needed. Just remove it from the tarball. Regrading the patches for glibc README.patches

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #10, sr #110199 (project administration): Hi again, As explained in patches/README.patches most patches are smaller than 10 lines, and therefore does not need to have Copyright information. They are denoted SHORT in that file. The longer patches do have Copyright information:

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #10, sr #110199 (project administration): Hi again, As explained in patches/README.patches most patches are smaller than 10 lines, and therefore does not need to have Copyright information. They are denoted SHORT in that file. The longer patches do have Copyright information:

Bug#956414: #956414: Upload a partially fixed version?

Hi again, I saw that there was some complaints from lintian of the uploaded version. I've fixed some of them. Upload again? BTW: running lintian with the --pedantic flag does not show all issues as 956...@bugs.debian.org does. Which option(s) trigger all the output at the link? Thanks!

Bug#956414: #956414: Upload a partially fixed version?

Hi again, I saw that there was some complaints from lintian of the uploaded version. I've fixed some of them. Upload again? BTW: running lintian with the --pedantic flag does not show all issues as 956...@bugs.debian.org does. Which option(s) trigger all the output at the link? Thanks!

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #8, sr #110199 (project administration): ping! ___ Reply to this item at: ___ Message sent via Savannah

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #8, sr #110199 (project administration): ping! ___ Reply to this item at: ___ Message sent via Savannah

Bug#956414: RFS: eudev/3.2.9-7+debian1: [ITP] /dev/ and hotplug management daemon

Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "eudev" * Package name: eudev Version : 3.2.9-7+debian1 Upstream Author : NA * URL : https://gitweb.gentoo.org/proj/eudev.git * License : GPL-2+ *

Bug#956414: RFS: eudev/3.2.9-7+debian1: [ITP] /dev/ and hotplug management daemon

Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "eudev" * Package name: eudev Version : 3.2.9-7+debian1 Upstream Author : NA * URL : https://gitweb.gentoo.org/proj/eudev.git * License : GPL-2+ *

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #7, sr #110199 (project administration): Hi again. This time I've tried to comply with all your requests of Copyright and License info. Please le me know if something is still missing. Attaching an updated tarball: hurd-cross.tar.gz. Thanks! (file #48777)

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #7, sr #110199 (project administration): Hi again. This time I've tried to comply with all your requests of Copyright and License info. Please le me know if something is still missing. Attaching an updated tarball: hurd-cross.tar.gz. Thanks! (file #48777)

[sr #110199] Cross-building of GNU/Hurd and additional packages

Follow-up Comment #6, sr #110199 (project administration): Hi Inieiev, I'll make one more effort to to comply to your requirements. If you reject the next tarball, I'll publish the project elsewhere, gitlab or github (god forgive) :( ___

<    1   2   3   4   5   6   7   8   9   10   >