Opportunités de rejoindre Freexian et contribuer à Debian

Bonjour, je voulais attirer votre attention sur l'annonce que l'on vient de poster sur debian-jobs: https://lists.debian.org/debian-jobs/2024/03/msg2.html Freexian s'est pas mal développé ses dernières années et pour accompagner notre croissance nous avons besoin d'aide sur des domaines plus

Re: Issues in the Patch Tagging Guidelines

Hi, On Tue, 08 Aug 2023, Guillem Jover wrote: > Lately I've been updating metadata in patches in packages I maintain and > noticed several issues with the Patch Tagging Guidelines, and after Lucas > created the new great patches UDD service [P] and we discussed some > other issues there, it

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

On Fri, 09 Jun 2023, Marco d'Itri wrote: > On Jun 08, Raphael Hertzog wrote: > > > In the same spirit, I'd like to throw an idea... could we decide that > > base-files is the first package to be configured as part of the bootstrap > > protocol and change base-fi

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Hi, On Wed, 17 May 2023, Helmut Grohne wrote: > For completeness sake, there is one more entry in category 3: We can run > the dynamic loader from its canonical location explicitly, so we'd > modify maintainer scripts to start with: > > #!/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

Re: DEP 17: Improve support for directory aliasing in dpkg

Hello, On Tue, 02 May 2023, Helmut Grohne wrote: > I think there is a caveat (whose severity I am unsure about): In order > to rely on this (and on DEP 17), we will likely have versioned > Pre-Depends on dpkg. Can we reasonably rule out the case where and old > dpkg is running, unpacking a fixed

Re: DEP 17: Improve support for directory aliasing in dpkg

Hello, On Wed, 26 Apr 2023, Simon Richter wrote: > > This and /bin/sh is the kind of files I'd consider important. And then > > upon thinking further it became more and more difficult for me to make > > sense of the objection. On a merged system, we can just move that file > > to its canonical

Re: DEP 17: Improve support for directory aliasing in dpkg

On Tue, 25 Apr 2023, Luca Boccassi wrote: > Brilliant! Would never have thought of using divert like that. +1 Nice trick. > So, what work would need to happen to make this reality? Do we need > tooling/scripts/build changes to support the divert scheme, or is it > "simply" a matter of

Re: DEP 17: Improve support for directory aliasing in dpkg

Hello, On Sat, 22 Apr 2023, Helmut Grohne wrote: > This is looking at it from a performance point of view. Guillem also > raised that this is changing the source of truth from the dpkg database > to the actual filesystem, which Guillem considers wrong and I find that > vaguely agreeable. smcv

Re: DEP 17: Improve support for directory aliasing in dpkg

Hello, I'd like to offer some food for thoughts on this issue. >From what I have understood, Guillem would rather avoid committing to a new public interface for this specific use-case, i.e. the fact that the DEP is suggesting "dpkg --add-alias" is problematic because that feature will be useless

Re: DEP 17: Improve support for directory aliasing in dpkg

Hello, On Mon, 03 Apr 2023, Helmut Grohne wrote: > Please consider it to be a piece of best > intentions at reconciling feedback wherever I could. At the time of this > writing it certainly is not consensus, but consensus is what I seek > here. Without further ado, the full DEP text follows

Re: Rejoindre Freexian pour aider à améliorer Debian

Salut, On Wed, 30 Mar 2022, Pierre-Elliott Bécue wrote: > > [1] https://www.freexian.com/apropos/index.html#ambition > > [2] https://www.freexian.com/apropos/index.html#mission > > [3] https://www.freexian.com/apropos/join-us.html > > Je pense que c'est cool de publier ce genre de choses ici,

Rejoindre Freexian pour aider à améliorer Debian

Bonjour, je voulais vous informer que Freexian s'est fixé des objectifs ambitieux[1] en soutien de Debian et que nous voulons étoffer l'équipe pour atteindre ces objectifs. Nous avons rédigé un énoncé de mission[2] pour clarifier notre raison d'être et nos valeurs, et nous espérons attirer des

Re: What are the most important projects that Debian ought to work on?

On Wed, 23 Feb 2022, Andreas Tille wrote: > Am Tue, Feb 22, 2022 at 04:46:23PM +0100 schrieb Raphael Hertzog: > > I have left out a few low-impact and really uncontroversial ideas (like > > "port UDD to Python 3", we all agree on that, it's more a matter of > &

Re: What are the most important projects that Debian ought to work on?

Hello, On Mon, 24 Jan 2022, Sébastien Delafond wrote: > As part of an upcoming survey that we are preparing, we plan to ask > Debian developers to rank, by order of importance, the most popular > ideas of improvements for Debian. So I have finalized the question with all the choices. Given the

Re: What are the most important projects that Debian ought to work on?

Hi, On Mon, 24 Jan 2022, Sébastien Delafond wrote: > However, there's no easy way to identify what are the most popular ideas > of improvements that Debian ought to make. We know of the > "grow-your-ideas" project on Salsa, but it's far from exhaustive: I spent a couple of hours to put my own

Re: What are the most important projects that Debian ought to work on?

On Mon, 24 Jan 2022, Sébastien Delafond wrote: > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would be

Re: Unified workflow for package review

On Tue, 08 Feb 2022, David Bremner wrote: > Raphael Hertzog writes: > > > We should have a single web service that is able to handle all those > > workflows and provide all the inputs that each team needs to make their > > decision. It should have a nifty

We should trim the base system to be more container friendly

Hi, On Mon, 24 Jan 2022, Sébastien Delafond wrote: > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would

Unified workflow for package review

Hi, On Mon, 24 Jan 2022, Sébastien Delafond wrote: > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would

Debian should provide high quality ansible roles

Hi, On Mon, 24 Jan 2022, Sébastien Delafond wrote: > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would

Re: Services offered by Debian should be dogfooding the real packages on DSA hosts.

Hi, On Tue, 25 Jan 2022, Phil Morrell wrote: > I have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15 Thanks for this, but this issue like a few others that have been filed do describe problems but fail to provide "project/improvement ideas". We are good at figuring out what's

Re: Q. What is the best practice about +dfsg and +ds extension?

On Sat, 02 Oct 2021, Sean Whitton wrote: > > When upstream codebase require repackaging for (only) other reasons than > > DFSG compliance I instead use the hint "ds" (as in "derived source"). > > Or "Debian source" :) I always thought "ds" was for "debian specific" tarball. :-) Cheers, --

Re: Reconsider sending ITP bugs to debian-devel: a new list?

Hi, On Fri, 11 Jun 2021, Jonathan Carter wrote: > Wouldn't it just be far simpler for those who wish not to receive the > ITPs to filter them out to a subfolder of debian-devel or discard them? Jonathan explained that it wasn't easy for him due to reading over NNTP and I also think that it's a

Re: Seeking feedback on a meta package builder

Hi, On Thu, 10 Jun 2021, Helmut Grohne wrote: > On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote: > > I want to know it precisely in the context of selecting a worker. I don't > > want to schedule a task on a worker and later get back an answer "sorry I > &

Re: Seeking feedback on a meta package builder

Hi, On Tue, 08 Jun 2021, Helmut Grohne wrote: > With "look behind the abstraction", I think that you mean that debusine > would have to implement the mdbp api to perform worker selection. While > that would be possible indeed, I don't see this as required though. […] > I do wonder though, in what

Re: Seeking feedback on a meta package builder

Hi, On Mon, 07 Jun 2021, Helmut Grohne wrote: > My abstraction says nothing about workers or how to select them. The > idea behind that was that a user should not have to care. Yes, you > (debusine) do need a mapping between workers and available distributions > somewhere. You can implement

Re: Seeking feedback on a meta package builder

Hi, On Fri, 04 Jun 2021, Helmut Grohne wrote: > This is very sad. The whole point of me reaching out where was > specifically trying to avoid this kind of fragmentation and now you're > adding to it. While mdbp also is an implementation, it first and > foremost is an API and I'd hope that it

Re: Seeking feedback on a meta package builder

Hi, On Wed, 02 Jun 2021, Helmut Grohne wrote: > * debusine's build milestone implements a lock-in on sbuild. The >abstraction that I'm seeking doesn't happen here. Just to be clear, I think I want that kind of abstraction at some point. Because one should be able to schedule a package build

Re: Seeking feedback on a meta package builder

Hi, On Mon, 31 May 2021, Helmut Grohne wrote: > I see this tight coupling as a problem for mainly two reasons. [...] > * As tasks grow, there is a desire to distribute builds to multiple >machines. As such, the various tools typically grow their own >strategy for moving build tasks

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

On Fri, 12 Feb 2021, Peter Pentchev wrote: > > Yeah, it would go a long way if pristine-tar would store the associated > > signature and restore it as well. It's easy to forget to include it > > when the uploads are not done by the same person. > > It can, since version 1.41: > > debcheckout

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

Control: block -1 by 876643 Hi, thanks for your quick answer! On Fri, 12 Feb 2021, Guillem Jover wrote: > > If we assume that the archive is meant to store immutable content > > under a given filename (and to me that requirement seems to be a good > > idea), then we should question ourselves

Re: Possible DEP proposal - contribution preferences

Hi Jelmer, On Tue, 02 Feb 2021, Jelmer Vernooij wrote: > One of the things that I've been wondering about is whether it would make > sense to have a configuration file in Debian packages that allows > maintainers to specify preferences for contributions. At the > moment, this is not a well-formed

Re: About lintian

Hi, On Tue, 19 Jan 2021, Antonio Terceiro wrote: > > Can you expand on the kind of features that ci.debian.net offers and what > > kind of mistakes we would likely avoid by reusing it? > > To name a few: > > - distributed processing > - data retention policies > - web interface Thanks for your

Re: About lintian

Hi, On Mon, 18 Jan 2021, Antonio Terceiro wrote: > FWIW, The ci.debian.net infrastructure is mostly independent from > autopkgtest, so we could have different types of jobs there. This could > be used for lintian, but also for on-demand rebuilds, and other types of > checks that needs to be done

Re: How should we handle greenbone-security-assistant?

On Fri, 18 Dec 2020, Jonas Smedegaard wrote: > Who is keeping software out of Debian here? We, collectively, with the fact that we have not adapted our rules and tooling. (And yes you certainly did more than me on this front, in particular in the tooling front, I'm not arguing against that) >

Re: How should we handle greenbone-security-assistant?

On Thu, 17 Dec 2020, Adrian Bunk wrote: > > - ease of installation and reliability > > => we are doing bad now because many useful things are not packaged > > What is the value added just by installing things through dpkg instead > of npm? Why are you using Debian if you ask this? On the top

Re: How should we handle greenbone-security-assistant?

On Thu, 17 Dec 2020, Jonas Smedegaard wrote: > > said package was updated in Kali in a matter of hours. > > That's great. > > I mean - *either* it is great that Kali has a far better tool that we > might adopt - *or* it is great that Kali exists for those with different > needs than those of

Re: How should we handle greenbone-security-assistant?

On Thu, 17 Dec 2020, Pirate Praveen wrote: > > - ensurance that we use DFSG free code only > > => we can have tool to review licenses of what has been > > downloaded during build and embedded in the binary packages > > Then there would not be any value for Debian with such a scenario as

Re: How should we handle greenbone-security-assistant?

Hi, On Thu, 17 Dec 2020, Jonas Smedegaard wrote: > > Out of curiosity, I have run your script on the package.json file of > > greenbone-security-assistant and this just confirms that it's not > > realistic to package everything separately: > >

Re: How should we handle greenbone-security-assistant?

Hello, On Thu, 17 Dec 2020, Pirate Praveen wrote: > >1/ download all the node modules and add them to the source package, but > >then it's just impossible to write a copyright file to document the source > >package. That would be the best option though, the yarn.lock file > >effectively locks a

Re: How should we handle greenbone-security-assistant?

Hi, On Wed, 16 Dec 2020, Jonas Smedegaard wrote: > 4/ analyze what yarn/npm would do during build, and translate that into > existing Debian Nodejs packages and actual need for custom work. In the > JavaScript team we use this page as starting point for analyzing large > projects:

How should we handle greenbone-security-assistant?

Hello, in the pkg-security team we have greenbone-security-assistant (gsa) which is a web interface for gvm (former openvas-manager), the version currently in Debian no longer works with the latest gvm so we have to update it to the latest upstream release... but the latest upstream release has

Re: RFC: DEP-14 update, second attempt

Hi, On Sun, 29 Nov 2020, Paride Legovini wrote: > I tried to do a synthesis of past August/September thread on the > finalization of DEP-14 [1], see: > > https://salsa.debian.org/dep-team/deps/-/merge_requests/1/diffs Looks good to me, thanks for your work! I merged your branch and I updated

Re: Architecture: all binNMUs (was: deduplicating jquery/)

On Wed, 02 Dec 2020, Raphael Hertzog wrote: > > potentially different content, breaking the important design principle > > that things that are different should have different names. [...] > And as an aside, the archive has big holes when enforcing this "design &

Re: Architecture: all binNMUs (was: deduplicating jquery/)

Hi, On Tue, 01 Dec 2020, Simon McVittie wrote: > If I understand correctly, one of the ftp team's objections to discarding > and rebuilding maintainer-uploaded binaries is that if I upload foo_1.2-3, > and they discard my binary upload and rebuild it on the buildds, this > would result in having

Re: Bug#972674: ITP: toolbox -- Unprivileged container development environment

Hi, On Thu, 22 Oct 2020, Hayley Hughes wrote: > * URL : > > Toolbox is a tool that offers a familiar package based environment for > developing and debugging software that runs fully unprivileged using Podman. […] > I have already made some progress which

Re: Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)

Control: clone -1 -2 Control: reassign -2 autopkgtest Control: retitle -2 "autopkgtest: implement a podman backend" Control: block -1 by -2 Hi, On Sun, 29 Nov 2020, Johannes Schauer Marin Rodrigues wrote: > The resulting tarball can then be used with the sbuild unshare backend. The > only time

Re: Mass bugs filing: autopkgtest should be marked superficial

On Thu, 17 Sep 2020, Paul Gevers wrote: > > And consider the case where the bug has been fixed in git but the package > > has not been uploaded because that small change didn't warrant an upload > > of its own. When the FTBFS bug pops up, the fix for the autopkgtest will > > be uploaded. > > For

Re: Mass bugs filing: autopkgtest should be marked superficial

Hi, On Thu, 17 Sep 2020, Paul Gevers wrote: > This. I have written it done in response to bug [#969819]: > > Notwithstanding the wording, the Release Team is happy with the bugs > that Sudip is filing. Because of the way that autopkgtests are used in > the Debian infrastructure to influence

Re: Mass bugs filing: autopkgtest should be marked superficial

On Thu, 17 Sep 2020, Sudip Mukherjee wrote: > i think I will leave it for the Release Team to decide. But just > consider the scenario when the severity of this bug for a package 'X' > is reduced and then another FTBFS bug is raised on that same package. > The FTBFS bug will be fixed and it will

Re: Mass bugs filing: autopkgtest should be marked superficial

Hi Graham, On Thu, 17 Sep 2020, Graham Inggs wrote: > On Thu, 17 Sep 2020 at 09:18, Raphael Hertzog wrote: > > Please reduce the severity of all the bugs that you opened to "normal" > > or "minor". > > Why? Because the packages are not broken and do

Re: Mass bugs filing: autopkgtest should be marked superficial

On Fri, 04 Sep 2020, Sudip Mukherjee wrote: > If the test done in the autopkgtest does not provide significant test > coverage then it should be marked with "Restrictions: superficial". > Ref: https://people.debian.org/~eriberto/README.package-tests.html I agreed about those bugs being filed but

Re: Reaching out

Hello, On Tue, 15 Sep 2020, Paul Sutton wrote: > Just wondered, if it is worth me (or someone) trying to reach out to the > team behind the Debian Administrators handbook That would be me. :) > I would assume we will be making use of the anyway or making references > to this within lessons, so

Re: RFC: Final update of DEP-14 on naming of git packaging branches

Hi, On Sat, 12 Sep 2020, Sean Whitton wrote: > There are arguments both ways here but as you're the person driving > this, I'm still keen to hear more from you about why debian/unstable is > to be preferred over debian/sid giving the existing convention > established by dgit. Thanks. I don't

Re: How to switch to DEP14 automatically for > 1000 existing repositories

On Fri, 11 Sep 2020, Andreas Tille wrote: > My guess is that the Salsa API provides means to script everything. Is > there any existing script that supports this or is there any volunteer > to write it. I would start migrating Debian Med, Debian Science and > R packaging team repositories once

Re: RFC: Final update of DEP-14 on naming of git packaging branches

On Sat, 05 Sep 2020, Richard Laager wrote: > > OK to use debian/unstable as default branch even if you are not a > > complex package that require multiple branches, provided that you will > > not use debian/unstable when you decide to push something to > > experimental. > > I do not see why we

Re: RFC: Final update of DEP-14 on naming of git packaging branches

On Fri, 04 Sep 2020, The Wanderer wrote: > As long as this is being patched anyway, how about fixing the "others > vendors" duplicate pluralization? I'd suggest either "but all other > vendors should do so" or "as all others should do", but other variations > are possible and I don't have a strong

Re: RFC: Final update of DEP-14 on naming of git packaging branches

(Resending without the attachment for posterity sinte the message didn't make it to -devel, but I also had no bounce notifying me that it was discarded...) Hello, On Sun, 30 Aug 2020, Richard Laager wrote: > You could use debian/experimental all the time and then merge down to > debian/unstable

Re: RFC: Final update of DEP-14 on naming of git packaging branches

Hi, On Fri, 04 Sep 2020, Paride Legovini wrote: > As the name of the development branch is not specified anymore, should dep14 > ask for it to be the repository default branch? Otherwise there's no safe I took this as granted. But maybe we should make it explicit, yes. I also clarified that

Re: RFC: Final update of DEP-14 on naming of git packaging branches

Hi, On Mon, 31 Aug 2020, Paride Legovini wrote: > A tl;dr version of my idea is: let's remove the special treatment for > development releases, treating e.g. debian/unstable like a stable > release. Optionally use a 'debian/devel' branch for development work. > The only "workflow" bit is: if you

Re: RFC: Final update of DEP-14 on naming of git packaging branches

On Mon, 31 Aug 2020, Paride Legovini wrote: > What I propose is to require for dep14 compliance that uploads to > are to be cut from debian/ branches, unless > is experimental. This allows to checkout the "maintainer > view" of a given (nonexperimental) version of a package by knowing only: > >

Re: Accepting / adopting DEP-14

On Sat, 29 Aug 2020, Emmanuel Arias wrote: > DEP-14 will recommend the use of debian/latest for a package uploaded > to sid/unstable? or debian/latest is a pre work before uploaded to > sid/unstable? It is to be expected that debian/latest keeps switching between different states: - in sync

Re: RFC: Final update of DEP-14 on naming of git packaging branches

On Sat, 29 Aug 2020, Richard Laager wrote: > That said, I do understand we give a lot of deference to developers' > workflows. So I have no objection to DEP-14 supporting this workflow > with debian/latest. But I would like to see it (debian/latest) > recharacterized as the alternate approach

Re: Accepting / adopting DEP-14

On Wed, 26 Aug 2020, Geert Stappers wrote: > On Wed, Aug 26, 2020 at 06:08:17PM +0100, Simon McVittie wrote: > > On Wed, 26 Aug 2020 at 16:00:02 +0200, Jonas Smedegaard wrote: > } } [ ... good input ... ] > > How to go from good input to accepting DEP-14 ? FWIW I fully agree with Simon.

RFC: Final update of DEP-14 on naming of git packaging branches

@@ Title: Recommended layout for Git packaging repositories DEP: 14 -State: DRAFT -Date: 2016-11-09 -Drivers: Raphael Hertzog -URL: http://dep.debian.net/deps/dep14 -Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn +State: ACCEPTED +Date: 2020-08-29

Re: Accepting / adopting DEP-14

Hi, On Mon, 24 Aug 2020, Geert Stappers wrote: > The good things of https://dep-team.pages.debian.net/deps/dep14/ are in use. > But https://dep-team.pages.debian.net/deps/dep14/ it self looks abandonned. Why are you saying that? > What is needed to official accept DEP-14? > (and to give

Re: [Summary]: RFC: Standardizing source package artifacts build paths

On Sat, 02 May 2020, Scott Kitterman wrote: > Personally, I don't see any real benefit of standardizing on (making up an > example here) debian/.build over debian/build. Same here. The arguments against debian/build are very weak. If we care about a source package building a binary package named

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

Hi, On Mon, 30 Mar 2020, Didier 'OdyX' Raboud wrote: > > How should package maintainers deal with QR codes ethically? > > Asking package maintainers to rebuild functionally-equivalent QR-codes during > the build-process seems entirely reasonable to me. To me it looks like wasting my time.

Re: migration from cron.daily to systemd timers

On Wed, 08 Jan 2020, Daniel Leidert wrote: > > This strikes me as clutter that will never be removed from debconf, so > > let's not decide to do that for every package that might need a timer. > > Why should this question ever been removed? What is your goal? Getting rid of > cron-jobs? The

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

On Sat, 28 Dec 2019, Alexander Wirt wrote: > On Thu, 26 Dec 2019, Otto Kekäläinen wrote: > > > Hello! > > > > I've seen many times before statements like these so I'd like to raise > > some discussion around the topic: > > > > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org)

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

On Thu, 26 Dec 2019, Otto Kekäläinen wrote: > I am sure there are many ways to help the team and it is not just > about Salsa/Gitlab admin stuff, but also about creating structure in > the team, triaging issues, spreading best practices for users and > helping the most advanced users to grow into

Re: Namespaces for Lintian Tags

Hi, On Wed, 20 Nov 2019, Felix Lechner wrote: > There are many motivations: Among those motivations, which one is the one that triggered this process and which one are there as "additional benefits" that you could identify to justify the change? > 1. Shortens tag names. I don't see that as a

Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]

On Tue, 08 Oct 2019, Holger Levsen wrote: > On Mon, Oct 07, 2019 at 09:22:46PM -0400, Sam Hartman wrote: > > [...] as a last opportunity for > > others to comment. > > what's the deadline to grok this 20k and respond? It's in the subject: [comments by 11/05/2019] November 5th. Cheers, --

Re: Git Packaging: Native source formats

Hi, On Wed, 28 Aug 2019, Sam Hartman wrote: > Internet is faster and disks are cheaper. I'm not sure that DSA (which is maintaining snapshot.debian.org) will be happy with this assertion. > Using native source formats (1.0 and 3.0 (native)) is attractive for > some git workflows. It means you

Re: tag2upload service architecture and risk assessment - draft v2

Hi, I reviewed the whole thread and the point of friction is the requirement to sign the .dsc file to make sure that the source package matches what the maintainer intended to upload. Ian doesn't want the maintainer to have to deal with the .dsc and the ftpmasters wants to have a signature within

Re: salsa.debian.org partially down

On Fri, 16 Aug 2019, Alexander Wirt wrote: > I am a bit surprised, from the first day on we said that there are limited > ressources for ci and that you should be nice to the service. Thats even > documented: > > "We mean that. Really. Be nice to the server. At some point in the future we >

Re: Git Packaging Round 1: Hopefully Easy Stuff

On Wed, 14 Aug 2019, Sam Hartman wrote: > Regardless of anything they are doing with Git, maintainers of a package > are expected to process patches sent to the BTS. Yes. > You cannot respond to a patch telling someone they need to file a merge > request to have it considered. I would not

Re: Git Packaging Round 1: Hopefully Easy Stuff

On Thu, 15 Aug 2019, Russ Allbery wrote: > Jonathan Carter writes: > > > The Debian QA DDPO pages will show you whether you have MRs on the same > > page where you see how many open bugs, RC bugs, lintian errors, etc you > > have. This makes it super easy to notice MRs when doing routine checks

Re: Building GTK programs without installing dconf-service?

On Fri, 16 Aug 2019, Simon McVittie wrote: > If there *is* consensus that "don't lose user configuration" is less > important than "weaken dependencies where possible", then that's a good > reason to weaken the dependency, although in practice that is likely to > be wontfix until

Re: salsa.debian.org partially down

Hi, On Fri, 16 Aug 2019, gregor herrmann wrote: > From what I know, this what not a "foolish user action" but an action > by a dedicated maintainer who enabled salsa-ci for all packages > ("projects") of a specific team; so they used a service advertised by > the salsa and salsa-ci teams. That

Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab

Hi, On Thu, 01 Aug 2019, Domenico Andreoli wrote: > >Questions to be answered: > >- Is the setting only a default applied to new projects? > >- If yes, how do you inform users that a new project with > > /.gitlab-ci.yml will not work? > >- If no, how do you inform users that an existing project

Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab

Hi, On Thu, 25 Jul 2019, Daniel Leidert wrote: > it has become quiet around this issue. So if you think such a configuration > option is useful too please support > > https://gitlab.com/gitlab-org/gitlab-ce/issues/41764 I added my +1. Another request that is important to have proper CI result

Re: git & Debian packaging sprint report

On Sun, 21 Jul 2019, Ian Jackson wrote: > IME as a sponsor I get (AFAICT) no mails as a result of my sponsorship > signatures so I think there are few automatic processes. That's actualy not true, dak is sending mails to the person who signs the upload when it has to send mails like NEW

Re: default firewall utility changes for Debian 11 bullseye

Hi, I'm replying to your questions but I have also other questions related to this fresh transition... On Tue, 16 Jul 2019, Arturo Borrero Gonzalez wrote: > as you may know, Debian 10 buster includes the iptables-nft utility by > default, > which is an iptables flavor that uses the nf_tables

Re: Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)

On Tue, 09 Jul 2019, Simon Richter wrote: > Your proposal of generating some of the fields doesn't affect the API > itself, as long as the fields are populated at the right time. We don't > have a mechanism for updating the control file at build time, because any > part of the build process that

Re: Question about Debian build infrastructure

On Wed, 12 Jun 2019, Vincent Bernat wrote: > It's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623 > > Maintainer doesn't seem to be interested or have no time to consider the > patch since many years. Another sticking point with reprepro is the lack of Acquire-by-hash support:

Re: paying people for Debian work (Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices))

Hi, On Mon, 03 Jun 2019, Paul Wise wrote: > There are a few things that are possibly concerning: Thanks for sharing those. Let me answer them. > Freexian is essentially the only available-to-hire provider of > services for Debian LTS, as the Freeside link doesn't lead anywhere > useful. This

Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

On Wed, 29 May 2019, Ansgar wrote: > On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote: > > On Wed, 29 May 2019, Andrey Rahmatullin wrote: > > > One of the popular answers to this and some other problems is "nobody sat > > > down and wrote the code". Not

Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

Hi, On Wed, 29 May 2019, Andrey Rahmatullin wrote: > One of the popular answers to this and some other problems is "nobody sat > down and wrote the code". Not sure what can we do about this class of > reasons. Use the $300,000 on our bank accounts?

Looking for a technical writer to update the Debian Handbook

Hello, Roland and I, the authors of the Debian Administrator's Handbook (package debian-handbook), we have not managed to update the book for Debian 9 and I don't want this to happen again for Debian 10 buster. I'm thus looking for a technical writer that would be willing to update the book for

Re: Handling of entropy during boot

Hi, On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote: > Pointers, please? Let's see them and investigate. The primary issue > I've been aware of to date has been on Fedora systems, and it's due to > some Red Hat specific changes that they made for FEDRAMP compliance > --- and Red Hat has dealt with

Re: Sending using my @debian.org in gmail

Hi, On Tue, 04 Dec 2018, Marc Haber wrote: > >> If I could vote for which idea Debian mail admin time is dedicated > >> (which I cannot since Debian admins are volunteers and can choose what > >> to work on), I'd vote for better spam filtering on > >> @packages.debian.org and

Re: Upcoming Qt switch to OpenGL ES on arm64

Hello, On Thu, 29 Nov 2018, Adrian Bunk wrote: > Qt already supports runtime ES/non-ES in the same library build on > Windows [2], something like that might also be doable for Linux if > anyone (Linaro? Canonical?) with a real interest in that would work > on making it happen. > > Some of the

Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Hello Lisandro, TLDR: thank you for starting this discussion, it was required as it's not an easy decision to take as there is no realistic perfect solution, but I believe you took the wrong decision. Please consider deferring the decision to the technical committe by seeking his advice (point

Re: Upcoming Qt switch to OpenGL ES on arm64

Hello, On Sat, 24 Nov 2018, bret curtis wrote: > Moving Qt back to using Desktop GL from GLES is going to have zero > impact performance on the RPi since the VC4 supports up to OpenGL 2.1 > and and GLES 2.0 [1] That's a different claim to what you made in a former message. > The problem is that

Re: Upcoming Qt switch to OpenGL ES on arm64

Hi, On Fri, 23 Nov 2018, Dmitry Shachnev wrote: > According to config_help.txt [1], Qt uses ES2 by default on Windows. Interesting. > But as Lisandro says, such a change in Debian will break many packages > (which are currently broken on ARM only), so we are definitely not > considering it at

Re: Upcoming Qt switch to OpenGL ES on arm64

Hello Bret, On Sat, 24 Nov 2018, bret curtis wrote: > This is a very wrong assumption, the OpenGL on a RPi (all of them) is > hardware accelerated via the VC4 mesa driver by Eric Anholt which is > shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and > if you plan on having

Re: Confusing our users - who is supporting LTS?

On Sun, 28 Oct 2018, Wouter Verhelst wrote: > On Sun, Oct 28, 2018 at 01:14:13AM +, Ben Hutchings wrote: > > Debian can't afford to pay developers in general, and previous > > proposals to pay specific developers were not well received. > > That was over a decade ago. The circumstances at the

Re: Confusing our users - who is supporting LTS?

Hi, On Tue, 23 Oct 2018, Noah Meyerhans wrote: > The question > here was simply about discoverability. If you're a Debian user just > beginning exploration of public cloud alternatives, should we make it > easy for you to launch LTS instead of stable? I don't see any reason to make it hard, but

Re: Confusing our users - who is supporting LTS?

Hi Steve, On Tue, 23 Oct 2018, Steve McIntyre wrote: > So I'm worried that those of us who have *not* volunteered to support > LTS are being pressured into spending our time on it anyway. What can > we do to fix that? How/where do we clarify for our users (and > developers!) what LTS means, and

  1   2   3   4   5   6   7   8   9   10   >