Re: Bits from DPL / Feedback on attracting newcomers
2024, ഡിസം 5 2:05:19 AM Lucas Kanashiro : > https://debconf24.debconf.org/talks/74-attracting-and-retaining-new-contributors-insights-from-brazil/ > > There was some follow-up discussion in Hacker News after a LWN post about > this talk was published: > > https://lwn.net/Articles/987548/ > https://news.ycombinator.com/item?id=41599327 > > I think people interested on the subject can get some insights from the above > (comments from people not involved in the project; yes, we, people already > involved in the project, can be very biased). Also ignore some stupid > comments, expected in those public discussions. > > And yes, this is something that Debian as whole needs to do better. I want to comment about registering on wiki.debian.org and salsa.debian.org specifically. Can we setup a system for adding to allow list by DD signed emails (like how debian.net DNS changes are done)? Possibly for IP address allow list too. This would help a lot during events or for local groups where getting a wiki account takes sending an email and waiting. Now that I think about this idea, this would also help for salsa accounts. It takes many days to get a salsa account after an event and I usually have to ask them to use another git hosting service till that happens. A DD validating email address and IP address can address the spam concern. This will expand people who can authorize new accounts hugely. Also reduce load on current admins and wait time for new contributors.
Re: Should l10n packages be Recommends or Suggests?
On Thu, 2024-12-05 at 13:28 -0500, Theodore Ts'o wrote: > Well, it seems most of the people who are complaining about the > dependency (Depends / Recommends / Suggests) inflation are primarily > complaining about the disk space thatis involved. Localization is not only about disk space, but also manuals, spell checking, input method tools, fonts etc. being scattered all over the system. It does not make sense that everyone has to select his spell checker language from 50+ options he does not speak. Particularly annoying is that Thai terminal (xiterm+thai), which is preinstalled in Debian desktop and appears in launchers such as Gnome Shell when searching for terminals. Most people never use it. I even doubt that many Thai users use it since it is ancient and any terminal should support UTF-8 by now. Regards Stephan PS: I use various languages (de_DE, en_US, de_CH and id_ID), but I prefer to install them manually. signature.asc Description: This is a digitally signed message part
Re: Should l10n packages be Recommends or Suggests?
On Fri, Dec 6, 2024 at 6:59 AM Stephan Verbücheln wrote: > Localization is not only about disk space, but also manuals, spell > checking, input method tools, fonts etc. being scattered all over the > system. > > It does not make sense that everyone has to select his spell checker > language from 50+ options he does not speak. > > Particularly annoying is that Thai terminal (xiterm+thai), which is > preinstalled in Debian desktop and appears in launchers such as Gnome > Shell when searching for terminals. To clarify, this happens if you use the Live ISO (that uses Calamares) but not if you use the default netinst ISO. Thank you, Jeremy Bícha
Bug#1089147: ITP: gdbuspp -- Simple C++ based interface to implement D-Bus
Package: wnpp Severity: wishlist Owner: Marc Leeman X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gdbuspp Version : 4 Upstream Contact: OpenVPN Solutions LLC * URL : https://codeberg.org/OpenVPN/gdbuspp/ * License : AGPL-3+ Programming Lang: C++ Description : Simple C++ based interface to implement D-Bus This library provides a simpler C++ based interface to implement D-Bus into applications in a more C++ approach, based on the C++17 standard. This package is used as an abstraction layer between glib2-2.76 and openvpn3-client (>> 21). Just as `openvpn3-client` that is on mentors, I will need a sponsor to get it uploaded before I can upload the newer versions of openvpn3-client.
Re: Should l10n packages be Recommends or Suggests?
On 2024-12-05, Theodore Ts'o wrote: > Given recent discussions about depends vs recommends vs suggests > inflation, I'm thinking about down-prioritizing e2fsprogs-l10n from > recommends to suggests. I do think down prioritizing them makes sense in the current setup. Though I do also think we have a hole in our dependency system here. if I set my system up to be in entish, I don't want to chase translation files all over the package system. It should somehow just happen. This is just me writing something in a email hoping that someone else picks it up (this time) Package: foo Recommends: foo-LANG And then somehow tell apt how to expand LANG for all relevant languages. /Sune
Re: Should l10n packages be Recommends or Suggests?
Hi! On Fri, 2024-12-06 at 09:22:43 -, Sune Vuorela wrote: > Though I do also think we have a hole in our dependency system here. I think most of the needed pieces are there already though. > if I set my system up to be in entish, I don't want to chase translation > files all over the package system. It should somehow just happen. > > This is just me writing something in a email hoping that someone else > picks it up (this time) > > Package: foo > Recommends: foo-LANG > > And then somehow tell apt how to expand LANG for all relevant languages. Something like the following should already work: $ aptitude install \ '?narrow(?narrow(~Gculture::valarin,?reverse-Recommends(~i)),!~i)' Although of course it's not very user friendly, and it would need to expanded to cover virtual packages for example. But I guess it could be wrapped in some kind of l10n support helper. Or the packaging frontends could be extended to support this with an easier to use term. Thanks, Guillem
Re: [Summary]: Supporting alternative zlib implementations
On Sun, Nov 24, 2024 at 02:06:37AM +0100, Fay Stegerman wrote: > For example, if it can be made easy to install both and choose between zlib > and > zlib-ng at runtime, so it's easy to build APKs using either zlib or zlib-ng as > needed, downstream breakage can be avoided. Considering whether that can > reasonably be done doesn't seem like an unreasonable request to me. > What I would like is to be able to continue to use Debian for Reproducible > Builds regardless of what Google does or doesn't do. Right now that means > being > able to choose to keep using the original zlib for backwards compatibility. > If > Google switched to zlib-ng I would be asking if Debian could provide a way to > opt in to using that instead. TBH the whole situation here seems incredibly fragile - you're also vulnerable to someone making an improvement in the zlib compression code and changing the generated output that way. It feels like the wrong question is being asked here. signature.asc Description: PGP signature
Bug#1089186: ITP: buteo-sync-plugin-caldav -- Buteo plugin for syncing with CalDAV servers
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: buteo-sync-plugin-caldav Version : 0.3.14 Upstream Contact: https://sailfishos.org/contact/ * URL : https://github.com/sailfishos/buteo-sync-plugin-caldav/ * License : LGPL-2.1 Programming Lang: C++ Description : Buteo plugin for syncing with CalDAV servers The Buteo Synchronization Framework relies on plugins in order to synchronize with a variety of data sources. . This package provides a Buteo plugin to sync calendar data with a CalDAV server. . This package will be maintained by the Debian UBports Packaging Team.
Bug#1089195: ITP: pix -- Library for image conversion and compositing
Package: wnpp Severity: wishlist Owner: Mitchell Augustin X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pix Version : 0.13.4 Upstream Contact: Doug Lau * URL : https://github.com/DougLau/pix * License : Apache-2.0 or MIT Programming Lang: Rust Description : Library for image conversion and compositing A raster image can be cheaply converted to and from raw byte buffers, enabling interoperability with other crates. Many image formats are supported: Bit depth: 8- or 16-bit integer and 32-bit float Alpha: premultiplied or straight Gamma: linear or sRGB Color models: RGB / BGR (red, green, blue) CMY (cyan, magenta, yellow) Gray (luma / relative luminance) HSV (hue, saturation, value) HSL (hue, saturation, lightness) HWB (hue, whiteness, blackness) YCbCr (used by JPEG) Matte (alpha only) OkLab (lightness, green/red, blue/yellow) XYZ (CIE 1931 XYZ) This package is a dependency of asusctl, which I plan to package for debian. It will be maintained as part of the Debian rust team. It does need a sponsor.
Re: Should l10n packages be Recommends or Suggests?
> "Josh" == Josh Triplett writes: Josh> In the future, I hope we have a more fine-grained mechanism Josh> that allows saying "X recommends Y if Z is installed" (or even Josh> "X depends on Y if Z is installed"). I'd really like this, both for Debian work and for downstream work on Debian derived systems. --Sam
Bug#1089168: ITP: python-sluurp -- launch shell scripts through slurm SBATCH command
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team Owner: Roland Mas Severity: wishlist * Package name: python-sluurp Version : 1.1.0 Upstream Contact: Henri Payno * URL : https://gitlab.esrf.fr/tomotools/nxtomomill * License : MIT Programming Lang: Python Description : launch shell scripts through slurm SBATCH command sluurp is a Python package providing an API to launch shell scripts through slurm's SBATCH command.
Bug#1089169: ITP: tomwer -- tomography workflow tools
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org, Debian PaN Maintainers Owner: Roland Mas Severity: wishlist * Package name: tomwer Version : 1.3.0 Upstream Contact: Henri Payno * URL : https://gitlab.esrf.fr/tomotools/tomwer * License : MIT Programming Lang: Python Description : tomography workflow tools tomwer is offering tools to automate acquisition and reconstruction processes for Tomography. It contains: . - a library to access each acquisition process individually; - gui and applications to control main processes (reconstruction, data transfer...) and execute them as a stand alone application; - an orange add-on to help users defining their own workflow.
Re: Plasma 6 coming to unstable
Le mercredi 4 décembre 2024, 13:01:12 UTC+1 Jonathan Carter a écrit : > On 2024/12/04 11:04, Aurélien COUDERC wrote: > > Plasma 6 has now migrated to testing/trixie and things are looking pretty > > good. > > That's great news! Thanks for all the work! … and I won’t take it personally. There are many people to thank for this from our dear upstream KDE contributors to the Debian Qt/KDE team members or adventurous users who tried our early experimental packages and provided valuable feedback. I’ll just mention the Qt/KDE team members whether established (Patrick, Pino, Sandro, Scarlett, Simon), somewhat new to the team (Jesse, Nicholas, Salvo) or old-timers still lingering around (Dmitry, Lisandro, Sune ;). They’ve done most of the packaging work on our 36 Qt6, 72 KDE Frameworks 6, 63 Plasma 6, nearly 250 KDE Gear (applications) and various other supporting libraries’ source packages producing more than a thousand binary packages, and on the automation tooling around it. A mention to the FTP Masters team for keeping up with our so many new packages during the 5 to 6 transition. Another mention to Rik Mills from Kubuntu for always providing insightful feedback and helping keep our packaging divergence to a minimum. And a special thanks again to Patrick for inspiring, driving or doing so much of the work. Happy hacking, -- Aurélien
Bug#1089176: ITP: node-svgdotjs-svg.js -- Lightweight library for manipulating and animating SVG
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-svgdotjs-svg.js Version : 3.2.4 Upstream Contact: Wout Fierens * URL : https://svgjs.dev/ * License : Expat Programming Lang: Node.js Description : Lightweight library for manipulating and animating SVG node-svgdotjs-svg.js is a lightweight library for manipulating and animating SVG; it has no dependencies, except Node.js, and aims to be as small as possible while providing close to complete coverage of the SVG spec. . Current features: . * animations on size, position, transformations, color, ... * painless extension thanks to the modular structure * various useful plugins available * unified api between shape types with move, size, center, ... * binding events to elements * full support for opacity masks and clipping paths * text paths, even animated * element groups * dynamic gradients and patterns * fully documented --- I uploaded the package to https://salsa.debian.org/js-team/node-svgdotjs-svg.js and I aim at maintaining it as a recommendation for the package slm which I own. . The ultimate goal (for my concern) is to support an easy way to edit digraphs in an interactive web page, and make it easier to specify a graph of dependencies which depicts books to be lent to students in a high school. However this package can have much more general use cases.
Re: [Summary]: Supporting alternative zlib implementations
On Fri, Nov 22, 2024 at 12:29:51PM +0100, Guillem Jover wrote: > [ I'll try to summarize the current discussion and status, what might > be blockers, and a potential incremental way forward. ] You CCed some people but not me so I only saw this today... > On Wed, 2024-09-25 at 10:48:50 +0200, Mark Brown wrote: > > On Tue, Sep 24, 2024 at 05:45:49PM +0200, Guillem Jover wrote: > > We do OTOH package more software than most distros on more architectures > > so we got a lot more exposure for testing coverage, and the revert would > > involve switching the entire implementation which complicates things a > > bit compared to a risky patch within a package. I'm not totally > > opposed, and if everything goes smoothly we could definitely implement > > it within the timeframe, but it feels like an impactful change to > > introduce now not having considered it sooner. > True, also two months have passed since (that's on me!). At this time, > I'm now not sure whether it is feasible to consider such a switch, even > if there was agreement to do it. As it is, I think there are too many > unknowns! It does seem more safe to offer zlib-ng as an alternative at this point... > I did that, and the current WIP zlib-ng packaging provides now two > builds, one with the new native zng_* API and another (tentatively) > with the compat API/ABI one in libz-dev and libz1 binary packages. > I've tentatively chosen those package names for the compat libraries > to avoid having to go through NEW multiple times (with the assumption > that we'd either go ahead with the switch or the packages could then > simply be dropped). I think this should initially only be uploaded to > experimental, to avoid getting packages built with either zlib or > zlib-ng. But depending on the outcome of this discussion, I think other > (probably better) options would be to perhaps name the compat packages > something like libz-ng-compat*, or drop them completely? The packages could have a different name and support diversion or replacement of the zlib library packages? That'd let people use them if they wanted to. > * I've had concerns both about providing the zlib compat API and the > native zlib-ng API in sid, and then getting a mess of packages > linking against (true) zlib and against (native) zlib-ng, or > packages relying on specific behaviors from either and breaking > when switching from (true) zlib to zlib-ng-compat or vice versa, > for example. What are those concerns? Like Simon says the zlib and zlib-ng APIs are just two separate APIs, they happen to have overlapping functionality but while that might be a bit wasteful it's not obvious that there's any actual problem. > * There were concerns (from Fay) about the output stream changing due > to a potential implementation switch and that affecting external > reproducibility. Personally I think while I can see how this is > annoying for the involved parties, it's part of the "you need > the same tools to generate the same output" premise that we also > assume in Debian. I guess keeping both implementations around > indefinitely, I think, would make this less of an issue, with the > potential drawbacks mentioned in the previous point. Yes, I don't think this should be a blocker - this seems like it's on a similar level to needing to use the same compilers. > * There was a concern (from Mike) about whether the performance gain > at the cost of stream size makes sense, given that the compression > level could be reduced instead to similar effect (?). I'm not sure > how these compare, so it would be interesting to analyze this, > because perhaps that's a less traumatic way to look at it (but that > might require redefining compression level semantics globally in > zlib, or patching users, with neither look very enticing options). > My perception from when I tested it is that the speed up was > significant enough and the size increase not so much, but… In any > case switching to zlib-ng upstream would also imply other benefits, > like (supposedly) a more responsive upstream with more frequent > releases, the new native API, and an implementation other > distributions are switching to. > * Some upstreams have started to use the zlib-ng native API, so > regardless of whether we plan a switch or not, I guess packaging > zlib-ng (w/ or w/ the compat API) might still make sense. Yes, it seems clear that we should package zlib-ng and there's just a question about handling of the compat interface it provides. > After having written the above, and if Mark agrees, I think I'd opt for > uploading zlib-ng to experimental, with the compat packages renamed to > libz-ng-compat* or similar (even if that implies later on another trip > through NEW if we want to perform a full switch), because that might > make it easier to move them to sid as a way less disruptive change, > even if we deci
