Re: Mandatory LC_ALL=C.UTF-8 during package building
Maybe a compromise would be to at least mandate some UTF-8 locale.
popcon is stuck since 2024-05-23
I guess this impact the project as a whole: https://qa.debian.org/popcon-graph.php?packages=bash&show_installed=on&want_legend=on&want_ticks=on&from_date=2024-05-01&to_date=&hlght_date=&date_fmt=%25m-%25d&beenhere=1 Greetings
Bug#1074309: ITP: python-pysubs2 -- Python library for editing subtitle files.
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pysubs2 Version : 1.7.1 Upstream Contact: Tomáš Karabela * URL : https://github.com/tkarabela/pysubs2/ * License : MIT/X Programming Lang: Python Description : Python library for editing subtitle files. pysubs2 is a Python library for editing subtitle files. It’s based on SubStation Alpha, the native format of Aegisub; it also supports SubRip (SRT), MicroDVD, MPL2, TMP and WebVTT formats and OpenAI Whisper captions. There is a small CLI tool for batch conversion and retiming. --- This package is a new dependency of "subliminal". I will maintain this package inside Debian Python Team
Re: Mandatory LC_ALL=C.UTF-8 during package building
Hi,
Thank you both.
One thing that could be fixed quite quickly is fixing the few
remaining official buildd workers that does not yet run with an UTF-8 locale.
If one is unlucky the build will mysteriously fail.
Adding export {LC_ALL|LANG|LC_CTYPE}=C.UTF-8
in every single d/rules by fear of this seems overkill.
Greetings
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074586
https://buildd.debian.org/status/package.php?p=xrayutilities
Le mar. 2 juil. 2024 à 14:37, Guillem Jover a écrit :
>
> Hi!
>
> On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote:
> > On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote:
> > > On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote:
> > > > Maybe a compromise would be to at least mandate some UTF-8 locale.
> > >
> > > dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when
> > > building packages
> >
> > Allowing ASCII seems counterproductive: that puts us in the code path
> > where various tools and runtimes (especially Python) will refuse to
> > process or output anything outside the 0-127 range, which I believe is
> > exactly the problem that debhelper aims to solve by using C.UTF-8 for
> > some categories of package (in particular those that build with Meson).
> >
> > To get what Alexandre suggested, we'd need to allow UTF-8 but not allow
> > ASCII (so for example fr_FR.UTF-8 or C.UTF-8 is fine, but in particular
> > the C locale is not).
>
> But, I guess I can at least unconditionally set LC_CTYPE=C.UTF-8 when
> using --sanitive-env, right away though.
>
> Thanks,
> Guillem
>
Re: Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation
Great review ! We should avoid packaging things with very extra utility. I'm tempted to RM python-easydev now that nothing left depends on it. Le dim. 7 juil. 2024 à 19:55, Yogeswaran Umasankar a écrit : > > Yes, can use the standard library. This dependency chain starts with > moarchiving, which itself is a dependency for cma, and so on. I can > create a patch specifically for moarchiving. > > Cheers!
Bug#1075926: ITP: asammdf -- GUI application used to analyse engine CAN logs
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-asammdf Version : 7.4.2 Upstream Contact: daniel.hri...@gmail.com * URL : https://github.com/danielhrisca/asammdf * License : GNU Lesser General Public License v3.0 Programming Lang: Python Description : GUI application used to analyse engine CAN logs Hi, So I plan to package this, I guess it will take a while because I dind't even managed to install it manually in a quick first attempt without breaking my desktop. I looks nifty https://www.youtube.com/watch?v=n5CBdfpBWzE The main binary package will be named "asammdf", the end-users doen't need to know it's coded in Python. By default/inertia this would be packaged under DebianPythonTeam; but I wonder if it would better to have an Automotive packaging team; which would also include python-canmatrix (under RFA 1014519) and other dependencies of asammdf which might not be in Python. tram & trains would be welcome too (I see for example the ITP 1053497 for tcnopen). I see this wiki page from 2012 but I don't know wether it materialized in packages: https://wiki.debian.org/Automotive -- When I get the bug ITP, I'll set the according blocks on 1062800 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062800 > Maintainers who know the Qt stack and understand > the details of how pyside works are desperately needed. Agree'd I'll have a look at this after my Holliday. Greetings
make vcswatch detect "archived" status
Hi Simon, I think there could be a more global solution for this problem: the vcswatch service could know about Gihub & Opendev infamous "This project has been archived ..." and the wontfix/upstream bug could be filed automatically to notify the maintainers that the current upstream dropped the ball. This bug could be closed with a new upload when moving to a newer fork. (this improvement request would itself be a bug against qa.debian.org) https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=qa.debian.org;dist=unstable Greetings Le sam. 3 août 2024 à 14:40, Simon McVittie a écrit : > On Sat, 03 Aug 2024 at 14:05:50 +0200, Alexandre Detiste wrote: > > https://opendev.org/openstack/murano-tempest-plugin > > > > "This project is no longer maintained." > > I think that fact deserves its own bug report, independent of whether it > uses deprecated Python libraries. > > As with the similar bugs I've reported for unmaintained GNOME and SDL > libraries, I'm tagging the cloned bug as upstream and wontfix, because > it will continue to be unmaintained upstream until/unless upstream action > is taken, therefore won't be fixed by Debian (unless a Debian contributor > becomes its new upstream maintainer, but that's an upstream action). > > smcv
Bug#1078440: ITP: python-bioregistry -- community curated registry, meta-registry, and compact identifier resolver
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org, debian-med-packag...@lists.alioth.debian.org * Package name: python-bioregistry Version : 0.11.12 Upstream Contact: Alexandre Detiste * URL : https://bioregistry.io/ * License : MIT Programming Lang: Python Description : community curated registry, meta-registry, and compact identifier resolver Here's what that means: . Registry . A collection of prefixes and metadata for ontologies, controlled vocabularies, and other semantic spaces. Some other well-known registries are the OBO Foundry, Identifiers.org, and the OLS. . Metaregistry . A collection of metadata about registries and mappings between their constituent prefixes. For example, ChEBI appears in all of the example registries from above. So far, the Bioregistry is the only metaregistry. . Resolver A tool for mapping compact URIs (CURIEs) of the form prefix:identifier to HTML and structured content providers. Some other well-known resolvers are Identifiers.org and Name-To-Thing. - I will maintain this inside the Debian Med Team. This is a new dependency of pybel also maintained by Med Team.
Bug#1078443: ITP: python-curies -- tool to manage Compact Uniform Resource Identifiers
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org, debian-med-packag...@lists.alioth.debian.org * Package name: python-curies Version : 0.7.10 Upstream Contact: Charles Tapley Hoyt * URL : https://pypi.org/project/curies/ * License : MIT Programming Lang: Python Description : tool to manage Compact Uniform Resource Identifiers this Python package can be used by a variety of people: . Data Scientist - someone who consumes and modifies data to suit an analysis or application. For example, they might want to convert tabular data containing CURIEs into IRIs, translate into RDF, then query with SPARQL. . Curator - someone who creates data. For example, an ontologist may want to curate using CURIEs but have their toolchain. cat: µ: Aucun fichier ou dossier de ce nom --- This is a dependency of python-bioregistry, I will maintin it inside the Debian Med Team.
Bug#1078517: ITP: python-rdflib-endpoint -- SPARQL endpoint for RDFLib
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-rdflib-endpoint Version : 0.5.1 Upstream Contact: Vincent Emonet * URL : https://github.com/vemonet/rdflib-endpoint * License : MIT Programming Lang: Python Description : SPARQL endpoint for RDFLib rdflib-endpoint is a SPARQL endpoint based on RDFLib to easily serve RDF files locally, machine learning models, or any other logic implemented in Python via custom SPARQL functions. --- This will be packaged in Debian Python Team This is a dependency of python-bioregistry packaged by Debian Med Team.
Re: Python2 idiosyncrasies in Python3 scripts
mypy will cry at py2+py3 if it doesn't understand the py2 half of hybridized code pyfkakes alike but there's a lot of things to grep for: - sys.error - except ImportError -C 3 - __unicode__ - unicode( - most "from __future__" ... except "annotations" - class (object): ---> "(object)" part can go. In debian/rules: The PYBUILD_python2 rules should be dropped and the "_python3" suffix can be dropped. In debian/control: Boilerplate like "This is the Python3 version of the library". This is mostly non-sensical now. The tools that generate d/control could be trimmed too. Debian Code Search can help for both. Greetings Le jeu. 15 août 2024, 12:57, Andrey Rakhmatullin a écrit : > On Thu, Aug 15, 2024 at 12:11:55PM +0200, Jerome BENOIT wrote: > > is there a reliable way to isolate Python2 idiosyncrasies in Python3 > scripts ? > > Do you mean code that still works in Python 3 but can be simplified? > Lots of linters do this in whole or in part, though I don't have > suggestions for something that does *only* this. You can also look at > pyupgrade. > > -- > WBR, wRAR >
Re: init system policy
>> There was some discussion about this a while back, and I vaguely remember >> that systemd comes with a tool that will tell you exactly what you're >> overriding. I'm not sure if that work got all the way to producing a nice >> Debian-aware tool or not. > >Sounds interesting. If anyone recall that discussion and can share a >pointer, I would appreciate it. systemd-delta -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadstwjkya5uc2hoj+tntagrgsewss9gbsrx13vudgjmphvq...@mail.gmail.com
Fwd: ITP: cruft-ng -- program that finds any cruft built up on your system / rewrite in C
Hi, Here is my ITP for my rewrite of cruft's engine. It reuses the same rule-set an produce the same output. I put Q.A. in CC because some people use it a bit like "piuparts" to see if there are not leftover files from removed packages. (or from hasty "sudo make install") I uploaded it to mentors.d.o: http://mentors.debian.net/package/cruft-ng Please comment :-) Alexandre Detiste -- Message transmis -- Objet : ITP: cruft-ng -- program that finds any cruft built up on your system / rewrite in C Date : vendredi 21 novembre 2014, 11:12:29 De : Alexandre Detiste À : Debian Bug Tracking System Package: wnpp Severity: wishlist Dear Maintainers, *Package Name : cruft-ng Version : 0.1 Upstream Author : Alexandre Detiste (this is a native package). *URL : https://github.com/a-detiste/cruft-ng *License : GPL-2+ *Description : program that finds any cruft built up on your system I've been using "cruft" for years, and I've packaged the last uploads needed to refresh the rule set. My main "itch to scratch" was that tool - while usefull for individual house-keeping & package debugging (like piuparts) - was sooo slow... I rewrote it in C++; but that's mostly C + strings + vector. This is my first C program in 13 years, you may find it a bit lame; patches are welcome. It is rouglhy 15 to 30 times fasters. Original cruft is a shell script that calls a myriad of sub-processes. While not yet feature complete; I find it already usefull; this enabled me to fix "cruft" ruleset iteratively, without waiting hours. This version also solves some original cruft bugs: #50731 , #429602 , #492001 This is mostly done, the only bit missing are a proper Makefile & and a man page. The first version would "Depends: cruft (< 0.9.20) | cruft-common" Then, after Jessie is released, cruft would be split in cruft + cruft-common . This way users can install both and even diff the results of both tools, as they are character compatible. Alexandre Detiste signature.asc Description: This is a digitally signed message part.
Re: successful upgrade to jessie - thanks!
Le vendredi 28 novembre 2014, 22:25:28 Marc Haber a écrit : > We start kdm via an init script and sysvrc emulation, > and this does actually break the distinction between multi-user.target > and graphical.target. Hi, Here is a native kdm service I'v copied from an other distro months ago; and used daily since. In theory it should go in /etc/systemd/system/ , but I guess that if you put it in /lib/systemd/system/ ; it will then be overwriten by dpkg once the package ship a native service. What begs me is that it actually works fine, without something matching the lengthlty setup_config() in init script; that is not replicated here. FYI: There is a more elaborate patch linked to this open bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=kdm-systemd.diff;att=1;bug=754314 Alexandre Detiste [Unit] Description=KDM Display Manager Conflicts=getty@tty1.service After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service [Service] ExecStart=/usr/bin/kdm -nodaemon Restart=always IgnoreSIGPIPE=no [Install] Alias=display-manager.service WantedBy=multi-user.target
Re: ITP: cruft-ng -- program that finds any cruft built up on your system / rewrite in C
> > Here is my ITP for my rewrite of cruft's engine. > > I think you might want to email debian-mentors, with a sponsorship request > (an RFS bug), rather than debian-devel, that is intended as a mailing list > for technical discussions. > See https://mentors.debian.net/sponsors Ok thanks for advice, It's already in the NEW queue. I posted here on purpose: this a remake of a native debian package, and a long term goal - I mean : since 1998[1] - was to have some of it functionality moved in dpkg itself. Here is a more detailed proposal that only pickup the lowest hanging fruit, that would be completely optional and left to each packager choice: https://wiki.debian.org/Cruft/purge TL;DR: move some of postrm scripts "rm -f" lines in machine-readable files than can also be re-used by "dpkg -S" [1] https://lists.debian.org/debian-policy/1998/04/msg00089.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/15240458.dnBom6Q025@antec
one package altering other package's postrm
Hi, Would it be OK / ugly / forbiden to do a "rm -f /var/lib/dpkg/info/cron.postrm" in systemd-cron preinst script ? This is needed to avoid that /etc/cron.allow & /etc/cron.deny disapears when cron is purged but systemd-cron still needs those. (from v1.5.1) In http://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/tree/debian/postrm : # if [ "$1" = "purge" ]; then #rm -f /etc/cron.allow /etc/cron.deny # fi The handover of custom /etc/crontab works fine thank to the "Replace:" in d/control Alexandre Detiste signature.asc Description: This is a digitally signed message part.
Re: one package altering other package's postrm
> : Russ Allbery > Well, ideally this is something that should be coordinated with the cron > package. I've sent a one-liner patch, as this put the least work on cron maintainers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773095 I guess they can apply it right away, even during the freeze; if there were a new RC bug popping up; this could even be included in Jessie. > How do the other cron replacements, like bcron, handle this? It seems not to implement this feature. > It feels cleaner to me To me too, I guess I could check in preinst [1] that /etc/cron.allow or /etc/cron.deny even exists (by default no) [2] that some version of cron without this patch is installed before deleting cron.postrm as last resort. > : Guillem Jover > Move the handling of those (and any other) common files or dirs >(like /etc/cron.allow, /etc/cron.deny, crontab.5, /etc/crontab, >the /etc/cron.* dirs and placeholders, and possibly also the cron >spool) to a third package (say cron-common/cron-support/cron-base/etc) >that both packages depend on. systemd-cron must ship it's own (blanks) /etc/crontab & /etc/anacrontab to avoid duplicate execution and also has it's own crontab.1 & .5 that documents the "PERSITENT=true" feature and other quirks. Ok for the dirs & placeholders tough; and to move "rm -f /etc/cron.allow|deny" in cron-base postrm. For exemple: Gentoo does ship "cronbase" with only the folders: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-process/cronbase/cronbase-0.3.3.ebuild > : Marco d'Itri > Ugly, but sometimes there is no other option. > I am quite sure that I had to do this once or twice in my packages and > no adverse effects have ever been reported. Ok, I'll first let cron's maintainer a chance to apply the patch & DTRT ... and I'll wait anyway till I find a new sponsor to update this package: http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-December/005181.html Alexandre Detiste signature.asc Description: This is a digitally signed message part.
Re: one package altering other package's postrm
> On the other hand, if the problem is that the upgrade causes a remove, > and then some time later the user is going to tidy up by purging cron, This is it; everything works fine when you switch packages back and forth; It's only sometime later when you run a routine "aptitude purge ~c" that this problem happens. > then rather than simply removing the postrm, you could edit it, thus: > > sed -e 's#rm .*/etc/cron.allow#: &#' /var/lib/dpkg/info/cron.postrm I would do that; that's the least intrusive. > although that still seems like a bad thing to be doing, but as long as > you discuss it with the cron maintainer, and ensure that the pattern is > going to match all versions I guess "cron" is pretty much set in the stone nowadays; so this would be low-maintenance. > for downstreams Never tought of/used downstreams (well Raspbian, but this is 99,9% Debian) ... I'll think of it. Ubuntu doesn't seems to do anything fancy here. > Making the files be conffiles of a common package seems like a better > way to go to me. I built this package right now: https://github.com/systemd-cron/cron-base And then I tried to merge in the bcron-run bits. The folders in /etc are handled identically; but /var/spool/cron/crontabs is owned by cron:cron ... I don't know how to solve this easily. There are various options: - keep only support for /etc/cron.allow|deny|d|hourly|daily|weekly|monthly in cron-base ; and duplicate code for /var/spool/cron/crontabs in cron & systemd-cron (both except a mode 1730 root:crontab folder) - share cron-base between only cron & systemd-cron; but not bcron-run (ugly) - split cron-base in cron-etc & cron-spool (ugly too); both made from the same source package; cron & systemd-cron would depend on cron-etc & cron-spool bcron-run would only depend on cron-etc Are such tiny packages going to be accepted in the archive ? At least they are arch:all ; so while trimming cron $numb_of_arch times, this would globaly reduce archive size. Alexandre Detiste Ref: http://sources.debian.net/src/bcron/0.10-3/debian/bcron-run.postinst/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadstwjjigdqh6pyd+9gt4dd59+1qcfp4edv1jgp2za9ojt2...@mail.gmail.com
Re: one package altering other package's postrm
> Another solution proposed by jfs was to factor out the crontab command
> (which writes to /var/spool/cron/crontabs) from src:cron.
That may have trickled down from this mail :-) (should I had CCed you ?)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766053#30
I finally came up with a minimal setgid helper called by the python
script when non-root ;
but I'd still rather use original crontab. (they do on other distros)
> Having various cron daemon implementations follows from their differing
> designs,
> but there isn't much design to merely writing out a file to a specific
> directory securely.
I agree.
bcrontab does special magic and talk to it's deamon with a socket.
> TBH, I'd expect such a cron-base package to be provided by src:cron,
> which already ships these files.
That would be great !
> It's merely a matter of splitting the
> current binary package into two separate ones.
Or three, to take care of bcron-run quirks:
- cron-base : /etc/{ crontab | cron.d | hourly | daily | weekly |
monthly } : this would be used by all cron-daemons
- crontab : owner of /var/spool/cron/crontabs , /etc/cron.allow ,
/etc/cron.deny : this would be shared by cron & systemd-cron
(the two files /etc/cron.allow & /etc/cron.deny really
belong to crontab, they are not used by the deamon)
- cron, that depends on cron-base & crontab
Regards,
Alexandre
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cadstwjkg6y7fttzwkyd8fslggebcoovyuhtqsgzbpd4-rk_...@mail.gmail.com
Re: Bug#773617: ITP: kcmsystemd -- A KDE Control Center module for systemd
Hi, That would be really nice ! I managed to find your packaging tree, so I add it in this CC so ohters can have alook at it: https://github.com/shsorbom/kcmsystemd-debian > Package: wnpp > Severity: wishlist > Owner: "Shawn Sörbom" > > * Package name: kcmsystemd > Version : 0.7.0 > Upstream Author : Ragnar Thomsen > * URL : https://github.com/rthomsen/kcmsystemd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2097312.I4OHycTajG@antec
Re: Bug#777220: ITP: you-get -- downloader for youtube and number of sites
Hi, >> Said that, I am totally fine to have more options :) > > Me too, as long as there is relevancy. So please describe and compare > relevancy (implementation language is not in itself a relevancy but > "needed for $foo" might make implementation of _libraries_ relevant). > > - Jonas the homepage list a lenghty list of Chinese websites supported, so people wanting to see these media would find in "relevant" and wouldn't care about implementation language or library. https://github.com/soimort/you-get A database that cross-match all video downloaders and supported website would be nice. Alexandre -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADsTwjJ165DXv9ckOK0GTG3UAOxQ2QMUctiYffOaY18aePB=z...@mail.gmail.com
new virtual package wolf3d-data
Hi, I noticed that the virtual package wolf3d-data had never been added to the authoritative list; and I would like to fix this. It has been a de-factor virtual package since 2011: http://anonscm.debian.org/cgit/pkg-games/wolf4sdl.git/commit/debian/control?id=8aeb2699e544f78049934b37b9d965f5445dba0f http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/commit/?id=14f8e5cc36360fc40b254fe08c32fc89ea4c7eec Now, it is also provided by the full version 1.2 & 1.4 of Wolf3D + the Spear Of Destiny sequels. I propose this wording: wolf3d-data The data component of a Wolfenstein 3D game. https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt Alexandre Detiste -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADsTwjJkjtaOOwVwT2LuPyr3VD_u12SuD-YzBZmL_s9kv=f...@mail.gmail.com
Re: new virtual package wolf3d-data
>> Jonathan Dowland > There's no problem coordinating > virtual packages names if they are all generated by the same source package, > game-data-packager; furthermore since the packages concerned are not actually > in Debian, it doesn't seem necessary to document them in Debian policy, IMHO. Well, wolf4sdl is in contrib; it's not clear for me if this policy is applicable or not. Status quo is fine too; but it's nice to know what to do when the same question will pop up again with other games (free engine + non-free data is a common pattern). >I forgot to add, you should probably post this to the debian-policy list, >either as well or instead of -devel. Ok, I just posted here first according to the instruction stated in the authoritative list of virtual package names. Alexandre -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2307892.XkQbbMkCqE@antec
Re: Misc Developer News (#38)
> Paul Wise wrote: > > Will be on d-d-a when the next DevNews is posted: > > > > https://wiki.debian.org/DeveloperNews#Google_Code_closing > > How about check and warn it with watch and lintian? > > e.g. https://qa.debian.org/cgi-bin/watch?pkg=mecab was hosted in Google Code, > and if so, warn "hosted site will be closed (January 25th, 2016)" with > Packages overview and lintian. I used this to locate games hosted on GoogleCode that had moved (I found&fixed opentyrian, gargoyle-free, lincity-ng), this parses the copyright file: grep code.google -R /usr/share/doc grep googlecode -R /usr/share/doc Parsing a list of all watch files would be better of course. Alexandre -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2062572.v42cgyHUGI@antec
Re: Packages to install be default for Stretch
Hi, Le mardi 5 mai 2015, 21:02:14 Josh Triplett a écrit : > Paul Wise wrote: > > On Wed, May 6, 2015 at 2:45 AM, Ansgar Burchardt wrote: > > > - cron: > > > Not needed in chroot/container environments. > > > -> demote to "standard" > > > > A lot of packages ship cron jobs, I guess this means they will need to > > depend on cron? They already do. > cron was never "Essential: yes", so if a package depended on it for key > functionality, it already should have depended on cron. And various packages > do. > > On the other hand, packages optionally enhanced by a cron job could use > suggests or recommends. Or could better Depends/Recommends/Suggests on "cron-daemon" This remind me to dig this mail and ask again propermy to complete the migration to "cron-daemon" that got started 5 years ago now that Jessie has been released. https://lists.debian.org/debian-devel/2014/10/msg00474.html Alexandre Detiste -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/30446027.mNS7mfypdK@antec
Re: Facilitating external repositories
Le samedi 6 juin 2015, 00:13:59 Brian May a écrit : > On Sat, 6 Jun 2015 at 02:11 Josh Triplett wrote: > > > Given that the packages in question appear to be Free Software (at least > > from a quick check of a couple of them, as well as the repository being > > named "main"), is there a reason you don't maintain them in Debian > > (including backports or volatile if you need to provide the newest > > packages for older distributions)? > > Well, this had been in Debian for some years until 2010 under an other name: 'beid' https://packages.qa.debian.org/b/beid.html but I don't know why it was removed. > In my case I maintain open source software Debian packages outside of > Debian because the software is far to volatile (e.g. important bug fixes on > a weekly basis) and I don't want old versions hanging around any longer > then absolutely required. Maybe Debian could just ship "eid-archive" package almost as-is, it's not like the key changes every day; the one active here doesn't even have an expiry date. This only contain: /usr/share/eid-archive/eid.list /usr/share/eid-archive/keys/10a04d46.gpg /usr/share/eid-archive/keys/6773d225.gpg - Belgian eID Automatic Signing Key (official releases) + a postinst & postrm The others packages would remain in http://files.eid.belgium.be/debian/ There is very little to clean-up: lintian /var/cache/apt-cacher-ng/files.eid.belgium.be/debian/pool/main/e/eid-archive/eid-archive_2014.8_all.deb W: eid-archive: copyright-without-copyright-notice W: eid-archive: command-with-path-in-maintainer-script postrm:7 /usr/bin/ucf > It is also a very narrow market, possibly not of > general interest to the Debian community (this is hard to determine > however; maybe what this needs right now is expanded exposure). Well 'beid' was there before and a there's a potential 10 millions persons having to do their taxes this month and needing this stuff if they are using Debian or a derivative. eid-archive is a tiny 'all' package that weights 6040 bytes :-) I guess the pros outweigh the cons. > There was also the (slightly confusing) perception in management that they > had to tightly control ownership and distribution, despite it being open > source GPL software, available on github, etc. Entirely possible :-( Alexandre Detiste signature.asc Description: This is a digitally signed message part.
Re: Facilitating external repositories
Le vendredi 12 juin 2015, 00:59:51 Wouter Verhelst a écrit : > On Thu, Jun 11, 2015 at 12:38:29PM +0200, Bálint Réczey wrote: > > I see eid-mw is built on for i386 and amd64, while I assume it would > > build and work perfectly on arm* laptops and computers as well: > > https://files.eid.belgium.be/debian/pool/main/e/eid-mw/ > > > > Cheers, > > Balint I was curious, so I tried it on Raspbian's "almost-armhf" architecture & it works ! The java applet is a bit slow, but some embedded application would use some other language. Having an "armhf" package in a Debian unnofficial repo means that it must still be recompiled for Raspbian because there armhf means something else. (or the armhf package could be build in a way that amrv7 instructions are allways avoided, or a separate repos is built only for Raspbian) The "eid-viewer" is now an 'any' package, but couldn't it be an 'all' because it only include a java program, an icon & a .desktop file? Alexandre Detiste -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1793536.pIiYa9OGHR@antec
Re: Bug#790933: ITP: drive - Google Drive tool
I think nobody mentioned it, but there is already "grive" https://packages.debian.org/jessie/grive . -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadstwjjw5wmoa8zwoj1ekj8omdrg+d8v7mzdb+lgerng8pn...@mail.gmail.com
Bug#794470: ITP: openxcom -- Open-source clone of the original X-Com game
Package: wnpp Severity: wishlist Owner: Alexandre Detiste * Package name: openxcom Version : 1.1 (not yet released) Upstream Author : SupSuper @ GitHub, OpenXcom Developers * URL : http://openxcom.org/ * License : GPL 3 Programming Lang: C Maintainer : Debian Games Team Description : Open-source clone of the original X-Com game As this needs the original game data, as currently still sold on Steam, this game would go in contrib. Upcoming game-data-packager can automacialy create a .deb for local consumption with these data. A draft package is available here: http://anonscm.debian.org/cgit/pkg-games/openxcom.git/ The current draft package is built upon a recent git snapshot, because the commercial data layout has evolved since v1.0 to allow room for 'Terror from the deep' sequel. There is a regression in libyaml-cpp0.5 0.5.2; one needs to downgrade to 0.5.1-1 before building this draft package. This will be solved in next libyaml-cpp release: https://github.com/jbeder/yaml-cpp/commit/b426fafff6238dda8d86fa668f585cba732dd272 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150803120222.27135.23545.reportbug@antec
Re: Bug#793644: ITP: hadoop -- Apache Hadoop distributed processing framework
2015-07-28 12:27 GMT+02:00 Emmanuel Bourg : >> I doubt that anybody would use a debian version of hadoop now as long as it >> isn't backed by upstream, cloudera or hortonworks. > > I don't think this package will be widely adopted either, not everyone > churns an amount of data that justifies the use of Hadoop. I'm mainly > packaging it as a dependency of Solr, which is more likely to be popular. Hadoop is listed on so many job offers, and that seems a nice exit-way to escape from "SAS B.I." hell, that would be really nice to be able to give it a try without going through some contrived manual build process as told here: https://wiki.debian.org/Hadoop . In a learning/academic mindset, the amount of data doesn't matter. > backed by upstream, cloudera or hortonworks. I guess that people paid to handle this stuff 9 to 5 can handle the existing manual build. Thanks ! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADsTwjKhavikoVxKEJNrZUm0Z9XssxBBk_O++cwArRiYsNE=g...@mail.gmail.com
Re: Cron, anacron, cronie, systemd-timers
Hi Mark,
Thanks for notifying me of this discussion at
https://github.com/systemd-cron/systemd-cron/issues/47
I have been trough some issues recently (apt-cacher-ng that spew
errors after the release)
and I had to dig trough the cron-daily unit journal to locate the problem
and I untersand this is a pain for others too.
> > in-sequence execution of the cron.{daily|weekly|monthly} jobs
> >As noted in another thread, this isn't actually missing from systemd-cron,
> >which still uses run-parts for these (although /issues/47 requests the
> >behaviour that it seems we both assumed it already had).
>
> I am not sure which way is the better one. I can think of both methods
> having advantages and disadvantages and would probably try the other
> one if it was implemented or just available by throwing one switch.
I did the boring work: autoconf, the Makefile...
It is alive here but needs some testing and feedback,
see how it works through the daily, weekly jobs...
> throwing one switch
The idea is to have RUN_PARTS as a bool in /etc/crontab but it
doesn't work yet if there isn't any job defined at all.
(the python generator returns nothing)...
Greets,
Alexandre Detiste
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
Le mer. 31 mai 2023 à 12:44, Wouter Verhelst a écrit : > 20+ year old machines are typically more power hungry, more expensive, > less performant, and less reliable than an up-to-date raspberry pi. Embedded systems and medical one can be crazily expensive to maintain and even more to replace but some will run on i386 for a long time more (had to manage some still running on DOS recently ...), there's also much of amd64 HW running on i386 because of lazyness/cost for hybrid fleets; energy efficiency is there the least of concerns. Some things _do_ start to fall apart: some nasty memory corruption bug in nginx that only shows up on i386 code path ... :-( Greetings
Re: Q: systemd-timer vs cron
On Sun, 13 Mar 2022 00:07:06 +, Simon McVittie wrote:
>> These are still somewhat annoying in practice because of the log entries for
>> CRON running something pointlessly.
>
>systemd-cron gets round this by assuming that /etc/cron.d/foobar
>is redundant with a native systemd timer foobar.timer, so if
>foobar.timer exists (or is explicitly masked), systemd-cron will not run
>/etc/cron.d/foobar. I don't think this naming convention is formally
>guaranteed by Policy, but it seems to work well enough in practice.
>
>systemd-cron is a third-party implementation of the cron-daemon interface
>as a systemd generator, which outputs pairs of systemd .timer and
>.service units corresponding to cron jobs. It is not part of systemd,
>and is an alternative to running a more traditional cron-daemon (Vixie
>cron or equivalent) as a long-running systemd service.
>
>This mechanism currently only works for cron.d, and not for the grouped
>hourly/daily/weekly/monthly sets of cron jobs, which always get run
>by run-parts (unless the corresponding directory is completely empty,
>in which case the appropriate hourly/daily/weekly/monthly timer is
>automatically disabled by a ConditionDirectoryNotEmpty rule).
>
> ... https://lists.debian.org/debian-devel/2022/03/msg00211.html
Hi, I want to change this part for the Trixie cycle;
I just uploaded a new systemd-cron right now.
The needed "part" name to timer "name" translation table
has been included in the upstream repos. There will certainly a lot
a cases missing ... a smarter idea is welcomed
(the easiest on my side is to ask packages to always use
same name for /etc/cron.*/ and .timer)
To do nothing faster systemd-cron could/should be rewritten in C/C++.
> # this is dumb, but gets the job done ... for now
>PART2TIMER = {
>'apt-compat': 'apt-daily',
>'dpkg': 'dpkg-db-backup',
>'plocate': 'plocate-updatedb',
>}
systemd-cron (1.15.21-1) unstable; urgency=low
* do not use "run-parts" anymore to execute /etc/cron.{hourly|weekly|monthly}
and instead generate a .timer+.service pair by item.
Most prominent Debian packages already provide their own .timer:
apt, dpkg, man-deb, plocate ... in this case systemd-cron does nothing.
Bug#1039091: RFP: cmake-d -- integration of D language for CMake
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: cmake-d Version : 0~20230625 Upstream Contact: Dragos Carp * URL : https://github.com/dcarp/cmake-d * License : MIT/X Programming Lang: D Description : integration of D language for CMake This package is needed to update the "mu-cade" game to a modernized version found here: https://github.com/mathstuf/abagames-mu-cade/ ... and to go further with the SDL1 -> SDL2 transition. I'm not an expert of CMake myself; but it looks like an easy job for someone who is used to. A (working alternative) would be to vendor this in src:mu-cade but I find it ugly. Greetings,
Bug#1042371: ITP: libchdr -- libchdr is a standalone library for reading MAME CHDv1-v5 formats.
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org, archive-1...@nm.debian.org * Package name: libchdr Version : 0 Upstream Contact: Romain Tisserand * URL : https://github.com/rtissera/libchdr * License : BSD-3-Clause Programming Lang: C Description : libchdr is a standalone library for reading MAME CHDv1-v5 formats. The code is based off of MAME's old C codebase which read up to CHDv4 with OS-dependent features removed, and CHDv5 support backported from MAME's current C++ codebase. CHD is a lossless compression format originally developed for MAME, for the hard-drive contents of certain arcade machines. It has since been used in several other emulators as a means of storing CD-ROM game data. For CD-based games, it compresses the contents of a disc image (.cue + .bin files) to a single .chd file. --- https://retropie.org.uk/docs/CHD-files/ This library is already currently vendored in these 3 packages: https://codesearch.debian.net/search?q=libchdr&literal=1&perpkg=1 * ares * mrboom * retroarch The library is sadly unversionned at the moment: https://github.com/rtissera/libchdr/issues/101 The package would be maintained inside the Games team. Greetings,
Re: /usr-merge: continuous archive analysis
Le ven. 21 juil. 2023 à 16:48, Helmut Grohne a écrit : > TL;DR: dpkg-statoverride detection cannot be automated, but there are > only 5 affected packages. > > On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > > * DEP17-P5: dpkg-statoverrides not matching the files shipped. > >Possibly, I can extend dumat to cover unconditional statoverrides. > > Changes needed: > * fuse (queries only, can be duplicated now) > * fuse3 (queries only, can be duplicated now) > * ntfs-3g (queries only, can be duplicated now) > * systemd-cron (needs to be updated when moving files) > * yp-tools (needs to be updated when moving files) [systemd-cron]: after a carefull review, I took a third option: these scriptlets belong neither in /lib nor /usr/lib but in /usr/libexec . This is now implemented this way in the upstream repository. The debian postinst will be adapted to remove the old override in a next upload. Greetings, Alexandre
Re: Please test apt-listchanges 4.0 in experimental
Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens a écrit : > I'd appreciate some testing from folks here before it gets promoted to > unstable. I got important NEWS from libx11 from 2006 (?) so far so good for the rest. > the database needs to be populated with data for existing packages during > upgrades Having a "solid" .timer forever for a single-time task seems a bit too much. Could this be done a different way with "systemd-run" or a .timer generated in /run/systemd/system ? > * Code cleanup and improvement, including `flake8' and `pylint' > compatibility, (some) unit tests, and adherence to newer standards and > best practices. Can annotations/mypy testing be considered now "best practices" for Debian native packages ? I see that testing of apt-listchanges would benefit from having python3-debconf typed first. I personally find annotations very usefull when handing over old, big codebases to some new team who doesn't have the expected input type of function in their head. It also helps clean-up things that were jurry rigged for python2+3 compatibility. (bytes/str...) I'm tempted to add for myself a RSS generator to apt-listchanges on a private branch and see where it goes, but would first would like it to be typed. Greetings
Re: Please test apt-listchanges 4.0 in experimental
Le mer. 11 oct. 2023 à 14:54, Jonathan Kamens a écrit : > Can you confirm that this occurred with 4.0 rather than 4.1? I'm a bit messy & forgetful these times. But you have #1053812 against 4.1 already. > > Can annotations/mypy testing be considered now "best practices" for > > Debian native packages ? > > Best practice? Sure. Requirement? Not so much. Of course it's not a requirement; and it can be done iteratively. > Regarding apt-listchanges in particular, I have already spent countless hours > getting > ready for this new release, including the addition of a substantial unit-test > suite > where there were no tests before. I see it, and it's nice work. > I do not have the bandwidth to add type hints as well, > and I do not think this should be a blocker to releasing the new version to > the public. This is why I propose to do it. > I am happy to consider a MR if someone else wants to add typing to the > code-base. There's a first MR pending. There's another one against python3-debconf with 100% "mypy --strict" coverage. I just don't know how to handle the "py.typed" there: it's a flag file, contents doesn't matter. It could be a "touch" in debian/rules, I just don't know what is the prefered way. Greetings
unattended-upgrade broken
How to fix this in an unanttended way ? (even Salsa seems to have UU installed, so maybe impact on infrastructure too) # unattended-upgrade --verbose Traceback (most recent call last): File "/usr/bin/unattended-upgrade", line 83, in import apt_inst ImportError: /usr/lib/python3/dist-packages/apt_inst.cpython-311-x86_64-linux-gnu.so: undefined symbol: PyAptWarning root@brix:~#
Re: unattended-upgrade broken
Yup I got a jump scare because I had pinned this one to unstable. Still a heads up can be useful. Thanks Le dim. 17 déc. 2023 à 16:15, Bálint Réczey a écrit : > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058657 . > The issue does not seem to be affecting stable and testing, just unstable. > > Cheers, > Balint
Bug#1060291: ITP: python-nh3 -- Python bindings to the ammonia HTML sanitization library.
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-nh3 Version : 0.2.15 Upstream Contact: * URL : https://github.com/messense/nh3 * License : MIT Programming Lang: Pytthon Description : Python bindings to the ammonia HTML sanitization library. NH3 is an HTML sanitizing library that escapes or strips markup and attributes based on a white list. NH3 can also linkify text safely, applying filters that Django's urlize filter cannot, and optionally setting rel attributes, even on links already in the text. . NH3 is intended for sanitizing text from untrusted sources. If you find yourself jumping through hoops to allow your site administrators to do lots of things, you're probably outside the use cases. Either trust those users, or don't. Bleach is deprecated, NH3 is seen a valid successor. NH3 is neead to package the latest version of 'python-readme-renderer' https://github.com/mozilla/bleach/issues/698 https://daniel.feldroy.com/posts/2023-06-converting-from-bleach-to-nh3
Re: xz backdoor
Le dim. 31 mars 2024 à 10:17, Sirius a écrit : > Reduction of complexity is IMHO always worthwhile as it would open the > door for more people being able to step up as maintainers (taking into > account that volunteers right this minute might not be overly welcome and > when they are, they should likely not be near authentication, crypto and > compression at least initially). It's worse than that: to make the xz MR looks more legit; the fake puppet profile "Hans Jansen" also sent _maybe_ legit MR to random games repos: https://news.ycombinator.com/item?id=39868390 Here fixing our Salsa tooling could help also making real newcomers life more enjoyable by always disabling MR again upstream & pristine-tar tar. I don't see any real good purpose for these unreviewable [*] huge diff; one could just ping someone with commit access to do "gbp import-orig --uscan --pristine-tar ; gbp push" or if absolutely nobody has the time for this maybe a bot could do it ? BTW it's quite smart to attack Games team: as we're used to get legit one-off MR from people never to be seen again later. [*] https://salsa.debian.org/games-team/endless-sky/-/merge_requests/5 Greetings
Re: Command /usr/bin/mv wrong message in German
Le lun. 1 avr. 2024 à 10:43, Johannes Schauer Marin Rodrigues a écrit : > > This is the reason I never expect dpkg -S to work and dpkg -L to be > > correct. The (probably) oldest registered bug report about this is #213907, > > from 2003. RPM has %ghost since before that, of course. > > This is the reason I never expect apt-file search to work. It would be nice if > we had a tool which would track the files created by maintainer scripts as > well > and associate them to packages. Isn't dumat tracking which files are actually > created after package installation? If yes, can that data be made searchable? That tool is cruft-ng ... I mostly use it for forensics of messed up OS images, but it can be asked where a single ghost/volatile file comes from. (If it has been teached so) $ LANG=C dpkg -S /etc/fstab dpkg-query: no path found matching pattern /etc/fstab $ cruft /etc/fstab base-files Greetings
Re: Validating tarballs against git repositories
Le lun. 1 avr. 2024 à 15:49, Colin Watson a écrit : > > The practice of running "autoreconf -fi" or similar via dh-autoreconf > has worked extremely well at scale in Debian. I'm sure there are > complex edge cases where it's caused problems, but it's far from being a > disaster area. It's pretty uncommon, only old stuff. That could be monitored (via lintian ?), anything with "--without autoreconf" or "overides dh_autoreconf". grep autoreconf */debian/rules enigma/debian/rules:override_dh_autoreconf: enigma/debian/rules:#dh_autoreconf geki2/debian/rules: dh $@ --no-parallel --without autoreconf kanatest/debian/rules:execute_before_dh_autoreconf: lincity-ng/debian/rules:dh $@ --without autoreconf
Bug#1070772: ITP: python-mutf8 -- encoders and decoders for the MUTF-8 character encoding
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-mutf8 Version : 1.0.0 Upstream Contact: Tyler Kennedy * URL : https://pypi.org/project/mutf8/ * License : MIT Programming Lang: Python Description : encoders and decoders for the MUTF-8 character encoding This package contains simple pure-python as well as C encoders and decoders for the MUTF-8 character encoding. In most cases, it can also parse the even-rarer CESU-8. These days, you'll most likely encounter MUTF-8 when working on files or protocols related to the JVM. Strings in a Java .class file are encoded using MUTF-8, strings passed by the JNI, as well as strings exported by the object serializer. This library was extracted from Lawu, a Python library for working with JVM class files. I will maintain this inside DPT. This is a new dependency of androguard
Bug#1070834: ITP: python-pystow -- file management utility library for Python programs
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pystow Version : 0.5.4 Upstream Contact: Charles Tapley Hoyt * URL : https://github.com/cthoyt/pystow * License : MIT Programming Lang: Python Description : file management utility library for Python programs This library can replace the boilerplate code one is needed to write in order to maintain files in $HOME --- This is a new depedency needed to upgrade 'pybel'.
Re: About i386 support
Hi, I have 900 :-) (Moxa V2416). For these type of industrial/embedded use, popcon is irrelevant. The debian-installer mostly too, the basis image was Wheezy based with unknown third party tweaks and with only dist upgrade from that souped up image. The remaining other legacy project can dist upgrade from bookworm. But well things do start falling appart anyway. This random nginx memory corruption bug is annoying. Greetings Le dim. 19 mai 2024, 17:31, a écrit : > I have an N270 system I can use to contribute, if someone is willing to > explain what I need to do to make it useful. > -- > *From:* Victor Gamper > *Sent:* Sunday, May 19, 2024 08:03 > *To:* debian-devel@lists.debian.org > *Subject:* Re: About i386 support >
Re: MBF: Building packages in the (not so distant) future
Le dim. 26 mai 2024 à 19:35, Santiago Vila a écrit : > * It would be wonderful if reproducible-builds people could set the > time-to-build-in-future for trixie and sid to three years after the > estimated release date of trixie (I believe they use six months ahead > of time, which imo it's not enough). And/or anything with not the same "leapness" as current year. https://gitlab.com/doctormo/python-crontab/-/issues/109
UsrMerge vs cruft
Hi, It looks like UsrMerge finally broke the "cruft" engine for good. As a mix of bash, Perl and ad-hoc C helpers, it has be unmaintainable and mostly unmaintained for so many years. request bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941998 RM request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020293 I wasn't notified about the RM request and stumbled on it by luck, but I won't oppose it, and will consider moving the rule database that is now in cruft-common into cruft-ng; although in a smarter concatenated format, to avoid wasting inodes with tiny 1 line files. Does cruft-ng needs to start providing a transitional "cruft" binary package / command for pre-existing users, or is this such a niche Q&A utility (in the likes of adequate, piuparts, diffoscope, lintian) that it can go without ? cruft-ng still has ways to evolve, for example by processing the globing patterns for R/W files provided in AppArmor templates by more and more packages. Any comments are welcome. Greetings, Alexandre Detiste pgpvytoB7j1BL.pgp Description: OpenPGP digital signature
cruft(-ng) and dh-cruft: handling and registering of dynamic files
Hi, I had been working on the cruft/cruft-ng package since 2014; there where a few setbacks along the years, like mlocate -> plocate & UsrMerge transitions, but it's alive and kicking, helping to find random lost files left behind by other packages and file bugs against those from time to time to get these glitches resolved. Recently I've been working a lot on it because I realized it would be the perfect solution to audit the disk space usage problems I'm facing at work. So I somewhat whipped up what I remembered from my own proposal https://wiki.debian.org/Cruft/purge and have now for myself a working "dh-cruft" than I can use to register dynamic files owned by some private .deb. Here "dh-cruft" is a must, I don't want to polute Debian with some random external data from downstream. This DebHelper works this way: * the "debian/cruft" list merely register the glob patterns, * and "debian/purge" list also an "rm -rf" stanza in postrm/purge. As a bonus there's now also a new "cpigs" command, working akin to "dpigs" from Debian Goodies to list the biggest volatile data producers. The plan now is to have a new option that dumps the whole matching result database as .json with individual file size for jq consumption or in my case Jupyter; this instead of implementing older requests (#291823 #487458 #527285). I know it's a very old unresolved subject that has been lurking forever here, but maybe it's the right time to look it up with a fresh view. My proposal for next steps:µ * gather your comments here * some review of dh-cruft (I don't know Perl) * get it in the NEW queue soon * have interested packages take part; for now cruft-ng ship it's own homegrown fallback database * (later): merge dh-cruft into DebHelper when it's basically "done" * (much much later): migrate some logic from DH to dpkg itself, with a more declarative packaging style; cruft-ng is already linked with the static library libdpkg and is bound to progress at the same pace. * there is still a performance problem in cruft-ng that I wish to improve. Basic profiling can be done by setting ELAPSED=1 env var. Greetings, Alexandre Detiste ./cpigs 30 496720816 apt 68957680 npm 61846660 linux-image-5.19.0-1-amd64 (the initrd) 61787431 linux-image-5.19.0-2-amd64 53131401 dlocate 36229735 aptitude 19621198 dpkg 17896745 plocate 13559874 jupyter-nbextension-jupyter-js-widgets 11982526 udev 11870208 openjdk-11-jre-headless 7257544 debconf 5704857 smartmontools 5685370 ttf-mscorefonts-installer 5086033 linux-image-5.18.0-4-amd64 -> rc state 4933502 grub-common 3550208 qgis 3523931 fontconfig 3421312 ucf 3231839 shared-mime-info 3063016 locales 2266947 libreoffice-common (files seen from explain/ucf) 1901483 grub-pc-bin 1565651 logrotate 1258042 man-db 1107968 ALTERNATIVES (I thought these were only symlinks ?) 783313 popularity-contest 763776 unattended-upgrades (du -b /var/log/unattended-upgrades/760422) 657496 breeze-icon-theme 625345 PYEXCEL(some pip3 automation) pgplDWk0_S4Hw.pgp Description: OpenPGP digital signature
Re: cruft(-ng) and dh-cruft: handling and registering of dynamic files
Hi, Le dim. 23 oct. 2022 à 04:24, Paul Wise a écrit : > Thank you for your work on this, being able to register files generated > at install time by maintainer scripts or even at runtime by system > maintainence tools to particular packages is a very useful feature for > keeping all the files on a system more easily managed. The "cpigs" command has now a new "-C" command line switch to output the ownership of all system files (static+volatile) in a single .csv. I think this is something quite basic that can fill so many needs; but simply did not existed before. "apt-file" could be adapted to also transparently cache this information. End-users of this tool would get better results without having to change their habits. $ apt-file search /etc/subgid [nothing] $ cpigs -c | grep subgid /etc/subgid;base-passwd;f;1;19 /etc/subgid-;base-passwd;f;1;0 The plan is to keep this .csv output stable, whatever changes in the upstream dataflow: which is now mix of dpkg&diversions + alternatives + custom fallback scripts that know and replicate how UCF, logrotate, initramfs, grub, systemd, sysvinit manage volatile files inside their postinst/postrm. > I do worry about users removing files that they don't understand, based > on feedback by cpigs/cruft-ng, but they do that already so... :) I have seen some complaints about this online, and I agree... original "cruft" tool looks more like an unfinished Q&A tool akin to piuparts than an end-user tool for me. > An ncdu or mc style interface (or plugins for those) to view cruft on a > system sounds very useful in addition to the data export. It's implemented but the ncdu datamodel does not allow to insert the matched package name for the volatile files. It's still nice to use if you need to quickly identify where are the big volatile files piling up and take action. Already done in real life. Greetings
security paperwork machine
Hi, I'm parsing the RSS from the tracker, like this one: https://tracker.debian.org/pkg/tiff/rss To get back the nice looking article URL like this one https://tracker.debian.org/news/1411413/accepted-tiff-410git191117-2deb10u5-source-into-oldstable/ ... and compile some static website each time a relevant update is queued for internal review. (look a spiral ! / squirrel !) Is it already a better way to do this programmatically ? I used python3-apt to get the source name matching the binary, I don't want the raw text of the changelog, I want the nice looking URL :-) https://salsa.debian.org/qa/distro-tracker/-/blob/master/debian/control I can't find python3-distro-tracker in the archive nor it's build-dep python3-django-jsonfield; but this looks more like the back-end than an hypothetical client side. A whole pre-existing private security tracker solution would be perfect; or a website where one could register all the package they care about. Geetings
packages.debian.org hasn't been updated for non-free-firmware
HI, It looks trivial to provide a blind MR without any testing ... But this really needs testing :-/, someone willing to clone the whole setup. https://packages.debian.org/source/unstable/amd64-microcode : 404 https://packages.debian.org/source/unstable/intel-microcode : 404 https://salsa.debian.org/search?search=non-free&nav_source=navbar&project_id=26568&group_id=3401&search_code=true&repository_ref=master No commit for one year https://salsa.debian.org/webmaster-team/packages/-/commits/master Greetings
Re: packages.debian.org hasn't been updated for non-free-firmware
Thanks it works now. Le dim. 19 févr. 2023 à 17:04, Cyril Brulebois a écrit : > > Cyril Brulebois (2023-02-19): > > I tried to hotpatch it, but failed to so far. > > Second attempt seems better. Might take an extra dinstall (+ indexing in > the following hours) to have all the things in place though. If people > still see problems tomorrow, please follow up with details.
Re: Adding epoch to kworkflow package to correct a wrong upstream version
Lintian already does some special handling for the initial release (like checking the closure of an ITP bug), this check could happen there. Greets Le dim. 12 mars 2023 à 19:06, IOhannes m zmölnig a écrit : > >In future, please use a lower version number when packaging unreleased > >software. A version starting with an 8-digit date is almost guaranteed > >to compare greater than whatever upstream eventually chooses, > > > Could lintian warn when a date based version is used? > (I haven't checked how many upstreams use date-based versions intentionally > and fully aware of the consequences, but I think the problem appears mostly > if upstream does not do any formal releases at all, so the package maintainer > concocts some arbitrary version number on their own) > > > mfh.her.fsr > IOhannes >
Re: unattended-upgrades by default?
2016-11-04 13:29 GMT+01:00 Roland Mas : > Tangentially related: is there something similar for kernels? My > monitoring setup currently compares the age of the most recent file in > /boot with the uptime, but I feel there must be something more proper > somewhere. Unattended-Upgrades can also handle this by itself, it ships a /etc/kernel/postinst.d/unattended-upgrades hook that create a /var/run/reboot-required trigger; which tell UU to reboot the computer after updates includiong a kernel are done. (1) This was a bit harsh to reboot with people logged now, so now UU can also check for active users. (2) (1) & (2) are disabled by default; there's also "Unattended-Upgrade::Automatic-Reboot-Time", for school & offices. Greets, Alexandre
Re: Bug#875545: ITP: cpdf -- The tool provide a wide range of professional, robust tools to modify PDF files.
2017-09-12 8:55 GMT+02:00 Andrey Rahmatullin : > On Tue, Sep 12, 2017 at 01:40:08AM -0300, Francisco Vilmar Cardoso Ruviaro > wrote: > > * License : Coherent Graphics Ltd Non-Commercial Use License > This is suitable only for non-free, and only if this is acceptable: > Then why not simply use pdftk from main ? What does cpdf can do that pdftk can't ? Greets, Alexandre
Re: Removal of upstart integration
Hi,
Please also sprinkle these maintainers scripts with some
rmdir /etc/init --ignore-fail-on-non-empty
to avoid ending up with a stale, unowned, empty /etc/init.
(ad: the "cruft" tool found out about this)
--- /var/spool/cruft/report_20170907.log2017-09-07
06:18:45.571974263 +0200
+++ /var/spool/cruft/report_20170913.log2017-09-13
06:19:16.245673086 +0200
@@ -1,13 +1,13 @@
-cruft report: jeu 07 sep 2017 06:15:25 CEST
+cruft report: mer 13 sep 2017 06:15:29 CEST
missing: dpkg
/usr/lib/arm-linux-gnueabihf/gio
/usr/lib/arm-linux-gnueabihf/gio/modules
unexplained: /
-/etc/apt/apt.conf.d/50unattended-upgrades.ucf-dist
/etc/apt/apt.conf.d/99local
/etc/ca-certificates.conf.dpkg-old
/etc/dpkg/dpkg.cfg.d/local
/etc/group.org
+/etc/init
/etc/modprobe.d/ipv6.conf
2017-08-30 15:39 GMT+02:00 Dimitri John Ledkov :
> upstart - event-based init daemon has been removed from debian and is
> currently only present in oldstable.
>
> Many packages however still ship upstart integration. Please consider
> removing /etc/init/* conffiles from your packages. Do note, that
> typically this will require a debian/pkg.maintscript snippet to
> rm_conffile these files.
>
> For straight forwarded cases where simply debian/*.upstart files
> exist, this can be resolved using this script:
>
> 8<
> #!/bin/bash
> set -e
> set -x
> drop_upstart() {
> ver=$1
> pkg=$2
> job=$2
> if [ -n "$4" ]
> then
> job=$3
> fi
> echo "rm_conffile /etc/init/$job.conf $ver~ $pkg" >> $pkg.maintscript
> }
> dch -i 'Drop upstart system jobs.'
> ver=$(parsechangelog | sed -n 's/Version: //p')
> pushd debian
> for f in *.upstart
> do
> drop_upstart $ver $(echo $f | sed 's/\./ /g')
> rm $f
> done
> popd
> 8<
Re: Bug#801837: ITP: yank -- interactively select and yank terminal output to stdout or xsel
Le jeudi 15 octobre 2015, 11:29:00 Sébastien Delafond a écrit : > On Oct/15, Jakub Wilk wrote: > > Sounds very cool, but apt-file tells me this name is already taken: > > > > emboss: /usr/bin/yank > > I think I'll keep the package name, but I'll install the binary itself > under some other name, maybe something like /usr/bin/yank-cli ? > > Cheers, > > --Seb > Hi, from [1], I see that emboss ships 261 programs in /usr/bin/ including cool names like "banana", "chaos", "needle", "water", "wobble" ... so this means all these names can't be re-used forerver :-( Current /usr/bin/yank [2] is 10 lines of code, the new tool seems more usefull for more users; and from the animated .gif on the project page, it's supposed to be something short that's called frequently, so the contrived name with the hypen will make it hard to use... Maybe this can be also be solved by documenting how to set a bash alias, or a symlink in /usr/local/bin . [1] https://packages.debian.org/sid/amd64/emboss/filelist [2] https://sources.debian.net/src/emboss/6.6.0%2Bdfsg-1/emboss/yank.c/ [3] https://github.com/mptre/yank Greets, Alexandre Detiste signature.asc Description: This is a digitally signed message part.
Re: (newbie) Disruptive LIRC package update.
Le dimanche 8 novembre 2015, 19:28:38 Dominique Dumont a écrit : > > If I rephrase, with the current setup, 'service lirc start' starts 4 daemon > processes. > > Which means the user only has to type one command to start and stop all of > them. > > With the new setup. the user will have to deal with 4 systemd services (one > per daemon) and will have to run 4 systemctl commands to start or stop lirc. > > Is that correct ? Or a systemd target can be defined to pull in these 4 services at once. Alexandre
Re: Ideas to improve dpkg/ucf with hooks
Le lundi 16 novembre 2015, 10:27:14 Marc Haber a écrit :
> On Sun, 15 Nov 2015 23:10:11 +0100, Wouter Verhelst
> wrote:
> >On Fri, Nov 13, 2015 at 05:47:41PM +0100, Marc Haber wrote:
> >> Regarding dpkg, its conffile handling is IMO beyond repair, it should
> >> be deprecated and later removed.
> >
> >Could you explain why?
>
> - It is documented to fail miserably when a conffile belonging to
> package A gets modified by package B. This is not relevant for
> Debian proper (since we forbid this constellation in Policy to cater
> for this shortcoming of our central package management tool), but
> making this possible would make package maintenance (e.g. sharing of
> a single conffile between packages) muche easier, and it would allow
> local administrators to have local "configuration" packages to roll
> out for basic site configuration without a full-fledged
> configuration management system.
There are conf files shared by various packages too, like
/etc/ethers is used by at least net-tools, nmap, dnsmasq-base .
There's also an accountability problem, because it's sometimes hard
to guess which packages own some files in /etc .
The dynamic files are not listed/matched with "dpkg -L" / "dpkg -S".
One way to find this info is doing
$ grep /etc/ /var/lib/dpkg/info/*.postrm
or
$ find /usr/share/man -type f -exec zgrep -l /etc/ {} \;
but that's not at all obvious.
(that's what I use to build the "cruft database").
But adding dynamic file support in dpkg is a lot of work.
Alexandre
Re: How shall I report a bug in the .deb packaging itself?
Le mardi 22 décembre 2015, 00:35:25 Robie Basak a écrit : > I had always assumed that this is the risk you take by using autoremove > and thus you need to pay attention to what you autoremove, which is for > example why unattended-upgrades is sensible by not doing it by default. Excepted that unattended-upgrades is changeing this behaviour right now because some users got their /boot filled with many differents kernel images over the time. https://github.com/mvo5/unattended-upgrades/commit/25ff94915a9fc99058839d16761cf029896cbe05 https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093 *) "apt-get autoremove" should always be safe; one can use apt-mark manual to pin pakcages *) "apt-get remove $(deborphan)" is more dangerous; and should be done manually; and then one can also build fake empty packages with equivs to register some -libs or -devel packages as needed by a local application. Greets, Alexandre signature.asc Description: This is a digitally signed message part.
Re: How shall I report a bug in the .deb packaging itself?
Le mardi 22 décembre 2015, 10:03:15 Ondřej Surý a écrit : > On Tue, Dec 22, 2015, at 09:37, Alexandre Detiste wrote: > > *) "apt-get remove $(deborphan)" is more dangerous; and should be done > > manually; > > and then one can also build fake empty packages with equivs to register > > some > > -libs or -devel packages as needed by a local application. > > Errr, why? Just use deborphan keep file: > > --add-keep, -A PKGS.. Never report PKGS. > --keep-file, -k FILE Use FILE to get/store info about kept > packages. > --list-keep, -LList the packages that are never reported. > --del-keep, -R PKGS.. Remove PKGS from the "keep" file. > --zero-keep, -ZRemove all packages from the "keep" file. I said "can", not "must". There's more than one way to do it (tm). The dummy package has some advantages: - "aptitude why" will give the correct answer, browsing aptitude TUI also - it can be stuffed in a local repository - that fasten duplicating one's setup on an other computer - it's much easier for this dummy package to Depends: on some -libs & -dev than to include a postinst script that modifies /var/lib/deborphan/keep the dummy package can then be expanded and provides some files in /etc/*.d/ PS: deborphan doesn't know about "Enhances:" :-( https://sources.debian.net/src/deborphan/1.7.28.8-0.2/src/pkginfo.c/ Cheers signature.asc Description: This is a digitally signed message part.
Bug#810304: ITP: stratagus -- Stratagus is a free cross-platform real-time strategy gaming engine.
Package: wnpp Severity: wishlist Owner: Alexandre Detiste * Package name: stratagus Version : 2.4.0 Upstream Author : Stratagus Team * URL : https://github.com/Wargus/ * License : GPL Programming Lang: C++ & Lua Description : Stratagus is a free cross-platform real-time strategy gaming engine. Stratagus is a fork of the Freecraft engine. This generic engine that can be used to play 'wargus' (Warcraft II or WCII-like "Aleonas Tales") or 'stargus' (StarCraft) games. Only wargus is in a good shape, it will be addressed in a other ITP. Stratagus was once in Debian, but got removed years ago when Freecraft was deemed in a better shape; nowadays "Freecraft" name seems to have vanished from the surface of the earth and only links to minecraft-y stuff. Thanks to the renewal of interrest brought by Stratagus's fork Wyrmsun; development is lively again with a third of four completely different team and long standing bugs have been fixed. I plan to first continue to fix the upstream-provided debian/ directory with help from other Debian-using contributors & then upload it to Debian inside the Games Team.
Re: Death to git://! Long live git://!
Hi, > http://blog.pault.ag/post/27268910152/usage-of-vcs-git-in-the-debian-archive > > Enter github.com/debian > > – IMHO, we should consider putting the repos that are already on > GitHub under Debian namespace, so that the team of maintainers > may be able to add new collaborators. I'd like to move my two native packages there: https://github.com/a-detiste/cruft https://github.com/a-detiste/cruft-ng but GitHub only allows to "Transfer this repository to another user or to an organization where you have admin rights." and then later confirms it: "You don’t have admin rights to Debian" So I could give personaly it to someone I trust from this team who would move it again to github.com/debian; that's weird. Greets, Alexandre signature.asc Description: This is a digitally signed message part.
Re: metapackages and setting config files in /etc and /home/dir
Le lundi 11 janvier 2016, 23:38:10 Stephan Foley a écrit : > Hello, let's say I have the following install: > > my_metapackage -> depends on windows_manager -> depends on lightdm -> > depends on xorg > > can I set the configuration files? For instance, can I set the lightdm > config in /etc or the windows_manager's config in /home/user? Or can > only the original package set this? Technicaly, yes you can do it & it will work; but it's agaisnt the policy so this package can never enter the archive; but it's not the goal anyway, so why not ? https://wiki.debian.org/ConfigPackages is a bit hard to follow & most tools support drop-in configuration files (/etc/$.d/ ) nowadays. I don't want to play the "I'll Show You Mine, If You Show Me Yours" game; but I couldn't find any example online, so here's one: https://github.com/a-detiste/detiste/ Does the name "my_metapackage" comes from there ? http://askubuntu.com/questions/33413/how-to-create-a-meta-package-that-automatically-installs-other-packages Make sure to pick a name that wouldn't match a possible future package official name. Alexandre Detiste
Re: Favoring systemd timers over cron files Re: Removing sysV init files
Le vendredi 15 janvier 2016, 21:58:18 Anthony DeRobertis a écrit : > On 01/15/2016 09:29 PM, Jens Reyer wrote: > > Does this also work somehow for e.g. foo-daily.service + > > foo-daily.timer being favored over /etc/cron.daily/foo? Next to a > > foo.service being favored over /etc/init.d/foo. Thanks and greets jre Hi, systemd-cron does that: https://sources.debian.net/src/systemd-cron/1.5.3-1/src/bin/systemd-crontab-generator.py/#L473 I also wrote a proposal for the policy here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770440 The only thing that systemd-cron needs to close last remaining bugs is a rewrite in a lower level language with a smaller runtime (C or C++) there's a rewrite done in Rust; butI have no idea on how to package that in Debian & the runtime is huge. That's only about 550 lines of python code to rewrite that read some textfiles in /etc/cron.d (crontabs) & output other text files in /run (systemd timers & service); I'll do that "someday". Then crontab would need to be spun out of cron.deb so that it could be shared by two implementations. > No, it won't work automatically. Cron doesn't look at systemd units. Vixie cron could be patched to also work this way to avoid noise in log files. > You could of course put something like this at the top of your > /etc/cron.daily/foo: > > if [ -d /run/systemd/system ]; then > exit 0; > fi >
Re: Facilitating external repositories
Le vendredi 12 juin 2015, 17:56:04 Wouter Verhelst a écrit : > On Fri, Jun 12, 2015 at 10:08:35AM +0200, Alexandre Detiste wrote: > > Le vendredi 12 juin 2015, 00:59:51 Wouter Verhelst a écrit : > > > On Thu, Jun 11, 2015 at 12:38:29PM +0200, Bálint Réczey wrote: > > > > I see eid-mw is built on for i386 and amd64, while I assume it would > > > > build and work perfectly on arm* laptops and computers as well: > > > > https://files.eid.belgium.be/debian/pool/main/e/eid-mw/ > > > > > > > > Cheers, > > > > Balint > > > > I was curious, so I tried it on Raspbian's "almost-armhf" architecture > > & it works ! The java applet is a bit slow, but some embedded > > application would use some other language. > > Good to know. I haven't tried this myself (enough work with other > things), but it's interesting none the less. > > Did you try running the test suite? If not, try running > EID_ROBOT_STYLE=manual make check > in a checkout of the build tree. This should tell you a bit more about > how well things work ;-) > Hi, I see there are now armhf packages in the repository \o/ https://files.eid.belgium.be/debian/pool/main/e/eid-mw/ But these doens't work anymore for me (viewer say "can't detect e-ID reader"; even when run as root, same device work on amd64 desktop); will have to dig this a bit further. lsusb list the ACR38 device correctly > (if you do find a bug, patches are welcome...) Here I guess ? https://github.com/Fedict/eid-mw/ An other thing I miss is eid...@packages.debian.org could this made to work even for the non-official packages "bikeshed" packages ? Alexandre signature.asc Description: This is a digitally signed message part.
Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space
Le mardi 23 février 2016, 15:57:11 Simon McVittie a écrit : > On Tue, 23 Feb 2016 at 15:45:59 +0100, Carl Chenet wrote: > > Description : Script to backup your data from a Debian system to a > > ftp space > > Backups via ftp? In 2016? It's a 45 lines shell script... maybe not worth packaging in Debian at all; https://gitlab.com/mytux/ftpbackup/blob/master/ftpbackup Er, it's not forbiden to have it's own little .deb in in it's onw little repository for this kind of trivial but usefull scripts.
Re: HTTPS in DEP-5
Le dimanche 6 mars 2016, 19:19:35 Bas Wijnen a écrit : > That. Https is good for our users. Even if the effect of this change is very > minor, we should show them that it should be the default everywhere. > Having https://incoming.debian.org/ would be nice too. Alexandre
Re: Bug#824152: ITP: ofxstatement -- Tool to convert proprietary bank statement to OFX format, suitable for importing to GnuCash.
Le vendredi 13 mai 2016, 01:18:03 Alexander GQ Gerasiov a écrit : > Package: wnpp > Severity: wishlist > Owner: Alexander GQ Gerasiov > > * Package name: ofxstatement > Version : 0.5.0 > Upstream Author : Andrey Lebedev > * URL : https://github.com/kedder/ofxstatement > * License : GPL > Programming Lang: Python > Description : Tool to convert proprietary bank statement to OFX format, > suitable for importing to GnuCash. > Hi, Do you also plan to ship all the 19 known plugins in the same package ? https://github.com/kedder/ofxstatement#known-plugins I'd personally use this one, but ITP'ing an extra package for only 70 lines of code doesn't seem like the right thing to do. https://github.com/TheoMarescaux/ofxstatement-be-ing/blob/master/src/ofxstatement/plugins/ingbe.py Greets, Alexandre
Re: Bug#824152: ITP: ofxstatement -- Tool to convert proprietary bank statement to OFX format, suitable for importing to GnuCash.
Le vendredi 13 mai 2016, 10:37:35 Alexander Gerasiov a écrit : > > Do you also plan to ship all the 19 known plugins in the same > > package ? https://github.com/kedder/ofxstatement#known-plugins > Not in ofxstatement, but in ofxstatement-plugin-name or ofxstatement-plugins. Hi, In my understanding, "package-plugins" are meant to extend functionality of "package"; where "package" can already be mostly usefull without the plugins. e.g.: "konqueror" suggests "konq-plugins" . In this case, ofxstatement is of absolutely no use by itself. Whoever made the pip3 package likely did understood that and also included ofxstatement-lithuanian & ofxstatement-czech in this archive. So I'd just roll everything, core + plugins, in one single package. > I was thinking about this. And would like to talk with guys from Python > apps packaging team. Team-maintained is a good idea. > Create separate package for every plugin looks like an overkill, may be > it would be better to merge them in one package. But since I'll put > them under team maintenance (I believe it's the right move), it would be > better to follow best practices. This is not python specific at all, it's just about trying to make packages where the metadata doesn't outweight the actual contents; & avoiding to put too much strain on ftp-masters, mirrors et all without any gain. Alexandre
Re: Bug#1078734: ITP: legacycrypt -- The legacycrypt module is a standalone version of https://docs.python.org/3/library/crypt.html (deprecated), to ease 3.13 transition.
Thank you for keeping an eye on this. There was an even more specific proposal of the Python Team to use the "python-zombie-*" namespace for all the modules removed by PEP594 and further future deprecation PEPs; this is based on the model of existing python-zombie-imp. https://peps.python.org/pep-0594/ I packaged python-zombie-telnetlib as a "native" package; it's a single file that will likely never change anymore. Someone could create a project on Pypi, maybe... we'll see. Here legacycrypt is an already established name, it can stay as python-legacycrypt. (?) Greetings Le ven. 18 oct. 2024 à 14:36, Guillem Jover a écrit : > > * URL : https://github.com/tiran/legacycrypt > > Description : The legacycrypt module is a standalone version of > > https://docs.python.org/3/library/crypt.html (crypt was removed in Python > > 3.13). > > This seems to be a python module only package, but its source package > name is not currently namespaced. Given that it has not yet passed NEW, > please namespace it with python- to avoid taking on the global namespace, > so that we do not "prevent" packaging something that for example installs > a command with the same name (or having to end up using a non-obvious one > for that, or requiring a future rename), so that it's easier to see what > it is about when doing archive-wide analysis from Sources, or dd-lists, > or even reading changelogs via stuff like apt-listchanges, like the rest > of the language specific teams are doing. :)
Bug#1088209: ITP: python-isal -- python bindings for Intel(R) Intelligent Storage Acceleration Library
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-isal Version : 1.7.1 Upstream Contact: Leiden University Medical Center * URL : https://pypi.org/project/isal/ * License : PSF-2 Programming Lang: Python Description : python bindings for ISA-L: Intel(R) Intelligent Storage Faster zlib and gzip compatible compression and decompression by providing Python bindings for the ISA-L library. This package provides Python bindings for the ISA-L library. The Intel(R) Intelligent Storage Acceleration Library (ISA-L) implements several key algorithms in assembly language. This includes a variety of functions to provide zlib/gzip-compatible compression. --- This is not a Medical software. I will package this inside the Debian Python Team. It's a dependency of asammdf CAN log analyser with ITP #1075926. Greetings
Bug#1088210: ITP: python-pyqtlet2 -- python Leaflet map wrapper for Qt bindings
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pyqtlet2 Version : 0.9.3 Upstream Contact: Leon Friedmann * URL : https://pypi.org/project/pyqtlet2/ * License : 3-Clause BSD License Programming Lang: Python Description : python Leaflet map wrapper for Qt bindings This is a fork of the repository pyqtlet from @skylarkdrones. Since the original repository is not further maintained. Since I find this package very useful for a map implementation in the QT environment, I want to further develop this package. - I will package this inside the Debian Python Team. It isa dependency of the asammdf -- GUI application used to analyse engine CAN logs Which has itself the ITP nr #1075926
Re: Bits from DPL / Feedback on attracting newcomers
Hi, Here's the default crontabs for debbugs. There do exists an handfull of other instances of debbugs, some might deviate from default settings. Greetings /usr/lib/debbugs/processall >/dev/null 7,22,37,52 * * * * https://bugs.debian.org/debbugs-source/debian/debian/crontab Le mar. 10 déc. 2024, 10:40, Gard Spreemann a écrit : > Absolutely. I of course also don't know whether it's just my e-mails > taking 10 minutes to reach the BTS, but I would suspect that a lot of > improvements can be had in the system's response time. > > > Best, > Gard >
Bug#1092483: ITP: python-dataset -- database abstraction layer
Package: wnpp Severity: wishlist Owner: Alexandre Detiste X-Debbugs-Cc: debian-devel@lists.debian.org, cjwat...@debian.org * Package name: python-dataset Version : 1.6.2 Upstream Contact: Friedrich Lindenberg * URL : https://github.com/pudo/dataset * License : MIT/X Programming Lang: Python Description : database abstraction layer This is a new dependency of Androguard 4.x This package will be maintained inside the Debian Python Team.
Re: Bug#1101376: ITP: package-assembler -- CLI tool to create necessary files for a Debian package
Please stop this series of troll packages.
---
package_name = subprocess.run("cat debian/control | grep Source | awk
'{{print $2}}'", shell=True, check=True, stdout=subprocess.PIPE, text=True)
Le mer. 26 mars 2025, 20:03, Luka Kubat a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Luka Kubat
> X-Debbugs-Cc: debian-devel@lists.debian.org, crypticvers...@gmail.com
>
> * Package name: package-assembler
> Version : 1.0.0
> Upstream Contact: Luka Kubat
> * URL : https://github.com/Crypticverse/package-assembler
> * License : GPL-3
> Programming Lang: Python
> Description : CLI tool to create necessary files for a Debian package
>
> The CLI tool simplifies the creation and modification of necessary
> metadata files
> for building and creating Debian packages. Based on user input, it can
> generate the control,
> changelog, and other needed files. There are a few options when running
> this tool: Create
> a new package, or add a new changelog entry using dch.
>
>
