All main products from Microsoft, Adobe, Macromedia, Corel, etc.
Software taking a bite out of your budget? Try OEM! http://nvc.8xcnb781ni8fn98.goodingdn.com Make voyages! - Attempt them! - there's nothing else... Audacious ribald: your laughter will finish in hideous boredom before morning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: where is #define __linux__
On Mon, Jan 08, 2001 at 11:05:54PM -0800, Aaron Brashears wrote: > > While on the topic, is there a > magic preprocessor definition that lets me know if I'm on > sunos/solaris? yes indeedy. multiple. there is __sun__ to detect solarisORsunos, and __svr4__ to detect solaris specifically, I believe. there is also __sparc__ and __i386__ to deal with
DD's, Debian Mentors needs you!
Hi all DD's Debian Mentors[1] always struggles to find available Debian Developers for final reviewing and sponsoring of packages submitted too our part of the project. We believe some packages are ready or very close to the quality for sponsorship and we would request any DD who has the time and is willing, to have a look at one or more of the packages below and possibly sponsor them into Debian. Mentors page: https://mentors.debian.net/package/hexwalk/ Request For Sponsorship (RFS): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065008 Mentors page: https://mentors.debian.net/package/uriparser/ Request For Sponsorship (RFS): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074542 Mentors page: https://mentors.debian.net/package/mailgraph/ Request For Sponsorship (RFS): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074552 Mentors page: https://mentors.debian.net/package/dmidecode/ Request For Sponsorship (RFS): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074553 Mentor page: https://mentors.debian.net/package/selint/ Request For Sponsorship (RFS): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074592 Your assistance will be extremely appreciated and if announcing a few at a time on the 'devel' list works, this could become a weekly thing. [1] https://mentors.debian.net Regards Phil -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Re: DD's, Debian Mentors needs you!
On Sat, 2024-07-06 at 17:42 -0700, Otto Kekäläinen wrote: > Hi! > > > https://mentors.debian.net/package/uriparser/ > > https://mentors.debian.net/package/mailgraph/ > > This is the same maintainer, I can take this on. > > > https://mentors.debian.net/package/selint/ > > I have worked with this maintainer before, I can help him now too. > > > After this Hexwalk still needs a mentor. Hi Otto, Many thanks for giving your time. selint has been picked up by Pierre Gruet via the Request For Sponsorship (RFS) bug[1], so I think that one is OK. The other two are happily yours. :-) [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074592 Regards Phil -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Re: DD's, Debian Mentors needs you!
On Sun, 2024-07-07 at 07:41 +0800, xiao sheng wen(肖盛文) wrote: > Hi, > > Support this become a weekly thing or a monthly thing. > > Can mentors.debian.net sent package list to debian-devel automatically? > > Regards, > xiao sheng wen > 在 2024/7/6 21:45, Phil Wyett 写道: > > Hi all DD's > > > > Debian Mentors[1] always struggles to find available Debian Developers for > > final reviewing and > > sponsoring of packages submitted too our part of the project. > > > > We believe some packages are ready or very close to the quality for > > sponsorship and we would request > > any DD who has the time and is willing, to have a look at one or more of > > the packages below and > > possibly sponsor them into Debian. > > > > Mentors page: > > https://mentors.debian.net/package/hexwalk/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065008 > > > > Mentors page: > > https://mentors.debian.net/package/uriparser/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074542 > > > > Mentors page: > > https://mentors.debian.net/package/mailgraph/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074552 > > > > Mentors page: > > https://mentors.debian.net/package/dmidecode/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074553 > > > > Mentor page: > > https://mentors.debian.net/package/selint/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074592 > > > > Your assistance will be extremely appreciated and if announcing a few at a > > time on the 'devel' list > > works, this could become a weekly thing. > > > > [1] https://mentors.debian.net > > > > Regards > > > > Phil > > > > -- > 肖盛文 xiao sheng wen > https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 > 操作系统 > Debian QA page: > https://qa.debian.org/developer.php?login=atzlinux%40sina.com > Debian salsa: https://salsa.debian.org/atzlinux-guest > GnuPG Public Key: 0x00186602339240CB Hi Xiao and all, I am not sure if this could be done automatically. Mentors uses the expo platform and that will take some research and discussion to see what maybe could be done. We could create a wiki page with ready packages for DD attention that could be forwarded in a mail to this list at a set interval. Maybe more experienced DDs/Contributors to Mentors such as Andrey Rakhmatullin may have more insight than I here. Regards Phil -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Re: DD's, Debian Mentors needs you!
On Sun, 2024-07-07 at 11:29 +0500, Andrey Rakhmatullin wrote: > On Sun, Jul 07, 2024 at 07:54:25AM +0200, Andreas Tille wrote: > > Hi Phil, > > > > thanks for advertising Debian Mentors. > > > > Am Sat, Jul 06, 2024 at 02:45:33PM +0100 schrieb Phil Wyett: > > > Hi all DD's > > > > > > Debian Mentors[1] always struggles to find available Debian Developers > > > for final reviewing and > > > sponsoring of packages submitted too our part of the project. > > > > One thing I'm missing on mentors.d.n is that I it does not advertise > > existing teams. It happened from time to time that there was some > > sponsoring request of Debian Science, Debian Med or Debian Python Team > > related packages (surely others I did not notices). Asking on the > > relevant lists very easily helps getting the package in question > > sponsored. I have a personal sponsoring policy that I only sponsor from > > a Git repository in a team I'm working in. This has the advantage I can > > easily help by pushing some commit with extensive comment to teach the > > sponsee in some direct way. Making a sponsee aware how to work together > > with a team inside Debian is IMHO very important. > > > > Thus I would welcome if there could be some explicit hint to mentees > > to relevant teams. > > Note that "Offer your package directly to relevant teams and individual > developers." is sugested on https://mentors.debian.net/intro-maintainers/ > and https://mentors.debian.net/sponsors/ > Andreas, Andrey and All, Andrey has kindly offered links for relevant information here. Any additions or changes etc. of course would be subject to discussion and consensus on the mentors mailing list. Regards Phil -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Re: DD's, Debian Mentors needs you!
Morning Soren, Many thanks for the kinds words and the encouragement. As you stated wonderfully and I will additionally offer a little of my mentors motivations. Debian mentors can be the first experience of contribution to not just Debian, but Free and Open Source Software projects in general. Though technical, having mentors be welcoming and friendly (we all started knowing nothing) environment with consistency of "here are the tests/standards required by all" I hope with the help of others, make mentors a successful part of the Debian project that attracts and retains contributors. I must thank Gianfranco Costamagna who initially showed me the value of Debian mentors and encouraged me to get involved. Regards Phil On Sat, 2024-07-06 at 23:18 -0700, Soren Stoutner wrote: > After reading a number of comments to the email below, I thought I would > provide a bit of context for this email and Phil’s excellent work on Mentors. > > Recently Phil has taken it upon himself to triage every package that requests > sponsorship on mentors.debian.net. Here is an example of the work he does: > > https://lists.debian.org/debian-mentors/2024/07/msg00032.html > > When he feels a package is ready for sponsorship, he indicates that with an > email to the list. > > https://lists.debian.org/debian-mentors/2024/07/msg00024.html > > In some cases, nobody picks these up. The email below was sent to debian- > devel with a curated list of packages that Phil has already reviewed and > feels > are ready for a DD to sponsor. > > At any point, anyone can look at all of the packages on Mentors requesting a > sponsor. > > https://mentors.debian.net/ > > But I have found Phil’s work to be very helpful, as I have limited time to > handle sponsorships. When I look at a package Phil has endorsed, I can be > sure that the simple and obvious things have already been taken care of. > > I would heartily hope that Phil continues to send periodic emails to debian- > devel with lists of packages that he considers ready, but that are > languishing > on the vine because nobody has noticed them. I would also encourage anyone > else to get involved in this process if they feel so inclined. I think that > one of the most important aspects of attracting people to Debian is to make > it > easy for someone who is not yet a DD or DM to submit packages and have them > be > reviewed promptly. There is probably nothing as demotivating to a first-time > contributor as putting a lot of effort into a package, having it be in good > shape, and then never having it be sponsored simply because it didn’t get > noticed. > > Soren > > P.S. Based on Phil’s work on Mentors and my interactions with him, I have > advocated for him to become a Debian Developer, uploading. I think his > contributions to Debian will be even more impactful when he can sponsor the > packages he feels are ready. > > https://nm.debian.org/process/1305/ > > On Saturday, July 6, 2024 6:45:33 AM MST Phil Wyett wrote: > > Hi all DD's > > > > Debian Mentors[1] always struggles to find available Debian Developers for > > final reviewing and sponsoring of packages submitted too our part of the > > project. > > > > We believe some packages are ready or very close to the quality for > > sponsorship and we would request any DD who has the time and is willing, to > > have a look at one or more of the packages below and possibly sponsor them > > into Debian. > > > > Mentors page: > > https://mentors.debian.net/package/hexwalk/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065008 > > > > Mentors page: > > https://mentors.debian.net/package/uriparser/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074542 > > > > Mentors page: > > https://mentors.debian.net/package/mailgraph/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074552 > > > > Mentors page: > > https://mentors.debian.net/package/dmidecode/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074553 > > > > Mentor page: > > https://mentors.debian.net/package/selint/ > > Request For Sponsorship (RFS): > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074592 > > > > Your assistance will be extremely appreciated and if announcing a few at a > > time on the 'devel' list works, this could become a weekly thing. > > > > [1] https://mentors.debian.net > > > > Regards > > > > Phil > > -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Re: DD's, Debian Mentors needs you!
On Sat, 2024-07-06 at 23:45 -0700, Xiyue Deng wrote: > Soren Stoutner writes: > > > [[PGP Signed Part:Undecided]] > > After reading a number of comments to the email below, I thought I would > > provide a bit of context for this email and Phil’s excellent work on > > Mentors. > > > > Recently Phil has taken it upon himself to triage every package that > > requests > > sponsorship on mentors.debian.net. Here is an example of the work he does: > > > > https://lists.debian.org/debian-mentors/2024/07/msg00032.html > > > > When he feels a package is ready for sponsorship, he indicates that with an > > email to the list. > > > > https://lists.debian.org/debian-mentors/2024/07/msg00024.html > > > > In some cases, nobody picks these up. The email below was sent to debian- > > devel with a curated list of packages that Phil has already reviewed and > > feels > > are ready for a DD to sponsor. > > > > At any point, anyone can look at all of the packages on Mentors requesting > > a > > sponsor. > > > > https://mentors.debian.net/ > > > > But I have found Phil’s work to be very helpful, as I have limited time to > > handle sponsorships. When I look at a package Phil has endorsed, I can be > > sure that the simple and obvious things have already been taken care of. > > > > I would heartily hope that Phil continues to send periodic emails to debian- > > devel with lists of packages that he considers ready, but that are > > languishing > > on the vine because nobody has noticed them. I would also encourage anyone > > else to get involved in this process if they feel so inclined. I think > > that > > one of the most important aspects of attracting people to Debian is to make > > it > > easy for someone who is not yet a DD or DM to submit packages and have them > > be > > reviewed promptly. There is probably nothing as demotivating to a > > first-time > > contributor as putting a lot of effort into a package, having it be in good > > shape, and then never having it be sponsored simply because it didn’t get > > noticed. > > > > Soren > > > > P.S. Based on Phil’s work on Mentors and my interactions with him, I have > > advocated for him to become a Debian Developer, uploading. I think his > > contributions to Debian will be even more impactful when he can sponsor the > > packages he feels are ready. > > > > https://nm.debian.org/process/1305/ > > > > On Saturday, July 6, 2024 6:45:33 AM MST Phil Wyett wrote: > > > Hi all DD's > > > > > > Debian Mentors[1] always struggles to find available Debian Developers for > > > final reviewing and sponsoring of packages submitted too our part of the > > > project. > > > > > > We believe some packages are ready or very close to the quality for > > > sponsorship and we would request any DD who has the time and is willing, > > > to > > > have a look at one or more of the packages below and possibly sponsor them > > > into Debian. > > > > > > Mentors page: > > > https://mentors.debian.net/package/hexwalk/ > > > Request For Sponsorship (RFS): > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065008 > > > > > > Mentors page: > > > https://mentors.debian.net/package/uriparser/ > > > Request For Sponsorship (RFS): > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074542 > > > > > > Mentors page: > > > https://mentors.debian.net/package/mailgraph/ > > > Request For Sponsorship (RFS): > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074552 > > > > > > Mentors page: > > > https://mentors.debian.net/package/dmidecode/ > > > Request For Sponsorship (RFS): > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074553 > > > > > > Mentor page: > > > https://mentors.debian.net/package/selint/ > > > Request For Sponsorship (RFS): > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074592 > > > > > > Your assistance will be extremely appreciated and if announcing a few at a > > > time on the 'devel' list works, this could become a weekly thing. > > > > > > [1] https://mentors.debian.net > > > > > > Regards > > > > > > Phil > > As one of those who received help from Phil who kindly helped review my > packages and finding potential sponsors
Re: DD's, Debian Mentors needs you!
On Sun, 2024-07-07 at 11:32 +0200, Niels Thykier wrote: > Soren Stoutner: > > After reading a number of comments to the email below, I thought I would > > provide a bit of context for this email and Phil’s excellent work on > > Mentors. > > > > Recently Phil has taken it upon himself to triage every package that > > requests > > sponsorship on mentors.debian.net. Here is an example of the work he does: > > > > [...] > > Hi, > > I wholehearted agree that Phil is doing a lot of good work here and that > it is helpful to all parties involved in d-mentors. From my PoV, what > Phil does is so valuable that ideally we would provide it to all > sponsored maintainers with minimal latency. For me, that means > automating most of what Phil does. Ideally all, but I am not sure all > the things Phil does are trivial to automate where we are now. > Many thanks. > > But I have found Phil’s work to be very helpful, as I have limited time to > > handle sponsorships. When I look at a package Phil has endorsed, I can be > > sure that the simple and obvious things have already been taken care of. > > > > Thinking a bit more on this and its long term sustainability, I think we > have a spot here where we could automate the process a lot. If we look > at the list of things Phil does: > > 1. Build: > > Automate-able if we had good sandboxes/throw away build machines. > > 2. Lintian: > > I think mentors.d.o already does this. But it only works on the > artifacts uploaded and Phil probably enriches this. > > 3. Licenses: > > While ideally, we would want this to be automatic, I think we do not > have a good solution to this and I doubt we get it any time soon. > > Though an 80/20 might be in our grasp for someone interested and > I do not think it would need to depend on 1). > > 4. Build Twice (sudo pbuilder build --twice .dsc): > > Automate-able once 1) is solved. > > 5. Reproducible builds (reporotest): > > Trivially automate-able once 1) is solved. > > 6. Install/Upgrade: > > It sounds like something piuparts would check, so I assume this is > all solvable once 1) is complete. > > 7. Curating packages that pass these checks to various prospective > sponsors (such as the mail we are all replying to) > > These automations would not replace Phil since Phil in "failure" cases > provides suggestions on how to move forward. This part we would ideally > automate as well, but that is a much harder problem for most of these > checks. Still, having a "red/green" marker would enable newcomers to > figure out where they need more effort or assistance. > > The salsa-CI pipeline basically does most of these (3+7 being very clear > exceptions, do not remember if 4 is covered by salsa-ci, but adding it > would probably easy) and that infrastructure already has "no trust" code > execution flows. Another alternative might be leveraging debusine if > that can do the same and is intended for this purpose (did not check). > > In theory, we can reduce this to a already solved problem by linking the > RFS/mentors entry with the relevant CI pipeline report where possible > and a "Consider using the salsa-CI pipeline" check. Might need > tag2upload or dgit (assuming these support mentors.d.o), since that > would make the commit visible. Additional bells and whistles can be > added to the salsa-CI pipeline in the form of a small machine readable > report output that mentors.d.n could render if necessary (etc.) > > I do think it could be a major improvement our sponsorship work flow for > both sponsors and sponsored maintainers. > > 1) We promote a streamlined packaging workflow that a large portion of > Debian already follows and leverage existing infrastructure. Any > updates to our workflow would appear into the sponsor workflow > checklist workflow because they are the same underlying checks. > > 2) The workflow provides most of these checks with low latency > automation and would save the sponsored maintainers RFS + > mentors.d.o upload round trips. > > 3) The process would be a lot more sustainable, since most of it would > be automatic. > > Obviously, on paper is doable but it might require ironing out a lot of > bends or even not be possible at all. Sadly, I am not volunteering to do > it (got too much on my plate already). However, I am putting the idea > out there in case someone has time and interest in working on this area. > > I think the primary risk (problem to solve) is linking the
Re: DD's, Debian Mentors needs you!
On Sun, 2024-07-07 at 22:51 +0200, Andreas Tille wrote: > Hi Phil, > > Am Sun, Jul 07, 2024 at 08:48:22AM +0100 schrieb Phil Wyett: > > Thank you for the kind words. I agree whole heartedly with your comments > > that more people getting > > involved to make for a better Debian mentors would be good. Debian mentors > > is a great place to be > > around and we all learn something being involved. > > Thanks to you and all your work for mentors.d.n. Just to clarify my > mail about connecting to teams (which is done as I learned in response): > I did by no means intended to lower the importance of mentors.d.n in > general for Debian and newcomers. > > Thanks again > Andreas. > Hi Andreas, No need at all for your clarification. My words were generally meant to be an ideal for what I feel that mentors should be and what people can gain from it. Your comments regarding connecting teams are in my thoughts for how we can do better in this direction. I did reach out to the python team a little while ago to find sponsors for a few python packages that had been languishing on mentors. This turned into a discussion if the python team can approach sponsoring in a different way and the ruby team was put forward, who have a very good procedures for sponsoring. I am not yet ready to let these thoughts out as yet until they are fully formed and be best put forward to contributors to mentors etc. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: DD's, Debian Mentors needs you!
On Mon, 2024-07-08 at 21:30 +0200, Baptiste Beauplat wrote: > Hi, > > On Sun, 2024-07-07 at 07:41 +0800, xiao sheng wen(肖盛文) wrote: > > Support this become a weekly thing or a monthly thing. > > > > Can mentors.debian.net sent package list to debian-devel automatically? > > It could. There is actually an issue for that[1], but no one has worked > on it yet. > > Note that, there is also an api on mentors[2], that an external > provider could use that to craft and send those weekly reports > automatically. > > Best, > > [1]: https://salsa.debian.org/mentors.debian.net-team/debexpo/-/issues/42 > [2]: https://mentors.debian.net/api/ > Morning, The API currently does not seem to expose the data to extract to create such a report. When comment is done in the comment box for an upload, we have a dropdown with: * Not reviewed * Needs work * Ready The above data does not seem to be stored. The up-loader also has the ability to mark an their upload as ready. These would need to be addressed before any viable report could be thought about. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: DD's, Debian Mentors needs you!
On Sun, 2024-07-07 at 13:20 +0200, Joerg Jaspert wrote: > On 17283 March 1977, Soren Stoutner wrote: > > > P.S. Based on Phil’s work on Mentors and my interactions with him, I > > have > > advocated for him to become a Debian Developer, uploading. I think > > his > > contributions to Debian will be even more impactful when he can > > sponsor the > > packages he feels are ready. > > It is only just July. He got rejected in May once - that's a bit too > soon yet. (The usual time for a retry is somewhere around 6 month, and > includes acknowleding (and working on) issues of the rejection). > > Note that it is not only technical knowledge that is required. That's > "just" part of it. > Morning Joerg, Thank you for your comments. Indeed, less than 24 hours later, I received an email stating my Debian Developer (DD), with upload application was to be closed and now has been. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: DD's, Debian Mentors needs you!
On Tue, 2024-07-09 at 14:23 +0200, Pierre-Elliott Bécue wrote: > Hello, > > Phil Wyett wrote on 09/07/2024 at 11:40:32+0200: > > > On Sun, 2024-07-07 at 13:20 +0200, Joerg Jaspert wrote: > > > On 17283 March 1977, Soren Stoutner wrote: > > > > > > > P.S. Based on Phil’s work on Mentors and my interactions with him, I > > > > have > > > > advocated for him to become a Debian Developer, uploading. I think > > > > his > > > > contributions to Debian will be even more impactful when he can > > > > sponsor the > > > > packages he feels are ready. > > > > > > It is only just July. He got rejected in May once - that's a bit too > > > soon yet. (The usual time for a retry is somewhere around 6 month, and > > > includes acknowleding (and working on) issues of the rejection). > > > > > > Note that it is not only technical knowledge that is required. That's > > > "just" part of it. > > > > > > > Morning Joerg, > > > > Thank you for your comments. Indeed, less than 24 hours later, I > > received an email stating my Debian Developer (DD), with upload > > application was to be closed and now has been. > > > > Regards > > FTAOD I closed this process without interacting DAM or Joerg and not > having read his mail. I will reopen it as I stated to you when the > proper time comes. > > I'm really happy that you're trying to work on making mentors.d.n more > proficient and active, and I'm also happy that you didn't get > demotivated by the different exchanges we collectively had in the past. > > As Joerg stated, we'll probably need to have a chat about the reasons > that led to the initial rejection and your thoughts on the whole > thing. That being said, I won't go into details publicly and I do hope > that you'll indeed come back to us in a few months so we can try going > forward. > > In the meantime, I'd like to express my gratitude for your commitment. > > Bests, Afternoon, There will be no seeking to reopen the application. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)
Morning all, As we embark on a new process where packages submitted to mentors are reviewed and brought to a "Ready" stage for then busy DDs who are gracious enough to give their time to review and possibly sponsor into Debian. We have a unique problem (one which is now a nice one to have to be honest :-)) where more than one DD may input on the same package review. Could submitters to mentors and DDs please ensure that only one DD is working on a package. This is to avoid conflicting info and also not waste valuable DD time. If a package is taken, please find another to work on, as there are many at the "Ready" stage. Many thanks for your cooperation. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)
On Fri, 2024-07-12 at 10:44 +0500, Andrey Rakhmatullin wrote: > On Fri, Jul 12, 2024 at 05:54:59AM +0100, Phil Wyett wrote: > > Morning all, > > > > As we embark on a new process where packages submitted to mentors are > > reviewed > > and brought to a "Ready" stage for then busy DDs who are gracious enough to > > give > > their time to review and possibly sponsor into Debian. We have a unique > > problem > > (one which is now a nice one to have to be honest :-)) where more than one > > DD > > may input on the same package review. > > > > Could submitters to mentors and DDs please ensure that only one DD is > > working on > > a package. This is to avoid conflicting info and also not waste valuable DD > > time. If a package is taken, please find another to work on, as there are > > many > > at the "Ready" stage. > > Do you also suggest to not review packages one isn't going to sponsor? Or > how should this work? > Morning Andrey, Anyone can review packages, that has been part of mentors forever really. But whoever does review a package, I would hope they see it through its journey. * For non DDs. Hopefully take it to that ready stage where a DD can then take over and finish a packages journey. * For DDs. Hopefully take a package on prior to or at the ready stage and take it through its full journey. Is this reasonable? Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Debian mentors - Packages looking for DD review and sponsorship - 2024 - 07 - 13
Evening all Debian Developers, Below is a curated list of packages in Debian Mentors[1] that are felt to be ready for review and possible sponsorship into Debian. rumur - https://mentors.debian.net/package/rumur/ RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071427 c-evo-dh - https://mentors.debian.net/package/c-evo-dh/ RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075861 wasix-libc - https://mentors.debian.net/package/wasix-libc/ RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058016 baby - https://mentors.debian.net/package/baby/ RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075734 libmobi - https://mentors.debian.net/package/libmobi/ RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073960 mangl - https://mentors.debian.net/package/mangl/ RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074777 colorize - https://mentors.debian.net/package/colorize/ RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073456 By sponsoring a package on this occasion is not a commitment to sponsoring the package in the long term if you cnnot commit to that. Supporting Debian mentors and giving of your time is appreciated. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: i686 require SSE4.1-capable processor?
On Mon, 2024-07-15 at 17:20 +0200, Philipp Kern wrote: > [Also adding Phil] > > On 15.07.24 14:52, Andreas Ronnquist wrote: > > > Packages built for the i386 arch need to conform to the i386 baseline, > > > which is currently i686. If a package contains a newer instruction it's a > > > bug in that package and gcc is not the cause of it, the package is. > > > https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0 > > > indeed contains at least one compile command with -msse4.1. > [...] > > Yeah, I have discovered that it is indeed a cause of the d/rules in the > > filezilla package. I blame having taken over it recently, and still > > haven't learned the ins and outs of it. > > It'd also be good to document reasons for such workarounds next time. > Both the changelog and the surrounding comments don't really tell you > what to watch out for in a new gcc version. There's no bug reference > (GCC or Debian bug) or example error message or a pointer to possible > miscompilation. > > Kind regards > Philipp Kern > Hi all, The addition to 'debian/rules' was in response to the below. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053804 Debian may have moved on to where this temporary workaround is no longer needed. You may wish to contact the original reporter at some point. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: i686 require SSE4.1-capable processor?
On Tue, 2024-07-16 at 14:36 +0200, Philipp Kern wrote: > Hi, > > On 2024-07-16 14:14, Andrey Rakhmatullin wrote: > > On Tue, Jul 16, 2024 at 12:46:01PM +0100, Phil Wyett wrote: > > > > > > Packages built for the i386 arch need to conform to the i386 > > > > > > baseline, > > > > > > which is currently i686. If a package contains a newer instruction > > > > > > it's a > > > > > > bug in that package and gcc is not the cause of it, the package is. > > > > > > https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0 > > > > > > indeed contains at least one compile command with -msse4.1. > > > > [...] > > > > > Yeah, I have discovered that it is indeed a cause of the d/rules in > > > > > the > > > > > filezilla package. I blame having taken over it recently, and still > > > > > haven't learned the ins and outs of it. > > > > It'd also be good to document reasons for such workarounds next time. > > > > Both the changelog and the surrounding comments don't really tell you > > > > what to watch out for in a new gcc version. There's no bug reference > > > > (GCC or Debian bug) or example error message or a pointer to possible > > > > miscompilation. > > > The addition to 'debian/rules' was in response to the below. > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053804 > > That bug report looks like the outcome of the "addition", not the > > reason > > for it. Did you mean > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034195 ? > > Yeah it'd have been good if there had been a link to that. E.g. in the > changelog or as a comment in debian/rules. > > > The interactions in both bugs look very weird to me, especially when > > the > > same person proposes compiling software with SSE4.1 and then complains > > that it fails on older hardware, and the reason for closing the newer > > bug > > also looks weird to me. I think it should be reopened and bumped to RC. > > I'm a bit confused as to why Filezilla bundles an ancient version of > Putty. The official Putty code does compile *that specific unit*[1] with > -msse4.1 but there is also a gate in the code to only use the > accelerated path if cpuid signals support for the new instructions. As > far as I can see you added the flag to all source files in the putty/ > subtree, thus more compilation units will use the new instructions that > are not necessarily ready for it (i.e. have extensive checking logic > upfront). It's not entirely surprising that the compiler then finds more > efficient ways to do operations using the new instructions, which will > then fail execution with invalid opcode. > > I'm with Andrey that the bug should be reopened and RC'ed because this > is effectively producing a miscompilation on i386. > > Kind regards > Philipp Kern > > [1] > https://sources.debian.org/src/putty/0.81-2/crypto/CMakeLists.txt/?hl=88#L130 > (it checks for the capability and then adds a specific library just for > that source file if successful) Hi, Reopening it and looking at it again is the way forward. I hope in conjunction with upstream where necessary this can resolved. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Debian Developers needed for mentors sponsorship - 2024-07-28
Hi all DDs, As DebConf24 starts I am going to put in another request for DDs with some spare time to review and possibly upload to Debian packages that have been submitted to Debian Mentors and have passed sanity checking/tests. Please see list at below link. https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Aconfirmed;package=sponsorship-requests If you pick up a package, please look at the bottom of the page below to take ownership and mark as pending on bts. https://mentors.debian.net/sponsors/rfs-howto/ Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- signature.asc Description: This is a digitally signed message part
Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-08-15
Dear all DDs, Below is the link to the page of currently "confirmed" being in good order packages that are awaiting a DD review and possible upload. If DDs could spare the time to pick up a package or two and finish off the package mentor process it would be greatly appreciated. https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Aconfirmed;package=sponsorship-requests Please check that another DD is not already involved in the package. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Help me with publishing package
On Mon, 2024-08-26 at 12:19 -0700, Soren Stoutner wrote: > Вероника, > > Thanks for working on preparing a package for inclusion in Debian. The > information you are looking for is on: > > https://mentors.debian.net/ > > If you have any questions, feel free to ask on the Debian Mentors mailing > list: > > https://lists.debian.org/debian-mentors/ > > On Monday, August 26, 2024 4:38:11 AM MST Вероника Кабанкова wrote: > > I have this repo https://github.com/vo6i/termux-package.git and work pckg > > for Termux, how I can upload in Debian Distro Repository? > > Soren and all, This seems like a link to to nothing more than a webgl game. The eventual payload is below. #!/bin/bash pkg install toilet toilet Dclxviclan echo -e "\e31;1mMy first dclxviclan pkg play now for supporting https://simmer.io/@dclxviclan/idle"; Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-08-27
Dear all DDs, Below is the link to the page of currently "confirmed" being in good order packages that are awaiting a DD review and possible upload. If DDs could spare the time to pick up a package or two and finish off the package mentor process it would be greatly appreciated. https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Aconfirmed;package=sponsorship-requests Please check that another DD is not already involved in the package. P.S. I have have emailed some team lists, as we have packages in a variety of laguages and may interest DDs from these teams. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Debian Mentors - Confirmed package of the day - graphite-carbon - Needs love
Hi Debian Developers, Our package marked as "confirmed" that has languished on mentors for quite some time is our package of the day. Please could a DD with a little free time, graciously give it your time and show this package some love? Package: graphite-carbon Links... * Mentors - https://mentors.debian.net/package/graphite-carbon/ * RFS bug - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077619 * Salsa - https://salsa.debian.org/debian-graphite-team/graphite-carbon Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Is Mari Wang MIA?
I've got a new version of the package (7.82) just about ready for upload, give me a day or two But the most recent production version of ExifTool is 7.89 (Aug. 18). Why not package the most recent production release? - Phil -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Announcing LHCP - Linux Hardware Compatibility Project
Hello everyone.
We've recently started working on a project called Linux Hardware
Compatibility
Project or in short LHCP. Goals are:
* Provide a list of working hardware for people wanting to buy a new
computer
* Provide an idea on what hardware our/your distribution in run on
* Provide a list of hardware we need to improve support for
* Provide an interface to all above that allows simple and complicated
queries
* Get the user a list of thing that should work and a way to test that
* Tell the user how good his hardware is supported
There have been several Hardware Compatibility lists from vendors and
other projects in the past, but most of them were limited in one
aspect or another - so we start our own.
To achive this we are building a modular framework to generate, collect,
submit
and analyze information about all components of systems running Linux
and how well each component works.
The project is currently in it's infancy, but following the typical
pragmatic
approach of open source projects ("Release early, release often!") we've
decided to already officially announce it.
Current status is that the basic GUI application for testing is up and
running
with some test modules. We're now in the process of writing the first real
data collection and test modules and are currently starting to design the
server end of the side.
The home page of the project can be found here:
https://hosted.fedoraproject.org/projects/LHCP
If you want to take a look at the current source code you can checked it out
using Mercurial in read only mode like this:
hg clone http://hg.fedoraproject.org/hg/hosted/LHCP
For development discussions a mailing list has been set up here:
https://www.redhat.com/mailman/listinfo/lhcp-devel
Although the project is hosted under Fedora we're aiming it to be very
distribution independant, so supporting other distributions should be
easy to
do. We have some basic requirements on what is needed on the system for
it to
simply work, but a lot of things will be optional.
Happy hacking,
Read ya, Phil & Fabi
--
Philipp Knirsch | Tel.: +49-711-96437-470
Development | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <[EMAIL PROTECTED]>
Hauptstaetterstr. 58 | Web: http://www.redhat.de/
D-70178 Stuttgart
Motd: You're only jealous cos the little penguins are talking to me.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
remove
remove -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#594224: ITP: moria -- A roguelike game with an infinite dungeon
Package: wnpp Severity: wishlist Owner: Phil Brooke X-Debbugs-CC: debian-devel@lists.debian.org * Package name: moria Version : 5.6 Upstream Author : David Grabiner et al. * URL : http://www.asselstine.com/moria-5.6.tar.gz * License : GPLv3 Description : A roguelike game with an infinite dungeon Umoria is now available under the GPLv3. It was previously in the Debian archive (last version 5.5.2-5), but was eventually removed. I've exchanged emails with upstream and the former maintainer, and intend to package the new, free version. The description from the old Debian package contained: NOTE: despite the package name, this is actually UMORIA 5.5.2. A single player roguelike game with a regenerating dungeon, moria is the predecessor of angband with a full-screen, text-based, turn-based interface. It features scrolling maps, and an infinite (constantly regenerated) dungeon. Moria's dungeons are populated by monsters, some of which are inspired by J.R.R. Tolkien's books. The goal of the game is to find and kill the Balrog, whereupon the player is crowned King. Your player can be created from a combination of 8 races (human, half-elf, elf, halfling, gnome, dwarf, half-orc, half-troll) and 6 classes (warrior, mage, priest, rogue, ranger, paladin), and is measured by 6 attributes (strength, dexterity, intelligence, wisdom, constitution, and charisma). Cheers, Phil. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1008241707300.3...@emerald.lothlann.freeserve.co.uk
No list archives getting updated at all
It isn't just debian-boot; none of the lists I checked at random have been updated past that date and time. No responses have been logged in the audit trail either, which for an 'important' severity is disturbing. listarchives maintainers, hello? Can we get some kind of response, just to let us know that these bug messages are reaching you, not being dropped, not being ignored, not hung up in a mail gateway somewhere?
Re: Appropriate? mutt/mailx requires mail-transport-agent
>I'm working on a diskless workstation configuration where I don't want >mailers running on each machine, though users may have access to the >mail spool through nfs. Is it appropriate for apt-get to coerce exim >to be installed when I only need a reader? Is this a problem about >finding the smtp agent? What do mailx and mutt do if you try to send mail and no MTA is installed? Unless they handle this situation gracefully, which doesn't seem all that likely, this dependency is correct. p.
Re: Debbugs and ACK messages
I'm no longer on this list, but was looking over the web archives. Anyhow, just FYI: the GCC folks have had to block [EMAIL PROTECTED] from sending to the GCC bug-reporting addresses because of this auto-ack problem. What apparently has been happening is that a Debian developer will forward a gcc bug to GNATS, but include the [EMAIL PROTECTED] address, then when the gcc people make a change, gnats generates an email, which goes to debbugs, which responds with "information FILED blah blah blah," which goes to gnats, which generates an email... Lather, rinse, repeat. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen.- Samuel Adams -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#143319: ITP: topal -- Links Pine and GnuPG together.
Package: wnpp Version: N/A; reported 2002-04-17 Severity: wishlist * Package name: topal Version : 0.6.4 Upstream Author : Phil Brooke <[EMAIL PROTECTED]> * URL : http://www.lothlann.freeserve.co.uk/pjb/topal/ * License : GPL Description : Links Pine and GnuPG together. Topal is yet another program that links GnuPG and Pine. It offers facilities to encrypt, decrypt, sign, and verify messages. Multiple PGP blocks included in the text of a message are processed. Decryption and verification output can be cached to reduce the number of times the passphrase is entered. RFC2015 multipart messages can be sent and received with help from some scripts, procmail, and a patch to Pine. There is a high level of configurability. I'm the upstream author I've put an initial packaging of it together: it should be at http://people.debian.org/~pjb/topal/ in case anyone wants to see what's going on with it. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux catbert 2.2.17 #1 Sun Jun 25 09:24:41 EST 2000 i586 Locale: LANG=C, LC_CTYPE=C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#728400: ITP: ripmime -- extract attachments out of MIME encoded emails
Package: wnpp Severity: wishlist Owner: Phil Brooke X-Debbugs-Cc: debian-devel@lists.debian.org Package name: ripmime Version : 1.4.0 Upstream Author : Paul L Daniels * URL : http://www.pldaniels.com/ripmime/ * License : BSD 3-Clause License Description : Extract attachments out of MIME encoded emails ripMIME's primary pupose is to extract attachments out of a MIME encoded email packages. -- Phil Brooke OpenPGP key: 1024D/50973B91 2000-12-19 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1310311830360.8880.lcdyyxfr%...@debian.org
Proposed removal of yiff
Hi, I plan to ask for the removal of the yiff sound package from Debian late next week. - It no longer appears to have any upstream maintainer. - The only package that depends on yiff is roaraudio, and I think that's only as a minor plugin. (I'm cc'ing the maintainers of roaraudio.) Please email if you object. Thanks, Phil. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1202241258480.27957.lidkzlzt%...@debian.org
Re: Bug#656858: libimage-exiftool-perl: new upstream version available
About 10 days ago I sent an email to m...@qu.debian.org requesting that this package be orphaned. They suggested that I email the sponsor/co-maintainer, Petter Reinholdtsen, which I did, but I have so far had no response from him either. - Phil -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98576e6d-5420-42ec-94bb-8936d5ca5...@owl.phy.queensu.ca
Re: salsa.debian.org: merge requests and such
On Sat, Nov 10, 2018 at 10:36:53AM -0200, Herbert Fortes wrote: > On 09/11/2018 20:26, Colin Watson wrote: > > I guessed that the particular commit was > > https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f. > > (The same developer has also been doing a number of other minor cleanups > > in many other packages along the same lines.) > > The fix is good. > > But why the new debian/changelog? It is a honest question. It's just an alternative personal style. Some people like to hand curate the changelog in a standalone commit, especially if not every commit is worth mentioning, or the version number needs changing. Other people want there to be some record of work in progress, showing up on e.g. tracker.debian.org or qa. signature.asc Description: PGP signature
Re: Bug#926076: goxkcdpwgen -- xkcd style password generator library and cli tool
On Sun, Mar 31, 2019 at 05:27:03PM +0530, Dhanya Thailappan wrote: > * Package name: goxkcdpwgen > Version : 0.0~git20181107.de898c7-1 > Upstream Author : Martin Hoefling > * URL : https://github.com/martinhoefling/goxkcdpwgen > * License : MIT > Programming Lang: Go > Description : xkcd style password generator library and cli tool Hello, How does this compare to the diceware package? Even the available parameters are very similar. Perhaps you could consider submitting the de_wordlist.txt to the diceware project? https://tracker.debian.org/pkg/diceware https://github.com/ulif/diceware#usage -- Phil Morrell signature.asc Description: PGP signature
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 07, 2019 at 07:01:28PM +0200, Alf Gaida wrote: > For debian it could work the same way - just host the debian dir and be done > with. Iirc the kde team work this way, they have only the debian dir in > salsa. With a modified watch file it should be possible to get any source > one want to. So the "only" thing needed is the infrastructure to host and > maintain these repos. The rest is up to the user and a fundamental different > approach as launchpad and ppa's. I like it, and just wanted to share this related idea from the Gentoo world about bootstrapping some automated trust without increasing contribution friction too much: https://dev.gentoo.org/~mgorny/articles/guru-a-new-model-of-contributing-to-gentoo.html#user-access-and-workflow -- Phil Morrell signature.asc Description: PGP signature
Re: duprkit User Repository
On Mon, Apr 08, 2019 at 05:00:21AM +, Mo Zhou wrote:
> Plus, it's super important to write every packaging bit into a single
> file. That would enable simple copy&pasting from github or any other
> resources. If you provide a directory, things will become more
> complicated. More impotantly, the proposed single file specification
> virtually adds NO overhead.
Obviously working implementation > perfect theoretical, but I'm confused
by your insistence on a single file without abstraction. Even an
uncompressed tarball can be cat'ed to read the contents, without
requiring a custom format. With a custom format, why not hide
implementation details like source format in "unfold"?
For the DefaultCollection example, don't we have a standardised download
tool in debian/watch? Similarly, the build script is essentially a
debian/rules in its construction. Could you get by with a `cat
debian/{watch,control,rules}`?
--
Phil Morrell
signature.asc
Description: PGP signature
Re: Challenge from Julia's non-standard vendored openblas"64_"
On Sun, Jul 28, 2019 at 02:30:15AM -0700, Mo Zhou wrote: > problem is that the 64-bit indexing variant doesn't > have a standard SONAME. Without knowing anything more than what you've written here (which I didn't find too long), it sounds like maintenance burden is the concern. Am I right in thinking that there still exists non-Julia software for which your solution is cleaner than symbol mangling? Is that LAPACK? > long time ago, we (mainly BLAS/LAPACK maintainers) > decided to use the "SONAME=libXXX64.so" convention > without mangling symbol names. Mangling is not > considered because only openblas supports it. What you would do today if you were packaging it from scratch? If you would pick the Julia approach for ease of maintenance then a SONAME transition seems "simple" enough. If you would implement the cleaner no-mangling approach, then a libopenblas-julia compatibility dependency (option 2) would isolate the problem to the julia ecosystem. > their vendored OpenBLAS to "libopenblas64_.so.*", Ugh, vendoring "compiles for me, so it's your problem". > I have no confidence at all to convince > upstream to change their widely-spread practice. Even when that's the case, it's usually still worth reporting the issue upstream, so they know the pain they're introducing to potential users. All the best from an outsider, and thank you for tackling difficult interoperability decisions in Debian. -- Phil Morrell (emorrp1) signature.asc Description: PGP signature
Re: anti-tarball clause and GPL
(debian-devel following Holger's advice, guessing all authors are subscribed) On Thu, Jul 25, 2019 at 10:43:12PM -0300, Yao Wei (魏銘廷) wrote: > What if, one of the upstream authors consider it violating GPL _without_ the > clause? I mean, it could happen. Indeed, and I'd argue this is already the case (implicitly). Consider a security bug reported in Buster, missing from Stretch, that when a fix is found needs to be backported to all upstream supported releases (say, for example, going all the way back to one released just after Stretch). Other than skimming release notes for the affecting change, what would a diligent upstream do to determine which release streams need patching? Would they do a git checkout of each tag, manually testing, but otherwise merely using git as the tarball distribution mechanism? Or would they do a git log on the fixed file to determine when the change was first introduced, then simply git tag --contains? Even better, if the fix is not even known yet, could they `git bisect run foo` to find the breaking commit, then use that knowledge to work out the fix? On Thu, 25 Jul 2019 at 17:40, Adam Borowski wrote: > On Wed, Jul 24, 2019 at 05:18:28AM +, Scott Kitterman wrote: > > On July 24, 2019 12:34:13 AM UTC, Adam Borowski wrote: > > >By this logic, a pile of .c files with comments removed or preprocessed > > >with cpp would be allowed as well. The VCS is also a means to store > > >human-readable comments. > > I infer from this you think projects without a public VCS (postfix is an > > example) belong in non-free? > > At this moment, not yet. Obviously, old projects didn't even _have_ a VCS, > and I'm not proposing imposing a VCS workflow on the upstream. I'd like to > consider, at some point in the future, hidden private VCSes where the upstream > occassionally releases a tarball of to be non-free, just like the same PNG Yes, yes, yes - if upstream would prefer to modify their source with the support that their private git repo provides, then publishing just the make dist tarball does not make sense. The repo doesn't have to publicly-writable or accept pull requests, perhaps even doesn't need to have the entire project history (shallow clone since last release?). On Fri, Jul 26, 2019 at 04:00:04AM +0900, Norbert Preining wrote: > On Wed, 24 Jul 2019, Yao Wei wrote: > > I believe that "flat" tarball in Adam's question means tarball stripping > > out VCS information, not tarball as a format. > > Just one hint, if this comes in I will upload texlive with about a > 70Gb tarball as source ... we have 15 years of history of "flat tarball > of 4Gb". > > I don't think that *this* is the preferred form of changes. Then why do *you* use it to make changes? This would also be a good opportunity to improve Debian's 9G+ support (also for game assets). For the record, the texlive .git is 28G and as mentioned, we could consider the replacement for .orig. to be a shallow bare clone since last upload (git-debpush wishlist?). signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote: > I think STS (Short term support) will fit nicely with LTS. If there is > no serious objections, I'd go with this. As debconf is finishing, though I don't know if either of you attended this year, has there been any progress on this idea? Is there an evergreen/sts/fasttrack destination I can put in my dput.cf to support normally unsuitable packages like jenkins/virtualbox/firefox/gitlab? signature.asc Description: PGP signature
Bug#1061649: ITP: vdr-plugin-wirbelscan -- This plugin performs channel scans for digital tv cards
Package: wnpp Severity: wishlist Owner: Phil Wyett X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: vdr-plugin-wirbelscan Version : 2023.10.15 Upstream Author : Winfried Koehler * URL : https://github.com/wirbel-at-vdr-portal/wirbelscan-dev * License : GPL-2 Programming Lang: C++ Description : This plugin performs channel scans for digital tv cards. Notes: * Goal is to take over from embedded wirbelscan code currently in some Debian packages. * Description will need some tuning. * Package will need a sponsor if my DD/with upload process is not completed. Regards Phil -- Playing the game for the games sake. Web: * Debian Wiki: https://wiki.debian.org/PhilWyett * Website: https://kathenas.org * Social Debian: https://pleroma.debian.social/kathenas/ * Social Instagram: https://www.instagram.com/kathenasorg/ signature.asc Description: This is a digitally signed message part
Re: New requirements for APT repository signing
On Wed, 2024-02-28 at 20:20 +0100, Julian Andres Klode wrote: > APT 2.7.13 just landed in unstable and with GnuPG 2.4.5 installed, > or 2.4.4 with a backport from the 2.4 branch, requires repositories > to be signed using one of > > - RSA keys of at least 2048 bit > - Ed25519 > - Ed448 > > Any other keys will cause warnings. These warnings will become > errors in March as we harden it up for the Ubuntu 24.04 release, > which was the main driver to do the change *now*. > > If you operate third-party repositories using different key > algorithms, now is your time to migrate before you get hit > with an error. > > For the Ubuntu perspective, feel free to check out the discourse > post: > > https://discourse.ubuntu.com/t/new-requirements-for-apt-repository-signing-in-24-04/42854 Hi, Could I be pointed to the public conversation, any plans or bug reports related to this update and transition etc. for affected users? Thanks. Regards Phil -- Playing the game for the games sake. Web: * Debian Wiki: https://wiki.debian.org/PhilWyett * Website: https://kathenas.org * Social Debian: https://pleroma.debian.social/kathenas/ * Social Instagram: https://www.instagram.com/kathenasorg/ signature.asc Description: This is a digitally signed message part
Re: NEW queue almost empty
On Mon, Nov 02, 2020 at 10:56:57PM +0100, Joerg Jaspert wrote: > On 15940 March 1977, Christian Kastner wrote: > > > The NEW queue length is down a single digit, from ~500 not all too long > > ago. That's an amazing effort by ftp-master that must have consumed a > > *lot* of energy. > > It consumed quite a batch of my poor jelly beans. :) Package: ftp.debian.org Severity: important Summary: NEW queue graphs not updating since 21:00 UTC thanks /s There can never be too much of a good thing, so I just wanted to hand out another thank you to the FTP masters (and this year's trainees) for continued work on the NEW queue. Keeping on top of the tens of unblocked packages daily and managing to hit 0 is a great achievement. I don't envy you the next four months, but thank you in advance for bullseye and I hope this helps prevent any inappropriate abusive emails previously reported on or at least raise the ratio of appreciation. -- Phil Morrell signature.asc Description: PGP signature
Re: Package broke in stable due to old API. Fix in stable or backports?
On Sun, Jan 10, 2021 at 12:15:22AM +0800, Yao Wei wrote: > There should be many existing cases, that external service the stable > package is using deprecates the old API, which in turn breaks the > package. Do we have documented conventions that where the fixed package > should be uploaded to: stable-proposed-updates or backports? Yes, absolutely stable updates, as documented in both the dev-ref and backports site. https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable > Backports are about additional features that are only offered in a new > version, not a replacement for getting fixes into stable - use stable-updates > for that. https://backports.debian.org/Contribute/#index1h3 signature.asc Description: PGP signature
Re: devscripts: wrap-and-sort should default to -ast
On Tue, Feb 09, 2021 at 08:49:51PM +0100, Thomas Goirand wrote: > On 2/9/21 7:40 PM, Russ Allbery wrote: > > Jonas Smedegaard writes: > >> Let's see if Debian can agree on a single normalization of 822-ish > >> files. For starters, I disagree that "wrap-and-sort -a" is a suitable > >> normalization, as that will involve re-indentation when keys change. > > > > I've been using wrap-and-sort -ast on all of my packages for a while, with > > much the same justification. > > For packages generating a lot of binaries, the -b option is also quite > useful, don't you think? As a user of -satb, I'd like to point out that the flags are not all equal. Two of them support a (more objective?) desire that "addition to a list in line-based VCS should have no deletions". That is -at, whereas -s is a subjective prettifier and -b could remove information, hence -k. To make that work as a default, there would need to be something like an --short-preferred-unless-existing-indent to prevent constant reformatting. I disagree with jonas on the importance of -s because I'm not convinced that field names change, especially not often. signature.asc Description: PGP signature
Re: devscripts: wrap-and-sort should default to -ast
On Wed, Feb 10, 2021 at 11:47:12AM +, Phil Morrell wrote: > To make that work as a default, there would need to be something like an > --short-preferred-unless-existing-indent sorry, going by the current default, that should be --align-preferred-unless-existing-short signature.asc Description: PGP signature
Re: libgcc-s1 buster -> bullseye upgrade issues
On Sun, Feb 14, 2021 at 04:58:35PM +, Simon McVittie wrote: > On Sat, 13 Feb 2021 at 19:52:10 +0100, Paul Gevers wrote: > > [The release team are] pretty concerned about a couple of known RC bugs > > which need the proper attention of people familiar with upgrade paths > > as there's potential to leave upgrading systems unbootable and/or > > without a working apt. > ... > > https://bugs.debian.org/972936 / libgcc-s1 > > I wanted to provide some signal boost for this and related upgrade issues. > Ryan Pavlik, one of my colleagues at Collabora, ran into a similar upgrade > failure involving libgcc-s1 and has made a self-contained reproducer > for it: <https://salsa.debian.org/rpavlik/gcc-upgrade-testcase>. Hi Simon, That testcase is two months old, I take it you missed my update yesterday to both bugs after the bits email failing to reproduce it with current buster/bullseye. I have just re-run the upgrade with the addition of libreoffice installed and it completed without issue. I didn't close/downgrade the bug in case I was missing something, so please can you re-test your upgrade and confirm it's fixed? -- Phil Morrell (emorrp1) ``` # apt full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: ant-contrib libboost-atomic1.67.0 libboost-chrono1.67.0 libboost-date-time1.67.0 libboost-filesystem1.67.0 libboost-iostreams1.67.0 libboost-locale1.67.0 libboost-system1.67.0 libboost-thread1.67.0 libcodec2-0.8.1 libcroco3 libcrystalhd3 libdbus-glib-1-2 libdc1394-22 libdvdread4 libfluidsynth1 libgail-common libgail18 libgdk-pixbuf-xlib-2.0-0 libgdk-pixbuf2.0-0 libgssdp-1.0-3 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libgupnp-1.0-4 libicu63 libidn11 libigdgmm5 libilmbase23 libip4tc0 libjson-c3 libllvm7 libmpdec2 libopenexr23 liborcus-0.14-0 libpoppler82 libpython3.7 libpython3.7-minimal libpython3.7-stdlib libreadline7 libreoffice-avmedia-backend-gstreamer libvpx5 libx264-155 libx265-165 python3.7-minimal Use 'apt autoremove' to remove them. The following packages will be REMOVED: g++-8 gcc-8 libgcc-8-dev libreoffice-style-tango libstdc++-8-dev python3.7 uno-libs3 The following NEW packages will be installed: alsa-topology-conf alsa-ucm-conf bsdextrautils cpp-10 fonts-noto-extra g++-10 gcc-10 gcc-10-base gcc-9-base gstreamer1.0-libav gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly gstreamer1.0-x liba52-0.7.4 libaa1 libaacs0 libapt-pkg6.0 libasan6 libavc1394-0 libavfilter7 libavformat58 libbdplus0 libbluray2 libboost-filesystem1.74.0 libboost-iostreams1.74.0 libboost-locale1.74.0 libboost-thread1.74.0 libbrotli1 libc-devtools libcaca0 libcdio19 libclone-perl libcodec2-0.9 libcrypt-dev libcrypt1 libctf-nobfd0 libctf0 libdav1d4 libdc1394-25 libdeflate0 libdv4 libdvdread8 libdw1 libffi7 libfluidsynth2 libgcc-10-dev libgcc-s1 libgd3 libgdk-pixbuf-2.0-0 libgdk-pixbuf-xlib-2.0-0 libgssdp-1.2-0 libgupnp-1.2-0 libhogweed6 libicu67 libiec61883-0 libigdgmm11 libilmbase25 libinstpatch-1.0-2 libip4tc2 libisl23 libjson-c5 libjuh-java libjurt-java liblibreoffice-java libllvm11 libltc11 liblua5.3-0 libmariadb3 libmd0 libmfx1 libmpdec3 libmpeg2-4 libmysofa1 libnettle8 libnorm1 libnsl-dev libnsl2 libnss-nis libnss-nisplus libopencore-amrnb0 libopencore-amrwb0 libopenexr25 libopenni2-0 liborcus-0.16-0 liborcus-parser-0.16-0 libpcre2-8-0 libperl5.32 libpgm-5.3-0 libpocketsphinx3 libpoppler102 libpostproc55 libpython3.9 libpython3.9-minimal libpython3.9-stdlib libqrcodegencpp1 librabbitmq4 libreadline8 libreoffice-sdbc-mysql libridl-java librubberband2 libsdl2-2.0-0 libshout3 libsidplay1v5 libslang2 libsodium23 libsphinxbase3 libsrt1.4-gnutls libssh-gcrypt-4 libstdc++-10-dev libswscale5 libtag1v5 libtag1v5-vanilla libtirpc-common libtirpc-dev libtirpc3 libudfread0 libuno-cppu3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3 libunoil-java libunoloader-java libunwind8 libvidstab1.1 libvpx6 libvte-2.91-0 libvte-2.91-common libx264-160 libx265-192 libxcb-randr0 libxkbfile1 libxss1 libxxhash0 libz3-4 libzmq5 logsave mailcap manpages manpages-dev mariadb-common media-types mesa-vulkan-drivers mysql-common ocl-icd-libopencl1 perl-modules-5.32 pocketsphinx-en-us python3.9 python3.9-minimal systemd-timesyncd termit timgm6mb-soundfont uno-libs-private The following packages will be upgraded: adwaita-icon-theme ant ant-contrib ant-optional apparmor apt at-spi2-core base-files base-passwd bash binutils binutils-common binutils-x86-64-linux-gnu bsdutils build-essential bzip2 ca-certificates ca-certificates-java coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5 coinor-libcoinutils3v5 coinor-libosi1v5 coreutils cpp dash dbus dbus-user-session dconf-gsettings-backend dconf
Re: Changed Github download URLs are affecting lots of existing watch files
On Fri, Mar 26, 2021 at 11:43:27PM +0100, Yadd wrote: > Le 26/03/2021 à 22:38, Andreas Tille a écrit : > > I just learned that what was formerly something like > > > > .*/archive/ > > > > became now > > > > .*/archive/refs/tags/ > > > > This breaks at least all Debian Med packages refereing to Github and > > probably way more. This means our toolset will fail to detect new > > upstream versions. FWIW, the github snippet in man uscan recommends `(?:.*?/)` which I can confirm has not broken with this update. > > Any idea what to do (besides uploading all packages obtained from > > Github right after the release)? You could make a lintian-brush filter to make Janitor prepare the change for you on next upload. In the meantime, I don't think there's a better way of tracking changes than to take a copy of all the affected watch files and uscan them locally/in CI. Watch files, homepage urls, signing keys are all just metadata that can occasionally change. > We could perhaps handle that with uscan then each time GitHub changes > its website, only uscan should be updated. > > IDEA 1: create a uscan macro > IDEA 2: create a uscan option: Sounds like you're asking for a new github redirector on qa.debian.org as there is for sf.net, which could use the official api for stability. signature.asc Description: PGP signature
Re: Who to contact about removing package from upcoming 11 release?
On Mon, May 03, 2021 at 11:18:04AM -0300, Kurt Fitzner wrote: > When the maintainers are unresponsive, I'm not sure the escalation process. > > - #926253 /usr/share/postfixadmin/lib/../templates_c does not exist on new > installation (Since Debian 9) > > The concern I have with this remaining in testing and then Debian 11 is > primarily #926253. Since about 2018, upstream's postfixadmin has required a > writeable tmp directory called templates_c. This is not created by the > installer and the application fails without it. Taking this entirely at face value, the escalation is quite straight forward. If you can confirm the issue "renders package unusable" on a fresh install of testing, then use `reportbug` to update #926253 to "grave" severity for version 3.3.5-1. https://www.debian.org/Bugs/Developer#severities > renders the package unusable, or mostly so, on all or nearly all > possible systems on which it could be installed (i.e., not a > hardware-specific bug); or renders package uninstallable or > unremovable without special effort If not, or if they disagree, then it's up to the maintainer's discretion. Please note that the currently listed Maintainer hasn't made an upload since 2014, and the Uploader explicitly requested in 2018 that someone else adopt it as "I can't test the package thoroughly". https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897683
Re: please document why a package has been dropped from Testing/Bullseye
On Mon, May 10, 2021 at 06:23:34AM -0500, Michael Lustfield wrote: > On Sun, 9 May 2021 07:30:04 +0200 > Harald Dunkel wrote: > > > > https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so I > > wonder > > what is the recommended way to find out why rsnapshot (or any other package) > > has been dropped from Testing? > > I was wondering what the easiest and most sensible way would be to find/share > this information. My first thought was feeding something like > 'aptitude search ~o' into a script that checks for RM bugs in the bug tracker. > It seems like it would be an easy enough trigger to write, but it would be > time-consuming to run and would add a fair bit of load to the bug tracker. Hi Michael, it sounds like you would be interested in installing the how-can-i-help package, where you can run queries pre-filtered to the list of packages you have locally installed. how-can-i-help --old --show no-testing,testing-autorm signature.asc Description: PGP signature
Bug#992196: ITP: opensmalltalk-vm -- High performance virtual machine for Smalltalk
Apparently something went wrong with the bug report and this wasn't sent to the list... -- Forwarded message - From: Phil Bellalouna https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sugar-devel>> Date: Sun, Aug 15, 2021 at 12:32 PM Subject: ITP: opensmalltalk-vm -- High performance virtual machine for Smalltalk To: Debian Bug Tracking System https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sugar-devel>> Package: wnpp Severity: wishlist Owner: Phil Bellalouna https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sugar-devel>> X-Debbugs-Cc: debian-devel at lists.debian.org <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sugar-devel>,pkg-sugar-devel at lists.alioth.debian.org <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sugar-devel> * Package name: opensmalltalk-vm Version : 1.0 Upstream Author : squeak.org * URL : https://github.com/OpenSmalltalk/opensmalltalk-vm * License : MIT Programming Lang: Smalltalk, C Description : High performance virtual machine for Smalltalk (this is part of the Squeak project https://squeak.org) Squeak is a full-featured implementation of the Smalltalk programming language and environment based on (and largely compatible with) the original Smalltalk-80 system. This package contains just the Unix Squeak opensmalltalk virtual machine, a modern implementation with significantly enhanced performance. You will likely need also an image file containing a "snapshot" of a live Squeak session - e.g. from the Squeak, Pharo or Cuis projects. -- This package is needed to provide Debian with a modern, high performance implementation of the Squeak VM. Recent Smalltalk images provided by Squeak and related dialects require this VM in order to run. A few key points: - It complements the existing squeak-vm package[1]. - One of the key differences between the implementations is that squeak-vm is a pure bytecode interpreter while opensmalltalk-vm includes a high performance JIT implementation for x86 and ARM. - There are some shared resources between opensmalltalk-vm and squeak-vm. As a result, at least two supporting packages (a common package and a metapackage) are also proposed. - We are prepared to upstream at least the majority of changes needed to satisfy Debian packaging requirements. I am a long-time Smalltalk developer and have been working with the Squeak project to produce at least the initial package for this VM. The Squeak project is open to whatever arrangement Debian maintainers feel is appropriate (i.e. it's unclear at this time if the Sugar team would be interested in taking on maintenance of the package, if I would continue to do so etc... this is open for discussion) for the ongoing maintenance of the package(s). I am looking for a sponsor. Obviously, I need someone to help me get the package uploaded. I could also use some packaging advice, given the non-trivial nature of this package. I am a long-term Debian user and believe we are addressing the key issues related to Debian packaging, but would appreciate another set of eyes to confirm. [1] squeak-vm is the 'classic' VM, whose code is also maintained by the Squeak project. It is still required by legacy applications such as Scratch and Etoys, so the plan is for both VMs to co-exist.
Re: Q: Use https for {deb,security}.debian.org by default
On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote: > On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote: > > Yes transparent proxies or overridden DNS lookups could be used to > > direct deb.debian.org and security.debian.org to your alternative > > location, > > I've been thinking for a while that we should bake a feature in apt > whereby a network administrator can indicate somehow that there is a > local apt mirror and that apt should use that one in preference to > deb.debian.org. This already exists in the form of an avahi service announcement for _apt_proxy._tcp, issued by both squid-deb-proxy and apt-cacher-ng. Literally the only thing needed client-side is installation of squid-deb-proxy-client, which is also available in udeb form implying that d-i already uses it. > This could be useful for both the "I've got a slow uplink and would like > it to not be overwhelmed at the BSP I'm hosting for my Debian friends" > type as well as the "I'm an ISP and I want to provide a mirror to Debian > users so we can reduce our uplink connection a bit" type of situations. It's a great solution for everyone on the same wifi network, if everyone has squid-deb-proxy-client installed then just one person can spawn a proxy and suddenly everyone's caching through them. > However, I've not been able to come up with a scheme which is simple > enough to be doable on a LAN while at the same time be usable by larger > network providers, *and* which can't also be abused by MitM attackers. Isn't the MitM handled by archive signatures etc., hence why http is fine? True I haven't tested this in a large network, since usually configuration management is in place, but apparently mDNS can even traverse routers via Multicast BGP. signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
On Tue, Aug 24, 2021 at 04:21:50PM -0700, Sean Whitton wrote: > On Wed 18 Aug 2021 at 10:10AM +02, Simon Josefsson wrote: > > Signing tarballs is the current > > established best practice -- moving to VCS builds needs a set of new > > schemes to be established and deployed, and I don't see any single > > universal solution today. > > From my point of view, signing git tags is no less well established a > best practice than signing tarballs -- in fact, to me, it seems *more* > well established. Maybe for upstreams the tooling is certainly easier for signed tags that are distributed with the git repo, rather than tarball signatures that have to be attached to a releases page after the fact. However, the debian tooling last I checked correctly passed on the upstream tarball signature intact to be available to the end-user (included in .dsc). uscan verifies signed tags only locally before throwing away the metadata - see also 3.0 (git) source format and tag2upload. It doesn't have to be full history clone, only IIRC the tag and its sole commit object from `git cat-file -p` to recreate them. signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
On Wed, Aug 25, 2021 at 04:35:51PM +0200, Simon Richter wrote: > > I wrote this many times, but I don't see why we should use any "upstream > > tarball" when the Git repository itself contains the tarball with: > > > git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ > > | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz > > "git archive" is reproducible, for simplicity I wouldn't use a prefix > though. For simplicity I *would* use a prefix, purely because that's what github/gitlab uses, so upstream can still choose to additionally sign the distributed tarball if they wish. name=CorsixTH-0.61-beta1 # don't ask me why there's no v, it's just what GitHub does git archive --prefix=$name/ -o ../$name.tar.gz v0.61-beta1 gpg --armor --detach-sign ../$name.tar.gz https://github.com/CorsixTH/CorsixTH/issues/1271#issuecomment-344882419 signature.asc Description: PGP signature
next steps after usrunmess
On Thu, Aug 26, 2021 at 02:56:21AM +0200, Guillem Jover wrote: > On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote: > > Afaict we have still no idea on how to move on. > > > > 1 I think you agree that there is a significant number of usrmerged Debian > > installations out there. > > My wish would be to indeed salvage those systems, > that's why I implemented dpkg-fsys-usrunmess. > > > 2 As you have stated there are known issues with dpkg and usrmerged > > systems. Some of them are are triggered by moving files from / to /usr. > > Well, in my mind the first and most immediate action that would be > done, is to stop the bleeding, by: > > - reverting the changes in deboostrap in sid, bullseye (and ideally > in buster too), > - reverting the notion that split-/usr is unsupported (which includes > the extremely confusing interpretation about this applying to > sid/testing too), and update documentation such as release-notes, This bullet point response confuses me - and then what? If I understand your position correctly, you don't want merged-/usr as an end-goal and you disagree with usrmerge transition as a hack. In order to achieve the result above without bypassing Debian processes, the formal method would to pass a GR overriding the tech-ctte minority. Is the only reason you haven't proposed that as a GR that you've already sunk too much energy into this? Or that you don't trust that process? Lets say you get your wish: to achieve technical excellence the Project backs your position and recommends running usrunmess to ensure everyone's systems are back to split-/usr for Debian 12. However, hypothetically, and against your better judgement, the Project still wants the end-goal to be merged-/usr. It seems to me that most commentators are deferring to your knowledge of dpkg internals. Whether you call it a feature request or a long-standing bug, what patchset would you be willing to merge into dpkg to support the new layout? This is a similar scenario to Russ' parallel email: On Wed, Aug 25, 2021 at 01:23:19PM -0700, Russ Allbery wrote: > I do not believe it will be possible at this point to > convince the project as a whole to unwind usrmerge and go back to doing > individual package migrations. > > Given that as a design constraint (we will not be doing this transition > via one-by-one changes to each package), what would you support as a good > architectural solution to this transition? What is the technically excellent thing everyone else should be working on, that you will support in dpkg despite personally disagreeing with the end-goal of merged-/usr? Presumably this feature could also be implemented in time for Debian 12. Would it then be possible to make everyone's systems merged-/usr upon release of Debian 13, in 2025? I'm sorry, you won't know me from adam, so I hope you don't interpret this as pro-merged-/usr, but as a chance to explain how you getting your way doesn't stand in the way of what others consider timely progress. signature.asc Description: PGP signature
Re: next steps after usrunmess
On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote: > Le ven. 27 août 2021 à 17:20, Theodore Ts'o a écrit : > > On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote: > > > > - reverting the changes in deboostrap in sid, bullseye (and ideally > > > > in buster too), > > > > - reverting the notion that split-/usr is unsupported (which includes > > > > the extremely confusing interpretation about this applying to > > > > sid/testing too), and update documentation such as release-notes, > > > > > > This bullet point response confuses me - and then what? > > > > > > If I understand your position correctly, you don't want merged-/usr as > > > an end-goal and you disagree with usrmerge transition as a hack. In > > > order to achieve the result above without bypassing Debian processes, > > > the formal method would to pass a GR overriding the tech-ctte minority. > > > > But the question remains --- how do we as a community move forward? > > Debian is made up of volunteers, so we can't *force* the dpkg > > developers to do anything they don't want to do. So what then? > > > > Does someone need to create patches to dpkg which attempt to teach it > > that /bin/foo and /usr/bin/foo are the same file, if there exists a > > symlink from /bin to usr/bin? > > > > So I repeat the question to the entire community --- what is to be > > done? How do we move forward? > > See the proposal here of guillem: > https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking Hi Bastien, it's hard for me to see as an outsider to dpkg how that proposal specifically addresses merged-/usr. It seems to be trying to solve a much, much more generalised problem of which merged-/usr is just a part. Is there no way to achieve the goal of making the dpkg database correspond with reality without that complexity? Secondly, assuming that this mechanism is needed, then according to that wiki page it appears to be almost complete? Can you confirm that the only thing needed to support merged-/usr as an option is these two remaining blockers? > [ ] (blocker) dpkg database access (.list and .md5sums) > * reportbug (no interface to map a db pathname to a pkgname) > [ ] (blocker) We cannot install .mtree files under /var/lib/dpkg/info/ > because old or new .debs could have shipped those, and these might be > invalid, or not match the contents. In general it seems like a bad > idea to store the files handled and generated by dpkg itself, with > files coming straight from the .debs. We need to separate them into > different directories. Perhaps /var/lib/dpkg/info/. > and /var/lib/dpkg/meta/. or similar. signature.asc Description: PGP signature
Finding rough consensus on level of vendoring for large upstreams
Over this last year there seems to have been a noticeable divergence of maintainer opinion, on what has become known as vendoring, from a strict reading of [policy 4.13]. I think it's notable that the heading is [Embedded] copies and was [Convenience] copies since its inception, thankfully I found a request to expand this section using [vendoring]. [policy 4.13]: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies [Embedded]: https://bugs.debian.org/955036 [Convenience]: https://bugs.debian.org/392362 [vendoring]: https://bugs.debian.org/907051 It is my reading of the situation that not only has this practice become more prevalent across multiple ecosystems since 2008, but that it can be a good thing when upstreams use it to better modularise their code. As a consequence, and in particular for large upstream projects, it is not a good use of maintainer time to package every single vendored library as a separate source package. See e.g. [kubernetes], [python BoF @25mins], [android-platform-tools], and even [uscan] grouping used by nodejs. [kubernetes]: https://bugs.debian.org/971515#172 [python BoF @25mins]: https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-97-python-team-bof.webm [android-platform-tools]: https://salsa.debian.org/android-tools-team/admin/-/issues/40 [uscan]: https://manpages.debian.org/uscan#grouped_package Is there any objection to the following summary? 1. If the reused code is small and intended to be embedded into a package, then this MUST be documented in the [security-tracker]. 2. If the included project has already been packaged, then the Debian version SHOULD be used instead. 3. If modifications have been made, then those changes SHOULD be forwarded and/or the package ported to the official version. 4. When 2 or 3 are too onerous to maintain, the package MAY use the convenience copy but MUST document why in README.source and SHOULD be included in the [security-tracker]. 5. Where only a small number of unrelated projects are bundled, they SHOULD be uploaded as separate source packages. 6. If the upstream authors are largely the same, then vendored sub-projects MAY simply be built together as the same source. 7. A large number of vendored dependencies used only together for a single Debian package MAY be grouped into a single source upload. 8. If 6 or 7 are used initially but a new package has some overlap, then the new package MUST NOT duplicate the vendoring. The duplication SHOULD be packaged separately, then the original package SHOULD be updated to use the Debian version instead. 9. When upstream has a proven track record of promptly handling security vulnerabilities inside their vendored dependencies, then maintainers SHOULD follow the same practice, updating versions in lockstep. I might be misusing the MUST/SHOULD/MAY, so those can be dropped as needed, but I tried to capture the accepted practice and deliberately used all the different historical terms. For comparison, there's also [Fedora] policy, but apart from not having an in-band "bundled", I also think that the line has ended up being drawn marginally differently. [security-tracker]: https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies [Fedora] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling signature.asc Description: PGP signature
Re: Finding rough consensus on level of vendoring for large upstreams
On Fri, Sep 03, 2021 at 01:03:35AM +0200, Jérémy Lal wrote: > - should a package debian/control list bundled dependencies to make > sure to avoid duplications ? Maybe? I noted in my final paragraph that Fedora has a mechanism for this that we don't, but perhaps Provides is sufficient. > - when a bundled package dependency is already available in debian, > and is the same (unpatched), should the upstream source tarball be > repacked without that dependency, or kept inside the source tarball ? I omitted this from the policy side, because it seems like this is already answered in ftp-master practice. Provided the vendored copy is not used during the build and unless there is a *different* reason for repacking with Files-Excluded, then I see no reason to remove it. -- emorrp1 signature.asc Description: PGP signature
Re: Finding rough consensus on level of vendoring for large upstreams
On Fri, Sep 03, 2021 at 02:46:20AM +0200, Jonas Smedegaard wrote: > First of all, thanks for compiling the list of reasonings. Thanks for taking the time to read through it, I was hoping it would be a useful observation. > I get the impression that you are framing current state of embedding as > a generally good thing to do, and if I understand that correctly then I > disagree with it. ish? I mostly tried to document current practice rather than have an opinion on it being good. I do think that the evidence of multiple independent maintainer teams coming to similar conclusions on the basis of lack of user benefit and drag on new version velocity indicates the positive side. I believe, based on only a day's investigation, that you are in the minority here. I don't mean that as a bad thing - 1/3 of DDs disagree(d) with offering non-free alongside main - but I'd like to hear why you think the maintainers I gave as examples should use their Debian time to unvendor everything? > I suspect that it helps if separating reasons for _encouraging_ > embedding (tiny upstream projects and deeply integrated sets of > upstreams, I guess) from reasons for _discouraging_ embdding (all other > cases, I guess). I think the expanded points I gave empower maintainers to make the best decision for their own packages. By laying out the permitted reasons clearly, it's implied other reasons are not valid, but there's probably something I haven't thought of. However #907051 also wanted more background on _why_ one might choose one way or the other, so please do elaborate on this if you can. > Quoting Phil Morrell (2021-09-03 00:38:35) > > 5. Where only a small number of unrelated projects are bundled, they > >SHOULD be uploaded as separate source packages. > > Concretely I think not I but ftpmaster objects to the above: Node.js > packages embed unrelated packages to meet ftpmaster requirement of a > minimum size source package. No, I think Node.js is covered by #7 (large number of deps). With #5 I was attempting to capture the current policy for when _not_ to bundle. Thanks for the additional background about why the bundling happens. -- emorrp1 signature.asc Description: PGP signature
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 05:18:13PM +0530, Anuradha Weeraman wrote: > As a result of a revert of v2020 of ksh last year, the current version > on sid for ksh is as follows: > > 2020.0.0+really93u+20120801-10 > > With the next upgrade, we're looking to move to the 93u+m community > maintained distribution that has a different versioning scheme (starting > with 1.0.0-beta.1). I was curious about why, and while I'm neither a ksh dev or user, in the context of Debian packaging it doesn't seem so simple. I'm trying not to step on your toes, or dredge up interpersonal conflict. https://github.com/att/ast/issues/1466 The impression I got is that there are at least 3 projects making claim to "ksh93" going forwards. 93u+2012 is the last known stable, compatible version that has been reverted to and, crucially, has been shipped in all Debian stable releases. There seems to be community demand and distro maintainers support for collaborating on keeping the build system working on modern systems, which will not be merged back into the att repo - do you know if this has happened, where the fork can be found? https://tracker.debian.org/pkg/ksh Then there appears to be this 93u+m project publishing essentially v2020 as 1.0.0 beta, tagged as 'v1.0.0-beta.1'. It's release notes say "This new fork is called ksh 93u+m as a permanent nod to its origin". It is making more invasive fixes to the codebase and trimming unused components, but there are some concerns noted over its backwards compatibility with 40 years of scripts. https://github.com/ksh93/ksh > However, I would like to request feedback to move to the following > version with a bump of the epoch: > > 1:93u+m-1.0.0~beta.1-1 1) If there are possible edge-case compatibility issues, have you considered a new source package and use of the alternatives system? This would let Debian users choose between the two options for their use case - maintaining existing systems, or writing new ksh scripts. 2) If you do go ahead with switching to the community distribution, then "93u+m" is part of the name, not the version number, so I'd suggest: 1:1.0.0~beta.1-1 signature.asc Description: PGP signature
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 07:37:55PM +0530, Anuradha Weeraman wrote: > ksh93u+m was a reboot attempt by Martijn Dekker et al. to build upon > the last stable 93u+ release (not on v2020, apart from some cherry > picked patches). This work has been taking place for over a year at this > point, with the objective of making incremental changes, by fixing long > standing issues, consolidating patches from RedHat, OpenSUSE, Solaris > etc, removing unused code, fixing the build system, and testing across > different UNIX variants. The distribution has come a long way, and the > upstream maintainers have been carefully curating fixes and maintaining > backwards compatibility. Ah I see, thanks for correcting my mistake about which project is which. That way round I completely agree there's no need to use alternatives and personally see no issue with bumping the epoch accordingly. signature.asc Description: PGP signature
Re: Finding rough consensus on level of vendoring for large upstreams
Thanks to Adrian and pabs for their corrections on documenting security support, and there wasn't too much objection to the summary, more to the sad state of affairs that leads to it and a bit of clarification. I believe all the major points have cc'd 907051, so would like to encourage someone more familiar with policy process than I am to draft an amendment. There should be enough written there now to expand the section accordingly with more recommendations, and possibly file wishlist bugs for maintainers to document their reasons in the source. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907051 signature.asc Description: PGP signature
task-laptop: please recommend automatic apt proxying
Package: task-laptop Version: 3.53 Severity: wishlist I'm not sure on the difference between auto-apt-proxy and squid-deb-proxy-client. Avahi is already pulled in by task-laptop. On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote: > On Wed, Sep 08, 2021 at 07:12:18PM -0400, Michael Stone wrote: > > Why not simply automate setting it at install time using preseed? I'm > > honestly not sure who the target audience for auto-apt-proxy is > > Laptops of end-user systems are the target, but also developers. When > people gather at a place (conference, hackspace, private meetup, etc.) > downloading of .debs should just work quickly by default. Many such > sites could easily provide a local cache and a number even do. BSPs tend > to have a blackboard with information including the local mirror to use. > Seriously, how many people change their mirror when they go to a BSP? If > we installed auto-apt-proxy by default, much of the local caching would > just work. -- System Information: Debian Release: 10.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable'), (100, 'buster-fasttrack'), (100, 'buster-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages task-laptop depends on: ii anacron 2.3-28 ii tasksel 3.53 Versions of packages task-laptop recommends: ii avahi-autoipd 0.7-4+deb10u1 ii bluetooth 5.50-1.2~deb10u2 ii iw 5.0.1-1 ii powertop2.8-1+b2 ii wireless-tools 30~pre9-13 ii wpasupplicant 2:2.7+git20190128+0c1e29f-6+deb10u3 task-laptop suggests no packages. -- no debconf information signature.asc Description: PGP signature
Re: Bundling
On Thu, Sep 30, 2021 at 10:24:01AM +0200, Alec Leamas wrote: > Just for the record: the issue about packaging wxWidgets 3.1 has already > been discussed with the maintainer: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919903 Hi Alec, I get the impression there that the maintainer is strongly indicating that they think it's not worth it, but that doesn't necessarily rule out being ok with you maintaining the experimental uploads. -- emorrp1 signature.asc Description: PGP signature
Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Mon, Jan 24, 2022 at 01:49:19PM -0500, Theodore Y. Ts'o wrote: > On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote: > > > > its surely an interesting topic how to avoid binary name changes and its > > also interesting to discuss ABI changes and workarounds. > > > > However, my point was that I want to know what policy ftpmaster applies > > to new binary names and to focus on this topic. > > As far as I know, ftpmaster requires a long, laborious review every > single time there is a new binary package released. As a result, it > strongly disincentivizes maintainers from packaging up new releases > because it's a pain in the posterior. > > Even if it isn't formal policy, the long delay has happened enough > times that I just assume it will be there, and it influences my > behavior accordingly. I like the earlier thread idea of de-coupling the copyright review (eventually of NEW entirely? but for now, just bin NEW) from "the other checks and balances". Ultimately, a mistake in debian/copyright *can* be just considered a bug with priority determined just like any other, so long as it is still legal for Debian to distribute. However, this is an issue whenever upstream ships a new source file, not when a new binary is added, so I hope that good maintainers do their due diligence on new upstream releases. If that is agreed informally, then while a lottery review would be a cool addition, it would not be a prerequisite to dropping its requirement for sources which have already been accepted into the archive once. This could be formalised via a GR empowering the FTP team. That last has made me wonder if the ftp-master team could split the NEW source queue into two phases, one where a copyright review is performed and one where the other checks are. I can see pros and cons for either way round these phases could be done, but one should feed into the other. Presumably, that this has not already happened means there would be little benefit because of context switching? signature.asc Description: PGP signature
Re: Back to the topic of changed binary named
On Tue, Jan 25, 2022 at 10:50:01AM +0100, Stephan Lachnit wrote: > On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille wrote: > > > > However, my point was that I want to know what policy ftpmaster applies > > to new binary names and to focus on this topic. I really want to know > > that policy of ftpmaster and I really would like to see that documented > > and I'm afraid that thread is drifting away from the original topic > > that I will not get any answer on this. > > > > So again: I see a conflict in my interpretation of the mail[1] (original > > posters again in CC) which suggests "an auto-approver" and what I'm > > currently observing and I would be really happy if we can document the > > policy for changed (and new) binary names of existing source packages. > > Since I feel my mail went lost in the discussion, here again my opinion: It's not been lost, there has been lots of discussion around the lottery idea C, but in changing the email subject I believe Andreas is trying to draw the distinction between the request to document *current* practice and your subthread about possible improvements to the overall process. signature.asc Description: PGP signature
Services offered by Debian should be dogfooding the real packages on DSA hosts.
On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote: > > As part of an upcoming survey that we are preparing, we plan to ask > Debian developers to rank, by order of importance, the most popular > ideas of improvements for Debian. > > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would be interesting to file them as new issues in > the "grow-your-ideas" project and then reply here pointing to your new > issue: I have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15 # The problem If I had a magic wand, I would like to resolve the situation around official instances of packaged servers being unable to dogfood their packaging work. I think this sends the wrong message as "If it's not good enough for Debian to use, why should I?". # Actual situation From what I've noticed in DebConf talks, it's explained by the fact the service maintainers do not have root access on DSA machines. This leads to either using upstream installation methods or deploying to non-DSA machines. It seems to me that this is either a solved problem, or can be made so, given it's similar to University provided computing resources. # Expected situation For (a simplified) example that I'm familiar with, matrix.debian.social should be as trivial as `apt install matrix-synapse` plus a config file. Going by the existing docs on apache vhosts and email, one possible interface would be: echo matrix-synapse >> /srv/foo.debian.org/packages/install vi /srv/foo.debian.org/packages/etc/matrix-synapse/conf.d/social.yaml sudo -u foo package-setup foo.debian.org The permitted packages and config paths could even be managed by a whitelist under the control of DSA to prevent a complete wildwest. The important thing is that a service owner can make (certain) direct changes without having to co-ordinate DSA approval. # Additional information I first wrote directly to debian-admin but that list isn't publicly archived, so I'll only paraphrase the response I got: * Installation + configuration can have a risk of privilege escalation * DSA might be happy with MRs to the puppet setup for the simple cases * There is no external testing on the current puppet code, holding back collaboration by non-DSA * There have been small experiments with containerisation (IMO, that's abandoning the strength of Debian's *integration*) signature.asc Description: PGP signature
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code TLDR: I think REUSE.software is a bad idea that is worse than what Debian already invented with Machine-readable debian/copyright file. I guess if upstream uses it, there's no reason not to ignore that as a source of copyright assertions. On Wed, Jan 26, 2022 at 12:49:34PM +0100, Stephan Lachnit wrote: > It is straightforward to > implement, add (e.g.) "SPDX-FileCopyrightText: 2019 Jane Doe > " and "SPDX-License-Identifier: GPL-3.0-or-later" as > comments to your source file's header and you are done. I *am* a big fan of SPDX-License-Identifier, but the above being straightforward is only true for the most trivial of examples. REUSE advocate for sprinkling .license files around your repo for e.g. logos and other binaries. Same story with multiple authors, they recommend using multiple FileCopyrightText's initially, then split it out to a separate AUTHORS file and use something like "Project X contributors". https://reuse.software/tutorial/#binary-and-uncommentable-files Ultimately, when everything becomes too much, REUSE falls back to recommending Debian's copyright format anyway! So even if upstream sees the value in taking some copyright busywork off our hands, why not suggest they just use it in the first place in e.g. the LICENSE file. https://reuse.software/faq/#bulk-license > My idea is to allow SPDX documents in addition to DEP-5. Firstly, I didn't think it was called DEP-5 anymore - it was accepted into policy in 2012 as "copyright-format" titled "Machine-readable debian/copyright file", so no longer a proposal for enhancement. This would be a minor pedantic point (a colloquialism) except for the fact that REUSE encourages it as part of their interface: `.reuse/dep5`. > Note that I don't want DEP-5 to go away - it is unlikely that every > project will follow the REUSE spec and writing an SPDX document by > hand has no significant advantages over DEP-5. Besides, using the > file-exclusion function in DEP-5 for uscan is quite useful for ds/dfsg > packages (although that could also be moved to an external file). I think this undermines your previous point about it being less prone to failure - if we could trust upstream assertions on copyright, the NEW review wouldn't be a problem in the first place. The point about uscan is interesting, since if upstream does take on the hard work of license verification such that packaging is just checking, then they're unlikely to have any Files-Excluded, so that would have to merged somehow. signature.asc Description: PGP signature
Re: Services offered by Debian should be dogfooding the real packages on DSA hosts.
On Wed, Jan 26, 2022 at 01:35:51PM +0100, Raphael Hertzog wrote: > On Tue, 25 Jan 2022, Phil Morrell wrote: > > I have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15 > > Thanks for this, but this issue like a few others that have been filed do > describe problems but fail to provide "project/improvement ideas". We are > good at figuring out what's sub-optimal but we are not good at proposing > solutions and implementing them. I completely agree with that limitation for Freexian funding, but this thread asked to rank "What are the most important projects that Debian ought to work on?" as a distinct question from "which projects are fully spec'ed enough to apply for Freexian funding". They are certainly projects that could inspire working groups, or guage support for certain team's ideas from the wider DDs that warrant looking into further, potentially culminating in a concrete application for funding. It's offputting to start a new high-impact project before even knowing if anyone other than yourself would appreciate it being part of Debian. signature.asc Description: PGP signature
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
On Thu, Jan 27, 2022 at 11:27:45AM +0100, Stephan Lachnit wrote: > On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote: > > > > TLDR: I think REUSE.software is a bad idea that is worse than what > > Debian already invented with Machine-readable debian/copyright file. I > > guess if upstream uses it, there's no reason not to ignore that as a > > source of copyright assertions. > > I expected some concerns about the complexity of the SPDX document, > but certainly not about standardized copyright information in source > files. > > Yes, Debian may have invented the machine-readable copyright bill, but > not machine-readable copyright information in source files. Erm, no that's not what I'm saying? I'll requote my agreement with > > I *am* a big fan of SPDX-License-Identifier I will admit I'm somewhat skeptical in how often file-level copies happen these days, rather than folder-level or whole project forks. But it's easy enough to convince people to slap a single-line license comment in to avoid ambiguity. > what REUSE is all about, and it greatly reduces manual labor - I don't > understand how this can be seen as bad. Because being REUSE-compliant IMO greatly *increases* manual labor as soon as you're dealing with non-text forms, multiple authors and aggregation of differing copyright assertions. These are all things that the debian copyright-format has already solved without (as much) manual busywork, so if upstream is agreeable to formally documenting their copyrights, I'd much rather they just used that format in LICENSE. > > Firstly, I didn't think it was called DEP-5 anymore - it was accepted > > into policy in 2012 as "copyright-format" titled "Machine-readable > > debian/copyright file", so no longer a proposal for enhancement. This > > would be a minor pedantic point (a colloquialism) except for the fact > > that REUSE encourages it as part of their interface: `.reuse/dep5`. > > Yes it is called "Machine-readable debian/copyright file Version 1.0", > but everybody knows it _is_ DEP-5, it is even in the spec in the > second sentence of the abstract. Sure, and that's fine as a colloquialism, but you haven't addressed my objection to REUSE formalising that as part of the spec. > The spec _is_ still DEP-5, being accepted doesn't change that. Sure it does, compare `#files-field` in both specs, from 2019 policy upgrading checklist 4.4.1. Perhaps that change should have bumped a version number, but it's a bit late now. > > I think this undermines your previous point about it being less prone to > > failure - if we could trust upstream assertions on copyright, the NEW > > review wouldn't be a problem in the first place. > > I strongly disagree. First of all, upstream knows way better where > they copy the code from than packagers do. > ... > And as a second point, if you write a debian/copyright, you are most > likely to trust what is in the header, and I suspect the copyright > review in NEW is not different from this regard. I mean how can one > even know if the copyright information is wrong? > Yes there are cases where copyright information is missing and one can > try to search it, I've done this not just once, but if a project uses > REUSE headers, this doesn't happen. That has not been my experience for projects without a long history, they tend to not care about copyright initially, slap a generic assertion on it at some point, but without noticing they've included e.g. an embedded copy of zlib or less formally - used an image with a vague gratis use but omitting a formal license. It's only either later, or from the ITP scrutiny that some confusion over pedigree comes to light, someone fires off an email to an early contributor and gets the accurate license information. Or for Debian, the path gets added to Files-Excluded and patched out of compilation. > And projects that use REUSE > are more likely to write that somewhere down as your average NPM > package that puts a "under MIT license" in the readme and copies > minified code from everywhere. Sure, but instead of wasting my time encouraging upstream to become REUSE-compliant, I would much rather promote a better standard like Debian's. I was curious and found approximately 40 instances of REUSE in codesearch, but multiple thousands of the (optional) copyright-format. signature.asc Description: PGP signature
Re: Legal advice regarding the NEW queue
On Thu, Feb 03, 2022 at 09:43:16AM -0500, Scott Kitterman wrote: > I am a member of the FTP Team and have been participating, at least a bit, in > this thread. I am not, however, speaking for the team. Hello Scott, thank you for taking the time to follow this thread, there are two very specific questions outstanding that those outside the FTP team would like an answer to - if you're not willing to speak for the team on these then please can you encourage internal discussion and announcement of the team's opinion. 1. Is it ftpmaster's opinion and policy that there is no difference in NEW queue review process between bin and src? Namely that a full copyright review is necessary to catch the kind of issues you noticed and so it is unhelpful to ping a mention on e.g. IRC that something only needs a lighter review. Alternatively, is it true that bin-NEW is primarily about non-copyright checks and only if something looks egregiously wrong it becomes subject to a full review which may take more time. https://lists.debian.org/debian-devel/2022/01/msg00226.html > I would certainly not support the notion that we have too few licensing > documentation bugs in the archive and we can afford to dismantle the one > process we have in place that actually makes a difference in this area. That is not the challenge being made here. I don't believe anyone is arguing that licensing documentation bugs would be anything other than RC bugs according to policy §2.3, just that NEW processing is not the only possible mitigation for the Debian project's legal risk. 2. Is the ftpmaster team willing and able to select someone to represent the team in a collaboration with non-team members to seek further legal council on the current NEW copyright practices? Specifically, to compile a list of questions in advance and join a call where these questions are put, communicate the results to the team and obviously have buy-in that any changes needed can be worked with. As examples, there are doubts over: the "abundance of caution" approach to avoiding redistribution during the review; the above mentioned copyright review for bin-NEW; whether RC licensing bugs should be treated differently to other RC bugs. https://lists.debian.org/debian-devel/2022/01/msg00359.html I really hope you can help get the answers to these two questions, because without it there doesn't seem to be a way forward for those with time available outside the ftpmaster team. signature.asc Description: PGP signature
Saturation of the FTP Team's available bandwidth processing NEW
On Wed Aug 24 23:20:30 BST 2022, Sean Whitton wrote: > I'm afraid I cannot respond to a message of this length. As I > mentioned previously, all the ftpteam really have the bandwidth to do > is process what's in NEW. * This is more concerning than its indirect effect on uploader motivation * Many thanks for what they do, and a successful decade of recruitment https://web.archive.org/web/201208/https://ftp-master.debian.org/ * That it's still a problem now means the only option left is to do less * Most copyright issues are merely RC bugs, not rejections or need RM * New uploads of existing sources should only have automated checks * Examples: binary splits/hijacks/soname, source clones/renames (other?) * Or this subset of NEW could be exposed as apt repo for manual checks * Somehow implement this without pestering the FTP Team for feedback https://salsa.debian.org/ftp-team/dak/-/merge_requests --- p.s. Sorry Gard for trimming your entire explanation, in the end I wanted to focus on message length rather than linking each point as a paragraph reply. I hope this encourages others to focus on how many times their email will be read. I'm also implicitly referencing all the existing discussions on this topic that end up in *long* threads e.g. https://lists.debian.org/debian-devel/2022/01/msg00360.html signature.asc Description: PGP signature
Re: General resolution: non-free firmware
On Sun, Aug 28, 2022 at 12:56:43AM +, Thorsten Glaser wrote: > Debian Project Secretary - Kurt Roeckx dixit: > > >it are available at: https://www.debian.org/vote/2022/vote_003 > > Is there support for something like A but not enabled by default? > That is, you have to actively select a nōn-default option I don't believe so, because that doesn't solve the problem at hand. How exactly do you select a non-default option if you cannot see or hear it? > More and more graphics adapters now also want firmware uploads to provide any > non-basic functions. A simple basic (S)VGA-compatible framebuffer is not > enough for most users these days; modern desktops expect 3D acceleration, and > a lot of current hardware will not provide that without extra firmware. > Current generations of common Intel-based laptops also need firmware uploads > to make audio work (see the firmware-sof-signed package). https://blog.einval.com/2022/04/19#firmware-what-do-we-do https://peertube.debian.social/w/gpdBYkAuxJ5D8V9DmsTvJS signature.asc Description: PGP signature
Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
On Fri, 2020-04-24 at 09:56 +0200, Andreas Tille wrote: > Hi, > > today I've seen the first time this new lintian warning: > >mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging > Team > > I wonder whether we could this set from severity Warning to Pedandic. > The point is that this address works not only as maintainer but rather > as key in several infrastrutural use case like database queries etc. > > The only reason that would convince me that a change is needed would > be > that the redirect to alioth-lists.debian.net would not work any more > at > some foreseable point of time. So please note: I would not mind > about > automatically replacing that address with something non-obsolete since > we try to do some turnover of all (about 1000) Debian Med packages per > release. But once we start this change several tools will stop > working > reliably. This is to much effort for something that looks cosmetical > in > my eyes. So if you insist that this should be at severity warning > I'll > probably rather add a lintian override automatically for all our > packages rather than automatically change the maintainer address. > > Kind regards > >Andreas. > Hi, See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958182 Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Re: Salsa update: no more "-guest" and more
On Sun, Apr 26, 2020 at 12:31:42AM +0200, Gard Spreemann wrote: > > Bernd Zeimetz writes: > > Actually I think 2FA should be enforced for everybody. > > Even debian.org related passwords might get lost. > > Right, but what's the threat model here? For some of us, losing the > Salsa password is essentially only possible if we have had our PGP > dongle or offline private key backup compromised. Actually, there's a good reason I enable two-factor everywhere despite using a password manager. Password auth submits the same secret over the network on every login, whereas TOTP is based on a pre shared key, so an attacker needs to intercept that initial sharing or phish the OTP. It's probably a minor concern and over the top, but with the ease of use of pass-otp in debian or andOTP in f-droid, why not? I think I've talked myself out of suggesting requiring 2FA on Salsa, but if it's possible to have it by default (opt-out vs opt-in) then that'd be great. signature.asc Description: PGP signature
Re: Pimp your shell - Debian developer tips?
On Jo, 04 iun 20, 10:13:06, Michael Shuler wrote:
> For many years, I have taken a different approach; use the default and add
> only a few minor changes. Each stable update, I use /etc/skel/.bashrc and
> edit/add in my little bits.
for config in ~/.config/bash/*; do source "$config"; done
That is the entirety of my ~/.bashrc due to [WONTFIX], which allows you
to drop in symlinks, organise overrides and specify ordering. I'm
definitely bookmarking this thread to steal some useful snippets.
00_skel -> /etc/skel/.bashrc
10_xdg # alias dig="HOME=~/.config dig"
arguments # alias ls='ls --almost-all --color=auto --human-readable'
bash# see below
git-sh-prompt -> /usr/lib/git-core/git-sh-prompt
shortcuts # alias serve='nohup python3 -m http.server &>/dev/null &'
ssh # see below
ZZ_run # PROMPT_COMMAND='__git_ps1 "'"${PS1%\\*}"'" "\\\$ "'
## ~/.config/bash/bash
# allow sudo to use local aliases
alias sudo='sudo '
export EDITOR=vim
# infinite bash history (currently c. 1MiB)
export HISTFILE="$HOME/.local/share/bash_history"
export HISTFILESIZE=
export HISTSIZE=
export HISTTIMEFORMAT='[%F %T] '
# more filetypes like .log.1.gz
export LESSCLOSE='/usr/bin/lesspipe %s %s'
export LESSOPEN='| /usr/bin/lesspipe %s'
export PATH="$HOME/bin:$PATH"
shopt -s globstar
## ~/.config/bash/ssh
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
ensure_known_host() {
local hostname=$1
local known_hosts=${2:-~/.ssh/known_hosts}
ssh-keygen -F "$hostname" -f "$known_hosts" &>/dev/null \
|| ssh-keyscan -H -t ecdsa "$hostname" \
| tee --append "$known_hosts"
}
# hook in a custom git style subcommand
ssh() {
case $1 in
tunnel )
shift
while true; do
date '+%FT%T'
command ssh -R :localhost:22 user@server "$@"
done
;;
* ) command ssh "$@" ;;
esac
}
[WONTFIX]: https://savannah.gnu.org/support/?108134
signature.asc
Description: PGP signature
Re: Lenovo discount portal update (and a few other things)
On Thu, Sep 03, 2020 at 03:18:21PM -0400, Mark Pearson wrote: > On 9/2/2020 9:18 PM, Paul Wise wrote: > > Many of the Debian membership benefits (link above) also apply to > > Debian Maintainers (folks who are not members but can do unsupervised > > uploads of particular packages) and Debian contributors in general, > > has Lenovo considered including one or both of these groups in the > > discount program? > > If there is a group missing that it makes sense to add we can look at that - > let me know. Using the debian.org email as a filter seemed like a neat and > simple solution when I discussed it with Jonathan originally. > I'd rather avoid having to manage lists of individual email addresses. > That's a real pain and IMO will only break in the long term. > Open to other suggestions if what we have implemented doesn't work but it > has to be balanced with the amount of effort involved. Oooh, as one of the 246 Debian Maintainers without a debian.org address, I would obviously appreciate it if we could be included in the offer. Some of the MemberBenefits offers accept a GPG-signed email to a special address, which can be checked against keyring.debian.org. On the other hand, I believe that would exclude Contributors such as translators, perhaps the FrontDesk team would have an idea of how a third-party could verify project status by email validity? https://nm.debian.org/public/stats/ https://nm.debian.org/public/findperson/?status=dm (uses /api/people/) https://wiki.debian.org/Teams/FrontDesk signature.asc Description: PGP signature
Bug#970200: ITP: rednotebook -- Modern desktop diary and personal journaling tool.
Package: wnpp Severity: wishlist Owner: Phil Wyett X-Debbugs-CC: debian-devel@lists.debian.org * Package name: rednotebook Version : 2.20+ds-1 Upstream Author : Jendrik Seipp * URL : https://github.com/jendrikseipp/rednotebook * License : GPL-2+ Programming Lang: Python Description : Modern desktop diary and personal journaling tool. It lets you format, tag and search your entries. You can also add pictures, links and customisable templates, spell check your notes, and export to plain text, HTML, LaTeX or PDF. Additional notes: A return of the package to debian. I shall maintain this package. Package will need salsa repo and appropriate permissions creating. RFS to follow. Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#970204: ITP: rednotebook -- Modern desktop diary and personal journaling tool.
Package: wnpp Severity: wishlist Owner: Phil Wyett X-Debbugs-CC: debian-devel@lists.debian.org * Package name: rednotebook Version : 2.20+ds-1 Upstream Author : Jendrik Seipp * URL : https://github.com/jendrikseipp/rednotebook * License : GPL-2+ Programming Lang: Python Description : Modern desktop diary and personal journaling tool. It lets you format, tag and search your entries. You can also add pictures, links and customisable templates, spell check your notes, and export to plain text, HTML, LaTeX or PDF. Additional notes: A return of the package to debian. I shall maintain this package. Package will need salsa repo and appropriate permissions creating. RFS to follow. Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 2020-07-26 at 04:55 +0100, Phil Wyett wrote: > On Tue, 28 Apr 2020 03:54:59 +0100 Phil Wyett < > philip.wy...@kathenas.org > > wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "gnome-maps" > > > > * Package name: gnome-maps > >Version : 3.30.3.1-0+deb10u1 > >Upstream Author : maps-l...@gnome.org > > * URL : https://wiki.gnome.org/Apps/Maps > > * License : GPL-2+ > > * Vcs : https://salsa.debian.org/gnome-team/gnome-maps > >Section : gnome > > > > It builds those binary packages: > > > > gnome-maps - map application for GNOME > > > > To access further information about this package, please visit the > > following URL: > > > > https://mentors.debian.net/package/gnome-maps > > > > Alternatively, one can download the package with dget using this > > command: > > > > dget -x > > > https://mentors.debian.net/debian/pool/main/g/gnome-maps/gnome-maps_3.30.3.1-0+deb10u1.dsc > > Changes since the last upload: > > > >* Non-maintainer upload > >* New upstream release > > - Make the shape layer renderer use the tile size specified in > the > > dynamic > >service file, fixing an issue with misaligned shape layer > > (GeoJSON, GPX, > >KML) rendering with the new 512 pixel tile > > - Update Icelandic translation > > > > === > > > > Note: Package requires sponsor for stable updates upload. > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947464 > > > > Regards > > > > Phil > > > > Hi all, > > Bump. Anyone fancy sponsoring with a stable release imminent? > > This RFS has been additionally mailed to the gtk-gnome list and the > gnome maintainers with zero replies/interaction to date. > > Regards > > Phil > Hi all, Ping. Can we have this uploaded for the upcoming 10.6? Still seen no love and missed so many point releases now. Just need someone with permissions to do it and a little time. Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 2020-09-13 at 15:24 +0100, Simon McVittie wrote: > On Sun, 13 Sep 2020 at 10:35:48 +0100, Simon McVittie wrote: > > On Sun, 13 Sep 2020 at 04:02:56 +0100, Phil Wyett wrote: > > > Can we have this uploaded for the upcoming 10.6? Still seen no > > > love and > > > missed so many point releases now. Just need someone with > > > permissions to > > > do it and a little time. > > > > I'll put this on my queue to review and test. > > Uploaded. In future, if you have changes for a package in stable, > please try to work with the package's maintainers first, rather than > bypassing them. > > I know the GNOME team has taken too long to respond, and I'm sorry > about > that. We are responsible for a lot of packages, of which gnome-maps is > far from our highest priority. > > smcv Hi Simon, Thank you for the response, review and upload. I will try to be more in touch with the GNOME team with future work. I hope via discussion, git and MR. To go back to time and hardware. The DPL did mention spending as part of his DebConf20 talk. Maybe an application can be made for hardware for members of the GNOME team, so they might have a stable instance on hand for its related needs. GNOME is a very important part of Debian and supporting those working on it would be a good thing. Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Re: Congratulations Phil , Federal 2017 Incentives for Home Solar Panelsm5ad
We already have solar. Sent from my iPad > On Feb 15, 2017, at 10:59 AM, GoSolarAmerica > wrote: > > gtsdpnv > CONGRATUIATlON_Phil, > > _Your_Home_May_Qualify_for_Government_Rebates_to_Go_Solar!_ > > > _Government_Subsidies_to_Go_Solar!_ > > > _Profit_From_Solar,_Save_Up_to_50%_or_More_on_Utility_Costs!_ > > > _Click_Here_ > > > > _Un_Subscribe_ > > > Opt_Out > > twebjmpo > @#$%^&*()(*&^%$#@$%^&*()(*&^%$#@$%^&*(*&^%$#@$%^&*(*&^%$#@#$%^&*(*&^%$#
Re: path to gitlab upstream
On Wed, May 30, 2018 at 03:10:57PM +0200, Geert Stappers wrote:
> On Tue, May 29, 2018 at 01:04:33PM +0100, Ian Jackson wrote:
> > Ansgar Burchardt writes ("Re: Want to make salsa advertise contact and
> > source code details [and 1 more messages]"):
> > > That seems like an horrible maintenance nightmare just to avoid even
> > > talking to upstream...
> >
> > OK, so does someone in Debian, maybe from the Salsa team, have any
> > contacts I could use ? (I promise to be reasonable and polite.)
> > Or should I just try to go in through the "front door" and create an
> > issue in Gitlab CE's gitlab ?
> >
> > ISTM that the former approach is more likely to work if we know anyone
> > at Gitlab already.
>
> There is https://gitlab.com/gitlab-org/gitlab-ce/
>
> It has currently 10,712 issues and 595 merge requests.
>
> About the issues: Open: 10,712 Closed: 25,941 All: 36,653
> MR: Open: 595 Merged: 15,906 Closed 2,696 All: 19,198
In the spirit of Debian (not necessarily Salsa team) communication with
GitLab development, I note that Gnome have coordinated under "GNOME List
of Issues & Priorities" [43566]. Perhaps Debian should also have an open
issue for requests from DDs, at the moment I can only find relevant
issues by searching for "salsa".
--
Phil Morrell (emorrp1)
[43566]: https://gitlab.com/gitlab-org/gitlab-ce/issues/43566
signature.asc
Description: PGP signature
Bug#900867: ITP: firefox-syncserver -- Firefox Sync storage and token server
Package: wnpp Severity: wishlist Owner: Phil Morrell * Package name: firefox-syncserver Version : 1.8.0 Upstream Author : Mozilla Corporation * URL : https://github.com/mozilla-services/syncserver * License : MPL-2.0 Programming Lang: Python 2 Description : Firefox Sync storage and token server This is an all-in-one package for running a self-hosted Firefox Sync server. It bundles the "tokenserver" project for authentication and the "syncstorage" project for storage, to produce a single stand-alone webapp. This server defers authentication to the Mozilla-hosted accounts server at https://accounts.firefox.com, but stores the user sync data such as bookmarks, preferences and add-ons. --- It is useful for using the multiple-device features of Firefox Sync without storing your sensitive data in the cloud. It would also be a prerequisite for someone packaging the Firefox Accounts server. I would love to maintain it as part of pkg-mozilla-maintainers, but since the alioth list is defunct I've not yet got in touch. https://salsa.debian.org/emorrp1-guest/firefox-syncserver signature.asc Description: PGP signature
Bug#909798: ITP: ryzomcore -- science-fantasy MMORPG engine
Package: wnpp Severity: wishlist Owner: Phil Morrell * Package name: ryzomcore Version : 3.4.0 Upstream Author : Winch Gate Property Ltd. * URL : http://www.ryzomcore.com/ * License : AGPL3+, CC-BY-SA, GPL-2 Programming Lang: C++, Lua Description : science-fantasy MMORPG engine Ryzom Core is a software platform for creating and running massively multi-user entertainment in a 3D environment over the Internet. Ryzom Core provides the base technologies and a set of development methodologies for the development of both client and server code. The library contains independently reusable network, ai and 3d modules. --- I'm not actually sure yet if the software is suitable for debian, but I'm filing the ITP to avoid duplication of effort and to document any relevant considerations. It will be packaged as part of the Games Team. https://salsa.debian.org/emorrp1-guest/ryzomcore https://ryzom.com/ is almost fully free software: client, server, tools, and graphics. The audio assets are currently proprietary "as Ryzom has not determined the copyright nature of those assets" and so is the official world configuration and data. Assets are c. 8GB uncompressed. A fully libre world server is in development https://khaganat.net The NeL library was previously packaged in Debian up to Wheezy. signature.asc Description: PGP signature
Bug#875264: ITP: rednotebook -- -- A cross-platform journal
Package: wnpp Severity: wishlist Owner: Phil Wyett X-Debbugs-CC: debian-devel@lists.debian.org * Package name: rednotebook Version : 2.2 Upstream Author : Jendrik Seipp * URL : https://github.com/jendrikseipp/rednotebook * License : GPL-2+ Programming Lang: Python Description: A modern desktop journal. It lets you format, tag and search your entries. You can also add pictures, links and customizable templates, spell check your notes, and export to plain text, HTML, Latex or PDF. Notes: This package was removed from debian due to webkit issues. The package, major version 2, will be introduced as a new package. I will also be taking maintainer responsibility of the package. Regards Phil -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Web: https://kathenas.org Github: https://github.com/kathenas Twitter: kathenasorg Instagram: kathenasorg signature.asc Description: This is a digitally signed message part
suil - current packaging query
Hi all, I looked at installing audacity on stretch and found it wanted to install QT deps as well as GTK deps. Not experiencing this in the past, I said 'n' to apt and had a delve into why this was happening. I found audacity now uses suil. Package page: https://packages.debian.org/stretch/libsuil-0-0 As you can see by the deps on the page above - GTK and QT. I looked upstream and found their packaging doc. http://git.drobilla.net/cgit.cgi/suil.git/tree/PACKAGING The bottom section of the doc: *** IMPORTANT GUIDELINES FOR PACKAGING SUIL *** The purpose of Suil is to abstract plugin UI toolkits away from host code. To achieve this, Suil performs its magic by dynamically loading modules for each toolkit. The main Suil library does NOT depend on any toolkit libraries, and thus neither should your package. Please package the individual modules (e.g. libsuil_gtk2_in_qt4.so) as separate packages, which themselves depend on the involved toolkits. These packages should also be versioned as described above to support parallel installation. Please do not make the main Suil package depend on any toolkit package, this defeats the purpose of Suil and will severely irritate those who for whatever reason do not want a particular toolkit dependency. The main Suil package may have a weak dependency (e.g. "recommends") on the individual wrapper modules, and it's fine if these are installed by default, but it must be possible to install Suil without installing them if the user explicitly wishes to do so. // End Is it just me or should this package be broken down into a core and subset module packages? Any thoughts and how suil should be better packaged welcome. Bug report? Regards Phil -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Web: https://kathenas.org Github: https://github.com/kathenas Twitter: kathenasorg Instagram: kathenasorg signature.asc Description: This is a digitally signed message part
Re: Proposed change of offensive packages to -offensive
On Wed, 2017-11-22 at 08:49 +, Jonathan Dowland wrote: > On Wed, Nov 22, 2017 at 01:38:43AM +, Holger Levsen wrote: > > no, please, no. > > > > policy should document technical terms. > > > > whatever else we might come up to deal with the "real world" (that is > > more complicated than that, eg think tibet, taiwan and china, or $foo) > > should not be included in -policy. > > This is about standardising the label we use for marking offensive > content, not about defining what is or isn't offensive. I'd argue that > "-offensive" suffix proposal was a technical term. > Hi, My two pence worth... In my honest opinion, rating certain content types within a package should be done along the lines of PEGI[1]. A self regulatory rating done as part of a social policy and administered by the particular packages maintainer. All subsequent questioning of rating would be done via bug reports against the particular package. Not an exhaustive list... * Rating set within debian folder - maybe rating file. * Seen on packages.d.o, PTS and query by apt etc. for package. * Should not be auto installed as a recommends etc. [1] http://www.pegi.info Regards Phil -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Web: https://kathenas.org GitLab: https://gitlab.com/kathenas Twitter: kathenasorg Instagram: kathenasorg GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A signature.asc Description: This is a digitally signed message part
Re: Proposed change of offensive packages to -offensive
On Wed, 2017-11-22 at 21:29 +0800, Paul Wise wrote: > On Wed, Nov 22, 2017 at 8:42 PM, Phil Wyett wrote: > > > In my honest opinion, rating certain content types within a package should > > be > > done along the lines of PEGI[1]. A self regulatory rating done as part of a > > social policy and administered by the particular packages maintainer. All > > subsequent questioning of rating would be done via bug reports against the > > particular package. > > Some rating related resources are at: > > https://wiki.debian.org/OpenRating > > > * Rating set within debian folder - maybe rating file. > > Personally I think a debtags/screenshots style service would be better here. > > > * Seen on packages.d.o, PTS and query by apt etc. for package. > > * Should not be auto installed as a recommends etc. > > Preferably configurable, perhaps by installing packages with standard names. > Hi, Thanks for the link Paul. The Open Rating debtags idea I find far more appealing than package naming with the offensive or other suffix. Regards Phil -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Web: https://kathenas.org GitLab: https://gitlab.com/kathenas Twitter: kathenasorg Instagram: kathenasorg GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A signature.asc Description: This is a digitally signed message part
Re: Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-09-29
On Sun, 2024-09-29 at 22:27 +0200, Marco d'Itri wrote: > On Sep 29, Phil Wyett wrote: > > > Below is the link to the page of currently "confirmed" as being in good > > order > I suggest that you also add the list to these emails. > > > Hi all DDs, It has been suggested that I need to supply a list of the current "confirmed" packages requiring a sponsor that need a DD to review and possibly upload to Debian when ready. Below is that list. #1072910 RFS: lsp-treemacs/0.5-1 -- treemacs integration for Emacs LSP RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072910 #1077968 RFS: scrcpy/2.6.1-1 -- Display and control your Android device RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077968 #1079474 RFS: openscap/1.4.0+dfsg-1 -- libraries enabling integration of the SCAP line of standards - Documentation RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079474 #1082242 RFS: nvidia-vaapi-driver/0.0.12-1 [ITA] -- VA-API implementation that uses NVDEC as a backend RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082242 #1082589 RFS: purple-discord/0.9.2024.09.29.git.32899c2-1 -- Discord messaging service plugin for libpurple RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082589 #1022747 RFS: prismlauncher/8.4+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022747 #1037098 RFS: serious-engine/0~git20230724+dfsg-1 [ITP] -- game engine developed for the classic Serious Sam games RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037098 #1061087 RFS: bash-unit/2.3.1-1 [ITP] -- bash_unit - bash unit testing RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061087 #1064485 RFS: samplebrain/0.18.5-1 [ITP] -- Custom sample smashing app designed by Aphex Twin RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064485 #1073153 RFS: emacs-lsp-docker/0.0~git20240507.16a0cfb-1 [ITP] -- LSP Docker integration for lsp-mode RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073153 #1074622 RFS: emacs-dape/0.15.0-1 [ITP] -- Debug Adapter Protocol for Emacs RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074622 #1076146 RFS: feenox/1.0.83-1 [RFP] -- cloud-first free no-X uniX-like finite-element(ish) tool RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076146 #1077618 RFS: libjs-jush/2.0.2+git20210206+1-1 [ITP] -- JavaScript Syntax Highlighter RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077618 #1078341 RFS: gpgmngr/1.0.2-1 [ITP] -- GPG assistant for the Linux terminal RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078341 #1079664 RFS: saf/1.013-1 [ITP] -- Minimal abstract interface for simple games RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079664 #1079902 RFS: descent3/1.5.0+ds-1 [ITP] -- port of the 1999 classic game Descent 3 RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079902 #1080305 RFS: apt-mirror2/9-1 [ITP] -- Python/asyncio reimplementation of the apt-mirror RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080305 #1080360 RFS: caio/0.9.17-1 [ITP] -- Asynchronous file IO for Linux MacOS or Windows RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080360 #1081042 RFS: aiolimiter/1.1.0-1 [ITP] -- asyncio rate limiter, a leaky bucket implementation RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081042 #1081131 RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081131 #1081455 RFS: keyd/2.5.0-1 [ITP] -- keyboard key remapping daemon RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081455 #1081586 RFS: log2ram/1.7.2+ds-1 [ITP] -- Write log files to RAM RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081586 Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-11-04
Dear all DDs, Below is a package list of the currently "confirmed", as being in good order packages that are awaiting a DD review and possible upload to Debian. If DDs could spare the time to pick up a package or two and finish off the package mentor process it would be greatly appreciated. Outstanding bugs -- Important bugs; Confirmed (1 bug) #1084901 RFS: qstardict/2.0.2-1 [ITA] [RC] -- International dictionary written using Qt https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084901 Outstanding bugs -- Normal bugs; Confirmed (4 bugs) #1072910 RFS: lsp-treemacs/0.5-1 -- treemacs integration for Emacs LSP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072910 #1077968 RFS: scrcpy/2.6.1-1 -- Display and control your Android device https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077968 #1084101 RFS: golang-golang-x-oauth2/0.23.0-1 [Team] -- Google APIs support for OAuth2 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084101 #1084847 RFS: elpa-subed/1.2.16-1 -- Emacs mode for editing subtitles while playing the corresponding video https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084847 Outstanding bugs -- Wishlist items; Confirmed (24 bugs) #988010 RFS: td-system-tools/2.0.1-1 [ITP] -- System https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988010 #1022747 RFS: prismlauncher/8.4+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022747 #1037098 RFS: serious-engine/0~git20230724+dfsg-1 [ITP] -- game engine developed for the classic Serious Sam games https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037098 #1064485 RFS: samplebrain/0.18.5-1 [ITP] -- Custom sample smashing app designed by Aphex Twin https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064485 #1072518 RFS: debpic/1.0.0 [ITP] -- build Debian packages in an isolated Docker environment https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072518 #1073153 RFS: emacs-lsp-docker/0.0~git20240507.16a0cfb-1 [ITP] -- LSP Docker integration for lsp-mode https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073153 #1074622 RFS: emacs-dape/0.15.0-1 [ITP] -- Debug Adapter Protocol for Emacs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074622 #1076146 RFS: feenox/1.0.83-1 [RFP] -- cloud-first free no-X uniX-like finite-element(ish) tool https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076146 #1077618 RFS: libjs-jush/2.0.2+git20210206+1-1 [ITP] -- JavaScript Syntax Highlighter https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077618 #1078341 RFS: gpgmngr/1.0.2-1 [ITP] -- GPG assistant for the Linux terminal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078341 #1079664 RFS: saf/1.013-1 [ITP] -- Minimal abstract interface for simple games https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079664 #1079902 RFS: descent3/1.5.0+ds-1 [ITP] -- port of the 1999 classic game Descent 3 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079902 #1080242 RFS: electrum-nmc/4.0.6-2 [ITP] -- Easy to use Namecoin client https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080242 #1080305 RFS: apt-mirror2/9-1 [ITP] -- Python/asyncio reimplementation of the apt-mirror https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080305 #1081042 RFS: aiolimiter/1.1.0-1 [ITP] -- asyncio rate limiter, a leaky bucket implementation https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081042 #1081131 RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081131 #1081455 RFS: keyd/2.5.0-1 [ITP] -- keyboard key remapping daemon https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081455 #1081586 RFS: log2ram/1.7.2+ds-1 [ITP] -- Write log files to RAM https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081586 #1084022 RFS: buffybox/3.2.0+dfsg-1 [ITP] -- Touch-enabled framebuffer keyboard (not only) for vampire slayers https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084022 #1084795 RFS: openmohaa/0.70.0+dfsg-1 [ITP] -- military WWII first-person shooter game https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084795 #1084869 RFS: keepass2-plugin-keepassrpc/2.0.2+dfsg-1 [RFP] -- RPC plugin for KeePass 2 Password manager https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084869 #1084884 RFS: golang-github-regclient-regclient/0.7.1-1 [ITP] -- Docker and OCI Registry Client (tooling) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084884 #1084885 RFS: golang-github-olareg-olareg/0.1.1-1 [ITP] -- Minimal container registry (program) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084885 #1085585 RFS: mcds/1.7-1 [ITP] -- Mutt CardDAV search utility https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085585 Please check that another DD is not already involved with the package. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Br
Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-09-29
Dear all DDs, Below is the link to the page of currently "confirmed" as being in good order packages that are awaiting a DD review and possible upload to Debian. If DDs could spare the time to pick up a package or two and finish off the package mentor process it would be greatly appreciated. https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Aconfirmed;package=sponsorship-requests Please check that another DD is not already involved with the package. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: xindy: Proposed NMU for xindy - light touch
On Fri, 2024-09-20 at 14:36 +0200, Preuße, Hilmar wrote: > Am 20.09.2024 um 13:34 schrieb Phil Wyett: > > Hi Phil, > > > Attached is a proposed NMU debdiff for your consideration that fixes a > > reproducible build bug and with a light touch, updates some other elements. > > Thanks for the patch! > > 1. For historical reasons the repo is on github, this is visible on the > tracker page [1]. > 2. Please rebase the patch, based on the commits after latest upload. > 3. You may send the patch to bug #1048039 directly, no need to spam > debian-devel@lists.debian.org for this. > > Hilmar > > [1] https://tracker.debian.org/pkg/xindy > -- > sigfault > Hi, As requested, I have added diff to the bug report. Apologies for sending to devel list, it will not happen again when doing such contribution. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
xindy: Proposed NMU for xindy - light touch
Dear Maintainer, Attached is a proposed NMU debdiff for your consideration that fixes a reproducible build bug and with a light touch, updates some other elements. xindy (2.5.1.20160104-11.1) unstable; urgency=medium * Non-maintainer upload. * 'd/clean' - add files: - make-rules/alphabets/norwegian/latin1.pl - user-commands/texindy.1 - user-commands/xindy.1 Fixes build after successful build. (Closes: #1048039) * 'd/control': - Use 'debhelper-compat' 13. - Update 'Standards-Version' to 4.7.0. no changes required. * 'd/watch': Update to version 4. -- Phil Wyett Fri, 20 Sep 2024 11:46:25 +0100 No Salsa repo, so cannot do this as a Merge Request (MR). Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- diff -Nru xindy-2.5.1.20160104/debian/changelog xindy-2.5.1.20160104/debian/changelog --- xindy-2.5.1.20160104/debian/changelog 2021-09-04 10:27:48.0 +0100 +++ xindy-2.5.1.20160104/debian/changelog 2024-09-20 11:46:25.0 +0100 @@ -1,3 +1,18 @@ +xindy (2.5.1.20160104-11.1) unstable; urgency=medium + + * Non-maintainer upload. + * 'd/clean' - add files: +- make-rules/alphabets/norwegian/latin1.pl +- user-commands/texindy.1 +- user-commands/xindy.1 +Fixes build after successful build. (Closes: #1048039) + * 'd/control': +- Use 'debhelper-compat' 13. +- Update 'Standards-Version' to 4.7.0. no changes required. + * 'd/watch': Update to version 4. + + -- Phil Wyett Fri, 20 Sep 2024 11:46:25 +0100 + xindy (2.5.1.20160104-11) unstable; urgency=medium [ Debian Janitor ] diff -Nru xindy-2.5.1.20160104/debian/clean xindy-2.5.1.20160104/debian/clean --- xindy-2.5.1.20160104/debian/clean 2021-09-04 10:27:48.0 +0100 +++ xindy-2.5.1.20160104/debian/clean 2024-09-20 11:46:08.0 +0100 @@ -1 +1,4 @@ aclocal.m4 +make-rules/alphabets/norwegian/latin1.pl +user-commands/texindy.1 +user-commands/xindy.1 \ No newline at end of file diff -Nru xindy-2.5.1.20160104/debian/control xindy-2.5.1.20160104/debian/control --- xindy-2.5.1.20160104/debian/control 2021-09-04 10:27:48.0 +0100 +++ xindy-2.5.1.20160104/debian/control 2024-09-20 11:46:25.0 +0100 @@ -10,10 +10,10 @@ texlive-latex-recommended, texlive-fonts-recommended, cm-super -Build-Depends: debhelper-compat (= 12), +Build-Depends: debhelper-compat (= 13), flex, clisp -Standards-Version: 4.5.1 +Standards-Version: 4.7.0 Homepage: http://www.xindy.org/ Vcs-Git: https://github.com/debian-tex/xindy.git Vcs-Browser: https://github.com/debian-tex/xindy diff -Nru xindy-2.5.1.20160104/debian/watch xindy-2.5.1.20160104/debian/watch --- xindy-2.5.1.20160104/debian/watch 2021-09-04 10:27:48.0 +0100 +++ xindy-2.5.1.20160104/debian/watch 2024-09-20 11:46:25.0 +0100 @@ -1,2 +1,2 @@ -version=3 -https://mirror.informatik.hs-fulda.de/tex-archive/indexing/xindy/base/xindy-([\d.]*)\.tar\.gz \ No newline at end of file +version=4 +https://mirror.informatik.hs-fulda.de/tex-archive/indexing/xindy/base/xindy-([\d.]*)\.tar\.gz signature.asc Description: This is a digitally signed message part
Re: Problems to find sponsors (Was: Bits from DPL)
On Wed, 2024-12-04 at 20:41 -0300, Leandro Cunha wrote: > Hi, > > On Wed, Dec 4, 2024 at 8:30 PM Xiyue Deng wrote: > > P.S. I would also like to take this chance to appreciate Phil Wyett's > > automatic RFS checking that adds "confirmed" tag to RFS bugs that passed > > the checks, which helps ensure a minimum quality of a prepared package > > ready for sponsorship that can reduce the review rounds and potentially > > save some time for potential sponsors. > > > > [1] > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com > > [2] https://wiki.debian.org/Teams/DebianEmacsenTeam > > > > -- > > Regards, > > Xiyue Deng > > Look, he really deserves to become a Debian Developer, from what I see > he has been contributing to Debian for a while and now he is doing > this work and he has got 3 advocates. It would be very fair and I > agree with you. > > https://lists.debian.org/debian-newmaint/2024/12/msg6.html > Leandro, Thank you for your support, but I would prefer to leave my DD application out of this discussion. Whatever happens regarding that process it will not affect my contribution. I hope to see some mentors contribution from yourself again in the near future. :-) Regards Phil -- Donations... Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Liberapay: https://liberapay.com/kathenas -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Wiki: https://wiki.kathenas.org Instagram: https://instagram.com/kathenasorg Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Problems to find sponsors (Was: Bits from DPL)
On Wed, 2024-12-04 at 15:30 -0800, Xiyue Deng wrote: > Andreas Tille writes: > > > Am Wed, Dec 04, 2024 at 10:46:03PM +0500 schrieb Andrey Rakhmatullin: > > > On Wed, Dec 04, 2024 at 10:39:52AM -0700, Soren Stoutner wrote: > > > > I have directed several RFS (Request For Sponsor) towards appropriate > > > > teams, > > > > when then exist. However, my personal experience is that the majority > > > > of RFS > > > > that come into Debian Mentors do not fit neatly into any existing team. > > > > > > Yeah. We have a lot of leaf applications and so on that can't have a team. > > > > To be precise, we have both: packages that may not fit neatly into any > > team, and many packages that align perfectly with existing teams, such > > as the scientific team, games team, multimedia team, phototools team, > > and others. I've moved many packages to these teams. Additionally, the > > software in question is written in a specific programming language, > > making it easier to find maintainers fluent in that language within the > > dedicated language team. These maintainers can help with issues, or, > > even better, the newcomer may contribute to resolving problems within > > the language-specific team. I don't want to suggest that current team > > members are eager for more work, but the potential for new, active team > > members might be compelling enough to take on the responsibility of > > sponsoring. > > > > Kind regards > >Andreas. > > > > -- > > https://fam-tille.de > > > > Having a team to maintain a group of related packages is supposed to > improve velocity and usually works well. However there is a chance that > a team may be understuffed, both temporarily and gradually. I have > recently become a DM, so technically if my RFS bugs have been sponsored > I can work autonomously on those packages. Unfortunately my RFS bug > list is still growing[1] as my team becomes relatively less active > recently. I totally understand as this is voluntary work and people > have their lives to attend to (I do), and I am grateful for all comments > and sponsoring from my team. On the other hand, seeing my packages > being removed from mentors.d.n because of no sponsorship after 20 weeks > is also discouraging. > > It would be great to have a group of DDs that are willing to regularly > check for RFS bugs / mentors.d.n and offer sponsorship, even for team > maintained packages. Some teams also maintain a team policy either on > wiki[2] or in a document in team repo, which can be a good guideline for > outside sponsors. > > Just my 2 cents. > > P.S. I would also like to take this chance to appreciate Phil Wyett's > automatic RFS checking that adds "confirmed" tag to RFS bugs that passed > the checks, which helps ensure a minimum quality of a prepared package > ready for sponsorship that can reduce the review rounds and potentially > save some time for potential sponsors. > > [1] > https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com > [2] https://wiki.debian.org/Teams/DebianEmacsenTeam > Xiyue, Many thanks for the kind words. I agree a Mentors Group of DD's would be great. We must find motivated individuals and this is the age old struggle for volunteer projects like Debian. I am hoping that contributors like yourself that have in real terms felt the benefits of mentors become DM's and DD's then allocate some of your contribution time to mentors on a weekly or monthly basis. This in turn I would hope over time add more contributors of all levels and we can maintain an active group connected to teams etc. that would serve Debian well. Ever hopeful. :-) Regards Phil -- Donations... Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Liberapay: https://liberapay.com/kathenas -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Wiki: https://wiki.kathenas.org Instagram: https://instagram.com/kathenasorg Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Problems to find sponsors (Was: Bits from DPL)
On Wed, 2024-12-04 at 22:07 -0300, Leandro Cunha wrote: > Hi, > > On Wed, Dec 4, 2024 at 9:20 PM Phil Wyett wrote: > > > > On Wed, 2024-12-04 at 20:41 -0300, Leandro Cunha wrote: > > > Hi, > > > > > > On Wed, Dec 4, 2024 at 8:30 PM Xiyue Deng wrote: > > > > P.S. I would also like to take this chance to appreciate Phil Wyett's > > > > automatic RFS checking that adds "confirmed" tag to RFS bugs that passed > > > > the checks, which helps ensure a minimum quality of a prepared package > > > > ready for sponsorship that can reduce the review rounds and potentially > > > > save some time for potential sponsors. > > > > > > > > [1] > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sponsorship-requests&submitter=manphiz%40gmail.com > > > > [2] https://wiki.debian.org/Teams/DebianEmacsenTeam > > > > > > > > -- > > > > Regards, > > > > Xiyue Deng > > > > > > Look, he really deserves to become a Debian Developer, from what I see > > > he has been contributing to Debian for a while and now he is doing > > > this work and he has got 3 advocates. It would be very fair and I > > > agree with you. > > > > > > https://lists.debian.org/debian-newmaint/2024/12/msg6.html > > > > > > > Leandro, > > > > Thank you for your support, but I would prefer to leave my DD application > > out of this discussion. Whatever happens > > regarding that process it will not affect my contribution. > > > > I hope to see some mentors contribution from yourself again in the near > > future. :-) > > I'm just saying that I agree with him, and also taking the opportunity > to wish Phil Wyett good luck, and that more contributions from me > should appear soon. > > I follow this list and the mentors, so it's not necessary to enter my > email and when reply with the list's email I should already receive it > here. No need to enter my email address. > > I am also grateful for the reviews that were carried out by the Debian > Mentors list. I have already learned and continue to learn a lot > there. :) > > > -- > Cheers, > Leandro Cunha Leandro, Sorry, 'Group Reply' adjusted. Many thanks and see you on mentors soon. Regards Phil -- Donations... Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Liberapay: https://liberapay.com/kathenas -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Wiki: https://wiki.kathenas.org Instagram: https://instagram.com/kathenasorg Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Mentors. Confirmed packages needing DD review and possible sponsorship
protocol RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092020 dget -x https://mentors.debian.net/debian/pool/main/w/woof/woof_20220202-1.dsc #1092027 RFS: midiminder/1.0.1-1 [ITP] -- MIDI connection minder & viewer RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092027 dget -x https://mentors.debian.net/debian/pool/main/m/midiminder/midiminder_1.0.1-1.dsc #1092093 RFS: turtle/0.11.1-1 [ITP] -- Nautilus extension for turtle RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092093 dget -x https://mentors.debian.net/debian/pool/main/t/turtle/turtle_0.11.1-1.dsc #1092179 RFS: boost-ext-ut/2.1.1-1 [ITP] -- C++ single header/module, macro- free unit testing framework RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092179 dget -x https://mentors.debian.net/debian/pool/main/b/boost-ext-ut/boost-ext-ut_2.1.1-1.dsc #1092272 RFS: xfce4-docklike-plugin/0.4.2-1 [ITP] -- Modern, minimalist taskbar for Xfce RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092272 dget -x https://mentors.debian.net/debian/pool/main/x/xfce4-docklike-plugin/xfce4-docklike-plugin_0.4.2-1.dsc #1092273 RFS: xfce4-time-out-plugin/1.1.4-1 [ITP] -- Take periodical breaks from the computer every X minutes RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092273 dget -x https://mentors.debian.net/debian/pool/main/x/xfce4-time-out-plugin/xfce4-time-out-plugin_1.1.4-1.dsc #1094174 RFS: showtime/47.0-1 [ITP] -- Watch without distraction RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094174 GNOME Team... #1094425 RFS: emacs-jsonrpc/1.0.25-1 [ITP] -- Emacs JSON-RPC library RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094425 dget -x https://mentors.debian.net/debian/pool/main/e/emacs-jsonrpc/emacs-jsonrpc_1.0.25-1.dsc #1094657 RFS: vim-vimtex/2.16-1 [ITP] -- Modern Vim and Neovim plugin for LaTeX files editing RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094657 dget -x https://mentors.debian.net/debian/pool/main/v/vim-vimtex/vim-vimtex_2.16-1.dsc #1094658 RFS: vim-vimwiki/2024.01.24-1 [ITP] -- Vim plugin for personal wiki RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094658 dget -x https://mentors.debian.net/debian/pool/main/v/vim-vimwiki/vim-vimwiki_2024.01.24-1.dsc Regards Phil -- Donations... Buy Me A Coffee: https://buymeacoffee.com/kathenasorg -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Internet Relay Chat (IRC): kathenas Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Problems to find sponsors (Was: Bits from DPL)
On Mon, 2024-12-09 at 15:58 -0800, Xiyue Deng wrote: > Hi Sam, > > Sam Hartman writes: > > > > > > > > "Andrey" == Andrey Rakhmatullin writes: > > > > Andrey> On Wed, Dec 04, 2024 at 03:30:23PM -0800, Xiyue Deng wrote: > > >> It would be great to have a group of DDs that are willing to > > >> regularly check for RFS bugs / mentors.d.n and offer sponsorship > > > > Andrey> Sure. This is true since the beginning of the RFS process, > > Andrey> and as nothing stops people from doing this, but based on my > > Andrey> observations such a group was never larger than 1-3 people, > > Andrey> just knowing that this is a good idea is not enough. > > > > Perhaps sharing reasons why people don't do this would help us > > understand what a change might look like. > > > > For myself, my reasons for not being involved in RFS have varied across > > my Debian Journey. > > > > 1) Right now, I am behind on Debian work I have committed to, and I'd > > rather get that done than work on picking up new obligations. > > > > 2) Sponsoring a package if you do it right is a lot of work. If it is > > going through new, it's really important that you review all the > > copyright and license statements and make a determination about whether > > it fits the DFSG. I firmly believe that work needs to be done by a DD > > and should never be outsourced to someone who hasn't been trusted to do > > that work by the project. > > I hate doing that. tooling has made it easier over the years. > > > > 3) I think it is important to grab a pristine copy of the upstream > > 3) I think it's important to make sure that all changes are documented. > > If not in Debian, that means going back to the upstream, grabbing > > pristine upstream sources and diffing what is proposed at the upstream > > source for Debian against those. If it is already in Debian, it means > > effectively doing a debdiff between the version already in Debian and > > the version proposed. The tooling for all that isn't great, and used to > > be really bad. > > > > 4) At least back in the day there was an expectation that if you > > sponsored a package you would test it. So it would involve learning how > > to use the software and then testing to make sure it worked. Perhaps we > > care about this less today. > > > > 5) At least back in the day there was an expectation that if you > > sponsored an upload you would be available to sponsor any fixes to bugs > > introduced in the upload. > > For me, promising future availability was a big ask. > > > > 6) I felt there was an obligation to work with the person you were > > sponsoring to get the package into shape. Sometimes that was a long > > process. If they didn't have good email turn-around time I got into the > > situation above where I had inadvertantly made a longer term commitment > > than I was ready for. > > > > There are many points in my Debian journey where if I could have made a > > 2-3 hour commitment to sponsoring packages without taking on future > > responsibilities at future times, I would have been willing to do so. > > (Not today unfortunately). > > As I understand it there never has been (and is not today) a responsible > > way to sponsor without at least taking on some chance of future > > commitments. > > > > These are valid concerns. I think the tooling from Phil should help > with your point 2 and 3. For 4-6, I personally never expect the same DD > would provide long-term support after sponsoring. Maybe making that > clear on the Debian wiki[1] would help with aligning the expectations. > > [1] https://wiki.debian.org/DebianMentorsFaq > Morning Xiyue and all, Xiyue mentions tooling after Sam raised an issue. Xiyue, Many thanks for entering this conversation as I feel you are an ideal person (through our many interactions) to detail/discuss what you feel mentors is, is not, what is expected of the submitter and the reviewer; and what mentors should be. As a none DD I do basic build testing and validation of packages and their files in-order to bring them up to a minimum standard for a DD to then look at. This is to encourage Debian Developers to review and sponsor packages in mentors. A mentors package submission at the stage tagged 'confirmed' on the RFS bug means it is decent shape and be less of a strain on a DD's time. I use the sbuild using unshare[1] setup which can also run lintian, piuparts and autopkgtest test when configured. pbuilder I have h
