Re: Unlock LUKS with login/password
On Wed, Mar 8, 2023 at 11:33 AM Alexey Kuznetsov wrote: > > > On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC wrote: > >> Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit : >> >> Hello! >> >> I have an idea about how modern linux should work with encrypted LUKS >> partitions. >> >> Hi, >> >> I'm using LUKS for a long time on both my personal (desktop) and >> professional (laptop) computers. Since they are single user (me), I use >> autologin in the display manager, lightdm in my case. Because there is only >> one slot configured in LUKS, I'm sure this is me, so lightdm can autologin >> safely. >> >> However, you are proposing to solve the case for multiple user computers. >> In that case, I would think about a much simpler design: >> >> - Remember which slot was used to unlock the LUKS root partition >> >> - Make a map with slot -> user to autologin >> >> - Autologin that user on boot >> >> No more passing password, no more password update headache. But only a >> root user can update the map "slot -> user". >> >> Adrien >> > Right. But you still have to remember passpharse and your main account > password. This is not about autologin. This is about unlocking your machine > LUKS with only login/password without having an additional passphrase to > remember. > The reason you can not use Login/Password as the LUKS passphrase is because The Passphrase can not be different for different users. The passphrase is not simply a password but instead it is part of the key material used to decrypt and encrypt. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Grub Password configuration during install
All, Would it be possible to add a section to the installer when Grub is being installed and configured to configure a grub password? Thanks Tim -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Populating non-free firmware?
On Sat, Dec 24, 2022 at 12:15 PM M. Zhou wrote: > On Sat, 2022-12-24 at 11:44 +0200, Jonathan Carter wrote: > > > > The non-free-firmware [component] has been created, but so far it > > only > > contains the rasbpi-firmware package. > > Please ensure to include the packages for wifi cards, especially > the iwlwifi since I don't use desktop pc. > > One of the most painful ways to install Debian is to realize that > iwlwifi is missing during the netinstall process, while RJ45 cable > is not available. As a result, one may download the package using > cellphone and find a way to transmit that file to the laptop. > If it's iphone then game is sadly over. > > In the past, such frustration had once irritated one of the new > users to whom I have recommended Debian. The user's anger has > finally converted into personal/emotional attacks, blaming > me as a Debian developer being incompetent to make the wifi > card working. As a result, I as a Debian developer, would never > recommend Debian to any new user, nor discussing linux with > any new user since then. > > iwlwifi is the very only reason that forced me to never use the > the default iso again. > > That said, my word only counts as a vote for the wifi card packages. > Just wanted to mention that iwlwifi may hurt people. > > I agree WiFi is needed. I have Realtek and it needs non-free firmware. I also need the binary blobs for AMD Radeon. I use the non-free installer. If not all firmware is going to be included in the installer will there still be a non-free installer image? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: looking for debian friendly web app technology
On Thu, Dec 15, 2022 at 8:51 AM Alastair McKinstry < alastair.mckins...@sceal.ie> wrote: > Hi, > > Is Qt6-base not in testing, for bookworm? I've an app (metview) that I > switched over Qt5->Qt6, should I move it back? > > Bookworm currently has Qt 6.3.1 and 6.4.0 packaged. > regards > > Alastair > > On 13/12/2022 20:27, Andreas Josef Heil wrote: > > Well qt5 is fine too. I don't need fancy features. I will make a kde app. > > > > On 13.12.22 05:22, Imre Nagy wrote: > >> The downside of these things, that current Debian does not seem to > >> include Qt6 at all and I have no idea when it can go into the > >> mainstream Debian, while there are a lot of project could be waiting > >> for it. (Even my one is still pending for Debian). Qt6 for Debian is > >> still in unstable/experimental state, which drives the developers > >> like me to find other alternatives instead of Debian or for Debian. > >> > >> Best regards, > >> Imre > >> > >> 2022. 12. 13. 1:48 keltezéssel, Sam Hartman írta: > I wrote too early sry. A desktop app is also possible. I will use qt. > > > -- > Alastair McKinstry, > GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 > ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: looking for debian friendly web app technology
On Tue, Dec 13, 2022 at 12:51 AM Imre Nagy wrote: > Hi, > > What do we think about "accessibility" in this thread? The MSAA like > helping for visually challenged, or the global avaiblity (and > acceptance) of QT? > > As of Qt 5.15, (and Qt 6.4.x lately) you do not have to make the hard > choice between responsive webpage or desktop application, since you can > generate both from the same QT source code. The native is native, the > browser based using WebAssembly technology. (I think MSAA is not yet > supported for WebAssembly till this date, but please double check this > information!) > > The downside of these things, that current Debian does not seem to > include Qt6 at all and I have no idea when it can go into the mainstream > Debian, while there are a lot of project could be waiting for it. (Even > my one is still pending for Debian). Qt6 for Debian is still in > unstable/experimental state, which drives the developers like me to find > other alternatives instead of Debian or for Debian. > > Qt 6 will not be in debian until debin 13. Bookworm will still have Qt 5 and KDE 5. You can manually download and install Qt6 on Debian. If you target Debian 13 for inclusion of your app that will give you about two years to finish it. > Best regards, > Imre > > 2022. 12. 13. 1:48 keltezéssel, Sam Hartman írta: > >> I wrote too early sry. A desktop app is also possible. I will use qt. > >> Thanks for your time. > > > > QT accessibility has improved a lot, but I suspect that a single page > > web app with vuejs and a good widget set on top of that is going to be > > more accessible than a QT app even today. > > I find I stumble less with web app accessibility than I do with linux > > desktop accessibility, although both are usable. > > > > > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: RFC: Switch default from netkit-telnet(d) to inetutils-telnet(d)
On Sat, Jul 16, 2022 at 10:19 PM Guillem Jover wrote: > Hi! > > There's been talk about switching away from netkit-telnet and > netkit-telnetd as the default implementations for some time now, > and replacing them with the ones from inetutils, which is a maintained > project and does see releases (even though with a long cadence). > > This has been discussed somehow in #982253 and #987729. > > These packages currently use a pair of virtual packages to denote > that they are a telnet or telnetd implementation (telnet-client and > telnet-server). One problem is that currently the netkit implementations > use the generic telnet and telnetd package names, which is a clear way > to mark them as the default implementations (instead of say the other > convention of naming or providing a default-foo package). Another is > that several packages depend on these generic names instead of the > virtual packages, see below for a list that would deserve a non-blocking > "mass" bug filing, which I can handle as part of the switch. > > The inetutils-telnet recently got support for the missing «-b» option > for compatibility with netkit-telnet. > > The inetutils-telnetd and netkit-telnetd have diverging options and some > conflicting ones, but after pondering about it I don't think this should > be a major issue, as the daemon does not tend to get called by users from > scripts and similar. For completeness the divergences are these: > >inetutils-telnetd netkit-telnetd >- -- >short and long options short options > -D (unimplemented «exercise» mode) >-D (debug modes «auth», «encr») -edebug >-S, --server-principal -S (used to set the IP TOS) >-E, --exec-login-L >-l, --linemode >-U, --reverse-lookup-N (related but not exactly the same) > > > Simon Josefsson (CCed), who is one of the inetutils upstream maintainers, > recently adopted the netkit-telnet source package in Debian, which he'd > prefer to keep around for a smoother transition period, in case users > want or need to revert back. > > > > So, the idea would be for src:inetutils to take over the telnet and > telnetd binary packages and make them transitional packages depending > on the inetutils variants, for a smooth upgrade, and in addition also > start providing them by the inetutils- packages. > > The src:netkit-telnet would then switch to ship netkit-telnet and > netkit-telnetd binary packages (this would ideally be uploaded to > experimental first, so that once ACCEPTED it can be uploaded to sid > once we start the switch, with no missing implementation in between). > > I'm inclined to do it in this order to potentially avoid two trips over > NEW, and to reduce any potential disruption period. > > In the future (after the next stable release) the telnet/telnetd > packages could be switched to be pure virtual packages, taking the role > of denoting the current default implementation, instead of introducing > default- variants, as that's what users are currently used to, and > it would keep working even if the depending packages below do not update > their dependencies. > > We'd file an override request against ftp.debian.org to get the > inetutils-telnet Priority bumped to standard to match the current > telnet package (which could get then its Priority lowered to optional). > > Currently inetutils and netkit have the same alternative priority > for telnet, I'd probably bump it also to 150 for inetutils to take > precedence. > > > If there are no objections, we could probably start working on this > switch in a couple of weeks or so. > > > > List of packages depending on telnet (but not telnet-client): > > forensics-extra (Depends) > lava (Depends) > live-task-standard (Depends) > mininet (Depends) > vland (Depends) > zssh (Depends) > > dish (Recommends against all current implementations) > lava-dev (Recommends) > lava-dispatcher (Recommends) > live-task-extra (Recommends) > pdudaemon (Recommends) > > libtelnet-dev (Suggests) > libtelnet-utils (Suggests) > procserv (Suggests) > ser2net (Suggests) > tucnak (Suggests) > > List of packages depending on telnetd (but not telnet-server): > > telnetd-ssl (Conflicts) > nyancat-server (Conflicts) > > > Thanks, > Guillem > > Telnet is old, insecure and should not be used any more. What is the point of packaging a Telnet daemon when everyone should be using SSH. Telnet Client I can see because a person may need to connect to a router or switch that is still using telnet or hasn't had SSH Certificates generated yet. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
bullseye-updates does not have a Release file
When I run sudo apt update I receive the following error messages: Err:5 http://security.debian.org/debian-security bullseye-updates Release 404 Not Found [IP: 2a04:4e42:77::644 80] *E: *The repository 'http://security.debian.org/debian-security bullseye-updates Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. Here is the settings from /etc/apt/sources.list: deb http://security.debian.org/debian-security/ bullseye-updates main deb-src http://security.debian.org/debian-security/ bullseye-updates main Is anyone else having this problem? Thanks Tim
Re: Firmware - what are we going to do about it?
On Sat, Apr 23, 2022 at 4:50 PM Paul van der Vlis wrote: > Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin: > > On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote: > >>> I see several possible options that the images team can choose from > here. > >>> However, several of these options could undermine the principles of > Debian. We > >>> don't want to make fundamental changes like that without the clear > backing of > >>> the wider project. That's why I'm writing this... > >> > >> I have an idea for an extra option: > >> > >> 6. Put the closed source firmware somewhere in the Debian images, but > never > >> install closed source firmware by default. "No" should be the default. > > That's the option 3 more or less. > > Option 3 says to publish two sets of images. > And it says nothing about defaults. > > > 3. We could stop pretending that the non-free images are unofficial, and > maybe move them alongside the normal free images so they're published > together. This would make them easier to find for people that need them, > but is likely to cause users to question why we still make any images > without firmware if they're otherwise identical. > > This is the option I like. As a user who needs the closed source binary blobs they should be easier to find. > >> to put "non-free" into sources.list should also be an non-default > choice, > >> even when you install closed source firmware. > > No, that's a bad idea, which is one of the main reasons for the option 5. > > The idea is not to promote closed source firmware in any way. Have it > available, but only for the people who really want it. > > Maybe it's also an idea to put the firmware in a seperate partition. > > With regards, > Paul > > BTW: I sell Debian media like USB-sticks. I know about the problems > people have to choose a medium-type etc. > > > -- > Paul van der Vlis Linux systeembeheer Groningen > https://vandervlis.nl > >
Re: Firmware - what are we going to do about it?
> > My laptop requires the non-free binary blobs for WiFi, AMD GPU and HDMI > Sound. I think making the non-free images easier to find is a good idea. I > didn't know they even existed until I got this new laptop and nothing was > working with the regular installer. Placing the non-free and non-free live > images along side with the free installer images would be very nice. > Tim
Re: Seeking consensus for some changes in adduser
On Tue, Mar 8, 2022 at 6:18 PM Richard Laager wrote: > > On 3/8/22 10:49, Marc Haber wrote: > > (1) > > #202943, #202944, #398793, #442627, #782001 > > The bug reporters are requesting the default for DIR_MODE to be changed > > from 0755 to 0700, making home directories readable for the user only. > > Policy 10.9 states that directories should be 0755, but the policy > > editors probably didn't have user home directories in mind when they > > wrote that. > > As a data point, Ubuntu moved to 750 a year ago: > https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04 > > At my day job, we then followed that across the board (despite not yet > being on an Ubuntu release where the change was made), and it was > essentially fine. We already considered home directories on our file > server to be "private", and on everything else, there are only accounts > for admins (who can use sudo in the rare event they need a file from > someone else's home directory). > > > (1a) would it be necessary to handle --system accounts differently? I > > think yes. > (1b) should we stay with 0755 for --system accounts? > > I don't see why system accounts need to be different. > > > (1c) does a change to 0700 for user accounts make sense? > > Yes. > > > (1d) should it be 0751 (#398793)? > > Pro: That helps ~/public_html. > > Con: That seems like a trap for non-expert users. It _feels_ like other > people can't get at things, but they actually can, if they know the next > directory down. I (and probably everyone reading this list) understands > the "1" in 751, but do end users? > > > (1e) how about ~/public_html that would break with 0750? > > As a comment on the bug mentioned, public_html not a default thing. > Changing DIR_MODE and/or ACLs are also options for those who want a > ~/public_html concept. > > > All those bugs referenced have more or less heated exchanges ranging > > from "it's fine" to "we should issue a DSA ASAP", most of them a decade > > old, so the times might have changed since then. Please note that the > > DIR_MODE _IS_ configurable in adduser, we're just discussing the > > default (which also applies for home directories created while still > > inside the Installer before a local admin can properly configure > > adduser). > > I think there is merit to defaulting to the most secure (but still > reasonable) option, and letting people loosen it if desired. > > > (2) > > #774046 #520037 > > Which special characters should we allow for account names? > > > > People demand being able to use a dot (which might break scripts using > > chown) and non-ASCII national characters in account names. The regex > > used to verify non-system accounts is configurable, so the policy can be > > locally relaxed at run-time. > > > > For system-accounts, I'd like to stick to ASCII letters, numbers, > > underscores. > > I support dashes, as was already discussed. That's already in use. > > I think the idea of dot in a username is perfectly reasonable on its > own. For some people this is very desirable. My wife, for example, uses > a dot in her email username as her first name plus my-now-her last > initial makes a word that is awkward. (This sort of problem is not > uncommon in usernames, especially at companies that make them via some > algorithm.) > > I always use colon for chown, which is what is documented, but I'm aware > it takes dot too. Is there any code in chown to handle the dot case > intelligently? Please add support for "." so we can use first.last names as user names. Other Linux's are already doing this so it should not break anything. > Non-ASCII does feel a little concerning to me (since those code paths > won't be exercised very often). > > But to recognize my bias, I have no need for a non-ASCII username. I'd > probably feel quite differently if my name wasn't correctly > representable in ASCII. Put differently, if usernames were currently > required to be Han or Cyrillic characters, I'd certainly be up in arms > asking for Latin character support. > > On the other hand, Debian probably can't go it alone here. If, as people > have mentioned, systemd isn't going to support those usernames, there's > not much point in adduser allowing them. > > > (3) > > #625758 > > --disabled-password just does not set a password for the newly created > > account (resulting in '*' in shadow) while --disabled-login places a '!' > > in shadow. On modern systems with PAM, both variants seem to be > > identical, allowing login via ssh. Aside from the documentation needing > > change to document reality > > Simon McVittie's explanation matches my understanding of what the > current behaviors of '*' and '!' are (but I haven't tested the empty > password nuance). > > While I get the general idea of locking in a way that allows unlocking > later (and keeping the original password hash), I don't see > --disabled-login as being particularly useful for adduser, since it > leads to an identical result as --disabled-password. >
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
All, I am against automatically setting HTTPS. Their should be an option in the installer to set or unset HTTPS while configuring the mirror! I like a lot of folks am on a metered internet connection with a UTM proxy firewall. I have multiple computers that need patched and only having to download the package once is a great convenience to both data usage and download time as my internet is not fast 4G LTE usually only operating at 3G speed. Tim
Re: testing for rootfs vs. /usr reproducibility regressions
On 8/21/21, Andy Smith wrote: > Hi Tim, > > On Fri, Aug 20, 2021 at 05:29:54PM -0400, Timothy M Butterworth wrote: >> I have a new-be question, what is the point of merged-usr? > > I put "debian merged-usr" into my favourite search engine and the > first result was: > > https://wiki.debian.org/UsrMerge > > Does this page and those linked from it answer your question > sufficiently as to what the point of the effort is? > > The link near to the bottom: > > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge > > is quite informative. Thanks for the links, I have read them and I am all caught up now. This seems like something that Linux Standard Base LSB should have resolved regarding the installation directory. > If you read those and it still isn't clear, it might be best to ask > about it on debian-user, as debian-devel would really be for Debian > Developers (who are mostly up to speed on this already to varying > degrees) to decide about *how* to do it, not the basics of *why* or if > it even *should* be done. > > It has been the default for some time for new installs and the > tech-ctte already decided that it will be the only supported > configuration for the next release after bookworm. At this point > rehashing the whys of it would be repeating conversations had over > the last several years, so I feel like it's a user documentation > issue at this point if that's necessary. > > Cheers, > Andy > >
Re: Debian 11 Bullseye Setup Problems Error Report
I have been using Debian 11 since Alpha 1 release. I installed with non-free live DVD using the calamaris installer. I have it installed on three systems one Intel Celeron, one Intel i5 and one AMD Ryzen 7. I give the installer a 5 star rating although I would like to see some improvements made to the disk configuration utility. Currently the disk configuration utility is non-intuitive and appears to be designed for keyboard only navigation as opposed to mouse navigation. No matter how many times I use the disk utility I just can not get used to using it. I have not found any show stopper bugs. I am having an issue in KDE Plasma where the desktop fails to load including the wall paper. The screen is just black with a functional task bar. Simply logging off and logging back in fixes it, so it is just a minor annoyance. Having a dedicated email list and IRC channel for installation related concerns seems like a good idea. I could see it getting used. Tim
Re: testing for rootfs vs. /usr reproducibility regressions
All, Sorry I am a little late to this party so I have a new-be question, what is the point of merged-usr? It seems like a lot of work for a little reward, as the packages already work. Is there a legitimate benefit for changing all these file paths that I am missing? Thanks Tim
Debian package manager privilege escalation attack
All, I just ran across this article https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested the attacks on Debian 11 and they work successfully giving me a root shell prompt. Tim
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
I am fine with Debian's release cycle but It would be nice to see more packages. For example Debian is missing KDE's Amarok music manager. I am happy to see Debian 11 gained KDE Elisa music manager. I am sad to see that VirtualBox is not available on Debian 11. I had to jerry-rig it using the Ubuntu Focal repo from Oracle. OpenSUSE Tumbleweed is a good rolling distro, I am surprised Steam did not use it. OpenSUSE was the repo Plasma Active shipped with. I tried Tumbleweed but I got tired of the constant need to download all of the packages. I am on a metered internet connection and a Rolling Distro is just not for me. Debian needs to have a mechanism like the openSUSE OBS Open Build Service, where people can create Repo's of newer software versions to use with stable Debian. On openSUSE I use the stable KDE Repo's to keep KDE up-to-date with the latest stable releases. Tim
Re: debian 11 Bullseye RC 1
I performed a clean install from https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/weekly-live-builds/amd64/iso-hybrid/ and now everything works. thanks Tim
Re: debian 11 Bullseye RC 1
On 5/29/21, Holger Wansing wrote: > > > Am 29. Mai 2021 18:33:34 MESZ schrieb "Andrew M.A. Cater" > : >>Are you using the unoffcial non-free firmware .iso to install from? >> >>Are you installing firmware-amdgpu from the non-free repository if not? > > Please note that there is no such package with name > "firmware-amdgpu" ! > (You have already been told so in the past.) > > It's named "firmware-amd-graphics". I just found this: https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/weekly-live-builds/amd64/iso-hybrid/ I am going to download and install from this image. Hopefully my WiFi will work if not Linux Mint has drivers so I may download and install it. > Holger > > > -- > Sent from /e/ OS on Fairphone3 > >
debian 11 Bullseye RC 1
All, I just successfully installed bullseye RC 1 on my Asus notebook model X200CA. Everything is working. If you are looking for a notebook to run Debian I highly recommend this model. I installed Bullseye RC 1 on my new HP Pavillion 15-eh0097nr laptop. The AMD Ryzen 4700 is a work horse but the integrated graphics don't work. The WiFi does not work needs kernel 5.12. The bluetooth does not work needs kernel 5.12. For now it will have to stay on Windows... Boo If you are looking for a laptop to run debian I do not recommend this model. I have Debian 11 RC 1 running in a virtual machine with VirtualBox and almost everything works. I am not able to mount my USB drive formatted to EXT4 and SDDM locks up and is unresponsive after locking the screen for an extended period of time requiring a reboot. Can anyone suggest a WiFi USB adapter that works with debian? I have purchased four from Amazon 2 AC 2 N and none of them work with Bullseye. I want one that does not require building my own drivers and has the drivers built into the Linux kernel. Any suggestions would be greatly appreciated. Looking forward to testing RC 2 when it is released. Tim
Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
All, Currently in Bullseye the Realtek 8822CE WiFi adapter is not being recognized. There is a patched driver available at: git clone https://github.com/lwfinger/rtw88.git is it too late to get this driver into Bullseye. I ask because I have a laptop with a 8822CE adapter that is not functional. More info on getting Realtek adapters working: https://easylinuxtipsproject.blogspot.com/p/realtek.html#ID7 Tim
Re: I'm orphan my packages and leave the project as maintainer
The FSF with out RMS would be like the Linux Foundations with out Linus. With their personality quirks it is sometimes hard for some people to like them but at the end of the day they get the job done. RMS has done alot for FLOSS it would be sad to see his contributions come to a halt but he can always write software and contribute that way I guess. On 3/26/21, Pierre-Elliott Bécue wrote: > Le vendredi 26 mars 2021 à 16:50:06+0300, Sergey B Kirpichev a écrit : >> On Fri, Mar 26, 2021 at 02:08:34PM +0100, Pierre-Elliott Bécue wrote: >> > I'm not trying to refrain you from leaving >> >> Well, lets I'll try last time to make things clear as much as I can. >> >> 1) Don't get me wrong, this is the end of story, started not today. >> 2) It's not something like "this hurts me, please do Debian >>great again - or I'll leave". I'm not in the camp of SJW's and won't >>share their methods. > > Well, you're doing so with your first mail which is "I'm leaving and > making a point". > >> 3) It's not an invitation to discuss something with mentioned >>GR and so on. For me, all is clear. > > For me it is not, but I'm glad that it is to you. > >> 4) It's only a technical letter to the technical maillist. End >>of contribution. Period. Do what you should do. > > A technical letter would not contain a philosophical dissertation about > "SJW" and bo-freaking-hoo Debian is bad towards RMS. > >> Please don't CC me. Keep me off. > > Ack > >> > but there are some things about how the project works that probably >> > need to be stated in a clearer manner for the sake of understanding. >> >> My first Debian contribution was ~2007. DM since ~2011. I've read >> DC, Constitution and so on. I had a time to learn. > > I'm happy to hear that you think that you've learnt and understood how > things work here. > >> > A General Resolution is not (yet) a decision of the project >> >> I don't care. > > It seems to me that you care enough to leave. > >> 1) Debian project do political statements for all it's members. >>Or "highly likely" will do. >> 2) There was an attempt to do this even without a GR. >> 3) No guarantees if this will not happen again. Maybe next time >>this will be coordinated on the private (forever?) maillist... > > Well that is the principle of having a community of people with diverse > opinions. I'm sad to hear that this diversity is the cause of such > griefs. > >> > As for RMS, whether one likes him or not, it's not hard to see his >> > public communications and see what things he defended. >> >> If someone won't/can't distinguish his personal opinions and ones on >> behalf of FSF stuff - not mine problem. > > Any organization who keeps at a direction position someone expressing > controversial or unsane opinions is, in a sense, either ignorant of the > situation or encouraging it. > >> > I wish you the best of luck in your future work >> >> Thank you. WBR > > Cheers. > > -- > Pierre-Elliott Bécue > GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 > It's far easier to fight for one's principles than to live up to them. >
Re: BinUtils /usr/bin/ld: cannot find -lGL
All, I added a symbolic link "libGL.so -> /usr/lib/x86_64-linux-gnu/libGL.so.1" and that fixed the issue. Timothy M Butterworth
BinUtils /usr/bin/ld: cannot find -lGL
All, I'm trying to built software with Qt Creator and I get the following error message /usr/bin/ld: cannot find -lGL. I'm running Debian 10 with KDE fully patched to the latest point release. Timothy M Butterworth
