Re: Who is taking care of storm.debian.net?
On 2024/08/12 10:57, Carsten Schoenert wrote: Knows someone who runs this service so the certificate could get renewed? O.k., I was unable to find the dedicated wiki page for this service. :-( https://wiki.debian.org/Services/storm.debian.net I contacted Laura and Kyle. Ah yes, Kyle mentioned last week that a manual update is necessary there because it uses a wildcard letsencrypt key, which currently needs some manual intervention on that instance. I'll poke him on IRC too as a reminder. -Jonathan
Bug#1081066: ITP: libjs-htmx -- framework for performing various javascript actions from html
Package: wnpp Severity: wishlist Owner: Jonathan Carter X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libjs-htmx Version : 2.0.2 Upstream Contact: bigskysoftware (https://github.com/bigskysoftware * URL : https://htmx.org * License : BSD-0-Clause Programming Lang: JavaScript Description : framework for performing various javascript actions from html htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext. htmx is tiny, and has no dependencies. This installs the htmx binary to: /usr/share/javascript/htmx/htmx.min.js.gz
Re: Gnome classic mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/2012 08:07, Cyril Brulebois wrote: > Josselin Mouette (11/09/2012): >> Just because these people are noisy doesn’t make them numerous. >> >> Furthermore, Debian (and Ubuntu too IIRC) makes “GNOME classic” >> available right from the login manager, with the default installation. >> Not considering gnome-panel 3.x a continuation of the existing >> environment is purely bad faith. > > Speaking of which, Ubuntu (according to Jeremy) disabled the “booh, bad > luck, gnome classic mode” warning at first login. Do we want to do the > same? As I said on IRC, I'm probably biased since I do quite a lot of > testing. But you guys will probably decide what's best. I've been doing some LTSP testing on Wheezy and it's incredibly annoying when every user has to get a warning that they're desktop is broken when using fallback on a thin client is actually a completely reasonable and normal thing to do. Sure, the local administrator could disable it, but it's nice having sane defaults. - -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBPQGgACgkQorfMNyt6sO/SawCeNewju0hZExEBkhrkkfX/mVaU 16gAn2b42oPLOiq2aI8I5UnkiqRuI0aL =AhIG -END PGP SIGNATURE- -- 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/504f406f.6010...@ubuntu.com
Re: Gnome classic mode
On 11/09/2012 11:32, Josselin Mouette wrote: > Le mardi 11 septembre 2012 à 15:58 +0100, Ian Jackson a écrit : >> I'm not sure of my actual opinion about the warning because I'm not >> sure of the technical background. But I think Debian should try to be >> remain good and useable even on machines with poor or no 3D graphics >> support, and not be seduced by bling and try to compete with the likes >> of Apple. There are many more people in the world whose computers >> don't have the latest shinies. > > Yes, and this is why we ship and support “GNOME 3 classic” fully. It > works for people with low-end machines, for those who want to keep their > 3D power available for serious sh*t, and for nostalgics of GNOME 2. > > Can we move on now? I don’t even understand how a *one-time warning* > explaining a user that his desktop will look different from what he > might obtain on another Debian machine can even be a serious topic of > discussion for debian-devel. I think I can explain it to you. Many people who install Debian for the first time do now know what Gnome is (or even Gnome Classic), nor do they realise that they could or choose something else from the session menu if they don't want to see a message telling them that something is broken. It's way more likely that someone who explicitly wants gnome shell but gets a gnome-fallback session will notice that they need to do something about it. -Jonathan -- 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/504f6813.3080...@ubuntu.com
Bug#921519: ITP: mozilla-deepspeech -- TensorFlow implementation of Baidu's DeepSpeech architecture
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: mozilla-deepspeech Version : 0.5.0-alpha.1 Upstream Author : Mozilla * URL : https://github.com/mozilla/DeepSpeech * License : MPL-2.0 Programming Lang: Python Description : TensorFlow implementation of Baidu's DeepSpeech architecture Project DeepSpeech is an open source Speech-To-Text engine, using a model trained by machine learning techniques, based on Baidu's Deep Speech research paper. Project DeepSpeech uses Google's TensorFlow project to make the implementation easier. I plan to main this package on the Debian team on salsa.debian.org, and intend on using this in future projects that will be packaged in Debian.
Bug#925518: ITP: gnome-shell-extension-draw-on-your-screen -- draw and write on your screen, then save your beautiful work by taking a screenshot
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-draw-on-your-screen Version : 3 Upstream Author : abakkk * URL : https://framagit.org/abakkk/DrawOnYourScreen * License : GPLv2 Programming Lang: javascript Description : draw and write on your screen, then save your beautiful work by taking a screenshot Draw and write on your screen, then save your beautiful work by taking a screenshot. Features: - Basic shapes (rectangle, circle, ellipse, line, curve, text, free) - Smooth stroke - Drawing on desktop and persistence - Multi-monitor support - Export to SVG I plan to maintain this package in the shell-extensions repository as part of the gnome-team on salsa.debian.org.
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On 2019/04/07 15:26, Mo Zhou wrote: > 3. Allows us to accept potential contributors friendly, and possibly > form a new user community. The high quality standard of Debian may scare > some potential contributors away. In the informal packaging area, it's > easier for people to contribute. Look at AUR and Archlinux Trusted Users > as example. Of course, we can promote high quality creations from users > into debian archive. > > Just a few of my naive thoughts. If this idea came true, I'll > denfinitely be able to continue with TensorFlow and PyTorch packaging, > at an significantly lower cost. I'm also happy to throw some of my > low-popcon packages to this area, so I can focus on more valuable ones. > This idea really excites me. Can we implement it? +1, it's a good idea and I've thought of it before as well. Reading some of the initial replies to your post, it seems like people don't entirely understand what you mean by an AUR-like service. This would definitely be different than PPAs (in the launchpad sense) or bikesheds (which is still a terrible name for all the confusion it causes). Have you put any thought in possible implementation yet? I don't think it's a good idea to devise any kind of new source packages. It's probably not even necessary to use existing source packages. If you'd have the standard debian packaging for such an AUR^W... DUR? in a git repository (maybe like salsa.debian.org/dur/*) with a standardised git workflow for these, then it should be rather trivial to implement with a helper script that fetches the upstream source and just builds that package locally. So I think from a technical point of view, implementing something like AUR for Debian doesn't seem so hard. It can also act as a nice gateway to proper Debian development. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?
On 2019/04/07 17:59, Adam Borowski wrote: > +1. With GNOME not working even on some amd64 machines, it's not fit to be > the default. Technical reasons aside, the UI is non-ergonomic and > counter-intuitive, has broken systray, and suffers from CSD. > > Once the black screen/crash problem is fixed, you may consider making > Wayland and/or GNOME the default again, but for Buster, that's a pretty bad > idea. You're kind of hijacking the thread there. Not sure if it's by accident though, the original question was about dropping wayland by default in favour of going back to xorg, not about dropping Gnome for something else. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: duprkit User Repository
On 2019/04/08 12:37, Ondřej Surý wrote: > I very much dislike the idea of inventing yet another format. Your energy > would be much better used if you rather added support for external tarballs > to the packaging tools (with hashes, etc.) and turn this into DEP. > > Debian is not Fedora/Arch/... and whacking the debian/ into a single file > doesn’t feel like something that would help anything at all. Just require git > (as AUR4 does). Indeed. I can see why Mo would want to put it in one file, but the Debian package format can work just fine if you work from git repositories as you suggest, plus if it looks like a more or less usual debian source package, then it's a smaller leap to turn it into a real package that can graduate into making its way into Debian. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 2019/04/16 21:51, Thomas Goirand wrote: > I'm not sure if I should say thanks, or just hide myself behind the > wall, considering how much work there would be to fix all of these > packages that I need to fix... :/ Heh, that's exactly why these graphs are so great! Rome wasn't built in a day either so I don't think anyone should feel stressed about it, and I think when your packages are team maintained it's a good idea to post to the team list and ask for some help on those fixes. (I'm speaking in the general and not just to you, and I think you're saying that slightly tongue-in-cheek too :) ) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Bits from /me: Difficulties in Deep Learning Framework Packaging
Hi Chris On 2019/04/17 13:08, Chris Lamb wrote: >> How many percent of the paid GSoC and Outreachy student workers >> continue unpaid afterwards and become a DM or DD? >> >> My impression is that GSoC does not have a high quota, >> and Outreachy is a complete failure. > > Curious that you have that perception. I don't have hard data but I > can immediately think of at least five folks. > > And that's not counting myself. Well, the Outreachy site is running, and since they have plans ahead they clearly seem to be continuing their work. So if Adrian wants to call it a complete failure then the burden lies on him to justify that statement, and not on everyone else to invalidate it. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Tell me about your salsa experience
On 2019/04/22 14:36, W. Martin Borgert wrote: > On 2019-04-22 09:55, Dmitry Bogatov wrote: >> Alioth did not get in my way. > > Salsa does not get into my way neither. I barely use the web > frontend, I do not use the issue tracker at all, nor merge > requests. Works fine for me! Same here, with Alioth, I often didn't figure out what I needed to do. I spent large amount of time trying to do something before I just ended up giving up. In GitLab, even when I'm not sure where a setting or button is it at least doesn't take long to figure out where to do it. I think Salsa is the single best thing to have happened in Debian in recent years. It's definitely something that reduces the barrier of entry to the Debian project, and I agree with recent sentiments expressed on the debian-vote list that we should standardise on salsa completely. That will pave the way for more ambitious ideas that are worth while like standardising on a git-based source package, which right now seems like a bit much to chew off in one go. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 2019/04/22 20:00, Samuel Thibault wrote: > So I could produce some hurd CD images with the archive from this > week-end. Aurélien injected the hurd-i386 archive to debian-ports, and > we got the buildds running. Various scripts will start breaking but at > least package building will continue like before. Perhaps I'll have time > to fix the CD image building scripts before the Buster release, to make > more recent image builds, but as I said I can't promise anything. That's fantastic news, is that image somewhere public where we can download it? -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Tell me about your salsa experience
On 2019/04/22 22:04, Scott Kitterman wrote: >> Same here, with Alioth, I often didn't figure out what I needed to do. I >> spent large amount of time trying to do something before I just ended up >> giving up. In GitLab, even when I'm not sure where a setting or button >> is it at least doesn't take long to figure out where to do it. I think >> Salsa is the single best thing to have happened in Debian in recent >> years. It's definitely something that reduces the barrier of entry to >> the Debian project, and I agree with recent sentiments expressed on the >> debian-vote list that we should standardise on salsa completely. That >> will pave the way for more ambitious ideas that are worth while like >> standardising on a git-based source package, which right now seems like >> a bit much to chew off in one go. > > Even assuming it's a good idea at all, which I don't think one should assume. Sure, the jury's still out on that one :) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Preferred git branch structure when upstream moves from tarballs to git
On 2019/05/08 13:23, Holger Levsen wrote: >> You should use dgit for the benefit of users. See my other mail which >> answers why Vcs-Git and debcheckout is not enough. > > could you be so kind and provide a pointer, this thread is rather long > already? (Maybe this is also worth an FAQ entry somewhere..) I'd like to second that request, I mean to go through this thread again when I have some free moments, but a FAQ would help a lot to assimilate all this information. (I'm in a similar boat to Holger with my experience to gbp, I tried going through the documentation on the wiki a few times and just got frustrated. I just use packaging and Vcs-fields and tags and nothing fancier than that, which works for the few dozen packages I have and I think the workflow is trivial enough so that downstream consumers wouldn't have any problem whatsoever figuring out how to make use of it, but I suppose as that list grows it will become important to have worflows that scale up a bit more.) > thanks. (also for the work and thoughts you put into dgit!) Ditto. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Some questions about DD status and salsa
On 2019/05/28 01:05, MENGUAL Jean-Philippe wrote: > I am happy with being now a non-uploading DD. And I dont know where to > ask, sorry for the noise. > > For non-uploading DD, is a salsa account created? I tried to auth with > it, but not possible, then to reset the passwd, but I dont rceive mail > to do it on @debian.org. Our nomenclature is a bit confusing on that one. In reality, a DD and a none-uploading DD are very similar, the significant difference is that a none-uploading DD doesn't have upload rights to the debian archive. Both are full project members that represent the project and can vote in the elections. People who aren't DDs can sign up for a guest account on salsa using: https://signup.salsa.debian.org/ More information on https://wiki.debian.org/Salsa/Doc -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: ZFS in Buster
Hi Dan On 2019/05/28 18:43, Dan wrote: > ZFS 0.8 has been released with lots of improvements, notably encryption. Yep, it's an exciting feature. > Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0 > that prevents ZFS from using SIMD. The result is that ZFS won't be > usable in Buster. See the following issue > https://github.com/zfsonlinux/zfs/issues/8793 Buster ships zfs-dkms version 0.7.12-2 though, which works just fine on buster. > NixOS reverted that particular commit: > https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop > > Debian is the "Universal Operating System" and gives the user the > option to choose. It provides "vim and emacs", "Gnome and KDE", > "Linux, Hurd, KfreeBSD, etc.". I think that Debian should also provide > the option to use ZFS with encryption. Debian does offer that, ZFS runs fine on LUKS, I use that all the time and it works just fine on buster. Misattributing the intent behind the "Universal Operating System" will never get you anywhere if you try to make a point in Debian. I suggest you not try to abuse it like that. > Would it be possible to provide an alternative patched linux kernel > that works with ZFS? I'm not making any kind of judgment call on this, I'm not on the kernel team, but it's kind of late in the buster cycle to test a patch in the kernel for a regression that doesn't manifest in buster, for a version of software that isn't packaged in buster. My guess is that it's very possible for bookworm, and also that by the time bookworm is released the upstreams would've come to a solution. > The ZFS developers proposed the Linux developers to rewrite the whole > ZFS code and use GPL, but surprisingly the linux developers didn't > accept. See below: > https://github.com/zfsonlinux/zfs/issues/8314 That issue is closed because as the commenters rightly point out, dual-licensing OpenZFS from cddl to cddl+gpl is impossible without the permission of the original copyright owners (who clearly doesn't want to do that). -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Buster/XFCE unlock screen is blank
Hey Adam On 2019/06/01 18:29, Adam Borowski wrote: > At the time of the xscreensaver debacle, there was no sane alternative > (candidates depended on 80% of GNOME, offered no feedback nor discoverable > controls to the user, etc). There _is_ a wonderful alternative now: > xfce4-screensaver, which seems to work perfectly[2] -- but alas, it's not in > Buster. When I first filed the ITP for xfce4-screensaver I got some pushback (of which I don't all disagree with). After some discussion and digging in deeper into the issue the Debian Xfce team agreed that it can be maintained as part of the Xfce team. At freeze time it was still in alpha and had some show-stopper issues, we decided that it would be best for everyone not to have that in buster at that time. There are also still some integration issues that are still outstanding. Overall it just wasn't ready for buster in time, but I'll be happy to work on a backport for buster when some of the last few issues have been resolved. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: @debian.org mail
On 2019/06/03 10:40, Daniel Lange wrote: > Mail submitted from DD's private IPs frequently gets flagged as spam > regardless of content by all three big players and - if submitted via > IPv6 - refused directly by Google. Microsoft and Yahoo still run their > MXs IPv4 only. But we can expect a similar policy once they add IPv6 > SMTPs at scale. And they won't warn us up-front. > The missing SPF record mentioned above means there is a lot of spam > circulating with @debian.org fake senders and obviously our open > submission policy on many mailing-lists and @debian.org technical > addresses also fan out quite some spam. So we're not the best netizens > we could be. > > To do better, we should really offer SMTP submission/IMAP services for > @debian.org as soon as possible and - after a grace period - publish a > mx -all SPF record. I think you make a good case for offering SMTP, and that's very beneficial to a lot of people. IMAP is a whole nother case in terms of the kind of sustained work it requires and I'm unconvinced that it would be at all worth it. I have little sympathy for people who say "but I use gmail", there's literally a 1000 better mail services on the Internet that they could use without having to set up their own, and the good reasons not to use google services keep rapidly piling up. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Debian, so ugly and unwieldy!
Hey Adam On 2019/06/07 17:24, Adam Borowski wrote:> I'll concentrate at XFCE I proposed most of what you said in this email (and some more) in the #debian-xfce channel a few months ago. They were actually surprisingly open to having such config changes and suggested I prepare a proposal, I was going to put something together but ran out of time before buster freeze happened, but they're certainly more open to this than the gnome team was in the past (and I'm hoping that has changed too over the years). > * the default icon theme is fugly > > => Default to eg. faenza? They specifically disliked faenza and obsidian, although I think obsidian is a bit nicer. Our default Xfce icon theme is broken (it doesn't have a run menu icon that is missing by default that sticks out like a big eye-sore) so I don't think it would take *too* much convincing to switch to even those because at this point nearly anything is better than what we have already. > In general: could we please do something to appearance beyond choosing a > wallpaper once a release? I'm a code hacker not a theme maker, so I see > this only once it gets in my way -- but text readability does matter. I meant to create a session for exactly this at DebConf but I'm leading/co-leading a handful of sessions already and don't want to overload. I do think we need a proper discussion around: * theming * our process for selecting wallpapers (particularly the timing, it really doesn't have to be in a latter part of the release cycle) * choosing defaults that is appealing and has sane defaults, there are limits to how far we can push this, gtk3 has horrible (and technically non-existant) theming support with defaults that kind of suck for most people so there's some technical limits on what's possible there but improvements are certainly possible I'll be happy to take that forward kicking it off in a #debian-meeting meeting post-debconf if no one else is interested. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: speeding up installs
On 2019/06/08 19:36, Simon McVittie wrote: > If the pre-prepared installation image is in a suitable format (for > example an unpacked tree, squashfs or OSTree, but not a tarball or an > OCI image), then there's no reason it couldn't also be bootable as a > stateless live system. It might be useful to some that we'll have a 'standard' image for Debian Live Buster. This is a base image with Debian standard that doesn't contain any desktop environment. It ships with d-i with a module that just unsquashes the squashfs image (just like the other live images), so it's a really quick and convenient way to get a Debian system installed on bare metal. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: speeding up installs
On 2019/06/08 21:43, Adam Borowski wrote: > I like this. The d-i is nothing but a glorified live image already. On > every not completely non-eventful install I find myself wishing this live > system wasn't crippled for space reasons. This crippling was intentional -- > d-i was designed in the days of boot floppies when a couple of megabytes was > a lot -- but today, no one gives a damn about ten or fifty megs extra to > have a real shell, less, man pages and what not. I did some tests before, using squashfs on an entire image is more efficient than using udebs. If you install all of d-i's dependencies in a chroot and squashfs it with xz, the resulting system ends up being smaller (by a small margin but still), than the current d-i images. Unfortunately, it's not trivial to just build normal debs of all the d-i modules and install them in a normal live system and use them like that. In a pinch, Calamares can also run from a framebuffer which might be nice for some environments but the version in buster doesn't support advanced partitioning yet, things like using RAID or ZFS. > So if you took current d-i and planted it into a regular live image, that'd > be great. It probably has too much functionality to be easily rewriteable, > but changing the base system under it sounds like a good idea. Yeah there's been a lot of discussions about this, it needs someone to spend a significant amount of time working with the d-i maintainers to make that an option, which involves going through a whole lot of shell scripts that isn't all that debianny anymore and modernising them. > On the other hand, do we have a list of what d-i can do that Calamares or > whatever you are using, can't? Calamares doesn't: * Have a cli installer (which is still useful and probably will be for a long time) (although as I mentioned above, it can run on a framebuffer, which is kind of cool). * Install on RAID or ZFS setups or SAN devices, although kpmcore, it's partitioning library, has recently been nearly rewritten and now has some RAID support. * Have any kind of pre-seed/kickstart or method to preconfigur it, although I've been in discussion with upstream and they are interested in implementing it. kpmcore has also dropped dependencies on all the kde/qt stuff. I'm often tempted to create another installer based on kpmcore becuase besides partitioning, most of the rest is reasonably simple. Calamares has some good ideas (I like how super simple it is to create extensions for it, which seems hard in d-i), but personally I'm not a fan of it being written in C++, developers spend way too much time trying to fix crashes which would better be spent adding new features. I also don't like its current dependency on Qt either. Ideally I think an installer should be more of a library than something that's tied to a front end, and then the world can go ahead and smack on any UI (or none at all) to it that they like. I think that would be even better than the script + configure UI approach that things like Propellor and Subiquity does. Calamares does a pretty good job of providing a distro-agnostic installer that works for the large majority of desktop end-users out there, and it gets a lot of things right that others don't, but I think if that concept could just go a little bit more further it could be possible to have a great installer that works for basically all the popular linux (and non-linux) distributions and fix all the problems with the current ones. Personally I don't think Calamares will ever be able to replace d-i, I think eventually something will come along that will replace both. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Programs contain ads - acceptable for packaging for Debian?
On 2019/06/20 10:49, W. Martin Borgert wrote: > Otherwise, I would leave it to the package maintainer, > whether they like to disable the ad or not, > but that's more a question for debian-le...@lists.debian.org. It seems clear-cut enough that it doesn't really need advice from debian-legal. If it's free software then a maintainer is free to patch out any behaviour of the app that's intrusive or otherwise undesirable. If the license of the software doesn't allow that, then it's highly likely that the software doesn't belong in main. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Seeking advice re: CVE-2019-13179 (insecure permissions for initramfs)
Hi I need some help regarding a security issue that surfaced yesterday that affects buster. Using the Calamares installer and full-disk encryption, sensitive information is stored in the initramfs, which is world readable: https://github.com/calamares/calamares/issues/1191 I just took a quick glance through the update-initramfs man pages and couldn't find anything specific for setting the initramfs permissions. Any advice on how to approach that? I'd usually do some diving and figure it out but due to the time-sensitive nature I don't want to rush something by myself. I'm wondering if it might be reasonable to make the whole /boot only root-accessible, which *would* fix this problem but not sure if it might cause additional problems for someone. AFAIK this isn't currently relevant in d-i since grub2 doesn't supports luks2 yet (which d-i now uses by default), but when grub2 does support luks2 this will be equally as much as an issue for d-i images with full disk encryption. weasel has also pointed out to me that the open permissions may also be a problem for dropbear users who's initramfs host private key can easily be spoofed by anyone who can read the initramfs, so I do believe that this is worth some attention right now. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Seeking advice re: CVE-2019-13179 (insecure permissions for initramfs)
Hi Roger On 2019/07/03 12:10, Roger Shimizu wrote: > According to latest LUKS for rootfs guide [1], you can append > "UMASK=0077" to /etc/initramfs-tools/initramfs.conf > > [1] https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html Ah great, having a "/etc/initramfs-tools/conf.d/initramfs-permissions" that contains "UMASK=0077" and running "update-initramfs -u" does fix that for me locally, I think it should be reasonable to add that to the calamares-settings package for Debian. Does anyone know of a reason why this can't be universally a default in Debian? Is there a use case where a regular user needs read access to the initramfs? My Fedora friends say dracut has defaulted to the more secure permissions for the last 7 years and that it hasn't been an issue there yet. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Bits from /me: Forgetting the Simplified Representation for Debian Packaging?
Hey Mo On 2019/07/23 04:52, Mo Zhou wrote: > Sorry for a series of failures, including > the deep learning one. I'm already used to failures. Nothing to apologize for, you can't have innovation without experimentation, and we keep hearing that people want more of that in Debian. So, thanks for your experiments and sharing your experiences with them so diligently so that we can collectively learn new things from them. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: duplicate popularity-contest ID
Hey Yao and Bill On 2019/08/05 14:31, "Yao Wei (魏銘廷)" wrote: >> I am not quite sure what it is the reason for this problem. >> Maybe people use prebuild system images with a pregenerated >> /etc/popularity-contest.conf file (instead of being generated >> by popcon postinst). > > Could this be caused by Debian-live installer based on Calamares? Very unlikely, we don't install popularity-contest on live media and it's not added/removed at any point by Calamares, so essentially when you install popularity-contest on a calamares-live-installed system, it's basically the same as installing it on any other type of Debian system that didn't have it before. I also just double-checked whether any /etc/popularity-contest.conf exists on debian live images, and can confirm that it doesn't. Bill, it might also be a good idea to ask on the debian-derivatives mailing list, perhaps someone there might know. I don't suppose there's any server logs with IPs that you can use to deduce from which country it's coming from? -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))
On 2018/06/01 19:22, Andrej Shadura wrote: >> On 2018-05-31 12:33 PM, Chris Lamb wrote: >>> [11] https://wiki.debian.org/MemberBenefits >> Oh, this reminds me of something. >> >> Has anyone gotten replies to their requests sent to >> debian-st...@collabora.com for the Steam subscriptions mentioned in the >> MemberBenefits page? >> >> I think that I have sent two mails in the past 3 years but have gotten >> no responses. >> >> Should we remove this benefit from the wiki page? Or do we have someone >> to contact about it? > The benefit should still be valid. The person responsible for it is > already looking into it, expect a reply shortly ;) I also still haven't heard back despite having emailed a few times over the last 2 years, it's probably time to remove it until we hear back from someone who actually administers this. Perhaps someone at Collabora could also check there if the email alias is still going somewhere? It's a pity because it would be nice to have access to games that use gamemode[1] because currently I mostly rely on users' feedback for testing (which is getting better now that more people use it), but I don't have a particular interest in buying games like the new Tomb Raider just to test that it invokes gamemode automatically properly, -Jonathan [1] https://github.com/FeralInteractive/gamemode -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))
On 2019/08/06 09:46, Andrej Shadura wrote: > I’m really sorry if nobody did come back to you with this, apparently > your request fell through the cracks. Thanks! Just received your off-list email with the details. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Bug#934042: ITP: gnome-shell-extension-gamemode -- show the current status of gamemode in the gnome-shell panel
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-gamemode Version : 1 Upstream Author : Christian Kellner * URL : https://github.com/gicmo/gamemode-extension * License : LGPL-2.1 Programming Lang: JavaScript Description : show the current status of gamemode in the gnome-shell panel Gamemode is a software package to "optimize Linux system performance on demand". This GNOME Shell extension will show the current status of Gamemode. For it to work, GameMode 1.4 or greater is required. This package will be maintained as part of the Gnome team.
Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"
On 2019/08/08 23:12, Sven Joachim wrote: >> The man page for machine-id says: >> >> This ID uniquely identifies the host. It should be considered >> "confidential", and must not be exposed in untrusted environments, in >> particular on the network. >> >> Why is the file mode 0666? > 0644, not 0666. 444 even (original post gave me a fright so I checked). -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Git Packaging Round 1: Hopefully Easy Stuff
On 2019/08/14 20:02, Sam Hartman wrote: > If you're going to set up a repository for Debian packaging on Salsa, > you need to either: > > 1) turn off merge requests That would be quite horrible IMHO, this is the de facto method that young (let's say under 35 years old) developers use to submit improvements to other projects. We have all the infrastructure and tools conveniently in place to accommodate this, it seems suboptimal to treat MRs as a second class citizen. > 2) Monitor them and process them. > > I don't want to get into how frequently you look at merge requests just > as I don't want to get into how responsive you need to be to the BTS. > But I hope we can agree that if you're going to have merge requests > enabled that they cannot go into a black hole. > > I think the question of whether people should use merge requests is more > complex. Sean pointed out some reasons why we might prefer the BTS. > And yet it's clear that many people do find merge requests useful. The Debian QA DDPO pages will show you whether you have MRs on the same page where you see how many open bugs, RC bugs, lintian errors, etc you have. This makes it super easy to notice MRs when doing routine checks of your general package health overview. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Git Packaging Round 1: Hopefully Easy Stuff
On 2019/08/14 20:36, Sam Hartman wrote: > And yet, consider the following cases: > > * You are simply mirroring from somewhere else to Salsa > > * You buy Sean's argument that MRs aren't stable enough to capture > discussion long-term and/or we're unlikely to port forward the > database of merge requests if we move away from Gitlab. Ah yes, good points. -Jonathan
Bug#935178: ITP: bcachefs-tools -- bcachefs userspace tools
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: bcachefs-tools Version : 0.1.0 Upstream Author : Kent Overstreet * URL : https://evilpiepirate.org/git/bcachefs-tools.git * License : GPL-2+ Programming Lang: C Description : bcachefs userspace tools Note: this is very different from bcache-tools, which ads a bcache device for existing filesystems. bcachefs is a new filesystem that aims to be included in the mainline kernel (https://lkml.org/lkml/2019/6/10/762). Userspace tools for bcachefs, a modern copy on write, checksumming, multi device filesystem. Note: The current Debian kernels do not come with bcachefs support, you will have to use your own kernel or one provided by a 3rd party that that contains bcachefs support. This package will be maintained under the debian group in salsa.
Re: Bug#939421: O: gdisk -- GPT fdisk text-mode partitioning tool
On 2019/09/05 12:05, Simon Richter wrote: > I believe this can be safely removed. The fdisk program has gained GPT > support since gdisk was written, so a separate tool is no longer needed. I'm not sure they have feature parity, I've had to help a lot of people who had strange partition layouts (hybrid MBR/GPT) that was misconfigured, often on low-end Acer and HP laptops, and very often on refurbished laptops that were re-installed (or rather, imaged) with Windows on them, and the only tool that (I know of) that could fix these to reliably dual-boot these setups with Debian is gdisk. It allows you to convert between GPT and MBR, backup/restore your current layout easily or to set up a proper hybrid system (if you need it for whatever reason, Windows doesn't like changes). AFAIK fdisk doesn't let you do all of this yet. If I'm correct and fdisk does indeed not let you do that then I'd rather maintain gdisk than have it removed from the archives since I somewhat rely on it for some of my users who have crappy^W more lower-end laptops. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: On the Removal of src:tensorflow
On 2019/09/05 05:55, Yao Wei wrote: > On Wed, Sep 04, 2019 at 07:38:11PM -0700, Mo Zhou wrote: >> I'm wondering who will read it. In the past I broadcasted some bits >> I learned to the public mailing lists and people responded, but >> nobody had ever asked me any detail about anything related. > > Recently there's ITP for DeepSpeech (#921519) based on Baidu's research > and Mozilla Common Voice project, which is depending on TensorFlow: > > https://github.com/mozilla/DeepSpeech I filed it and intend to keep it open for the foreseeable future. Based on Mo's original post in this thread, I decided that it will be better to look for alternatives to DeepSpeech (especially since all my intended use cases rely on very limited dictionaries). Things change though and the Tensorflow project might mature in a few years and the project might have better methods available for building it. > I think it is a good practice to leave a tombstone in the wiki that what > you consider may be pitfalls for packaging deep learning programs and > the problems that are specific to certain ML frameworks. > > If anyone wants to resurrect TensorFlow in Debian, then it is a good > reference to see what they would like to avoid. I think a link to Mo's mail is sufficient on the DeepSpeech ITP bug report (and related ITPs). Less is probably more when it comes to wiki pages at this point. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Bug#939421: O: gdisk -- GPT fdisk text-mode partitioning tool
On 2019/09/05 12:27, Jonathan Carter wrote: > If I'm correct and fdisk does indeed not let you do that then I'd rather > maintain gdisk than have it removed from the archives since I somewhat > rely on it for some of my users who have crappy^W more lower-end laptops. I adopted this package today. It's description wasn't very clear on what you'd use it for so I updated it to include some of its common use cases: """ GPT fdisk (aka gdisk) is a text-mode partitioning tool that provides utilities for Globally Unique Identifier (GUID) Partition Table (GPT) disks. . Features: . - Edit GUID partition table definitions - In place conversion of BSD disklabels to GPT - In place conversion of MBR to GPT - In place conversion of GPT to MBR - Create hybrid MBR/GPT layouts - Repair damaged GPT data structures - Repair damaged MBR structures - Back up GPT data to a file (and restore from file) """ Probably not perfect but it is an improvement, packaging is on salsa now so any further improvements are welcome there. https://salsa.debian.org/debian/gdisk -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
Hi Simon On 2023/05/19 17:30, Simon McVittie wrote: 1. same as in recent Ubuntu: just enough packages (mostly libraries) to configure it as a multiarch foreign architecture on an amd64 system, and run legacy Linux i386 binaries directly or legacy Windows i386 binaries via Wine 2. same as (1), plus basic utilities (coreutils, etc.) and optionally an init system, to be able to make a pure i386 container or chroot that can run on an externally-provided amd64 kernel 3. same as (2), plus kernel, bootloader and init system to be able to: (a) construct a complete bootable installation using debootstrap or similar; (b) upgrade existing i386 installations All of the above sounds reasonable, all those options acknowledge that we need some method to support a subset of packages for an architecture. It would be nice to see this extend to more than just 32bit x86. A while back someone from release team mentioned to me that they toyed with the idea of adding a new 32bit x86 architecture for Debian that's called i686 instead (and enable things that might not actually work on actual 32bit binary), so it would really just be for compatibility/containers/etc, and then dropping the entire i386 architecture completely. Not sure how viable that is in practice, but it sounds like a good idea. 4. user-facing media like debian-installer and Debian Live I think we already have broad enough consensus that we don't need this. If there's enough Debian binaries to make that happen, and a user who has a niche enough use case for that, then they should have no problem just performing a local debootstrap install themselves. -Jonathan
Constructive contributions (was: Re: 64-bit time_t transition for 32-bit archs: a proposal)
Hi Everyone It goes without saying that the Debian Code of Conduct applies to all Debian communication platforms (https://www.debian.org/code_of_conduct), but in addition to that, please try to go further when it comes to potentially long, and technical discussions that many will try to follow. Remember some good netiquette principles: - Reply below the the parts you're responding to - Snip out any parts that is not pertinent to your reply - If there's no need to repeat yourself, then don't. Once you've made your position, there is no need to reply to every mail that doesn't match yours. - If your message doesn't contribute to the discussion, please consider not sending it at all. It basically all boils down to the "Try to be concise" part in our code of conduct, but not everyone quite understands what that means. Thank you to everyone who contributes to making Debian lists more productive, informative and enjoyable to use. -Jonathan
Re: systmd-analyze security as a release goal
Hi Russell On 2023/07/03 14:37, Russell Coker wrote: Someone said on Matrix that we aren't going to have official release goals in future. One shouldn't trust everything that is read on Matrix. I suggest asking the release team for clarification, because my last understanding is that release goals still exist, it's just that the release team doesn't want to be the entity pushing it. -Jonathan
Re: xz backdoor
Hi Russ On 2024/03/29 23:38, Russ Allbery wrote: I think the big open question we need to ask now is what exactly the backdoor (or, rather, backdoors; we know there were at least two versions over time) did. Another big question for me is whether I should really still package/upload/etc from an unstable machine. It seems that it may be prudent to consider it best practice to work from stable machines where any private keys are involved. For me it's just been so convenient to use unstable because it helps track changes that affect my users by the time it hits stable and also find bugs early that I care about, but perhaps I just need to make that adjustment and find more efficient ways to track unstable (perhaps on additional machines / VMs / etc). Not sure how other DDs think about this, but I'm also curious how they will deal with this, because there's near to no filter between unstable and the outside world, and this is probably not the last time someone will try something like this. -Jonathan
Re: Validating tarballs against git repositories
On 2024/03/30 11:05, Simon Josefsson wrote: 1. Move towards allowing, and then favoring, git-tags over source tarballs > Some people have suggested this before -- and I have considered adopting that approach myself, but one thing that is often overlooked is that building from git usually increase the Build-Depends quite a lot compared to building from tarball How in the world do you jump to that conclusion? -Jonathan
Re: Validating tarballs against git repositories
Hi Sean On 2024/03/30 12:43, Sean Whitton wrote: On 2024-03-30 08:02:04, Gioele Barabucci wrote: Now it is time to take a step forward: 1. new upstream release; 2. the DD/DM merges the upstream release VCS into the Debian VCS; 3. the buildd is notified of the new release; 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source deb" and "binary deb" to unstable. This change would have three advantages: I think everyone fully agrees this is a good thing, no need to list the advantages. > It is also already fully implemented as tag2upload, and is merely as yet undeployed, for social reasons. My understanding is that DSA aren't quite comfortable with it, since it would need to archive GPG signing key (or a keypair trusted by DAK)? I did enjoy the tag2upload talk that was given earlier this year at miniDebConf Campridge: https://peertube.debian.social/w/pav68XBWdurWzfTYvDgWRM One of the things I like most about it is that it doesn't break any existing workflow or technical implementation. And it seems like something most people would reasonably want to see implemented. So I think it boils down to finding some constructive way to engage with ftpmasters to find a solution that they are content with, because without that, nothing is going to happen. I'm not 100% sure that I would classify that as a social reason, DSA/ftpmaster is careful out of necessity. Any chance we can convince both ftpmaster members and tag2upload team to join at DebConf24 in Busan so that an attempt can be made to hash this out in person? I'm not sure everyone involved will be motivated enough to join a sprint just to work on this, but it tends to work so much better when people work on problems together in person rather than emails where people want to reply thoughtfully and then end up taking weeks to do so. I think it's not so much a question of *if* the Debian would ever switch to a git-based workflow, but *when*. And tag2upload's opt-in nature provides a great bridge to that future, there's clearly been a lot of good thought put into it, and there's really no alternative that even comes close in either design or being so close to being ready for implementation. However, I think it can only happen if you get all the right people in the same room to address the remaining concerns. -Jonathan
Epoch bump for bcachefs-tools
Hi Debian Developers In January, bcachefs[1] finally made it into the mainline Linux kernel as an experimental filesystem in to Linux 6.7 In 2022 something odd happened and the versions releases were 23 and 24 (previously we had alpha versions in Debian that were just git snapshots) before reverting to 1.x.x release tags. We released those higher numbers in Debian, which means that the current version in Debian, bcachefs-tools 1.7.0, has the upstream version number of 24~really1.7.0. Since it's a filesystem (and experimental one at that), where the version number is quite important for both tools and humans alike (who might not understand the version number currently in use), I think it would be justified to bump the epoch of this package. I'm mailing debian-devel before commiting such an epoch bump, as per our versioning policy[2]. Yesterday I made an upload with the 1.7.0 version to experimental, this version uses significantly more rust code compared to the old versions. If it doesn't manifest any major issues, I'd like to upload it to unstable along with the epoch bump. -Jonathan [1] https://en.wikipedia.org/wiki/Bcachefs [2] https://www.debian.org/doc/debian-policy/ch-controlfields.html#version OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Intel SOF audio firmware packaging
Hi Mark On 2020/12/07 15:57, Mark Pearson wrote: > I did a bit of reading this weekend, and started the process. Having > created appropriate files under a debian sub-dir, and messed around a > bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of > the sof-bin git repo I end up with a .deb file that I can install and > makes audio work. Feels like progress :) That sounds like great progress! > There are plenty of warnings along the way, and it's my first time doing > this so I'm sure I'm doing all sorts of things wrong (there seems like a > lot of different options on how to do this); but I figured I have a good > starting point. I wasn't sure where to go with this next. Push it to a git repository and/or mentors.debian.net and send a link, I'd be happy to also take a look and give some pointers. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: [External] Re: Intel SOF audio firmware packaging
On 2020/12/07 18:07, Mark Pearson wrote: > I pushed what I have to https://salsa.debian.org/mpearson/sof-bin-packaging > > It's pretty basic :) Seems like you haven't committed go.sh? (and hopefully more files?) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: Disabling automatic upgrades on Sid by default?
On 2020/12/28 01:04, Sean Whitton wrote: >> I think Debian stable users should enable automatic upgrades (IIRC >> that is the case now). Debian unstable/testing users should probably >> only enable safe upgrades that don't remove packages. > > I'm pretty sure it's not default because the security team do not > consider unattended-upgrades sufficiently robust. I'm sorry for not > going ahead and verifying but I thought it should be mentioned. Gnome does, which is what M. Zhou pointed at in the original post. -Jonathan
Re: -1 (Re: Making Debian available)
On 2021/01/23 12:43, Holger Levsen wrote: > On Sat, Jan 23, 2021 at 11:14:52AM +0100, Emanuele Rocca wrote: >> Having the option to opt-out firmware during the installation procedure >> seems reasonable to me, and I don't think anyone was suggesting >> otherwise. >> >> The situation we are in today is very different though: we build a >> Defective by Design image that fails to install Debian on lots of >> computers because it does not include the firmware most WiFi cards need >> to function. If we were to make a mistake and accidentally include such >> firmware, people would be able to use what we publish on www.debian.org >> under the large "Download" button to install Debian on their Thinkpads, >> and we would consider that a problem. That's insane. > > very well said, thank you! I find myself disagreeing with both of you. Firstly, no doubt having firmware available on the media would be convienient to many users, I'm not contesting that here. But the sentiment above and in other similar messages were that the completely free images are broken for many users that might need some non-free firmware. This is simply not true. I've only ever installed using the free images, and then afterwards just install the firmware packages I actually need. On all my thinkpads this was typically just the intel wifi firmware, which is super quick and simple, on my AMD laptop I needed some amd graphics firmware which wasn't on the media, but also a very quick install and it works flawlessly, so I think implying that the free images are completely unusable for people who might need firmware is an unreasonably large stretch. I also like that I know exactly which non-free firmware packages are installed on my system. Again, I'm not saying that there shouldn't be images that contain non-free firmware, but dismissing the images that don't have firmware on as useless is harmful and misleading. -Jonathan
Re: Making Debian available, non-free promotor
On 2021/01/28 01:49, Daniel S. wrote: > The hope would be that, after collecting a 5 figure sum has been > donated, paid developers work on freeing the most common firmware(s). If that was enough to free up firmware, we'd probably have figured out a way to pay that right away without even spending time doing additional fund raising. -Jonathan
Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)
On 2021/02/10 15:16, Bjørn Mork wrote: > Adam Borowski writes: >>> As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux) >>> is, maybe it's time for a src:proper-unix-system package for those who care? >> >> Define "proper Unix"... > > The definition depends on whether you are a longhair or shorthair. If you're a proper blue-haired person, then the only proper Unix is Debian. -Jonathan
Re: Huh?? sbuild fails and pbuilder succeeds in building a Fortran-containing Python package
On 2021/02/10 23:51, Julian Gilbey wrote: > creating > build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src > compile options: '-Ibuild/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src > -I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.9 > -c' > error: [Errno 13] Permission denied Is this on a local filesystem? I had similar problems a while back when building packages over a network filesystem when the build system couldn't set specific attributes/flags/permissions/etc. -Jonathan
Re: Contributing without your real name
Hey Stephan On 2021/02/25 11:48, Stephan Lachnit wrote: > I never really thought of this, and I'm not sure how much one can > contribute to Debian without posting some kind of real name > (sorry if that is already answered somewhere). > > I'm aware that for sponsored work the name doesn't really matter, > but can one become a DM or even a DD? They would have to share their real name with DAM, and some DDs might want to see their ID when keysigning, but it is entirely possible to work in the public in Debian under a pseudonym. I think this is probably something that needs a paragraph in the nm guide. -Jonathan
Re: Statement regarding Richard Stallman's readmission to the FSF board
On 2021/03/26 21:22, Michael Shigorin wrote: > Jonathan, I hereby demand that the Debian Project gets rid > of this manipulative, insultive, divisive and libelous member. > He (them? it?) can't even stand by the rules (pro|im)posed. I'm asking both of you, and everyone else for that matter, to keep this off of debian-devel. We're freezing for release, this is debian-devel, not twitter, if you have disagreements to figure out, please do it elsewhere. No one is interested in playing police right now or baby-sitting this list, so whenever you reply to a message to this list, reply in a way that you would to your co-workers or family members, or don't reply at all. If you can't do that, then simply don't post at all. -Jonathan
Re: Tone policing by a member of the community team [Was, Re: Statement regarding Richard Stallman's readmission to the FSF board]
> Apologies, this is all off-topic for debian-devel Please take it elsewhere, I do not think that this discussion is of any value to the project whatsoever and it should have already ended several posts ago already. -Jonathan
Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Hi Kurt On 2021/04/18 13:20, Debian Project Secretary - Kurt Roeckx wrote: > The details of the results are available at: > https://www.debian.org/vote/2021/vote_002 Thanks for all your work on this vote, I believe that you made excellent decisions as project secretary and it seems that all views that were expressed on -vote were well represented in the vote, so again, I think I can talk on behalf of the project here when I'm giving special thanks for your work. However, I don't think we're quite in a position to pat ourselves on the back here. This vote has once again highlighted some problems in our methods for making decisions. I think that we should set up a working group to specifically deal with voting, polling and project-wide decision making so that we can deal more efficiently with problems in the future. While this vote caught a lot of heat, essentially it's quite a trivial vote. Ultimately it had become a question of if and how we should respond to an external situation. I think that as Debian grows, as the free software eco-system grows, and as software gets ever more ingrained in our every day life, the questions and problems we're going to face will become increasingly complex and that we should adapt to be able to deal with those as a project. Can we go ahead and set up such a working group? I'm thinking that it would involve mailing list discussions, video calls, sessions at DebConf, probably at least one GR, research on different voting methods that could be used, voting software, etc. Fortunately, we're not the only organisation in the world facing issues like these and we can make use of some external experts too. Although all of this will also take some time and effort so I'd really like to have you on board as one of the drivers of this project and also others who have a keen interest in this. What do you think? -Jonathan
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Hi Benda On 2021/04/19 05:30, Benda Xu wrote: > I would like to congratulate you for becoming our next DPL. Thanks! >> However, I don't think we're quite in a position to pat ourselves on >> the back here. This vote has once again highlighted some problems in >> our methods for making decisions. I think that we should set up a >> working group to specifically deal with voting, polling and >> project-wide decision making so that we can deal more efficiently with >> problems in the future. >> >> While this vote caught a lot of heat, essentially it's quite a trivial >> vote. Ultimately it had become a question of if and how we should >> respond to an external situation. I think that as Debian grows, as the >> free software eco-system grows, and as software gets ever more ingrained >> in our every day life, the questions and problems we're going to face >> will become increasingly complex and that we should adapt to be able to >> deal with those as a project. >> >> Can we go ahead and set up such a working group? I'm thinking that it >> would involve mailing list discussions, video calls, sessions at >> DebConf, probably at least one GR, research on different voting methods >> that could be used, voting software, etc. Fortunately, we're not the >> only organisation in the world facing issues like these and we can make >> use of some external experts too. Although all of this will also take >> some time and effort so I'd really like to have you on board as one of >> the drivers of this project and also others who have a keen interest in >> this. What do you think? > > The winning option "Debian will not issue a public statement on this > issue" implies that the majority of DDs is not interested in such > non-technical affairs. Such a working group will distract us from > achieving technical excellence. That's more than just a big assumption, I'd go as far to say that it's a big leap to assume that from that option. Additionally, you're assuming that that attempts to fix the problems in our voting system would somehow make us more political? How do you come to that conclusion? We've had very large technical GRs which have shown significant problems in that process causing huge amounts of pain and frustration in our community, and it comes up regularly how useful it would be to take a formal project-wide poll on something. At the same time, there's often confusion about what exact vote rankings actually mean. To the point where a significant people either don't vote at all exactly because of that, or their vote actually has a significantly different effect than what they intended. Why would anyone in their right mind be apposed to fixing these problems!? -Jonathan
Re: Thanks and Decision making working group
On 2021/04/19 20:18, Daniel Leidert wrote: > The vote was actually two votes: > > a) Should Debian respond publicly as a project? (the "if) > b) How should such a response read? (the "how") I agree with you, I've said something similar before, although instead of saying it was two votes, I'd rather say it started out as a, and that that was the initial intention of the GR, and then it morphed into b as the additional options were added. Sam noted this phenomenon in his last mail in this thread as a strategic abuse. I think it certainly could be used as a strategic abuse and we should be weary of that, but I also don't assign any bad intentions to the people who added options in this particular vote, I don't think it was their intentions to purposely change the nature of the vote in order to change the outcome of the original vote, and I think it's more a failure of our process, but I think in broad strokes we're about on the same page on this. -Jonathan
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Hi Russ On 2021/04/19 21:36, Russ Allbery wrote: > I'm helping hash out some ideas in private only because framing the > problem and brainstorming possible solutions requires a ton of back and > forth... I think that framing the problems and noting them while the last GR is still fresh in our collective memories will be really useful. I don't think anyone should feel too much pressure right now to come up with solutions, and I'd urge any group of people who are brainstorming on this whether on a public channel or among some Debian friends to not yet propose any kind of GR or anything major like that just yet. For the next few weeks the project focus is on releasing bullseye. Once the dust settles on that I think it would be a good time to address the problems in a structured manner and take it from there. It would be great to iron out at least some of the usual kinks in the process by the time the next (non-voting related) GR pops up. -Jonathan
Re: Thanks and Decision making working group
On 2021/04/20 00:10, Sam Hartman wrote: > The sorts of abuses I was talking about have to do with powers of the > original proposer to muck with the process. > Steve could have dragged the process out as long as he wished by > accepting amendments. > Under a strict reading of the constitution, Steve could have made it > more difficult for other people to revise the wording of their ballot > options. > Those are the sorts of abuses I'm talking about. > None of those happened in this election as far as I am aware. Ah in that case I completely misunderstood you, thanks for clearing that up. -Jonathan
Re: Reconsider sending ITP bugs to debian-devel: a new list?
On 2021/06/11 12:17, Jonathan Dowland wrote: > ITP bugs are copied to debian-devel@. The intention, I think, is to make > sure that they have many eyes on them. ITP bugs often get feedback from > readers of debian-devel. > > I think this is valuable. However, it's one job/task/role, and sometimes > One wishes to focus on other jobs/tasks/roles instead. When I subscribed > to debian-devel directly, I most often filtered ITP mail into a separate > mailbox, to read at separate times. Nowadays, I read most Debian lists > via NNTP gateways, and filtering ITPs is not quite so convenient (not > least, because I don't easily have an analogue of the ITP-dedicated > mailbox I used to.). But besides me, I think a better "default" for > debian-devel would be not to have the ITPs. > > I think the ITP mails can make reading the rest of the list difficult > without extra local filtering or steps. Some times they are the > majority of the list traffic. I think it would be better if > ITP mail went to a separate, dedicated list, e.g. "debian-itp" to which > contributors are encouraged to subscribe and participate. > > Does anyone have any strong feelings about this, either for or against? Wouldn't it just be far simpler for those who wish not to receive the ITPs to filter them out to a subfolder of debian-devel or discard them? -Jonathan
Re: Reconsider sending ITP bugs to debian-devel: a new list?
On 2021/06/11 12:33, Raphael Hertzog wrote: > Jonathan explained that it wasn't easy for him due to reading over NNTP > and I also think that it's a bad default to have lists where custom > filtering is desirable for many. Ah, I haven't used NNTP in 22 years so the details to its limitations have faded a bit :) -Jonathan
Re: Regarding the new "Debian User Repository"
Hi Stephan On 2021/07/02 19:16, Stephan Lachnit wrote: > Today I discovered a relatively new project called "Debian User Repository" > [1]. For what it's worth, the Debian trademark team is already aware of this. -Jonathan
Re: Regarding the new "Debian User Repository"
Hi Hunter On 2021/07/05 05:50, Hunter Wittenborn wrote: > In combination with some thoughts that have been said here, as well as > from a branding perspective of what is currently the DUR, I think I'm > going to change the naming for the project. > > I'll be changing it to be called the "makedeb User Repository", which > just makes more sense to me. > > One, it removes the targeting towards Debian (when the project /does/ > first and foremost aim at Ubuntu), and two, it aligns more with the > project's purpose, a user repository for use with makedeb. That definitely sounds a lot more sensible, thanks! -Jonathan
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
Hi Sean On 2021/07/15 09:04, Sean Whitton wrote: > Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean > what I would get if I typed 'debootstrap bullseye /foo', right? > > I would like to note that the TC decision did not specify any particular > implementation of merged-/usr. It was just about whether to continue to > try to support both. I think a more detailed explanation/expansion/clarification on what exactly this means (and ideally also the rationale behind) that in the bug report would be appreciated. thanks, -Jonathan
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
On 2021/07/15 10:47, Marc Haber wrote: > Can we please delay this discussion until after the release? To be clear, I was requesting further details from the TC, not a re-evaluation or further discussion. -Jonathan
Re: Automated backports based on Janitor work?
Hey Lucas
On 2021/08/27 15:04, Lucas Nussbaum wrote:
Oh I wasn't thinking about uploading to the official backports suite.
In the same spirit as the fresh-{releases,snapshots} suites provided by
janitor, I was thinking about an automatically-generated backports
suite.
That sounds great. Firstly there's a lot of benefit to many people who
would use that, but also at the same time it would also count towards
some testing to newer packages that will end up in the next release.
There'll probably be some complications as always, but overall it sounds
like a great idea!
-Jonathan
Re: dpkg taking a bit too long ...
On 2021/10/05 14:24, Norbert Preining wrote: $ time eatmydata dpkg -i /var/cache/apt/archives/papirus-icon-theme_20211001-1_all.deb (Reading database ... 1215786 files and directories currently installed.) Preparing to unpack .../papirus-icon-theme_20211001-1_all.deb ... Unpacking papirus-icon-theme (20211001-1) over (20210901-1) ... Setting up papirus-icon-theme (20211001-1) ... real15m28.611s user0m12.769s sys 15m17.049s $ It took a long time here too but not nearly as long as that: $ time sudo dpkg -i /var/cache/apt/archives/papirus-icon-theme_20210901-1_all.deb Selecting previously unselected package papirus-icon-theme. (Reading database ... 471201 files and directories currently installed.) Preparing to unpack .../papirus-icon-theme_20210901-1_all.deb ... Unpacking papirus-icon-theme (20210901-1) ... Setting up papirus-icon-theme (20210901-1) ... real0m37.751s user0m7.428s sys 0m12.374s That's on ext4/nvme with no eatmydata. Perhaps time to perform a smart test on your disk? -Jonathan
Re: Do we need to hide packages in NEW queue
Hey Russ On 2022/01/30 21:34, Russ Allbery wrote: Francesco Poli writes: I thought the basis was the fact that copyright and licensing bugs may have bad legal consequences (lawsuits against the Project for distributing legally undistributable packages, things like that), while technical bugs do not cause issues with lawyers and are, in this sense, "easier" to fix. Sure, everyone says this, but is this *true*? The free software community has a tendency to assume a lot of things about laws that aren't actually true. Sometimes this is useful conservatism, since there are a lot of legal areas for which the answer is not clear-cut, and if it doesn't matter much either way, better to avoid any sharp corners. But in this case, this assumption has a very high cost for the project, so maybe it's worth finding out whether it actually matters. Very true indeed. As people have pointed out in the numerous previous iterations of this discussion, it's not like the ftp-master screen eliminates all copyright and licensing bugs on project services. I'm sure that we've accidentally pushed non-distributable material to Salsa, we did to Alioth before that, ftp-master will occasionally make mistakes, etc. We should act with alacrity to remedy serious copyright and licensing bugs; no one is arguing against that. But is it legally necessary to take the very specific measure that we are currently taking against them? I don't believe it is, if a piece of work is uploaded in NEW, chances are that we already host that in a public git repository already. Also, in the legal framework the process is usually to first send a cease and desist before further escalating, so in the case of that happening, I'm quite confident that the FTP masters will oblige and that it wouldn't become a major issue. (but also #IANAL) As for getting legal advice, we do have an existing contract with Aaron K. Williamson of Williamson Legal, PLLC (https://www.akwlc.com/). His specialty is Open Source softwware, technology, licensing and contracts, so he would be a good person to ask specific questions about this, and since we have an existing contract with him, it's really easy to set up a video call / email thread with him if anyone wants to get some advice from him. So if anyone has some time / energy to put together some concrete questions / examples (and ideally also recruit one or more people from FTP team to be involved), then I'd be happy to do the introductions and set that up. -Jonathan
Re: Do we need to hide packages in NEW queue
Hey Russ On 2022/01/30 21:34, Russ Allbery wrote: Francesco Poli writes: I thought the basis was the fact that copyright and licensing bugs may have bad legal consequences (lawsuits against the Project for distributing legally undistributable packages, things like that), while technical bugs do not cause issues with lawyers and are, in this sense, "easier" to fix. Sure, everyone says this, but is this *true*? The free software community has a tendency to assume a lot of things about laws that aren't actually true. Sometimes this is useful conservatism, since there are a lot of legal areas for which the answer is not clear-cut, and if it doesn't matter much either way, better to avoid any sharp corners. But in this case, this assumption has a very high cost for the project, so maybe it's worth finding out whether it actually matters. Very true indeed. As people have pointed out in the numerous previous iterations of this discussion, it's not like the ftp-master screen eliminates all copyright and licensing bugs on project services. I'm sure that we've accidentally pushed non-distributable material to Salsa, we did to Alioth before that, ftp-master will occasionally make mistakes, etc. We should act with alacrity to remedy serious copyright and licensing bugs; no one is arguing against that. But is it legally necessary to take the very specific measure that we are currently taking against them? I don't believe it is, if a piece of work is uploaded in NEW, chances are that we already host that in a public git repository already. Also, in the legal framework the process is usually to first send a cease and desist before further escalating, so in the case of that happening, I'm quite confident that the FTP masters will oblige and that it wouldn't become a major issue. (but also #IANAL) As for getting legal advice, we do have an existing contract with Aaron K. Williamson of Williamson Legal, PLLC (https://www.akwlc.com/). His specialty is Open Source softwware, technology, licensing and contracts, so he would be a good person to ask specific questions about this, and since we have an existing contract with him, it's really easy to set up a video call / email thread with him if anyone wants to get some advice from him. So if anyone has some time / energy to put together some concrete questions / examples (and ideally also recruit one or more people from FTP team to be involved), then I'd be happy to do the introductions and set that up. -Jonathan
Re: History doesn't repeat itself, but it often rhymes
Hi Paul On 2022/02/22 19:29, Paul Tagliamonte wrote: We don't need to be hostile or expel people for doing things outlined in the OSS Simple Sabotage Manual, since a lot of that behavior is -- at times -- desirable, but I think we do need a*LOT* of self-reflection (from*everyone* who actively engages with Debian politics) to consider our actions, and determine how (if at all) we feel that we (as individuals) should change. Thanks for that mail, it was an interesting read and I think I'll try to get a copy of that manual! As for the paragraph quoted above, I do think we need to deal with people who are indistinguishable from a saboteur. I value my time a lot, and also of those who spend all their love and energy and years of their lives into this project, so I find it incredibly offensive when someone comes and things that it's their god given right to piss all over it and keep wasting everyone's time. As a courtesy, I think it's fine to tell them that we find that behavior problematic, and that they should stop it if they wish to remain part of the project. But failing that, whether I'm DPL or not, I will strongly campaign with DAM or whoever makes those kind of decisions to kick them out. If we have leadership that can't take those kind of decisions then I'd rather not be part of Debian at all. -Jonathan
Re: access forbiden salsa.debian.org
Hi Phil (and everyone) On 2022/03/01 15:10, Philip Wyett wrote: Thank you for the terse response. The two examples i.e. micronews and the infra list do not sound that this is scheduled work at all. Better communication from teams would possibly give better understanding and the patience of users/developers that is being asked for. Our GitLab instance (Salsa), have fallen behind multiple versions. This is due to a bunch of different hurdles that all came with their own decisions (I'm going to urge the Salsa admins again to do a write-up about it). So what's happening now is point-to-point upgrades between all the GitLab versions needed on this upgrade path, along with the migrations between them (which are quite large, Salsa is one of the biggest GitLab instances out there). So while a huge amount of pent up maintenance is all happening at once now, at least regular updates (and security updates) will be able to run again on short cycles. (I hope salsa admins don't mind me posting this, but I hope it helps all our contributors better understand what's going on). On a practical note, please take note of any uploads you do during this downtime, and be sure to do a git push along with the tags when Salsa is back up again. -Jonathan
Re: Open Letter to Debian election candidates about Debian vendettas
Daniel, you have been kicked out and consequently banned entirely from the project due to your behaviour and continued poor behaviour. You are not welcome or allowed in Debian, which includes our mailing lists, other communication channels or in-person events. And we will certainly not apologise to you for the harassment that you have caused to our project members and volunteers. For anyone else, our public statement remains at: https://www.debian.org/News/2021/2027 -Jonathan On 2022/03/19 11:28, Daniel Pocock wrote: Felix, Hideki, Jonathan You all nominated as candidates in the Debian election In August 2018 I publicly resigned from mentoring the Google Summer of Code internships. My resignation email[1] was written diplomatically and did not contain any hints about the intern relationships and other problems in Debian. Over four years since my polite resignation, rogue volunteers associated with Debian have been making attacks through emails and web sites that are causing harm to reputations, families, careers of both volunteers and interns, past and present. This culture of attacks was cultivated by a series of emails sent from the leadership role in 2018 when Chris Lamb occupied that position. No subsequent leader has shown any remorse or contrition for the way Lamb misused this position. Other volunteers, for example, Dr Norbert Preining, have resigned[2] in disgust at the same culture crisis in Debian. The recent legal verdict against Red Hat, Inc has explicitly stated that overbearing and controlling tendencies of people in leadership roles amounts to harassment[3]. As a leader, can you identify anything that is more important than stopping, retracting and apologizing for these vendettas that were born out of the leadership post you hope to occupy? Will you publicly denounce the culture of denouncing people? Does anybody else support an end to hostilities in Debian? Regards, Daniel 1. https://lists.debian.org/debian-outreach/2018/08/msg00108.html 2. https://itwire.com/open-source/debian-developer-demoted,-quits-after-two-decades-with-project.html 3. https://www.theregister.com/2022/03/16/red_hat_fedotra/
Re: Open Letter to Debian election candidates about Debian vendettas
Hi Everyone On 2022/03/19 12:36, Jonathan Carter wrote: ... Apparently I missed some header abuse in the original mail (used to work around being banned from this list and mislead recipients to believing that it arrived via the list). So, yes I fell for it, sorry for bringing some of that noise to the list, and be on the lookout for similar attacks. thanks, -Jonathan
Re: Open Letter to Debian election candidates about Debian vendettas
Hi Dominik On 2022/03/19 20:04, Dominik George wrote: I ask to finally ban Pocock from all Debian lists (and other communication channels). The last statement here is upright racist, and although there has been more than enough reason to get rid of him, this must be the last thing he ever did within the realms of Debian. Please do not tolerate this person any longer. I don't think you got that original mail from the list, it's Daniel sending mails to a large amount of people and forging some headers to make it look like it's coming from debian-devel, and then when people reply-to, they inadvertently send the content to debian-devel themselves. He's already banned from all the Debian lists, this is just a new way he's discovered of being abusive. -Jonathan
Re: Bits from the DPL
On 2022/04/20 08:25, j...@debian.org wrote: 2022-01-12 - Milestone 1 - Transition and toolchain freeze 2022-02-12 - Milestone 2 - Soft Freeze 2022-03-12 - Milestone 3 - Hard Freeze - for key packages and packages without autopkgtests To be announced - Milestone 4 - Full Freeze Oops, that was a copy and paste from an initial incorrect mail, the dates are of course meant to be for 2023, not 2022. -Jonathan OpenPGP_signature Description: OpenPGP digital signature
Bug#1011631: ITP: python3-dmm -- distribution management modules/toolkit
Package: wnpp Severity: wishlist Owner: Jonathan Carter X-Debbugs-Cc: debian-devel@lists.debian.org, j...@debian.org * Package name: python3-dmm Version : 0.0.1 Upstream Author : Jonathan Carter * URL : https://salsa.debian.org/jcc/distribution-management-modules * License : ISC Programming Lang: Python Description : distribution management modules/toolkit Modules and toolkit that makes taking care of Linux distribution tasks easier. Its initial set of modules allow you to configure tools like. apt, grub, squashfs (among others) and actions from these modules can be stringed together using recipes (which are yaml files).
Bug#1023979: ITP: python3-simpleobsws -- simple obs-websocket library in Python for people who just want JSON output
Package: wnpp Severity: wishlist Owner: Jonathan Carter X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python3-simpleobsws Version : 1.3.1 Upstream Author : IRLToolkit Inc. * URL : https://github.com/IRLToolkit/simpleobsws * License : Expat Programming Lang: Python Description : simple obs-websocket library in Python for people who just want JSON output This software provides an asynchronous client for Python to control OBS via it's websocket gateway. I plan to maintain this package within the Debian Python team.
Populating non-free firmware?
Hi Debianites Earlier this year, we had a [vote] where we concluded that we'd include non-free firmware in the upcoming Debian 12 release. Steve posted a summary of [next steps] to this list, but it seems like we have some steps missing. The non-free-firmware [component] has been created, but so far it only contains the rasbpi-firmware package. I recall seeing various discussions about /what/ should be included in non-free-firmware (packages that install files under /lib/firmware seems like a reasonable approach), but it's unclear how that's going to happen. Will the archive team be moving those over? Is it up to firmware packagers to re-upload it to the correct component? As far as I recall, there was also some discussion between archive admins on whether non-free-firmware should contain copies of packages, or whether the packages should be moved (along with migration concerns for the latter). Since we're so close to freeze, and since there are lots of bits that will be depending on this if we are to implement this for Debian 12, can we have some basic plan and communication put together for this so that everyone knows what to expect? Thanks to everyone involved in this and putting in the work to make it happen! -Jonathan [vote] https://www.debian.org/vote/2022/vote_003 [next steps] https://lists.debian.org/msgid-search/20221002142736.ga1700...@tack.einval.com [component] http://ftp.debian.org/debian/dists/testing/non-free-firmware/
Re: Populating non-free firmware?
Hi Bastian On 2022/12/25 13:32, Bastian Blank wrote: AFAIK this requires a re-upload. However, does the installer properly include it yet? I need to check that. I can handle the main firmware packages maintained by the kernel team. Great! That covers a large percentage of them (and even most of the important ones). So if we're going with maintainers-are-going-to-do-the-uploads, then taking a cursory glance at what's left that seems important is: - firmware-sof-signed (maintainer: Mark Pearson) - intel-microcode (maintainer: Henrique de Moraes Holschuh) - amd64-microcode (maintainer: Henrique de Moraes Holschuh) -Jonathan
Re-enabling os-prober for live images?
Hello Debian Developers Since the grub 2.06 upload, os-prober is now disabled by default. This means that other operating systems are no longer detected and added to grub by default in Debian 12. This makes some sense, since mounting foreign filesystems and reading files on them, extracting some text and using it as variable in shell scripts could well be dangerous if those foreign filesystems are infected with malware that takes advantage of this. However, I'm not sure this is a good default for Debian Live at this time. Many people who install from Debian Live are dual-boot users, and currently, they'll have to do an additional step that's relatively easy for any system administrator, but far more complicated than any other step to configure Debian at that point (edit a file as root and then run update-grub, and, they'll need to know that they need to do this). Julien posted about this on ubuntu-devel a while back too: https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041769.html I haven't followed further on to which solution they went with, but since it's so late in the development cycle, wouldn't it make sense to enable os-prober for Live systems for Debian 12, and then look at some of the better solutions (like only probing at install time, and keeping a cached results for grub) for Debian 13? -Jonathan
Re: should Debian add itself to https://python3statement.org ?
On 2019/09/12 18:30, Mo Zhou wrote: > Agreed. there are already python2 forks such as: > https://github.com/naftaliharris/tauthon > > It may sound funny but I don't hope any python2 stuff get back with > a new name after the python2 removal. But, it could happen if some > people is willing to support and maintain... > > How should Debian react if someone submitted an ITP for python2 > forks, such as the tauthon above? It would probably be handled just like any other piece of new software entering Debian. I can't speak for the entire Python team, but the Python team would probably not pay much (or any) attention to it whatsoever and it would be unfair for anyone to expect that from the Python team. Just like with any other software, it would just need an active set of contributors behind it. Personally I just don't think putting a significant amount of effort into a python2 fork is worth while long-term. It's just adding more technical debt. Instagram is one of the largest sites in the world and switched over to python3 because they say they realised that no significant performance work is still going into python2, that's all happening in the python3 world now. JP Morgan's Athena[1] project has over 35 million lines of python code over 150 000 python modules and they regret starting so late but aim to complete migrating the critical core pieces by the 2nd quarter of 2020. My point is that the world is moving to python3, maybe not as fast as everyone would like, but putting in additional work to stick with python2 would mean confining yourself to an ever faster shrinking universe and earning interest on that technical debt and you'll end up with code that no one will want to touch in either terms of working on it or using it. So, I don't think it would be a problem accepting such fork in Debian, I think Debian would be indifferent to it, but in terms of a consumer of such a fork I believe it's better to pull the plaster fast, do the work now to get it updated, or it will just get more expensive in the future. -Jonathan [1] https://www.techrepublic.com/article/jpmorgans-athena-has-35-million-lines-of-python-code-and-wont-be-updated-to-python-3-in-time/ -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Bits from the DPL (August 2019)
On 2019/09/19 11:18, Martin Steigerwald wrote: > I also feel sad cause I saw the enormous efforts of Devuan and Debian > people as well as the new Sysvinit upstream maintainer to improve the > quality of sysvinit, startpart, insserv, runit, openrc you name them > packages and to actually introduce elogind to Debian. The great care, > the willingness to cooperate, the willing to step over own shadows into > light… all of this in vain? FWIW, I don't think any of these efforts are in vain at all. Running alternative (alternative as in, not the default) init systems on Debian is easier now than it was when stretch was released. I've been trying out runit in containers and it seems to be working really well for my use cases (a lot lighter than systemd and does everything I want it to). I'm also a bit curious about openrc and tini and either way I think these are important for our non-linux kernels too (which some people seem to like snuffing at but they are actually important). I appreciate the work that all the people have been doing to help preserve the possibility of having an init system other than systemd, and I'm sure there are many Debian users who are probably not on this list that feel the same way. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Bits from the DPL (August 2019)
Hi Sam On 2019/10/01 15:57, Sam Hartman wrote: > I'd say it is a consensus of those who prioritize participating in this > discussion enough to do so, consented to by the rest of the project. > If we get it sufficiently wrong people in the broader community will let > us know. > > Yes, because of privilege some people can prioritize more things > successfully. I try to follow debian-devel really closely, and mostly manage to succeed, but this was probably the toughest topics for me to follow, there's lots of repetition, me-toos, posts that don't really address either the issue at hand and overall, it just feels like I have to fine-comb it for information and my concentration span just can't handle it. I concur with what others have said in this thread, that we need a better discussion culture, and I think ideally one that has respect for the time of others. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Bug#942310: ITP: gnome-shell-extension-arc-menu -- shell extension designed to replace the standard menu found in GNOME
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-arc-menu Version : 34.2-dev Upstream Author : LinxGem33 (https://gitlab.com/LinxGem33) * URL : https://gitlab.com/LinxGem33/Arc-Menu * License : GPL-2+ Programming Lang: JavaScript Description : shell extension designed to replace the standard menu found in GNOME Arc Menu is a GNOME shell extension designed to replace the standard menu found in GNOME 3 this application menu extension has some added benefits over the standard menu found in GNOME 3, these include the long awaited search functionality as well as quick access to files on your system and also the current logged in user along with quick access to the software centre and system settings and other features which can be accessed from the settings menu. This package will be maintained as part of the shell-extensions subgroup of the GNOME team on salsa.debian.net
Re: Debian event pre FOSDEM?
Hi Holger On 2019/11/18 12:20, Holger Levsen wrote: > I'm not aware the video team has planned a sprint for 2020 already. So > they could very well do it at the MiniDebCamp too. First off, thanks for taking the initiative to get something rolling. Linux.be offices was nice for the video team because we had a space where we could leave equipment safely without having to pack it up every day, they were also very welcoming and fine with people sleeping over and taking showers there. Not 100% sure whether that's possible at the hackerspace, linux.be might still be a better option for the video sprint but if you have more information on what's possible at the hackerspace, then that could help the video team to coordinate at the next IRC meeting. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Bug#946043: ITP: python3-flask-caching -- caching module for flask apps
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: python3-flask-caching Version : 1.8.0 Upstream Author : Peter Justin * URL : https://github.com/sh4nks/flask-caching * License : BSD-3-clause Programming Lang: Python Description : caching module for flask apps Flask extension that provides smart caching support. This is a fork of python3-flask-cache that is still maintained, which maintains a high level of backward compatibility and new features. This package will be maintained as part of the Debian Python modules team.
Re: [PATCH reproducible-notes] Remove non-sense wireguard note
On 2020/01/21 16:43, Jason A. Donenfeld wrote: > This note doesn't make sense. It's either entirely invalid or so poorly > written that it's useless. As the author of the code in question, I've > been unable to ascertain what the note is about, and an email to the note > author hasn't yielded any understanding. Well, if that's the way you approach them then you shouldn't at all be surprised if you don't get a response. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: bootstrap.min.js in pydoctor
On 2020/03/05 00:47, Sam Hartman wrote: > Anthony> Files: > Anthony> debian/missing-sources/pydoctor/templates/bootstrap.css > Anthony> pydoctor/templates/bootstrap.min.css Copyright: 2011-2015 > Anthony> Twitter, Inc. Embedded copy of normalize.css v3.0.2: > Anthony> 2011-2014 Nicolas Gallagher License: Expat Comment: These > Anthony> files are copies of vanilla Bootstrap v3.3.4 CSS files, > Anthony> identical to those distributed on Bootstrap CDN: * > Anthony> https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.css > Anthony> * > Anthony> > https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.min.css > > Is the css file actually source code though? > At least for bootstrap 4, the source code is in sas and the css is not > the preferred form for modification. > I think bootstrap has been using sas for a long time, so I suspect css > is not source code for bootstrap 3 either. That's not really an issue in the context of the original question, Anthony's answer is the correct approach here, that is, patch the application (or use a symlink or whatever) to use the CSS file provided by the libjs-bootstrap4 package. Using the CSS file from the libjs-bootstrap4 doesn't present any kind of DFSG issue since that package builds the CSS file from the original sass sources, see: https://salsa.debian.org/js-team/twitter-bootstrap4/-/blob/master/debian/rules -Jonathan
Re: Recommendations around Git Packaging in Debian
On 2020/04/20 21:45, Thomas Goirand wrote: > When talking about the south hemisphere, I always found it confusing to > talk about summer and winter... What your recommendation? Only use month > names? Well, I live in the Southern hemisphere. It's winter here from June until the end of August. Don't you think it would be confusing to many people in the world if I used terms like "during this winter" in reports? In a global community, it's better to avoid regional terms to describe a period of time, even if that covers a very large region or percentage of contributors. Otherwise it's possible to cause some confusion or to make some percentage of people feel less included. And I 100% understand that it wouldn't be intentional because that's just how people tend to talk (especially in the US and in Europe), but I do tend to think that months is just better all round. Some people like to talk about quarters (where Q1 could be Jan-March etc), but again some people count quarters based on when financial years start in their country (some companies I work for start Q1 in March) so I'd even avoid that and stick with months since that's the same everywhere. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
NMU for Imagemagick?
Hi Imagemagick in Debian is extremely outdated (6.9.10.23 vs 7.0.10-21), causing some FTBFS on packages that depend on it. I know this package is notorious for needing security updates, and not sure if there might be a good reason for it to be stuck on it's current version, so any objection if I look into making an NMU upload for this package? -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: Videoconference Friday 2020-07-24 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020))
On 2020/07/24 12:00, Andreas Tille wrote: > I hope these weekly announcements are not boring for readers of > debian-devel list. Not at all, but it might be nice if you could share some more updates along with them now and again too like any recent achievements or something that turned out to be much more challenging than anticipated. PS: As someone who's constantly behind with posting updates these day, I know that's a bit rich coming from me, I know it's tough so no pressure :) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: Lenovo discount portal update (and a few other things)
Hi Mark On 2020/09/02 15:08, Mark Pearson wrote: > Following on from DebConf 2020 (which I thoroughly enjoyed - thank you!) > the Lenovo portal that was announced is now available: > > US: http://www.lenovo.com/us/en/Linux > Canada: http://www.lenovo.com/ca/en/linuxca > > We're still working on getting other geographies up and running - not > available yet I'm afraid. > > You should just be able to register with your debian.org email address > to get the discount on any Lenovo equipment. Do let me know if any > problems. > > We also have our first Linux platform up (X1 Carbon Gen 8 with Fedora). > There should be a number of other platforms coming soon - we're working > on those and I expect them to be out in the next few weeks. If you have > any questions on our Linux platforms please let me know. > > I did also try and get through the remaining questions that didn't get > answered during the Debconf talk - so if your question didn't get > answered at the time have a look at etherpad and check. Thanks for the information! And congratulations on the successful launch of your Linux line-up, I hope it's the first of many success stories on this front! -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: [External] Re: Lenovo discount portal update (and a few other things)
On 2020/09/04 11:23, Philip Rinn wrote: >> Why do we need to make this 100% accurate in the first place? Everyone >> who got access to a debian.org email address has been an OSS contributor >> of sorts. Which leaves those who opted out of the email address entirely >> (rather than not using it) - but they are free to reactivate it. It >> feels like just checking for @debian.org is good enough, IMO. > > Well, DMs don't have debian.org email addresses. The benefit is currently just for DDs. Maybe that could change in the future, but that is how it is now. For people who don't usually use their debian.org addresses, it seems like a small issue? All they need to do is temporarily enable the forwarder to their usual address in db.debian.org, so no big deal? -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Bug#838029: ITP: bundlewrap -- Simple, decentralized configuration management with Python
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: bundlewrap Version : 2.8.0 Upstream Author : Torsten Rehn Peter Hofmann Tim Buchwaldt * URL : http://www.bundlewrap.org/ * License : GPLv3+ Programming Lang: Python Description : Simple, decentralized configuration management with Python BundleWrap fills the gap between complex deployments using Chef or Puppet and old school system administration over SSH. While most other config management systems rely on a client-server architecture, BundleWrap works off a repository cloned to your local machine. It then automates the process of SSHing into your servers and making sure everything is configured the way it's supposed to be. You won't have to install anything on managed servers. I'm a user of this software myself, and plan to maintain it as part of the Debian Python Application Packaging Team (PAPT).
Bug#841913: ITP: gnome-shell-extension-refresh-wifi -- keep wifi access point list current in GNOME shell
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-refresh-wifi Version : 6-1 Upstream Author : Gopi Sankar Karmegam * URL : https://github.com/kgshank/gse-refresh-wifi * License : GPL-3 Programming Lang: Javascript Description : keep wifi access point list current in GNOME shell By default, GNOME doesn't scan for additional networks once you're connected to a network. . This extension will periodically refresh the wifi list, making it easier to switch networks.
Bug#841920: ITP: gnome-shell-extension-hide-activities -- gnome shell extension that hides the activities button
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-hide-activities Version : 0.00~git20131024.1.6574986-1 Upstream Author : Shay Elkin * URL : https://github.com/shayel/gnome-hide-activities * License : PD Programming Lang: Javascript Description : gnome shell extension that hides the activities button This extension hides the Acitivies text and button on the top left corner of GNOME shell, making the appearance simpler and the panel less cluttered.
Bug#842014: ITP: gnome-shell-extension-impatience -- speed up the gnome-shell animation speed
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-impatience Version : 0.4.3-1 Upstream Author : Tim Cuthbertson * URL : https://github.com/timbertson/gnome-shell-impatience * License : GPL-3 Programming Lang: Javascript Description : speed up the gnome-shell animation speed The impatience extension allows you to speed up GNOME Shell animation speeds. . >From gnome-tweak-tool you can use a slider to scale the animation speed down to any percentage. A speed scale of 1 means normal speed, 0.5 will result in animations twice as fast, 0.1 will result in animations being 10x faster, etc.
Bug#842671: ITP: calamares -- universal system installer framework
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: calamares Version : 2.4.3 Upstream Author : Teo Mrnjavac * URL : https://calamares.io * License : GPL-3+ Programming Lang: C++, Python Description : universal system installer framework Calamares is a distribution-independent installer framework. It provides a graphical installer that can be used with nearly any distribution. This package is suitable for live media on Debian-based systems, and won't be of any particular use on and already installed system. You will likely want to provide your own config files to match your distribution, reading the Calamares documentation will guide you through that process.
Bug#842694: ITP: gnome-shell-extension-proxy-switcher -- gnome-shell-extension-proxy-switcher
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-proxy-switcher Version : 1.2 Upstream Author : Tom Flannaghan * URL : https://github.com/tomflannaghan/proxy-switcher * License : GPL-2+ Programming Lang: JavaScript Description : gnome-shell-extension-proxy-switcher Adds an option to the GNOME Shell system menu that allows a user to quickly switch between no proxy, manual proxy and automatic proxy settings.
Bug#842701: ITP: gnome-shell-extension-hard-disk-led -- Shows harddisk activity (IO speed read/write and LED) in GNOME Shell
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-hard-disk-led Version : 13 Upstream Author : bigi * URL : https://github.com/biji/harddiskled * License : GPL-3+ Programming Lang: JavaScript Description : Shows harddisk activity (IO speed read/write and LED) in GNOME Shell Many new laptops and some tiny computers do not have hard disk LEDs. . This extension ads an indicator to GNOME Shell that can either show read/write speeds or LED lights to indicate activity.
