freeipa is in trouble for the next release (again)
Hi folks, I understand that freeipa-server has a very serious problem (#970880), making it unfit for Bullseye. It is *highly* painful that it puts freeipa-client at risk for the next release, too. We had something similar for Buster about 2 years ago, AFAIR. For my own part, I run freeipa-server on CentOS 7. I am not affected by #970880. I would be very happy with freeipa-client in Bullseye, even if freeipa-server doesn't make it. Do you think it would be possible to cut a clear line between freeipa- client and -server? Regards Harri -- https://bugs.debian.org/970880
Re: freeipa is in trouble for the next release (again)
On Wed, Mar 24, 2021 at 10:02:37AM +0100, Harald Dunkel wrote: > I understand that freeipa-server has a very serious problem (#970880), > making it unfit for Bullseye. It is *highly* painful that it puts > freeipa-client at risk for the next release, too. We had something > similar for Buster about 2 years ago, AFAIR. The freeipa source package is not in testing since 2019-10-07, so "at risk for the next release" is an understatement. > For my own part, I run freeipa-server on CentOS 7. I am not affected > by #970880. I would be very happy with freeipa-client in Bullseye, even > if freeipa-server doesn't make it. The deadline for adding new packages to testing was 2021-02-12. -- WBR, wRAR signature.asc Description: PGP signature
Re: freeipa is in trouble for the next release (again)
On 3/24/21 11:05 AM, Andrey Rahmatullin wrote: On Wed, Mar 24, 2021 at 10:02:37AM +0100, Harald Dunkel wrote: For my own part, I run freeipa-server on CentOS 7. I am not affected by #970880. I would be very happy with freeipa-client in Bullseye, even if freeipa-server doesn't make it. The deadline for adding new packages to testing was 2021-02-12. So what would be your suggestion?
Re: freeipa is in trouble for the next release (again)
On Wed, Mar 24, 2021 at 12:33:53PM +0100, Harald Dunkel wrote: > On 3/24/21 11:05 AM, Andrey Rahmatullin wrote: > > On Wed, Mar 24, 2021 at 10:02:37AM +0100, Harald Dunkel wrote: > > > For my own part, I run freeipa-server on CentOS 7. I am not affected > > > by #970880. I would be very happy with freeipa-client in Bullseye, even > > > if freeipa-server doesn't make it. > > The deadline for adding new packages to testing was 2021-02-12. > > So what would be your suggestion? FWIW, my suggestion would be to attempt to work with the Debian FreeIPA team (there is a release critical bug open since September 2020, so it's unclear how active the team is currently) to get the package healthy, and after Bullseye releases, work to get it into testing, and then into Bullseye-backports. Cheers, - Ted
Re: freeipa is in trouble for the next release (again)
On Wed, Mar 24, 2021 at 12:33:53PM +0100, Harald Dunkel wrote: > > > For my own part, I run freeipa-server on CentOS 7. I am not affected > > > by #970880. I would be very happy with freeipa-client in Bullseye, even > > > if freeipa-server doesn't make it. > > The deadline for adding new packages to testing was 2021-02-12. > So what would be your suggestion? If you are still asking about getting this package into bullseye then I'm afraid it's not possible. Otherwise, as already suggested, it's possible to have it in bullseye-backports after fixing problems keeping it outside testing. -- WBR, wRAR signature.asc Description: PGP signature
Re: freeipa is in trouble for the next release (again)
On 3/24/21 2:49 PM, Andrey Rahmatullin wrote: On Wed, Mar 24, 2021 at 12:33:53PM +0100, Harald Dunkel wrote: So what would be your suggestion? If you are still asking about getting this package into bullseye then I'm afraid it's not possible. Otherwise, as already suggested, it's possible to have it in bullseye-backports after fixing problems keeping it outside testing. Thats not the point. The point is, how can we make sure that freeipa-client stays in Testing for Bookworm, even if there is a fatal problem with freeipa-server?
Re: freeipa is in trouble for the next release (again)
On Wed, Mar 24, 2021 at 04:02:17PM +0100, Harald Dunkel wrote: > > If you are still asking about getting this package into bullseye then I'm > > afraid it's not possible. Otherwise, as already suggested, it's possible > > to have it in bullseye-backports after fixing problems keeping it outside > > testing. > > > > Thats not the point. You should have expressed it more clearly then. > The point is, how can we make sure that freeipa-client stays in Testing > for Bookworm, even if there is a fatal problem with freeipa-server? Make it a separate source package, if it's possible to do a clean split. Make sure the server package neither build-depends nor depends on the client one. The only sane way to do this is at the upstream side though. -- WBR, wRAR signature.asc Description: PGP signature
Re: freeipa is in trouble for the next release (again)
Hi Harald, Quoting Harald Dunkel (2021-03-24 16:02:17) > On 3/24/21 2:49 PM, Andrey Rahmatullin wrote: > > On Wed, Mar 24, 2021 at 12:33:53PM +0100, Harald Dunkel wrote: > >> So what would be your suggestion? > > If you are still asking about getting this package into bullseye > > then I'm afraid it's not possible. Otherwise, as already suggested, > > it's possible to have it in bullseye-backports after fixing problems > > keeping it outside testing. > > > > Thats not the point. > > The point is, how can we make sure that freeipa-client stays in Testing > for Bookworm, even if there is a fatal problem with freeipa-server? Please file a bugreport against freeipa, suggesting to split into two source packages, one for server and one for client. Maybe the maintainers will agree that it is a sensible move, but maybe they will disagree that other concerns (e.g. simplicity of maintenance) overweighs the risk of the package not stabilizing. It really isn't sensible to discuss this among all Debian developers: It's very much tied to the maintenance of that specific package. Kind regards, and thanks for caring about Debian, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Processed: Re: Bug#985833: General: when searching repos I get an error message
Processing control commands: > reassign -1 command-not-found Bug #985833 [general] General: when searching repos I get an error message Bug reassigned from package 'general' to 'command-not-found'. Ignoring request to alter found versions of bug #985833 to the same values previously set Ignoring request to alter fixed versions of bug #985833 to the same values previously set > tags -1 + wontfix Bug #985833 [command-not-found] General: when searching repos I get an error message Added tag(s) wontfix. -- 985833: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985833 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#985833: General: when searching repos I get an error message
Control: reassign -1 command-not-found Control: tags -1 + wontfix Hi Silverback! unable to open database file Traceback (most recent call last): File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in crash_guard callback() File "/usr/lib/command-not-found", line 90, in main cnf = CommandNotFound.CommandNotFound(options.data_dir) File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 79, in __init__ self.db = SqliteDatabase(dbpath) File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in __init__ self.con = sqlite3.connect(filename) sqlite3.OperationalError: unable to open database file There's no internet access involved; the tool cannot open the local database file, which is located at /var/lib/command-not-found/commands.db This can have a bunch of reasons: maybe the file was not created properly, your filesystem might be corrupted, or your disk is full. Speaking of potential fixes: Sorry, command-not-found has crashed! Please file a bug report at: http://www.debian.org/Bugs/Reporting I see why you ended up filing a bug with Debian, but... command-not-found version: 0.3 Python version: 3.9.2 final 0 Distributor ID: Kali Description:Kali GNU/Linux Rolling Release:2021.1 Codename: kali-rolling ...even if this is an actual bug and not an issue with your machine, it is probably Kali Linux related (which derives from Debian, but it is *not* a Debian release), so you are better off asking for support and/or file a bug there: https://www.kali.org/docs/community/submitting-issues-kali-bug-tracker/ Cheers Timo signature.asc Description: PGP signature
Tips for debugging/testing debian/control Depends/Breaks etc changes?
Hello! I've noticed I've spent quite a lot of time debugging various situations where the debian/control definitions for depends/breaks/replaces/conflicts/provides are not optimal. The waste of time is two-fold: 1) apt is not verbose enough 2) the cycle to rebuild/tests is too slow As an example of 1, sometimes I see this: apt install mariadb-client The following packages have unmet dependencies: mariadb-client : Depends: mariadb-client-10.5 (>= 1:10.5.10) but it is not going to be installed apt install mariadb-client-10.5 Installing.. Done! When this happens I have no idea why apt did not resolve the dependency by itself automatically, as there was no real conflict in installing it. Do you have tips on how to debug the root cause of situations like these? For the problem 2, I hate to rebuild all of the packages (and binaries) just because there was a change in debian/control and go through the hassle of updating a test repo etc. I wonder if there is some other "lighter" way to just edit the debian/control and produce new binary packages with them updated without having to actually build new binary packages (and no, editing the .deb files manually and repackaging them with 'ar' is not an option that would make life easier). Thanks for any tips you have on the topic! - Otto
Bug#985833: General: when searching repos I get an error message
Package: General Severity: normal X-Debbugs-Cc: 51lv3rb...@protonmail.com Dear Maintainer, After using the command apt search 'package_name' if the package can't be found I get the following error message, when the error happened and every other instance I have a good internet connection. I'm assuming that the 'unable to open database file' would mean there was no connection, am I right? Sorry, command-not-found has crashed! Please file a bug report at: http://www.debian.org/Bugs/Reporting Please include the following information with the report: command-not-found version: 0.3 Python version: 3.9.2 final 0 Distributor ID: Kali Description:Kali GNU/Linux Rolling Release:2021.1 Codename: kali-rolling Exception information: unable to open database file Traceback (most recent call last): File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in crash_guard callback() File "/usr/lib/command-not-found", line 90, in main cnf = CommandNotFound.CommandNotFound(options.data_dir) File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 79, in __init__ self.db = SqliteDatabase(dbpath) File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in __init__ self.con = sqlite3.connect(filename) sqlite3.OperationalError: unable to open database file -- System Information: Distributor ID: Kali Description:Kali GNU/Linux Rolling Release:2021.1 Codename: kali-rolling Architecture: x86_64 Kernel: Linux 5.10.0-kali4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
