Bug#1071380: RM: r-cran-randomfields -- ROM; Package removed from CRAN
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: r-cran-randomfie...@packages.debian.org, debia...@lists.debian.org, 1071...@bugs.debian.org Control: affects -1 + src:r-cran-randomfields User: ftp.debian@packages.debian.org Usertags: remove Hi ftpmasters, this package was removed from CRAN. Since we want to reduce the maintenance effort of R pkg team this package should not be maintained in Debian any more. Kind regards Andreas.
Bug#1071379: RM: r-cran-randomfields -- ROM; Package removed from CRAN
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: r-cran-randomfie...@packages.debian.org, debia...@lists.debian.org, 1071...@bugs.debian.org Control: affects -1 + src:r-cran-randomfields User: ftp.debian@packages.debian.org Usertags: remove Hi ftpmasters, this package was removed from CRAN. Since we want to reduce the maintenance effort of R pkg team this package should not be maintained in Debian any more. Kind regards Andreas.
Bug#1071358: r-cran-rgeos: FTBFS: geos.c:102:13: error: format not a string literal and no format arguments
Control: block -1 by 1071375 thanks Hi Santiago, Am Fri, May 17, 2024 at 10:41:36PM +0200 schrieb Santiago Vila: > Package: src:r-cran-rgeos > Version: 0.6-4-2 > Severity: serious > Tags: ftbfs thanks a lot for your QA effort. It turns out that the package is not maintained at CRAN any more. To reduce the maintenance effort of the R pkg team this package will be removed from Debian (see bug #1071375). Kind regards Andreas. -- https://fam-tille.de
Bug#1071376: RM: r-cran-randomfieldsutils -- ROM; Package removed from CRAN
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: r-cran-randomfieldsut...@packages.debian.org, debia...@lists.debian.org Control: affects -1 + src:r-cran-randomfieldsutils User: ftp.debian@packages.debian.org Usertags: remove Hi ftpmasters, this package was removed from CRAN. Since we want to reduce the maintenance effort of R pkg team this package should not be maintained in Debian any more. Kind regards Andreas.
Bug#1071375: RM: r-cran-rgeos -- ROM; Removed from CRAN, just remove maintenance burden of R pkg team
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: r-cran-rg...@packages.debian.org, debia...@lists.debian.org Control: affects -1 + src:r-cran-rgeos User: ftp.debian@packages.debian.org Usertags: remove Hi ftpmasters, this package was removed from CRAN and there is no point in distributing it in Debian any more. Please remove it from the ftpmirrors. Kind regards Andreas.
Bug#1070839: r-cran-data.table: autopkgtest regression on i386
Control: tags -1 upstream Control: forwarded -1 https://github.com/Rdatatable/data.table/issues/6133
Bug#1070839: [Help] Re: Bug#1070839: r-cran-data.table: autopkgtest regression on i386
Control: tags -1 help Hi Graham, Am Fri, May 10, 2024 at 10:44:48AM + schrieb Graham Inggs: > Source: r-cran-data.table > Version: 1.15.4+dfsg-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: regression > > r-cran-data.table's autopkgtest has regressed on i386 [1]. I've > copied what I hope is the relevant part of the log below. > > Regards > Graham > > [1] https://ci.debian.net/packages/r/r-cran-data.table/testing/i386/ I need help for this package which seems to be urgent and is blocking some migrations. I will not be able to do anything on this bug before June. Maybe the most straightforward way to tackle this is to simply remove the one failing test? Anyone is kindly invited to work on this / contact upstream (or even remove the package and packages depending from it for i386 / 32bit architectures). The package is team maintained and everybody can do a team upload. Kind regards Andreas. -- https://fam-tille.de
Bug#1070723: bullseye-pu: package bart/0.6.00-3+deb11u1
Am Wed, May 08, 2024 at 01:18:44AM +0200 schrieb Santiago Vila: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: b...@packages.debian.org, sanv...@debian.org > Control: affects -1 + src:bart > > [ Reason ] > This upload fixes Bug #1026061 FTBFS randomly in bullseye. Thanks a lot Santiago for your great QA work Andreas. -- https://fam-tille.de
Bug#1070515: dipy: FTBFS with nocheck profile
Control: tags -1 help thanks Hi Grahamm Am Mon, May 06, 2024 at 02:08:25PM + schrieb Graham Inggs: > Source: dipy > Version: 1.8.0-2 > Severity: serious > Tags: ftbfs patch thanks a lot for the patch which looks perfectly sensible. Unfortunatly the build runs into a different error as you can see in Salsa CI[1]: === FAILURES === __ test_shore_fitting_no_constrain_e0 __ def test_shore_fitting_no_constrain_e0(): > asm = ShoreModel(data.gtab, radial_order=data.radial_order, zeta=data.zeta, lambdaN=data.lambdaN, lambdaL=data.lambdaL) E AttributeError: '_C' object has no attribute 'radial_order' dipy/reconst/tests/test_shore.py:70: AttributeError Any help would be welcome Andreas. [1] https://salsa.debian.org/med-team/dipy/-/pipelines/674858 -- https://fam-tille.de
Bug#1069370: shasta: FTBFS: dpkg-shlibdeps: error: cannot continue due to the error above
Control: tags -1 help Hi, I pushed some potential fix to Git but this does not help[1]. :-( Any idea is welcome Andreas. [1] https://salsa.debian.org/med-team/shasta/-/jobs/5695708 -- https://fam-tille.de
Bug#1070459: Tagging help
Control: tags -1 help thanks
Bug#1057562: Forwarded upstream (Was: gcr4: FTBFS: failing tests)
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gcr/-/issues/119 thanks Hi, this issue was reported upstream. I would have pointed the issue to the Debian BTS but for whatever reason my login is not accepted. Santiago, since you can provide VMs where the problem is reproducible which seems to be a problem for the reporter of the issue, would you also offer such a VM to gcr4 upstream? If yes, it would be cool to add this info to their bug tracker. In case this might be a problem for you and nobody else has a valid login I try to get a login tomorrow and will proxy this information. Kind regards Andreas. -- https://fam-tille.de
Bug#1070459: psortb: FTBFS: binding.c:52:13: error: implicit declaration of function ‘free’
Hi, I've fixed the original error in Git but Salsa CI shows another one[1] which is more tricky since it involves a header file for a perl module and I have no idea how to fix this. Any help from the team is welcome. Kind regards Andreas. [1] https://salsa.debian.org/med-team/psortb/-/jobs/5693162 -- https://fam-tille.de
Bug#1070243: dicomnifti 2.33.1-5: ROM; Obsolete
Hi, Am Thu, May 02, 2024 at 09:57:57PM +0200 schrieb Andreas Beckmann: > I assume you wanted to file a RM request for ftpmaster. I've reassigned and > retitled the bug accordingly. I've removed dicomnifti from the Debian Med tasks (med-imaging metapackage) thus the recommends will be dropped with the next release of the metapackages. Kind regards Andreas. -- https://fam-tille.de
Bug#1070009: r-cran-data.table: Update to current upstream
Hi Dirk,
thanks for the bug report. I even tried to upgrade to 1.15.0 in Februar
but stumbled about a test suite error[1] of the Debian package which
prevented me from uploading.
Am Sun, Apr 28, 2024 at 09:03:08AM -0500 schrieb Dirk Eddelbuettel:
>
> This should likely reduce some autopkgtest noise too in both data.table
> itself and some of the packages depending on it.
The autopkgtest of current version 1.15.4 has[2]:
> test.data.table() # runs the main test suite of 5,000+ tests in
> /inst/tests/tests.Rraw
getDTthreads(verbose=TRUE):
OpenMP version (_OPENMP) 201511
omp_get_num_procs()2
R_DATATABLE_NUM_PROCS_PERCENT unset (default 50)
R_DATATABLE_NUM_THREADSunset
R_DATATABLE_THROTTLE unset (default 1024)
omp_get_thread_limit() 2147483647
omp_get_max_threads() 2
OMP_THREAD_LIMIT unset
OMP_NUM_THREADSunset
RestoreAfterFork true
data.table is using 1 threads with throttle==1024. See ?setDTthreads.
test.data.table() running:
/usr/lib/R/site-library/data.table/tests/tests.Rraw.bz2
Test 2194.7 produced 0 errors but expected 1
Expected: Internal error.*types or lengths incorrect
Observed:
Tue Apr 30 05:47:51 2024 endian==little, sizeof(long double)==16,
longdouble.digits==64, sizeof(pointer)==8, TZ==unset,
Sys.timezone()=='Etc/UTC', Sys.getlocale()=='C', l10n_info()=='MBCS=FALSE;
UTF-8=FALSE; Latin-1=FALSE; codeset=ANSI_X3.4-1968', getDTthreads()=='OpenMP
version (_OPENMP)==201511; omp_get_num_procs()==2;
R_DATATABLE_NUM_PROCS_PERCENT==unset (default 50);
R_DATATABLE_NUM_THREADS==unset; R_DATATABLE_THROTTLE==unset (default 1024);
omp_get_thread_limit()==2147483647; omp_get_max_threads()==2;
OMP_THREAD_LIMIT==unset; OMP_NUM_THREADS==unset; RestoreAfterFork==true;
data.table is using 1 threads with throttle==1024. See ?setDTthreads.',
zlibVersion()==1.3 ZLIB_VERSION==1.3
Error: 1 error(s) out of 11067. Search tests/tests.Rraw.bz2 for test number(s)
2194.7. Duration: 42.5s elapsed (41.9s cpu).
In addition: Warning message:
In readLines(testDir("issue_563_fread.txt")) :
invalid input found on input connection
'/usr/lib/R/site-library/data.table/tests/issue_563_fread.txt'
Execution halted
I've checked the two files
/usr/lib/R/site-library/data.table/tests/tests.Rraw.bz2
/usr/lib/R/site-library/data.table/tests/issue_563_fread.txt
which do not look suspicious in any way.
Any hint how to fix this test would be welcome.
Kind regards
Andreas.
[1] https://salsa.debian.org/r-pkg-team/r-cran-data.table/-/jobs/5291564
[2] https://salsa.debian.org/r-pkg-team/r-cran-data.table/-/jobs/5660288
--
https://fam-tille.de
Bug#1065810: Correction: New appointments for the Debian Technical Committee: csmall
Dear fellow developers, sorry, the list of CTTE members in my last mail contained Simon McVittie but his term has ended already. Thanks to Simon for his previous work and here comes the corrected text (with no change but the correct list of members). As defined by our constitution (§6.2.2), the Debian Technical Committee has recommended the appointment to the committee of: * Craig Small I agree with their recommendation, and hereby appoint Craig as member of the Technical Committee, effective immediately. For reference, the nominations and votes are recorded at: https://bugs.debian.org/1065810 The Technical Committee now consists of: * Sean Whitton (chair) * Christoph Berg * Helmut Grohne * Matthew Vernon * Matthew Garrett * Stefano Rivera * Timo Röhling * Craig Small Task Description: The Technical Committee is established by the Debian Constitution, section 6. It is the body which makes the final decision on technical disputes in the Debian project. More info about the Technical Committee, including recent decisions, discussion and advice, may be found at: https://www.debian.org/devel/tech-ctte The previous CTTE Appointment mail can be found at: https://lists.debian.org/debian-devel-announce/2023/07/msg0.html Thanks to everyone on the committee who dedicate their time and skills towards Debian as well as good luck for Craig for the new position! Andreas, Debian Project Leader signature.asc Description: PGP signature
Bug#1065810: New appointments for the Debian Technical Committee: csmall
Dear fellow developers, As defined by our constitution (§6.2.2), the Debian Technical Committee has recommended the appointment to the committee of: * Craig Small I agree with their recommendation, and hereby appoint Craig as member of the Technical Committee, effective immediately. For reference, the nominations and votes are recorded at: https://bugs.debian.org/1065810 The Technical Committee now consists of: * Sean Whitton (chair) * Simon McVittie * Christoph Berg * Helmut Grohne * Matthew Vernon * Matthew Garrett * Stefano Rivera * Timo Röhling * Craig Small Task Description: The Technical Committee is established by the Debian Constitution, section 6. It is the body which makes the final decision on technical disputes in the Debian project. More info about the Technical Committee, including recent decisions, discussion and advice, may be found at: https://www.debian.org/devel/tech-ctte The previous CTTE Appointment mail can be found at: https://lists.debian.org/debian-devel-announce/2023/07/msg0.html Thanks to everyone on the committee who dedicate their time and skills towards Debian as well as good luck for Craig for the new position! Andreas, Debian Project Leader signature.asc Description: PGP signature
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Hi Sean, Am Fri, Apr 26, 2024 at 10:53:41AM +0100 schrieb Sean Whitton: > > Possibly I need to send some delegation mail like this[1]? > > It's an appointment, not a delegation, but yes something like that mail. So something I could copy-n-paste from https://lists.debian.org/debian-devel-announce/2023/07/msg0.html adding Craig Small on top? I'm about to go AFK for traveling until today evening. If you consider it urgent and it should be different from that text, some draft I could send out would be welcome. Looking forward to see you in Busan Andreas. -- https://fam-tille.de
Bug#1069876: libsbml: autopkgtest regression
Hi, Am Fri, Apr 26, 2024 at 09:27:55AM +0200 schrieb Sebastian Ramacher: > 95s autopkgtest [21:29:51]: test autodep8-python3: [--- > 95s Testing with python3.12: Short note: If I understood upstream correctly they currently support Python3.11 only. In any case they support only *one* Python3 version at the same time. It might be sensible to reach out to upstream for an update but that's currently out of my scope. Kind regards Andreas. -- https://fam-tille.de
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Hi Craig, Am Fri, Apr 26, 2024 at 08:12:02AM +1000 schrieb Craig Small: > Hi Andreas, > Congratulations on your appointment, hopefully you can find a way to > balance work, life and DPL because it seems like a very busy role. Thank you vor the congratulations and your empathy. > Not sure if Sean/the TC have reached out yet but in your first DPL email > you mentioned checking on the various teams to see what they need you to > do, here's one thing. > > No idea what the administrative stuff Sean is talking about, I guess I'll > find out soon. Possibly I need to send some delegation mail like this[1]? Since I'm now in contact with CTTE I'd like to start here: I currently don't have any questions for your team. Like previous DPLs, I'm open to any inquiries or requests for assistance. I personally prefer public discussions whenever possible, as they can benefit a wider audience. You can find a list of contact options at the bottom of my page on people.d.o[2]. I prefer being offline when I'm away from my keyboard, so I don't carry a phone. In urgent situations, I can provide the number of my dumb phone, though it may not always be within reach. Feel free to ping me if I don't respond promptly to ensure I address your concerns. Please let me know whether I can do something for you. I'm fine joining your IRC channel for the next couple of hous but I'll be offline later today. Hopefully see you in Busan Andreas. [1] https://lists.debian.org/debian-devel-announce/2023/07/msg0.html [2] https://people.debian.org/~tille/ > > On Sat, 13 Apr 2024 at 13:47, Sean Whitton wrote: > > > Ping again. Thanks. > > > > On Thu 28 Mar 2024 at 01:33pm +08, Sean Whitton wrote: > > > > > Hello, > > > > > > On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote: > > > > > >> The vote has concluded. The result is that the Technical Committee > > >> recommends that Craig Small be appointed by the Debian Project > > >> Leader to the Technical Committee. > > >> > > >> Jonathan, over to you. > > > > > > Quick ping about this. The appointment holds up some administrative > > > stuff for us. Thanks. > > > > -- > > Sean Whitton > > -- https://fam-tille.de
Bug#1024889: Pending
Control: tags -1 pending Control: block -1 by 1064596 thanks Pplacer needs to be build against the old version of MCL which is featuring some OCAML patch. This old version was just uploaded to new. Kind regards Andreas. -- https://fam-tille.de
Bug#1069745: magics-python: wrong arch: any packaging builds potentially uninstallable packages
Hi Alastair, Am Thu, Apr 25, 2024 at 08:33:58AM +0100 schrieb Alastair McKinstry: > Yes, thanks for this. You are perfectly welcome. Its relieving to work in a cooperative team (compared to my experiences in DPT). ;-) > I'm moving all packages I have in science-team to Science Maintainers. That's fine and even helps making your packages covered by some Blends tools. In case I might stumble upon a package of yours that is not yet maintained by Science Maintainers I take this as a sign I can safely do so when I feel some other work on this package is needed. Kind regards Andreas. > regards > > Alastair > > On 24/04/2024 07:23, Andreas Tille wrote: > > Control: tags -1 pending > > thanks > > > > Hi Alastair, > > > > as far as I learned in past example cases its rather by chance that > > you did not set > > > > Maintainer: Debian Science Maintainers > > > > > > in packages that are residing in science-team space on Salsa. I took > > the freedom to fix this in Git as well as applying the patch for this > > bug + routine-update (doing several tiny polishing changes). > > > > I hope you don't mind if I'll upload those changes this evening. > > > > Kind regards and thanks for maintaining this package in Debian Science > > team > > Andreas. > > > -- > Alastair McKinstry, > GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 > e: mckins...@debian.org, im: @alastair:mckinstry.ie > > -- https://fam-tille.de
Bug#1069509: r-cran-metamix: FTBFS on armhf: tests fail
Hi Lucas, thanks a lot for all your work on rebuilding the archive on different architectures. That's really appreciated. In this specific case I wonder whether your build host has simply trouble initialising MPI given I find strings like MPI_ERRORS_ARE_FATAL Kind regards Andreas. Am Sat, Apr 20, 2024 at 03:14:31PM +0200 schrieb Lucas Nussbaum: > Source: r-cran-metamix > Version: 0.3-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on armhf. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>/src' > > make[1]: Leaving directory '/<>/src' > > installing to > > /<>/debian/r-cran-metamix/usr/lib/R/site-library/00LOCK-r-cran-metamix-0.3/00new/metaMix/libs > > ** R > > ** data > > *** moving datasets to lazyload DB > > ** inst > > ** byte-compile and prepare package for lazy loading > > -- > > Sorry! You were supposed to get help about: > > pmix_init:startup:internal-failure > > But I couldn't open the help file: > > /usr/share/pmix/help-pmix-runtime.txt: No such file or directory. > > Sorry! > > -- > > [ip-10-84-234-19:2164897] PMIX ERROR: NOT-FOUND in file > > ../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c > > at line 237 > > [ip-10-84-234-19:2164891] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to > > start a daemon on the local node in file > > ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 716 > > [ip-10-84-234-19:2164891] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to > > start a daemon on the local node in file > > ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at line 172 > > -- > > It looks like orte_init failed for some reason; your parallel process is > > likely to abort. There are many reasons that a parallel process can > > fail during orte_init; some of which are due to configuration or > > environment problems. This failure appears to be an internal failure; > > here's some additional information (which may only be relevant to an > > Open MPI developer): > > > > orte_ess_init failed > > --> Returned value Unable to start a daemon on the local node (-127) > > instead of ORTE_SUCCESS > > -- > > -- > > It looks like MPI_INIT failed for some reason; your parallel process is > > likely to abort. There are many reasons that a parallel process can > > fail during MPI_INIT; some of which are due to configuration or environment > > problems. This failure appears to be an internal failure; here's some > > additional information (which may only be relevant to an Open MPI > > developer): > > > > ompi_mpi_init: ompi_rte_init failed > > --> Returned "Unable to start a daemon on the local node" (-127) instead > > of "Success" (0) > > -- > > *** An error occurred in MPI_Init > > *** on a NULL communicator > > *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, > > ***and potentially your MPI job) > > [ip-10-84-234-19:2164891] Local abort before MPI_INIT completed completed > > successfully, but am not able to aggregate error messages, and not able to > > guarantee that all other processes were killed! > > ERROR: lazy loading failed for package ‘metaMix’ > > * removing > > ‘/<>/debian/r-cran-metamix/usr/lib/R/site-library/metaMix’ > > dh_auto_install: error: R CMD INSTALL -l > > /<>/debian/r-cran-metamix/usr/lib/R/site-library --clean . > > "--built-timestamp='Sat, 21 Mar 2020 14:53:15 +0100'" returned exit code 1 > > make: *** [debian/rules:4: binary] Error 25 > > > The full build log is available from: > http://qa-logs.debian.net/2024/04/20/r-cran-metamix_0.3-2_unstable-armhf.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240420=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. > >
Bug#1055847: Please check python-sparse issue at Github
Hi Diane and Ghislain, you are listed as Uploaders of python-sparse. Since I now have other tasks than maintaining team maintained packages I would be really happy if you could subscribe upstream issue https://github.com/pydata/sparse/issues/628 and continue what I have started. Thanks a lot Andreas. -- https://fam-tille.de
Bug#1069745: magics-python: wrong arch: any packaging builds potentially uninstallable packages
Control: tags -1 pending thanks Hi Alastair, as far as I learned in past example cases its rather by chance that you did not set Maintainer: Debian Science Maintainers in packages that are residing in science-team space on Salsa. I took the freedom to fix this in Git as well as applying the patch for this bug + routine-update (doing several tiny polishing changes). I hope you don't mind if I'll upload those changes this evening. Kind regards and thanks for maintaining this package in Debian Science team Andreas. -- https://fam-tille.de
Bug#1068314: python-inflate64_1.0.0+ds-1_amd64.changes REJECTED
Hi Hiroshi, Am Wed, Apr 24, 2024 at 01:14:27AM +0900 schrieb yokota: > > please also mention Ma Lin in your debian/copyright. Thanks for fixing this issue. I've uploaded to new again. > I was updated Debian salsa repository to fix the issue. > https://salsa.debian.org/python-team/packages/python-inflate64 Remarks to your changes: As long as the package is not in unstable please stick to Debian revision "-1". Thus I cleaned up the changelog. Some words about tagging: I removed all debian/* tags in Git - please make sure you delete them in your clone as well. Please do not tag the state you push to Salsa. Tagging is something that should happen for the state which will be really uploaded to Debian. If the package is in new we can't be sure it will move to unstable. I'd do this only *after* the package is accepted. Also if you need a sponsor for your packages the tagging should be done by the sponsor. The rationale is that the sponsor might see some need for further changes which need to be incorporated into the tag. At least this is what I know from all teams I'm working in. > Please upload it as Debian package by Debian Python Team because I > don't have upload rights. Done. Thanks again for all your work Andreas. -- https://fam-tille.de
Bug#1033028: fixed in pydata-sphinx-theme 0.15.2-1
Hi Gianfranco, Am Tue, Apr 23, 2024 at 08:52:56PM +0200 schrieb Gianfranco Costamagna: > control: notfixed -1 0.15.2-1 > control: reopen -1 > Hello Andreas, I tried to upload your package, Not really "my" package - I used "QA upload". > but I failed due to some nodejs failures. > Looks like the new theme-switcher is running some npm install during build, > failing due to network access... > > Any idea? Sorry, absolutely not. I admit I do not really remember. There must have been some reason why I finally did not upload. In addition to having no good idea I also have no spare time any more now due to my new task. > In the meanwhile I reuploaded 0.7 version in sid. Thanks a lot. If I where you I would seek advise on DPT list. Kind regards and thanks for keeping me informed Andreas. -- https://fam-tille.de
Bug#1065222: O: pychm -- Python binding for CHMLIB - Python 3
Hi, Am Tue, Apr 23, 2024 at 09:02:41AM +0900 schrieb yokota: > Debian pychm was updated. Good job. > I can't upload the new package because I don't have upload rights. > Please upload the new package by someone in debian-python who has upload > rights. In case you might become Debian Maintainer we could grant you upload permissions for the packages you are maintaining. Kind regards Andreas. -- https://fam-tille.de
Bug#922907: Does anybody intent to adopt openmx -- nano-scale material simulations
Hi, since openmx is listed on the list of blockers for t64 transition and long time orphaned I wonder whether it is better to remove the package from Debian. According popcon its usage has basically zero votes[2] (which might be caused by the fact that it was not included into the last two stable releases. It would be nice if some volunteer would care for this package which had a new upstream version in 2021 (so is not completely orphaned upstream). Otherwise it probably makes sense to remove the package from Debian. Kind regards Andreas. [1] https://lists.debian.org/debian-devel/2024/04/msg00331.html [2] https://qa.debian.org/popcon-graph.php?packages=openmx_vote=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1 -- https://fam-tille.de
Bug#1012893: Status of the t64 transition
Hi Sebastian, thank you for your work on t64 transition. Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: I've spotted these Debian Med packages. > gentle > jellyfish > quorum > sbmltoolbox No idea how we can help here. Please let us know if we can do something. > anfo We like to fix gcc-12 issues (#1012893) in anfo but so far nobody managed to do so since it seems to be quite complex. If we are blocking progress with this package its probably a sign that it should be removed from Debian. > blasr We try to work on #1067374. > freebayes Upstream is working on bug #1067271. > vg This package is in a bad state in any case and we are aware of this. However, could you explain in how far is this affecting t64 transition since 32bit architectures are excluded? > If you maintain any of the packages above, please check their status and > help get them fixed. Any help in filing bugs, fixing packages, > requesting removals, etc. is appreciated so that we can look into > unblocking the whole stack and migrate it to testing. I fixed two packages of Debian Python Team and pinged about some packages in Debian Science Team. Kind regards Andreas. -- https://fam-tille.de
Bug#1069098: emboss: all executables segfault on s390x
Hi Andrius, I'd recommend following the procedure you supposed in https://lists.debian.org/debian-med/2024/04/msg00034.html Someone needs to file removal requests for s390x for the rdepends from emboss, thought. Kind regards Andreas. -- https://fam-tille.de
Bug#1069122: RM: sambamba [armhf i386] -- ROM; Does not build on 32bit architectures any more
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: samba...@packages.debian.org, 1067...@bugs.debian.org Control: affects -1 + src:sambamba User: ftp.debian@packages.debian.org Usertags: remove Hi, sambamba does not build on i386 architectures any more and also has no practical relevance on those architectures use case wise. I'll upload it Build-Depending from architecture-is-64-bit, architecture-is-little-endian soon to reflect this fact. Kind regards Andreas.
Bug#1066334: Redefinition of _Int (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
H again,
Am Sun, Apr 14, 2024 at 07:17:41AM +0200 schrieb Andreas Tille:
> Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden:
> >
> > The one after this looks like a GTK problem, and that's the point at
> > which I bow out.
I was able to fix some more missing declaration issues (which luckily did
not were connected to GTK) but I'm now stumbling upon:
...
In file included from disknew.c:85:
../whooks/systags.h:57:15: error: expected identifier before numeric constant
57 | #define _Int 24
| ^~
../wh/acetypes.h:36:16: note: in expansion of macro '_Int'
36 | typedef enum { _Int, _Text, _Float, _DateType, _Key, _Tag } AceType;
|^~~~
...
which is caused by whooks/systags.h[2]
...
#define _Int 24
#define _Unsigned 25
#define _Long 26 /* not supported */
#define _Long_Unsigned 27 /* not supported */
#define _Float 28
...
Is there any trick I could use here instead of replacing these
definitions by something else like _Int_acedb or so globally to get this
build by modern compilers?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/acedb/-/jobs/5586407#L1893
[2]
https://salsa.debian.org/med-team/acedb/-/blob/master/whooks/systags.h?ref_type=heads#L57-61
--
https://fam-tille.de
Bug#1066334: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
Hi Jeremy, Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden: > > The one after this looks like a GTK problem, and that's the point at > which I bow out. Thanks a lot for your help so far. Your patches are pushed to Git. Kind regards Andreas. -- https://fam-tille.de
Bug#1066334: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
Control: tags -1 help thanks Hi, while I was able to fix the origininal cause of the failure I'm now blocked by some issue that cython seems to miss adding some #include but I have no idea how to accomplish this. The Salsa CI build log[1] says: ... y.tab.c: In function 'yyparse': y.tab.c:1409:16: error: implicit declaration of function 'yylex' [-Werror=implicit-function-declaration] y.tab.c:2185:7: error: implicit declaration of function 'yyerror'; did you mean 'YYerror'? [-Werror=implicit-function-declaration] In file included from aqlparse.y:335: aqlparse.l: In function 'yylex': ... Any help would be welcome Andreas. [1] https://salsa.debian.org/med-team/acedb/-/jobs/5580840 -- https://fam-tille.de
Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker: > I like that solution since I believe there are 64-bit platforms where long > is 32-bits. I've updated my development version thus: > > // > // timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP doesn't > yet have support > // for long long which is a problem on platforms where long is less > than 8 bytes. > // > #if SIZEOF_LONG < 8 > double seconds = timeValue.tv_sec; > #else > long seconds = timeValue.tv_sec; > #endif > mpz_class nanoSeconds(seconds); Sounds like some working solution. It would help if you could tag a new released to enable us fetching a fresh tarball incorporatinig this change. > Of course I expect to drop support for 32-bit before 2038 - certainly when > one our dependencies drops support. But I've gotten a bug report for > building Maude on a Raspberry Pi. Raspian is based on Debian and if the 32bit ARM architectures fail here Raspian people have a problem. Kind regards Andreas. -- https://fam-tille.de
Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, I'd suggest to set Build-Depends: architecture-is-64-bit, architecture-is-little-endian and remove 32bit architectures of maude. Kind regards Andreas. -- https://fam-tille.de
Bug#1065221: O: py7zr -- pure Python 7-zip library
Hi Hiroshi, Am Mon, Apr 08, 2024 at 08:34:23AM +0900 schrieb yokota: > > When writing this I'm wondering whether it might be better to remove > > this in Files-Excluded. On one hand this saves us from mentioning the > > copyright on the other hand we could be really sure that it is not used. > > What do you think - should I override the previous upload without that > > code copy? I did not wanted to be too invasive with your packaging > > but I would have done so in my packages. > > Thanks for your suggestion. > I was dropped embedded library code from brotlicffi I commited a change to d/changelog. In case ftpmaster might accept what currently is in new queue we need to mention this. Alternatively I could push the new version to new since as far as I know ftpmaster can cope with this. However, I do not see any urgent need for this. We can rather upload your change in the source-only upload after the package might have been accepted. In case it will not be accepted we can change d/changelog accordingly. > and pyzstd, and push > them to salsa.debian.org repository. > > I was also fix some copyright issues. Fine. I've uploaded python-pyppmd and python-pyzstd to new. Please read my commit logs for python-pyzstd. Thanks a lot for all your work and ping here on this list if you need further sponsoring help. Kind regards Andreas. -- https://fam-tille.de
Bug#1068561: ITS: argtable2
Hi Shachar, Am Sun, Apr 07, 2024 at 02:39:24PM +0300 schrieb Shachar Shemesh: > > Go ahead. I'm swamped beyond words. You can take formal ownership, if you > like. Thanks a lot and sorry if my further mails might have offended you due the fingerpointing. I think I've learned that for future cases. Kind regards Andreas. > Shachar > > > On 07/04/2024 12:46, Andreas Tille wrote: > > Source: argtable2 > Version: 13-1.1 > Severity: important > X-Debbugs-Cc: Shachar Shemesh , Debian Med Packaging > Team , 1066...@bugs.debian.org, > m...@qa.debian.org > > Hi, > > on behalf of the Debian Med team I intend to salvage[1] this package > since the > following criteria from Wiki[2] are met > > There is no visible activity regarding the package for six months > A previous NMU was not acknowledged, and a bug justifying another NMU > is pending for one month > The last upload was an NMU and there was no maintainer upload within > one year > Bugs exist for more than one major missing upstream version (bug > #1066377) > > I have prepared the package I intend to upload inside the Debian Med > team space > > https://salsa.debian.org/med-team/argtable2 > > The rationale to move this package into Debian Med team is that it > affects a tree of dependencies in this team which maintains clustalo > that depends from libargtable2-dev. > > Kind regards >Andreas. > > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > [2] https://wiki.debian.org/PackageSalvaging > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (50, > 'buildd-unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > -- https://fam-tille.de
Bug#1068576: tar: Please provide autopkgtest
Source: tar
Version: 1.35+dfsg-3
Severity: wishlist
Hi,
I used
$ PGPASSWORD="udd-mirror" psql --port=5432 --host=udd-mirror.debian.net
--username=udd-mirror udd < 1000
ORDER BY vote DESC, source
LIMIT 5;
EOT
source| vote | maintainer
| vcs_url
| tags
-+++-+--
debconf | 217976 | Debconf Developers
|
https://salsa.debian.org/pkg-debconf/debconf.git|
{uitoolkit::ncurses,interface::x11,uitoolkit::TODO,uitoolkit::gtk,uitoolkit::qt}
zlib| 217757 | Mark Brown
|
|
tar | 216067 | Janos Lenart
| https://salsa.debian.org/debian/tar.git
|
sysvinit| 214097 | Debian sysvinit maintainers
|
https://salsa.debian.org/debian/sysvinit.git|
libgcrypt20 | 212538 | Debian GnuTLS Maintainers
|
https://salsa.debian.org/gnutls-team/libgcrypt.git -b branch1.6 |
to find out what most popular packages in Debian are not featuring some
autopkgtest. Since I somehow considered tar some feasible target to
write such a test I tweaked the build time test to hopefully work as
autopkgtest. I succeeded in my local chroot. To make sure it will
really work reliably I created a branch in Git[1] where I added this
test. My hope was an additional verification that it works in CI - but
this failed[2]. I admit I'm a bit clueless about
1. Why this test fails in Salsa CI while it succeeds locally
2. Whether this kind of test is really sensible since it includes
some automake created header files I have stolen from amd64
build[3] which definitely is a hack that might break for
a) upgrades
b) other architectures
3. Whether we might consider a more simple test just as starting
point.
Thus I did not created a MR and do not tag this bug patch leaving it for
further discussion. If you prefer I should rather fork your git
repository on Salsa and discuss things in some MR I'm fine with removing
that said branch. I just don't know your prefered way of communication
in your small packaging team.
Thanks a lot for maintaining tar
Andreas.
[1] https://salsa.debian.org/debian/tar/-/tree/autopkgtest?ref_type=heads
[2] https://salsa.debian.org/debian/tar/-/jobs/5494107
[3]
https://salsa.debian.org/debian/tar/-/blob/autopkgtest/debian/tests/headers.tar.xz?ref_type=heads
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1065221: O: py7zr -- pure Python 7-zip library
Hi again, Am Sun, Apr 07, 2024 at 11:54:00AM +0900 schrieb yokota: > Hello, > > I think these packages are now ready for upload to NEW queue. > Please examine them. > > https://salsa.debian.org/python-team/packages/python-brotlicffi See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#47 where I forgot to CC Debian Python list. > https://salsa.debian.org/python-team/packages/python-inflate64 Uploaded as well. I had to strip d/changelog and fixed the spelling of "python" in description. Please verify this for the next two packages. I've also spotted third party code which was not mentioned in d/copyright. I'd recommend to do some grep -Ri copyright in your source tree to have a rough information about code that is possibly missing in d/copyright. Otherwise the package will be rejected by ftpmaster. > https://salsa.debian.org/python-team/packages/python-pyppmd > https://salsa.debian.org/python-team/packages/python-pyzstd Thanks a lot for your work in any case Andreas. -- https://fam-tille.de
Bug#1068561: ITS: argtable2
Source: argtable2 Version: 13-1.1 Severity: important X-Debbugs-Cc: Shachar Shemesh , Debian Med Packaging Team , 1066...@bugs.debian.org, m...@qa.debian.org Hi, on behalf of the Debian Med team I intend to salvage[1] this package since the following criteria from Wiki[2] are met There is no visible activity regarding the package for six months A previous NMU was not acknowledged, and a bug justifying another NMU is pending for one month The last upload was an NMU and there was no maintainer upload within one year Bugs exist for more than one major missing upstream version (bug #1066377) I have prepared the package I intend to upload inside the Debian Med team space https://salsa.debian.org/med-team/argtable2 The rationale to move this package into Debian Med team is that it affects a tree of dependencies in this team which maintains clustalo that depends from libargtable2-dev. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://wiki.debian.org/PackageSalvaging -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1065221: O: py7zr -- pure Python 7-zip library
Hi, Am Sun, Apr 07, 2024 at 11:54:00AM +0900 schrieb yokota: > Hello, > > I think these packages are now ready for upload to NEW queue. > Please examine them. > > https://salsa.debian.org/python-team/packages/python-brotlicffi Uploaded. Please note that the clean process failed in my pbuilder chroot without adding pybuild-plugin-pyproject to Build-Depends. I also fixed the d/copyright file in two aspects: 1. lintian claimed missing copyright statement since the line starting with Copyright: had only blanks 2. The code copy of libbrotli was not mentioned. When writing this I'm wondering whether it might be better to remove this in Files-Excluded. On one hand this saves us from mentioning the copyright on the other hand we could be really sure that it is not used. What do you think - should I override the previous upload without that code copy? I did not wanted to be too invasive with your packaging but I would have done so in my packages. Kind regards Andreas. > https://salsa.debian.org/python-team/packages/python-inflate64 > https://salsa.debian.org/python-team/packages/python-pyppmd > https://salsa.debian.org/python-team/packages/python-pyzstd > > -- > YOKOTA Hiroshi > -- https://fam-tille.de
Bug#1065222: Adopting pychm (Was: Packaging multivolumefile?)
Hi Hiroshi, Am Sat, Apr 06, 2024 at 02:51:51AM +0900 schrieb yokota: > Thanks a lot for your detailed document. You are welcome. > I will try to fixup other packages. Just ping me once done. > PS: > If py7zr is done, I will also try package pychm to use for Debian > Calibre package. > Please sponsor me for pychm package if you have time. I'll try in any case. It should be some change of maintainer + close bug and - as I'd recommend - some routine-update -f away. Just let me know once you are ready Andreas. > > O: pychm -- Python binding for CHMLIB - Python 3 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065222 > > -- > YOKOTA Hiroshi > -- https://fam-tille.de
Bug#1065221: Packaging multivolumefile?
Hi Yokota, Am Tue, Apr 02, 2024 at 08:39:36PM +0200 schrieb Andreas Tille: > > Nevermind, YOKOTA Hiroshi already has done this and more and is looking > > for sponsors. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#17 > > Thanks a lot for your packaging work. My very personal sponsoring > policy is that I sponsor only team maintained packages. If you move > your packages to DPT I'll happily sponsor your work. Thanks a lot for all your work on the said pre-requisites and moving them to DPT. For the moment I've picked python-multivolumefile and python-bcj and uploaded them to New queue. My sponsoring style is to do additional commits trying to be as verbose as possible to tell the sponsee what to change and why. I hope you like this. When looking at these two packages I've noticed a pattern of changes that were needed to fix lintian info messages. Please make sure to run lintian -I PACKAGE_VERSION_amd64.changes to learn about what changes might be sensible to silence lintian. Some of them where cosmetic but I try to fix these to make sure the lintian output is not too noisy and I might miss something that might really need fixing. I'd also recommend: $ grep -v ^# ~/.lintianrc color=always display-info=yes I hope my commits are sensible to you - if not please ask back. As a general remark: In those teams I'm more involved we have the tradition that sponsees leave the distribution in d/changelog to UNRELEASED while the sponsor changes this to unstable before the final upload. This helps team members to immediately know about the status. I'd be happy if you would follow this as well. Please verify that your other packages are fixing the things I commited to the two example packages. If time permits I'd happily sponsor you other packages (if nobody else in the team will beat me in doing so). Thanks again for all your work Andreas. -- https://fam-tille.de
Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)
Hi Sascha, Am Thu, Apr 04, 2024 at 10:33:16PM +0200 schrieb Sascha Steinbiss: > Interesting to see that there is no ltrsift-examples package indeed. But > I must have had my reasons back then... > > Anyway, to be honest I don't see much long-term future for LTRsift. I am > actually surprised to see it still in Debian and not dropped out of > testing as it depends on GTK2, which I assumed was gone from Debian > already [0, 1]. I guess GTK2 will not be supported after the next release any more (at best). As long as no RC bugs are filed against packages depending from it, it seems fine to keep these in a clean shape. > I'd be happy with introducing an examples package but I don't think > there is going to be a usable autopkgtest to gain, sorry. Thanks for the clarification. I'll leave this absolutely to you. Given your explanation I do not think it is worth a detour via new queue. Thus I reverted my change to introduce the examples package. I'll leave you the final decision and upload (where you can drop the "Team upload" in changelog to silence lintian). > I have pushed some changes and can upload soon. Thanks a lot Andreas. > [0] Apparently not, but it's dead upstream: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947713 > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967603 -- https://fam-tille.de
Bug#1065339: src:r-cran-rstanarm: FTBFS on mips64el and risc64
Control: retitle -1 src:r-cran-rstanarm: FTBFS on mips64el and risc64
Control: reopen -1
Control: tags -1 upstream
Control: forwarded -1 https://github.com/stan-dev/rstanarm/issues/619
thanks
As per autobuilders log[1] the package fails to build on mips64el and risc64
with
...
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG -I"../inst/include"
-I"/usr/lib/R/site-library/StanHeaders/include/src" -DBOOST_DISABLE_ASSERTS
-DEIGEN_NO_DEBUG -DBOOST_MATH_OVERFLOW_ERROR_POLICY=errno_on_error -DUSE_STANC3
-D_HAS_AUTO_PTR_ETC=0 -I'/usr/lib/R/site-library/StanHeaders/include'
-I'/usr/lib/R/site-library/rstan/include'
-I'/usr/lib/R/site-library/BH/include' -I'/usr/lib/R/site-library/Rcpp/include'
-I'/usr/lib/R/site-library/RcppEigen/include'
-I'/usr/lib/R/site-library/RcppParallel/include'-I/usr/include
-DTBB_INTERFACE_NEW -I'/usr/lib/R/site-library/RcppParallel/include'
-D_REENTRANT -DSTAN_THREADS -DTBB_INTERFACE_NEW-fpic -g -O2
-ffile-prefix-map=/<>/r-base-4.3.2=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c
stan_files/count.cc -o stan_files/count.o
In file included from
/usr/include/boost/math/special_functions/detail/bessel_jy.hpp:14,
from /usr/include/boost/math/special_functions/bessel.hpp:20,
from
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun/bessel_first_kind.hpp:6,
from
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun.hpp:31,
from
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim.hpp:14,
from
/usr/lib/R/site-library/StanHeaders/include/src/stan/io/dump.hpp:7,
from
/usr/lib/R/site-library/rstan/include/rstan/stan_fit.hpp:43,
from
/usr/lib/R/site-library/rstan/include/rstan/rstaninc.hpp:4,
from stan_files/count.hpp:18,
from stan_files/count.cc:3:
/usr/include/boost/math/special_functions/gamma.hpp: In instantiation of
‘boost::math::detail::upper_incomplete_gamma_fract::result_type
boost::math::detail::upper_incomplete_gamma_fract::operator()() [with T =
double; result_type = std::pair]’:
/usr/include/boost/math/tools/fraction.hpp:217:20: required from ‘typename
boost::math::tools::detail::fraction_traits::result_type
boost::math::tools::continued_fraction_a(Gen&, const U&, uintmax_t&) [with Gen
= boost::math::detail::upper_incomplete_gamma_fract; U = double;
typename detail::fraction_traits::result_type = double; uintmax_t = long
unsigned int]’
/usr/include/boost/math/tools/fraction.hpp:252:31: required from ‘typename
boost::math::tools::detail::fraction_traits::result_type
boost::math::tools::continued_fraction_a(Gen&, const U&) [with Gen =
boost::math::detail::upper_incomplete_gamma_fract; U = double; typename
detail::fraction_traits::result_type = double]’
/usr/include/boost/math/special_functions/gamma.hpp:314:68: required from ‘T
boost::math::detail::upper_gamma_fraction(T, T, T) [with T = double]’
/usr/include/boost/math/special_functions/gamma.hpp:1176:44: required from ‘T
boost::math::detail::gamma_incomplete_imp(T, T, bool, bool, const Policy&, T*)
[with T = double; Policy =
boost::math::policies::policy,
boost::math::policies::promote_float,
boost::math::policies::promote_double,
boost::math::policies::default_policy, boost::math::policies::default_policy,
boost::math::policies::default_policy, boost::math::policies::default_policy,
boost::math::policies::default_policy, boost::math::policies::default_policy,
boost::math::policies::default_policy, boost::math::policies::default_policy,
boost::math::policies::default_policy, boost::math::policies::default_policy>]’
/usr/include/boost/math/special_functions/gamma.hpp:2130:35: required from
‘boost::math::tools::promote_args_t boost::math::gamma_p(RT1, RT2,
const Policy&) [with RT1 = double; RT2 = double; Policy =
policies::policy,
policies::pole_error,
policies::promote_double, policies::digits2<0>,
policies::default_policy, policies::default_policy, policies::default_policy,
policies::default_policy, policies::default_policy, policies::default_policy,
policies::default_policy, policies::default_policy, policies::default_policy>;
tools::promote_args_t = double]’
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun/gamma_p.hpp:76:30:
required from here
/usr/include/boost/math/special_functions/gamma.hpp:299:16: note: the ABI for
returning a value with C++17 empty bases but otherwise an aggregate with only
one or two floating-point fields was changed in GCC 12.1
299 |result_type operator()()
|^~~~
"/usr/lib/R/bin/Rscript" -e "source(file.path('..', 'tools', 'make_cc.R'));
make_cc(commandArgs(TRUE))" stan_files/jm.stan
code for methods in class "Rcpp_model_base" was not checked for suspicious
field assignments (recommended package 'codetools' not available?)
code for methods in class
Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)
Control: tags -1 pending thanks Hi Sascha, after routine-update dh_missing failed due to compat level 13 which defaults to fail if some files are not installed. This made me aware that upstream in principle installs a test suite we could use for an autopkgtest. I also realised that you once added debian/ltrsift-examples.examples - so you probably had such a package in mind. Since I have no idea what reasons you had not to use this file I'll leave the final decision to you. (Please note: Somehow a copy of ltrsift_code ends up in the examples dir - I did not yet investigated why this is happening. Before I have no clear picture about your intentions I'll left this for later investigation.) Kind regards Andreas. -- https://fam-tille.de
Bug#1068341: bioawk: FTBFS randomly due to Makefile bug: cp: cannot create regular file 'ytab.c': File exists
Hi Santiago, Am Wed, Apr 03, 2024 at 10:58:07PM +0200 schrieb Santiago Vila: > Hi. I've just realized that (as a member of Debian Med) > I could fix this myself. > > Nilesh: Would it help if I do a "team upload" to fix this? > (Using the proposed patch) > > Or would you prefer to fix it yourself? I'm not Nilesh but its usual practice in our team that team uploads are fine since those who usually care for a package can concentrate on other things. >From my point of view just go for it ... and BTW, thanks for all your QA work Andreas. -- https://fam-tille.de
Bug#1065221: Packaging multivolumefile?
Hi Yokota, Am Sat, Mar 30, 2024 at 06:31:54PM +0100 schrieb Andreas Metzler: > On 2024-03-30 Andreas Metzler wrote: > > I originally intended to file an ITP, but it probably makes more sense > > to ask here: > > > py7zr >= 0.16.0 requires multivolumefile by the same author. How about > > packaging it under the debian-python umbrella? > > Nevermind, YOKOTA Hiroshi already has done this and more and is looking > for sponsors. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#17 Thanks a lot for your packaging work. My very personal sponsoring policy is that I sponsor only team maintained packages. If you move your packages to DPT I'll happily sponsor your work. Kind regards Andreas. -- https://fam-tille.de
Bug#1034805: Upgrading fis-gtm and closing CVE-2021-44496 CVE-2021-44504
Ping? Am Sat, Dec 09, 2023 at 06:13:24PM +0100 schrieb Andreas Tille: > Hi Amul, > > I realised that fis-gtm is lagging behind upstream some versions and the > Debian packaged fis-gtm is featuring CVE-2021-44496 and CVE-2021-44504. > It would be great if you could upgrade the Debian package to the latest > upstream version. > > Kind regards, > Andreas. > > -- > http://fam-tille.de > > -- https://fam-tille.de
Bug#1068164: bart: please add support for loong64
Hi Martin, can you please comment on this? Kind regards Andreas. Am Mon, Apr 01, 2024 at 01:22:03AM + schrieb wuruilong: > Source: bart > Severity: normal > User: debian-loonga...@lists.debian.org > Usertags: loong64 > X-Debbugs-Cc: wuruil...@loongson.cn > > Dear Maintainer, > > bart failed to compile on loongarch, the attachment fixes the bug > > wuruilong > > -- System Information: > Debian Release: trixie/sid > APT prefers unreleased > APT policy: (500, 'unreleased'), (500, 'unstable') > Architecture: loong64 (loongarch64) > > Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads) > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: unable to detect > --- bart-0.9.00/debian/rules 2024-03-30 06:12:54.235656645 + > +++ bart-0.9.00/debian/rules 2023-12-11 17:42:37.0 + > @@ -12,7 +12,7 @@ > export PARALLEL_NJOBS=1 > > # some archs require turning of some optimizations > -NOEXPOPT_ARCHS=arm64 ppc64el s390x ia64 powerpc ppc64 riscv64 loong64 > +NOEXPOPT_ARCHS=arm64 ppc64el s390x ia64 powerpc ppc64 riscv64 > > # turn off hanging tests on i386 > ifeq ($(DEB_BUILD_ARCH), i386) > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- https://fam-tille.de
Bug#1043686: Please provide a proper download location for beads
Ping? Am Thu, Jan 25, 2024 at 12:46:17PM +0100 schrieb Andreas Tille: > Hi Filippo, > > I intended to have a look at bug #1043686 noticing that beads is > shipping a copy of cimg (which is packaged and should probably be > excluded from upstream source in favour of the packaged code). > When checking the download locations mentioned in d/watch I realised > that the last two packaged versions are not available for download. > > It would be great if you could point the watch file to some place > where the latest tags could be found. > > Kind regards > Andras. > > -- > http://fam-tille.de > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > -- https://fam-tille.de
Bug#1067959: sambamba: FTBFS on armhf (supported compiler issue)
Hi, Am Fri, Mar 29, 2024 at 10:32:25PM +0900 schrieb Kentaro HAYASHI: > sambamba fails to build on armhf. Thanks a lot for this bug report. I'd recommend to drop 32bit architectures for this package. Kind regards Andreas. > FYI: > > https://buildd.debian.org/status/fetch.php?pkg=sambamba=armhf=1.0.1%2Bdfsg-1=1699230688=0 > > Regards, -- https://fam-tille.de
Bug#1065199: RM: pprintpp -- ROM; leaf package
Hi ftpmasters, Am Thu, Mar 28, 2024 at 11:55:24AM +0100 schrieb Alexandre Detiste: > > > > ? #1065199 RM: pprintpp -- ROM; leaf package > > Do we need this package? > It looks dead upstream & was a trivial utility, let's drop it. For the package pprintpp there is consens that this can be removed. Kind regards Andreas. -- https://fam-tille.de
Bug#1067098: mpl-sphinx-theme: please make the build reproducible
Control: tags -1 pending thanks Hi Vagrant, sorry about your work was lost. I confirm the new upstream version in Git contains the patch. Unfortunately it needs new dependencies. If it might help you I could upload your NMU again. Kind regards Andreas. -- https://fam-tille.de
Bug#790235: basemap: [PATCH] please make the build reproducible
Control: tags -1 - patch thanks Hi, I applied the suggested patch in basemap (1.2.2+dfsg-4) but according to Salsa CI[1] the package does not build reprducibly yet. Since bug #827361 that might have affected this bug is closed I removed the tag patch. Any further suggestions how to make basemap building reproducible are welcome. Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/basemap/-/jobs/5502164 -- https://fam-tille.de
Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi Emanuele. Am Tue, Mar 19, 2024 at 12:16:16PM +0100 schrieb Emanuele Rocca: > I've uploaded a NMU to DELAYED/2: https://bugs.debian.org/1067147 Thanks a lot for your attempt to help. In principle we have a team wide low threshold NMU - so undelayed NMUs are fine. The kind of race condition in uploads might imply that some ping in advance might be helpful to avoid duplicated work. > With those changes dcmtk builds fine on both armel and armhf. I've > dropped the graphviz build-depend on those arches too, it can of course > be reintroduced once graphviz become installable again. Meanwhile your patch is imported and was uploaded by Michael - thanks to all who helped solving this. Kind regards Andreas. -- http://fam-tille.de
Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi again, sorry, I did not checked the situation. Am Tue, Mar 19, 2024 at 10:34:13AM +0100 schrieb Andreas Tille: > Testing removals are happening automatically if some RC bug exists > for a certain time without pinging. Just writing some additional > information to the bug in question would have prevented this but > nobody of us had sufficient capacity. That's a shame but will be > healed over time (which is hopefully not that long). Since you all pinged that bug we now have another 4 weeks of time before anything gets removed from testing. So we just need to bear the noise from testing removal warnings of quite some packages (which I'd love to get rid of thus uploading a fix would be great). Kind regards Andreas. -- http://fam-tille.de
Bug#1066146: #1066146 RM: flask-basicauth (Re: morph's abandoned packages (list))
Hi Carsten, sorry for occupying your time such a long and detailed answer. I simply had seen a conflict in your I see no real issues to drop This horse is long dead which was surely simply a typo. I personally agree with the dead horse. I'm CCing your long explanation to the bug to make sure it has finally some positive use. Kind regards Andreas. Am Tue, Mar 19, 2024 at 07:06:18AM +0100 schrieb Carsten Schoenert: > Hello Andreas, > > Am 18.03.24 um 21:15 schrieb Andreas Tille: > > Hi Carsten, > > > > Am Sun, Mar 17, 2024 at 08:18:58AM +0100 schrieb Carsten Schoenert: > > > > The arguments to remove flask-basicauth looks sensible, can someone > > > > confirm ? > > > > > > looking at the upstream situation for flask-basicauth I see no real issues > > > to drop and this package from the archive. This horse is long dead for a > > > long time. > > > > This sentence looks as if would have been created by autocomplete function. > > Could you please try to rephrase for better understandability? > > well, it's getting harder to maintain upstream source that is simply not > maintained anymore by the original upstream author or group. flask-basicauth > is one of these cases. The last action by upstream is now 8 years old! > > https://github.com/jpvanhal/flask-basicauth > > There is no feedback from upstream on bug reports since years. I'm writing > bug reports in such cases sometimes mainly only to show the problems we or I > have discovered in a hope that other will post than how they solved this > issue. > > And of course also upstream is not reacting on created PRs. I've given up to > write new and further PRs in such cases, it's a waste of time. > > Doing the needed maintenance for such old repositories is often difficult > and time consuming, e.g. dealing with old build systems or the test setup. > I'm primarily a package maintainer not a person that is having fun to update > or adjust old trees with a 5th possible solution. It's not helpful and wise > if every distro is doing the same with lots of energy. It's not our > responsibility to keep every source package alive in the archive if upstream > has moved away, at least this is my thinking. > > We have more and more the problem to manage big transitions like the usual > Python major updates, or big frameworks like Sphinx, PyTest, Django etc. > I've spend a lot of time with rather old and not really maintained anymore > by upstream packages in the past year. > We can't deal with all the challenges that will need some action all other > the time. But shipping then outdated or not really useful packages within a > release is not something we should do. Sometimes it's better to drop such > packages from the archive and shift time and energy to other packages. > > And to me flask-basicauth is such a package. It's dead Jim! > > -- > Regards > Carsten > > -- http://fam-tille.de
Bug#1060736: Would you agree with swapping Maintainer and Uploaders in eric?
Control: tags -1 pending thanks Hi again, since I know you from Debian Science team and you are usually comfortable with setting Maintainer to the team I've done so besides fixing the bug and polished the package a bit. I also upgraded to the latest upstream version. Please confirm that this all is OK before I upload (feel free to upload yourself which is perfectly fine for me). Kind regards Andreas. Am Mon, Mar 11, 2024 at 10:13:50PM +0100 schrieb Andreas Tille: > Hi Gudjon, > > in case you agree with the suggested change of policy discussed on the > debian-python mailing list[1] would you agree to set DPT as maintainer? > If yes, I'd volunteer to do this, fix bug #1065855 and #1060736. > > Kind regards and thanks for working on this package > Andreas. > > > [1] https://lists.debian.org/debian-python/2024/02/msg00052.html > > -- > http://fam-tille.de -- http://fam-tille.de
Bug#1063980: Mark affected test xfail and reduce bug severity + report upstream
Control: tags -1 important Control: tags -1 upstream Control: forwarded -1 https://github.com/jnothman/UpSetPlot/issues/273 thanks Hi, I've checked the new upstream version of python-upsetplot which shows the same problem. Thus I marked the one affected test xfail and reported the problem upstream. Since the package builds again now and is passing its autopkgtest I reduced the severity of the bug from serious to important. Kind regards Andreas. -- http://fam-tille.de
Bug#1066409: Reassign nodejs and merge bug (Was: Linker fails to find libraries in unstable but succeeds in testing)
Control: reassign -1 nodejs Control: forcemerge 1066399 -1 thanks Hi Jochen, Am Fri, Mar 15, 2024 at 08:46:11AM +0100 schrieb Jochen Sprickerhof: > > I guess that's the same as #1066399. > > libnode-dev: > libv8.so -> libnode.so > libnode.so -> libnode.so.108t64 > > But libnode.so.108t64 does not exist Thanks a lot for the hint. Reassigning and merging accordingly. Kind regards Andreas. -- http://fam-tille.de
Bug#1066409: Linker fails to find libraries in unstable but succeeds in testing
Hi, thanks to the next round of Lucas' FTBFS QA rebuilds (at least) one package of the R pkg team is affected by some strange linker issue #1066409 r-cran-v8: FTBFS: ld: cannot find -lv8: No such file or directory which boils down to[1] g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR /usr/bin/ld: cannot find -lv8: No such file or directory /usr/bin/ld: cannot find -lv8_libplatform: No such file or directory The Build-Depends libnode-dev provides both libraries and when I try to build the package under testing all is fine. Is there any linker issue involved that might be introduced in unstable? Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-v8/-/jobs/5446089 -- http://fam-tille.de
Bug#1066409: [Help] Re: Bug#1066409: r-cran-v8: FTBFS: ld: cannot find -lv8: No such file or directory
Control: tags -1 help Control: tags -1 confirmed Hi, Am Wed, Mar 13, 2024 at 01:05:16PM +0100 schrieb Lucas Nussbaum: > > Using PKG_LIBS=-lv8 -lv8_libplatform > > Running feature test for pointer compression... > > /usr/bin/ld: cannot find -lv8: No such file or directory > > /usr/bin/ld: cannot find -lv8_libplatform: No such file or directory I can confirm this problem also for the latest upstream version (which is not astonishing since nothing in this line has changed) as you can see on Salsa CI https://salsa.debian.org/r-pkg-team/r-cran-v8/-/jobs/5446089 I have to admit I have no idea why suddenly the perfectly available libraries are not found by the linker any more. The linker call g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR looks perfectly fine, was not changed and the libraries /usr/lib/x86_64-linux-gnu/libv8_libplatform.so /usr/lib/x86_64-linux-gnu/libv8.so are provided by libnode-dev inside the chroot as I verified. Interestingly the package builds fine on my local system which is running testing. Remark to Leopold: As I wrote in my "Action needed for R-pkg Uploaders"-mail I would be happy if you would pronounce whether you are up for maintaining this package actively or not. You are mentioned as only Uploader but the changelog says: $ grep '^ --' debian/changelog -- Andreas Tille Fri, 22 Dec 2023 10:19:13 +0100 -- Andreas Tille Fri, 22 Dec 2023 10:12:23 +0100 -- Andreas Tille Mon, 16 Oct 2023 16:47:36 +0200 -- Andreas Tille Fri, 21 Jul 2023 17:26:16 +0200 -- Andreas Tille Tue, 04 Jul 2023 09:07:03 +0200 -- Andreas Tille Thu, 29 Jun 2023 14:58:21 +0200 -- Andreas Tille Tue, 15 Nov 2022 19:39:16 +0100 -- Andreas Tille Thu, 11 Aug 2022 16:19:43 +0200 -- Jérémy Lal Sun, 17 Jul 2022 17:49:15 +0200 -- Andreas Tille Tue, 24 May 2022 11:25:24 +0200 -- Andreas Tille Wed, 16 Feb 2022 10:45:42 +0100 -- Andreas Tille Sun, 15 Aug 2021 13:51:20 +0200 -- Andreas Tille Mon, 09 Nov 2020 12:50:36 +0100 -- Dylan Aïssi Tue, 30 Jun 2020 10:18:56 +0200 -- Jérémy Lal Sun, 14 Jun 2020 21:31:12 +0200 -- Dylan Aïssi Wed, 03 Jun 2020 08:57:25 +0200 -- Dylan Aïssi Fri, 20 Mar 2020 12:03:25 +0100 -- Andreas Tille Thu, 23 Jan 2020 21:23:32 +0100 -- Dylan Aïssi Sat, 11 Jan 2020 08:30:40 +0100 -- Dylan Aïssi Thu, 18 Jul 2019 21:14:49 +0200 -- Dylan Aïssi Thu, 07 Feb 2019 07:43:35 +0100 -- Dylan Aïssi Sun, 03 Feb 2019 13:46:40 +0100 -- Andreas Tille Thu, 21 Jun 2018 17:34:03 +0200 -- Andreas Tille Wed, 25 Oct 2017 09:28:11 +0200 -- Leopold Palomo-Avellaneda Tue, 21 Mar 2017 12:17:40 +0100 It was great you introduced the package into Debian. Thanks fro doing so. However, please be verbose whether you have the capacity to keep on maintaining it or not. Kind regards Andreas. [1] https://lists.debian.org/debian-r/2024/03/msg0.html -- http://fam-tille.de
Bug#1018336: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy]
Hi Miriam, Am Thu, Mar 14, 2024 at 08:33:13PM +0100 schrieb Miriam Ruiz: > I am totally okay with team maintenance. Lots of thanks!!! Updated to latest upstream which fixes the bug. Thanks a lot for your quick response Andreas. -- http://fam-tille.de
Bug#1018336: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy]
Hi Miriam, gentle ping about this. I remember for cycle and pcalendar you was fine with team maintenance. So I assume in this case you are as well. If we do not hear from you in the next two weeks we will assume agreement. Kind regards Andreas. - Weitergeleitete Nachricht von Andreas Tille - Date: Tue, 27 Feb 2024 14:48:21 +0100 From: Andreas Tille To: Miriam Ruiz Subject: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy] Hi Miriam, as you can read below I doubt that the situation in several packages is the interpretation of "weak" team maintenance if the Maintainer field is set to a person. In the case of your package deap I would guess you are OK if I would swap these fields in a potential upload of the new upstream version (which might potentially fix #1018336 deap: build-depends on python3-nose or uses it for autopkgtest ) Would you mind if I would do so? Kind regards Andreas. - Weitergeleitete Nachricht von Andreas Tille - Date: Tue, 27 Feb 2024 09:05:44 +0100 From: Andreas Tille To: Debian Python Subject: Suggesting change in DPT policy Hi, I became more deeply involved into DPT since 2022 as a consequence of the suggestion for transfering several Debian Med/Science packages to DPMT[1][2]. I happily followed this suggestion and moved >30 packages from the Blends teams to DPT. I was happy with this move since it makes sense. Recently we received lots of testing removal warnings in those Blends teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So I did what I usually do in those teams: I dedicated quite some time in team wide bug hunting. That way I squashed about 50 bugs on packages where I was not in Uploaders. When doing so I usually run routine-update on the package which basically streamlines packaging to latest standards including calling Janitor tools which are so far accepted inside DPT. I probably should have reviewed the DPT policy on Maintainership[3] more carefully. In other teams, it's common for the Maintainer to be set to the team, so I assumed it was just an oversight when I made this change[4] when touching the package to fix RC bug #1058177. However, I I was pointed immediately about the fact that I was mistaken according to the current DPT policy. I apologize for this. However, the wording of the comment on my commit was discouraging, especially considering I was a volunteer who had fixed a critical bug. Because of this, I decided to focus my efforts on fixing other critical bugs for the moment. If the comment had started with a 'Thanks for fixing the critical bug, but...' I likely would have corrected my mistake quickly. The lack of respect from my teammate simply made me prioritize my time on other issues that are more visible to our users. I wonder whether I should propose another change to the policy about maintaining a kind and polite language inside the team - but that's a different thing. While I applied the patch for another RC bug (#1063443) after >2 weeks which triggered a RC bug in reportbug I remembered the "keep the maintainer" policy. But I kept on doing Janitor like changes since finally the package is maintained in a team where Janitor is accepted. When doing so I failed the phrase "please contact the Maintainer for the green light." I apoligize for this again. The response was another volunteer-demotivating private mail (thus no quote) which also was lacking the "Thanks for fixing"-phrase and degrading my changes as "frivolous". So far what happened (seen from my possibly biased perspective). Why do I like to change the policy? The current wording provides some means to stop volunteer team members helping out moving forward to speed up migrations and fix Debian wide dependencies. It hides team maintained packages from a common BTS view. When pointing my browser to https://bugs.debian.org/team+pyt...@tracker.debian.org I currently see 1339 open bugs (calculated by [UDD1]). This hides another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work around this flaw I used an UDD query to find relevant Python3.12 bugs. When I think twice about the wording Team in Uploaders is a weak statement of collaboration.[3] I personally consider it a statement of *no* collaboration (which fits the wording of the responses I've got). How can a team member for instance find another RC bug #1009424? Just from reading the bug report it is pretty easy to fix but does not feature any response in BTS. I came across this while looking into Cython 3.0 bugs. The same source package (basemap) that had the open Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug (#1009424) that stayed unattended for 22 months? We all know volunteers have limited time and I do not want to blame anybody in the team to not care promptly about RC bugs. But what else is the sense of a p
Bug#1064946: morph's abandoned packages (list)
Control: tags -1 moreinfo Hi, this package is team maintained. I have to assume its former maintainer has decided to leave the team. Please delay the removal until it is perfectly clear that no other team member intends to take over this package. Thank you for your work as ftpmaster Andreas. -- http://fam-tille.de
Bug#1066814: plotly: Please upgrade to latest upstream version
Hi Josue, Am Wed, Mar 13, 2024 at 06:19:05PM -0600 schrieb Josue Ortega: > > Hopefully, I'll be uploading the latest version next weekend. I've been quite > busy with $DAILY_JOB. Thank you for your quick response. As a volunteer your $DAILY_JOB has definitely preference. To cover such situations I recommend team maintenance which would enable team members to simply do some team upload. It might help you concentrating on other things if your available time is limited. Thank you for maintaining the package in any case Andreas. -- http://fam-tille.de
Bug#1059308: Tag bugs pending
Control: tags -1 pending I'm just marking these bugs pending for next upload. They were even closed in recent Debian package but since they are concerning CVEs it might be better to close these inside a changelog of next upload. Kind regards Andreas. -- http://fam-tille.de
Bug#1065908: multiqc: Please drop dependencies on python3-distutils
Control: tags -1 pending Hi, this bug is fixed in Git. Since I used the chance to upgrade to latest upstream which is blocked by a needed upgrade of plotly the upload will be delayed. Kind regards Andreas. -- http://fam-tille.de
Bug#1066814: plotly: Please upgrade to latest upstream version
Source: plotly Version: 5.15.0+dfsg1-1 Severity: normal Hi, I want to upgrade multiqc but this package requires a higher version of plotly as you can see in Salsa CI[1]. It would be great if you could upgrade the package. BTW, I would consider it a good idea if plotly would be maintained in the Debian Python Team. Kind regards Andreas. [1] https://salsa.debian.org/med-team/multiqc/-/jobs/5442252 -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=sh: 0: getcwd() failed: No such file or directory UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1065841: Taking over datalad to either Debian Med or Debian Science team
Hi Yaroslav, Am Tue, Mar 12, 2024 at 03:50:22PM -0400 schrieb Yaroslav Halchenko: > Let's keep DataLad under our (NeuroDebian) umbrella for now, since we > are also upstream there and project is active. We are also > working with Vasyl (CCed) to experiment with some semi-automation for > package updates/backports (for neurodebian) and datalad (and some of its > ecosystem) packages are the target. Packaging will be on salsa. We > might move them under larger Med or Science teams, but not just yet. That's perfectly fine and all I would like to see. No presure. > Re #1065841 specifically -- while trying to build updated package I > experienced some odd side-effect (pip started to try to install > tqdm) and didn't see immediate reason.I will see how well it goes on > debian infra after source only upload (did now). I perfectly trust you to maintain this package properly. I simply was querying this type of bug and thought datalad would nicely fit into Debian Science scope. Kind regards Andreas. -- http://fam-tille.de
Bug#1065759: Retitle libbio-samtools-perl: FTBFS on arm{el,hf}: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function ‘bam_sort_core’; did you mean ‘bam_format1_core’? [-Werror=implicit-fun
Control: retitle -1 libbio-samtools-perl: FTBFS: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function ‘bam_sort_core’; did you mean ‘bam_format1_core’? [-Werror=implicit-function-declaration] Control: tags -1 help thanks I can confirm that this bug also occures on amd64 thus removing the arm-restriction from the title. Unfortunately I have no idea how to fix this (except by possibly suppressing the -Werror=implicit-function-declaration option). Thus tagging 'help' Kind regards Andreas. -- http://fam-tille.de
Bug#1063376: Create bugs against ftp.debian.org to enable removal of 32bit architectures for all r-bioc-rhtslib rdepends
clone 1063379 -1 block 1063376 by -1 retitle -1 RM: r-bioc-ballgown [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -1 + src:r-bioc-ballgown clone 1063379 -2 block 1063376 by -2 retitle -2 RM: r-bioc-cner [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -2 + src:r-bioc-cner clone 1063379 -3 block 1063376 by -3 retitle -3 RM: r-bioc-biovizbase [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -3 + src:r-bioc-biovizbase clone 1063379 -4 block 1063376 by -4 retitle -4 RM: r-bioc-bsseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -4 + src:r-bioc-bsseq clone 1063379 -5 block 1063376 by -5 retitle -5 RM: r-bioc-cummerbund [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -5 + src:r-bioc-cummerbund clone 1063379 -6 block 1063376 by -6 retitle -6 RM: r-bioc-dada2 [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -6 + src:r-bioc-dada2 clone 1063379 -7 block 1063376 by -7 retitle -7 RM: r-bioc-dss [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -7 + src:r-bioc-dss clone 1063379 -8 block 1063376 by -8 retitle -8 RM: r-bioc-dexseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -8 + src:r-bioc-dexseq clone 1063379 -9 block 1063376 by -9 retitle -9 RM: r-bioc-degnorm [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -9 + src:r-bioc-degnorm clone 1063379 -10 block 1063376 by -10 retitle -10 RM: r-bioc-demixt [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -10 + src:r-bioc-demixt clone 1063379 -11 block 1063376 by -11 retitle -11 RM: r-bioc-genomicfiles [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -11 + src:r-bioc-genomicfiles clone 1063379 -12 block 1063376 by -12 retitle -12 RM: r-bioc-genelendatabase [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -12 + src:r-bioc-genelendatabase clone 1063379 -13 block 1063376 by -13 retitle -13 RM: r-bioc-goseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -13 + src:r-bioc-goseq clone 1063379 -14 block 1063376 by -14 retitle -14 RM: r-bioc-genomicfeatures [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -14 + src:r-bioc-genomicfeatures clone 1063379 -15 block 1063376 by -15 retitle -15 RM: r-bioc-edaseq [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -15 + src:r-bioc-edaseq clone 1063379 -16 block 1063376 by -16 retitle -16 RM: r-bioc-genomicalignments [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -16 + src:r-bioc-genomicalignments clone 1063379 -17 block 1063376 by -17 retitle -17 RM: r-bioc-ioniser [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -17 + src:r-bioc-ioniser clone 1063379 -18 block 1063376 by -18 retitle -18 RM: r-bioc-grohmm [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -18 + src:r-bioc-grohmm clone 1063379 -19 block 1063376 by -19 retitle -19 RM: r-bioc-isoformswitchanalyzer [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -19 + src:r-bioc-isoformswitchanalyzer clone 1063379 -20 block 1063376 by -20 retitle -20 RM: r-bioc-gviz [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -20 + src:r-bioc-gviz clone 1063379 -21 block 1063376 by -21 retitle -21 RM: r-bioc-organismdbi [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -21 + src:r-bioc-organismdbi clone 1063379 -22 block 1063376 by -22 retitle -22 RM: r-bioc-mutationalpatterns [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more affects -22 + src:r-bioc-mutationalpatterns clone 1063379 -23 block 1063376 by -23 retitle -23 RM: r-bioc-rgsepd [armel armhf i386 hppa m68k powerpc sh4] -- ROM;
Bug#1066085: q2cli: please make the build reproducible
Control: tags -1 pending Hi Chris, thanks a lot for your patch which I commited to Git. I did not uploaded yet since a general refresh of q2* packages is pending anyway. Kind regards Andreas. Am Tue, Mar 12, 2024 at 10:37:41AM + schrieb Chris Lamb: > --- a/debian/rules2024-03-12 10:05:22.980824959 + > --- b/debian/rules2024-03-12 10:34:47.399635439 + > @@ -21,6 +21,7 @@ > mkdir -p debian/$(DEB_SOURCE)/usr/share/bash-completion/completions > mv debian/$(DEB_SOURCE)/usr/bin/tab-qiime > debian/$(DEB_SOURCE)/usr/share/bash-completion/completions/qiime > chmod -x > debian/$(DEB_SOURCE)/usr/share/bash-completion/completions/qiime > + find debian/$(DEB_SOURCE) -type f -name parsl.log -delete > > debian/control: debian/control.in > echo "# This file is autogenerated from control.in to update versioned > dependencies" > $@ > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#1060736: Would you agree with swapping Maintainer and Uploaders in eric?
Hi Gudjon, in case you agree with the suggested change of policy discussed on the debian-python mailing list[1] would you agree to set DPT as maintainer? If yes, I'd volunteer to do this, fix bug #1065855 and #1060736. Kind regards and thanks for working on this package Andreas. [1] https://lists.debian.org/debian-python/2024/02/msg00052.html -- http://fam-tille.de
Bug#1065841: Taking over datalad to either Debian Med or Debian Science team
Hi Yaroslav, once we agreed that we should probably move all Neurodebian packages to Debian Med to make it accessible for a bigger team. I was not really active for some time in this attempt. However, bug #1065841 brought datalad on my screen. I would love to see it maintained on Salsa either in Debian Science team (since it has wider usage) or Debiam Med (since we moved Neurodebian packages there). I'd volunteer to do the move if you agree to and by doing so also fix the two open bugs and run some `routine-update` on the packaging. What do you think? Kind regards AndreasI'd volunteer to do the move if you agree to and by doing so also fix the two open bugs and run some `routine-update` on the packaging. What do you think? Kind regards Andreas. -- http://fam-tille.de
Bug#1063376: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
Hi, Am Mon, Mar 04, 2024 at 06:25:50PM + schrieb Thorsten Alteholz: > Control: tags -1 + moreinfo > > please file one RM bug for each package that needs to be partially removed. > This needs to be done even for dependencies of dependencies. > Please remove the moreinfo tag once that is done. As Thorsten wrote above[1] every single package needs its own bug to enable ftpmaster removing the binary packages of 32bit architectures for about 40 packages (currently affected by testing removals). I hope there is some better solution than sending single bug reports for those packages. If ftpmaster tooling really needs single bug reports I wonder how I can automatically create such bug reports with always the same text, just targeting at different binary packages. This also should include some means to work around the less than 5 bug reports per hour SPAM protection means of BTS. Any help would be welcome Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063376#23 -- http://fam-tille.de
Bug#1064921: src:r-cran-estimatr: fails to migrate to testing for too long: autopkgtest regression on i386
Control: tags -1 upstream Control: forwarded -1 https://github.com/DeclareDesign/estimatr/issues/407 Control: reopen -1 thanks I have forwarded this problem upstream. I've also reopened this bug to make sure it will show up on our sentinel Kind regards Andreas. -- http://fam-tille.de
Bug#1064922: src:r-cran-gbm: fails to migrate to testing for too long: autopkgtest regression
Control: tags -1 upstream Control: forwarded -1 https://github.com/gbm-developers/gbm/issues/78 Control: reopen -1 thanks I have forwarded this bug upstream. I've also re-opened the bug to make sure it appears on our list of bugs. -- http://fam-tille.de
Bug#1062371: Build-Dependencies from emboss-lib for bioperl-run and python-biopython (Was: reverse dependencie)
Control: block -1 by 1065782 Hi Thorsten, Am Mon, Mar 04, 2024 at 06:41:28PM + schrieb Thorsten Alteholz: > there are still reverse dependencies that need to be taken care of: > > Checking reverse dependencies... > # Broken Depends: > emboss: jemboss I think this is a false positive since jemboss is built from the emboss source. > emboss-explorer: emboss-explorer Bug filed. > # Broken Build-Depends: > bioperl-run: emboss This needs further investigation. > embassy-domainatrix: emboss-lib (6.6.1~ <) Fixed Build-Depends. > embassy-domalign: emboss-lib (6.6.1~ <) Fixed Build-Depends. > embassy-domsearch: emboss-lib (6.6.0-1~ >=) >emboss-lib (6.6.1~ <) Fixed Build-Depends. > python-biopython: emboss This needs further investigation. > In case they matter, this needs to be addressed first. Please remove the > moreinfo tag once that is done. Thanks for checking. Once bioperl-run and python-biopython is fixed we reset moreinfo. Kind regards Andreas. -- http://fam-tille.de
Bug#1065782: RM: emboss-explorer [armel armhf i386 hppa m68k powerpc sh4] -- ROM; emboss-lib does not support of 32 bit architectures any more
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: emboss-explo...@packages.debian.org, debian-med-packag...@lists.alioth.debian.org Control: affects -1 + src:emboss-explorer User: ftp.debian@packages.debian.org Usertags: remove Hi, as requested in the emboss-lib removal for 32-bit architectures for this package the 32bit architectures need to be removed as well. Kind regards and thanks a lot for your work as ftpmaster Andreas.
Bug#1065646: Additional information
Control: tags -1 pending Hi Vladimir, Am Fri, Mar 08, 2024 at 07:51:44PM +1300 schrieb Vladimir Petko: > Would it be possible to consider a merge request[1] that addresses this > issue? thanks a lot for the bug report and the patch. I accepted the MR. I intended to update the package at the same time to latest upstream but this failed building. As always in this cases I need to trust the Java insight of Pierre - thus the upload will be done once Pierre found the time he needs to decide whether it is sensible to work on the new ustream version or for the moment to the old one to get this bug fixed quickly. @Pierre: I've created branch 2.17.3 incorporating a few easy patch refreshes for the new version. I did not used master branch since I have no idea how hard this would be: Compiling with JDK Java compiler API. /build/igv-2.17.3+dfsg/src/test/java/org/broad/igv/ucsc/bb/BBFeatureSourceTest.java:102: error: Ignore is not a repeatable annotation type @Ignore ^ /build/igv-2.17.3+dfsg/src/test/java/org/broad/igv/ucsc/bb/BBFeatureSourceTest.java:203: error: Ignore is not a repeatable annotation type @Ignore ^ Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 2 errors :compileTestJava FAILED Kind regards Andreas. -- http://fam-tille.de
Bug#1065042: O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme Python library
Am Thu, Feb 29, 2024 at 02:06:25PM -0800 schrieb Vagrant Cascadian: > On 2024-02-29, Sandro Tosi wrote: > > I intend to orphan the mpl-sphinx-theme package. > > > > The package description is: > > This is the official Sphinx theme for Matplotlib documentation. It > > extends the > > pydata-sphinx-theme project, but adds custom styling and a navigation bar. > > . > > This package provides documentation for mpl-sphinx-theme > > It looks like you attempted to orphan it, but switched the Maintainer to > the python team rather than the Debian QA team ... It seems Sandro is trying to get rid of several of his packages. There are quite some Orphan bugs done by him in the last couple of days. > Was your intention to orphan it, or just leave it up to the python team? My gut feeling is that someone from the Python team would take over these packages. I will bounce the orphan messages from BTS to debian-python list to keep people informed about these packages. Kind regards Andreas. -- http://fam-tille.de
Bug#1064979: O: python-cryptography -- Python library exposing cryptographic recipes and primitives (documentation)
Hi, as per bug #1064979 python-cryptography was orphaned. Actually the process of orphaninig is defined differently[1] by setting QA team as maintainer. In this case DPT remains maintainer but there is no Uploader specified any more. I personally will not add my ID as Uploader. I have added those team members who did uploads in the last year in CC. I tried to do some bug squashing anyway. Since the latest version was requested in bug #1063771 and this new version also closes #1064778 (CVE-2024-26130) (the other CVE-bug should have been closed in previous upload) I decided to inject latest upstream, adapted the patches and pushed to Git. Unfortunately the package does not build as you can verify in Salsa CI[1]. I admit I have no clue how to fix this but I hope someone can take over from here. I guess uploading to experimental first and see how it plays nicely with its lots of rdepends makes sense here. Kind regards Andreas. PS: I would have expected that to orphan a team maintained package the team mailing list would have been CCed in the bug report. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package [2] https://salsa.debian.org/python-team/packages/python-cryptography/-/jobs/5381997 -- http://fam-tille.de
Bug#1064853: RM: r-bioc-rhtslib [armel armhf i386] -- ANAIS; No longer built
Control: merge -1 1063376 This is a duplicate of bug #1063376. Please note that you need to remove rdepends first. According bugs are filed and block by is set. It would help a lot if those ROM requests could be done soon to reduce noise of testing removal mails. Thanks a lot Andreas. Am Mon, Feb 26, 2024 at 06:35:41PM +0100 schrieb Sebastian Andrzej Siewior: > Package: ftp.debian.org > Control: affects -1 + src:r-bioc-rhtslib > X-Debbugs-Cc: r-bioc-rhts...@packages.debian.org > User: ftp.debian@packages.debian.org > Usertags: remove > Severity: normal > > Hi, > > starting with 2.4.1+dfsg-2 the r-bioc-rhtslib package no longer builds > for 32bit archs. The previously built 32bit packages prevents migration > to testing and debci tests fail for other packages, too. -- http://fam-tille.de
Bug#1064135: src:r-cran-bigmemory: fails to migrate to testing for too long: autopkgtest fails on arm*, ppc64el and s390x
Control: tags -1 upstream Control: forwarded -1 https://github.com/kaneplusplus/bigmemory/issues/115 Control: reopen -1 Thanks Bug was forwarded upstream with no response so far. Re-opening to stay aware that this bug exists. -- http://fam-tille.de
Bug#1064999: override: cs:utils/optional
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: python...@packages.debian.org, 832...@bugs.debian.org Control: affects -1 + src:python-cs User: ftp.debian@packages.debian.org Usertags: override The change was requested in bug #832202 and fixed in upload of 3.2.0-1. Kind regards, Andreas.
Bug#832202: cs: Section should not be “python”
Hi, the section issue is fixed in version 3.2.0. As stated in your report I did not closed this bug report. Kind regards Andreas. -- http://fam-tille.de
Bug#1026587: cerealizer: TypeError: __dict__ must be set to a dictionary, not a 'NoneType'
Control: tags -1 upstream Control: forwarded -1 j...@lesfleursdunormal.fr Hi Jean-Baptiste, the Debian packaged version of cerealizer recieved a bug report about a build failure TypeError: __dict__ must be set to a dictionary, not a 'NoneType' You can read the relevant part of the build log inside the bug report[1]. While this report is not about your latest upstream version (it is against version 0.8.1 which was the packaged version at the time of the bug report) I updated to version 0.8.3 in our packaging git. When running our CI test with the latest tools I get the same error unfortunately. You can find the full build log here: https://salsa.debian.org/python-team/packages/cerealizer/-/jobs/5375270 It would be great if you could find a fix for this issue. Kind regards Andreas. [1] https://bugs.debian.org/1026587 -- http://fam-tille.de
Bug#1064952: pypi2deb: Please set DPT as Maintainer and the ID of the person calling py2dsp as uploader
Package: pypi2deb
Version: 3.20230219
Severity: minor
Tags: patch
Hi,
in the discussion about team maintenance in DPT weepingclown raised the
point[1] that py2dsp creates an initial packaging with team in uploaders
section. The discussion seems to indicate that the favourite application
of py2deb is creating packages that are using
Maintainer: Debian Python Team
+Uploaders: {{maintainer}}{%- if uploaders %}, {{uploaders}}{% endif %}
Build-Depends: debhelper-compat (= 13),
{{pybuild_depends}},
{%- for dependency in build_depends|sort %}
should accomplish this.
Kind regards and thanks for maintaining pypi2deb
Andreas.
[1] https://lists.debian.org/debian-python/2024/02/msg00058.html
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5,
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pypi2deb depends on:
ii build-essential 12.10
ii devscripts 2.23.7
ii dh-python6.20231223
ii python3 3.11.6-1
ii python3-aiohttp 3.9.1-1
ii python3-debian 0.1.49
ii python3-github 2.2.0-1
ii python3-jinja2 3.1.2-1
ii python3-redis4.3.4-3
Versions of packages pypi2deb recommends:
ii python3-msgpack 1.0.3-3+b1
Versions of packages pypi2deb suggests:
pn cython
pn cython3
ii pypy7.3.9+dfsg-1+b1
pn python-all-dev
pn python-nose
pn python-pytest
pn python-setuptools
ii python3-all-dev 3.11.6-1
ii python3-nose1.3.7-12
ii python3-pytest 7.4.4-3
ii python3-setuptools 68.1.2-2
ii python3-sphinx 7.2.6-4
-- no debconf information
Bug#1064436: lintian-brush: Missing git commit + changelog entry for added upstream/metadata
Control: tags -1 - moreinfo thanks Hi Jelmer, Am Mon, Feb 26, 2024 at 03:14:20PM + schrieb Jelmer Vernooij: > On Thu, Feb 22, 2024 at 08:30:46AM +0100, Andreas Tille wrote: > > if upstream/metadata are added this is not added+commited to > > the packaging repository. There is also no changelog created > > which should be something like > > > > * Add upstream metadata > > Are you specifying --update-changelog ? Not explicitly yet. I'm pretty sure when I started calling lintian-brush from routine-update changelog was updated. I changed now to: diff --git a/debian/changelog b/debian/changelog index 1a7aca1..4083c5b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,7 @@ routine-update (0.2.1) UNRELEASED; urgency=medium * Deal with other packaging branches than master even if debian/gbp.conf is missing + * Make sure changelog will be updated -- Andreas Tille Thu, 22 Feb 2024 07:49:24 +0100 diff --git a/routine-update b/routine-update index f1eaa23..b13748d 100755 --- a/routine-update +++ b/routine-update @@ -777,17 +777,17 @@ if grep -q -P '\t' debian/copyright ; then dch_git_commit "No tab in license text" fi -LIBRUSH=$(lintian-brush 2>&1 | head -n1) +LIBRUSH=$(lintian-brush --update-changelog 2>&1 | head -n1) if [ "$LIBRUSH" != "No changes made." ]; then echo "I: lintian-brush was doing some changes" fi -AMHINTS=$(apply-multiarch-hints 2>&1 | head -n1) +AMHINTS=$(apply-multiarch-hints --update-changelog 2>&1 | head -n1) if [ "$AMHINTS" != "Nothing to do." ]; then echo "I: apply-multiarch-hints was doing some changes" fi -DSOBSOLETE=$(deb-scrub-obsolete 2>&1 | wc -l) +DSOBSOLETE=$(deb-scrub-obsolete --update-changelog 2>&1 | wc -l) if [ "$DSOBSOLETE" -gt 1 ]; then echo "I: deb-scrub-obsolete was doing some changes" fi And as you can see in my other bug report #1060338 lintian-brush: Changelog entries are lacking asterisk there actually *are* changelog entries ... but they are more ugly than before. > By default lintian-brush > autodetects whether it needs to update the changelog. Well, this actual bug is about "if upstream/metadata are added this is not added+commited to the packaging repository". It simply happens that upstream/metadata is added and after lintian-brush git consideres the local repository not clean any more since there are files that are not yet added. You should be able to verify this by simply removing upstream/metadata and run lintian-brush (or whatever tool finally is adding this file.) I would not mind about a missing changelog entry but at least the freshly created file should be added. I'm pretty sure this is a regression since that worked before. > You can see whether it thinks it needs to update the changelog by running > ``detect-changelog-behaviour``. I simply want to have a changelog entry once something was changed. > (Also happy to take bug reports on the autodetection behaviour not working > well, > but in that case, please provide extra context). This was not really the point of my bug report but if I notice something I will file an according bug report. Kind regards and thanks a lot for all those Janitor tools which are really helpful. Kind regards Andreas. -- http://fam-tille.de
Bug#1054736: Do we need versiontools in Debian any more?
Hi Benjamin, as far as I can see no other package is using versiontools and it seems orphaned upstream. Do you think we need this package in Debian or should we rather ask ftpmaster for removal? I personally have no specific interest in this package and was just hunting some Python3.12 related bugs. Kind regards Andreas. -- http://fam-tille.de
Bug#1064160: pngcrush FTBFS with libpng 1.6.42
Control: tags -1 patch Control: tags -1 pending Hi Marga, I've pushed the patch used in ArchLinux to Git[1]. I could do another NMU but I would prefer to move the package to Debian Phototools team and I'd volunteer to do that move. Kind regards Andreas. [1] https://salsa.debian.org/debian/pngcrush/-/blob/master/debian/patches/ignore_PNG_IGNORE_ADLER32.patch?ref_type=heads -- http://fam-tille.de
Bug#1064596: ITP: mcl14 -- library providing bindings between mcl and OCaml
Package: wnpp Severity: wishlist X-Debbugs-Cc: 1024...@bugs.debian.org Subject: ITP: mcl14 -- library providing bindings between mcl and OCaml Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: mcl14 Version : 14 Upstream Author : Copyright: © 1999-2014 Stijn van Dongen * URL : https://micans.org/mcl/ * License : GPL-3+ Programming Lang: C Description : library providing bindings between mcl and OCaml The MCL package is an implementation of the MCL algorithm, and offers utilities for manipulating sparse matrices (the essential data structure in the MCL algorithm) and conducting cluster experiments. . This library provides bindings between mcl and OCaml. . This OCaml code is based on a patch for mcl version 14. Unfortunately the attempt to port the patch to latest mcl did not succeeded. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/mcl14
Bug#901677: amide: Window is too wide and not resizable
Hi, thanks a lot for all your patches for amide. Its really appreciated. Kind regards Andreas. -- http://fam-tille.de
Bug#1063376: Add blockers
Control: block -1 by 1063377 Control: block -1 by 1063378 Control: block -1 by 1063379 Adding blockers. Please remove the rdepends first. Kind regards Andreas. -- http://fam-tille.de
Bug#1062371: Add blocking bugs
Control: block -1 by 1063060 Control: block -1 by 1063063 The bugs to remove reverse dependencies were filed. For your convenience I have added these as blocker. It would be great if the packages in question could be removed in the near future to stop cluttering our developer mailing list with testing removal mails. Thanks a lot Andreas. -- http://fam-tille.de
Bug#1061765: Help needed to fix python-coverage-test-runner
HI Andrius, Am Fri, Feb 23, 2024 at 09:29:27AM +0200 schrieb Andrius Merkys: > > ModuleNotFoundError: No module named 'imp' > > I had a similar problem. I worked it around by depending on > python3-zombie-imp, the original code did not require any modifications. Nice hint - implemented. Thanks a lot Andreas. -- http://fam-tille.de
