Re: Silent hijacking and stripping records from changelog
Quoting James McCoy (2024-04-09 03:25:16) > On Mon, Apr 08, 2024 at 10:21:49PM +0200, Jonas Smedegaard wrote: > > ...and about moving on: Can you please also clarify if you understand > > "moving on" as reverting to me maintaining the package that you > > accidentally hijacked, or if you instead understand it as you (on bhalf > > of the Rust team) now having taken over maintainership of that package? > > I've already filed an RM request for src:rust-lazy-regex-proc-macros, so > your package will prevail. Ah, good to know. Thanks! > > > Den mån 8 apr. 2024 kl 12:41 skrev James McCoy : > > > > Now, that happens because our tooling is based around a 1:1 > > > > relationship of crate to source package where as you've been > > > > packaging an entire workspace as a source package. We need to adapt > > > > our tooling to better detect this so we get accurate information > > > > presented to us and avoid stepping on your work. > > > > Yes, please improve your tooling to better align with Debian packaging > > rules, not assume your team rules apply also outside of your team. > > Having policy for a language ecosystem is pretty common, since that > makes it easier to interoperate. Yes, team-specific policies exist, to ease work within those teams. Team-defined policies do not, however, hold any special powers outside of said team, so it is sensible for them to not conflict with general Debian packaging policies or assume that all packages *outside* of the team are aligned by those team-specific policies - e.g. that a binary package containing cargo crate source files must¹ be built from a source package with same name as that cargo crate. ¹ "Package naming" in https://wiki.debian.org/Teams/RustPackaging/Policy > > > > I'd still prefer if we could consolidate our efforts into the rust > > > > team (and re-integrate your forks of our package helpers), rather > > > > than have two divergent sources of rust packaging. > > > > I would also prefer if we could consolidate our efforts, and am open to > > joining the Rust team and collaborate there, as also stated previously. > > > > What I am not open to is abandon the one-git-repo-per-source-package > > packaging style that is commonly practiced in Debian. As I understand > > it, only Haskell and Rust teams use giant-git-for-all-team-packages > > style, and only the Rust team strictly enforce that style (Perl team > > uses myrepos to work across many packages which I recommend you to > > consider). > > When I first started looking into Rust packaging it was initially going > to be for a workspace of crates. I didn't receive any pushback when I > asked about taking over the one crate that had already been packaged and > handling it from a single source package for that workspace. In the end > I changed my mind and continued using the monorepo for the rest of the > crates. > > It makes certain things easier, while using a repo based on upstream git > makes other things easier. Which method is used is up to the maintainer. > Not using the monorepo just requires better coordination. Well, I received strong pushback by Ximin (on irc - I can share chat log discretely if interested) when I joined the team and published a single-package-repo rust library (possibly the first librust-* in Debian), and the pushback and insisting on strong rules imposed for team members lead me to drop that package and leave the team. I have since, every time I have been approached by Rust team members and suggested to join the team, shared my concern about the Rust team policy, and asked if those policies might have changed, or if those approaching me might see a benefit of working towards changing team policy. I am not quite sure what you are really saying above. Squinting my eyes it kinda sounds like you might be open to relaxing team policy. If that's the case then that's great news. I look forward to that. If you are interested in better understanding my notivation for the crisicism I raise towards the Rust team policy, then feel free to reach out - I am happy to elaborate. > > More important, however, and despite what I can or cannot agree with: > > For as long as the Rust team chooses to deviate from general Debian > > practices, it *must* constrain those deviated rules to team work, and > > *not* make the flawed assumption that all Rust crates in Debian are > > aligned with Rust team packaging rules. At any time any Debian developer > > may upload a rust-* package - that namespace does not belong to the Rust > > team, regardless if/when I join the team. > > As far as I know, no one has claimed that we have sole ownership of the > rust-* namespace. Sorry if my phrasing came across as such strong allegation. What I meant to imply was not explicit *claim* of ownership but merely *assumptions* about team-specific policies applying Debian-wide. > However, we do expect anything using that namespace > is uploading a package which agrees with upstream's use of that > namespac
Re: syslog-ng: identified for time_t transition but no ABI in shlibs
On Mon, Apr 8, 2024 at 9:15 PM Attila Szalay wrote:
>
> Ok. I re-checked the patch and realized that I checked the only wrong
> module (the only one which is arch all and not any).
>
> So my apologies for the fuzz and will apply the patch with the
> appropriate changes.
>
> But here my original reply too:
>
> I admit that I joined late to this conversation. But my complain is not
> about the time_t change.
>
> My complain is the contradiction between two thing:
> 1. https://wiki.debian.org/binNMU says that I should declar[e]
> dependency between an arch: all to an arch: any package: Depends: foo
> (>= ${source:Version}), foo (<< ${source:Version}.1~)
>
This is for arch: all -> arch: any. However I see most syslog-ng-mod-*
packages are arch: any. So it should just use strict equal on
syslog-ng-core.
What I'm confused about is some syslog-ng-mod-* packages are arch:
all, which don't have .so in it. Then why do they need to depend on
syslog-ng-core?
> 2. The bug report ask to depend on 'syslog-ng-core (=
> $${binary:Version})'
>
> This two is contradict and because syslog-ng complies with the binNMU
> request, I really reluctant to change that. Especially because in that
> case another ticket will be created in no-time to revert it.
>
> This is from the proposed changelog:
> + * Adjust shlibs for syslog-ng-core to use a strict versioned depends;
> +previously, modules used >=, << dependencies which did not account for
> +the possibility of ABI skew in a binNMU, which is exactly what happens
> +with the 64-bit time_t transition.
>
> And my question is again, is the rules really changed or we bend the
> rules just because of one transition?
--
Shengjing Zhu
Re: About Package Maintenance
On 09/04/24 08:52, Simon Richter wrote: Otoh, I am fully aware of the "you can't force a volunteer to do things", knowing that I myself would be the first one to violently oppose a decision that I don't like while - at the same time - being mad at some core package maintainers who have forced the project to jump through even more burning hoops to finally get the usrmerge migration The project has always had, and continues to have the two options "submit a patch" and "replace the maintainer." We have processes for that. No one, especially not the people driving the usrmerge migration, wants to do that, because that would require taking on a long-term commitment and the responsibility that comes with it, when they would prefer to do a drive-by contribution. Hence we are having a debate again whether there should be a mechanism to force maintainers to accept any patch thrown at them by someone "authorized" to perform a global change. No result can be reached from this debate, because there is no difference between force-accepting a contribution and replacing a maintainer. Between forcing maintainers to accept drive-by patches as-is and replacing them, there is also the option of asking maintainers to respond to patches in a "timely"* fashion instead of letting them rot in the BTS or forcing the requester to do an NMU. "A timely response" could be two weeks for packages in (build-)essential, one month for top-10% popcon packages, three months for all other packages. Tagging as "wontfix" would also be an OK response, at least the project will have a clear and explicit view of what is blocking distro-wide changes. Regards, -- Gioele Barabucci
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
[I'm skipping most of this email because I haven't generally been keeping up with the thread, but thought it might be worth pointing out one thing.] On Mon, Apr 08, 2024 at 06:48:13PM +0200, Marc Haber wrote: > On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote: > > Before uploading I usually > > run `routine-update -f` which is just upgrading to latest standards by > > calling Janitor tools and does some other changes to keep up with latest > > packaging standards semi-automatically. > > I wasn't aware of that tool. We need to publish more about such things. > > I am not particularly fond of Janitor's suggestions though. For my > taste, it removes support for older versions of Debian too quickly, and > I have frequently chosen to not accept janitor MRs because this would > affect ability and ease to backport to oldstable or even to > oldoldstable. But that also is a matter of style. I'm not sure how widely known it is, but the Janitor does have a mechanism for overriding the versions of Debian it retains compatibility with based on various considerations, and I've found it useful to land changes there in the past so that its other facilities can still be useful without getting in my way. Search for "compat_release" in https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
Hi Marc (2024.04.08_16:48:13_+) > I have also noticed that the young people we manage to recruit are > usually not interested too much in the boring gruntwork of maintaining > important core packages (like adduser and sudo) but instead want to do > "new" things. But, otoh, what would Debian be without sudo? Somebody > needs to do that work as well. To some degree, this is self-fulfilling. Most core packages have a maintainer. Drive-by contributions in a bug or MR are likely to go ignored for years. Newbies aren't going to get pulled into these packages, easily. Where core packages are up for adoption, they're probably pretty complex and maybe not the best candidate for a new contributor. The best stuff has probably already been adopted. All of this leads to the position we are in, where new contributors best road into the project is into teams. And the best way to get some experience is packaging something new in a team. I see one of the goals of promoting team maintenance as increasing the pipeline of new contributors into the maintenance of core infrastructure. Rather than having to wait for the current maintainers to slowly fade away and salvage the result after years of problems. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: finally end single-person maintainership
Hi Julien, Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt: > > I only use salsa's git. That begs two questions: > - What do I miss by not using the web interface? If you are owner of a team repository you need to manage members. As far as I know this is only possible via web interface (I did not checked glab since I just learned in this thread about is existence.) This is sometimes a bit slow but acceptable for me since I need to deal with it once or twice a month. When intending to package something new I do not only fire up wnpp-check to look for some ITP bug but also seek on Salsa for some preliminary work done on this project without filing some ITP. I like this web search and in case you do some duplicated work you might miss it (see above for possible replacement by glab). For me Salsa CI is one of the greatest things we have. Its not "pure" Salsa but I'd say you are missing something if you are not using it. (Thanks a lot to those who are running Salsa CI!) > - What does that web interface have that people don't like? I confirm that logs from Salsa CI are sometimes a bit slow but I'm not sure whom to blame about this. For me it does not cross the borderline to "not like it" - but in Johannes Schauer wrote in this thread that slow clients might fail to show log files at all. For me the two biggest argument for using Salsa consequently are: - It enables more than one person to work on one package effectively - I've met lots of potential young contributors who expect somehow a modern collaboration tool and we are risking that young blood moves to other distros if we do not use it consequently Kind regards Andreas. -- https://fam-tille.de
fence-agents package split
Hi,
Based on the suggestion from Ubuntu maintainers, fence-agents package
is going to be split as described below. The main goal is to have
agent dependencies specified more accurately and allow only required
agents to be installed on the cluster nodes. It is expected that a few
agents/packages will be added or removed per year.
After the split fence-agents becomes a metapackage that recommends
the new 75 agent packages:
Package: fence-agents
Architecture: all
Depends: ${misc:Depends},
Recommends: fence-agents-ack-manual,
fence-agents-aliyun,
fence-agents-alom,
fence-agents-amt,
fence-agents-apc,
fence-agents-apc-snmp,
...
Description: Fence Agents for Red Hat Cluster - all agents
Package: fence-agents-common
Architecture: all
Depends: ${misc:Depends},
${python3:Depends},
python3-pexpect,
python3-pycurl,
Breaks: fence-agents (<< 4.12.1-2~exp1)
Replaces: fence-agents (<< 4.12.1-2~exp1)
Description: Fence Agents for Red Hat Cluster - common files
Package: fence-agents-alom
Architecture: all
Depends: ${shlibs:Depends},
${misc:Depends},
${python3:Depends},
fence-agents-common (>= ${source:Version}),
openssh-client,
telnet
Breaks: fence-agents (<< 4.12.1-2~exp1)
Replaces: fence-agents (<< 4.12.1-2~exp1)
Description: Fence Agents for Red Hat Cluster - Sun ALOM agent
Package: fence-agents-amt
Architecture: all
Depends: ${shlibs:Depends},
${misc:Depends},
${python3:Depends},
fence-agents-common (>= ${source:Version}),
amtterm
Breaks: fence-agents (<< 4.12.1-2~exp1)
Replaces: fence-agents (<< 4.12.1-2~exp1)
Description: Fence Agents for Red Hat Cluster - Intel AMT agent
For more details see experimental where the split package is
already uploaded.
Let me know if you have any concerns or suggestions regarding
this change.
--
Valentin
Re: finally end single-person maintainership
On 2024-04-08 21:44 +0900, Simon Richter wrote: > Testing a package requires me to > commit everything into git first, so I have to remember to squash all these > commits later. Right - this was (one of the) main thing(s) that annoyed me enough to just go back to the non-git based workflow. I want to make changes and try them. I don't want to have to commit every damn time - it's not done yet - I'll commit it after I'm satisfied that it works. But I don't know that until I've made a whole set of changes and it builds. So now I've got a pile of changes which should really be separate commits and logically separate things often affect the same files, and even the same lines, so really I need to commit some chunks and not others and tidy it all up. Yes this makes a nice set of commits but it's _so_ much work in comparison to just editing the damn files, and then effectively doing one fat 'commit' when I dupload. Often something ends up stalled for weeks or months or years because I've got some chunks in the wrong places and sorting it out is painful, so I go do something else and lose all my state. You all know how that goes... Sometimes git is useful - I do use it quite intensively for things where it actually helps (complicated cave survey datasets with hundreds of entangled commits that need re-ordering). For the vast majority of my debian packaging it's just makework. I realise this (like my previous message) will result in a load of people telling me git _is_ better and I'm just doing it wrong, or should learn better tools. And they may even be right, (and I will probably learn some things from this thread), but I don't believe the goal we agree on (fixing other people's packages should be culturally accepted) _requires_ this change in tooling (which is a heavy cost for at least some of us). The point here is that 'requiring salsa' is actually code for 'no, you can't just use the tarball-based VCS any more - you have to use git'. Removing that interface is a very big deal - it has served quite well for 30 years. Yes it old-fashioned and crufty and (presumably) only a minority still use it as the primary interface, but any GR on this should acknowledge what we are requiring of people still using it, not just frame this as 'and add salsa'. It's more fundamental than that (or I am misunderstanding).. Also what do you git people do to replace uscan? Currently I go to my existing version, or a newly-acquired apt get or dget source. I do 'uscan' and if there is a new upstream version I have a nice separate directly that is easy to dirdiff (then fixup any packaging and dupload). If there isn't I can move on. git world seems to make this way more complicated. I have to set up two different repos - one for salsa one for upstream, then pull them, maybe into different branches, and fight the diff config to let me dirdiff two different commits. And the upstream pull will always pull changes, not just only do it is there is an actual release (tag). None of that feels like an improvement over 'uscan'. One word for the standard process of updating to a new version. And if the patches still apply it's probably all done (I always do a meld review too to see what changed). And I do just prefer having two directories rather than multiple version on top of each other. My simple brain finds it a lot easier to keep track of a version directory to diff between, rather than finding the right runes to get git to give meld faked-up directories pointing at revisions or branches. If someone can make a tool so that this workflow still works, but a copy gets dumped into salsa, then I don't mind this new requirement. But otherwise it seems like a big imposition. I do understand the argument that lots of different workflows adds friction. But I'm just still using what used to be _the_ standard one (insofar as we ever had such a thing). Putting everything in salsa/git doesn't standardise workflows in itself. I think Ian/Sean identified 12 different git-based methods in their dgit review. Josch's suggestion that just recording the workflow in metadata would be useful is a good one. Then at least you know what other maintainers are doing. And dgit's approach of unifying the archive representation and the git representation is definitely progress in the right direction. I was very sad to find that it didn't help us 'tarball people' directly at all (except I guess to reduce exactly this pressure to stop doing it and use git). So why mandate salsa rather than make dgit more official? That lets the people that want to use git use it for everything - even the packages that were just uploaded as tarballs. And explicitly _doesn't_ remove the archive VCS interface. And it supports all the git-based workflows. (someone should probably tell IWJ this conversation is occuring as he's taken a bit intererest in it, but no longer reads debian-devel). Does than not solve a good chunk of this 'make it easy to fix other packages using your
Janitor (Was: About Package Maintenance)
Hi Colin, Am Tue, Apr 09, 2024 at 12:03:52PM +0100 schrieb Colin Watson: > I'm not sure how widely known it is, but the Janitor does have a > mechanism for overriding the versions of Debian it retains compatibility > with based on various considerations, and I've found it useful to land > changes there in the past so that its other facilities can still be > useful without getting in my way. Search for "compat_release" in > https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf. Thanks a lot for this hint. I was not aware of this and for my use cases I'm happy with Janitor defaults since it makes sense for leaf packages as we usually maintain in the scientific software branch. When talking about criticism on Janitor: I personally do not see much sense in creating changes like Bump debhelper from old 10 to 11 and later Bump debhelper from old 11 to 12 etc. for packages that are not used for a long time. Thus I rather call Janitor tools right before uploading a package. But this are details. In my eyes the greatest thing in Janitor is that it proves that Debian wide changes can be done automatically and can be adjusted to users needs (by either commiting directly, create MR or to leave out packages or teams at request) and as I learned now can even work with fine graned adjustments. Kind regards Andreas. -- https://fam-tille.de
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
Am Tue, Apr 09, 2024 at 01:03:10PM + schrieb Stefano Rivera: > > I have also noticed that the young people we manage to recruit are > > usually not interested too much in the boring gruntwork of maintaining > > important core packages (like adduser and sudo) but instead want to do > > "new" things. But, otoh, what would Debian be without sudo? Somebody > > needs to do that work as well. > > To some degree, this is self-fulfilling. Most core packages have a > maintainer. Drive-by contributions in a bug or MR are likely to go > ignored for years. Newbies aren't going to get pulled into these > packages, easily. > > Where core packages are up for adoption, they're probably pretty complex > and maybe not the best candidate for a new contributor. The best stuff > has probably already been adopted. > > All of this leads to the position we are in, where new contributors best > road into the project is into teams. And the best way to get some > experience is packaging something new in a team. > > I see one of the goals of promoting team maintenance as increasing the > pipeline of new contributors into the maintenance of core > infrastructure. Rather than having to wait for the current maintainers > to slowly fade away and salvage the result after years of problems. Very well said. Congratulations for remotely reading my mind and turn it into those clear words. Kind regards Andreas. -- https://fam-tille.de
Re: finally end single-person maintainership
Hi Wookey and all, Quoting Wookey (2024-04-09 18:52:43) > On 2024-04-08 21:44 +0900, Simon Richter wrote: > > Testing a package requires me to commit everything into git first, so I > > have to remember to squash all these commits later. > Right - this was (one of the) main thing(s) that annoyed me enough to just go > back to the non-git based workflow. I want to make changes and try them. I > don't want to have to commit every damn time - it's not done yet - I'll > commit it after I'm satisfied that it works. But I don't know that until I've > made a whole set of changes and it builds. if what I want to do is more complicated, what I do is indeed to create a stack of commits which I squash in the end. I see this as a feature because it allows me to always go back to an earlier stage of my changes. If the code is complex I'm unable to keep in my head what I changed when and why. I use git commits to keep track of that as I work towards the final result. Because every meaningful change is in a git commit I can always go back to an earlier stage if it turns out I messed something up. Yes, running "git add ... && git commit" is overhead but I in my experience I waste more time with forgetting what file I changed how the last time I tested something than with running these git commands. > So now I've got a pile of changes which should really be separate commits and > logically separate things often affect the same files, and even the same > lines, so really I need to commit some chunks and not others and tidy it all > up. Yes this makes a nice set of commits but it's _so_ much work in > comparison to just editing the damn files, and then effectively doing one fat > 'commit' when I dupload. Often something ends up stalled for weeks or months > or years because I've got some chunks in the wrong places and sorting it out > is painful, so I go do something else and lose all my state. You all know how > that goes... I manage these "piles of changes" in git branches and oftentimes, those branches end up as "merge requests" against another repo or my own repo. By doing it like that I not only allow others to see my work and potentially contribute as I'm working on it but I also keep a record of all the stuff I'm working on for future-me as I come back to work on a bug or feature. The extra data I am storing in git commit messages, that extra work, allows me to organize myself so it helps me even assuming that nobody else is contributing. > I realise this (like my previous message) will result in a load of people > telling me git _is_ better and I'm just doing it wrong, or should learn > better tools. And they may even be right, (and I will probably learn some > things from this thread), but I don't believe the goal we agree on (fixing > other people's packages should be culturally accepted) _requires_ this change > in tooling (which is a heavy cost for at least some of us). Personally, I think the project would be better off with more standardization of our workflows. The more different workflows we have, the harder it is to make archive-wide changes or for newcomers to learn the ropes. Speaking of newcomers: if I talk to my students, then for them, using git and workflows involving branches, tags and pull/merge requests is natural to them. So one can also argue the other way round and say: we deter younger contributors by not embracing the git workflow more. Sadly, there is probably no way to make everybody happy. I'd also not like to force you to switch your workflows. Of course ideally, I'd like to convince you that embracing git for packaging not only helps others but can also help you. :) > Also what do you git people do to replace uscan? Currently I go to my > existing version, or a newly-acquired apt get or dget source. I do 'uscan' > and if there is a new upstream version I have a nice separate directly that > is easy to dirdiff (then fixup any packaging and dupload). If there isn't I > can move on. Personally, I run: $ uscan --verbose $ gbp import-orig ../source.orig.tar.gz > And I do just prefer having two directories rather than multiple > version on top of each other. My simple brain finds it a lot easier to > keep track of a version directory to diff between, rather than finding > the right runes to get git to give meld faked-up directories pointing > at revisions or branches. I found this paragraph really interesting because reading your other emails I was wondering "well but how else do you do it then??" :D Maybe this is just muscle memory? Your directories are just my git branches. Instead of "cd ../source-verX" I'd do "git switch verX". Personally, I find git branches superior to directories because the git commit messages in each branch allow me to describe what this feature-branch is doing much better than a directory name could. A stack of commits in a branch allows me to trace back what changes I did in what order when I worked on a feature. By pushing the branches to salsa, I
Re: finally end single-person maintainership
On Tue, Apr 09, 2024 at 05:52:43PM +0100, Wookey wrote: > Right - this was (one of the) main thing(s) that annoyed me enough to > just go back to the non-git based workflow. I want to make changes and > try them. I don't want to have to commit every damn time - it's not > done yet - I'll commit it after I'm satisfied that it works. But I > don't know that until I've made a whole set of changes and it builds. > > So now I've got a pile of changes which should really be separate > commits and logically separate things often affect the same files, and > even the same lines, so really I need to commit some chunks and not > others and tidy it all up. Yes this makes a nice set of commits but > it's _so_ much work in comparison to just editing the damn files, and > then effectively doing one fat 'commit' when I dupload. Often > something ends up stalled for weeks or months or years because I've > got some chunks in the wrong places and sorting it out is painful, so > I go do something else and lose all my state. You all know how that > goes... Again, you don't need to commit anything to test it, so you can use whatever commit style is fine, including one fat commit before dupload. You may mean that doing this provides no benefit over not using git, which isn't really true. > Also what do you git people do to replace uscan? gbp import-orig --uscan > git world seems to make this way more complicated. I have to set up > two different repos - one for salsa one for upstream, then pull them, > maybe into different branches, and fight the diff config to let me > dirdiff two different commits. And the upstream pull will always pull > changes, not just only do it is there is an actual release (tag). You don't need to do that, you can't do that with upstreams that don't use git and some (probably all?) teams forbid that. -- WBR, wRAR signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Tue, Apr 09, 2024 at 07:43:04PM +0200, Johannes Schauer Marin Rodrigues wrote: > > And I do just prefer having two directories rather than multiple > > version on top of each other. My simple brain finds it a lot easier to > > keep track of a version directory to diff between, rather than finding > > the right runes to get git to give meld faked-up directories pointing > > at revisions or branches. > > I found this paragraph really interesting because reading your other emails I > was wondering "well but how else do you do it then??" :D Maybe this is just > muscle memory? Your directories are just my git branches. Instead of "cd > ../source-verX" I'd do "git switch verX". Personally, I find git branches > superior to directories because the git commit messages in each branch allow > me > to describe what this feature-branch is doing much better than a directory > name > could. A stack of commits in a branch allows me to trace back what changes I > did in what order when I worked on a feature. By pushing the branches to > salsa, > I enable collaboration on my work by doing not much more than running "git > push > --set-upstream origin myfeature". And of course git can emulate the other workflow using git-worktree. -- WBR, wRAR signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Tue Apr 9, 2024 at 1:52 PM -03, Wookey wrote: > On 2024-04-08 21:44 +0900, Simon Richter wrote: > > > Testing a package requires me to > > commit everything into git first, so I have to remember to squash all these > > commits later. > > Right - this was (one of the) main thing(s) that annoyed me enough to > just go back to the non-git based workflow. I want to make changes and > try them. I don't want to have to commit every damn time - it's not > done yet - I'll commit it after I'm satisfied that it works. But I > don't know that until I've made a whole set of changes and it builds. Use gbp-buildpackage --git-ignore-new. By default checks for uncommited, so you don't ship to Debian things that are not commited. If you use this flag, the burden of checking this lands on you. Yet, you can still use the regular workflow to build stuff, just dpkg-buildpackage -us -uc. > So now I've got a pile of changes which should really be separate > commits and logically separate things often affect the same files, and > even the same lines, so really I need to commit some chunks and not > others and tidy it all up. Yes this makes a nice set of commits but > it's _so_ much work in comparison to just editing the damn files, and > then effectively doing one fat 'commit' when I dupload. Often > something ends up stalled for weeks or months or years because I've > got some chunks in the wrong places and sorting it out is painful, so > I go do something else and lose all my state. You all know how that > goes... Use git commit -p, I tend to throw -v as well, so when I am writing the commit description I also get the diff of that commit. With -p you basically select by blocks what goes into your commit with simple y and n. You can also split blocks. If you prefer to just make a bunch of small commits and then combine them all into one big-fat commit, just use git rebase -i HEAD~N with N being how many commits you want to rebase. This will give you a file text where you decide which commits are squashed onto the top one, you can also re-arrange. After you save that file, it'll allow you to modify the commit. So you can do a bunch of git commit -m 'random' and with git rebase -i create a proper commit message from a bunch of commits. > I realise this (like my previous message) will result in a load of > people telling me git _is_ better and I'm just doing it wrong, or > should learn better tools. And they may even be right, (and I will > probably learn some things from this thread), but I don't believe the > goal we agree on (fixing other people's packages should be culturally > accepted) _requires_ this change in tooling (which is a heavy cost for > at least some of us). Git is the default tooling in the whole open-source ecosystem. Maybe a poll would be good to know how much people actually is against using Git as default, after so many years with proper git tooling in Debian. I would not be surprised if the loud bunch in the mailing lists end-up being very very small. I understand is hard to have your workflows changed, but IMO it's been too many years that Git is the default VCS everywhere. There's no other workflow you need to change, if you use Git. > The point here is that 'requiring salsa' is actually code for 'no, > you can't just use the tarball-based VCS any more - you have to use > git'. Removing that interface is a very big deal - it has served > quite well for 30 years. Yes it old-fashioned and crufty and > (presumably) only a minority still use it as the primary interface, > but any GR on this should acknowledge what we are requiring of people > still using it, not just frame this as 'and add salsa'. It's more > fundamental than that (or I am misunderstanding).. This is untrue. All the git tooling depends on non-git tooling for the build. I actually have a setup for building everything on docker and does not use any git tooling, because that's just sugar-coating for the non-git tools. > Also what do you git people do to replace uscan? Currently I go to my > existing version, or a newly-acquired apt get or dget source. I do > 'uscan' and if there is a new upstream version I have a nice separate > directly that is easy to dirdiff (then fixup any packaging and > dupload). If there isn't I can move on. You can use uscan. > git world seems to make this way more complicated. I have to set up > two different repos - one for salsa one for upstream, then pull them, > maybe into different branches, and fight the diff config to let me > dirdiff two different commits. And the upstream pull will always pull > changes, not just only do it is there is an actual release (tag). > > None of that feels like an improvement over 'uscan'. One word for the > standard process of updating to a new version. And if the patches > still apply it's probably all done (I always do a meld review too to > see what changed). I see, you are confusing two things here. Having the source from Git vs using tarballs. And using Salsa
Re: finally end single-person maintainership
hi, just adding some random data points to this thread: - I love git. - I very much dislike git-buildpackage, too much magic. I try to avoid it where I can. - I like salsa. (though I think for many new contributors this is rather a barrier "why not use github" directly. Also salsa is Debian only, which also is a barrier for some.) - I love autopkgtests. - I hardly every look at the autopkgs logs on salsaci, cause I find them incomprehensible and the javascript "UX" makes me wanna chop wood. - I also think disallowing single-person maintainership would be very unwise, though I agree team maintenance in general is probably better than single-person maintainership. Still disallowing single-person maintainership doesnt make a team and motivation lost is often motivation lost forever. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The era of global warming has ended, the era of global boiling has arrived. The heat is unbearable, and the level of fossil fuel profits & climate inaction is unacceptable. Humanity has unleashed destruction. This must not inspire despair, but action." — UNSG @AntonioGuterres signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Mon, Apr 08, 2024 at 11:00:52PM +0100, Luca Boccassi wrote: > ...right up until the point where that "bus factor of 1" moves > on/changes priorities/changes job/etc and the package is abandoned. > Fortunately that never happens, though! Having a repository on salsa or even "packaging team" does not prevent a lack of maintainer, so this is not relevant. Without a maintainer, no contribution will be merged in any case. Cheers, -- Bill. Imagine a large red swirl here.
Re: finally end single-person maintainership
On 09/04/24 18:52, Wookey wrote: So why mandate salsa rather than make dgit more official? Independently from whether salsa should be mandated, "git", "salsa" and "dgit" are three different things and should not be used as replacement of one another. Asking maintainers "to use git" means: please push your changes, even those unreleased to a public git repository (salsa, github, codeberg, your own domain...), so other people can contribute 1) knowing that they are working against the same sources the maintainer has on their hard drive, and 2) using git-based workflows. dgit is both a Web interface to browse git repositories as wells as a system to access the Debian archive as if it were a git repository, so you can "dgit push" a branch and have the resulting binary uploaded to the archive. (Yes, I'm simplifying here, but that's the gist.) Salsa is a forge, i.e. a combination of a Web interface, a git server, and a set of integrated features. In comparison to dgit, salsa has, like most forges: * Merge requests: where people can suggest changes and discuss them with line-based comments (accessible via email, no need to use the Web interface) * Continuous integration pipelines: as soon as you push a commit, Salsa-CI will try to build a package, cross build it, test it against piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI developers). * Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla, but funnily enough not BTS). * Project specific wikis, snippets, Docker images. * And with tag2upload salsa fulfills 50% of dgit functionality. Regards, -- Gioele Barabucci
Re: finally end single-person maintainership
On April 9, 2024 6:37:23 PM UTC, Holger Levsen wrote: >hi, > >just adding some random data points to this thread: > >- I love git. >- I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. >- I like salsa. (though I think for many new contributors this is rather > a barrier "why not use github" directly. Also salsa is Debian only, > which also is a barrier for some.) >- I love autopkgtests. >- I hardly every look at the autopkgs logs on salsaci, cause I find > them incomprehensible and the javascript "UX" makes me wanna chop wood. >- I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. Specifically to your last point, absolutely. Saying everyone must do a certain thing has an inverse that is we would rather you not contribute at all than do it without that thing. I would rather we make that list as short as possible. I have all my packages in git on salsa. Mostly I find it not that helpful to me, but I know others value it, so I do it (and for the occasional benefits it provides me). I think I would feel pretty strongly about not continuing to do so if someone told me I had to. Scott K
Bug#1068726: ITP: rust-csv2svg -- Take a csv as input and outputs svg
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-csv2svg Version : 0.2.1 Upstream Contact: dystroy * URL : https://crates.io/crates/csv2svg * License : MIT Programming Lang: Rust Description : Take a csv as input and outputs svg Build a SVG graph from a csv document. This is a dependency needed by glassbench, which comes the zellij dependency tree.
Bug#1068736: ITP: mount-zip -- recent FUSE file system for ZIP archives (read-only access)
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mount-zip Version : 1.0.7 Upstream Contact: François Degros * URL : https://github.com/google/mount-zip * License : GPL-3.0-or-later Programming Lang: C++ Description : recent FUSE file system for ZIP archives (read-only access) mount-zip is a tool allowing to open, explore and extract ZIP archives. . mount-zip mounts a ZIP archive as a read-only FUSE file system, which can then be explored and read by any application. . mount-zip aspires to be an excellent ZIP mounter. It starts quickly, uses little memory, decodes encrypted files, and provides on-the-go decompression and caching for maximum efficiency. . The mount point should be an empty directory. If the mount point doesn't exist yet, mount-zip creates it first. If no mount point is provided, mount-zip creates one in the same directory as the ZIP archive. . It is an alternative to fuse-zip. Compared to fuse-zip, its performance is improved, but write mode was dropped. Version 1.0.0 was forked from fuse-zip 0.7.2 See also RFP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068638
