Re: wiki.d.o on a git-backed engine
Hi Steve and others with interest in wiki.debian.org! I wanted to follow up on this thread and advertise that Steve is running a BoF session about the wiki future at DebConf: https://debconf25.debconf.org/talks/146-debian-wiki-bof/ I've added some of the people who participated in https://salsa.debian.org/debian/grow-your-ideas/-/issues/2 and who's email address I have easily available as CC here, and I've posted a note about this BoF in that issue. I have also added some research about potential Markdown+git software in https://salsa.debian.org/debian/grow-your-ideas/-/issues/2#note_288815. Maybe you Steve could invite people to the BoF in advance to ensure there is good attendance at least by the people who have publicly committed they would be willing to work on upgrading/migrating the wiki? I probably won't have bandwidth to help with the software part, but feel free to add me as co-organizer in the BoF if you want further help with the BoF session itself.
Re: Interesting learnings about Guix contributor dynamics that apply to Debian?
Hello, if I wanted to rethink the bug tracking i would seriously consider storing the bug in git maybe with something like this i just discovered https://github.com/git-bug/git-bug/tree/master The big advantage is to unlock the tracking from any forge and there is some kind of logic to attach bug to branch (i don't know if they do this) But there seems to have at least Bridges with GitHub and GitLab Regards Christian Le 24/05/2025 à 09:51, Pirate Praveen a écrit : If we're at that point of "considering" having a second system to the BTS (or to augment) what would be wrong with using Gitlab issues on Salsa? I've done little research on the matter besides a quick search [1], but presumably the BTS software could be modified to build a bridge with the Gitlab issues? Then perhaps maintainers for packages that want to opt in could set a flag to have the BTS forward everything from BTS to Salsa for their packages. [1] https://docs.gitlab.com/administration/incoming_email/ Gitlab has a fully email based Service Desk feature as well, which we use at work for customer support.
Re: Interesting learnings about Guix contributor dynamics that apply to Debian?
Quoting Christian BAYLE (2025-05-24 22:27:41) > Hello, > > if I wanted to rethink the bug tracking > i would seriously consider storing the bug in git > > maybe with something like this i just discovered > https://github.com/git-bug/git-bug/tree/master > > The big advantage is to unlock the tracking from any forge > and there is some kind of logic to attach bug to branch (i don't know if > they do this) > But there seems to have at least Bridges with GitHub and GitLab Radicle provides a decentralized layer on top of git: https://radicle.xyz/ Also adds an issue tracker. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Interesting learnings about Guix contributor dynamics that apply to Debian?
Le Wed, May 21, 2025 at 08:48:00AM -0700, Otto Kekäläinen a écrit : > Hi! > > I came across this post https://issues.guix.gnu.org/76503 in Guix > where they discuss how to improve the contributor experience, and in > particular what technical changes they are doing. > > Guix is interesting as they use a clone of Debbugs as their bug > tracker at https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix. Yes, but there is issue was not with Debbugs as a bug tracking system, but Debbugs as a merge-request tracker, something that Debbugs was never intended to be, and is available in Salsa already. Also they used extra scripts that were not properly interfaced with the BTS, which leads to extra problem. So I do not think this applies to Debian. Cheers, -- Bill. Imagine a large red swirl here.
Re: Interesting learnings about Guix contributor dynamics that apply to Debian?
On 24/05/2025 12:46 am, Mario Limonciello wrote: On 5/23/25 11:59, Andrew M.A. Cater wrote: On Fri, May 23, 2025 at 10:00:22AM -0400, Roberto C. Sánchez wrote: On Fri, May 23, 2025 at 10:59:47AM +0200, Marc Haber wrote: On Fri, 23 May 2025 08:57:36 +0100, "Jonathan Dowland" wrote: On Thu May 22, 2025 at 4:56 PM BST, Ahmad Khalifa wrote: It's alive, not sure if sponsored by Red Hat/Mozilla, but both use it (and Kernel, KDE, the list goes on). Red Hat have transitioned almost entirely to JIRA. Thankfully that's not an option for us (not dfsg free). But it could be an option. If Atlassian offered the Debian project free (gratis) use of their platform (especially if they handle the administration), why wouldn't we accept? Three points: Having used Jira - I think I'd rather stick hot needles in my eyes. Atlassian are *EXTREMELY* unlikely to offer anyone gratis use of their software. Do remember why we have Git to replace Bitkeeper - free gifts can get withdrawn. Just my €0.02 If we're at that point of "considering" having a second system to the BTS (or to augment) what would be wrong with using Gitlab issues on Salsa? I've done little research on the matter besides a quick search [1], but presumably the BTS software could be modified to build a bridge with the Gitlab issues? Then perhaps maintainers for packages that want to opt in could set a flag to have the BTS forward everything from BTS to Salsa for their packages. [1] https://docs.gitlab.com/administration/incoming_email/ Gitlab has a fully email based Service Desk feature as well, which we use at work for customer support. https://docs.gitlab.com/user/project/service_desk/using_service_desk/ OpenPGP_0x8F53E0193B294B75.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Inquiry About Contributing a COM Mouse Driver to the Community
bjorn@miraculix:~$ apt show inputattach Package: inputattach Version: 1:1.8.1-1 Priority: optional Section: utils Source: joystick Maintainer: Stephen Kitt Installed-Size: 73.7 kB Depends: libc6 (>= 2.15), libsystemd0 Homepage: https://sourceforge.net/projects/linuxconsole/ Tag: hardware::input, hardware::input:joystick, hardware::input:keyboard, hardware::input:mouse, implemented-in::c, interface::commandline, interface::daemon, role::program Download-Size: 29.1 kB APT-Sources: http://deb.debian.org/debian bookworm/main amd64 Packages Description: utility to connect serial-attached peripherals to the input subsystem inputattach connects legacy serial-attached input peripherals to the input subsystem: keyboards, mice, joysticks, touch-screens... . Amongst other things this allows legacy mice to be accessed via the /dev/input/mice multiplexer. . Supported devices include: * Serial-attached keyboards including the Apple Newton keyboard, DEC LK201 / LK401 keyboards, the Stowaway keyboard, Sun type 4 and 5 keyboards, standard PS/2 keyboards with a serial adapter * Serial mice using Genius, Logitech, Microsoft or Mouse Systems protocols * Serial-attached touchscreens including those manufactured by 3M, ELO, Fujitsu, Penmount, Touchright, Touchwindow * Serial-attached joysticks including I-Force, SpaceBall, SpaceOrb, Gravis Stinger, WingMan Warrior * The Handykey Twiddler used as a joystick or a chording keyboard
