Bug#1031075: ITP: libcatmandu-html-perl -- Modules for handling HTML data within the Catmandu framework
Package: wnpp Owner: Mason James Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libcatmandu-html-perl Version : 0.02-1+dfsg Upstream Author : Patrick Hochstenbach * URL : https://metacpan.org/release/Catmandu-HTML * License : Artistic or GPL-1+ Programming Lang: Perl Description : Modules for handling HTML data within the Catmandu framework Catmandu::HTML contains modules for handling HTML data within the Catmandu framework. Catmandu provides a suite of Perl modules to ease the import, storage, retrieval, export and transformation of metadata records. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: about MiniDebConf
Hi João You're welcome, all details are here: https://pt2023.mini.debconf.org/ Regards Bernelle (indiebio on irc) On Sat, 11 Feb 2023, 10:44 Ottis, wrote: > Hi. > I just see the announce of the debConf, in a local web. > As I'm in lisbon and I'm interested in assist I would like to know if > there is any agenda (I couldn't find, but the wiki page was not working > so maybe there was the answer) where in the campus is the meeting and if > its ok to just arrive. > > Thanks for any clarification. > > João Ottis >
Re: 32bit arch packages are built with wrong ownership due to fakeroot bug
Simon McVittie: On Fri, 10 Feb 2023 at 03:18:16 +0100, Johannes Schauer Marin Rodrigues wrote: Quoting Santiago Vila (2023-02-09 17:32:08) - No intervention from individual maintainers is required for fixing this, as we already have a binNMU mechanism which we already use for transitions. Once fakeroot is fixed, binNMUs can be used to fix packages, yes. Without the fakeroot fix in place, individual maintainers could do things to fix their packages on the affected architectures but I do not think doing so is a good idea. There is one thing that maintainers can do to fix their packages on the affected architectures that I think *might* be a good idea: if their package builds correctly with Rules-Require-Root: no, they could add that field, resulting in fakeroot not being used. [...] smcv Packages that need static non-root ownership cannot do that at the moment using debhelper / dpkg. These are in turn the most likely packages to exhibit this problem that triggered this discussion. For everything else, you can pretty much always migrate to "Rules-Requires-Root: no". It is "just" a question of: 1) Stop the accidental root usage in d/rules. E.g., remove -o root -g root passed to install and left over chown calls. 2) Convince the upstream build system to stop using root during installation in the rare cases they do that. Example from sudo: https://salsa.debian.org/sudo-team/sudo/-/merge_requests/13/diffs?commit_id=fa2a3a3ce37eb356b79ce31838e8b415a7dc31d2 It is not very difficult to do. However, it does take human time and effort, which is a scares resource. But the moment you see a non "root/root" line in the data.tar listing, it is checkmate and game-over. I think we may be able to provide better debian package tooling for the next release that can solve the static ownership problem, but not the human time/effort part. Thanks, ~Niels
Bug#1031098: ITP: gtsam -- sensor fusion using factor graphs
Package: wnpp Owner: Dima Kogan Severity: wishlist * Package name: gtsam Version : 4.2a9 Upstream Author : frank.della...@gtsam.org * URL or Web page : https://gtsam.org/ * License : BSD-3clause Description : Sensor fusion using factor graphs
Bug#1031099: ITP: g2o -- A General Framework for Graph Optimization
Package: wnpp Owner: Dima Kogan Severity: wishlist * Package name: g2o Version : 20201223_git Upstream Author : Rainer Kuemmerle * URL or Web page : https://openslam-org.github.io/g2o.html * License : BSD Description : A General Framework for Graph Optimization
Re: Consensus on closing old bugs
On Mon, Feb 06, 2023 at 10:07:59AM -0700, Sam Hartman wrote: >... > Most of us do not prefer to close bugs simply because they are old. It creates angry users and no real benefits. > But closing bugs with a moreinfo tag when information has not been > provided in six months to a year is likely fine. Only if the bug closer is aware that the BTS does not Cc the submitter by default, and checks first whether the question was ever sent to the submitter (quite often it was not). > So is asking for more info and adding a moreinfo tag when appropriate. > > It's even appropriate to ask if the bug still happens. >... I would consider it abusive behaviour if the person asking the user does not have the intention of trying to fix the bug if the answer is "yes". Our user might be spending hours or days trying to give a good reply,[1] expecting a serious attempt at fixing the bug in exchange for the effort. It is bad enough that we are often not good at trying to resolve bugs where users have sometimes spent considerable effort at writing a good bug report, but asking users to do pointless work would be horrible. cu Adrian [1] especially if asked "Does the problem still happen in unstable?", only a small minority of our users are using unstable
Re: OpenMPI 5.0 to be 32-bit only ?
On Thu, Feb 09, 2023 at 09:53:37AM +, Alastair McKinstry wrote: > Hi, > > The push-back from upstream is that they're unconvinced anyone is actually > using i386 for MPI. > > For example, MPI is configured to use PMIx but its thought that doesn't work > on 32-bit, but no bugs have been reported. > > Either we increase our 32-bit testing regime, or realistically consider it > marginal and dying. I don't think lack of testing is the problem, we should have pretty good coverage due to buildtime and autopkgtest tests. There are bugs like e.g. #1003020 or #1026912 that might be due to OpenMPI failing on 32-bit with 160 cores. Whether spending time trying to properly fix these would be worth it, that's a different question. > Currently I'm favouring accepting a move to 64-bit OpenMPI as a fait > accompli as part of code cleanups for 5.X (post Bookworm), and Debian moving > to MPICH on at least 32-bit archs - I'd favour OpenMPI on 64-bit archs for > better incoming-code-and-compatability support. > > I'd like to hear the case otherwise. The case we should make is that "no one cares about 32-bit builds" from the starting post in the GitHub issue is not true for Debian. We do care that it *builds*, even if it might not be actually used. [1] was about the benefits of switching the two architectures that were using MPICH to OpenMPI two years ago. The mentioned "makes packages like octave build" is due to sundials build depending on mpi-default-dev but requiring ompi-c.pc [2]. m68k and sh4 are building with nocheck, whether or not there might be additional/different test failures in packages with MPICH is unknown. Having different MPI implementations on different architectures again would be painful for us, especially if it would be on release architectures. If it would be architecturally hard for upstream to continue supporting 32-bit then that's how it is, otherwise the current status quo of 32-bit OpenMPI is good enough for us and a possible compromise might be if upstream says "32-bit patches are welcome" and requires an --i-know-that-32-bit-support-is-unsupported-and-might-be-broken configure flag when building for 32-bit archs. > Best regards > Alastair cu Adrian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853029#18 [2] https://buildd.debian.org/status/fetch.php?pkg=sundials&arch=m68k&ver=5.7.0%2Bdfsg-1~exp1&stamp=1626976038&raw=0
Bug#1031119: ITP: libdata-session-perl -- Perl module for persistent session data management
Package: wnpp Owner: Mason James Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdata-session-perl Version : 1.18 Upstream Author : Ron Savage * URL : https://metacpan.org/release/Data-Session * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module for persistent session data management Data::Session is typically used by a CGI script to preserve state data between runs of the script. This gives the end user the illusion that the script never exits. It can also be used to communicate between 2 scripts, as long as they agree beforehand what session id to use. See Data::Session::CGISession for an extended discussion of the design changes between Data::Session and CGI::Session. Data::Session stores user data internally in a hashref, and the module reserves key names starting with '_'. The current list of reserved keys is documented under "flush()". Of course, the module also has a whole set of methods to help manage state. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
