Help to ship a better rsync on Buster
Hello everyone, and Paul, It got to my attention the rsync is a little behind our standards wrt to packaging and it looks like the maintainer doesn't have time to deal with that at the moment. Basically what I want to do is to upload the new release (along with some packaging fixes), adding new Uploaders while keeping the original Maintainer, or maybe moving it to a team while also keeping the original maintainer. The few changes that I already made: - Package the last release (which fixes a good amount of bugs and security issues) - Create a git repo on Salsa and use git for packaging [0] - Fix d/watch in order to be able to use uscan to download new releases Things that I would like to have fixed, either for Buster or later: - Use debhelper with quilt instead of a complex d/rules that manually apply patches - Use autopkgtests - Bug triage I understand that as I'm not familiar with the rsync packaging, some of the things may have been a explicit maintainer choice with a rational behind it, and that could be either spotted by a more experienced Debian Developer, explained by Paul, or discovered when changing it. Here are the points which leads me to think the maintainer might need help with rsync: - Last upload of rsync from maintainer was almost 2 years ago - Last upload of maintainer (any package) was in March 2017 - There were two NMUs after that - There is an open bug (#906895) since January asking for packaging of the new release, without replies from maintainer[1] - A lot of open bugs, 74 as of now. On a side note, I can see that there was recent (August 2018) email activity from Paul, so hopefully he may reply something about this. Overall, I can see that rsync is not a simple package to deal with, Paul having made a great job for many years all by himself, I would like to receive help with that so we all can ship a better rsync on Buster :) The transition freeze is for 12th January of 2019, so we would need to upload this new release asap, in order to account for time to fix any RC bug that may show up before the new release enters Testing. We can also pick which changes we want to ship for Buster and which ones we want to upload to experimental because we don't wanna risk introducing bugs that close to the freeze. Thanks, [0]https://salsa.debian.org/debian/rsync [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906895 -- Samuel Henrique
first epoch for acme-tiny
Hello d-devel, and Harlan, I'm currently working on a fix for an RC bug on acme-tiny that requires the packaging of the latest upstream release: acme-tiny: Please update to ACMEv2 API #924393 [0] In order for that to happen I need to introduce an epoch as we were using calver and now we have semver, I'm assuming this is a non-controversial epoch but I need to send this email on d-devel anyway. Previous version: 20171115-2 Current/Proposed Version: 1:4.0.4-1 I'm CCíng Harlan, a member of the LetsEncrypt Debian Team, as I will need ack from the team to proceed with the upload (I requested access on salsa already, can you accept me?) and I couldn't find a mailing list for the team. And to be clear I do understand that I will have to ask for an unblock for this new upstream release. The packaging is currently on my fork[1], and it will be there until I'm added on the team, then I will push all of the changes there[2]. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924393 [1] https://salsa.debian.org/samueloph/acme-tiny [2] https://salsa.debian.org/letsencrypt-team/acme-tiny -- Samuel Henrique
Re: first epoch for acme-tiny
Let me also CC Sebastien Badia, I just CC'ed the first two people that I found out and are active on the LetsEncrypt team. On Sat, 6 Apr 2019 at 14:11, Samuel Henrique wrote: > Hello d-devel, and Harlan, > > I'm currently working on a fix for an RC bug on acme-tiny that requires > the packaging of the latest upstream release: > acme-tiny: Please update to ACMEv2 API #924393 [0] > > In order for that to happen I need to introduce an epoch as we were using > calver and now we have semver, I'm assuming this is a non-controversial > epoch but I need to send this email on d-devel anyway. > > Previous version: 20171115-2 > Current/Proposed Version: 1:4.0.4-1 > > I'm CCíng Harlan, a member of the LetsEncrypt Debian Team, as I will need > ack from the team to proceed with the upload (I requested access on salsa > already, can you accept me?) and I couldn't find a mailing list for the > team. > > And to be clear I do understand that I will have to ask for an unblock for > this new upstream release. > > The packaging is currently on my fork[1], and it will be there until I'm > added on the team, then I will push all of the changes there[2]. > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924393 > [1] https://salsa.debian.org/samueloph/acme-tiny > [2] https://salsa.debian.org/letsencrypt-team/acme-tiny > > > -- > Samuel Henrique > -- Samuel Henrique
Re: DebConf19: Join our local crowdfunding campaign until June 15th
And here's the URL for the crowdfunding: https://www.catarse.me/debconf19
Re: Debian 13 release schedule and Debian 15 codename announcement
The person who sent this "announcement" doesn't seem to be part of the Debian Project, they're also not listed as a member of the release team at https://www.debian.org/intro/organization Someone from the release team might confirm my assumption, but for now please assume this is a fake/troll email, definitely not coming from the release team (also no mail signatures). Cheers, -- Samuel Henrique
Re: tracker.d.o displaying inconsistent information
Hello, > There are more inconsistencies, but you get the point. I'm pretty > sure everything will go back to normal given enough time, but it > looks like the particular set of circumstances around the libvirt > package have fallen through the cracks of tracker.d.o's logic and it > could be interesting to investigate them while the issue is still > manifesting itself. I've noticed issues for other packages[0][1][2][3] and they might all be related. grequests has been accepted 3 days ago and its tracker page is missing data. nmap's migration counter is stuck at 0: "Too young, only 0 of 5 days old". licenseutils and dd-opentracing-cpp both have RC bugs that don't show up on tracker, they likely have already been picked by the autoremoval tool (and might have a removal date set). I haven't looked for it, but there's probably a bug somewhere for this already. [0] https://tracker.debian.org/pkg/grequests [1] https://tracker.debian.org/pkg/nmap [2] https://tracker.debian.org/pkg/licenseutils [3] https://tracker.debian.org/pkg/dd-opentracing-cpp Cheers, -- Samuel Henrique
Re: tracker.d.o displaying inconsistent information
> I haven't looked for it, but there's probably a bug somewhere for this > already. I could not find any opened bugs, so I created one against the tracker virtual package: https://bugs.debian.org/1043546 Cheers, -- Samuel Henrique
Bug#1054871: ITP: legba -- A fast multi protocol credential bruteforcer/sprayer/enumerator
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Samuel Henrique Severity: wishlist * Package name: legba Version : 0.2.0 Upstream Contact: Simone Margaritelli * URL : https://github.com/evilsocket/legba * License : GPL-3.0 Programming Lang: Rust Description : A fast multi protocol credential bruteforcer/sprayer/enumerator Legba is a multiprotocol credentials bruteforcer / password sprayer and enumerator built with Rust and the Tokio asynchronous runtime in order to achieve better performances and stability while consuming less resources than similar tools. I plan to maintain this package under the pkg-security[0] and/or rust team[1]. [0] https://tracker.debian.org/teams/pkg-security/ [1] In case it ends up being easier to maintain under the rust team, due to the way Rust crates are packaged. -- Samuel Henrique
Re: 64-bit time_t transition: cargo needs manual intervention
On Sat, 16 Mar 2024 at 14:29, Simon McVittie wrote: > On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote: > > For example curl isn't building on armel/armhf now and numerous packages > > that > > depend of curl are not building on armel/armhf. > > I believe a maintainer upload or NMU of #1066981 and #1066982 would > now be enough to unblock curl, which would hopefully unblock a lot of > the C/C++ ecosystem (in particular fixing the unsatisfiable dependency > libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow > gdb to be installed), while also making life easier for the people trying > to re-bootstrap cargo. I've uploaded curl 8.6.0-4 with the patches from #1066981 and #1066982, thank you for those, Simon! Cheers, -- Samuel Henrique
Debian testing/unstable users: beware of Firefox critical CVEs
Hello everyone, Given our current time_t transition happening, which means packages are blocked from migrating to testing for weeks, and that unstable updates have become harder to apply, two critical CVE fixes for Firefox became impossible to get it through the official repositories: https://security-tracker.debian.org/tracker/CVE-2024-29943 https://security-tracker.debian.org/tracker/CVE-2024-29944 https://www.mozilla.org/en-US/security/advisories/mfsa2024-15/ The most serious one, CVE-2024-29943, is said to achieve remote code execution but it does not affect firefox-esr, only firefox. I'm sending this to d-devel because there should be a lot of testing and unstable users on this list. If you're not running firefox 124.0.1 or firefox-esr 115.9.1esr-1, you should find a way of upgrading to those versions. One valid workaround seems to be installing Firefox from Mozilla's repo: https://support.mozilla.org/en-US/kb/install-firefox-linux It might be a good time to remember that unstable and testing are not officially supported releases (as their name suggests), so issues like this do happen from time to time. In a recent case, the issue was addressed by performing a testing-proposed-update of the package. This would allow firefox-esr to be fixed on testing before the transition is over, but it would not work for those installing the firefox package from unstable on a testing machine (since there's no firefox package on testing, just firefox-esr). I hope this is useful to those who are not aware of the issue yet. Cheers, -- Samuel Henrique
Re: Debian testing/unstable users: beware of Firefox critical CVEs
> On 24-03-2024 11:45 p.m., Samuel Henrique wrote: > > In a recent case, the issue was addressed by performing a > > testing-proposed-update of the package. This would allow firefox-esr to be > > fixed on testing before the transition is over, but it would not work for > > those > > installing the firefox package from unstable on a testing machine (since > > there's no firefox package on testing, just firefox-esr). > > So, is the plan to deliver firefox-esr via tpu (after alignment with the > Release Team)? I'm not involved in the Firefox packaging so I'm cc'ing Mike Hommey, who maintains Firefox, in case he has any plans. Regards, -- Samuel Henrique
Steam Deck: good news for Linux gaming, bad news for Debian :(
Hello d-devel, As some of you already seem, we have very good news for the Linux gaming community, although somewhat bad for Debian: https://www.steamdeck.com The Steam Deck is a portable gaming device, running SteamOS, to be released later this year. Review video from 2kliksphilip: Valve Steam Deck - The Budget Gaming PC We Need https://youtu.be/zBEpymHvrpo The bad news for Debian comes from this page: https://www.steamdeck.com/en/tech Operating System: SteamOS 3.0 (Arch-based) SteamOS used to be based on Debian, and Valve seems to have decided to go with Arch instead (great news for Arch, don't get me wrong). The reasons for the switch have not been publicized, but I think we're safe to assume it's because Debian is not fit for the majority of the desktop/gaming users, at least not officially (since testing is not a supported release). I remember having some issues due to SteamOS being based on stable. These are the people who need to be able to run the most up-to-date packages, especially drivers and kernel (backports is not always there). Now, this is ok for regular users, as they can take the risk[0] of running testing to get all the benefits from it, and that's what I recommend to pretty much anyone running Debian on a desktop, though I recognize some people prefer to run stable. Debian Testing is very close to Arch wrt up-to-date packages (when not frozen) but most people don't know this and we end up being known for not supporting newer hardware/software[1]. This is a niche that is currently fulfilled by Fedora, Ubuntu non-LTS, Arch... and Debian Testing (only one which is not an official release). I know the situation is not as simple as calling Debian Testing something else and making it an official release, my intentions here are to expose the current issue we have: that we don't fulfill the needs of a lot of desktop users and SteamOS is now Arch-based, most likely because of this. So here's my wish that someday we can have a Debian semi-rolling release (if we want to have it based on Testing), with security support and a different name other than "Testing". [0] No security team support. [1] And software matters here because the gaming side of Linux still receives major improvements with new releases of things like Proton. Have a nice weekend! -- Samuel Henrique
Re: Steam Deck: good news for Linux gaming, bad news for Debian?
Hello Simon, That's an awesome reply, thank you very much for having the time to write all of this and adding the links, I have found the Steam runtime bit particularly interesting. > (Disclosure: I work for Collabora, and I'm currently working on the > Steam Runtime.) If you're ever feeling like it, I would love to see a talk from you about the inner workings of Steam on Linux/Debian. > Anyway, enough email-writing, time to get back to Assassin's Creed > Odyssey, under Proton, in a Debian-10-based Steam Runtime 2 container, > on a Debian 11 machine :-) Nice, I loved Odyssey and Origins, although I had a little bit of issues on Odyssey because I didn't go for the hard difficulty when I knew I was gonna try and do all the side quests... I ended up too powerful at the end xD. Cheers, -- Samuel Henrique
Q: uscan with GitHub
On Tue 20 Sept 2022, 01:39 Paul Wise, wrote: On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote: > Hi, what I usually do with GitHub is to use its API, since it has the > advantage of not breaking uscan when they do changes to the web UI. Since the API uses pagination, this has the minor downside of making it harder to use the uscan --download-version option with older versions. The GitHub pages are also paginated, so you get the same issue whether using the API or not. I have been hit by this on cases where upstream does enough beta|rc|snapshots releases such that the latest GA release gets in the second page and uscan fails due to not finding it.
Re: Welcome to your new installation of Debian GNU/Linux bookworm/sid
Hi, On Sun, 9 Oct 2022 at 08:41, Johannes Schauer Marin Rodrigues wrote: > the last upload of src:systemd (251.5-1) enabled firstboot by default on > Debian. From debian/changelog: > > * Enable firstboot, disabled by default on Debian. I'm confused by the above, one part says "enabled firstboot by default on Debian" and the other "disabled by default on Debian", which one is it? Regards, -- Samuel Henrique
Re: Bits from the DPL (August 2019)
> > Am I really expected to add a "me too" response every time I agree with > what > someone else took the time to write... making it harder for people with > limited > time to follow? This seems especially cruel to those that don't speak > English > natively, and those that rely on translation services. > I can't help but feel we should be using better tooling for discussions. There are various cases where I would like to +1 but I know this is frowned upon when dealing with email threads. I feel much more committed to Debian than to hackernews, although I participate much more in discussions there than in Debian ones. If we remove the fact that these tools are proprietary/not-accessible, event the worst social networks are better at doing forum type discussions than email threads. The ability to +1 without having to add something substantial to the discussion, the ease to see all the subthreads (sub discussions) without having to dig into the mail box trying to figure it out which one is about what, and the centralization of the discussion in a "tree like" structure are things that I miss a lot here. Here's me hoping that somebody has the time to propose some solution for this problem that doesn't fall into N subthreads that most of the people don't even bother trying to find or give up participating because they can't just "+1". Regards, -- Samuel Henrique
Re: Discussion tooling (was: Bits from the DPL (August 2019))
On Wed, 2 Oct 2019 at 10:48, Mathias Behrle wrote: > ...BTW no discussion tool can help in automating > separate discussion threads when the topic changes. > They can, I think reddit and hackernews are good at this. That's the "tree-like" structure that I mentioned in my email. > You will definitely lose me when I am forced to enter such an online > platform to > follow and participate in discussions. > I am 100% sure that there will be people saying they won't interact anymore if $something changes, and there will also be people who will actually stop interacting if it happens, and there will also be people that say they don't interact because of the current situation, and there will be people who will start interacting if we address it. It's impossible to do anything with 100% approval on Debian, and I think when we discuss about this we are talking about trading off receiving new contributors to the project over keeping the current ones. Both things are bad: losing current contributors and not being able to get new ones, due to the tools we use. So I'm not saying that we should totally ignore one of them. I just want to point to the fact that we need to be careful when people start saying they will stop interacting/leave if something changes because on the other side there are new contributors that don't join because of it and we need to balance both. And I mean, this is not news, almost everyone outside of Debian that I talk to have this idea that "Debian uses old and bad tools" for communications, bug reporting, and etc. I don't consider our situation to be bad as some people say, I'm here and overall happy after all, but there's definitely room for improvement. Regards, -- Samuel Henrique
Re: Discussion tooling (was: Bits from the DPL (August 2019))
On Wed, 2 Oct 2019 at 14:51, Antonio Terceiro wrote: > On Wed, Oct 02, 2019 at 01:37:58PM +0100, Samuel Henrique wrote: > > On Wed, 2 Oct 2019 at 10:48, Mathias Behrle wrote: > > > > > ...BTW no discussion tool can help in automating > > > separate discussion threads when the topic changes. > > > > > > > They can, I think reddit and hackernews are good at this. > > That's the "tree-like" structure that I mentioned in my email. > > Note that email already has a "tree-like" structure, since forever. You > just don't see it if you (ironically) use web application email clients > like gmail that decided to not show it. Most console/desktop clients > that I ever saw do support it. > Hm, but I wonder of the ones you saw how much they are used, because from the ones I see people using, I would say less than 5% (by usage) has this. And even then we are talking about tools that are either console or desktop-only, there is still the smartphone user cases and, most importantly, being able to follow the discussions without the need to authenticate and being subscribed to the list, which would be useful for outsiders (and an outsider is someone who will become a contributor eventually). And the problems with relying on the tree view of email subthreads have already been exposed here as it depends on people formatting the subthread in a specific way, which does always happens. On Wed, 2 Oct 2019 at 15:29, Jeremy Stanley wrote: > If you find that mailing list discussions lack a tree-like > structure, that's a failing of the mail client you've chosen, not > the medium itself. I don't think it helps with having new contributors to require them to use specific mail clients that are used by a small niche of mail users (talking about client percentage usage). Besides it also require one to be subscribed to the list and authenticated, so outsiders can't easily follow. I know there is a web interface for the archives but is isn't good to follow the threads as well. On Wed, 2 Oct 2019 at 15:36, Sean Whitton wrote: > > BTW no discussion tool can help in automating separate discussion > > threads when the topic changes. > > Yes, and more generally, what we are trying to deal with seems to be a > social problem, not a technical problem, so moving away from mailing > lists is unlikely to have a large impact. I don't understand the argument of it being a social problem, isn't our own constitution a technical solution to a social problem? When dealing with behavior/social problems, it's fine if you don't solve 100% of the cases, but you can certainly help by having tools that makes it harder for one to follow trough the wrong way of doing things, that's the whole point of UX. In this case, for example, this subthread started by saying that the titles need to be formatted in a correct way so it's easier to follow the big picture. Reddit and Hackernews doesn't have this problem as you're always replying to a given comment, if it's not the OP, it's a subthread. It's very hard to accidentally not open a subthread when you want to, as the "add comment" screen shows you only the one you're replying to. In the end, I'm not saying the hackernews and reddit solution are perfect, they still probably do have other problems when used as a discussion tool. I'm fine with not talking about changing the status quo anymore, I thought there would be people exposing the problems and talking about the pros/cons of the tools but it's clear that I'm the outlier here. It seems most of the community doesn't think we could have a better tool for discussions. -- Samuel Henrique
udeb of rsync
Hello debian-devel, TL:DR; What are the drawbacks of providing an rsync udeb (and am I right regarding the pros)? I would like to check in with you before moving on with this feature request. rsync: Please provide an rsync udeb https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729069 My main problem here is that I'm not experienced with udebs and using anna, so I might be missing something important here. It looks like there's good value to be delivered to our users by providing an rsync udeb, as described in the bugreport, but I'm afraid of missing some possible drawback here. For example, when reading the docs about udeb I noticed that there's lots of details that need to be paid attention to, like having all deps as udebs and listing the menu item number as 9 (not listed in the installer, but available to anna). The dependencies libacl1 and libattr1 would also need to provide udebs, and the maintainer is the same person, I will contact them if this proceeds. So would anyone advise me against doing so, and why? Thanks, -- Samuel Henrique
Re: Pimp your shell - Debian developer tips?
Sorry for being late to the discussion, but I'd like to share my dotfiles and setup script that I use for my Debian Testing machines. https://salsa.debian.org/samueloph/dotfiles I just updated the README.md to explain the high level of it. In summary, this is what I use to setup vim, atom, i3, bashrc, powerline and my packaging tools. Regards, -- Samuel Henrique
Re: RFC: Final update of DEP-14 on naming of git packaging branches
> And it also marks the proposal as ACCEPTED given that it has gained > traction over the years and that we didn't feel the need to make > significant change to it. +1 to this and the other changes. I believe we will be able to easily perform the branch naming changes under the pkg-sec team. Regards, -- Samuel Henrique
Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter
I didn't know that, fortunately i didn't ended in a situation where i needed feedback from the bug submitter. But the question is, shouldn't the bot forward to the submitter? Samuel Henrique 2016-12-26 14:29 GMT-02:00 Samuel Thibault : > This happens again and again... Quite a few maintainers don't seem to > realize that mails sent to n...@bugs.debian.org are not sent to the bug > submitter, and the bug tracking thus halts down completely when the > maintainer asks for information only to the bot, and not to the human. > > I don't know how it happens that maintainers get to reply only to > n...@bugs.debian.org , my only guess is that they just don't know that > it's not sufficient to mail the bug, so I guess the only solution is to > repeat it over and over :/ > > Samuel > >
Re: Newcomer to Debian: Help wanted
One of the best ways to start IMHO, is to get one of these packages[1] (don't get the old ones, as they're probably harder to work on) and prepare a QA upload fixing easy things, like: DH bump Standards Version bump Fix/bump d/watch Convert d/copyright to DEP-5 Change maintainer to QA Group Fix typos wrap-and-sort a Package new release ACK bugs with patch attached (eg.: the reproducible-builds team is always opening bugs with patch attached, and BTW they're awesome) The QA upload can be sponsored by any DD, and you can ask sponsorhip ont mentors. [1]https://www.debian.org/devel/wnpp/orphaned_byage Samuel Henrique 2017-01-08 10:54 GMT-02:00 Jonas Smedegaard : > Quoting Vijeth T Aradhya (2017-01-08 13:23:41) > > Firstly, thank you so much for such a quick response! It's really nice > > when the community responds to you so quickly, hopefully I can be a > > part of it in the coming near future :) > > > >> Mentioned briefly in first URL above, but I'd like to emphasize one > >> suggestion: Cosnider join (or at list get in touch with) the teams > >> relevant for your particular interests. Here's an incomplete list: > >> https://wiki.debian.org/Teams > >> > >> > > I looked at the teams, and I have sent a mail to pkg-GPG about joining > > and development there. This was mainly because I became interested in > > PGP/PKI Clean Room Project proposed by Daniel Pocock on his blog. ( > > https://danielpocock.com/outreachy-gsoc-2017-pki-clean-room). > > Hopefully, they will get back to me! > > > > I'll look at other teams as well! > > Great. > > You mentioned Haskell specifically, and I know that team will appreciate > more participants. Probably same for most if not all teams - just > wanted to encourage your exploring more options, now that you asked. > > > > Any other path you suggest which will help me get acquainted with the > > org so that it will help with Gsoc? > > There are so many suggestions, but also so much already documented at > many places. I think pabs referenced plenty of god starting points. > > Seem you might also appreciate reading how we prefer to use > mailinglists: https://www.debian.org/MailingLists/#codeofconduct > > Welcome to the World of Debian :-) > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > >
Re: Debian Policy 4.1.5.0 released
Helllo, 9.1.1 > Update Debian's version of the Filesystem Hierarchy Standard from > 2.3 to 3.0, and update the list of exceptions. Only a tiny minority > of packages, if any, should be made buggy by this change. > Where can i read debian's FHS 3.0? I can only see 2.3 on https://www.debian.org/doc/packaging-manuals/fhs/ -- Samuel Henrique
Re: Debian Policy 4.1.5.0 released
Hello Roberto, On Wed, 4 Jul 2018 at 11:03, Roberto C. Sánchez wrote: > On Wed, Jul 04, 2018 at 10:58:12AM -0300, Samuel Henrique wrote: > >Helllo, > > > > 9.1.1 > > Update Debian's version of the Filesystem Hierarchy Standard > from > > 2.3 to 3.0, and update the list of exceptions. Only a tiny > minority > > of packages, if any, should be made buggy by this change. > > > >Where can i read debian's FHS 3.0? > >I can only see 2.3 on [1] > https://www.debian.org/doc/packaging-manuals/fhs/ > > > It is kind of a pain to locate. Here is the link: > https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf > Oh, i misunderstood the email, i was thinking there was like a "Debian FHS 3.0", but it was actually meaning that we just updated our FHS with "upstream's" FHS 3.0. Thanks -- Samuel Henrique
Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))
Hello everyone, I sent an email on 1st June (when this thread started) to debian-steam[a] collabora.com requesting it but got no response. Is it still going? Did you receive a reply Alexandre? Thanks On Fri, 1 Jun 2018 at 16:10, Alexandre Viau wrote: > On 2018-06-01 01:22 PM, Andrej Shadura wrote: > > The benefit should still be valid. The person responsible for it is > > already looking into it, expect a reply shortly ;) > > Great, thanks :)! > > -- > Alexandre Viau > av...@debian.org > > > -- Samuel Henrique
Re: Leftover in ftp-master.debian.org/dm.txt after DM -> DD transition
I noticed that my key is also there as a DM. And I'll pretty soon ask for a key transition and stop using that one. Maybe it should be removed from there? It doesn't have to be now but at least put on the next batch maybe. -- Samuel Henrique
The deal with our old logo[s?] (the penguin one)
As some of you may not know, Debian used to have a penguin logo[1]. The only reference i could find of it does not tell much[1]. I could also find some (almost none) detail about the first logo from a cool guy's blog[2]*. Where can i read more about our logo's history? (at least for how long they were used) Does any of our ancients DDs have some intel? [1]https://www.debian.org/vote/1999/vote_0004 [2]http://ianmurdock.debian.net/index.html%3Fp=1880.html * Worth mention that's Ian Murdock, the founder of Deb*ian*, for the few ones that don't know this yet. Thanks. Samuel Henrique
Re: X facts about Debian - some fact checking and looking for ideas.
CC'ing to pkg-sec As far as fact-checking goes, can anybody share about Debian and Kali > Linux relationship in bit more detail. AFAIK Raphaël Hertzog is one of > the main developers and there has been lot of symbiotic relationship > between the two projects but how much both projects have benefited > from this partnership has not been codified or told/shared anywhere > AFAIK. Samuel Henrique 2017-08-23 23:31 GMT-03:00 shirish शिरीष : > Dear all, > > I have been writing some beginner articles in my spare-time to > talk/share about Debian and make it more popular. > > In that direction I have and had been penning few articles at > https://itsfoss.com/author/shirish/ > > As shared before, these are beginner articles and are meant only to > bring awareness about Debian to the masses. > > Just a few days back, Debian turned 24 > https://bits.debian.org/2017/08/debian-turns-24.html > > While I have been thinking about sharing the number of packages, the > number of developers, the diversity, the debconf's and where debconfs > have been held over the years for starters but all of these I have > already shared before. > > I saw hartmann's article on p.d.o. the other day > http://hartmans.livejournal.com/96841.html and I started pondering > about some of the lesser unknown innovative ideas of debian which > people don't know about. > > For e.g. the reproducible builds project > https://reproducible-builds.org/ seems to have a lot of weight and > faith of DD's but is not known at all (or maybe some slightly bit) > outside the technical circles. > > Are there any such unsung technical/non-technical or social > innovations that Debian has done that is now known/or lesser known > which Debianities should know about and be proud about. Having more > Debian fanboys should also increase both participation and > contribution to Debian. > > As far as fact-checking goes, can anybody share about Debian and Kali > Linux relationship in bit more detail. AFAIK Raphaël Hertzog is one of > the main developers and there has been lot of symbiotic relationship > between the two projects but how much both projects have benefited > from this partnership has not been codified or told/shared anywhere > AFAIK. > > The only thing I could get is > https://docs.kali.org/policy/kali-linux-relationship-with-debian which > seems to be pretty dry and short as far as documentation goes. > > Looking forward to knowing more. > > -- > Regards, > Shirish Agarwal शिरीष अग्रवाल > My quotes in this email licensed under CC 3.0 > http://creativecommons.org/licenses/by-nc/3.0/ > http://flossexperiences.wordpress.com > EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 > >
Re: Announcing new pkg-security team
Hi, That is great news, i maintain the package goldeneye(a HTTP DoS Test Tool), which i believe it would be nice to maintain together with the security team, i started to package T50[1] too and i believe it is aligned with the security team too, at least that's what i thought when i read in the alioth page that the team will also focus on pentest tools (i was missing a team like that). I'm still a novice regarding packaging, but i'm very much excited to join the team, over the next two weeks i will see what can i do to help (right now college is taking too much time). I didn't understand one part though, the alioth page says "All security related tools are welcome: penetration testing tools, forensics tools, hardening tools, network monitoring tools, etc." How does this team relate to the forensics team? It seems confusing to have a forensics team and a security team which will treat forensics packages. In my opinion, we should have only one team integrating both, maybe the forensics team could be merged into security? [1]https://github.com/fredericopissarra/t50 Samuel Henrique O. P. [samueloph] 2016-06-20 3:55 GMT-03:00 Gianfranco Costamagna : > Hi Arturo, > > > > >I'm involved in a couple of related packages [0][1] which I would be > >very happy to integrate in this new team. > > > can you please join the team [1], and create the repositories/ask for > sponsorship? > > > You should just need a "setup-repository", change the maintainer/uploaders > fields, > git push and ping for sponsorship in case (I see one of them is not under > DM permission.) > (feel free to read the wiki, and correct in case something is wrong, and > if you have > not enough permission to create the repo, ping me privately, also for > sponsoring) > > > [1] https://alioth.debian.org/project/memberlist.php?group_id=101003 > > thanks! > > Gianfranco > >
Re: Thinking about a "jessie and a half" release
2016-07-05 7:43 GMT-03:00 Jose R R : > > Why would you call it "Jessie + 1/2"? Wouldn't it be a better idea > Well IBM set a precedent for that: OS/2. > Accordingly, Jessie BP could be called Jessie/2 ;-) Well, that would be a half Jessie, not Jessie and a half, right? We could use 3Jessie/2 or Jessie3/2, or maybe not. Mark Brown > We're getting to the point where there's a fairly pressing need for > arm64 - the more useful hardware is starting to get a wider distribution > and we don't really have anything for people who want to run Debian > that gets them a supported system with an upgrade path. > We have Debian Stretch, which is what i recommend to anybody who wants do install Debian as a desktop. I understand the difference of running Debian Testing and Debian Stable with some backported packages, but is it really worth it? Shouldn't we discuss more the usability of Testing as a solid release, or maybe start doing a stable release and another release kinda like Testing but with more stability guarantees? I'm not really sure, but i think opensuse has a model like that. I use debian for a considerable amount of time now, but just started interacting with the community recently, having installed debian to a lot of new users on installfests over the years, one of the most common problems i found out for novice Debian users is that they don't really know how Debian releases works and thinks using stable in their laptop bought last year is a good idea, then i always end up having a conversation where they're needing help with problems related to using stable, i have to explain things like: why their performance is crap, why they can't see youtube html5 videos on iceweasel version lastversion-4, why they can't install softwares like steam (wheezy was a hard one on this)* and how the testing stability is the same, or better, than of the other distros they used to use. They always end up using Debian Testing, knowing that the main risk comes when the unfreeze happens and that while the freeze is rolling they will have a more stable debian (compared to when unfreezed). *these are just some of the various conversations i've had. Unfortunately i' not attending DebConf, but it is a great opportunity to discuss things like this there, maybe even form a team and work on policies changes for this "new testing" release, if i'm not dreaming too big. Samuel Henrique O. P. [samueloph]
Re: Dropping awk?
On Thu, 17 Apr 2025 at 19:41, Santiago Vila wrote: > Installed size of mawk is 263 MB which is really small for today's standards. Isn't that bad for the Debian minimal images for containers? I'm not too familiar with how we generate our container images but I can see mawk there and Debian is used on most official container images of other projects. Cheers, -- Samuel Henrique
Bug#1101076: ITP: rsync -- rsync in Go! implements client and server, which can send or receive files (upload, download, all directions supported)
Package: wnpp Severity: wishlist Owner: Samuel Henrique X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: rsync Version : 0.2.6-1 Upstream Author : Michael Stapelberg * URL : https://github.com/gokrazy/rsync * License : BSD-3-clause Programming Lang: Go Description : rsync in Go! implements client and server, which can send or receive files (upload, download, all directions supported) Given the current status of the maintenance on rsync upstream, it's going to be handy to have an alternative packaged in the repository just in case. I haven't played much with this software yet, but I plan to package it for forky. Thank you, -- Samuel Henrique
