Re: My package is marked for autoremoval from testing
On Thu, Nov 25, 2021 at 03:45:37PM -0500, Tong Sun wrote: > My package cannot be upgraded from current version to latest version > -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 > > It might have something to do with obsoleted conffile files or it > might even not. The problem is, I've been trying to understand how the > conffile files work, and I think I'm doing the right thing, yet my > package cannot be properly upgraded. > > - I don't understand what breaks and why, from the output of the > package upgrade log (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769). Well those errors are clearly caused by dbab.maintscript saying "rm_conffile /etc/dbab", while /etc/dbab is indeed a directory and not a file. So it would be helpful if you told us what were you trying to do by this. If this is about #958900 then rm_conffile is *not* about removing files on purge. You should remove them manually in postrm, but only on purge. Unrelated, but is the package doesn't function without files downloaded from Internet, and even downloads them in postinst, then it should go to contrib. Should I file a bug about this? -- WBR, wRAR signature.asc Description: PGP signature
Wrestling with debconf
Hey list, I'm having an issue with my myfoo-server maintainer scripts for my package myfoo-server. In a nutshell, I am trying to get the user's requested configuration to be handled elegantly. I've read the debconf specification and debconf-devel(7). I see that my issue is discussed: https://manpages.debian.org/jessie/debconf-doc/debconf-devel.7.en.html#HACKS If the user installs the myfoo-server package they will be prompted by debconf in myfoo-server.config to select whether to enable zeroconf, upnp, etc. and various other settings for the server. Those selected settings, whatever their values, should then be written out during the subsequent run of myfoo-server.postinst to /etc/myfoo/server.conf. If myfoo-server.config detects that the user already had an /etc/myfoo/server.conf, such as when they are re-installing the package, myfoo-server.conf should read those values in-place from disk and then seed debconf via my SeedFromUserConfiguration POSIX shell function before any prompts might be displayed (depends on priority, of course). That is what I had intended. I think this behaviour is reasonable. So I start by installing the myfoo-server package locally, e.g. $ sudo apt install ./myfoo-server(...).deb ... Preconfiguring packages ... ... I then see debconf prompts, as expected, from within my myfoo- server.config. I select true to enable upnp and zeroconf (false and true by default in their templates respectively). For the sake of debugging, I checked the myfoo-server/zeroconf debconf field as you see on myfoo-server.config:192 after it is read back from debconf and it is indeed whatever value the user had set it to when prompted (and same for all other settings). Great. That much works as expected. But after that session of myfoo-server.config is run, it appears to be run _again_ after the package is unpacked, but _before_ myfoo- server.postinst is run: ... Setting up myfoo-server (...) ... The problem here is this re-running of the myfoo-server.config happens before the myfoo-server.postinst. This is bad because the latter is supposed to update the values in /etc/myfoo/server.conf to whatever the user just entered via debconf prompts. Because myfoo-server.config's second invocation sees the newly unpacked /etc/myfoo/server.conf, it unintentionally seeds debconf with the values contained therein. The myfoo-server.postinst script is then run, writing out to /etc/myfoo/server.conf the clobbered debconf values. What am I doing wrong and what do you recommend? These are my myfoo-server.config and myfoo-server.postinst: https://pastebin.com/hyWyH5id https://pastebin.com/xW1andmW -- Kip Warner -- Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Bug#974217: RFS: python-radexreader/1.0.0-5 [ITP] -- Reader for the RADEX RD1212 Geiger counter
Control: tags -1 - moreinfo On 25.11.21 18:21, Fabrice Creuzot wrote: I'm not sure what error you have encountered. When I trying the following commands, it works (for me). But perhaps it's not the good way. dget -x https://mentors.debian.net/debian/pool/main/p/python-radexreader/python-radexreader_1.2.1-1.dsc This is not building via git but gives the correct URL for your RFS. You previously wrote https://mentors.debian.net/package/python3-radexreader/ which is non-existing. Therefore I tried to build from the URL in Vcs-Git, which errors. tar xzf python-radexreader_1.2.1.orig.tar.gz tar xf python-radexreader_1.2.1-1.debian.tar.xz cp -a debian/ python-radexreader-1.2.1/ You should use dpkg-source -x instead of those... cd python-radexreader-1.2.1/ debuild -b -uc -us ls ../*deb ../python3-radexreader_1.2.1-1_all.deb ../radexreader_1.2.1-1_all.deb Le 27/10/2021 à 22:28, Bastian Germann a écrit : Control: tags -1 moreinfo On Sun, 29 Nov 2020 13:08:01 +0100 Fabrice Creuzot wrote: I uploaded a new package release (1.0.0-5). I fixed lintian errors and I updated debian directory in source repository. Building from git is broken. Please reupload a source package and remove this bug's moreinfo tag after that.
My package is marked for autoremoval from testing
Hi Mentors, I need help. My package cannot be upgraded from current version to latest version -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 It might have something to do with obsoleted conffile files or it might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my package cannot be properly upgraded. - I don't understand what breaks and why, from the output of the package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769). - Thus, I have no idea how to fix it, and all my previous attempts failed. So, Please help. The package source is at: https://salsa.debian.org/debian/dbab/ Also, I've been trying to solve it on my own for so long that now the good version in testing is marked for autoremoval, for the reason that: > If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. However, this is not true in my case. So if I still cannot fix the problem by myself by the deadline, would I be able to at least stop my package being autoremed from testing? Thanks for helping -- Forwarded message - From: Debian testing autoremoval watch Date: Sat, Nov 20, 2021 at 11:40 PM Subject: dbab is marked for autoremoval from testing To: dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11 It is affected by these RC bugs: 999581: dbab: fails to migrate to testing for too long: unresolved RC bug https://bugs.debian.org/999581 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Bug#974217: RFS: python-radexreader/1.0.0-5 [ITP] -- Reader for the RADEX RD1212 Geiger counter
I'm not sure what error you have encountered. When I trying the following commands, it works (for me). But perhaps it's not the good way. dget -x https://mentors.debian.net/debian/pool/main/p/python-radexreader/python-radexreader_1.2.1-1.dsc tar xzf python-radexreader_1.2.1.orig.tar.gz tar xf python-radexreader_1.2.1-1.debian.tar.xz cp -a debian/ python-radexreader-1.2.1/ cd python-radexreader-1.2.1/ debuild -b -uc -us ls ../*deb ../python3-radexreader_1.2.1-1_all.deb ../radexreader_1.2.1-1_all.deb Le 27/10/2021 à 22:28, Bastian Germann a écrit : Control: tags -1 moreinfo On Sun, 29 Nov 2020 13:08:01 +0100 Fabrice Creuzot wrote: I uploaded a new package release (1.0.0-5). I fixed lintian errors and I updated debian directory in source repository. Building from git is broken. Please reupload a source package and remove this bug's moreinfo tag after that.
Re: Suggestion needed on test failures due to double arithmetics
On Thu, Nov 25, 2021 at 01:45:49PM +0100, Giulio Paci wrote: > Moreover I am still wondering if the compiler behavior is correct in this > case and why it is so unstable. It's correct when you don't care about the amount of precision, and it's unstable for the reasons described in gcc(1) for the options you mentioned, e.g. "This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a "double" is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point.", as in different circumstances the temporary values will have or not have the x87 80-bit precision, leading to different calculation results. -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestion needed on test failures due to double arithmetics
Il gio 25 nov 2021, 13:21 Andrey Rahmatullin ha scritto: > On Thu, Nov 25, 2021 at 01:13:20PM +0100, Giulio Paci wrote: > > The double values refer to timing information. The specific format, > > known as CTM, stores information in seconds in decimals (e.g. "30.66" > > seconds) from the beginning of the stream. > > The failing tool reads this information into double variables > Sounds like it just shouldn't read this data into a float type but use > some fixed-point data type instead. > This is also my opinion (and already suggested upstream), although it would make the code a little bit less readable. Moreover I am still wondering if the compiler behavior is correct in this case and why it is so unstable. Apart from this corner case (which in my opinion should also work), I have not seen bad assumptions about double arithmetics in the rest of the failing tool. Bests, Giulio
Re: Suggestion needed on test failures due to double arithmetics
Hi Paul, On Thu, Nov 25, 2021 at 3:24 AM Paul Wise wrote: > Giulio Paci wrote: > > > 3) what is the most appropriate solution. > > As I understand it, floating point values should not be compared > without some kind of accuracy/precision factor. Zero idea about the > best reference for how to do it correctly, but here is a random one: > > https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ Thanks for this link. It is a very great resource and summarizes very well what I already know about double/float and much more. Since the test case is dealing with timings, I think the most related article is [1]. However even after reading that article it seems to me that in this case it should be reasonable to expect stable behavior of those operators. I have uploaded simplified code that showcase the issue and some of the instabilities [2]. The code seems to behave as if the last value is different from the other 3, supposed equal values. I am not even sure what I am seeing in the debugger, since most of the values are optimized out (and I am not so skilled with debuggers). [1] https://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ [2] https://pastebin.com/embed_js/T3g560UV Bests, Giulio
Bug#1000554: RFS: libfm-qt/0.16.0-3.1 [NMU] [RC] -- Language package for libfm-qt
On Wed, Nov 24, 2021 at 04:14:29PM -0500, S. 7 wrote: > I am looking for a sponsor for my package "libfm-qt": > > * Package name : libfm-qt > Version : 0.16.0-3.1 > libfm-qt (0.16.0-3.1) unstable; urgency=high + * Non-maintainer upload + * Update symbols to fix FTBFS. (Closes: #984102) + + -- S. 7 Sat, 30 Oct 2021 18:19:55 +0200 The new symbols work on amd64 arm64, but are not enough on i386. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ceterum censeo systemdinem esse delendam. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ y
Re: Suggestion needed on test failures due to double arithmetics
On Thu, Nov 25, 2021 at 01:13:20PM +0100, Giulio Paci wrote: > The double values refer to timing information. The specific format, > known as CTM, stores information in seconds in decimals (e.g. "30.66" > seconds) from the beginning of the stream. > The failing tool reads this information into double variables Sounds like it just shouldn't read this data into a float type but use some fixed-point data type instead. -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestion needed on test failures due to double arithmetics
On Thu, Nov 25, 2021 at 8:54 AM Andrey Rahmatullin wrote: > > On Wed, Nov 24, 2021 at 06:38:07PM +0100, Giulio Paci wrote: > > Dear mentors, > > while updating SCTK package I enabled the execution of the test suite > > which was previously disabled. The tests are working fine on x86_64 > > architecture, but a couple of them are failing on i386. > > After investigation [1] I found out that tests are failing because they > > rely on the assumptions that, when a and b have the same double value: > > 1) "a < b" is false; > > 2) "a - b" is 0.0. > What do they actually test, why do they use these assumptions? SCTK is a toolkit to evaluate speech recognition (and other related tasks) tools performance. These tools usually read audio streams and produce simple text files containing the transcriptions and time information (relative to the stream) to synchronize the transcription to the stream. These files are very similar to video subtitles files. The SCTK compares two textual files (usually one is a manually created file and the other is created by an automatic tool) to score how different these outputs are. The tests are checking that SCTK produces the same score reports when provided with the same input files. The double values refer to timing information. The specific format, known as CTM, stores information in seconds in decimals (e.g. "30.66" seconds) from the beginning of the stream. The failing tool reads this information into double variables and, to simplify, it compares "up to when the timings in one file is less than the timings in the other files. If it exceeds or is the same, it checks the difference". In this kind of application you are not usually going beyond what you can store uncompressed on a filesystem in PCM. So, even assuming audio samples of 1 byte, int64 should be a reasonable type to store timings (in samples, rather then seconds). But I understand that doing so would complicate the logic of the tool, especially since it is very unlikely that math approximation would be an issue. To be honest I did not expect the corner case above would fail since it is comparing a value against another value that should just be the same. I have uploaded simplified code that showcase the issue and some of the instabilities [1]. The code seems to behave as if the last value is different from the other 3, supposed equal values. [1] https://pastebin.com/embed_js/T3g560UV Bests, Giulio
Bug#1000583: RFS: foomatic-filters/4.0.17-13 [RC] -- OpenPrinting printer support - filters
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "foomatic-filters": Package name: foomatic-filters Version : 4.0.17-13 Upstream Author : Mailinglist URL : https://wiki.linuxfoundation.org/openprinting/start License : GPL-2.0+, MIT Vcs : https://jff.email/cgit/foomatic-filters.git Section : text It builds those binary packages: foomatic-filters - OpenPrinting printer support - filters foomatic-filters-beh - Openprinting Backend error handler To access further information about this package, please visit the following URL: https://mentors.debian.net/package/foomatic-filters/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/foomatic-filters/foomatic-filters_4.0.17-13.dsc or from git https://jff.email/cgit/foomatic-filters.git/?h=release%2Fdebian%2F4.0.17-13 Changes since the last upload: foomatic-filters (4.0.17-13) unstable; urgency=medium . * Fix error processing package (Closes: #997318): - debian/foomatic-filters.postins: Switch to mktemp. * Declare compliance with Debian Policy 4.6.0.1 (No changes needed). * debian/copyright: - Add year 2021 to myself. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Skype: joergpenguin Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
