Running pybuild tests with search path for entry_points()
(Please CC me as I'm not subscribed to debian-devel)
Hello,
I am currently trying to update src:kiwi to its latest upstream version to fix
#1069389 [1].
The problem that I am now stuck with is that the testsuite uses the entry_points
class to test for the available kiwi.tasks. It looks like something like this:
from importlib_metadata import entry_points
for entry in dict.get(entry_points(), 'kiwi.tasks'):
discovered_tasks[entry.name] = entry.load()
However, that fails because the kiwi module needs to be either installed for
entry_points() to find "kiwi.tasks" or the PYTHONPATH needs to include the
build directory below ".pybuild". Otherwise, entry_points() will not include
"kiwi.tasks" and the testsuite fails.
I noticed that entry_points() will also work as expected if the python
interpretor
is run from within the build directory below ".pybuild", so I tried adding the
following to debian/rules according to [2]:
export PYTHONPATH = $(CURDIR)
export PYBUILD_TEST_ARGS_python3 = cd {build_dir}; python{version} -m discover
That doesn't work unfortunately and entry_points() still fails and there doesn't
seem to be much documentation available for pybuild which explains how to adjust
PYTHONPATH for running the testuite.
Note that I tried this with kiwi 10.0.16 plus the patch from [3]. I put up a
little
reproducer in [4].
Does anyone know how to make pybuild set the proper PYTHONPATH so that
entry_points()
works while running the testsuite?
Thanks,
Adrian
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069389
> [2] https://wiki.debian.org/Python/Pybuild
> [3] https://github.com/OSInside/kiwi/pull/2550
> [4] https://github.com/OSInside/kiwi/issues/2548#issuecomment-2103993758
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Status of the t64 transition
Hello, On Thu, 2024-04-18 at 21:22 +0200, Sebastian Ramacher wrote: > Finally, packages that need rebuilds but currently have open FTBFS (RC + > ftbfs tag) bugs: > (...) > virtualjaguar I already have a tentative patch and will fix the package within the next days. I am also preparing to fix two other bugs, one being missing SDL-2 support and the other the FTBFS after rebuild from the same source unpack. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Requesting help with the t64 transition
Hi, On Tue, 2024-03-05 at 09:56 +0100, John Paul Adrian Glaubitz wrote: > I would like to ask for help with the t64 transition for m68k, powerpc and > sh4 because it's getting too much for me alone and I'm really exhausted. > > I have build many packages for powerpc already and some for m68k and sh4, > but I'm not there yet. The progress with powerpc is the furthest, but perl > is still uninstallable and I don't really understand why because cudf does > not produce any useful output. Some update. I have managed to get powerpc back to the state where the devscripts and build-essential packages can be installed. However, I had to update the chroots on the buildds manually as debbootstrap currently fails due to left-over perl-modules package. debbootstrap first downloads perl-modules-5.38_5.38.2-3_all.deb, then later tries to install perl_5.38.2-3.2_powerpc.deb which causes dpkg to bail out. It can be reproduced with: # debootstrap --no-check-gpg --arch=powerpc --variant=buildd \ --include=debian-ports-archive-keyring unstable sid-powerpc-sbuild \ http://ftp.ports.debian.org/debian-ports Thus, we need to get rid of perl-modules-5.38_5.38.2-3_all.deb from the repositories in order to be able to create fresh chroots with debbootstrap again. Since packages in Debian Ports are directly synced from the main repos for arch:all, this needs to be done by the FTP masters. For m68k and sh4, I managed to build perl and pam so that all Perl packages are rebuilding for now. Thorsten Glaser is kindly helping me with the transition on m68k. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Re: Perl problem - loadable library and perl binaries are mismatched
Hi Roderich,
On Wed, 2024-03-06 at 19:20 +0100, Roderich Schupp wrote:
> Hi,
>
> > Parser.c: loadable library and perl binaries are mismatched (got first
> > handshake key 0xb600080, needed 0xb700080)
> >
>
>
> The upper 16 bits in these keys (i.e. 0xb60 vs 0xb70) is
> sizeof(PerlInterpreter), the one that some XS module saw
> when it was built vs the size your current perl executable was built with.
> From the location of the error message
> it looks as the build process ("perl Build") has just created the "glue"
> shared library (blib/arch/auto/XS/Parse/
> Keyword/Keyword.so), next it is going to generate documentation (man pages).
> Unless there's an error warning,
> this doesn't produce any output. I ran "perl Build" under strace, this shows
> that doc generation loads Pod::Html
> (probably to generate HTML pages as well, though none were requested) and
> finally this loads HTML::Parser. The
> latter is an XS module
> (/usr/lib/x86_64-linux-gnu/perl5/5.38/auto/HTML/Parser/Parser.so) and seems
> to emit the
> above message.
>
> So the reason is that your HTML/Parser/Parser.so (maybe a version not in the
> canonical path?) is built with a
> different struct PerlInterpreter. The difference in sizeof(PerlInterpreter)
> can probably explained with the
> time64 transition as PerlInterpreter contains a struct stat.
Thanks a lot for the detailed analysis. In fact, libhtml-parser-perl has not
been rebuilt against the time64_t
Perl package yet [1] which would align with your explanation. I'll try to
rebuild the package locally and if
it fixes the problem, I'll binNMU it for powerpc.
Your explanation will enable me to debug future occurrences as I now understand
the underlying problem.
Thanks,
Adrian
> [1] https://buildd.debian.org/status/package.php?p=libhtml-parser-perl
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Perl problem - loadable library and perl binaries are mismatched
Hi,
On Tue, 2024-03-05 at 23:10 +0100, John Paul Adrian Glaubitz wrote:
> >
> > oks like it's built with dpkg-dev_1.22.4 but the time64 build flags are
> > only activated with 1.22.5.
>
> Ah, that would explain it, thank you so much!
>
> > I think there was talk about making them the default in gcc too, not
> > sure if they got there yet.
> >
> > I suppose Perl could/should store them in its configuration so they'd be
> > passed to all XS module builds regardless of what dpkg-buildflags says.
> > But currently things from dpkg-buildflags get explicitly filtered away [1].
> >
> > IIRC the rationale for this was that packages could opt in/out of security
> > hardening flags independently. That doesn't seem desirable here as they
> > make the XS module ABI incompatible as you've noticed.
> >
> > [1] see https://sources.debian.org/src/perl/5.38.2-3.1/debian/rules/#L188
> > I think -fstack-protector gets passed through there as an exception,
> > so doing the same with the relevant time64 flags should do the trick.
> >
>
> Thanks! You saved me a lot of headaches!
I have run into this issue again trying to rebuild libxs-parse-keyword-perl
with a src:perl that was built with dpkg_1.22.5:
Building XS-Parse-Keyword
powerpc-linux-gnu-gcc -Isrc/ -I/usr/lib/powerpc-linux-gnu/perl/5.38/CORE -fPIC
-I. -Ihax -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing
-pipe -I/usr/local/include -
D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
-fstack-protector-strong -Wformat -
Werror=format-security -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
-fstack-protector-strong -Wformat -Werror=format-
security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2 -o src/infix.o src/infix.c
powerpc-linux-gnu-gcc -Isrc/ -I/usr/lib/powerpc-linux-gnu/perl/5.38/CORE -fPIC
-I. -Ihax -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing
-pipe -I/usr/local/include -
D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
-fstack-protector-strong -Wformat -
Werror=format-security -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
-fstack-protector-strong -Wformat -Werror=format-
security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
-D_FORTIFY_SOURCE=2 -o src/keyword.o src/keyword.c
src/keyword.c: In function 'probe_piece':
src/keyword.c:348:37: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'U32' {aka 'long unsigned int'} [-Wformat=]
348 | croak("TODO: probe_piece on type=%d\n", type);
|~^
| | |
| int U32 {aka long unsigned int}
|%ld
src/keyword.c: In function 'parse_piece':
src/keyword.c:828:37: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'U32' {aka 'long unsigned int'} [-Wformat=]
828 | croak("TODO: parse_piece on type=%d\n", type);
|~^
| | |
| int U32 {aka long unsigned int}
|%ld
powerpc-linux-gnu-gcc -Isrc/ -I/usr/lib/powerpc-linux-gnu/perl/5.38/CORE
-DVERSION="0.39" -DXS_VERSION="0.39" -fPIC -I. -Ihax -c -D_REENTRANT
-D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
-fstack-
protector-strong -Wformat -Werror=format-security -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
-fstack-protector-strong -
Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -o lib/XS/Parse/Keyword.o
lib/XS/Parse/Keyword.c
ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/XS/Parse/Keyword/Keyword.bs')
powerpc-linux-gnu-gcc -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=.
-fstack-protector-strong -Wformat -Werror=format-
security -Wl,-z,relro -Wl,-z,now -shared -L/usr/local/lib
-fstack-protector-strong -o blib/arch/auto/XS/Parse/Keyword/Keyword.so
lib/XS/Parse/K
Re: Perl problem - loadable library and perl binaries are mismatched
On Wed, 2024-03-06 at 00:08 +0200, Niko Tyni wrote: > (Oops, forgot the Cc you asked for. So resending. Apologies for the > duplicate on the list.) No worries. > On Tue, Mar 05, 2024 at 09:17:17PM +0100, John Paul Adrian Glaubitz wrote: > > > I am getting strange Perl error after rebuilding Perl for the time64_t > > transition on powerpc: > > > > loadable library and perl binaries are mismatched (got first handshake key > > 0xb600080, needed 0xb700080) > > > > See: > > https://buildd.debian.org/status/fetch.php?pkg=libdevice-usb-perl=powerpc=0.38-3=1709663348=0 > > > > I have already rebuilt Perl once again against the new time64_t libraries, > > but that didn't help although the package builds fine locally. > > > > Does anyone knowledgeable with Perl know what's going on? > > (You're in somewhat uncharted territory unfortunately, as none of this > was tested beforehand.) Yikes. > Looks like it's built with dpkg-dev_1.22.4 but the time64 build flags are > only activated with 1.22.5. Ah, that would explain it, thank you so much! > I think there was talk about making them the default in gcc too, not > sure if they got there yet. > > I suppose Perl could/should store them in its configuration so they'd be > passed to all XS module builds regardless of what dpkg-buildflags says. > But currently things from dpkg-buildflags get explicitly filtered away [1]. > > IIRC the rationale for this was that packages could opt in/out of security > hardening flags independently. That doesn't seem desirable here as they > make the XS module ABI incompatible as you've noticed. > > [1] see https://sources.debian.org/src/perl/5.38.2-3.1/debian/rules/#L188 > I think -fstack-protector gets passed through there as an exception, > so doing the same with the relevant time64 flags should do the trick. > Thanks! You saved me a lot of headaches! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Perl problem - loadable library and perl binaries are mismatched
Hello, I am getting strange Perl error after rebuilding Perl for the time64_t transition on powerpc: loadable library and perl binaries are mismatched (got first handshake key 0xb600080, needed 0xb700080) See: https://buildd.debian.org/status/fetch.php?pkg=libdevice-usb-perl=powerpc=0.38-3=1709663348=0 I have already rebuilt Perl once again against the new time64_t libraries, but that didn't help although the package builds fine locally. Does anyone knowledgeable with Perl know what's going on? Thanks, Adrian PS: Please CC me, I am not subscribed to debian-devel. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Requesting help with the t64 transition
On Tue, 2024-03-05 at 09:56 +0100, John Paul Adrian Glaubitz wrote: > For m68k, there is mitchy.debian.net and for powerpc, there is > perotto.debian.net. > > For sh4, qemu-user can be used. > > Chroots here: https://people.debian.org/~glaubitz/chroots/ I'm collecting packages for bootstrap here: https://people.debian.org/~glaubitz/bootstrap/ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Requesting help with the t64 transition
Hello, I would like to ask for help with the t64 transition for m68k, powerpc and sh4 because it's getting too much for me alone and I'm really exhausted. I have build many packages for powerpc already and some for m68k and sh4, but I'm not there yet. The progress with powerpc is the furthest, but perl is still uninstallable and I don't really understand why because cudf does not produce any useful output. See: https://buildd.debian.org/status/fetch.php?pkg=bfs=powerpc=3.1.2-1=1709623862=0 I am not subscribed to debian-devel, so please CC. For m68k, there is mitchy.debian.net and for powerpc, there is perotto.debian.net. For sh4, qemu-user can be used. Chroots here: https://people.debian.org/~glaubitz/chroots/ Thank you, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Resuming snapshot.debian.org for Debian Ports
(Please CC me in replies as I'm not subscribed to debian-devel) Hello, does anyone know whether there are any plans to resume snapshot.debian.org for Debian Ports? The service has been unavailable for some months and the lack of snapshots means that it becomes more difficult to fix the buildd queue once it has become stuck due to Mini-DAK as used by Debian Ports not supporting cruft [1]. Thanks, Adrian > [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
New sparc64 porterbox available
Hi! After a long time since the previous sparc64 porterbox went offline since it had to move out of the data center at my old university, I am happy to announce that a new sparc64 porterbox is now available. The porterbox is a virtual machine (LDOM) hosted on a SPARC T4-1 with 96 GB of RAM and more than 500 GB of disk space (I hope we will be able to increase the available disk space in the near future). Hosting is kindly provided by Cononva Communications GmbH in Salzburg, Austria. I have already verified that creating a chroot works as expected and I could test-build a package without any issues, so I am confident it should work for everyone else. For questions and problems reports, please drop me an email or join #debian-ports on OFTC IRC network. Thanks, Adrian > [1] https://db.debian.org/machines.cgi?host=stadler -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1050994: xutils-dev: Please add support for loong64
Source: xutils-dev Version: 1:7.7+6.1 Severity: normal User: debian-devel@lists.debian.org Usertags: loong64 X-Debbugs-Cc: debian-devel@lists.debian.org,zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! Multiple X packages currently fail to build from source on loong64 due to missing architecture support in xutils-dev [1]: gcc: warning: LinuxMachineDefines: linker input file unused because linking not done gcc: error: LinuxMachineDefines: linker input file not found: No such file or directory This should be fixed in a similar fashion for loong64 as it has been done for riscv64 in [2]. I have CC'ed two engineers from Loongson to make them aware of the bug so they can work on a patch to add loong64 support. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=xaw3d=loong64=1.5%2BF-1.1=1693526902=0 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026002 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1050893: gcc-13: Please disable Ada, D, Go and M2 as well as GDB support on loong64
Source: gcc-13 Version: 13.2.0-2 Severity: normal Tags: patch User: debian-devel@lists.debian.org Usertags: loong64 X-Debbugs-Cc: debian-devel@lists.debian.org Hello! In order to ease the bootstrap of the new loong64 port, please reduce the build dependencies and number of enabled languages. - Please disable Ada, D, Go and M2 for loong64 in debian/rules.def. - Please add "!loong64" for gdb in debian/control.m4 The attached patch implements these changes. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/gcc-13-13.2.0/debian/control.m4 new/gcc-13-13.2.0/debian/control.m4 --- old/gcc-13-13.2.0/debian/control.m4 2023-07-11 17:40:07.0 +0200 +++ new/gcc-13-13.2.0/debian/control.m4 2023-08-30 20:17:54.515043971 +0200 @@ -81,7 +81,7 @@ libzstd-dev, zlib1g-dev, SDT_BUILD_DEP USAGE_BUILD_DEP BINUTILS_BUILD_DEP, gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, - gdb`'NT [!riscv64 !mipsel !mips64el], OFFLOAD_BUILD_DEP + gdb`'NT [!loong64 !riscv64 !mipsel !mips64el], OFFLOAD_BUILD_DEP texinfo (>= 4.3), LOCALES, sharutils, procps, FORTRAN_BUILD_DEP GNAT_BUILD_DEP GO_BUILD_DEP GDC_BUILD_DEP GM2_BUILD_DEP ISL_BUILD_DEP MPC_BUILD_DEP MPFR_BUILD_DEP GMP_BUILD_DEP PHOBOS_BUILD_DEP diff -Nru old/gcc-13-13.2.0/debian/rules.defs new/gcc-13-13.2.0/debian/rules.defs --- old/gcc-13-13.2.0/debian/rules.defs 2023-08-04 04:48:33.0 +0200 +++ new/gcc-13-13.2.0/debian/rules.defs 2023-08-30 20:11:21.780573351 +0200 @@ -850,6 +850,7 @@ ada_no_cpus:= m32r sh3 sh3eb sh4eb ada_no_cpus+= arc ada_no_cpus+= ia64 +ada_no_cpus+= loong64 ada_no_systems := ada_no_cross := no ada_no_snap:= no @@ -1006,7 +1007,7 @@ with_libcc1 := endif -go_no_cpus := arc avr hppa +go_no_cpus := arc avr hppa loong64 go_no_cpus += m68k # See PR 79281 / PR 83314 go_no_systems := kfreebsd ifneq (,$(filter $(distrelease),precise)) @@ -1064,7 +1065,7 @@ # D --- d_no_cross := yes d_no_snap := -d_no_cpus := alpha arc ia64 m68k sh4 s390 sparc64 +d_no_cpus := alpha arc loong64 ia64 m68k sh4 s390 sparc64 d_no_systems := gnu kfreebsd-gnu ifneq ($(single_package),yes) @@ -1261,7 +1262,7 @@ with_m2 := yes endif endif -m2_no_archs = powerpc ppc64 sh4 kfreebsd-amd64 kfreebsd-i386 hurd-amd64 hurd-i386 +m2_no_archs = loong64 powerpc ppc64 sh4 kfreebsd-amd64 kfreebsd-i386 hurd-amd64 hurd-i386 ifneq (,$(filter $(DEB_TARGET_ARCH),$(m2_no_archs))) with_m2 := disabled for cpu $(DEB_TARGET_ARCH) endif
Re: Bug#1033888: ITP: usbscale -- read weight data from a USB scale
Hi Johnny! On Mon, 2023-04-03 at 16:50 -0300, johnny.nor...@policorp.com.br wrote: > If you are interested in sponsoring a package that includes a scale with > USB, you should reach out to the seller or the manufacturer of the > product to discuss potential sponsorship opportunities. They may have > specific requirements or guidelines for sponsorships, so it's best to > directly communicate with them to ensure a smooth transaction. I think you are misunderstanding something. This isn't about a financial sponsorship but package sponsoring, i.e. uploading a package as a Debian Developer on behalf on the person who created the package and doesn't have upload rights themselves. See: https://wiki.debian.org/DebianMentorsFaq#Sponsored_Packages Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1033888: ITP: usbscale -- read weight data from a USB scale
Hi John! > Package: wnpp > Severity: wishlist > Owner: John Scott > Tags: newcomer > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: usbscale > Upstream Contact: Eric Jiang > * URL : https://github.com/erjiang/usbscale > * License : GPL 3.0 or any later version > Programming Lang: C > Description : read weight data from a USB scale > > This package provides a utility one can use to read data from various > USB scales, ones which are sold as postage scales in particular. I'm actually about to buy such a scale with USB and I would therefore be interested in sponsoring this package. Let me know if you're interested. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))
Hi Helge! On 1/11/23 15:03, Helge Deller wrote: Yes, sadly we don't have a working java right now on hppa, and it will probably take some more time to get one. At least I won't have time for it during the next few months. But it would be sad to loose those bindings... There are some efforts to bring back gcj if that helps: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609530.html The reason for being BD-Uninstallable is the lack of cruft in Debian Ports: https://lists.debian.org/debian-sparc/2017/12/msg00060.html as a result of some packages FTBFS. That is for sparc and m68k? (Where both the needed KDE packages are uninstallable) Adrian, as there seems to be various arches (and reasons) will you speak upstream? Yes, I have already replied upstream. I will follow up there tonight. One of the biggest problems for Debian Ports remains the lack of cruft as explained in my post to the debian-sparc mailing list above. This causes these long BD-Uninstallable queues. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))
(posting this to debian-devel@ since debian-ports@ cross-posts to too many lists) Hello Rene! On 1/10/23 19:25, Rene Engelhard wrote: (which are for many BD-Uninstallable since ages because it does not have Java (anymore), didn't do a long-ago transition, ...) They all have Java support except for hppa, see: https://buildd.debian.org/status/package.php?p=openjdk-11=sid https://buildd.debian.org/status/package.php?p=openjdk-18=sid The reason for being BD-Uninstallable is the lack of cruft in Debian Ports: https://lists.debian.org/debian-sparc/2017/12/msg00060.html as a result of some packages FTBFS. So, it's more a Debian Ports problem than an architecture problem. Also, both alpha and ia64 are BD-Uninstallable because you don't want to drop clang from Build-Depends from these architectures for whatever reason despite these not having had a LLVM/clang port for several years: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963109 If clang could be dropped from Build-Depends for alpha and ia64, that would already help us move a little further. speak up at upstream or they will be gone. And without those bridges no architecture support for it. I will see what I can do. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Converting Debian OpenStack images to btrfs
(I'm not subscribed to the list, please CC me. Thanks!) Hello! I'm using Debian's OpenStack images to deploy buildd hosts for Debian Ports. [1] To workaround a longstanding qemu/glibc compatibility issue [2], I need the images to use btrfs instead of ext4 and I was wondering whether anyone can give me some hints on how to convert the images provided at [1] from ext4 to btrfs. Thanks, Adriam [1] https://cloud.debian.org/cdimage/cloud/OpenStack/ [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi! On 5/12/22 03:29, M. Zhou wrote: > I learned in disappointment after becoming LuaJit uploader that > the LuaJit upstream behaves uncooperatively especially for IBM > architectures [1]. IIUC, the upstream has no intention to care > about IBM architectures (ppc64el, s390x). > > The current ppc64el support on stable is done through cherry-picked > out-of-tree patch. And I learned that the patch is no longer > functional[2] for newer snapshots if we step away from that > ancient 2.1.0~beta3 release. > > However, architectures like amd64 needs relatively newer version[3], > while IBM architecture still has demand luajit[4] (only the > ancient version will possibly work on IBM archs). I saw that Matej Cepl was replying in the thread who is a colleague of mine and who is the maintainer of the luajit package in openSUSE/SLE. Since SUSE has a commercial interest in working POWER/S390 support, he takes care of the package and makes sure it keeps working on these architectures. My suggestion would be to just pick the packages from openSUSE [1] since they are kept up-to-date. Adrian > [1] https://build.opensuse.org/package/show/devel:languages:lua/luajit -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1008145: ITP: partman-hfs -- Add to partman support for hfs and hfsplus
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz X-Debbugs-Cc: debian-devel@lists.debian.org,debian-powe...@lists.debian.org * Package name: partman-hfs Version : 1 Upstream Author : John Paul Adrian Glaubitz * URL : https://salsa.debian.org/installer-team/partman-btrfs * License : GPL-2.0+ Programming Lang: Shell Description : Add to partman support for hfs and hfsplus This package contains partman support for creating HFS and HFS+ filesystems in debian-installer. HFS and HFS+ are primarily useful on Apple Macintosh computers. In particular, support for HFS/HFS+ filesystems is required in debian-installer to create boot partitions for installing GRUB on Apple Power Macintosh systems.
Re: Use of License-Reference in debian/copyright allowed?
Hi Jonas! On 1/16/22 20:06, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2022-01-16 19:53:48) >> Quoting John Paul Adrian Glaubitz (2022-01-16 19:38:25) >>> I have updated debian/copyright of both fs-uae-* packages to use the >>> "License-Reference" keyword, however lintian now complains about the >>> missing license texts so I'm wondering whether this approach - which >>> I like - is actually compliant with the Debian Policy? > [...] >> I firmly believe that it is Policy-compliant to reference files >> included with package base-files and installed below >> /usr/share/common-licenses. All other license texts must be included >> verbatim in the debian/copyright file > > Maybe more interesting than what I personally believe might be, that I > use that writing style generally for the about 600 packages that I am > involved in maintaining, and evidently ftpmasters agree with me. That's a very positive sign that the FTP team will accept the writing style as well. > For anyone considering to adopt this pattern, it is quite some time ago > that I helped Vasudev package Roboto fonts, and I have simplified and > extended my writing style to use the shorter field "Reference" and also > use it to reference sources of copyright holders and license grants when > not contained in licensed file itself (with a little special twist of > self-referencing canonical statements in debian/copyright). I agree it's a great idea as it saves a lot of time. Writing an acceptable debian/copyright file can be quite frustrating so this is a very welcome improvement. > I use the package ghostscript as my sort-of reference package. Look at > that for my newest inventions on copyright file writing and checking. > > See also https://wiki.debian.org/CopyrightReviewTools Thanks, I'll have a look! Thanks a lot for the quick and detailed response! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Use of License-Reference in debian/copyright allowed?
(Please CC me, I'm not subscribed to debian-devel) Hi! I'm currently updating the debian/copyright of my two packages fs-uae-arcade [1] and fs-uae-launcher [2] as both packages got rejected by the FTP team due to an incomplete debian/copyright. Since the packages contain a lot of different licenses, the debian/copyright would be very long when copying the different license texts verbatim. However, I stumbled over the fonts-roboto package which resolves this issue by using just references to the full license texts which are present on any Debian system anyway [3]. I have updated debian/copyright of both fs-uae-* packages to use the "License-Reference" keyword, however lintian now complains about the missing license texts so I'm wondering whether this approach - which I like - is actually compliant with the Debian Policy? Thanks, Adrian > [1] https://github.com/glaubitz/fs-uae-arcade-debian > [2] https://github.com/glaubitz/fs-uae-launcher-debian > [3] > https://salsa.debian.org/fonts-team/fonts-roboto/-/blob/master/debian/copyright -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#980889: RFP: binutils-sh-elf -- cross binary utilities for SuperH bare-metal systems
Hi John! On 9/26/21 13:05, John Paul Adrian Glaubitz wrote: >> This package would provide GNU Binutils suited for embedded targets, and >> would be suited for both SH-1 and SH-2 hardware at least [1]. This is needed >> to build carl9170, the libre wireless firmware for AR9170 devices that's >> currently in firmware-linux-free. That will require GCC and Newlib as well. > > I'm Debian's sh4 maintainer and I would be willing to sponsor this provided > that Matthias is fine with a separate binutils package. I had a look at the package and it throws a number of lintian errors. Are you planning to address these or are they common for all binutils-$ARCH-elf packages we currently have in Debian? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#996769: ITP: fs-uae-launcher -- Launcher and configuration program for FS-UAE
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fs-uae-launcher Version : 3.0.5 Upstream Author : Frode Solheim * URL : https://fs-uae.net/ * License : GPL-2+ Programming Lang: Python Description : Launcher and configuration program for FS-UAE FS-UAE is a cross-platform Amiga emulator based on updated emulation code from WinUAE. FS-UAE uses SDL for input, OpenAL for audio and OpenGL for graphics. . This package contains the launcher, a graphical user interface for setting up FS-UAE. This package used to be part of the fs-uae source package but has been split into a separate package by upstream. The Debian package was split for version 3.1.35 which is why fs-uae-launcher is now being submitted as a new source package. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#996768: ITP: fs-uae-arcade -- Fullscreen game browser for FS-UAE
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fs-uae-arcade Version : 3.0.5 Upstream Author : Frode Solheim * URL : https://fs-uae.net/ * License : GPL-2+ Programming Lang: Python Description : Fullscreen game browser for FS-UAE FS-UAE is a cross-platform Amiga emulator based on updated emulation code from WinUAE. FS-UAE uses SDL for input, OpenAL for audio and OpenGL for graphics. . This package contains the launcher, a graphical user interface for setting up FS-UAE. This package used to be part of the fs-uae source package but has been split into a separate package by upstream. The Debian package was split for version 3.1.35 which is why fs-uae-arcade is now being submitted as a new source package. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: gbp vs. vcswatch - how to create automatic debian tags?
Hi Timo! On 10/5/21 12:04, Timo Röhling wrote: > * John Paul Adrian Glaubitz [2021-10-05 11:45]: >> Could anyone tell me what the proper gbp command is for creating the >> changelog >> entries for the new release including the proper tag. The gbp manual [1] >> mentions >> Debian tags but it doesn't seem to explain how to create them. > > I usually run "gbp dch -R -c" first, then build and upload the > package, and finalize with "gbp tag && gbp push". > >> And if I wanted to add the tags later manually and push them, what is the >> expected >> format of the tags? Just "debian/$VERSION"? > > Yes. Perfect, thank you. This answers all my questions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: gbp vs. vcswatch - how to create automatic debian tags?
On 10/5/21 12:00, Jonas Smedegaard wrote: > I use this spell to finalize a package: > > gpb dch -a > dch -r > gbp buildpackage > gbp tag > gbp push Thanks. > (I guess specifically you were asking for the "gbp tag" step) Yes, it seems that "gbp tag" is what I was missing. I guess I can just add the missing tags with "git tag" unless gbp-tag has a similar feature to add tags for historic commits. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
gbp vs. vcswatch - how to create automatic debian tags?
(Please CC me as I'm not subscribed to debian-devel) Hi! I have noticed some time ago that vcswatch doesn't recognize the releases of some of my Debian packages such as fs-uae [1]. As a result, it sees 67 commits since the last release, asking me to perform an upload. However, I have already uploaded all changes and I'm apparently just missing the proper tags. I have always used gbp for git packaging and "gbp dch --auto" to finalize the changelog, apparently that's not sufficient. Could anyone tell me what the proper gbp command is for creating the changelog entries for the new release including the proper tag. The gbp manual [1] mentions Debian tags but it doesn't seem to explain how to create them. And if I wanted to add the tags later manually and push them, what is the expected format of the tags? Just "debian/$VERSION"? Thanks, Adrian > [1] https://tracker.debian.org/pkg/fs-uae > [2] > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.releases.html#gbp.changelog.release -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: binutils-m68hc1x: Repackage as a native package
Hi Vincent! On 9/30/21 18:03, Vincent Smeets wrote: > Hello Adrian, (I'm not sure that my first mail did reach all needed > recipients, so here again) It did. Sorry, I'm currently on vacation which I was not so busy the past days. > Yes, I am interested in you being the sponsor of my package. Does it need > to be recorded somewhere (e.g. on mentors.debian.net or in d/control) or is > it just information for me? > Can you forward the package to unstable, so it can be included in the next > Debian release? I have to review the package first which will take some time. I will start looking into it tomorrow as I just came home today and I'm pretty tired. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: partman, growlight, discoverable partitions, and fun
On 9/28/21 12:13, Wouter Verhelst wrote: > IOW, chill out, nobody's going to kill off partman unless there's > something that's *actually* better than partman. Just some comments after reading after this [1] because I honestly find it unfair the way I am being cornered here. First of all, neither Fedora or openSUSE seem to use glowlight as their primary partitioning tool nor are they using discoverable partitions. Secondly, discoverable partitions are primarily intended for containers and systemd is using mkosi [2] for generating such images with discoverable partitions. Thirdly, Luca Boccassi considers himself to be systemd upstream [3] without disclosing that information here. This is an information that he should at least have disclosed before starting to voice his support for discoverable partitions and insisting that the feature is important enough to kill off parted. Thanks, Adrian > [1] https://lwn.net/Articles/859240/ > [2] http://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html > [3] https://lwn.net/Articles/859769/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: partman, growlight, discoverable partitions, and fun
> On Sep 27, 2021, at 3:41 PM, Luca Boccassi wrote: > > On Mon, 2021-09-27 at 15:18 +0200, John Paul Adrian Glaubitz wrote: >> >>>> On Sep 27, 2021, at 2:25 PM, Luca Boccassi wrote: >>> >>> Even if that interpretation would work as an excuse to never do >>> anything, and I'm not really sure it does, this specification has been >>> published in 2014 [0] so even by Debian standard it's old stuff. >> >> That’s not what I said so. You’re trying to dismiss my opinion as completely >> invalid now by trying to frame it such that I am against progress. I am not. > > You dismissed it because it's "new technology": > >> Not for me, though. Debian has always followed the philosophy to be a >> universal >> operating system, which also meant that we can't (immediately) use all the >> new >> technologies and features that other distributions or upstream projects >> develop. You’re reducing my argument to the word “new” which is definitely not my point. As you can see from the rest of my message my primary point is that Debian follows a different philosophy meaning that we don’t always adopt technologies that other distributions use. Fedora and openSUSE are much more similar to each other than Debian is to both. > I simply pointed out that it's a 7 years old spec that saw an entire > LTS Debian version (8, we are now at 11) being released and EOL'ed > since the time it was published. If this is too new to consider, then > so are all Debian releases newer than Wheezy. Yes, but the age was never my argument. My argument was that replacing such a fundamental software component like the partitioning tool in an installer is something that has to be justified by technical merits and by weighing pros and cons against each other. The fact that’s it’s newer or has the single feature X is not sufficient in my opinion. Especially when there is no proof yet that getting support for discoverable partitions justifies the loss of features that parted has. >>> It's >>> older than Debian Jessie, which was EOL'd last year. If libparted can't >>> keep up with 7 years old stuff that in the meantime was implemented in >>> util-linux's (which is a truly universal tool) in 2014, gdisk in 2019, >>> and so on, then to me it sounds like a tool in maintenance mode: >>> perfectly fine and adequate for existing tools and programs, but not >>> quite the best choice for new tools developed from scratch. >> >> Whether a tool that was developed new from scratch is automatically better >> is not a given. The burden of proof is on the person trying to introduce the >> new software, not on the people maintaining the current set of software. >> >> And claiming that parted is in pure maintenance mode is not true either. It >> has a paid developer working on the project and is receiving updates and >> improvements. >> >> Whether growlight is better and more suitable for Debian needs to be >> technically proven, not just by arguing that it’s the newer project. >> >> Adrian > > Of course. But jumping in and saying "you should use X instead of Y", > you can't pretend that nobody asks questions such as "ok, but does libX > support this very much related and relevant 7 years old specification > that other comparable tools support", no matter how awkward it is for > libX. I was not the one that was making this request, it was Nick. I’m perfectly fine with the status quo. Again, the party introducing the new solution should provide the arguments to convince the maintainers of the existing solution. For example, a convincing argument would be a demonstration installation ISO which let’s others interested in the project test it and check whether it delivers the improvements that were promised. I don’t think that this is such an extraordinary requirement to ask for. Also, I would be interested to know what approaches are currently used in Fedora, Arch, Gentoo and openSUSE (I will check that later myself when I’m back at the computer). Adrian
Re: partman, growlight, discoverable partitions, and fun
> On Sep 27, 2021, at 2:25 PM, Luca Boccassi wrote: > > Even if that interpretation would work as an excuse to never do > anything, and I'm not really sure it does, this specification has been > published in 2014 [0] so even by Debian standard it's old stuff. That’s not what I said so. You’re trying to dismiss my opinion as completely invalid now by trying to frame it such that I am against progress. I am not. > It's > older than Debian Jessie, which was EOL'd last year. If libparted can't > keep up with 7 years old stuff that in the meantime was implemented in > util-linux's (which is a truly universal tool) in 2014, gdisk in 2019, > and so on, then to me it sounds like a tool in maintenance mode: > perfectly fine and adequate for existing tools and programs, but not > quite the best choice for new tools developed from scratch. Whether a tool that was developed new from scratch is automatically better is not a given. The burden of proof is on the person trying to introduce the new software, not on the people maintaining the current set of software. And claiming that parted is in pure maintenance mode is not true either. It has a paid developer working on the project and is receiving updates and improvements. Whether growlight is better and more suitable for Debian needs to be technically proven, not just by arguing that it’s the newer project. Adrian
Re: partman, growlight, discoverable partitions, and fun
Hello! On 9/27/21 12:46, Luca Boccassi wrote: >> Also, since parted is maintained by RedHat, I would expect that this feature >> would land in parted soon as well. >> > If the question is "why does X not use libparted", "does not support > discoverable parts spec" is a good enough answer for me. Not for me, though. Debian has always followed the philosophy to be a universal operating system, which also meant that we can't (immediately) use all the new technologies and features that other distributions or upstream projects develop. For example, we don't use systemd-homed or systemd-firstboot either. That doesn't mean Debian is per se worse off. It just means Debian tries to cater different use cases and follows different concepts. It's different for distributions like Fedora or openSUSE which focus on a very limited set of targets and use cases. That's why they can quickly adopt to all the new features and technologies that upstream projects like systemd develop. I'm not saying that one philosophy is better than the other. I'm just saying that Debian is not like these other distributions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: partman, growlight, discoverable partitions, and fun
Hello Nick! On 9/26/21 16:29, Nick Black wrote: > I'd be delighted to support them -- as in, I am honestly eager > to add ATARI support; that sounds awesome -- I just need some > way to test the implementations, either via someone running it > on the environment, or getting access to such a machine. There are emulators available for Atari such as Aranym. And emulators available for Amiga such as fs-uae. FWIW, parted should contain everything needed to be able to implement your own support for these partition tables. >> I think it makes little sense to not use libparted as it already supports >> all common and less common partition types and reimplementing everything >> that libparted makes little sense to me. > > parted did not have ZFS support when I embarked on this project > (it appears to have it now). i would not be opposed to > leveraging libparted if it presents a definite advantage; > supporting more partition types, so long as it exposes an API i > can easily work with, would be such an advantage. Well, using a missing feature in the past against parted that is present there is not such a good argument against using it, to be honest. > i do note that libparted2 is 621K in the archive, whereas > growlight itself is only 555K. it is of course possible that > all that weight is desirable functionality. I think 70k more disk space is not really a concern. > with that said, i would *still want to test on the target > environment*, to make sure i'm using libparted correctly there. > so that necessity remains. I thought you didn't depend on libparted? > would this allay your concerns? No, not really. I consider a partitioning tool to be too important to be replaced by an unproven solution. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: binutils-m68hc1x: Repackage as a native package
Hello Vincent! > It is suggested to use a native package structure to package binutils > for a less common target. The way this package should be packaged is > described in https://wiki.debian.org/PackagingLessCommonBinutilsTargets > > Please update the packaging to follow the above suggestions. I'm the primary maintainer of Debian's m68k port and I would be happy to sponsor the package for you. Let me know if you're interested. Please join the debian-68k mailing list and the #debian-ports IRC channel on OFTC if you want to get in touch with the rest of us. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#980889: RFP: binutils-sh-elf -- cross binary utilities for SuperH bare-metal systems
Hi John! > This package would provide GNU Binutils suited for embedded targets, and > would be suited for both SH-1 and SH-2 hardware at least [1]. This is needed > to build carl9170, the libre wireless firmware for AR9170 devices that's > currently in firmware-linux-free. That will require GCC and Newlib as well. I'm Debian's sh4 maintainer and I would be willing to sponsor this provided that Matthias is fine with a separate binutils package. Also, please join the debian-superh mailing list [1] and the #debian-ports IRC channel. Thanks, Adrian > [1] https://lists.debian.org/debian-superh/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: partman, growlight, discoverable partitions, and fun
Hello! On 9/26/21 12:40, Luca Boccassi wrote: > Does libparted support the discoverable partitions spec? I'm not sure, this thread is the first time I have heard about discoverable partitions. I have read up first what the motivations for these are and how useful they would be for Debian. Also, since parted is maintained by RedHat, I would expect that this feature would land in parted soon as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: partman, growlight, discoverable partitions, and fun
Hello Nick! On 9/26/21 00:49, Nick Black wrote: > It supports MBR, GPT, and APM: > > https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123 > > (sorry for the gmail-style top posting; i can't find your mail in my mbox > for whatever reason) > > Any other partition schemes ought be trivial to add; they've not been added > yet > simply because I don't have means with which to test them. So, you are not using libparted then? > Looking at the "partition types" section of the Linux configuration, I see: > Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris > x86, Unixware, > Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68. > > Looking at the disk-label code from partman, I see: > gpt, msdos, amiga, atari, mac, sun > > So the only ones covered by partman and not covered by growlight would be: > amiga, atari, sun, > and mac (if mac is not the same as APM). I don't see any difficulty in > adding these four, so long > as there's someone with an Amiga or ATARI who'd be willing to test them > out. If there are no such > people, is it that important? Yes, it is important as we're supporting these architectures in Debian Ports and I invested quite some time to get Atari partition support added [1], for example. I think it makes little sense to not use libparted as it already supports all common and less common partition types and reimplementing everything that libparted makes little sense to me. Adrian > [1] > https://git.savannah.gnu.org/cgit/parted.git/commit/?id=9c266205416ec956d6205c828211480de3767d02 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: partman, growlight, discoverable partitions, and fun
Hello! On 9/23/21 22:57, nick black wrote: > I am just finishing up the implementation of Discoverable GPT > Partitions [0] in my growlight tool, and it seems a good time to > see if I can push this discussion [1] forward. Does it support partition tables other than GPT, in particular all of the partition tables that parted supports? If not, I don't think it would be a viable replacement for partman. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#994458: ITP: anymarkup -- Parse or serialize any markup format in Python
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz X-Debbugs-Cc: debian-devel@lists.debian.org,marcus.schae...@gmail.com * Package name: anymarkup Version : 0.8.1 Upstream Author : Slavek Kabrda * URL : https://github.com/bkabrda/anymarkup * License : BSD-3-clause Programming Lang: Pyhton Description : Parse or serialize any markup format in Python Parse or serialize any markup. Currently supports INI, JSON, JSON5, TOML, XML and YAML. This package is required as a dependency for the upcoming kiwi package. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#994447: ITP: anymarkup-core -- Core library for the anymarkup Python package
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz X-Debbugs-Cc: debian-devel@lists.debian.org,marcus.schae...@gmail.com * Package name: anymarkup-core Version : 0.8.1 Upstream Author : Slavek Kabrda * URL : https://github.com/bkabrda/anymarkup * License : BSD Programming Lang: Python Description : Core library for the anymarkup Python package This is the core library that implements functionality of the anymarkup package. This package can be installed if one wants to use a subset of the anymarkup parsers. This package is required as a dependency for the upcoming kiwi package. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: dh_install -X not excluding any files
Hi Boian On 9/14/21 18:46, Boian Bonev wrote:> Hi, >> I tried using "dh_install -Xkiwicompat" [2] but that doesn't work no >> matter what >> variation I'm trying, the binary kiwicompat still gets installed into >> /usr/bin. > > You mean installed in debian/tmp during build or in the final package? > I think that adding a debian/not-installed with usr/bin/kiwicompat > would do the trick? Thanks for the hint but unfortunately that doesn't work and according to the manpage of dh_missing it cannot work as this file is not intended for excluding files. [1] I guess, I just have to delete the files manually. Adrian > [1] https://man7.org/linux/man-pages/man1/dh_missing.1.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
dh_install -X not excluding any files
(Please CC in replies me as I'm not subscribed to debian-devel) Hello! I'm currently working on packaging KIWI [1] for Debian where I need to exclude on of the binaries from being installed into /usr/bin. I tried using "dh_install -Xkiwicompat" [2] but that doesn't work no matter what variation I'm trying, the binary kiwicompat still gets installed into /usr/bin. Does anyone have a clue why excluding "kiwicompat" doesn't work? Thanks, Adrian > [1] https://github.com/OSInside/kiwi > [2] https://github.com/glaubitz/kiwi-debian/blob/master/debian/rules#L25 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#994231: ITP: kiwi -- Flexible OS Image and Appliance Builder
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: kiwi Version : 9.23.56 Upstream Author : Marcus Schäfer , and others * URL : https://osinside.github.io/kiwi * License : GPL-3 Programming Lang: Python Description : Flexible OS Image and Appliance Builder The KIWI Image System provides an operating system image builder for Linux supported hardware platforms as well as for virtualization and cloud systems. This package will be co-maintained by Marcus Schäfer. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
New ia64 porterbox available
Hello! There is a new Debian porterbox available for the ia64 architecture [1]. It is called yttrium, has a four-core Intel Itanium Processor 9320 clocked at 1.33 GHz/1.47 GHz and 24 GB of RAM. The machine is hosted in Germany at Will & Co KG. If you run into any issues with the machine, please drop me an email. Thanks, Adrian > [1] https://db.debian.org/machines.cgi?host=yttrium -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fixed release dates are hurting quality
On 3/3/21 9:09 AM, Wouter Verhelst wrote: > I don't agree with the statement that doing things like this is a bad > idea. Sometimes doing the minimal necessary to make a package work again > so that our future needs will still be served by it is a good idea. I > think that this is one of those times, and I guess that it's the same > for most of the packages uploaded like that. Sure, you don't have to agree with my stance on this. I think it's better to not ship something at all than to ship something with a hotpatch that hasn't been touched for a long time. After all, users expect packages that are shipped with a release to meet certain quality standards and I would say that chances are not zero that such a package which hasn't been touched for a longer time will have other problems that may warrant further action of the security team in the future. But ok, maybe my thinking is too much influenced from the SLES release process at SUSE which ships with a rather limited set of packages which are guaranteed to work and are officially supported. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fixed release dates are hurting quality
On 2/7/21 3:20 PM, David Bremner wrote: > John Paul Adrian Glaubitz writes: > >> It shouldn't be enough for a package to have its worst bugs fixed like FTBFS >> or >> crashes when it gets shipped with a release. Packages that are being shipped >> with >> a release should also be properly maintained or not shipped at all. > > For context, there are currently 929 packages maintained by > packa...@qa.debian.org. That doesn't count packages that have an > inactive maintainer, which is more challenging to quantify. Yes, and I think that number 929 is already too high. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Fixed release dates are hurting quality
Hello! I just noticed how maintainers are NMU'ing packages in large quantities to get them somehow in a usable state for the release. The packages get small patches so that they are more or less working and can get into testing, despite the packages being untouched for a long time in some cases meaning there is no guarantee for quality. I personally do not think that this is a good idea as this leads to the release being shipped with lots of packages that have not been properly maintained and the single NMU just paints over that issue. It shouldn't be enough for a package to have its worst bugs fixed like FTBFS or crashes when it gets shipped with a release. Packages that are being shipped with a release should also be properly maintained or not shipped at all. If the packages in question are essential, then these packages should get a proper maintainer with a maintenance release first before the freeze kicks in. I don't think we gain anything by shipping half-finished releases. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: apt ignoring check-valid-until flag
Hi Ansgar! On 12/17/20 11:02 AM, Ansgar wrote: > Maybe the same could be done for archive.d.o? > > I might be interested to experiment with this as it seems reasonably > small project to implement. :-) That would be fantastic and a huge improvement in user experience. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: apt ignoring check-valid-until flag
On 12/17/20 12:36 AM, Paul Wise wrote: > * snapshot could gain a re-signing service (#763419) That would be absolutely awesome. Whom do I throw my money at? FWIW, snapshot.debian.org is a Godsent and extremely helpful when working with different ports. It's one of the best features we have in Debian and something that I'm sometimes missing for other distributions. openSUSE has snapshots for a few days only, for example. Thanks to everyone keeping snapshot.debian.org up and running! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: apt ignoring check-valid-until flag
On 12/16/20 11:53 PM, Paul Wise wrote: > It seems to be saying that the 2019 ports archive signing key used for > signing the snapshot URLs is expired, I don't think check-valid-until > ignores key expiry. Ah, the "check-valid-until" is for the signature of the Release file, but not for the signing key of the archive. That explains it. We should probably extend the instructions on snapshot.debian.org [1] to include that information. Adrian > [1] http://snapshot.debian.org/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
apt ignoring check-valid-until flag
Hi! For some reason, apt is ignoring the "check-valid-until" flag for me, no matter whether I'm passing that option in /etc/apt/sources.list or on the command line (see below). Does anyone have any idea what I'm missing? PS: Please CC me, I'm not subscribed to debian-devel. Thanks, Adrian === (sid-powerpc-sbuild2)root@kapitsa:/# cat /etc/apt/sources.list # binary default deb http://ftp.ports.debian.org/debian-ports/ unstable main deb http://incoming.ports.debian.org/buildd/ unstable main deb http://ftp.ports.debian.org/debian-ports/ unreleased main deb http://ftp.ports.debian.org/debian-ports/ experimental main # deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-ports/20200111T031626Z/ unstable main # deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-ports/20190824T033111Z/ unstable main # deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-ports/20200114T211249Z/ unstable main # deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-ports/20200111T094546Z/ unstable main #deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-ports/20190428T083118Z/ unstable main deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-ports/20190428T083118Z/ unstable main deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-ports/20201014T042941Z/ unstable main ##deb [arch=all] http://snapshot.debian.org/archive/debian/20190731T151946Z/ unstable main # source deb-src http://ftp.debian.org/debian/ unstable main deb-src http://incoming.debian.org/debian-buildd/ buildd-unstable main deb-src http://ftp.debian.org/debian/ experimental main deb-src http://incoming.debian.org/debian-buildd/ buildd-experimental main (sid-powerpc-sbuild2)root@kapitsa:/# apt-get update -o Acquire::Check-Valid-Until=false Hit:1 http://ftp.debian.org/debian unstable InRelease Hit:2 http://ftp.debian.org/debian experimental InRelease Hit:3 http://incoming.debian.org/debian-buildd buildd-unstable InRelease Hit:4 http://incoming.debian.org/debian-buildd buildd-experimental InRelease Hit:5 http://incoming.ports.debian.org/buildd unstable InRelease Hit:6 http://ftp.ports.debian.org/debian-ports unstable InRelease Get:7 http://snapshot.debian.org/archive/debian-ports/20190428T083118Z unstable InRelease [51.1 kB] Hit:8 http://ftp.ports.debian.org/debian-ports unreleased InRelease Hit:9 http://snapshot.debian.org/archive/debian-ports/20201014T042941Z unstable InRelease Hit:10 http://ftp.ports.debian.org/debian-ports experimental InRelease Err:7 http://snapshot.debian.org/archive/debian-ports/20190428T083118Z unstable InRelease The following signatures were invalid: EXPKEYSIG DA1B2CEA81DCBC61 Debian Ports Archive Automatic Signing Key (2019) Reading package lists... Done W: GPG error: http://snapshot.debian.org/archive/debian-ports/20190428T083118Z unstable InRelease: The following signatures were invalid: EXPKEYSIG DA1B2CEA81DCBC61 Debian Ports Archive Automatic Signing Key (2019) E: The repository 'http://snapshot.debian.org/archive/debian-ports/20190428T083118Z unstable InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. (sid-powerpc-sbuild2)root@kapitsa:/# apt-cache policy python3-ipywidgets python3-ipywidgets: Installed: (none) Candidate: 6.0.0-6 Version table: 6.0.0-6 500 500 http://ftp.ports.debian.org/debian-ports unstable/main powerpc Packages 500 http://ftp.ports.debian.org/debian-ports unstable/main all Packages 500 http://snapshot.debian.org/archive/debian-ports/20201014T042941Z unstable/main powerpc Packages 500 http://snapshot.debian.org/archive/debian-ports/20201014T042941Z unstable/main all Packages (sid-powerpc-sbuild2)root@kapitsa:/# -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF
Re: Porter roll call for Debian Bullseye
Hello! On 11/2/20 9:23 PM, Graham Inggs wrote: > We are doing a roll call for porters of all release architectures. If > you are an active porter behind one of the release architectures [1] > for the entire lifetime of Debian Bullseye (est. end of 2024), please > respond with a signed email containing the following before Friday, > November 27: > > * Which architectures are you committing to be an active porter for? > * Please describe recent relevant porter contributions. > * Are you running/using Debian testing or sid on said port(s)? > * Are you testing/patching d-i for the port(s)? > > Please note that no response is required for amd64 because our > toolchain maintainers are happy to support amd64 as-is. Also note > that this waiver no longer applies for i386, where it did in previous > releases. Since there haven't been any replies to this call - at least not on the lists that I am currently on - I would like to make a suggestion to address this porter issue in the long term. In Debian Ports, we have many users that would still like to be able to use stable or testing releases which we can't offer since we don't have a Britney instance ourselves. We are also missing a proper instance of the Debian Archive Kit (DAK) meaning that we don't have the possibility to use cruft, see [1]. If we had both Britney and a proper DAK in Debian Ports, we could make Debian Ports more official by turning Debian's architecture support policy into a tier system similar to many other projects such as NetBSD [2]. The plan would be that ports can be promoted and demoted between tiers at the courtesy of the release team. Current release architectures would be Tier I while ports architectures would be Tier II. Being Tier I means, port must have a dedicated porter team, Tier II means that the Debian Ports team takes care of the maintenance of the port, similar to what the QA team already does for packages. Tier I is guaranteed to be stable with FTBFS bugs and other QA issues being release critical while such bugs on Tier II will only be classified as important or normal. This means that users will still be able to install fresh releases on Tier II targets, we just don't guarantee that it will work. At the same time, the release and security teams don't have to deal with ports where finding porters is more difficult. The only problem that I see with this approach is that DSA will probably not be easily transferring administration rights over Tier I buildds to the Debian Ports team when a port becomes Tier II. Similarly, DSA will probably not agree to take care of Tier II buildds. So the question over server administration could be an actual blocker for such a concept, although it would probably less critical in practice as ports won't be moved between tiers too often. And we would need to get DAK and Brtiney for Debian Ports, first, of course. Any comments? Adrian > [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html > [2] https://www.netbsd.org/ports -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
New powerful m68k Debian porterbox available
Hi! I'm happy to announce that we are finally able to provide a porterbox for the m68k architecture which is available to every Debian Developer and everyone with a Debian guest account with the necessary permissions. The machine is called mitchy [1] (FQDN: mitchy.debian.net) and is named after the dog Mitchy of the creator of the Amiga, Jay Miner [2]. The machine is based on a new QEMU m68k virtual machine type based on Google's Goldfish project [3] and supports up to 3.2 GB of RAM and up to 128 virtual devices. With the host server currently in use, the emulated 68040 is clocked at around 1 GHz which is enough to build and test most packages - although for building larger projects like GCC, it's advisable to use a faster host machine or QEMU user emulation. Hosting is kindly provided by Gandi.net [4] who have been providing cloud resources for Debian Ports to provide build machines for multiple architectures for a while now. The code has been developed by Laurent Vivier and consists of changes to both QEMU [5] and the Linux [6] which have not been upstreamed yet. Laurent will be giving a talk on the current status of this project and m68k emulation in QEMU in general during our next m68k online meeting on November, 6th [7] where everyone is invited to join. Since the Goldfish-based m68k emulation support is rather new, the new porterbox may sometimes becomes unstable although that has improved a lot with the latest kernel patches by Laurent. There are also still some limitations in the FPU emulation support, so if you are seeing unexpected build failures or run into any other problems with the virtual machine, please let me know. I do have real m68k hardware available (which is much slower) to be able to run occasional tests on it. Thanks, Adrian > [1] https://db.debian.org/machines.cgi?host=mitchy > [2] https://arstechnica.com/gadgets/2007/07/a-history-of-the-amiga-part-1/3/ > [3] https://www.phoronix.com/scan.php?page=news_item=MTMwNjM > [4] https://www.gandi.net > [5] https://github.com/vivier/qemu-m68k/tree/m68k-virt > [6] https://github.com/vivier/linux/tree/m68k-virt > [7] http://m68k.info/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Is the debian-mirrors team MIA?
Hi Holger! On 5/29/20 10:37 AM, Holger Levsen wrote: > On Fri, May 29, 2020 at 09:41:33AM +0200, John Paul Adrian Glaubitz wrote: >> On 5/29/20 9:40 AM, John Paul Adrian Glaubitz wrote: >>> (Please keep me CC'd, I'm not on the list) > > I find it somewhat amusing, to ask for courtesty copies and then not > having the courtesty to cc: the people one is complaining about. > > So I've added mirr...@debian.org to cc: so they are notified about > this thread on -devel@ at least. > >>> I have been trying to get a small pull request on the masterlist [1] merged >>> for Debian Ports but I have not heard any feedback for over a month. >> >> Forgot the link, sorry: >> >>> https://salsa.debian.org/mirror-team/masterlist/-/merge_requests/6 > > you also could have pinged the MR once again, before escalating to > debian-devel@ > immediatly. Sometimes stuff fells of the radar. Just saying... I still haven't heard back since your mail. Any suggestions what to do? I find it problematic when one of the core teams of Debian is not responsive for weeks. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Is the debian-mirrors team MIA?
On 5/29/20 10:37 AM, Holger Levsen wrote: > On Fri, May 29, 2020 at 09:41:33AM +0200, John Paul Adrian Glaubitz wrote: >> On 5/29/20 9:40 AM, John Paul Adrian Glaubitz wrote: >>> (Please keep me CC'd, I'm not on the list) > > I find it somewhat amusing, to ask for courtesty copies and then not > having the courtesty to cc: the people one is complaining about. > > So I've added mirr...@debian.org to cc: so they are notified about > this thread on -devel@ at least. I have asked on debian-mirrors@d.o, I wasn't aware of mirr...@debian.org, thanks for the heads-up. >>> I have been trying to get a small pull request on the masterlist [1] merged >>> for Debian Ports but I have not heard any feedback for over a month. >> >> Forgot the link, sorry: >> >>> https://salsa.debian.org/mirror-team/masterlist/-/merge_requests/6 > > you also could have pinged the MR once again, before escalating to > debian-devel@ > immediatly. Sometimes stuff fells of the radar. Just saying... This wasn't about escalating, this was just asking if anyone can provide input. If I don't hear back for about a month on three different communication channels, I'm assuming I might be asking at the wrong location. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Is the debian-mirrors team MIA?
On 5/29/20 9:40 AM, John Paul Adrian Glaubitz wrote: > (Please keep me CC'd, I'm not on the list) > I have been trying to get a small pull request on the masterlist [1] merged > for Debian Ports but I have not heard any feedback for over a month. Forgot the link, sorry: > https://salsa.debian.org/mirror-team/masterlist/-/merge_requests/6 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Is the debian-mirrors team MIA?
(Please keep me CC'd, I'm not on the list) Hi! I have been trying to get a small pull request on the masterlist [1] merged for Debian Ports but I have not heard any feedback for over a month. I also tried pinging on #debian-mirrors on IRC but didn't get any feedback either. Does anyone know whom to reach out to? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#927047 closed by Debian FTP Masters (Bug#959102: Removed package(s) from unstable)
On 4/29/20 10:38 PM, John Paul Adrian Glaubitz wrote: > Aehm, mozjs68 is rust-only, so this is rather unfortunate for Debian > Ports until we got Rust working everywhere (through additional LLVM > backends being worked on and gcc-rs). > > I'm not against Rust per se, I have contributed many patches to it > myself. But can't these changes not be less abrupt so we can deal > with these changes? Funny, mozjs68 actually Build-Depends on cargo and rustc, but doesn't build a single line of Rust code, see [1]. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959144 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#927047 closed by Debian FTP Masters (Bug#959102: Removed package(s) from unstable)
On 4/29/20 10:33 PM, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:mozjs60 package: > > #927047: mozjs60: Please ignore non262/extensions/clone-errors.js on ppc64 > and sparc64 > > It has been closed by Debian FTP Masters . Aehm, mozjs68 is rust-only, so this is rather unfortunate for Debian Ports until we got Rust working everywhere (through additional LLVM backends being worked on and gcc-rs). I'm not against Rust per se, I have contributed many patches to it myself. But can't these changes not be less abrupt so we can deal with these changes? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/16/20 12:31 PM, Thomas Pircher wrote: > John Paul Adrian Glaubitz wrote: >> I would like to suggest to replace vim-tiny with nano as the default minimal >> editor installed with debootstrap and therefore debian-installer. > > Would you consider nvi as an alternative to vim-tiny? It is quite small > and is functional enough to edit the occasional config file when > necessary. FWIW, there is also vile [1] which is a small vim clone which is also currently maintained, both in Debian and upstream. Adrian > [1] https://packages.qa.debian.org/v/vile.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/22/20 3:48 PM, Julien Cristau wrote: > On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote: >> Debian Ports is affected by this problem in particular because we don't have >> the cruft feature in mini-DAK [3], so every time I build a debian-installer >> image and forget checking whether vim build successfully on every >> architecture, >> the particular debian-installer image becomes unusable because debootstrap >> cannot install vim-tiny as its version mismatches the version of vim-common. >> > The debian-ports archive maintainers could decide to change vim-tiny's > priority on their side, without imposing that decision on the debian > archive. And the opinion of the vim maintainer that he would like to get rid of the vim-tiny package is not relevant? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/17/20 8:34 PM, Gunnar Wolf wrote: > Ansgar dijo [Tue, Mar 17, 2020 at 09:49:49AM +0100]: >> And Debian ships vim-tiny, not vim, as part of the minimal >> installation. That the same source package also builds other versions >> doesn't really matter for vim-tiny. >> >> The only problem you mentioned was vim-tiny (arch: any) depending on >> vim-common (arch: all) and these sometimes getting out of sync on Debian >> Ports. I don't think that is a good reason to switch editors and there >> are other ways to work around that problem. > > Agree. The vim maintainer himself would like to get rid of the vim-tiny package and I'm not sure there is a compelling argument that you have to use a particular vi implementation in a minimal environment. I wouldn't have a problem with vim if the package didn't fail its testsuite that often. While the last upload has helped a little, it's still FTBFS on five architectures [1], three of them in Debian Ports meaning I won't be able to build usable d-i images and several users have asked me for updated images already. >> But if we really wanted a minimal editor: `ed` is still there with an >> Installed-Size: 116 kB and no external dependencies besides libc6. It >> also works without fancy terminal features. > > Well, yes. But while mostly everybody who reads this will be > moderately proficient with the basic subset of vi, I don't know > anybody who'd know how to drive ed (I have done it, but I surely don't > remember how to). It's not about the size of the editor package but more about using an editor which causes less build issues. >> Or have debootstrap not install any editor. But if I remember correctly >> that idea wasn't popular. > > I agree with those that would oppose. Having an editor handy is core > to be able to get a Unix system out of many unexpected > situations. Having an Unix system without an editor is IMO having a > broken system. Could make sense for embedded targets... but nothing else. I'm not arguing that, I just want to solve this particular problem. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
(I'm not subscribed to debian-devel, please keep me CC'ed) > It seems to me that this is a large part of the problem here. DAK > presumably has that feature for good reasons, and if the Ports archive is > missing features that DAK has, the Ports is going to hit bad situations > that the maintainers of "Debian proper" don't necessarily consider to be > a big deal because the DAK-driven Debian archive copes better with them. It still remains a problem because we don't release Debian with packages that fail to build from source. If you are just ignoring the problem here, you will postpone its solution into the future, nothing else. Eventually, someone has to fix vim. > If anything, I would expect the Ports archive to need to be *more* > featureful than the archive for release architectures, because on release > architectures it's a RC bug if an architecture is long-term out-of-sync > with the other release architectures, whereas on Ports there are sometimes > architecture-specific modifications to packages (if I understand correctly), > and there are definitely architectures that don't/can't keep up, either > because their buildds are slower or because a build-dependency FTBFS on > that architecture. vim *is* out of sync. It's not a problem that affects Debian Ports only, it's not a ports-specific bug. It just shows more prominently in Debian Ports. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/17/20 9:49 AM, Ansgar wrote: > John Paul Adrian Glaubitz writes: >> And I assume, once we have fixed vim everywhere, it will be broken again >> at some point due to the fact vim upstream is continuously adding features >> which is why it's no longer suitable being an editor to be shipped in a >> minimal installation. > > And Debian ships vim-tiny, not vim, as part of the minimal > installation. That the same source package also builds other versions > doesn't really matter for vim-tiny. > > The only problem you mentioned was vim-tiny (arch: any) depending on > vim-common (arch: all) and these sometimes getting out of sync on Debian > Ports. I don't think that is a good reason to switch editors and there > are other ways to work around that problem. So, are you going to fix the testsuite failures then? I don't think it's fair to downplay problems and then not be willing to provide any possible solutions to it. And the issue with vim-common being out of sync is not trivially fixable with Debian Ports as we don't have the cruft feature that DAK has. Unless someone actually goes ahead and fixes the problem, it will continue to exist which is why I made this suggestion. And with even the maintainer of the vim package saying that he would like to get rid of vim-tiny, I don't think you have a strong argument in this discussion. After all, anyone wanting to use a particular editor can just install it, for anyone else, a basic version of vi and nano are enough when boooting a rescue system. You are not going to work on software projects with a minimal system or a rescue environment, are you? Most likely, you are using the editors in d-i to fix an entry in /etc/fstab or the GRUB configuration. > But if we really wanted a minimal editor: `ed` is still there with an > Installed-Size: 116 kB and no external dependencies besides libc6. It > also works without fancy terminal features. It isn't about the size of the package. It's about src:vim constantly failing to build from source and no one stepping up to fix these problems. And I don't really see a point in using a fully fledged version of vim in a minimal environment when simple alternatives exist. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/17/20 3:21 AM, James McCoy wrote: > On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote: >> The rationale behind that suggestion is that the vim package is becoming more >> and more complex and hence more prone to build failures as can be seen from >> the current build logs [1] > > I'd love any help fixing the test failures. I generally help with fixing packages on any architecture whereever I can but vim has become rather complex and some of the testsuite failures are a result of vim using Ruby which requires fixing the Ruby interpreter packages. And I assume, once we have fixed vim everywhere, it will be broken again at some point due to the fact vim upstream is continuously adding features which is why it's no longer suitable being an editor to be shipped in a minimal installation. > As far as priorities, whatever the project/ftp-masters decide is fine > with me. I've wanted to drop vim-tiny altogther, but that's been met > with resistance. Sounds like dropping vim-tiny and replacing it with vi from busybox would be a good approach to fix this particular issues, doesn't it? FWIW, I'm still happy to help fixing issues in vim, it's just not very high on my priority list at the moment. PS: Thanks to everyone for the very constructive discussion! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
Hi Thomas!
On 3/16/20 12:31 PM, Thomas Pircher wrote:
> John Paul Adrian Glaubitz wrote:
>> I would like to suggest to replace vim-tiny with nano as the default minimal
>> editor installed with debootstrap and therefore debian-installer.
>
> Would you consider nvi as an alternative to vim-tiny? It is quite small
> and is functional enough to edit the occasional config file when
> necessary.
Since nvi [1] does not suffer from the same regular build problems as vim,
I'm perfectly fine with nvi over nano if this should be up for decision.
My only goal is to avoid the d-i build problems in the future that the
regular build failures of the vim package cause.
> A user who does a lot of editing will probably install a better editor
> than {vim-tiny,nvi} anyways. And it would minimise disruption to people
> who expect some form of vi to be installed on the system.
Sure. I just wasn't thinking of nvi when I wrote my mail :).
Adrian
> [1] https://buildd.debian.org/status/package.php?p=nvi=sid
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
RFC: Replacing vim-tiny with nano in essential packages
Hello! I would like to suggest to replace vim-tiny with nano as the default minimal editor installed with debootstrap and therefore debian-installer. The rationale behind that suggestion is that the vim package is becoming more and more complex and hence more prone to build failures as can be seen from the current build logs [1] as compared to nano [2]. Debian Ports is affected by this problem in particular because we don't have the cruft feature in mini-DAK [3], so every time I build a debian-installer image and forget checking whether vim build successfully on every architecture, the particular debian-installer image becomes unusable because debootstrap cannot install vim-tiny as its version mismatches the version of vim-common. Thus, my suggestion would be to replace vim-tiny with nano in the list of essential packages unless there is any feature in vim-tiny that makes its availability in a minimal debootstrap essential. Thanks, Adrian PS: Please keep me CC'ed, I'm not subscribed to debian-devel. > [1] https://buildd.debian.org/status/package.php?p=vim=unstable > [2] https://buildd.debian.org/status/package.php?p=nano=unstable > [3] https://lists.debian.org/debian-sparc/2017/12/msg00060.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
New fast porterbox for powerpc and ppc64 available
Hi! Thanks to a very generous donation by IBM we have now a new porterbox for powerpc and ppc64 (big-endian) available [1]. The machine the porterbox VM is hosted on is pretty fast an also hosts an additional buildd for both powerpc and ppc64. If there are any issues with the machine, please get in contact with me or James. Adrian > [1] https://db.debian.org/machines.cgi?host=perotto -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Accepted ausweisapp2 1.20.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 18 Jan 2020 15:59:04 +0100 Source: ausweisapp2 Architecture: source Version: 1.20.0-1 Distribution: unstable Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Changes: ausweisapp2 (1.20.0-1) unstable; urgency=medium . * New upstream release * Add patch to disable vendor name * Add patch to fix desktop icon path * Drop 0001-Disable-auto-updater.patch, fixed upstream * Drop 0002-Disable-Qt-Quick.patch, fixed upstream * Drop 0003-Fix-path-for-application-icon.patch, fixed upstream * Drop 0004-Fix-path-for-configuration-file.patch, fixed upstream * Drop 0005-Fix-path-for-resource-file.patch, fixed upstream * Drop 0006-Fix-path-for-translation-files.patch, fixed upstream * Update debian/patches/series * Add libhttp-parser-dev to Build-Depends * Add qtdeclarative5-dev to Build-Depends * Add qtquickcontrols2-5-dev to Build-Depends * Add qml-module-qt-labs-platform to Depends for ausweisapp2 package * Improve wording and grammar in summary and description * Remove manual installation of shared data in debian/rules * Update installation path of desktop icon in debian/rules Checksums-Sha1: ef69e678a74d3bc9a50a5bda281ee7d00071d477 2075 ausweisapp2_1.20.0-1.dsc 00def3bf1118a7ca6c4f7bed4483ac54c5f3ebc6 9727699 ausweisapp2_1.20.0.orig.tar.gz 6797706a869d6200f9de023f1a00f1e5e5ce9292 7660 ausweisapp2_1.20.0-1.debian.tar.xz cbccba41ddf82f73a9b5cb5ecafc154aebef683c 11813 ausweisapp2_1.20.0-1_amd64.buildinfo Checksums-Sha256: 69a446eead9b78efaa54575f8018e5802b30375e90fd1cc96e9f70990eae64ac 2075 ausweisapp2_1.20.0-1.dsc 4501465e7d597aa0ee41afbff8944cf837ea4bc015411b29bce0cd5d437cdb22 9727699 ausweisapp2_1.20.0.orig.tar.gz f4aaa3e476087e589ea82a1057f6caa914ccb6dcf6cd8df206c61f1d29313e37 7660 ausweisapp2_1.20.0-1.debian.tar.xz 28361c20d742feea9ba330d4240730583ae1bb7644c856f3189c6cdff4a3318d 11813 ausweisapp2_1.20.0-1_amd64.buildinfo Files: 03222b9eca95767b15955fb901fa6357 2075 utils optional ausweisapp2_1.20.0-1.dsc 0a0dc612f0be9b1e3900648cf0f08c69 9727699 utils optional ausweisapp2_1.20.0.orig.tar.gz e648e3720c4508efbc71eb330e1cf45c 7660 utils optional ausweisapp2_1.20.0-1.debian.tar.xz 7b9eabcf5c1d51f381b89dae4ebe9450 11813 utils optional ausweisapp2_1.20.0-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAl4jJO0ACgkQdCY7N/W1 +ROTixAAtZK9rGztVqscU9YAzcQsdTFK+d+ZETa/sU6zGh+seNWZL2U28+XzN8Qu bUxkT6ZRdY8aOzEAKHCsHHzIrUokbn4HqMlug6pV+nQCnD9RlWWWHtIuyAccS6iI CNmZj1cgzWnw8hAl1fpF3fh9Y9lLs/p2CEE4EtvEIRlnDJTeLxxUTXRovgRHTEoO s056Ov/HG6Z1xeXHq2/CQjRy4am8pyv4SN4H2t10zVpZOUmdgU5DszE+4O1Y/DPy xG1T8GKvu73ouNJqZjedQYBDCDykdxWqKtI+IC8r+HWr9/GrZBEWEIrCHvdOj2Q4 zjExRPfl/QvFhOf0d6ZOP1a+44vkvPtwPsvh+Jt93s1RS/EX9I0DarZiZb18Mdqr y6+gI07jHYzhdr0HY7cW7qHT5jdZKMPUgeByvAEQeOdo2hiLy8k95H5I0nr5XRBu 3692ldSMK9k376KwgXzB8fNp9Sz4r2w9u8lcQDwqtVj7fhazyrjQ/E+ZMMqU1Pir QkT5O2oWlFl2UfofURBHYz1k4ijAMLDio/oq+yFhQkpHAm+Zwie0K+riTO2PW32e oWfajdFmT4/GiBfZaNTbl4t/m4uXJC6seEGxv2O1CFTJUF032KDoHNdxfLdzOc9H FZGqDOFPmam9erPXgc92rI/SIxqYdUYioud3nTaBye4yNFc5YFk= =9ozX -END PGP SIGNATURE-
Working around the firefox nodejs dependency on riscv64 et al
Hi! I was browsing the debian-devel mailing list archives some weeks ago and ran into this thread [1] where the removal of the firefox-esr package on armel was discussed because newer Firefox versions have a build-dependency on nodejs which isn't available on armel. This could actually be fixed by patching the Debian source package such that the Javascript code is compiled in the binary-indep target of debian/rules so that the compiled Javascript files are put into the arch:all package and the Firefox packages firefox and firefox-esr can be built on armel, powerpc and sparc64 again. I know from a contact at Oracle that they are doing this to be able to build Firefox on Solaris/SPARC, they just keep the Javascript files in the repository out of which they are building the Firefox package for SPARC [2]. If we manage to split out the Javascript files into an arch:all package, we would be able to build Firefox on armel, powerpc, riscv64 and sparc64 as all these targets have full Rust support but don't support NodeJS. In the future, this will affect MIPS as well [3]. I think even ppc64 support is going to be removed from NodeJS in the near future. I have already opened a bug report for that against src:firefox [4]. Would anyone be interested to work with me on this issue? PS: Please keep me CC'ed, I'm not on the list. Thanks, Adrian > [1] https://lists.debian.org/debian-devel/2019/10/msg00391.html > [2] > https://github.com/oracle/solaris-userland/commit/05a1b957d036297a70a1f42a453f94f8cb789324 > [3] https://github.com/nodejs/node/issues/26179 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920902 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Resent, wrong email]: Working around the firefox nodejs dependency on riscv64 et al
(Apologies, for some reason Thunderbird used my GMail account for sending the mail. Please ignore the first message and respond here). Hi! I was browsing the debian-devel mailing list archives some weeks ago and ran into this thread [1] where the removal of the firefox-esr package on armel was discussed because newer Firefox versions have a build-dependency on nodejs which isn't available on armel. This could actually be fixed by patching the Debian source package such that the Javascript code is compiled in the binary-indep target of debian/rules so that the compiled Javascript files are put into the arch:all package and the Firefox packages firefox and firefox-esr can be built on armel, powerpc and sparc64 again. I know from a contact at Oracle that they are doing this to be able to build Firefox on Solaris/SPARC, they just keep the Javascript files in the repository out of which they are building the Firefox package for SPARC [2]. If we manage to split out the Javascript files into an arch:all package, we would be able to build Firefox on armel, powerpc, riscv64 and sparc64 as all these targets have full Rust support but don't support NodeJS. In the future, this will affect MIPS as well [3]. I think even ppc64 support is going to be removed from NodeJS in the near future. I have already opened a bug report for that against src:firefox [4]. Would anyone be interested to work with me on this issue? PS: Please keep me CC'ed, I'm not on the list. Thanks, Adrian > [1] https://lists.debian.org/debian-devel/2019/10/msg00391.html > [2] > https://github.com/oracle/solaris-userland/commit/05a1b957d036297a70a1f42a453f94f8cb789324 > [3] https://github.com/nodejs/node/issues/26179 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920902 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Issues with piuparts blocking testing migration
Hi Utkarsh! On 1/5/20 11:52 AM, Utkarsh Gupta wrote: > On 05/01/20 3:57 pm, John Paul Adrian Glaubitz wrote: >> PS: Please keep me CC'ed, I'm not subscribed to debian-devel. > > If you were, you'd have known this was already discussed :) > Here's that thread[1] and here's the answer[2] you're looking for. Haha, good point ;). Thanks for the pointer. I sometimes check debian-devel messages in the archive but I haven't subscribed due to the large volume of messages and the fact that I'm already on too many other lists. Thanks, Adrian > [1]: https://lists.debian.org/debian-devel/2020/01/msg00028.html > [2]: https://lists.debian.org/debian-devel/2020/01/msg00030.html > -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Issues with piuparts blocking testing migration
Hi! I recently uploaded a new upstream version of fs-uae which is blocked from testing migration due to failing piuparts tests [1]. I have looked at the log file of the failing test but it's not clear to me what the actual problem is. The package also doesn't do any fancy stuff in its debian directory so I'm not sure where the problems come from [2]. Could someone give a pointer who is more experienced with piuparts? PS: Please keep me CC'ed, I'm not subscribed to debian-devel. Thanks, Adrian > [1] https://piuparts.debian.org/sid/source/f/fs-uae.html > [2] https://github.com/glaubitz/fs-uae-debian/blob/master/debian/rules -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Accepted ausweisapp2 1.18.2-1 (source amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 28 Dec 2019 15:56:32 +0100 Source: ausweisapp2 Binary: ausweisapp2 ausweisapp2-dbgsym Architecture: source amd64 Version: 1.18.2-1 Distribution: unstable Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: ausweisapp2 - Official authentication app for German ID cards and residence tit Closes: 881424 Changes: ausweisapp2 (1.18.2-1) unstable; urgency=medium . * Initial release. (Closes: #881424) Checksums-Sha1: 6fb315257fedf78e2cea9b52e5cdc5dc56dbbafa 2014 ausweisapp2_1.18.2-1.dsc 1adc39a2212f469dab97fd93ea52e3fc2474f86a 12059412 ausweisapp2_1.18.2.orig.tar.gz 3b89a7e96840238c51614ebe7479e3919a901115 8664 ausweisapp2_1.18.2-1.debian.tar.xz 3c57919fee5421f1290a721fe9c0aaaf664d856a 27149648 ausweisapp2-dbgsym_1.18.2-1_amd64.deb 3864d4c221747897404a5d81c1f48c83f929aad9 11215 ausweisapp2_1.18.2-1_amd64.buildinfo 2c7c03005a44ef34c8ca7c67ec1ea808b5fa0ede 6946996 ausweisapp2_1.18.2-1_amd64.deb Checksums-Sha256: 5cbc8328500afac3939ca17c20704d14238fc2a5e4d8b468564163028d9dd78c 2014 ausweisapp2_1.18.2-1.dsc aa253758af41846de3c6ab2aefef3a70f7d8987bb70eba7acede42803ff02f90 12059412 ausweisapp2_1.18.2.orig.tar.gz 6c2095aca20872902ecef00c3efc024c5a2fd481009619a053a7b30bcb107a5e 8664 ausweisapp2_1.18.2-1.debian.tar.xz c51c5852f2638506643fc64b970b0dbfc681a83ca1a65431607a989682a42b11 27149648 ausweisapp2-dbgsym_1.18.2-1_amd64.deb b50a68859d14d102d3e1a277bbb81f7fbcde81d696c8f168ddfe531884977011 11215 ausweisapp2_1.18.2-1_amd64.buildinfo 6038e36d302fad377ed360129dae9279215ba1c65441edf10471c5f255b6ea5e 6946996 ausweisapp2_1.18.2-1_amd64.deb Files: e4b83dd7b40946b62837a8171c698c51 2014 utils optional ausweisapp2_1.18.2-1.dsc 20d5a06c5c026a720d675ac62ee6f714 12059412 utils optional ausweisapp2_1.18.2.orig.tar.gz 4f7dc2a3bfd3db9902cdc547fbfbe028 8664 utils optional ausweisapp2_1.18.2-1.debian.tar.xz 6110c073d91ea6477dab2ad2716fb170 27149648 debug optional ausweisapp2-dbgsym_1.18.2-1_amd64.deb 1cbcdc1d42890b0ad39bc90b95622bae 11215 utils optional ausweisapp2_1.18.2-1_amd64.buildinfo 4e1bcf6b184b8ce637ded24248996430 6946996 utils optional ausweisapp2_1.18.2-1_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAl4LLpAACgkQdCY7N/W1 +ROu/w/8DPhT2HnChzFSUkFZSjavwq7gfdVS52upfvn84nStN2ZE49skpGhqfzb5 uOTz72kE1hcny1m6JpZqdGNJDlyutFFB8a1Ezd9qm2M1z+YD0g/227VcAZtx//lv vn23p/8ml8eCaz8ybyXzi0KiP+vYHr3tpzZd83RveSGEtbJKMYJZxBiyWj2pWFHq uhhpElqj16FfwJT33XGBfB4Dr8ORU26bXBYFBQqRIL0MozRt54uOWGI5cblM+DH7 GGbCJUm0tgFvbtyKKu33UNHgB6ecRwko0qitfMyPPJQ4ZkDlOHnxZlAgQvjZnlPE 96tTYIsvmfNr56rhj3hN4xImRQfkonVhjjltMF8UzRGA9avznjzEX9sGTi/fnKex GkcBL6Qpc7Qznq/X8yOXfDOsPfE9LFds7vuLoxrMjH/AYH0jgzAwy323acgXHmTW 0taAafR7XG4XYOkQjgtoy5Mi6bfJJdWxaE0uE03C+O2GiLCfsgS5PvKo1XTEuZr2 b/oftBJ8RO/bSqbKGfg9D4m8HVDH74S97wtEao6v4WOik6mURDm844FU5S7nP1Xr Ou9t4L8S2huRdcup85GU4pmBL6DhutBmWplEZRYIVkGQNNliXUi50jTbkSzYxmtN V/dwfqD1S6e1A7GfFcnFDOXMwg+LAYPH9kGbCFmlBaC8l8mAF5Y= =ig17 -END PGP SIGNATURE-
Accepted fs-uae 3.0.2+dfsg-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 27 Dec 2019 13:47:35 +0100 Source: fs-uae Architecture: source Version: 3.0.2+dfsg-1 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Closes: 886933 936566 944373 Changes: fs-uae (3.0.2+dfsg-1) unstable; urgency=medium . * New upstream release. (Closes: #886933, #944373) * Drop fs-uae-netplay-server package which is python2-only. (Closes: #936566) + Add note about removal in debian/README.source. + Delete debian/fs-uae-netplay-server.* files. + Drop python and python-setuptools from Build-Depends in debian/control. + Remove package description from debian/README.Debian. + Remove package build invocation from debian/rules. + Remove file pattern matching from debian/copyright. + Remove section from debian/control. * Drop debian/patches directory to start with a fresh patch-queue. * Re-add patch to define unknown CPUs as CPU_unknown: + debian/patches/0001-Define-unknown-host-CPUs-as-CPU_unknown.patch. Checksums-Sha1: b0555e75636c32ed60f6155d3addc1786af99582 2167 fs-uae_3.0.2+dfsg-1.dsc ddd34b2311a084c6ba7f36febebe096a6a2966d1 23683232 fs-uae_3.0.2+dfsg.orig.tar.gz 777520d2f91643e6d82c4317c0f0d6bcef7096a3 21532 fs-uae_3.0.2+dfsg-1.debian.tar.xz 113ec1ba2b5f435bee0e03ae21e7b5d97d53595c 11309 fs-uae_3.0.2+dfsg-1_amd64.buildinfo Checksums-Sha256: 8b0c202e2e407395fa87dc8655a9710d5f5d9e6a2c221ec127d67bd300a3d231 2167 fs-uae_3.0.2+dfsg-1.dsc 6ec9e26d42fc2aaa0d8ae0dfa99e1df1fbffa2fc8e7f6817f8755a27359e0b1e 23683232 fs-uae_3.0.2+dfsg.orig.tar.gz 68840b8401013c1e879aa893912e470cbfac6fb02c546534258b3404663fa7bb 21532 fs-uae_3.0.2+dfsg-1.debian.tar.xz 01a6a147797c6ee20b003cf6bb5ce559a3b60ae735f7e9b7b18d670a392d473f 11309 fs-uae_3.0.2+dfsg-1_amd64.buildinfo Files: e45a3ed5b02a75919a13b490d77a0e8f 2167 otherosfs optional fs-uae_3.0.2+dfsg-1.dsc 191dbbcf65168f8bdf08d0d93e628865 23683232 otherosfs optional fs-uae_3.0.2+dfsg.orig.tar.gz fbb8812a72cdf1797f7a56ae1d462190 21532 otherosfs optional fs-uae_3.0.2+dfsg-1.debian.tar.xz da334453422083c24587ad972105 11309 otherosfs optional fs-uae_3.0.2+dfsg-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAl4GBiUACgkQdCY7N/W1 +RNKmQ//WSbrumQ4tREedTvKBARRe4sFvxPg5ntO8WUXYTEGwRe6eNR2ngmARnau NOg0x1H3bPs4vzysmerBvtSjRJfKFfUlQ7/jqEKp6hGhkndR1UsK3dxRzBtB172C 6MqQ+g4GNx6ymNrWvbnrHJTn9OPFKqyXxLVgMXgo2L09RaH0ifvv1XZKzapSj+ei ADJYzwNrbeBOBDheYkBCOlSlbY9yE6DrNu9mh9MovosktJg3CTvjvnLOsjq9VTJ1 ED7HDniN+zATFdf4aGRt39FV2moxJZ309l3IXze54zZIUIchcEL7m39s4W0k0ms/ ID25YYypEIFVPz/6aLFMjsLmiDl6hR01Rhhy2C5F4NBqbRcgIu0IgWDZxWFq+N8L VTzUh6YrM/AW9rMJxSqEzyxjkMpCqhI8H8P8fP9/GKYl1fr0tLsh9q5tgB7eXqTB yjsaFqxjKB8ilkFxoa6q0qC5LNskn9wqyR2fppSe+AbREeCtwpAOc1Gj6wrRsjd2 j+9jmocw3sYUFcNN2Jkz8hnuVFF+67lbTqYzgf6dF2120642xDzQJJcxqvDvvalo +8JgOeNPRgEVQIdz4kXtNYQU88YHPRzEJzj2MAqe/KcWnxsHN0Wa5DKy2c4hXMoR aKzuYtEZdEFBhp8kp90XD4GjoabevzL1tJ9wT8IcIyyNejBRSwk= =LukT -END PGP SIGNATURE-
Accepted radeontop 1.2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 07 Sep 2019 15:21:38 +0200 Source: radeontop Architecture: source Version: 1.2-1 Distribution: unstable Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Changes: radeontop (1.2-1) unstable; urgency=medium . * New upstream release. - update PCI IDs from latest kernel, Navi10 support - update PCI IDs, adding VEGAM, VEGA12 and VEGA20 - fix bus being wrong when auto-detecting GPU - add an soname to libradeontop_xcb.so - tune the UI so it fits to normal terminals still - bump the required libdrm version to 2.4.77 - add support for memory and shader clock reporting - update man page - add --dump-interval command-line option - fix bus parameter to be hexadecimal - add bus information to dump and UI - don't sleep when dumping the last line * Update standards version to 4.4.0, no changes required. Checksums-Sha1: e8a66e2cb7abc745aeeef09da36404858338b523 1924 radeontop_1.2-1.dsc 6ebcc3d8d9af04b3c6de9bcb9a8e5d46dfdfae52 35319 radeontop_1.2.orig.tar.gz 6712a93af0353132ba83e52a7305a9eeea6276c2 3196 radeontop_1.2-1.debian.tar.xz c045f94a2e637a9bc0bfd83c986289770d359f23 6420 radeontop_1.2-1_amd64.buildinfo Checksums-Sha256: e7ab8845cb5f6c4dbd1d4e7528866b9f20948ba3682dd954f3de3d7b9e2225fd 1924 radeontop_1.2-1.dsc dced8f8e64e6bfac1f4054b5cdd986e984b80766547ba272870bc25291c68349 35319 radeontop_1.2.orig.tar.gz e41c823cd7663631ac8b8f37969a60bdc764143d29a94d0294b86980e951cb48 3196 radeontop_1.2-1.debian.tar.xz e4c0784051341a8417a54ed8155092e190ac42d43c339c5436f4c4308e6f5124 6420 radeontop_1.2-1_amd64.buildinfo Files: 5f98e1cf7f150f3a919f613197f8a143 1924 utils extra radeontop_1.2-1.dsc 4422707f607e525500d960a34dd5dfae 35319 utils extra radeontop_1.2.orig.tar.gz 4f138d636cc7cafb757c93cbc7520f81 3196 utils extra radeontop_1.2-1.debian.tar.xz d4634c15ba8b9013653c1f50b094947e 6420 utils extra radeontop_1.2-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAl1zs2IACgkQdCY7N/W1 +ROFgA//c305agJGBJTYjS7QLm7UqpAnwno+H8C0FqvfW/GYD/Y4HdeMro7OJ1Lk FZAXZxCNqxtC4YwNbAnWZBHgKc1Kii4oZiPg1zsPbGPtpdckfy8Qb8l2hoPj/+cI YCj/F73NaWyg8nkINsZ+dDZOoZL3+anwR2YzmD3/wOKXIQx8f3xHrlg55gsw37fX g+rASwEbCWp2m/NixcrITyESsoOwtYWI0M1R03MNOPfdIbl6jMstuGHJqTMPnVrA UfJyzwHid8UGHGq01z+C6G0ckaQzlpeW3FelOHR8WHP8jmacd2v4xW8at5sutvzP TylUbDEYGbaVJHF+PX8TJlEs3F+Onjj4PbNL4/8n4rKgeECykdjxoj/3Mwy1wgJh 98x9vJ+D0dBQgApfl75IQrwGvyT6gvecefc0t4+DtBEJkCp52CfgmSYTVJrX/X6C GaoiHetQIUi/EBAsQYjfUSPLrtlMxJ5Xjw8XeCU0WdM/1vxUQLnIwtE/GWV5DmJC fv6+F46BNXaujtlBDgMh2R+3RegOppOETg0JiUi/9iLndBDJesVH9QnJkQWbK70/ uJ2ehIeESwodi7KYhOzUCJUCqt2vkP9XNtUUQziFm3Ds6GaE0VICIKMeb0EUjq44 HrM2gzG3n4P5+mOUH8Sk8JfHgAas3MYac7fiq21rvHOnp6KNqJ8= =vdrW -END PGP SIGNATURE-
Accepted gkrellm2-cpufreq 0.6.4-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 04 Sep 2019 11:56:46 +0200 Source: gkrellm2-cpufreq Architecture: source Version: 0.6.4-6 Distribution: unstable Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Closes: 939308 Changes: gkrellm2-cpufreq (0.6.4-6) unstable; urgency=medium . * Remove stray characters in Section field in debian/control. (Closes: #939308) * Change Priority from extra to optional in debian/control. Checksums-Sha1: acc5916c77ab16c9354cb17f4ef10e2786cb6971 1968 gkrellm2-cpufreq_0.6.4-6.dsc 5310d53dbca3172e78e59affaf0467cde85cedb4 3208 gkrellm2-cpufreq_0.6.4-6.debian.tar.xz e39cabafbfe524b7a2240811cc4f4b8a820d8436 11133 gkrellm2-cpufreq_0.6.4-6_amd64.buildinfo Checksums-Sha256: 0aae0ccf77e3fac749b9d4020de072fbab748825d152e6748f94b3922c36e0d3 1968 gkrellm2-cpufreq_0.6.4-6.dsc 339bb0824f3a5e4011c2eb3aaafb76da39c2d4a9c2f3328c4eba8dca488a6cd2 3208 gkrellm2-cpufreq_0.6.4-6.debian.tar.xz d32daeac80fdf1107a9d94754efe0323d6b22bb4665d1f242217ff4382164c41 11133 gkrellm2-cpufreq_0.6.4-6_amd64.buildinfo Files: 60bb8a214482977a786790a663782673 1968 x11 optional gkrellm2-cpufreq_0.6.4-6.dsc 76d922a1ff1326916c52df09b37f8e77 3208 x11 optional gkrellm2-cpufreq_0.6.4-6.debian.tar.xz e3affcf78342aa05d3c43c5801575d26 11133 x11 optional gkrellm2-cpufreq_0.6.4-6_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAl1vigEACgkQdCY7N/W1 +ROOMhAAlP7SGuED3HK29zs8iU/odLL7Rsq4CE5ZXqoQzQNYiubGcvCuOAS67dhX RqFjEsUT14tCp009ejEha8bW+UJDg0kFOU7pgTYzegck5C/X3CWJxc6DhGzDIWmw Gt4+lzp8wKr2TSZ587SLyCuqae2Vh1rBxI+qZAJ5dxssAXa6IAQWeF7n1t9eteSi /bkdfEuTpUnXtknkOKmEFwwi1acGfHxCUYHztdQZaJh3fwjMKHlXhipgQrEc44E6 4MvUTzlTjsTtwEaORdn+mfVy18A1QwpVYWJcCf3ViOMPleyuDz7mRMVAe9NYtX0g NyEFRPHKg1X2VPmfSn3rBXtC+reERvJ7j2aaDSSE+by3pyzqH5D2WCGksUHvzVhd pchdrDk9oCLq3Gv3Sfj5feg9/T7iEOBHI38P9e/0G8zuJDYvd5/R7IqCdeuRHlfb maTWjYvY3T5RJoQ4q25UHzHUJQV0LEt80s5+66lwY/Gum81tGcbOr19LDCpGfuom s5p3Iedte17GJnG2xgjad7zfPgl+YpxAb2OBBX9DVobgtjH/NBtG3Y/H21caL809 mmdZbeFksirTt2Q6YCHCF4sM7qvXA3otn/HQcwzVdYyNbZDD8w1fd6t18L/FlLCg O4D4ljiEOgWZEKmuBaIrJo9zLbRzJTiv3XmH3ATvUMZmOzvgKHU= =LUvX -END PGP SIGNATURE-
Accepted gkrellm2-cpufreq 0.6.4-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 02 Sep 2019 21:43:55 +0200 Source: gkrellm2-cpufreq Architecture: source Version: 0.6.4-5 Distribution: unstable Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Closes: 895297 936063 Changes: gkrellm2-cpufreq (0.6.4-5) unstable; urgency=medium . * Fix text formatting of debian/patches/0001-Modify-Makefile- to-make-sure-linker-flags-are-proper.patch. * Add patch to modify Makefile to enable cross-builds. (Closes: #895297) * Add patch to modify Makefile to link against libcpupower. (Closes: #936063) * Replace libcpufreq-dev dependency with libcpupower-dev in debian/control. * Remove unneccessary commit hashes from debian/changelog. * Use my full name in debian/changelog. * Bump debhelper version to 12. * Verify and bump standards to 4.4.0 in debian/control. Checksums-Sha1: 81a12bf7c6a01e5e985945eec56c9e8d0f845f2d 1969 gkrellm2-cpufreq_0.6.4-5.dsc 8bec0fe545ec5b3b165f23f1c6eaa2a6e74aebdd 3148 gkrellm2-cpufreq_0.6.4-5.debian.tar.xz d5b97dbf0073fc89672bb5b111f508e0cba11c23 11133 gkrellm2-cpufreq_0.6.4-5_amd64.buildinfo Checksums-Sha256: a706ffd911aa09ef32cf28d5b42db1cce85e71c4df054cad6862da7560f602a6 1969 gkrellm2-cpufreq_0.6.4-5.dsc 6621c0022b8ca5c36b174af0ed30aefbe906887f89d07233f9abfb69aec4ceda 3148 gkrellm2-cpufreq_0.6.4-5.debian.tar.xz 1aec583f601c3295d7b63b84f44f4eff9471232918dcbd60f951cdf9a9714793 11133 gkrellm2-cpufreq_0.6.4-5_amd64.buildinfo Files: 71ecaa08d4c0ab5d5ec2ae637e599232 1969 - extra gkrellm2-cpufreq_0.6.4-5.dsc 17af9a4e712967ac81eed04acee9a768 3148 - extra gkrellm2-cpufreq_0.6.4-5.debian.tar.xz faf8bb25145cc9ed4a0aeddd0d84ccf7 11133 - extra gkrellm2-cpufreq_0.6.4-5_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAl1tgd8ACgkQdCY7N/W1 +RPnRBAAxSJ0XMe0Tz/fjAzACc0i6kgBWCEbLK/M4LeCty/rbzTzy1eYbcpGmcR/ msNP7y5a1Rr/8iOGmNSz3NGSa36fM6Beu+JG5feoCJcZI42Ln4PGMyx12LtlGeqx knJ7/H2TDpy6O9s0ywjIeDmODRmnUSkb0SauShb2YhVEJugXr0t8wdyBz9IzTD3b 4W8phEr/f3+PJ5gyeTRd4UTWlD7xuVfZcz8c/hNIM93Tcm4aiNfZUkKf56XA/m0y fL4EDme6uXpQGNWYJ8phIrFMGtga/KiyI9mAXC22eCUcyBzpY2LvmW9aIphEK/M9 S0R67f+QBOVU2flHtlZy5kCHc14sdp8d3Rg4Y20WKHqfiUE6/HgQerB9iwVB+wzG +Zjz2SgTnyXJwCUgPUorjyMuQbQsmzvXVO7zX6/PvGSE1q7VeJSPG/f7iR2uo4sT 5xARq92TjEH/otjh4StcESljXBu/lvgd6kxuEeJl4jEzgPk0MDdElHMTTtJNb4Ou bFlM9LJRXnMNz00a0IsoO49uXHHzjWa+D64WfZzl51baHJ5rXJyk166NF7cCJU0W 0Y7CsGGnmGgOrScYrJDOhCSZW+SCEEpmuf5HgKEUYaV8ZjzWHx2/v7gLkSMP6Sol 11XNxsErFXv6zvFHiN74KJvQOEc0r9YfR5pZSeY9pNWHt6PNYzA= =ETKQ -END PGP SIGNATURE-
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
Hi! On 8/8/19 10:38 PM, Aurelien Jarno wrote: > Any comments, ideas, or help here? I'm by no means a GHC nor Haskell expert, but I think it should be generally feasible to add native code generation support in GHC for all architectures which are supported by LLVM. According to a bug report I saw upstream [1], adding native support for GHC through LLVM is comparably easy and might be a good options for mips*, riscv*, s390x and sparc* which all are officially supported by LLVM but have no NGC in GHC (with the exception of SPARC which has a 32-bit NGC that James Clarke is currently porting to SPARC64 [2]). I would be willing to support such a project financially (e.g. BountySource). Adrian > [1] https://gitlab.haskell.org/ghc/ghc/issues/16783 > [2] https://github.com/jrtc27/ghc/tree/rebased -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 5/26/19 1:22 PM, Bastian Blank wrote: > [SN: Trimmed Cc list] > > Hi John My name is Adrian. Thanks. > On Sun, May 26, 2019 at 06:48:36AM +0200, John Paul Adrian Glaubitz wrote: >> Could you PLEASE stop posting to debian-ports@? You are sending these mails >> to every Debian Ports architecture mailing list. > > Please stop shouting. Please fix your MUA to produce readable mails. > Thank you. Please stop sending mails to users which are not affected by your discussion. I'm sorry but after kindly asking two times not to use this address for this discussion as you are reaching way too many unrelated lists, I think it's a fair thing to spell that "please" in capital letters. > Also -ports goes to all port specific mailing lists. No, debian-ports goes to every architecture list which is really annoying when you're on all these lists. I got this email through the following mailing lists: debian-arm, debian-alpha, debian-hppa, debian-ia64, debian-68k, debian-powerpc, debian-sparc, debian-superh, debian-riscv. None of these are related to BSD or Hurd yet the discussion was on these lists. It's not related to Debian Ports and therefore not too much to ask to reduce the noise on unrelated mailing lists. And I would also like to continue using Thunderbird without having to mess with the configuration now. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Could you PLEASE stop posting to debian-ports@? You are sending these mails to
every Debian Ports architecture mailing list.
I already asked for the third time now.
Thank You,
Adrian
> On May 26, 2019, at 5:34 AM, wrote:
>
> Sorry if this is off-topic, but I can't help asking if that "15381 March
> 1977" was on purpose or just from some wonky email client: 15380 days after
> March 1st 1977 happens to be April 10th 2019, so...
>
> --
> Pengcheng Xu
> https://jsteward.moe/
>
>
>> -Original Message-
>> From: Aurelien Jarno
>> Sent: Saturday, May 25, 2019 4:56 PM
>> To: debian-h...@lists.debian.org; debian-...@lists.debian.org; debian-
>> de...@lists.debian.org; debian-po...@lists.debian.org; ftpmaster@ports-
>> master.debian.org
>> Subject: Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
>>
>> Hi,
>>
>>> On 2019-04-24 12:34, Joerg Jaspert wrote:
>>> On 15381 March 1977, Aurelien Jarno wrote:
> ^^^ HERE
>>>
>> It would be nice to have a bit more than 2 weeks to do all of that.
> Ok. How much? Is 6 or 8 weeks better? I don't think, given how
> long this is on the table already, it doesn't make much difference if its
> 2
>> or 8.
> Just something thats clear defined and not some random, non-clear
> "sometime in the future" point.
The hurd-i386 architecture has been moved to to debian-ports yesterday.
I hope it shows the willingness to do that. Please give us at least
4 more weeks to do the remaining kfreebsd-*. That will provide some
margin to account for the non-infinite free time to work on that
(especially in the freeze period) and possibly to get more disk
space for the debian-ports machine.
>>>
>>> Thats ok, end of May is a nice point to take.
>>>
>>> Thanks for the work and the timeframe for the rest!
>>
>> kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports.
>> As
>> hurd-i386 has been moved earlier, it means that all the 3 architectures have
>> now been moved.
>>
>> Aurelien
>>
>> --
>> Aurelien Jarno GPG: 4096R/1DDD8C9B
>> aurel...@aurel32.net http://www.aurel32.net
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 5/25/19 1:00 PM, Manuel A. Fernandez Montecelo wrote: > Not sure who's the admin (I couldn't find the admin address in the > main pages), but they're not registered in the graphs (while > powerpcpse, recently removed, still is). Could you please not use debian-ports@ unless you actually want to send a mail that is supposed to reach the mailing lists for every single ports architecture? Every time someone posts in this thread, I am receiving 9 identical mails -.-. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Hello! Just as a heads-up: Sending mail to debian-ports@l.d.o ends up sending the mail to debian-alpha@, debian-hppa@, debian-ia64@, ... simultaneously, so it would be better to avoid using this address in the discussion. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Accepted sane-backends 1.0.27-3.2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 23 Mar 2019 17:38:37 +0100 Source: sane-backends Architecture: source Version: 1.0.27-3.2 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Closes: 886777 Changes: sane-backends (1.0.27-3.2) unstable; urgency=medium . * Non-maintainer upload. * New debian/patches/0720-mustek_usb2-Avoid-stack-smashing.patch - Fix regression in the mustek_usb2 backend (Closes: #886777). Checksums-Sha1: adecfb9cee373735cd3ae058f8f027af51b0b9a1 2354 sane-backends_1.0.27-3.2.dsc dcfbfa8becf916f3b808ecc39aa4deb5811ffc49 114292 sane-backends_1.0.27-3.2.debian.tar.xz fd0c538a224a8711bd16541673a2bf351ea5e860 8795 sane-backends_1.0.27-3.2_amd64.buildinfo Checksums-Sha256: eb7c40002942a1ab1d1b873c53ea69434d96ad7c916b51b8b017dd67596ea07d 2354 sane-backends_1.0.27-3.2.dsc 59ad3242cf63c0e7d6d992dac4501c8f18518f72d9381ef02de23fb6ef3234a5 114292 sane-backends_1.0.27-3.2.debian.tar.xz cbbb0c6ac95fe969cd3256b86191d09f58515fdaaf833bdff431d8505897b033 8795 sane-backends_1.0.27-3.2_amd64.buildinfo Files: f86f4cf08e7a640682798135e9e2c423 2354 graphics optional sane-backends_1.0.27-3.2.dsc a188d732c76dcef81b753c602b99986f 114292 graphics optional sane-backends_1.0.27-3.2.debian.tar.xz 1a2765f70b8124b07d004089b2f365e4 8795 graphics optional sane-backends_1.0.27-3.2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlyWbb4ACgkQdCY7N/W1 +RN2nw//YitzSBXpMbe+vOh113xk7q/v32Ueot2IKmkM4PJrQKbwRF2mzDvCgR4o 2Rai/KnwBPU0SHui3uX/Oe+0erHLFlF1SlUmk4t4CNib7BjE7ioX34Hlq0HSPbWJ fplo/Nh+kVf+MXG/qXewfN8i5HoNvlKo6wa+SgzYw3aSby5k5HpjPtdBZ7pfPP4d mQZDRSu+HnzOJO3+GLcuKmWe+W4K9jhcYoVNdjEzWdNUc2jzdRhz9s5pGO8X1ySB /4ZzNySa9/PCzgqtg8FWXa86ZSGJ07QQW+0CXHVK8PxrVUlSsDH+D4ZGM5gduGVb HL4ydEpbKBE/sWpGgyb+4VMLxB0njL7RCnC4kNcj1tlF7tdnNCKvuFRCTT4jQNj9 a4a2A9SoIDD8P3bAYdjmjXOenwOM/5LnweYVGgv5sdnCUmStgJ5p1uajAvGbSLtt bG8DAUZv0UBV0ztFO04QJWPZvIJgtKXCodns6rdfgnaRzBdygFW28e08ijBphpc+ 1Ggwv3GSvnrA2zXEchj5BQ0tIvoalLZOzC+8Pbs4/pE2X9qeX0BjjifY/XlBSox0 bZtcRzS/nZyiZSe0j14zDJV30qaRlZJwQiinnXiI4SjDwSUr62Lpvr/4nGl8rO95 EvbnZ0Kk3ULsRIu/wvdtGJpJ4CveMRh85sh/w4oWbLx4O2Btf6s= =YvKk -END PGP SIGNATURE-
Accepted powerpc-utils 1.3.2-1.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Feb 2019 14:35:38 +0100 Source: powerpc-utils Architecture: source Version: 1.3.2-1.1 Distribution: sid Urgency: medium Maintainer: Adam Conrad Changed-By: John Paul Adrian Glaubitz Closes: 852575 Changes: powerpc-utils (1.3.2-1.1) unstable; urgency=medium . * Non-maintainer upload. * 03_udevadm_path.patch: Switch udevadm path prefix from /sbin to /bin (closes: #852575) Checksums-Sha1: fac63ea016e1b2ba478347fcb42f66d04ad6f4e1 1992 powerpc-utils_1.3.2-1.1.dsc 87ef4dae9c863d93c6155bdbf547f6bdab72e901 4908 powerpc-utils_1.3.2-1.1.debian.tar.xz 9c83fe33869d7f8ca5645dd24971b7a87826ef89 6014 powerpc-utils_1.3.2-1.1_ppc64.buildinfo Checksums-Sha256: be724864ccee76cfb235e47c30eb4d9eede65c262d42835d1d45994827577f47 1992 powerpc-utils_1.3.2-1.1.dsc a526bd484cfcf65753927c82bd0ff006dc324f12d64ea062d5e37d15b210570e 4908 powerpc-utils_1.3.2-1.1.debian.tar.xz 9199b9fc1c138ec48ceace66ced51337c1c96ae3a8a0a6a49436f51edcea2f6f 6014 powerpc-utils_1.3.2-1.1_ppc64.buildinfo Files: b52054d8f7d719f896f0799618f11427 1992 utils important powerpc-utils_1.3.2-1.1.dsc 9ab2423080cfd9e55913e54adbf88fb6 4908 utils important powerpc-utils_1.3.2-1.1.debian.tar.xz 544259a8d4c758acf246a7eb76d9fde8 6014 utils important powerpc-utils_1.3.2-1.1_ppc64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlxgLVcACgkQdCY7N/W1 +RPyZg//fMUahH18M5V/P8c6icxinTcUvubrfZoWBiSEX7bbfS5zYTXPIDI7os7Z SG4iuAJAiFENhrCjiSYpFot9B+6bb80ZKWiEWFmwyhULsawBvbbtDCkXweTm8Q3m QCkbJdWxViXPw6pp3TxGFVv3PhbpRAN2/U+MJY5Hu1rVj6x8d+mT3Yhpji9LRQ2i PloZMFE9ks210KeKkgl7E5gvhYoG7lVDHJ4S5MilYDB7TbvY05gQIXB+HD987x6f dswzo+gxgGTXHMYorVChH4D5taNJnBuHNa/zLVY+/ovDiWaKQgWl+1S98VVeBMJB RyWbzBp4x8WT1/uy2BaMvh4wK9R6uexY5zIXZV84jyPVmYUHyesYZ9laoyXuUOAt TTQ64IFRgIohStzGN/dnlyaerr9sQOctwnMAcwywC6Jns9H/eVsTA21FXaGU+wqa 1pGKnaYnir5kuGYtRJZQm6xLLDdRftXDS6cy2im7onqNR3P8nbYlsx8VcV7mAn81 2Qj4L+MrVHa+5ZsbtUG6AyNYdS3egBQIECXRZZrSucAl/wMsKaMaG1xrAiSPj9Db W7s7TSYfGFeGXaQjPsAPK9TJnmH9rkd1XUnMSI7O92hBiC4kOvCV5Tux9KZuy1Vc NUvqiLisN99H24TGBrA13NDeEA7RNdpT0mZLUGCGgvXWN86n4zE= =I6kN -END PGP SIGNATURE-
Accepted linux-minidisc 0.9.16-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 16 Jan 2019 16:18:06 +0100 Source: linux-minidisc Binary: minidisc-utils qhimdtransfer Architecture: source Version: 0.9.16-2 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: minidisc-utils - Command line utilities for MiniDisc access qhimdtransfer - Transfer software for HiMD Walkman Changes: linux-minidisc (0.9.16-2) unstable; urgency=medium . * Switch priority from extra to optional in debian/control. * Remove trailing space from dh statement in debian/rules. * Fix spelling errors in description in debian/control. * Fix spelling error in debian/README.Debian. * Fix redefinition of licenses in debian/copyright. * Use secure URI for copyright format reference in debian/copyright. * Update years in debian/copyright. Checksums-Sha1: 1ee0a8001a7a2cd73c94d6a755eca9f4f08fa9a6 2109 linux-minidisc_0.9.16-2.dsc 10f10958da325dca7cb140d72688a179144de022 5212 linux-minidisc_0.9.16-2.debian.tar.xz 3c8dfdd520b15eb797ed739ae779ce5e8e974fcf 12636 linux-minidisc_0.9.16-2_amd64.buildinfo Checksums-Sha256: f23b71cafdbaa29bfe8fdef821aad2efb7ca0a185bebe1d425ea2474d03a6579 2109 linux-minidisc_0.9.16-2.dsc 38c021d031429aef33c52da80d067f4f92676ee25a517dbc2d6a4da7f24bd7c8 5212 linux-minidisc_0.9.16-2.debian.tar.xz a2484d18a4a178fff1c8ca392ed91412880067a4faaae11e75877b4e92ea41a4 12636 linux-minidisc_0.9.16-2_amd64.buildinfo Files: 324cb36ae94f3606ab4c8e4ec35a7291 2109 sound optional linux-minidisc_0.9.16-2.dsc e1577ee4e32c43b08ec2bf06ceeb6203 5212 sound optional linux-minidisc_0.9.16-2.debian.tar.xz d1b8c4df9b591cdd37d5c18d10c86dcf 12636 sound optional linux-minidisc_0.9.16-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlw/TR8ACgkQdCY7N/W1 +ROSXhAAtOi5UjgrqWPJNc4SkHsFVpdwlJpPz5z4BPmKQ8FuT/ZhijHK2n5BHE0Z ols6880nvjHEti5cwkDLuPhMlnoKiwtaJyil5GWhSS2GQtn+gOR57Sr5Yo7VYNsW 7A/rEBNd2vPJ39DJ43erBgfnOngj9kH19LdHT6zD2/HtMe59NsVHwq4vHudrxDUc +7G987DYo6/R/SiMyy0JtgxjeF6JXgxbNnbFsxZLxNzkww4VnFcpd7j4EcWwxZmZ Q08UuWjdUeU+R2/PBB6FzFVfgjuJE+TbxWORaySX29Ge6E/NMWXxRsu55g+MmwPK VR4MEKars+AsdelpmqXb1xFPEXEBIXciwVx7nB1USbODCg0rzsxjJ35MHNriNV03 +9kCRp+yNDH3+bMNs2zKBpjPXx/TTlpqotOoQw0D6ltXU24M8Vjt3ADkYywwWL7r CzMsuUwsitMN4PrjdQKjAXMe36awVOcyStY3UP4DywxXbVwSvfxdN3o3qGZAuXD0 wTdm3RdUjNqBIq6Y9LLYQkSlAWWkwi3OGWhG/l9Dwk0MT5xtefmFPTeKSVNjo9RY 90k9sDCOi3cKiL4fcfv9plegXq81cHtr77v82iOqN1UTIhvE/Z/ZbcxlbQAfbG1M 3b0ww+cGEAPmiGU/CTliJ/rK96bHwE6aLy/5DPwR3bJWw9ChQiM= =0cI3 -END PGP SIGNATURE-
Accepted linux-minidisc 0.9.16-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 16 Jan 2019 11:08:26 +0100 Source: linux-minidisc Binary: minidisc-utils qhimdtransfer Architecture: source Version: 0.9.16-1 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: minidisc-utils - Command line utilities for MiniDisc access qhimdtransfer - Transfer software for HiMD Walkman Changes: linux-minidisc (0.9.16-1) unstable; urgency=medium . * New upstream release. - add missing dependency on libz in qhimdtransfer qmake project file - implement very rudimentary MP3 download support in qhimdtransfer - move himd_writemp3() from himdcli to libhimd - free allocted strings in himd_write_tifdata() - fix crash when _trkidxXX.hma does not exist - use regular expressions in scanfortif() - scan for the highest numbered track index file in scanfortif() - use better names for argc/min_argc in netmdcli - check arguments to avoid out-of-bounds access in netmdcli * Bump debhelper version to 12, in d/compat and d/control. * Update standards version to 4.2.1 in debian/control. Checksums-Sha1: 59ce66d7b56af624850904b35be7fbb188f8fef0 2103 linux-minidisc_0.9.16-1.dsc 4f12a7daf2bbf06d5113d176c066808ab9234ff2 2462052 linux-minidisc_0.9.16.orig.tar.gz 6d0d9fce08d56b95ab2a71165028dbd17ac37cd6 5072 linux-minidisc_0.9.16-1.debian.tar.xz b9749f82c264dc530f47799fb7d6a5f46a9390ee 12680 linux-minidisc_0.9.16-1_amd64.buildinfo Checksums-Sha256: 911e2b76f388cf1d0a789264db6f6b408fb8421ec063a49c50a80128539f88f9 2103 linux-minidisc_0.9.16-1.dsc 457962de3da8557017e9d80009fecd50ed06c89b8f34a5f2567faf8ff13c9352 2462052 linux-minidisc_0.9.16.orig.tar.gz dcf9e2fdbda18bff5c4b4acde7f3a46849ce8754334b20a83498e928273d8e64 5072 linux-minidisc_0.9.16-1.debian.tar.xz 6dc2d02eb400d775e53c02477aee4678bef6b8a730d6a27511207aa623d37d1e 12680 linux-minidisc_0.9.16-1_amd64.buildinfo Files: da575b578be0b9fba28e37ff235d93c7 2103 sound extra linux-minidisc_0.9.16-1.dsc e4a2a35494220e4f5df6bba28b0b1aaa 2462052 sound extra linux-minidisc_0.9.16.orig.tar.gz 972a46a8173d67a915017950f28cc212 5072 sound extra linux-minidisc_0.9.16-1.debian.tar.xz 2615bf7f70e0eb875d0887b5171f95d1 12680 sound extra linux-minidisc_0.9.16-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlw/BjsACgkQdCY7N/W1 +ROK3w/9Hy/5znLdFlMEmtlArnKVuM/dyl01S4hDBWEbx+PraV4I+XoMwE7NUYm2 GN8Z3AJ/VbwAJG4oG1liYXAGPq9LKXYzd+kB9axlPPZ9wVPjDRJl87U+aoy3AbIT WFIi5A5QwvywBHttIkF9nFj+f/4FwIBiHNODNLddb+5cNd3gJqF7yTeHjszwLYPP RN0UwgqoiXLX2k7STxPcUXurmcK89LfcpTEUNNfYQYPnJOswOiEcogiTUUc4onA/ cUdI4438rbotYG/gMyEGpO7adXimUzbCyOPLTlgzxRQNa1LgKeuoUFapzAHBQ2Ip FiwRcVjRS+y+OJAGMamuAIcJk+ORNR67NvoZ+TUtJUuCCvU0rZ3cr3m3GsSdvI90 87k72SbiiJNI81CYrxlcRWwz13HZSxS7dXmLfkhTgH++5nKP1xkyFCvb9ZarRiFa 77lx6qBp+yzdSeFOxO6tyGgQCnT4KI3KDmtoMaxneLDCYRNfLEZLWqv7kTKVysQq bXqWzOJ7OzEwx2J4Qvb8ED5OKHRZm1m+EAJu2s5yPqBlX75GWnsymK5ikVI2pYGe fav8EIAGROYeKfxlhNljCOX62+2Ie0NtlM/gyC6m7O/PzzBXWytIuGcrJPXd6MHS HrysMWm5SFtUo7Uab4+IWOBEoSYFm/36xyn0vRMz3pZO8sFuVic= =rYSx -END PGP SIGNATURE-
Accepted radeontop 1.1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 30 Dec 2018 13:16:25 +0100 Source: radeontop Binary: radeontop Architecture: source Version: 1.1-2 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: radeontop - Utility to show Radeon GPU utilization Closes: 870135 Changes: radeontop (1.1-2) unstable; urgency=medium . * Override dh_auto_build with empty target in debian/rules to avoid radeontop being built twice. * Remove trailing space from dh command line in debian/rules. * Add -DENABLE_AMDGPU=1 to DEB_CFLAGS_MAINT_APPEND to enable amdgpu support. (Closes: #870135) Checksums-Sha1: 6ace5d038db025588fb79a89dc15dd31fcf4f039 1924 radeontop_1.1-2.dsc 7acffea50cb3aedf209a351d0d57ac46e72ab568 2936 radeontop_1.1-2.debian.tar.xz 44434013d52af1eb9ed17ff7ff7bfba938e7e670 6227 radeontop_1.1-2_amd64.buildinfo Checksums-Sha256: df1e557b7cb9cf9ffe3e51de7023a6353144cbb57ef285e501a81d38dbc1f577 1924 radeontop_1.1-2.dsc 4b07f78386043fc85499db25076d8cab34c2cff26e02a729ef047eb50c429e56 2936 radeontop_1.1-2.debian.tar.xz e50a5f811164d4a30cba2fe9df2f5182d8aae498349f6802bdc6e8b12cd4573f 6227 radeontop_1.1-2_amd64.buildinfo Files: 128a68ecee62f34bd505db24526b42c2 1924 utils extra radeontop_1.1-2.dsc d9816f573764109d6645f572454d7b59 2936 utils extra radeontop_1.1-2.debian.tar.xz 99e80d61d7ae09db273488f8bb2d3456 6227 utils extra radeontop_1.1-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlwot8AACgkQdCY7N/W1 +ROWtw//eh9PKRh7qcVAWLvuDXY3pQRW/xRwyICPIt/8LTpZL3HDWUBrzpdf24UU lF4HJJDhxWoWeOMwjg9LW0RixBlpm+1qtTD3nq3HWeQmyhMqLlssPYg+360wRpl7 mtePWWaeOl5eR/mLMZJbYRqYdBrmSnMg0BN7yORv3j/JbsyRqGhGhIY0Jbm073WD DGmFBbA6J3PIhhFlD9qXvthXyft0C857Mj07gWkgjg+byOlcTi6Q/1qQIxqbSU8q FaCpzVABPcG0xPkS2XiqVAX/a+DP3JonFNggKxEJIheRdz1cLH7f/S1u76IKDZqy lSZjYSggNJ7d6WyplyyiQ9eCZk4IJI3e2wzyKOPQpauMNuCovk+eyX0Ku3lru+7E eGLYY/IB/kKIy1Y/sdiG8bRuokrLuAvZuoiaQwBEswxQ09DgQDLhSz4jkwpImuxO kGqmACUy8Xqbx+i9hELaMbTyhQSqBiOCC9hxlSveNbBIfjBX3ON5rV9dFqZIv2p5 EYWO+p0MvlGY0ycygi7WCQHw2iW3t+SdthsLPZCcU1Hy74jwD56DpciQDZSdKzfd hxRE6u6itjFcq26AOUXm/DYQTMcDTSoLOxLzahkGPVc3B/oiCAaiSjmbrWkg8T6c Qo0Ik3eeNG17Vnit0dwJ5qaI7JYvzKnzrX/8LmWXK0EdGOb9Ykc= =8uEp -END PGP SIGNATURE-
Accepted openscad 2015.03-2+dfsg-2.2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 30 Dec 2018 01:28:34 +0100 Source: openscad Binary: openscad openscad-testing openscad-testing-data openscad-dbg Architecture: source Version: 2015.03-2+dfsg-2.2 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: openscad - script file based graphical CAD environment openscad-dbg - script file based graphical CAD environment (debugging symbols) openscad-testing - script file based graphical CAD environment (test suite) openscad-testing-data - script file based graphical CAD environment (test suite data) Changes: openscad (2015.03-2+dfsg-2.2) unstable; urgency=medium . * Non-maintainer upload. * Drop ttf-marvosym from Depends of openscad-testing-data package * Reduce generated debug info during build by passing -g1 to the compiler on powerpcspe to avoid OOM issues Checksums-Sha1: 832c841d7a76ca274f264efb073b78f21bc98861 2809 openscad_2015.03-2+dfsg-2.2.dsc d667cf608c68f22d1be8a9a79c14263a7c15f9a0 30084 openscad_2015.03-2+dfsg-2.2.debian.tar.xz ec77adb7d651efc3bce54c0276a9178e1217acaa 15072 openscad_2015.03-2+dfsg-2.2_amd64.buildinfo Checksums-Sha256: bc4b23a2e12762804317f5bba34cdd1e611cbc702629b422a22e20db9a4ffb0e 2809 openscad_2015.03-2+dfsg-2.2.dsc 5953bd4e5a1819931812795cf6f4ca69c9ba8afaee0ac26692fa5bcb93109328 30084 openscad_2015.03-2+dfsg-2.2.debian.tar.xz 9820246326e80e76338d524fbac9d08fc7d12517213c301092e17cea67e81207 15072 openscad_2015.03-2+dfsg-2.2_amd64.buildinfo Files: a6d0dacc230135a571c8f8d2f3b1fd42 2809 graphics optional openscad_2015.03-2+dfsg-2.2.dsc a7c05af171c2a1eba21b1e18034239d0 30084 graphics optional openscad_2015.03-2+dfsg-2.2.debian.tar.xz 7c4485c81b66ee1dcc128dee012a5233 15072 graphics optional openscad_2015.03-2+dfsg-2.2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlwoEw4ACgkQdCY7N/W1 +RMMPhAAxTV43xJTCWL2WHwt1PEdm0gVulpTF6b7HNnuu46xPEfhUmfI6w6jyKyo Ms4MVN6jp0N6aNmiXIZxKk6weu+cpVoLGWha01K9Ob8TcvGXV/xhnT6R0M78UI7K 0jMwkV92qFScxVlfvrCVa1XPYg1x8LKytAYsQTqTY/JxyWLruFnBvGv4efiI34Gw BxceIeiB7IP7xco5oATqtoPkvTBe/4ppuibm5z4svr6cY4nlvrXfiz0R5sBFJ21l 7JdmEQi90aF+tPFkgPvMZ6qNuT51tNIh9WpHy5eWm9WLmaZGkLyQFmWaKULvOzME zGHFXDzxZONZTd0wrBOmIyY3GVInnLbu+h/+E5UQNbxqymdII5tkrT2zT0wh39wR LY30AxOAkCW8pMrobxiTaK0l78mB9LFA1FSJDUP40hNYe8D3ZiNj+i2tCvJJiOFe uqN2rtOM/obABBAQQoo0sXVI0pZjQq0zq2eC6uYKn7ChksR5U2hHZrADnA/ENBF2 RcoVL/0bsQFfbpOaoXjST1k8KIjiyCjrt5AOOjXRMG7nWZVt0tnJmkZbHnaW0fbt ZbUd79HIoiU5iCar7QYR1BHVUq5FY5B2YR6RIqeRlBHaZWqfi4A40K5pgz8QRAlm 3HPj4UbAJsjAOo34vfgYB9NkubvSBDxyT5B+D5hOh2jxJGkV1IY= =5DKp -END PGP SIGNATURE-
Accepted radeontop 1.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 30 Dec 2018 00:32:12 +0100 Source: radeontop Binary: radeontop Architecture: source Version: 1.1-1 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: radeontop - Utility to show Radeon GPU utilization Closes: 894054 Changes: radeontop (1.1-1) unstable; urgency=medium . * New upstream release. (Closes: #894054) - update PCI IDs for one polaris12 and one raven card - drop privileges for setuid installations - add appstream info file - add support for GTT memory status - update amdgpu PCI IDs; two new ones for old families, polaris 12 and vega 10 cards - various bug fixes and improvements * Bump debhelper version to 12. * Update standards version to 4.2.1, no changes required. Checksums-Sha1: 82879145d1810eb0a1a0ebe02ca21bf7de2c65b4 1924 radeontop_1.1-1.dsc 6ba97a38ae22483ae53bda52295b962b661835d1 33527 radeontop_1.1.orig.tar.gz 4daa6daeeaaebc55bb542d8e5d6643e1242415f4 2772 radeontop_1.1-1.debian.tar.xz f3c45388a245e1caaa7bc07b826b9b6ff5f3de3f 6392 radeontop_1.1-1_amd64.buildinfo Checksums-Sha256: 362c2a184a789a072448566f2fea9aa8644b919a297a24182c964fb14c7135cf 1924 radeontop_1.1-1.dsc 8685ea42a44b24b92974ce5b774e14ab64281f05440ea6e6df35a6c48a3460bb 33527 radeontop_1.1.orig.tar.gz f5958de95884f48959b8a509a2360a865c7c61ba2731195a359f3db8f94760be 2772 radeontop_1.1-1.debian.tar.xz 555ad0968c4af9d9658170a73df51fb4b4d832d5f58d8e327440bd4b8e214700 6392 radeontop_1.1-1_amd64.buildinfo Files: 30a5691978bf1248457e41576007945c 1924 utils extra radeontop_1.1-1.dsc 51bbca383b72855ff1c6d4e7d1f4f657 33527 utils extra radeontop_1.1.orig.tar.gz 2e9210d5004bfdd5780503e84c411108 2772 utils extra radeontop_1.1-1.debian.tar.xz 80977700d516e756dca7321daf468e6d 6392 utils extra radeontop_1.1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlwoBjAACgkQdCY7N/W1 +ROSOBAAmKfXnv66mgqNnrhqyNIzD2xVFtoYLt9xhI58labFSuLswWVBEBmcxh8y wms0Nn6EOgayM7AG2AOM3ecnJzW6l2aFHPqRVSoO4KAiwwu+AwI1d7d1gFz8teto w259kGPuHbMvfhsJLdtWp6PcmUZLLVtRV73XDrSTau1SYFS71iKddB1xZxgWK1IP EDmPMIX/+LWW4NnBw/NDE1AzQcmukrfJ+peQR2LlcoV72dtZcSG9Ox68L4yhozSK FLVOIs5/9mPTsHIVrnGLPgJOW86UIoISgwJKyslhYHDjuBQaB3EAcjLMbjIZn1Yb /Pa9TVqf5raYEzoDMMqOcI4PqyLKfyeHK1ajGljqLkWRpBh35SNQSgGbYW6tdUw6 4vKVzL1WpF3hJpHCQDMXC+npoc9vvDS/XZcrQKgOCeAJQFO9GdCCbArYc/fdEmXW PCYHFaANyveAaBPTOwATE60ifTIHkbAKCs4UYjLrcHgpVLJsR59xCKLdLjplh8iP qg1oCIg1Z4Kq4bMfFAV5ZzoJPqjqAZHrwMGqh2qtWXhn+DWnGh5uo86LJ9KzwNiB 4/1Ivat/5DEcEmAjaeSzKOPZ92xn0SsKOQWsCaA2def3QgoNRKD7Deh3SXli+Q9J UjV1gOixBICcMsrSY6mu715OyAv6c6w3TmCRrY1vpcrWGomHZS4= =ndfW -END PGP SIGNATURE-
Accepted openscad 2015.03-2+dfsg-2.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 29 Dec 2018 02:32:32 +0100 Source: openscad Binary: openscad openscad-testing openscad-testing-data openscad-dbg Architecture: source Version: 2015.03-2+dfsg-2.1 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: openscad - script file based graphical CAD environment openscad-dbg - script file based graphical CAD environment (debugging symbols) openscad-testing - script file based graphical CAD environment (test suite) openscad-testing-data - script file based graphical CAD environment (test suite data) Closes: 809634 883986 884509 885429 Changes: openscad (2015.03-2+dfsg-2.1) unstable; urgency=medium . * Non-maintainer upload. * Add emacsen-startup file (Closes: #809634) * Add Debian DEP-8 test control file (Closes: #885429) * Drop ttf-marvosym from Build-Depends (Closes: #884509) * New patch * Build system: Strip -g -O2 from CGAL_CXX_FLAGS_INIT in testsuite * Reduce generated debug info during build by passing -g1 to the compiler on mips and mipsel to avoid OOM issues (Closes: #883986) Checksums-Sha1: 4c587d518cb28376f6e26ef794e9663c84badb7d 2809 openscad_2015.03-2+dfsg-2.1.dsc d05cd4c2423cfb1861931794c082014e2d9afaf9 30048 openscad_2015.03-2+dfsg-2.1.debian.tar.xz 3f023288d8c608f82c24b059c26be2bfff25d840 15091 openscad_2015.03-2+dfsg-2.1_amd64.buildinfo Checksums-Sha256: d6d378cd9aeebecd5c50ac9248c5d70ecca8529cc7dac56410e2ab4296e609d7 2809 openscad_2015.03-2+dfsg-2.1.dsc 745f2dc15d8ab401a15d26875b8dda3aeefe99ed6e3d91193a0f1b1e7e587134 30048 openscad_2015.03-2+dfsg-2.1.debian.tar.xz 45894e50e7475e595ea5c5f4cf7b0654dedebf1571ea00876cb169a9153f4723 15091 openscad_2015.03-2+dfsg-2.1_amd64.buildinfo Files: 5e4b9ec6105ca4f76f97cdd4847d3cb3 2809 graphics optional openscad_2015.03-2+dfsg-2.1.dsc 053ce4561670920dcc82b03b35b69426 30048 graphics optional openscad_2015.03-2+dfsg-2.1.debian.tar.xz 3ec0e341e8fc00c8309438fef70bd126 15091 graphics optional openscad_2015.03-2+dfsg-2.1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlwm0KsACgkQdCY7N/W1 +RMrVBAAunk1PbrucrtuzJptHdaC3gtaw3V0jYX6rgZBTcqnb1dj4/Fco46cjnYK 2bf+3pL5YI3fmES2vYXgNYwSo0z9IASPdw8GnMcibFCidEBvr2tYGVfKMUJQ2Kh6 CjwBm+i+zfgLjCWw4T2J0/ueY4frHbAY7DB03c74BQOSDErekJdqjPhhMpS4LOnE HwuJc2yD7QHDRiMaSkP8mxlisUiqzFIvt7KK8ZfjGo+6W9WXj3jgE2jV2MbD5O66 EDlFlWkVAMmtyAHgqUBpN2JE/RkgwaLCWnvtF9ZQVxBQDPegud9fOgQ6Jl8whkph It4nDYOfR4TkUrXUaCiiVVg5PR7O3mGUj725wTvN9ADAalPDSvrPjgbp8NACvYJd e4/sfxtLfF95ugA4rmVPzxDUqoQPgJrHPJ8nO65n3yrv6o6t+itxWqS5YAUgi3Sk fOznKBCtpHQsLp4uJo2FgT8nwzwcp4R6EmDKgIRhBiMiA5XjqtGHJT6/BNDgQaHQ zQukBtuPQUgcV/lHrLVWY9r7pG+JK/5sHlruYoI8jOAhME61lDk2YfrcJ8oijpmY WYfF1ppZU/d3pjtnQTnGyw2N+GRYdf61yt9xwQQ9gXVd8AQ81CZtJMd0YIz2sAYF funAKQXh3+wGaO4MBtbg5uMA/yi+U/RXdtUbpal4eEbJjm5hZjk= =qIMF -END PGP SIGNATURE-
Accepted gdisk 1.0.3-1.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 15 Dec 2018 11:57:39 +0100 Source: gdisk Binary: gdisk Architecture: source Version: 1.0.3-1.1 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: gdisk - GPT fdisk text-mode partitioning tool Closes: 898985 Changes: gdisk (1.0.3-1.1) unstable; urgency=medium . * Non-maintainer upload. * debian/patches/alignment-fixes.diff: Reset struct alignment back to standard after each #pragma pack (n) (Closes: #898985) Checksums-Sha1: c6b3696f4bf75e592694a6b307a099ff61a2b4e1 1889 gdisk_1.0.3-1.1.dsc 4b2f03a068e50ef8e44916c55241ad2c4737b0bd 6264 gdisk_1.0.3-1.1.debian.tar.xz 188706b5f4f2e36b666202783e5073e7a49bb66e 5805 gdisk_1.0.3-1.1_amd64.buildinfo Checksums-Sha256: 87372056ef1b963f1e36c30c7a4827851314f360fafd29c0a8abe8f7efb72ebf 1889 gdisk_1.0.3-1.1.dsc 130e07fe36bedfaf7c45d946cd853ebe919e46602e85c7e56651c715937c8070 6264 gdisk_1.0.3-1.1.debian.tar.xz 7506200a77499cd840166b2ab6b413cd354251398f2122a7e7ff93f7c3d6d74a 5805 gdisk_1.0.3-1.1_amd64.buildinfo Files: 35d84657cb13e6ecc3c3b56a69da16b9 1889 admin extra gdisk_1.0.3-1.1.dsc 7f12c6c33548ed7ee2ef2900a2e47f3d 6264 admin extra gdisk_1.0.3-1.1.debian.tar.xz 06f8fb59e157d830da08f25d671858d0 5805 admin extra gdisk_1.0.3-1.1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlwU39AACgkQdCY7N/W1 +ROdqA/9FA4J3NiURKHc3WP+VJLDEALriA2mP0uSbm9Xpq2Mupgi+jPWb/hDnpPV Em3vzMSGu8cZdek5/DiGp2ryhdjsyXVmeSrdyfuhIePundj+rCpSZQvpW8AHU4CA dk+Agqx+Uq9rGR7UCAMTvJ6bpLTK5iss5GY3WpL8tjtQcxMjL8AYOLVuVYzCjyjd sE+AzIiZ8H90gyONld4x7Q0Xecii44oLhILck8bhLZNfm4XEFKEvya5ys/2pN4Ai dBzwn2FufJNETdjeNkIIQ2dtkvrCyuU2dL7eAyboChkINSsZWnGNFSC9wzt5uwTl eZr1VoH/WshZrIk8+GlnMAmcbJNBeCPJLmbUsFuKxrd/l2ipIUO4QaGTCvWWQfYJ D+DUcnYk//l6iQZkUYe2lPgFR0+qgqqjz/FxhZxmwuUi55/Q91uHPA+qTGkgnbN3 /CqZK6MOu+DEXqZyqujFp4frxiZu773WMT/a70rptXLgjKhcgiMYxTLeu0yCYYB+ Z1whUDxOi55n+Bhps9JNqL9Vjbjbp5Vt53+D7kCYnXm/EM1SMOww5Ff3F07iwzK+ 4KNQ7BOBeK8+s13OHrWrsotQIV4SNvelC+hIA4E0B6++nkN51rJDmZBCpg5FN1jI ZfUkg6JX24BZ3s4re+jJEvZRs8SvPOhJ1wh5LvGk2ZwaCvei1pk= =AbOL -END PGP SIGNATURE-
Accepted libvoikko 4.2-0.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 25 Nov 2018 21:36:52 +0100 Source: libvoikko Binary: libvoikko-dev libvoikko1 python-libvoikko python3-libvoikko Architecture: source Version: 4.2-0.1 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: libvoikko-dev - Development files for libvoikko libvoikko1 - Library of free natural language processing tools python-libvoikko - transitional dummy package for Python bindings for libvoikko python3-libvoikko - Python bindings for libvoikko Closes: 911985 Changes: libvoikko (4.2-0.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream release. (Closes: #911985) Checksums-Sha1: cb18fb76520ce5b0fd7e9a07473f978131031a74 2135 libvoikko_4.2-0.1.dsc 0ac7eab0ade2b621a63b564db793126f8e2f6464 653769 libvoikko_4.2.orig.tar.gz 8214e5abf72e67ca5fe3b686bc3b185ec0145344 6400 libvoikko_4.2-0.1.debian.tar.xz 3d20ff8635ccf7955462934038e9b2275c46267a 7503 libvoikko_4.2-0.1_amd64.buildinfo Checksums-Sha256: 0c80b8e730d294e6976590bf28ba576bbf615944db324095e409ebec0ab93d3e 2135 libvoikko_4.2-0.1.dsc f13c59825f36152f388cd96f638e447744199775277f4e6bcd0b9483f0eebeca 653769 libvoikko_4.2.orig.tar.gz ec1ec68be46b577b92a9559dc8b124d6061926045f74e310eeb44422102f 6400 libvoikko_4.2-0.1.debian.tar.xz 5beef09ad6bfd82f8a128f85c49d0520c726ecc811c2036092844af0e26e8337 7503 libvoikko_4.2-0.1_amd64.buildinfo Files: 94301b19fb468fbd72007cd7a709b716 2135 libs optional libvoikko_4.2-0.1.dsc 138e188844d522371e5c3df1fed9e66e 653769 libs optional libvoikko_4.2.orig.tar.gz 58fdcaf28d9ee8d9dbe80bb4c69588c3 6400 libs optional libvoikko_4.2-0.1.debian.tar.xz fe2b806030b8d8322400fb058efddacd 7503 libs optional libvoikko_4.2-0.1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlv7CTEACgkQdCY7N/W1 +RMcOA//WJhZWN3n38WqzohydmpP8glwHKR7ywRTyfl2fu92ZyFs36eB3axOH2zw U3H43+2QRqWoCvAJYc+9Mbedwut7cd0Vw61LaaPlnBw5meZprthxADuQI0iy+ERF Cfheq8mGMw6o+Hj6JLF7DHEIBUSSXQcoVYh6H223b7u77ZQMsEHAXgRL8GwtfXx2 y2Lgbi+UxR1svcbmuKulIE5WRwC8PZKJ/mY4oLf3eBCWX67Fi2h+CJ9wzahIrYul +WrwcvKuC4N0DGsBx4LVvDovAsq8ZufLtzSR1SNHICb2tMpkYmGErykLxMn4YCdK RcXeXw3RNCH9Z5WmTuLWCVqpCTUPVQs6MlMOHqfdPXLVAeonNNHyRDO1gWsqqhZA uKl6XJcp5vkhfWRddLpN+1qjDOLI4YnuyCoOWum+yBQvIaHKi3eYl0aUtUv88jFo t7ZtcqmGAGfCTnUbp1o4Gw0HaVMmpqhrcP2rcXGfUWNanlxoaTHYQhdlL5AW0fyn BCxi6U4b1tmCXhagpn2/rL3/8Nqus7X1lt5J1K7a8jXiG+HzbWLEXG3QBXDKlCSZ fED5QM7VJ1sQ1ii1ZpwTrgCO1xXyJ1wC0VdvnamYn60Hi8oeZQVSsUCAgzOqmzKu pdwm7wDRJZOoUAbhwtWPHrxEbSnvw5aTWgZxE77urfo03CAGy6g= =mC1K -END PGP SIGNATURE-
Accepted fs-uae 2.8.4+dfsg-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 02 Dec 2018 19:10:14 +0100 Source: fs-uae Binary: fs-uae fs-uae-launcher fs-uae-netplay-server fs-uae-arcade Architecture: source Version: 2.8.4+dfsg-2 Distribution: sid Urgency: medium Maintainer: John Paul Adrian Glaubitz Changed-By: John Paul Adrian Glaubitz Description: fs-uae - Cross-platform Amiga emulator based on UAE/WinUAE fs-uae-arcade - Fullscreen game browser for FS-UAE fs-uae-launcher - Launcher and configuration program for FS-UAE fs-uae-netplay-server - Netplay server for FS-UAE online play Closes: 914790 Changes: fs-uae (2.8.4+dfsg-2) unstable; urgency=medium . * Add debian/patches/0002-rename-async-for-python3.7.patch to account for the renaming of the "async" module in pyopengl to "_async". (Closes: #914790) Checksums-Sha1: 58be5eb49d037f1c62ac608e60b68a0e2975c1a3 2281 fs-uae_2.8.4+dfsg-2.dsc 4c269fd1ed78b69922ab361d5fbe4a4b2e13 23608 fs-uae_2.8.4+dfsg-2.debian.tar.xz 3cbbe6e36097826e3b86a6910a86f16449819a72 12425 fs-uae_2.8.4+dfsg-2_amd64.buildinfo Checksums-Sha256: 58c423c4f3fd4559faabb90e26e96848b8a4c55fb3c4ffc627763cb3120932b4 2281 fs-uae_2.8.4+dfsg-2.dsc d564b353d8e3389c12755b19fa79c4cb2d04faf94c0955829d006380e4b12cc7 23608 fs-uae_2.8.4+dfsg-2.debian.tar.xz 195d38e2faec35423fe00ca4047c657726398ca51fb08b7904cc282a6ea0220c 12425 fs-uae_2.8.4+dfsg-2_amd64.buildinfo Files: 49e0549b67082be9e2d411354331aacc 2281 otherosfs optional fs-uae_2.8.4+dfsg-2.dsc 136b1769a93bf21e3799409e117cb8a7 23608 otherosfs optional fs-uae_2.8.4+dfsg-2.debian.tar.xz d42207b9edd1e8975af6c1e3c9f57175 12425 otherosfs optional fs-uae_2.8.4+dfsg-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlwEJmwACgkQdCY7N/W1 +RMKuhAAkjXYhAQwJzVPnltnQG+L/opACuLiaX6jxSvpS+PobbWxG3x7a/FabP37 xctXX2gxXq3AUi5/NZwc3uHK3IvY7P6DYV4xscJGX4fAPPnx5b/LSUadGq4/KW5b /czrkfN/ENLxue9v8w3zT+Z3y+wN0RVUbOGm7f4au5rm0t9bjTWKo/bQgVjk7LjO U1BsI0hWv/eFgIXWNx0bHlCxKA+sHrjC4g2Gt+KzyNKATNJ0ypmrRgaIhz2POeMC o60n6KquP4aXBIsfSmkUYDC9C3AHjbGinI0tULNaKQGfBQjBVTUAcg+XedxTApna ZJ89B5P6epCTv8OzJvPBouGeq0O1wA2TDtjLXkiNCGH4z97onpVvI6SK/I3YXJoD /YCpTT9FXP7AuEGaqLR8krfJblQZqcdAHsO4fmr6JhERkMtBkO/CyTQ38U9T9MQB +K1ee8rnd6lxMlOzJ9Y9jM1nOFazXGhSGw2ACoeklXh4UH8KSmlLHBcjI0L/c7GU oxQIqNVjs9nN8oV+YfKd1z9ZTrmUdBBExofCuo4oZPMU6Tp47TGBoyUz1bsWo4fO fpwtARQvcJGHrwno3SagYRjrl4w2rz4wGbK3s+FxK5A5w+OazwDnsyPqTNbGp5ak OrMJt72/14JSs2/AqcdVDp2ihl1f3Z81hG5/MV7dgvtHUfCgzds= =Oea2 -END PGP SIGNATURE-
Re: Upcoming Qt switch to OpenGL ES on arm64
> On Nov 22, 2018, at 10:30 PM, Marcin Juszkiewicz > wrote: > > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze: > >> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES >> support. At the moment we are building it with OpenGL ES on armel and armhf, >> and with desktop OpenGL on all other architectures. >> >> However we have received a request [1] from two different persons to add >> arm64 >> to the list of architectures where OpenGL ES is used. >> >> We want your feedback! If you are using an arm64 device or board with Qt, >> please let us know your opinion about this change, by replying to this mail >> or to [1], and describe your use case. > > Does it mean that arm64 box with PCI Express graphics card will be not > able to use Qt based software? I can put Radeon or NVidia card into my > box and use it as a normal OpenGL accelerated desktop (did that already > few years ago). Correct. After this switch, Qt on arm64 will be forced into embedded mode when it comes to graphics. Not sure whether it’s the right decision to be made. Might be an idea to ask more users on their opinions on this issue. Granted, I don’t really know what the real world distribution of embedded and desktop/server/laptop devices of arm64 is. But I could imagine that there will be more arm64 devices in the future which are desktops, servers or laptops. Adrian
Re: Uncoordinated upload of the rustified librsvg
rch any, otherwise librsvg >> would already been uninstallable in Debian Ports. So, this is just >> pure luck. Please don't make such statements when you're not aware of >> the differences between Debian's release and ports architectures. > > Good to know, and sorry to hear that. Another reason why it doesn't seem > particularly unreasonable to focus on release architectures, and treat > others as "best effort". Sure, I'm not arguing that. However, we still have the problem that we have multiple architectures in Debian that Debian considers release architectures which Rust upstream considers tier II only. >>> Speaking with an upstream Rust hat on in addition to a >>> Debian hat: what could Rust do to make life easier for porters? >> >> Please provide an actual stable version of the Rust compiler that >> is supported in the long term and can be shipped by enterprise >> distributions. > > There's a stable version of the compiler every six weeks. Pick one and > ship it. > > If, instead of "stable", you mean "supported on other architectures", > that's going to require upstream infrastructure to *test* those > architectures on a regular basis. With stable I mean that I can assume that Rust 1.X compiles the same code as Rust 1.Y. I accept that Rust upstream thinks that this is a viable model of developing the language and compiler, but I don't think this is compatible with most downstream distributions and users. Distributions, unless they are rolling release, usually evolve much slower. And the more you are shifting into the enterprise field, the slower that speed is to the point that you have distributions like RHEL or SLES which support their software for well beyond 10 years. >>> And what could Debian's *considerable* expertise in porting do to make that >>> more >>> sustainable upstream? (As an example, it might help if upstream Rust >>> folks had access to machines for more architectures, though that's a >>> side issue for having an LLVM port in the first place.) >> >> Debian Ports has worked closely with QEMU upstream to help make significant >> improvements to that emulator. So, in most cases, Rust developers can just >> use QEMU for the first porting efforts. But there are also porterboxes >> available >> from gcc to which we from Debian Ports also have provided hardware, for >> example: > > I'm more suggesting that if people want to see an architecture better > supported, it needs to end up in at least tier 2 on > https://forge.rust-lang.org/platform-support.html . Yes, I'm aware of the tier model. I just think upstream should keep more invasive changes for a 2.x version and not rewrite half of the compiler every six weeks. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Uncoordinated upload of the rustified librsvg
rchitectures? There are open reviews for LLVM, for example: > https://reviews.llvm.org/D50784 > https://reviews.llvm.org/D50856 > https://reviews.llvm.org/D50858 And a bug in Rust: > https://github.com/rust-lang/rust/issues/49773 > Speaking with an upstream Rust hat on in addition to a > Debian hat: what could Rust do to make life easier for porters? Please provide an actual stable version of the Rust compiler that is supported in the long term and can be shipped by enterprise distributions. > And what could Debian's *considerable* expertise in porting do to make that > more > sustainable upstream? (As an example, it might help if upstream Rust > folks had access to machines for more architectures, though that's a > side issue for having an LLVM port in the first place.) Debian Ports has worked closely with QEMU upstream to help make significant improvements to that emulator. So, in most cases, Rust developers can just use QEMU for the first porting efforts. But there are also porterboxes available from gcc to which we from Debian Ports also have provided hardware, for example: > https://gcc.gnu.org/wiki/CompileFarm Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Uncoordinated upload of the rustified librsvg
On 11/6/18 11:51 AM, Holger Levsen wrote: > please get of your high horse. > > I'm not sure it is said anywhere that one has to care about ports and/or > some pet projects. This isn't about caring about ports, this is about being respectful to each other. > Also, you wrote a mail to d-d-a that rust is now running on 14 archs, so > I was utterly surprised about your mail a few hours later blaming > someone who uploaded a rust library. I am blaming them for an *uncoordinated* upload. > That said, I do understand your frustration and I do applause your work > on "strange" ports, I also bootstrapped the Rust compiler and helped fixing issues on armel, mips, mipsel, mips64el. Those are "strange" ports for you? Ok. > however, most of us are here to have Debian running > nicely on hardware used by the 99%, and if those two objectives are > getting in each others way, I'm not sure you have moral or practical > grounds to demand that we priotize your 1% needs over those of the 99%. Well, if it wasn't for me, we'd probably be shipping the 2.40-version of librsrv in Debian Buster and Firefox would be missing on a couple of release architectures.. But I guess the phrase "Thank you" doesn't exist in Debian anymore. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Uncoordinated upload of the rustified librsvg
>> Why would I need to communicate that? > Because coordination needs involvement from all If the maintainer of a package doesn't understand which reverse dependencies his package has, he shouldn't be the maintainer of his package. I don't understand why you are defending his behavior. It's simply not nice to pull such a stunt after I put in all these efforts to help others. If you think it is, then the CoCs we have aren't worth the "paper" they are written on. FWIW, I am not subscribed to debian-devel, please keep me CC'ed. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
