ITP: node-markdown-it -- FIX_ME write the Debian package description
Package: markdown-it Severity: wishlist Owner: Sakshi Sangwan * Package name: node-markdown-it Version : 10.0.0 Upstream Author : Vitaly Puzrin, Alex Kocharin * URL : https://github.com/markdown-it/markdown-it#readme * License : Expat Programming Lang: JavaScript Description : Fast and easy to extend markdown parser Follows the CommonMark spec, adds syntax extensions and sugar (URL autolinking, typographer). Provides configurable syntax, can add new rules and even replace existing ones, and high speed . Node.js is an event-based server-side JavaScript engine. This is a dependency of Gitlab. Best, Sakshi
Re: Heads up: persistent journal has been enabled in systemd
Hi Michael, On Sat, Feb 01, 2020 at 04:05:55AM +0100, Michael Biebl wrote: > with today's upload of systemd 244.1-2 I finally enabled persistent > journal by default [1]. It has been a long requested feature. Thank you. > Users that prefer text logs can of course still install rsyslog by > default (or their syslogger of choice). I am an early adopter (at a time when you had to pass init= to use systemd) and I also enabled the persistent journal on practically all of my systems. I find myself liking the filtering that is enabled by journalctl, but it seems to come at a cost: performance. On multiple systems (embedded, VMs, desktops, servers) I observe that journalctl takes longer to display the initial batch than I am willing to wait. Unfortunately, this also affects systemctl status. I admit that my patience is quite limited here. Having to wait 3 seconds for systemctl status someservice is already more than I am willing to wait. As such, I find myself resorting to plaintext logs more often than not to avoid the annoying delay. It gets way worse on a busy system where you'd need the journal most to figure out what's wrong. Do you happen to know more about the performance aspects? * Known discussions? -> https://github.com/systemd/systemd/issues/2460 * Workarounds / tricks? -> I already apply a size limit. Memory consumption by journald itself is also worth a mention. For servers, I usually don't care, but for embedded systems it is sometimes difficult to afford. rsyslog comes at around a fifth of what journald needs. As such, I question whether the journal is ready for production while at the same time wanting it to be. I believe that the github issue above should be fixed before enabling the persistent journal by default. Helmut
Re: News about the debhelper toolchain
Hideki Yamane: > On Mon, 10 Feb 2020 21:37:05 +0100 > Niels Thykier wrote: >> Remember to *remove* "--with python3" from d/rules as well. An explicit >> "--with python3" will cause issues with Build-Depends-Indep and other >> conditional usage (e.g. build-profiles). > > And does lintian warns it? > > Not sure; I have not tracked the lintian side of things. Though if it does not, please file a bug against lintian. ~Niels
Bug#951098: ITP: ruby-rspec-puppet-facts -- Library containing facts from many Facter versions on many Operating Systems
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-rspec-puppet-facts Version : 1.10.0 Upstream Author : Mickaël Canévet * URL : https://github.com/mcanevet/rspec-puppet-facts * License : Apache-2.0 Programming Lang: Ruby Description : Library containing facts from many Facter versions on many Operating Systems With this library, simplify your unit tests by looping on every supported Operating System and populating facts (provided by facterdb). This simplifies unit testing because you don't need to specify the facts yourself. This library is very useful for writing tests when working on a puppet module. It also makes it very fast to setup a CI environment for your modules. This library is used by puppet-development-kit as a requirement in order to provide an easier framework and workflow for puppet module development. I intend to maintain this module within the ruby team and I will ask for sponsorship within the team.
Bug#951097: ITP: ruby-spdx-licenses -- Library for looking up and identifying SPDX licences
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-spdx-licenses Version : 1.2.0 Upstream Author : Dominic Cleal * URL : https://github.com/domcleal/spdx-licenses * License : Expat Programming Lang: Ruby Description : Library for looking up and identifying SPDX licences This library can lookup a list of SPDX licences on spdx.org, and provide them as a list of information that can be handled by your code. You can also use this to lookup whether a certain licence is an SPDX license or not, and thus programatically identify certain licences in code or other structured information. This library is a dependency to metadata-json-lint, which in turn is needed for packaging puppet-development-kit (pdk) which I'm working towards packaging. I intend to maintain this within the ruby team, and will ask for a sponsor within the team.
Re: News about the debhelper toolchain
On Mon, 10 Feb 2020 21:37:05 +0100 Niels Thykier wrote: > Remember to *remove* "--with python3" from d/rules as well. An explicit > "--with python3" will cause issues with Build-Depends-Indep and other > conditional usage (e.g. build-profiles). And does lintian warns it? -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Re: Salsa CI news
On 2/10/20 7:17 AM, Dmitry Smirnov wrote: > It appears to me that Salsa admins don't use packaged Gitlab-Runner simply > because they don't want to, and I don't understand why. Seriously, stop that. Instead of complaining, you could send tested patches: https://salsa.debian.org/salsa/salsa-ansible/tree/master/roles/gitlab-runner -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Debian With Alternate Init Systems
Hi! Am 10.02.2020 um 12:18 schrieb Svante Signell: > I would really like to know what the second part of the sentence > "Systemd but we > support exploring alternatives" means. in debian terms, if someone likes to send patches and they don't break anything, they are welcome, but patches which enable systemd specific behavior are not rejected for not supporting other systems. if the patches are nice enough to challenge systemd they will be discussed. greetings
Re: Y2038 - best way forward in Debian?
* Ben Hutchings: > On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote: >> * Ben Hutchings: >> >> > If I recall correctly, glibc *will* provide both entry points, so there >> > is no ABI break. But the size of time_t (etc.) exposed through libc- >> > dev is fixed at glibc build time. >> >> Is this a Debian-specific decision? > > I though that was the *upstream* decision, but perhaps that's still not > decided after all? There's going to be a _TIME_BITS selector, similar to _FILE_OFFSET_BITS. There was a proposal to have only one API before, but I think the agreement was that it wouldn't save much complexity.
Re: News about the debhelper toolchain
Hideki Yamane: > On Sat, 1 Feb 2020 15:38:14 +0100 > Niels Thykier wrote: >> * The "dh-sequence- build-dependency" to replace the >>"--with " parameter to dh in the debian/rules. >>- Note that third-party add-ons may not have added the relevant >> Provides to support this change. > > Build-Depends: debhelper (>= 10~), dh-python3, > ↓ > Build-Depends: debhelper-compat (= 12), > Build-Depends-Indep: dh-sequence-python3, > > like this? > > Yes, this is now possible in general. :) I have not tested concretely whether dh-sequence-python3 supports being put into Build-Depends-Indep (but it probably does). Remember to *remove* "--with python3" from d/rules as well. An explicit "--with python3" will cause issues with Build-Depends-Indep and other conditional usage (e.g. build-profiles). ~Niels
Re: Debian With Alternate Init Systems
Hello, Svante Signell, le lun. 10 févr. 2020 12:18:37 +0100, a ecrit: > On Sat, 2020-02-08 at 16:40 +0100, Samuel Thibault wrote: > > > Nice, the first thing I'll do is to shut down the Debian/GNU Hurd > > > buildd mahler. > > > Can't you see you are here exactly very precisely here *again* putting > > pressure to get something through? > > It is not about pressure, definitely not! That is however how, I believe, everybody understood it. > It's frustration on you trying to punish me for having an opinion. I am not trying to "punish" (I don't even see how that would happen). I am telling Sam that we have never managed to make you change the *way* you are expressing your opinions through pressure. > What do you think would be obtained with the above words? That you perhaps at least understand that what you were writing above *is* pressure, even if you don't realize it when writing it. > BTW: How many euros do you think having a buildd running 24/7 cost me > personally > every month? I'm spending a large amount of my time supporting free software, > including hosting several buildds (without a single (euro)cent in funding). I really appreciate the effort you spend here, I am grateful for that. > > Really, please grow up. You have already worded such a threat in the > > past. That's at best childish. > > I'm asking you to apologize for what you just wrote. The above is an outright > insult to me. Right. I apologize for this sentence, I didn't mean to make it an insult. The thing is: at some point I don't know how to explain that the way you are engaging discussions is most often immediately with big words and everything, and that it's not Okay. On the d-i init question, there hasn't even been any discussion on debian-boot (and thus no worded opposition), and then you already said that some developers "out to leave the project". That's really not a good way to start a discussion... And this is a recurrent scheme I have seen on IRC etc., your starting topics is most often already "isn't it about time to do [...]?". Honestly, when I see such a start, I have no other will than working on something else than what you are talking about, and thus your way of suggesting improvements is actually completely anti-productive. If you simply worded it "could we perhaps do [...]?" things would flow way better. And similarly on d-i init, discussion can lead to compromises. I guess you'll again find this coward, like you already said previously, but really, long-term wise, I have seen it work way better than immediate battles that rather antagonize people. Samuel
Re: Debian With Alternate Init Systems
On Mon, Feb 10, 2020 at 06:27:55PM +0100, Svante Signell wrote: Not much space for other init systems than systemd within Debian. I was hoping for too much. Let's move on with our lives. I think we'd all appreciate if you would do that and stop sending messages about systemd!
Re: CI vs Releases (was: Upstream rolling releases and version control)
On 2020-02-10 17:40:47 +0100 (+0100), Simon Richter wrote: [...] > It can absolutely be done, and I'm doing that myself, but I often > find myself fighting implicit assumptions in the framework, and > either I'm doing it entirely wrong or these assumptions apply to > the majority of users. No, I think that's an entirely fair assessment. If you don't build the CI system yourself (and most folks don't), you end up fitting your release models to the tools you have rather than fitting the tools to the release models you want. > The most annoying instance is that there is a notion of a single > "current" state for every project and dependency. I can set up a > copy of my pipeline to implement a "stable" or "production" > variant, but I have yet to see a CI system that is powerful enough > to analyze a stable branch for regressions compared to the > branch-off point without a lot of hand-holding. For each release > branch, I find myself copying the existing pipelines and pointing > the new instances at the new branch. At least the open source CI system we're using (Zuul) considers every branch of every Git repository as a current state, though it's also less concerned with "current" states of repos than it is with speculative future states since it's technically more of a project gating system than traditional CI. Testing every commit in context before it's allowed to merge reduces the risk that you pick a bad branch point. Also having the ability to branch your job configuration along with your source code makes a big difference when it comes to handling behavior needs for stable maintenance, and avoiding development in master from bleeding into those stable jobs. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Debian With Alternate Init Systems
(leaving the other parts of threads to later, when I'll get time to think what useful answer I can give, beyond just apologizing) Svante Signell, le lun. 10 févr. 2020 18:27:55 +0100, a ecrit: > Regarding your opinion about the GR becomes very clear by reading > https://hartmans.livejournal.com/99395.html again. > Not much more to comment about that. This part is especially interesting: > "Proposal B is a systemd focused proposal. It's very similar to Proposal F. > The > text is different, but the implications of both proposals are similar." > > Not much space for other init systems than systemd within Debian. Please also quote: « My experience is that key maintainers and teams maintaining central infrastructure or packages often need to work with people who are trying to integrate new features. The difference between Proposal B and F is that under Proposal B, we commit to making that happen for technologies that are important in exploring alternatives to systemd. » That *does* leave space for other init systems. Much more than F would have. Samuel
Re: Debian With Alternate Init Systems
Back on debian-devel. On Mon, 2020-02-10 at 14:22 +, Sam Hartman wrote: >From a private reply to me from Sam: > I hear your frustration at Samuel's message. I want Samuel to apologize on _this_ email list for insulting me. Regarding your opinion about the GR becomes very clear by reading https://hartmans.livejournal.com/99395.html again. Not much more to comment about that. This part is especially interesting: "Proposal B is a systemd focused proposal. It's very similar to Proposal F. The text is different, but the implications of both proposals are similar." Not much space for other init systems than systemd within Debian. I was hoping for too much. Let's move on with our lives. Thanks!
Re: CI vs Releases (was: Upstream rolling releases and version control)
Hi, On Mon, Feb 10, 2020 at 01:17:02PM +, Jeremy Stanley wrote: > > CI and releases are kind of antithetical. They wouldn't have to > > be, but this is the way the culture around CI developed. > As someone who's helped for nearly a decade to maintain CI-driven > release automation for a very large community of projects, I'm > actually curious what you see as culturally incompatible between the > two. It may be the communities I'm most embedded in don't suffer > this cultural rift, but it's also entirely possible I've got some > sort of tunnel vision preventing me from seeing it. It can absolutely be done, and I'm doing that myself, but I often find myself fighting implicit assumptions in the framework, and either I'm doing it entirely wrong or these assumptions apply to the majority of users. The most annoying instance is that there is a notion of a single "current" state for every project and dependency. I can set up a copy of my pipeline to implement a "stable" or "production" variant, but I have yet to see a CI system that is powerful enough to analyze a stable branch for regressions compared to the branch-off point without a lot of hand-holding. For each release branch, I find myself copying the existing pipelines and pointing the new instances at the new branch. Simon
Bug#951065: ITP: ukui-sidebar -- parallels toolbox for UKUI
Package: wnpp Severity: wishlist Owner: handsome_feng * Package name: ukui-sidebar Version : 1.0.0 Upstream Author : Chen Chunan * URL : http://github.com/ukui/ukui-sidebar * License : GPL-3+ Programming Lang: C++ Description : parallels toolbox for UKUI The ukui-sidebar is mainly used in the desktop operating system. It pops up from the right side of the desktop in the form of a tray, displaying some application notification messages and some cutting storage information. Thanks!
CI vs Releases (was: Upstream rolling releases and version control)
On 2020-02-10 11:35:06 +0100 (+0100), Simon Richter wrote: [...] > CI and releases are kind of antithetical. They wouldn't have to > be, but this is the way the culture around CI developed. [...] As someone who's helped for nearly a decade to maintain CI-driven release automation for a very large community of projects, I'm actually curious what you see as culturally incompatible between the two. It may be the communities I'm most embedded in don't suffer this cultural rift, but it's also entirely possible I've got some sort of tunnel vision preventing me from seeing it. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Debian With Alternate Init Systems
Sam: This reply is addressed to Samuel and another to you follows, then I'll shut up. On Sat, 2020-02-08 at 16:40 +0100, Samuel Thibault wrote: > > Nice, the first thing I'll do is to shut down the Debian/GNU Hurd > > buildd mahler. > Can't you see you are here exactly very precisely here *again* putting > pressure to get something through? It is not about pressure, definitely not! It's frustration on you trying to punish me for having an opinion. What do you think would be obtained with the above words? BTW: How many euros do you think having a buildd running 24/7 cost me personally every month? I'm spending a large amount of my time supporting free software, including hosting several buildds (without a single (euro)cent in funding). > Really, please grow up. You have already worded such a threat in the > past. That's at best childish. I'm asking you to apologize for what you just wrote. The above is an outright insult to me. And you are talking about pressure! Which is the most polite way to communicate?
Re: Debian With Alternate Init Systems
Sam: This reply is addressed to you, and another to Samuel, then I'll shut up. On Sat, 2020-02-08 at 08:27 -0500, Sam Hartman wrote: > I can't speak for anyone else, but yeah I've come to my own conclusions. > I was fairly open about them: > https://hartmans.livejournal.com/99395.html > > For myself I've concluded that systemd (at least for Linux) is far > better than anything else out there today. My question is merely: You believe that systemd is the best solution at the moment for Linux. Of course your opinion is fully respected. However, there are a number of Debian Developers, Maintainers and Users that would like to use something "inferior" like sysvinit, openrc, runit, s6 or Shepherd. These users are blocked from using these init systems on Debian (they can be used with a lot of manual intervention but that requires non-trivial knowledge). I would really like to know what the second part of the sentence "Systemd but we support exploring alternatives" means. > Something else might come along tomorrow even better than systemd. Thank you for your time!
Upstream rolling releases and version control
Hi, On Mon, Feb 10, 2020 at 05:17:38PM +1100, Dmitry Smirnov wrote: > In case of Gitlab I recognise that Salsa could not be maintained from the > official packages. They are too fragile, often uninstallable even in > "unstable" and depend on unofficial "fasttrack" repository. There are too > many dependencies and things get broken far to often in too many places. > In theory Gitlab could be in a better shape with larger team, but in the > current situation I see why Salsa operates from vendor container image and it > is reasonable. If the packages are unusable for us, then they are likely to be unusable for a lot of other people as well. If it's the nature of the software that stable releases don't make sense, then not having them as part of a stable release is a sound technical decision. I've filed RC bugs "this package should not be part of a stable release" against my own packages a few times already when it looked as if upstream was unable or unwilling to support anything but the bleeding edge versions. CI and releases are kind of antithetical. They wouldn't have to be, but this is the way the culture around CI developed. >From a Debian POV, we should have a discussion on what that means for packaging: - how do we handle packages that have no stable releases at all? Some packages, like piglit, are still useful even as a frozen-in-time development version. On the other end of the scale, we have clients for protocols that change often as the service develops, and where users are expected to upgrade to the latest client. - how can we better integrate different package ecosystems? There are a lot of language-specific package managers, like npm, build systems that pull in packages like gradle, and services like docker that all provide package management that runs in parallel with .deb packages, and has different update policies than the Debian archive. - how can we better integrate non-Debian version control? Fundamentally, the Debian archive is a kind of early distributed version control system, implemented on top of dumb file storage and file transfer protocols. If we exchange the lower layers, then suddenly the upper layers reimplement part of their functionality in a conflicting way, which is why building packages from git is a mess of scripts. All three are long-overdue discussions on how to adapt to the changing times. Simon
Re: Heads up: persistent journal has been enabled in systemd
On 2/4/20 8:30 PM, Russ Allbery wrote: > Dmitry Smirnov writes: >> On Saturday, 1 February 2020 2:05:55 PM AEDT Michael Biebl wrote: > >>> Depending on how it goes, I might ask the ftp-masters to lower the >>> priority of rsyslog from important to optional, so it would no longer >>> be installed by default on new bullseye installations. > >> I have a mixed feelings about that. I think that replacing rsyslog with >> journald is two steps back in regards to functionality and flexibility. > >> Rsyslog in unparalleled with its ability to process and filter messages >> (rainerscript), to transform messages (liblognorm), to forward messages >> to Elasticsearch or centralise Rsyslog instance, _reliably_ (relp), to >> buffer message queue on disk in case communication is disrupted, etc. > > I completely agree with this assessment of the quality of rsyslog > features, but I'm not sure that's the right criteria to be considering for > the choice of the *default*. I'm fairly certain that 95% or more of > installed Debian systems never used any of those features, as nice as they > are. > > The goal of the default is not to provide in latent form every excellent > feature that anyone may want to use. It's to provide a hopefully simple, > reliable, functional, and light-weight implementation of a facility that > serves as a reasonable default for most systems. Anyone with other needs > or preferences is very likely to replace or supplement that implementation > with something else, similar to how I replace exim4 with postfix on all of > my systems. I'm ok with this reasoning, however, rsyslogd is also a reasonable default, and I don't see why it wouldn't be good for the general use also. The main problem with journald is that it can't keep-up with too much syslog traffic and doesn't scale. I'd very much prefer if our default was a solution that works on *all* cases, rather than just the one for a specific target. Cheers, Thomas Goirand (zigo)
Re: News about the debhelper toolchain
On Sat, 1 Feb 2020 15:38:14 +0100 Niels Thykier wrote: > * The "dh-sequence- build-dependency" to replace the >"--with " parameter to dh in the debian/rules. >- Note that third-party add-ons may not have added the relevant > Provides to support this change. Build-Depends: debhelper (>= 10~), dh-python3, ↓ Build-Depends: debhelper-compat (= 12), Build-Depends-Indep: dh-sequence-python3, like this? -- Hideki Yamane
