Re: RFS: HexWalk Request for sponsor
Hi Samuel, Thank you for your time, I'll try to fix the issues by myself and will return to you asap. The strange thing is that I already generated the package here: https://mentors.debian.net/package/hexwalk/ and I didn't face all these issues Am I missing something? Thank you again, Carmix Il Mar 21 Mag 2024, 00:00 Samuel Henrique ha scritto: > Hello carmix, > > I've had some time to review the package today, I didn't review everything > in > depth so there might be more comments after these changes. > > 1) d/changelog: unstable distribution > I see that you're targeting "stable" in the changelog, but in Debian we do > uploads to unstable or experimental, new packages can only get to stable > through stable-backports (and that's after the package migrates from > unstable > to testing). > You can read more about it here: > https://backports.debian.org/ > This diagram shows the workflow of packages: > https://wiki.debian.org/DebianReleases#Workflow > > For more information, I suggest reading about the Debian release process. > > 2) debian/compat: deprecated file > We don't use this file anymore, check the following manpage section for > details: > > https://manpages.debian.org/unstable/debhelper/debhelper.7.en.html#COMPATIBILITY_LEVELS > > 3) Build fails > I'm not able to build the package, it fails with missing file errors, like: > > dh_install: warning: Cannot find (any matches for) "hexwalk.ico" (tried > in ., debian/tmp) > I think the solution to this might fall under #4 below. > > In order for a review to be done, the package needs to be buildable, if > not, > then I suggest reaching out for help with the specific issues. > > 4) No build system > It doesn't seem like debhelper is building anything, changes need to be > done to > actually trigger the build, they will depend on the buildsystem you use. > > You can search for how other packages make use of qmake here: > https://codesearch.debian.net/search?q=qmake=1=1 > > I believe finding someone to help you more directly would be useful, > packaging > is hard and I know how tough it is to be in this position. > > But also, you don't necessarily need to do the packaging yourself, if you > prefer, you can open an RFP bug (or turn your RFS into an RFP), this would > be a > request for someone to package it. > > The only reason I'm saying this is because usually upstreams don't want to > get > too much involved in packaging, but if you do, that's great. > > Cheers, > > > -- > Samuel Henrique >
Re: Request to join your team as new member
Hello Alicherif, On Mon, 20 May 2024 at 14:54, Alicherif Samir wrote: > I'm working on the Wapiti web scanner with a team of motivated people, and we > want to see our work published on the Salsa repositories. That's great, feel free to send an MR against the debian branch, you can skip doing an MR for the pristine-tar and upstream branches (but they need to be updated in your fork). > As nobody packages Wapiti anymore, I'd like to take care of it. That's not true, the package is still under the team and someone ought to package the latest version eventually. It's still being taken care of, but contributions are very much welcomed! > Now that you know what I want to do, let me introduce myself. I'm Samir. I am > a developer passionate about many subjects, including Cyber Security and Risk > Management. I work for a company that publishes a vulnerability management > software. Awesome, we don't have a strict definition of being part of the team, so for any MRs you make against wapiti, feel free to use "Team upload" in the changelog. Salsa does have the concept of the team, for the pkg-security namespace, but ayn members added will have permissions across all repos maintained by the team, so we tend to only add people if needed/after some contributions. This doesn't stop others from contributing, as anyone is allowed to send an MR doing a "Team upload" (d/changelog). Welcome! -- Samuel Henrique
Re: Request to join as new member
Hello Simon, On Sat, 11 May 2024 at 10:59, Simon Josefsson wrote: > I'm not up to speed on all the pkg-security tooling, so please review > and fix anything that needs fixing. I feel uncomfortable having a salsa > write permission token in plain text on my laptop, which seemed required > to use some of the suggested tools -- hopefully none of that stuff is > critical, and if important could be fixed by others too? It felt like > going down someone's personal work flow understanding, which is great > for inspiration (I quickly agreed with most concepts) but may require > some more polishing before everyone can adapt. I had the same feeling > when adapting to the Debian Go Packaging workflow, most of the workflow > concepts are great improvements but deep below some assumptions that may > not be universal are made. I hope to learn and adapt though. I think only a few people use the tools at https://salsa.debian.org/pkg-security-team/pkg-security-team. You should be definitely fine without using it. The feature we get is standardization of the packaging, the main one being setting up the IRC and BTS hooks, but then the logic around branch names is outdated :(. I should take some time to update that wiki and the scripts... But for now, feel free to skip that. > Regarding having the repository in debian/ but still use pkg-security > group maintenance, I'll think about that some more, but you can tell > from my decision to move libntlm to pkg-security that I wanted to give > this approach a try first. Ack, I'm interested in your findings after trying it out for a bit. Cheers, -- Samuel Henrique
Re: pkg-security-team vs debian namespace
Hello Simon, On Sat, 11 May 2024 at 11:51, Simon Josefsson wrote: > Following up on the namespace question separately. To clarify: I'm not > proposing any change. I'm mostly trying to learn and understand why > some decisions were made and if the rationale still apply. No worries, I think there's definitely room for improvement. I've been having discussions like this with the other curl maintainers but we haven't managed to find a good alternative for the issue yet. If you're going to attend DebConf, I'd love to chat about this with you (I have seen your emails on other threads and it looks like we are aligned on how we view the issue). > Samuel Henrique writes: > > > Downsides of keeping the packaging under debian/: > > * Lack of the salsa's view of current opened MRs, as seen on > > https://salsa.debian.org/groups/pkg-security-team/-/merge_requests. This > > is > > the biggest downside in my opinion. > > Couldn't this easily be solved by tagging merge requests for > pkg-security-related packages with a tag, and search for that? Assuming > all pkg-security-team packages were to be moved to /debian/ (for sake of > discussing this aspect). I'm not familiar enough with GitLab workflows > to tell if using Assignee, Reviewer, Label, Environment or some other > tag though then you could go to this page, using label CI as an > example but CI would be replaced with PKG-SECURITY or similar: > > https://salsa.debian.org/groups/debian/-/merge_requests?scope=all=opened_name[]=CI That would work, yes, but I don't think there's a straightforward way to automate this. It's an interesting idea nonetheless... > > * Team contributors who have received permissions to push to all team-owned > > repos (before becoming DDs) will still not be able to push to the packages > > under debian/. This is not a huge issue because they can still open MRs, > > but > > the process to contribute becomes a bit more cumbersome. > > Is there any documented policy for /debian/ packages including group > membership policy? Maybe lack of documented policy for /debian/ is the > biggest problem here though, it isn't even possible to evaluate if the > policies are compatible. Not that I'm aware, what's done in practice is that all DDs get permission to push to the debian namespace. The way we handle the concept of teams on debian is not very well defined, for good or for bad. We miss a few things to get an ideal process, but one that often gets to my mind is the ability for multiple teams to own the same package. For example, a security-related package written in python should be set up so that both the security-tools and the python team are able to push to git (and to upload) as a team upload. If we go further, we can also say that any DD is allowed to push and upload, while still keeping a team under its maintenance umbrella (the people from the team would be the ones receiving bug reports, watching MRs, etc...). Cheers, -- Samuel Henrique
Re: RFS: HexWalk Request for sponsor
Hello carmix, I've had some time to review the package today, I didn't review everything in depth so there might be more comments after these changes. 1) d/changelog: unstable distribution I see that you're targeting "stable" in the changelog, but in Debian we do uploads to unstable or experimental, new packages can only get to stable through stable-backports (and that's after the package migrates from unstable to testing). You can read more about it here: https://backports.debian.org/ This diagram shows the workflow of packages: https://wiki.debian.org/DebianReleases#Workflow For more information, I suggest reading about the Debian release process. 2) debian/compat: deprecated file We don't use this file anymore, check the following manpage section for details: https://manpages.debian.org/unstable/debhelper/debhelper.7.en.html#COMPATIBILITY_LEVELS 3) Build fails I'm not able to build the package, it fails with missing file errors, like: > dh_install: warning: Cannot find (any matches for) "hexwalk.ico" (tried in ., > debian/tmp) I think the solution to this might fall under #4 below. In order for a review to be done, the package needs to be buildable, if not, then I suggest reaching out for help with the specific issues. 4) No build system It doesn't seem like debhelper is building anything, changes need to be done to actually trigger the build, they will depend on the buildsystem you use. You can search for how other packages make use of qmake here: https://codesearch.debian.net/search?q=qmake=1=1 I believe finding someone to help you more directly would be useful, packaging is hard and I know how tough it is to be in this position. But also, you don't necessarily need to do the packaging yourself, if you prefer, you can open an RFP bug (or turn your RFS into an RFP), this would be a request for someone to package it. The only reason I'm saying this is because usually upstreams don't want to get too much involved in packaging, but if you do, that's great. Cheers, -- Samuel Henrique
Request to join your team as new member
Hello there, I'm working on the Wapiti web scanner with a team of motivated people, and we want to see our work published on the Salsa repositories. As nobody packages Wapiti anymore, I'd like to take care of it. Now that you know what I want to do, let me introduce myself. I'm Samir. I am a developer passionate about many subjects, including Cyber Security and Risk Management. I work for a company that publishes a vulnerability management software. Cheers, Samir
