Re: debian/*.symbols files for C++ libraries
Am 29.02.20 um 16:33 schrieb Mike Gabriel: > Until now, I mostly avoided writing .symbols files for C++ shared libs. Solve the problem, but let some maybe important informations pass through. > But I am now. Thanks to all pkg-kde-tools hackers for the symbols > helper. Much appreciated. A maybe a wrong explanation - changes in the symbols mean that a library will not work at some points - may it be because of a changed compiler or changed sources - the result is that the former lib will behave different - and that's exactly my motivation to take care about. And yes, pure c behave better regarding symbols. - I for myself prefer readable symbols, so i made this very small script "symmangle": > if [ -d ./debian ]; then > for i in `find . -name symbols`; do > k=`echo $i | sed "s#/DEBIAN/symbols##" | sed "s#./debian/##"` > cat "$i" | sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' | c++filt | > LC_ALL=C sort -u | tee "debian/$k.mangled"; > done > fi > it's easy to see that it's a simple wrapper around c++filt. > > light+love > Mike > Cheers Alf signature.asc Description: OpenPGP digital signature
Re: Best practices for Debian developers who are also upstreams?
Hi Otto, i'm doing this for years now (LXQt) To sum it up: * there are no special rules, but i suggest to keep your hats strictly separated * if there are some doubts upstream - just think how you would feel with a release with your downstream hat on * if you release something upstream and have to patch it for debian (nuff said :D) * if still in doubt - just make an Arch Linux package - and think about the differences At all, we (LXQt) have learned a lot about licenses, abi and api things and simple no-go's for an reliable upstream. Most of my packages are without any patches, some packages have some ness. overrides for architectures, nothing i could do against. All packages are boring packagingwise - and that's a very good sign. I use the classical way of release tarballs, the workflow is: download, import, pristine-tar, check control, copyright and be done with. In my case up- and down-stream are fully discoupled. If something special happend - new abi, need for package splits, things we couldn't handle upstream - i know it before and be prepared, even packagingwise. So the maintainance is just a breeze most of the time. If you ware both upstream and downstream hats you should ask yourself some questions: * have i really done all the things to make downstream comftable * if not, what could i do to make downstream more comftable * what can i do to make downstream life better in future releases Guess what, other downstreams will love you for. Cheers Alf
Re: Debian With Alternate Init Systems
Am 08.02.20 um 16:15 schrieb Svante Signell: > > Anything else? > Yes, you forget something - as long the discussion culture in Debian stays this way i'm not motivated to start my NM process again. Waste of time to join a bunch of unripe kids. Sorry, but i find no other words with my limited english. Thank you for remind me, will wait maybe another year. Cheers Alf
Re: Integration with systemd
On 01.11.19 02:33, Thomas Goirand wrote: ...the bigger question is: why systemd-sysusers is part of systemd, and not a standalone thing, which we could make an essential package. If we want it to be part of a package standard toolkit, it means systemd becomes an essential package, which isn't really what we want (we don't need an init system in a chroot, as you know). For that reason alone, it's probably a bad idea to recommend systemd-sysusers everywhere. Just file a bug against systemd and request a split out. Done. And i still don't get it. Why should upstream care and put the sources into another project - i don't get it in the discussion about systemd in the past years. If the handling of the sources is so evil, nobody should use *BSD anymore. Cheers
Re: BITS from the DPL For September/October 2019
On Thu, 31 Oct 2019 18:40:58 +0100 Thomas Goirand wrote: > On 10/29/19 11:19 PM, Russ Allbery wrote: > > of clear project guidance, no one is clearly empowered to prevent > > it from bitrotting. What is wrong with bitrotting if nobody cares about - in case nobody cares about it's the logical consequence. And please don't even try to enforce this care. > My understanding is that the current guidance is that doing init > script isn't mandatory. What is mandatory, is to ACK init scripts / > patches when contributed (through the BTS). I read it the same way - and also a logical consequece: if these patches lead to bugs, the maintainer should not be forced to fix the mess. I for myself would just remove buggy things that nobody care in a certain amount of time. > I think that's fair enough for everyone, and I don't see why we need > to change anything to this rule. Dito > Make what deferred decision? That we want to actively dismiss patches > adding init script support? This IMO would just destroy any work > attempted in the non-linux ports, or anyone willing to add support > for a new init system. I don't think that's fair for these. Voting > them out would not feel right. See it different: if the provided scripts/patches are good, why not take and keep them - systemd users are not hurt. If the scripts/patches don't work - ignore the upcoming bugs and downgrade everything about to whishlist - or if interested in: Fix the bugs. Default will work and good. And i don't want to provoke, i see it exactly this way, if people spend time one something, why blocking or discourage if it do no harm. I even merge patches for kfreebsd and the hurd upstream - but i would never active work on it. > As much as I understand, we never wrote or decided we would. We just > need to accept patches to add or fix sysv-rc scripts. What makes you > think sysv-rc scripts are mandatory? Good question - if these things are not mandatory nothing needs to change. > > Thomas Goirand (zigo) > -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Bug#942741: ITP: lxqt-organizer -- LXQt Pim, right now only an basic organizer
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-organizer Version : 0.1.0 Upstream Author : crispinalan * URL : https://github.com/lxqt/lxqt-organizer * License : LGPL Programming Lang: C++ Description : LXQt Pim, right now only an basic organizer The LXQt Team will maintain the package
Re: source only upload with git-buildpackage
On 06.10.19 08:18, Attila Szalay wrote: > That option means that the system will create not only the binary > .amd.changes but another changes too which contains only the source > packages. And I would like to use this method to be sure the package > compiles, to be able to run the lintian against the package and even > be able to test it before the upload. > Sounds cool, right now i use a different workflow: Build and sign source packages and send them to pbuilder (different machine) - build in two architectures, lintian is part of the build process, pbuilder hook. So i was a bit irritated :) Cheers Alf
Re: source only upload with git-buildpackage
On 05.10.19 23:14, Andrey Rahmatullin wrote: > On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote: >>>> that is miss something - my point is: Why do you invoke pbuilder (read >>>> the same question about sbuild too) to create pure source packages? >>> To make sure they build correctly. >>> >> Ok, checked the calender, it is not April 1. I'm out. > --source-only-changes doesn't mean "only create the source package". Maybe i have a general problem in understanding the gbp workflow - thanks for the explanation.
Re: source only upload with git-buildpackage
On 05.10.19 21:48, Andrey Rahmatullin wrote: > On Sat, Oct 05, 2019 at 08:06:56PM +0200, Alf Gaida wrote: >> that is miss something - my point is: Why do you invoke pbuilder (read >> the same question about sbuild too) to create pure source packages? > To make sure they build correctly. > Ok, checked the calender, it is not April 1. I'm out. Cheers Alf
Re: source only upload with git-buildpackage
On 05.10.19 19:48, Attila Szalay wrote: > Hi, > > I'm struggling with it for a while now and I couldn't find the > solution. I have a package maintained with git-buildpackage. And now, > that I "cannot" upload binary packages I tried to compile the new > version with the option to create a source-only changes file too. But > for some reason that changes files are not created. > Ok, not uploading binaries is default now, isn't it? Maybe i don't understand your question right, but i've created my needed source packages yesterday with: gbp buildpackage -S and uploaded them - ok, i use gbp only for a month now so it might be that is miss something - my point is: Why do you invoke pbuilder (read the same question about sbuild too) to create pure source packages? Cheers Alf
Re: GPL for package under MIT license upstream; repack?
Sorry Gary, i just make a mistake - you can't relicense MIT(X11) stuff - it would work only with some BSD files. You could modify the license (just as in ncurses) and be done with - i would like to recommend not to do so. Cheers Alf
Re: GPL for package under MIT license upstream; repack?
Plain no. If they are really interested they would know that they can use every MIT part under GPL because of license compatibilty. Things change dramatically if you would consider to change the licenses of the files - if one would contribute to your now forked files the original project would have hard times to use your (hopefully useful) changes because they could not port back (license incompatibility) So - it is up to you. Cheers Alf On 24.09.19 21:30, Gard Spreemann wrote: > Colin Watson writes: > >> On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote: >>> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and >>> including the current version in the archives. Since then, upstream has >>> switched to an MIT license, but with the caveat that many parts of the >>> code has GPL dependencies and that "for practical purposes this code is >>> GPL-3 for the user" [1]. >>> >>> Instead of having to carefully figure out precisely which parts of the >>> code should be considered GPL for the Debian package, I'm tempted to >>> consider the whole codebase GPL for this purpose. >>> >>> Does this sound sane? Are there some particular steps I should follow? >>> Should I create a Debian repack of the source where every file's >>> copyright header reflects the above, or do I only need to do this for >>> (header) files included in the binary packages? Or does it suffice for >>> d/copyright to reflect it? >> I don't think you need to (or even should) change the licence notices on >> individual files. > But if I don't even change this in the header files (installed with > libgudhi-dev), isn't there a significant risk that I will mislead Debian > users into thinking that they may use every part of the GUDHI library > under the MIT? > > Best, > Gard >
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On 15.09.19 00:05, Russ Allbery wrote: > We have more agreement here, although there are a lot of details hidden in > what "forcing" really means. But there's a huge space between "don't > force other people to use non-free software to contribute to Debian" and > "forbid using non-free software within the Debian project." > > I feel like I can say with a very high degree of confidence that we're not > going to do the latter. For instance, we're not going to stop using Intel > and AMD processors in the Debian project, even though they are full of > non-free software. So whatever policy stance you're aiming for here needs > to be a lot more nuanced than how you're presenting it. > Thank you Russ for your insightful words - it's like a beacon in the night and let me try to trust debian at all more than i do right now. To be honest about, i have not much trust in anyone, but your posts over the last decade helped me to build something like that. Thanks Alf
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
Thomas Goirand wrote: > As long as you push to Github *for yourself* (ie: not in order to > share the repository with other people form the Debian community), > that's fine. But forcing it to others is not acceptable. > > Thomas Goirand (zigo) Thomas - what you want to achive? Right now i'm affraid of you and others who share your opinion: There will something happend as result: * i will consider that my view on debian was just false * i will move all my packaging to github or gitlab - the service don't matter, but it will make sure that i can have my workflow after the GR * it will not hurt debian directly, because i will mirror the repo's to salsa * there will be nice improvements in sense of my workflow coming with it: i will only accept github PRs - nothing else. I will only use github issues - because after such a descision i will suspspect the debian bts as not trustworthy at all - i will have my packaging in a safe haven - and don't have to care how nuts the outcome of a GR will be. Hey - if you really want it that way, you layed out the first few meters of the new debian road. Before i forget - if your plans happend, i will be verbose about - with every contributor who will left debian alone after me. Promised. Before there are false assumtions that i'm searching any consensus in this unbelivable bullshit - no - i don't. I'll only stepping aside and see debian and debians ideas die. An cry silently. Thats all. Alf -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On Sat, 14 Sep 2019 00:51:16 +0200 Thomas Goirand wrote: > Sorry, WHAAAT ? That's shocking to read this from the DPL. > Are you sure you didn't do a mistake in this sentence? Sorry, Sam is right, he just read and understand the DSC $1 right. If one work on Debian with non-free tools that will not make the result non-free. > There's absolutely no problem within the Debian project to forbid > using non-free software. That's what I've signed-up for (ie: "debian > will remain 100% free", aka the FIRST LINE of the social contract), > and what I want, and I'm sure the vast majority of DDs agree. Nope, you signed up that debian will remain 100% free - not for the tools people work with. And if debian would forbid the usage of non-free software to work on some code - i would be the first to leave the project. I don't use much non-free beside my graphics drivers and some firmware - but nobody is entitled to forbid me to use bcompare or github or maybe a commercial editor - nobody has the right to dictate my tools. Regarding the software: Software has to be free and should not depend on non-free tools - but to forbid non-free tools if there are equiv. free interchangeble tools is far over the top. --- snap --- > On 9/13/19 9:39 AM, Enrico Zini wrote: > > This cannot be the discussion culture of a group where I can be > > comfortable working with others. Fully agree. > I'm feel sorry to read these lines, though, I don't see how we can > compromise on how much free Debian should be. I'm very surprised read > you're not comfortable working in a group where some of us are > pointing this out. Now, this makes *me* uncomfortable. That's not > what I thought Debian was about then. I thought we all signed up on > "Debian will remain 100% free"... How come we don't have a strong > consensus on this then? Have some of us just given-up on software > freedom? And again - i'm not comfortable with this reading of §1 - like it or not - if your opinion and reading is the consensus and supported by the majority in debian it will be time for me to leave as fast as i can and don't look back. Would make me a bit sorry for the then wasted years - but hey, life goes on. And i subscribed the same things as you do and had no problem to do so. I'm all for free software, i spend the very most of my spare time to it - not only in debian. But if the official reading will be your interpretation: Sorry, i'm out, can't and will not follow - in that special case there will be some projects that fit my needs better. Cheers Alf PS: Please read this in the context of my former posts - this discussion would not happend if all the packages are hosted used debian infrastructure - and i'm dead set against using non-free infra in debian. One exception: I don't consider firmware and processor patches as Software in the sense of DFSG - so the servers we are running should be allowed to use the newest firmware and processor patches they need) Cheers Alf > Thomas Goirand (zigo) > -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On 13.09.19 17:55, Russ Allbery wrote: > There seems to be an obvious ordering issue here, namely that it's very > weird to insist on the first (which has been the topic of this thread) > before we insist on the second. I wouldn't see it as an ordering issue - my POV is that each of these issues is independend. Maybe it is just wishful thinking - but it would not really matter, in which direction these issues would be addressed. If i should setup a priority list it would be: 1) all packaging sources must be hosted in debian infrastructure (no matter in which way) 2) all packages should use a SCM (no matter what) 3) finally (maybe) consider git as the only supported SCM Each of these three points is controversial - i know. But it would be a nice goal. Cheers Alf
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On 13.09.19 15:10, Simon Richter wrote: > Hi, > > On Fri, Sep 13, 2019 at 02:51:47PM +0200, Alf Gaida wrote: > >> Is it really so hard to understand? Github, Gitlab and other service are >> just tools. I don't care if they are free or non-free. > For Debian, free software is kind of important. > >Simon Simon - if you cite me, you should cite the relevant part. Really, the text wasn't that long: > Is it really so hard to understand? Github, Gitlab and other service are > just tools. I don't care if they are free or non-free. No account, no > participation. And if you had read the whole post - imho the best > outcome woul be: No hosting of Debian packaging outside Debian > infrastructure. Second thing i would prefer: Packaging has to use a VCS > supported in the debian project. If it boils down to: We support only > git in our infrastructure - fine. No hosting outside of debian means: One has to use Debian infrastructure - and we only use services we consider free, don't we? So it's is not relevant if other services are free or non-free. It wouldn't matter. Cheers Alf
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On 9/13/19 10:18 AM, Bastian Blank wrote: > On Thu, Sep 12, 2019 at 06:34:42PM +0200, Alf Gaida wrote: >> Regarding the workflow and participation - it might be a problem that >> one need an account for github or other non-free services - it's easy: > You also need accounts for _free_ services, so what do you want to say? Is it really so hard to understand? Github, Gitlab and other service are just tools. I don't care if they are free or non-free. No account, no participation. And if you had read the whole post - imho the best outcome woul be: No hosting of Debian packaging outside Debian infrastructure. Second thing i would prefer: Packaging has to use a VCS supported in the debian project. If it boils down to: We support only git in our infrastructure - fine. Cheers Alf > > Bastian >
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On Thu, 12 Sep 2019 08:47:49 -0400 Sam Hartman wrote: > That said, I'm really confused that your message didn't get any > response before now. Considering how sharp some of the responses > were on -project, I don't know how to take this. Were people not > responding because the -project discussion was so recent, they didn't > see a need to rehash it? Were people not responding because -devel > has a very different audience and everyone here agrees with you? That's really easy: Most people aviod harsh or sharp answers, i'm not. And to be honest, i don't really understand all the discussions about git. It's just a tool - and most of the time misused in debian. Not that i'm the biggest git expert on earth - i'm only a happy user for ten years now. And the ten years include bitbucket, github, gitlab, gitblit, gitea, gitolite, gerrit and so on - so it is totally irrelevant to some extend where things are hosted, it remains git in the very end. Regarding the workflow and participation - it might be a problem that one need an account for github or other non-free services - it's easy: No account, no participation, bad luck. In one thing Ian is right: Debian packages should not be hosted on non-free services. I would go a step further: No Debian package must be hosted outside of debian. Period. Problem solved. That would prevent problems like the ones with debian live hosted by Progress Linux, LXDE packaging hosted on https://git.lxde.org (broken for some month now) and so on. Would really make sense, but is a different story. Another though: If we start not to allow packaging on non free services and using non-free tools - what would be next: Considering projects that use non-free services like github or bitbucket as non-free - in this case please drop the whole LXQt from debian, we will continue to use github.com in near future and are not planning a change right now. Cheers Alf -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: should Debian add itself to https://python3statement.org ?
On Thu, 12 Sep 2019 16:01:54 +0100 Ian Jackson wrote: > That statement is a *pledge* to drop support for python2 by the end of > 2020. Have we in fact made such a pledge ? I think I may have missed > the memo that python2 would be removed from bullseye. > ""He's dead, Jim" (Doctor Leonard McCoy) > I did some searching and found this > https://lists.debian.org/debian-python/2019/07/msg00080.html > which is a sane-looking transition plan but doesn't seem to have a > timeframe and doesn't seem to contemplate removal of the actual > python2 interpreter. It doesn't really matter. In fact python2 is dead for years, if we start now to make a plan we are years to late. The timeframe is _now:. > FTAOD I don't have an opinion about whether bullseye *should* ship > without python2. Obviously dropping it would not be desirable from > users' pov, but maintaining an ancient thing by ourselves would not be > desirable either. I think I trust the Debian Python team to make that > tradeoff. I have an opinion. If we define stable following Jack Cohen, python2 can stay forever - if you forgOt: There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen > But we need to be clear what's going on and communicate early. If > python2 is going out of bullseye then there are a lot of bugs that > should probably be marked rc fairly soon... We can't do better now - planning of the removal and preparation for would been a task for the buster release cycle - this chance is gone. But is is no reason to remove dead things now. And the last reminder is the python clock: Let me copy and paste the content of https://pythonclock.org/ at the time of writing: > Hell, yes, Python 2.7 will retire in... > 0 > Years > 3 > Months > 19 > Days > 4 > Hours > 59 > Minutes > 44 > Seconds > > > What's all this, then? > Python 2.7 will not be maintained past 2020. Originally, there was no > official date. Recently, that date has been updated to January 1, > 2020. > This clock has been updated accordingly. My original idea was to throw > a Python 2 Celebration of Life party at PyCon 2020, to celebrate > everything Python 2 did for us. That idea still stands. (If this > sounds > interesting to you, email pythonclock...@gmail.com). > > Python 2, thank you for your years of faithful service. > > Python 3, your time is now. > > How do I get started? > If the code you care about is still on Python 2, that's totally > understandable. Most of PyPI's popular packages now work on Python 2 > and 3, and more are being added every day. Additionally, a number of > critical Python projects have pledged to stop supporting Python 2 > soon. > To ease the transition, the official porting guide has advice for > running Python 2 code in Python 3. > Only another harsh comment: So what do you expect - i kown this page from the beginning. If it is surprising for the Debian project that these guys are serious about it we really should adjust the perception of the environment around us. I for myself have two important python2 projects that are not migrated right now - and i will migrate them if really needed because it is no fun to do so - so it depends on Debian - but i'm dead without both projects, so i'm in fact prepared, only to lazy to do it now. > thanks, > Ian. > Cheers Alf -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Bug#939796: ITP: lxqt-kcm-integration -- Integration package for several KDE control modules into LXQt
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-kcm-integration Version : 0.0.1 Upstream Author : Alf Gaida * URL : https://github.com/lxqt/lxqt-kcm-integration * License : (LGPL2+) Programming Lang: (desktop files) Description : Integration package for several KDE control modules into LXQt Right now the set of controls include: * KCM KWin settings * KCM Appearance * KCM Bluetooth * KCM Systeminfo The package will ease the pain when $user descide to use kwin with LXQt. The LXQt packaging team will maintain the package.
Re: Consensus Call: Git Packaging Round 1
Am Mittwoch, den 28.08.2019, 17:57 +0200 schrieb Thomas Goirand: > However, there's still a way too much web interaction with it, compared > to what we do with a simple "git review" with gerrit. Not we - you. Please don't expect that people have the same opinion. I like any kind of nice interfaces. This is not only related to webinterfaces. Next fact: We don't have gerit. And only my opinion - everytime i was forced to work with gerrit it was a horrible experience. > If I have to choose between the BTS and the stupid web interface of > Gitlab, then I very much prefer the BTS. The stupid web interface of Gitlab is ok for about 95% or more of all cases. Most of the work in debian isn't exactly rocket science. For the remaining few percent i would suggest to use pure git. But tastes differ. So not a real world problem. > > Cheers, > > Thomas Goirand (zigo) > Cheers Alf signature.asc Description: This is a digitally signed message part
Re: Consensus Call: Git Packaging Round 1
On Tue, 27 Aug 2019 15:35:37 -0400 Milan Kupcevic wrote: > I fully agree with the initial best practices proposal stating that > merge requests in salsa have to be attended to or otherwise this > feature has to be disabled as per package maintainer preference. I only stated that the Debian BTS feels like stone age - but i see no replacement for when i look into things like Gitlab or Gitlab "bugtracking" - i suggest we should only discuss possible git workflows here - gbp is already invented, switched all my packages to. The only thing i don't use right now is the changelog functionality, this will come later. And with right written commits it should work well with the Debian BTS - so best of both worlds. Cheers -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: Consensus Call: Git Packaging Round 1
On Tue, 27 Aug 2019 14:52:01 -0400 Sam Hartman wrote: > And as Sean pointed out, it's hard to understand the history of the > changes and comments after they hppened. What happens when I'm trying > to review a MR three years later and the MR was rebased 4 times during > the lifetime of the MR prior to merge. > > You may not care about that, but others do. > > That's why there are interesting trade offs to balance. > > --Sam To be honest, i find it hard even to read my own code after one, three, ten or god beware 30 years - have done so several times. Ok - i had no problem with the 30 y.o. things and pull requests - there was no SCM involved. -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: Consensus Call: Git Packaging Round 1
Am Dienstag, den 27.08.2019, 19:18 +0200 schrieb Adam Borowski: > New stuff is always better. Go Electron! > Like it or not - the idea of pull requests (Github) or merge requests (Gitlab) isn't exactly new. It might surprise you that people outside of debian are used to use it a lot. Anyways, it's the method i like most if available. If not available the good old patch via mail is ok too. There are things i really like about PRs or MRs - they can be reviewed, commented, changed without problems and fast. Just a "new" workflow. I can talk only for myself, but i really like it - it speeds up development if used right. Cheers Alf signature.asc Description: This is a digitally signed message part
Re: Consensus Call: Git Packaging Round 1
On Tue, 27 Aug 2019 16:08:59 +0100 Ian Jackson wrote: > I think Sam's proposed change would be to document in the DR that a > maintainer should handle change requests (including code > contributions) sent to the BTS. That would surely just be documenting > our existing norm. It seems to me that if you want to change a norm, > it is up to you to argue for it. > > > Please remember that it should be easier and more fun to contribute > > to Debian. Keeping packaging in the stone age jsut because some > > people still live there is not what you should strive for. > > Please avoid pejorative language like "stone age". Nicer would be "lowest common nominator" but "stone age" describe the process of sending patches via BTS very well. Upps, sorry, not only the process, but the BTS also. We have git, we have salsa, it seems to me that using merge requests is common sense and should not need any mention. Otherwise - if one is happy to send patches via BTS - why not, as long one don't bother me with. And this it a two way thing - i will not bother other people with patches via BTS (nicer for: if not in salsa, gitlab or github, no contribution, no patch) Cheers Alf -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
On 09.08.19 12:06, Ansgar wrote: > > Having sysvinit might make things a bit easier for Hurd/kFreeBSD, but > it's not an absolute requirement for such a port to exist. > > Ansgar > Thanks Ansgar, this is the user deep in me - i like things to easy as possible. More verbose: I will apply all patches for the Hurd or kFreeBSD as soon as possible in my packages and upstream if possible and will continue to do so. The other thing is: God damn, i want to able to run a Hurd or kFreeBSD desktop system on my hardware as soon as possible :D - it was possible for a mere human with kfreebsd before, right now it is not so easy anymore Alf
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
On 09.08.19 15:51, Tomas Pospisek wrote: > > FWIW (I mean it, this is just anecdotical evidence): I have been > recently upgrading a lot of containers and host and I have been unable > to make lxc guest with systemd inits even start. > > Also, I have been having problems with ssh sessions taking 25 seconds to > start on the remote side because of systemd and pam trying to initialize > some systemd user session. > > I gave up on understanding both of those problems after an hour or two > of research on each. After all, machines were down, automation was not > working I had to get the stuff running again. > > So at this instant I can't see sysv going away because there's too many > things not working in practice on my systems with systemd. > *t Tom, you are not alone. I use LXD with lots of containers - and i had a) to use Ubuntu as host because LXD is not in debian yet b) LXC is more fun with an LXD daemon Some services still have problems, right now in all of my installations i have a problem with redis - it just don't work with systemd inside of the container. Filed a bug, the bug was closed without a solution in debian, there is no solution in upstream nor in systemd - so my solution was: a) give some silent swearwords to the involved parties b) give a fuck about the reaction of the redis debian maintainer c) delete the not working systemd service file and activate the service over the fallback in init.d More verbose: I used the f* word before and i will continue to do so. Beside of that: * i don't care about any init systems as long they work predictable * for my use cases systemd works far more predictable than sysv * there will be some things that are not optimal in systemd right now - so what, let fix them * same for sysv - as long sysv scripts are in debian package they should be as bug free as possible The ultima ratio for me (and i guess for the vast majority of user) is: I like working software - so lets build working software. It might be that some things right now don't work like expected, so improve these things if possible. Cheers Alf
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
On Thu, 8 Aug 2019 19:10:42 +0200 Simon Richter wrote: > For servers, the benefit is rather limited. There is no local user who i don't agree - systemd just work™ in the most cases. Without changing a bit. > The "desktop" and "server" use cases are so vastly different that it > doesn't make sense to try to squeeze both into a single design, No. They aren't. > It is way more useful to have multiple alternatives that fit their > respective use cases well than one thing that attempts to do > everything. No. > > So then the question boils down to what kind of feature > > development sysvinit *in Debian* is willing to do to do that. If the No, it don't. We need sysvinit for some non-linux things and some enthusiasts that are not switched to devuan yet - it would be sane to abandon sysvinit, kfreebsd and the hurd alltogether or split them out. Only my point of view. > The sanest thing we could do in Debian is to teach start-stop-daemon > to parse systemd .service files and pull its command line arguments No. The sanest thing would be to consider systemd as winning system and improve it - and let sysv bitrot. > For that to happen, we'd have to define .service files as an API > though, which would feature-freeze them, and I'm not sure the systemd > people would be happy about that. No one would be happy about. Blocking upstream development or trying to be more clever than upstream is generally a bad idea. And i really like the idea. > System-wide systemd-only services past the early boot stage are just > bad design, do not currently exist and we shouldn't encourage their > creation. And why. elaborate it a bit more ... Cheers Alf PS: I'm not a systemd fanboi - i just use it - and i'm happy that it goes out of my way most of the time - on desktop and servers. And i'm an old fart, so i know the time before systemd well - to be honest, if someone would turn back time i would abandon Linux and go back to some sane system like Windows. I just don't want one minute on sysv anymore. In Linux it is dead for the vast majority - and i'm thankful for. -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
On 07.08.19 19:00, Marc Haber wrote: > Marc, who is trying to have neutral view on systemd and has managed to > be seen as a fanboi by systemd haters and as a hater by the systemd > community, and now fully expects the CoC to be used to be silenced Marc, i don't hope so - you are not alone. For me systemd is one of the best things ever happend to Linux. That doesn't mean that all people has to be happy about. Long story short: I can't hear it anymore - there are reasons why systemd exist and why it is superior over some other init systems for some use cases. It might be an incident that all the my use cases are covered today. And there will be other use cases that are not covered yet or never will be covered. I read in my early youth that the australians say: "Show me!" if they don't belive in something - right o, for me and my needs systemd has delivered. Cheers Alf
Re: dgit advocacy again (Re: Survey results: git packaging practices / repository format)
On Wed, Jul 03, 2019 at 01:49:13PM +0100, Ian Jackson wrote: > The main difficulty now with getting dgit push adopted is that > maintainers don't see the benefit *to themselves* and it is always > harder to get someone to see a benefit *to someone else*. Ok, that describe me. I see benefits in an optimized git workflow for *me* and maybe for *someone else*. But right now i don't get the point where dgit can help me. Maybe i'm just ignorant. Ok, i right now don't get the point of gbp fully. Especially, it can be hard to convince people of the reality of a benefit to someone else, which they perhaps ought to provide, if it would involve them having to change the way they do things... Fair point: So let's talk about. * Getting released sources: uscan and pristine-tar are my friends - what can dgit do better? * Creating a upstream/latest branch - questionable action, do it for years now - and really see no benefit in it. Was the team workflow since 2015, does not hurt much, so i don't changed it. * Cherry picking latest release into the sid- or experimental branch. Where can dgit help me or others? * Do the needed changes in debian $foo, commit, push, tag, push tag. Same question. These things are not rhetoric - right now i use three scripts from a package that was former in debian - git-stuff. Unfortunately discontinued. So i'm in search for a tool to make my life easier. Cheers Alf
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
It will confuse me because in 2021 I will expect release 2021 . Furthermore, will .7 stand for July ? I assume it's about point releases (which, again, Ubuntu doesn't do AFAIK). The keyword will be education - i wrote some times ago: Let people use wht they are happy with - it will take a blog entry or two to let users know what 20xy.z means - i can't resist and bring it to the point: If there will be a release 2020.0 and 2020.1 - and there will be release notes - do we really assume our users are to dumb to get it??? Cheers Alf
Re: getting rid of "testing"
Only a last thought: Didn't we have really important problems to solve? It might be only me, but i see the discussion as a minor variation of bike shedding. To sum it up: Some people like codenames, some not, same for numbers - the real question is: Does it really matters? Over and out Alf
Re: getting rid of "testing"
On 25.06.19 17:48, Michael Stone wrote: oldoldstable has the value of demonstrating some of what's wrong with the current system Can you please explain, i don't get it - maybe i to new at this. For me file like /etc/apt/sources.lists.d/debian.list: deb http://ftp.debian.org/debian/ oldoldstable main contrib non-free deb-src http://ftp.debian.org/debian/ oldoldstable main contrib non-free deb http://ftp.debian.org/debian/ oldstable main contrib non-free deb-src http://ftp.debian.org/debian/ oldstable main contrib non-free deb http://ftp.debian.org/debian/ stable main contrib non-free deb-src http://ftp.debian.org/debian/ stable main contrib non-free deb http://ftp.debian.org/debian/ testing main contrib non-free deb-src http://ftp.debian.org/debian/ testing main contrib non-free deb http://ftp.debian.org/debian/ unstable main contrib non-free deb-src http://ftp.debian.org/debian/ unstable main contrib non-free deb http://ftp.debian.org/debian/ experimental main contrib non-free deb-src http://ftp.debian.org/debian/ experimental main contrib non-free deb http://incoming.debian.org/debian-buildd buildd-unstable main contrib non-free deb-src http://incoming.debian.org/debian-buildd buildd-unstable main contrib non-free deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main contrib non-free deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main contrib non-free deb http://ftp.debian.org/debian/ stretch-backports main contrib non-free is perfectly fine. So it is possible for me -- strictly running sid with buildd on _my_ production system -- doing things like: % apt policy nano nano: Installiert: 3.2-3 Installationskandidat: 3.2-3 Versionstabelle: 4.1-1 1 1 http://ftp.debian.org/debian experimental/main amd64 Packages *** 3.2-3 500 500 http://ftp.debian.org/debian testing/main amd64 Packages 500 http://ftp.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status 2.7.4-1 500 500 http://ftp.debian.org/debian stable/main amd64 Packages 2.2.6-3 500 500 http://ftp.debian.org/debian oldstable/main amd64 Packages and so on - i take the older releases only as reference. So for me there is a use case, i'm not interested in older versions as old or oldoldstable - and i will never change this file without reason. Cheers Alf
Re: getting rid of "testing"
Only a few remarks as former simple user and now maintainer: * Please don't mix things: release names has a value, distribution names like oldoldstable, oldstable, stable, testing, unstable has their value too * the value is that they never change - they are convenient. Especially if one use unstable most of the time, please think of such things like `apt policy $foo` - it is highly unlikely that a sid user want to use old stuff, but will ask from time to time about versions ... * using the release names is convenient to set up systems before the release is done - i can set up a "buster" system now and have to change nothing when it become stable. The other way around is not a good way to go. At all - using distributions like "testing" or "unstable" should mean that the users/admins in charge can handle it - if not they should learn it or never ever do such things again. Might sound stubborn, but hey - i learned it this way. As a user of a rock stable "Sid" system i see no big problems for ten years now - ok, maybe to resist this: Hmm, what will happend if i will hit now ... Cheers Alf
Re: Bits from the DPL (May 2019)
> A guest account in Debian LDAP does not get a Salsa account, at least > not an usable one. Currently only users in the Debian group are > allowed.Hmm - so salsa is useless at all - i don't think so. Change your pov and see it otherwise: A guest can open a project - all members of the Debian group have no saying and no rights. Some would call it nice and the best outcome ever. Joke aside: If i want to have any rights as a DM in some repositories i contribute to i had to ask for polite - no problem for me, as the very most people in Debian are very kind. Same is for Debian Developers when they want to provide to a project that was started by a DM - just fair, isn't it? >> There are transitions like someone retiring from the project where we >> actually would be delighted if they continued to use salsa in some >> capacity.The rights to use salsa should not be coupled with the status as DD, DM or whatever - imho different things. The outcome is: People bitten by this will put their repos on github, gitlab or whatever. Do we really want this as a project? Imho no, if these issues could be solved i would go so far that i would expect that packages in debian are managed within debian infrastructure - SCM included. > The largest technical problem with that is providing the user with a > valid e-mail address. Apart from that we need DSA to properly define > states in LDAP.If it is only a technical problem - solve it.> >> Making the transition from foo to foo-guest is currently incredibly >> expensive for the person involved. > > Yes, it is. > >> This is one of the issues we will discuss later this month. I hope the >> salsa admins will join that discussion. > > Well, you could just ask. > > Bastian > Cheers Alf
Re: Do we want to Require or Recommend DH
I think such a GR would be a collosal waste of time. This issue is not important enough. In particular, because the consensus is *not* GR's can be man made a collosal waste of time. Well, a GR can be quick and it would help to know where people stand instead of having a few vocal people decide for everyone. I think we should impose the use of "dh" for bullseye (with an exception for teams with more then 50 packages), but I honestly don't know how much this opinion is shared. I followed the discussion closely but i don't get some points. I assume that "dh" is here to stay - so in that case new packages should be done with "dh", older packages should be converted. There might be some packages which are not worth the additional work. Just leave a note why and everyone is happy. So a GR would be a appr. tool to solve this endless discussion fast. last "technical" GR was for systemd in 2014. We are in a project where it is very hard to be heard because you can only participate in endless debates. I for myself have no time for endless debates - i have things to do in Debian and upstream. And it's just boring to read the same arguments pro and esp. contra again and again. I was quiet until now because the debate don't change anything for me firsthand. I use dh for all my packages already and don't think i will change it in the future. The very most packages i'm interested in are dh - so no problem for me to read and maybe fix them if needed. Will i touch complex things written in cdbs? Hell no. Will i touch other complex things not in dh - hell, no, not worth the time. One might think of as a bit stubborn or short sighted, but to be true: It's lack of motivation - learning a bunch of things i'm not interested in to change things i'm not that interested in? Sounds nuts. A solution could be: Deprecate some thing like cdbs an others if they are really deprecated, be verbose about why and don't let packages that using these things go into the repository. Can be done stepwise. My 2¢ Alf
Re: Do we want to Require or Recommend DH
On 13.05.19 15:39, Holger Levsen wrote: Maybe we could also make the "should" stronger: - new packages (except if they are ment to become build-depends of debhelper)*must* either use dh or cdbs. - old packages should be switched to dh (or cdbs). And then turn this "should" into a "must" for bookworm (and thus make it RC then as well). Thanks Holger, couln't write it better, fully aggree. Cheers Alf
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On 13.04.19 15:07, Andrey Rahmatullin wrote: On Sat, Apr 13, 2019 at 12:59:19PM +, Holger Levsen wrote: I see no point whatsoever in 3.0 (native). What's the point/advantage of native packages? No need to make a separate orig tarball. Can't agree more, there are places where 3.0 (quilt|git|anything esls) don't make any sense, think about meta packages with no upstream tarball and such things. And i wouldn't consider 1.0 bad or smelly, i use it on a regular base for git based builds in my experimental snapshots, it's simply the best format to do so (just put the new sources in and be done with) Cheers Alf
Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
DUR is fine, DPA is fine PPA is not - as it is used before in a totally different context. The idea just to require git is really nice, putting all the things into a single file is not. Not even Arch does it. (patches, install, config ...) - so the default debian dir should be enough. Please think a bit further - which files are really needed? * control * rules * watch There was discussions to make rules obsolete in standard packages - if there is no rules file, just assume/use the default. compat is obsoleted if one use debhelper-compat, copyright would be nice to have, but might not be needed for a possible dur. Same for all other things. Things become a bit different if one want to use patches. So why don't use the debian standards. Same for packages that result in more than one binary package. If anything else fails just add a file with a special set of things for the DUR/DPA - should be dead easy, i use something similar for years now to build things from several git sources. Cheers Alf
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On 07.04.19 17:40, gregor herrmann wrote: I'm one of those people. And I still don't know what "an AUR-like service" is, or what "packaging scripts" are. After reading the intro at https://wiki.archlinux.org/index.php/Arch_User_Repository I guess, translated to Debian terms, we are talking about user-provided source packages? Cheers, gregor Maybe a simple example of how things could work - the AUR consists of several things * the website https://aur.archlinux.org/ * the git repo * some not official (and not really needed) helper scripts The wiki put it in the best possible way: Users can search and download PKGBUILDs from the AUR Web Interface. These PKGBUILDs can be built into installable packages using makepkg, then installed using pacman. Let's take lxqt-about as example: It is both in the regular archlinux repository and in the AUR: * https://www.archlinux.de/packages/community/x86_64/lxqt-about * https://aur.archlinux.org/packages/lxqt-about-git/ So - what is the difference in this case: the community repository points to the release, the AUR package points to git master. The packaging consits only of the PKGBUILD aka the "build script". Thats all. One can download these scripts and build with a simple `makepkg`. After building the package one can install the local packate with pacman: * Repo: pacman -S lxqt-about * local: pacman -U lxqt-about*tar.xz And thats the whole magic - the only thing that the arch guys host is the PKGBUILD, maybe some patches and install instructions. So they don't have to care about any licensing or limitations - they only host the receipe. For debian it could work the same way - just host the debian dir and be done with. Iirc the kde team work this way, they have only the debian dir in salsa. With a modified watch file it should be possible to get any source one want to. So the "only" thing needed is the infrastructure to host and maintain these repos. The rest is up to the user and a fundamental different approach as launchpad and ppa's. Cheers Alf PS: Please don't hit/yell at me if i've overly simplified some things. :)
Re: usrmerge -- plan B?
>> I think it would be good to hear from any derivatives in this >> position. We should probably ask them more formally than by having a >> horrible flamewar on -devel ... With my siduction dev hat on i want to have usrmerge as soon as possible. Built the last months with usrmerge activated and can't see any downsides. Ok, we had to modify some things in our iso build process and some minor things in our scripts, nothing important. So we will have indeed the situation that new systems will be usrmerged, old systems not. We will solve this the nice way: We will strongly recommend to merge and help with problems. If all things go well - there will be no reports, if things go south, expect some bugs filed together with patches. > I don't mean that I'm unsympathetic to downstreams in that situation, or > that I wouldn't want to help them; only that their plight /should not/ be an > obstacle to Debian doing the right thing. We switched to systemd before debian, i guess we will switch before debian in the usrmerge case - i don't see any problems doing so. Cheers Alf
Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)
On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote: > The experimental distribution is a good place for work in > progress. Maybe the rules for automatic rejects can be relaxed for > experimental so a package can go into the archive (and have e.g. the BTS > used for that version) if the maintainer doesn't want to fix the reject > right away. I see a problem with relaxing the rules - if a project is in experimental one could (theoretical) upload it to unstable too - without any changes, because it is in the repository. Beside of that i applaud it if uploading to experimental with relaxed rules would be possible - esp. the possible BTS usage would be nice. signature.asc Description: OpenPGP digital signature
Re: changing git tags on the remote repo
git push --tags --force - if one have the needed rights and the remote settings allow it. Cheers Alf
Re: Should the weboob package stay in Debian?
Wow - we should wait a few days and there will be more comments about this issue than users of this package. Impressive. To be honest - i don't really like the "humor" and the names of the package and the applications, but i fear that this heatened discussion does more harm than the package itself. My 2 ¢ Alf
Bug#904224: ITP: feathernotes -- FeatherNotes is a lightweight Qt5 hierarchical notes-manager for Linux. It is independent of any desktop environment.
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: feathernotes Version : 0.4.5 Upstream Author : Pedram Pourang, a.k.a. Tsu Jan tsujan2...@gmail.com * URL : https://github.com/tsujan/FeatherNotes * License : GPL Programming Lang: C++ Description : FeatherNotes is a lightweight Qt5 hierarchical notes-manager for Linux. FeatherNotes (by Pedram Pourang, a.k.a. Tsu Jan tsujan2...@gmail.com) is a lightweight Qt5 hierarchical notes-manager for Linux. It is independent of any desktop environment and has: * Support for rich text formatting, image embedding and inserting editable tables; * Drag-and-drop capability for moving nodes and also for embedding images; * A tray icon for quick access on any desktop; * Correct position/size saving and restoring with most window managers; * Compact but complete search and replacement widgets; * The ability to include searchable tags (hidden info on each node); * Support for local and remote hyperlinks (bookmarks); * Text zooming; * Printing and exporting to HTML and PDF; * Password protection; * Auto-saving; and Other features that can be found in its settings, on its menus or when it is actually used. Usefulness: We don't have a Qt based note taking application right now, so FeatherNotes will a great enhenchment of the LXQt and Qt portfolio at all. The LXQt packaging team will maintain it.
Bug#902808: ITP: lxqt-archiver -- Simple & lightweight Qt file archiver
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-archiver Version : 0.1.0 Upstream Author : PCMan * URL : https://github.com/lxqt/lxqt-archiver/ * License : GPL2+ Programming Lang: C++ Description : Simple & lightweight Qt file archiver lxqt-archiver is a front-end (a graphical interface) to archiving programs like tar and zip The core I/O functions are ported from Engrampa (a Gnome File Roller fork). The lxqt team will maintaine it.
Bug#890354: ITP: nm-tray -- a simple NetworkManager front end written in KF5/Qt
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: nm-tray Version : 0.3.0 Upstream Author : Palo Kisa * URL : https://github.com/palinek/nm-tray * License : GPL-2.0+ Programming Lang: C++ Description : a simple NetworkManager front end written in KF5/Qt nm-tray is a simple NetworkManager front end with information icon residing in system tray (like e.g. nm-applet). It's a pure Qt application. For interaction with NetworkManager it uses API provided by KF5::NetworkManagerQt -> plain DBus communication. Qt-Frontend for network-manager - there is no alternative, unless one will see cmst as connman-frontend as an alternative. The LXQt team will maintain the package.
Bug#889075: ITP: qt5-engines-kvantum -- SVG-based theme engine for Qt5
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: qt5-engines-kvantum Version : 10.5 Upstream Author : Pedram Pourang * URL : https://github.com/tsujan/Kvantum * License : GPL-3.0+ Programming Lang: C++, etc Description : SVG-based theme engine for Qt5 Kvantum (by Pedram Pourang, a.k.a. Tsu Jan tsujan2...@gmail.com) is an SVG-based theme engine for Qt4/Qt5, KDE and LXQt, with an emphasis on elegance, usability and practicality. LXQt Team want to maintain it.
Re: ISO download difficult
Russ, thanks, convinced. On 06.12.2017 00:15, Russ Allbery wrote: > It's not quite that simple. Once it's included in the default > sources.list, those packages show up in apt-cache search and other tools, > or in aptitude browsing. Then, when looking for a package to solve a > particular problem,
Re: ISO download difficult
On 05.12.2017 10:33, Jonas Meurer wrote: > 3. We should consider the a firmware subsection to non-free in our >repositories. This would allow users to use non-free firmware while >not adding sources for other non-free software on their systems. > > Cheers > jonas I see this a little bit different - hell, no! - non-free is non-free and the pure existence of a line http://ftp.debian.org/debian $distribution main contrib non-free will not pollute a system with not wanted non-free packages. Afaik it needs a apt install $list_of_non_free_packages to do so. So we can leave non-free and all things are good. Anything else should be considered as bike shedding. And i'm serious about that - if we consider amd and intel processor patches not as firmware should we leave them out or need these two packages a subsection too? I would call this pure nonsense. For me these sub-section discussion sounds like "I was young and i need the money ...". Sorry if this should be to offensive. But we are (at least should be) mature enought to stand to our decisions without any half-hearted excuses.
Re: Debian Stretch new user report (vs Linux Mint)
On 05.12.2017 00:11, Adam Borowski wrote: > How exactly firmware is not software? > We may take a concession and offer non-free or parts of non-free more > prominently (as it's needed on modern x86, all wifi cards I've seen, etc), > but let's not declare that non-software. > > Thus, until the situation improves: > * let's make the non-free iso download more obvious > * explain why it's bad. No quotes from Stallman -- they're opaque to most > users, quotes from Linus would be better. > > On the other hand, there's only 297 non-free packages in Debian, thus I > don't see a benefit in splitting that further. Most of it is firmware or > docs with unmodifiable parts anyway. > > > Meow! And that's exactly the point - non-free is non-free is non-free. And will ever be. So - there is nothing like 'good' non-free versus 'bad' non-free. For which reason ever (sources not available, license things, etc. pp.) all non-free things will be non-free. There is no distinction - and it will be sufficient to put some firmware on an iso and name that iso 'non-free' - with all the things said above. The only real question in this context is: Is that piece of non-free software distributable or not? If so, it might be shipped. This step will help some free software also a lot - best example is the radeon driver - the driver is free and usable, but depend on a non-free firmware. And i also see no bad things in delivering two images - the free and the non-free one - it would be nuts to put away the efforts that was needed to create the free ones. And for a stronger user experience there should be a script remove-non-free on the iso - the script or better the command should be promoted too: apt purge $(vrms -s)
Re: Debian Stretch new user report (vs Linux Mint)
On 03.12.2017 21:17, Thomas Goirand wrote: > The FSF wouldn't be the only one. I at least, and probably a lot of > Debian contributors, would start hating Debian for promoting hardware > that needs non-free drivers if the non-free ISO was the default one. If > this drives some of our users away, never mind, we're doing free > software, that's what Debian is about. With all due respect - i can't follow here, no way. In that case i never ever has joined Debian nor spend an hour on it. So - first thing was to read and understand the Debian Social Contract. Do you remember, you once aggreed with this too: 1. Debian will remain 100% free We provide the guidelines that we use to determine if a work is "free" in the document entitled "The Debian Free Software Guidelines". We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component. ^^ And i take that dead serious - i work only on free software, but i use non-free too. And i think i will do so in future. 4. Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. ^^ Hmm, i can't read anything about: I don't care about users, they suck, i do free software. > Happy, but using non-free software. This isn't what Debian is about. > I've signed-up on the social-contract, and I stand by it. > >> What do we weight more: Happy users or free software? > Free software, definitively. If users aren't happy, it's not our fault, > but the one of hardware makers that are promoting non-free software. > Instead trying to convince Debian people, it'd be better if you spent > your energy trying to convince hardware makers. Cool - but i don't aggree here - i work hard on free software, not for free software. I want happy users to use this software. I left out the FSF part - nothing new. And promoting our free ISOs will not make them working better. If they work on some hardware or in some virt. machines - cool. But in real life a new Debian user has some hardware and not much experience in running a linux system. And do you really expect that a new user will be interested in Debian politics first hand? I guess no. If we drive those users away from Debian they are a loss for the whole FOSS ecosystem. But if they stay and become educated over time ... > It's probably that last bit that needs to be fixed. In my view, it'd be > fine to promote this ISO a little bit more, as long as we write in BOLD > that this contains non-free drivers, and how bad hardware makers are. > > Cheers, > > Thomas Goirand (zigo) > It is not only the last bit. And i don't think that 'a little bit more' promotion is sufficient. We should clearly state why we prefer the free ones. But we should not hide the non-free ones and should have them on the same site. With a clear statement why these images are not prefered. Cheers Alf Gaida (agaida)
Re: Debian Stretch new user report (vs Linux Mint)
On 01.12.2017 16:53, Ian Jackson wrote:
> Simon McVittie writes ("Re: Debian Stretch new user report (vs Linux Mint)"):
>> I find it interesting that we're having this conversation at the same
>> time as a thread about how there should be a configuration option that
>> denies our users the opportunity to choose to install non-free software.
> Perhaps you mean: a configuration option that allows a user not to be
> nagged to install non-free software.
>
> FAOD I agree that the current situation with install images for random
> PCs is quite unsatisfactory, but I don't know how to square the circle.
>
> Ian.
>
Ian, thats dead easy - put the needed packages onto the iso and be done
with. The installer should have an option to opt-in contrib and/or
non-free. Done. Ok, that was the technical part. The other part of the
story would be that the FSF wouldn't like us for that step. Anyways,
they don't recommend Debian because debian make it still to easy for
users to install non-free stuff, so i think this would be no real
probelm. Bradley M. would be upset too - and some other people who think
that every debian user need to be educated that one has to buy hardware
that would work without non-free things. The majority of the users would
be happy. Hmm, but there would be still the catch 22 with the social
contract and the free software guidelines. What do we weight more: Happy
users or free software? The FSF has answered this before - Debian is not
free, so they don't recommend us. Their choice. We choose to promote and
deliver iso's without any non-free. Our choice. And for the people with
the needed knowledge there are iso's that will work well with nearly all
hardware. Sounds fair, doesn't it?
The result will be: Normal users will use fedora, ubuntu etc - these
distributions that are proven to work otb with the most hardware in the
wild and are recommended by their friends who tested them before. Debian
will be limited to users who prefer free software or have the knowledge
to work around these limitations. Or are able to find the working isos
with non-free. To me it not sound like the best service for our users
_and_ free software. Free software is a learning process and my guess is
that this process will not start for a lot of people if they can't
install a working Debian firsthand. It might be that i see this to
simplified.
My 2¢
Alf
Bug#869730: ITP: featherpad -- FeatherPad is a lightweight Qt5 plain-text editor for Linux
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: featherpad Version : 0.6 Upstream Author : Tsu Jan * URL : https://github.com/tsujan/FeatherPad * License : GPL Programming Lang: C++ Description : FeatherPad is a lightweight Qt5 plain-text editor for Linux FeatherPad (by Pedram Pourang, a.k.a. Tsu Jan ) is a lightweight Qt5 plain-text editor for Linux. It is independent of any desktop environment and has: * Drag-and-drop support, including tab detachment and attachment; * X11 virtual desktop awareness (using tabs on current desktop but opening a new window on another); * An optionally permanent search-bar with a different search entry for each tab; * Instant highlighting of found matches when searching; * A docked window for text replacement; * Support for showing line numbers and jumping to a specific line; * Automatic detection of text encoding as far as possible and optional saving with encoding; * Syntax highlighting for common programming languages; * Printing; * Text zooming; * Appropriate but non-interrupting prompts; - Lightweight Qt Editor, replacement for the more or less dead Juffed in LXQt - pkg-lxqt will maintain it
Bug#868562: ITP: sddm-config-editor -- Graphical editor for SDDM
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: sddm-config-editor Version : 0.1 Upstream Author : Yaohan Chen * URL : https://github.com/hagabaka/sddm-config-editor * License : ASL Programming Lang: C++ Description : Graphical editor for SDDM Qt implementation of an graphical editor for SDDM. KDE has a KCM for SDDM configuration. Other environments have no such things - vi and nano excluded.
Bug#868274: ITP: lxqt-themes-extra -- Extra themes for LXQt (debian and derivatives)
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name : lxqt-themes-extra Version : 0.11.96 Upstream Author : Alf Gaida * URL : https://anonscm.debian.org/cgit/pkg-lxqt/lxqt-themes-extra.git/ * License : LGPL Programming Lang: n.A. Description : Extra themes for LXQt (debian and derivatives) Theme for debian which uses the background of desktop-base, planned something similar for Lubuntu
Bug#867606: ITP: lxqt-themes -- Upstream Themes for LXQt
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-themes Version : 0.11.96 Upstream Author : Alf Gaida * URL : http://github.com/lxde/lxqt-themes * License : LGPL Programming Lang: n.A. Description : Upstream Themes for LXQt Several upstream themes for LXQt, including - Ambiance - Dark - Frost - Light This package is the successor of the obsoleted lxqt-commons. The common files was merged in the matching packages, the themes will be a new package.
Bug#846401: ITP: fswatch -- File change monitor that receives notifications on file or directory changes
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: fswatch Version : 1.9.96 Upstream Author : Enrico M. Crisostomo * URL : https://github.com/emcrisostomo/fswatch * License : GPL-3+ Programming Lang: C, C++ Description : File change monitor that receives notifications on file or directory changes fswatch is a file change monitor that receives notifications when the contents of the specified files or directories are modified. fswatch implements four kinds of monitors: * A monitor based on the File System Events API of Apple OS X. * A monitor based on kqueue, a notification interface introduced in FreeBSD 4.1 (and supported on most *BSD systems, including OS X). * A monitor based on the File Events Notification API of the Solaris kernel and its derivatives. * A monitor based on inotify, a Linux kernel subsystem that reports file system changes to applications. * A monitor based on ReadDirectoryChangesW, a Microsoft Windows API that reports changes to a directory. * A monitor which periodically stats the file system, saves file modification times in memory, and manually calculates file system changes (which works anywhere stat (2) can be used). fswatch should build and work correctly on any system shipping either of the aforementioned APIs.
Bug#839943: ITP: lxqt-build-tools -- Set of scripts required to build LXQt desktop environment
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-build-tools Version : 0.1.0 Upstream Author : Luís Pereira * URL : https://github.com/lxde/lxqt-build-tools * License : LGPL-2.1+ and BSD-3-clause Programming Lang: cmake Description : Set of scripts required to build LXQt desktop environment Right now the package contain the needed cmake scripts for building the LXQT desktop environment. More scripts will follow over time. Maintainer of the package will be the LXQt Packaging Team
Bug#838724: ITP: pavucontrol-qt -- pavucontrol-qt is the Qt port of volume control pavucontrol
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: pavucontrol-qt Version : 0.1.0 Upstream Author : Hong Jen-Yee (PCMan) * URL : https://github.com/lxde/pavucontrol-qt * License : GPL Programming Lang: C++ Description : pavucontrol-qt is the Qt port of volume control pavucontrol The software belongs to the LXQt project but its usage isn't limited to this desktop environment. The package will be maintained by LXQt Packaging Team.
Bug#835545: ITP: xfwm-theme-breeze -- A clone of KDE/Plasma 5's "Breeze" window manager theme.
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: xfwm-theme-breeze Version : 0.1.0 Upstream Author : Ramón Cahenzli * URL : https://github.com/psy-q/xfwm-theme-breeze * License : GPL2 Programming Lang: etc. Description : A clone of KDE/Plasma 5's "Breeze" window manager theme. Works well with xfwm4 and LXQt. The standard themes don't.
Bug#825851: ITP: meteo-qt -- Application to display weather information
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: meteo-qt Version : 0.9.3 Upstream Author : Dimitrios Glentadakis * URL : https://github.com/dglent/meteo-qt * License : GPL Programming Lang: Python Description : Application to display weather information meteo-qt is an application to display weather information in desktop panels, desktop notifications and it's own window. . Weather data is taken from OpenWeatherMap (http://openweathermap.org/). The application is based on Python 3 and Qt 5.
Bug#824225: ITP: lxqt-l10n -- Language packages for LXQt
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-l10n Version : 0.10.9~beta Upstream Author : LXQt team * URL : https://github.com/lxde/translations * License : (LGPL) Programming Lang: (etc.) Description : Language packages for LXQt The package will provide all localisations for the LXQt packages. The package will be team maintained by the LXQt packaging team.
Bug#795805: ITP: nomacs -- multiplatform image viewer and manipulator
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: nomacs Version: 2.4.4 Upstream Author: Markus Diem , Stefan Fiel , Florian Kleber URL: http://nomacs.org/ License: GPL, LGPL and BSD Description: nomacs is a free, open source image viewer, which supports multiple platforms. You can use it for viewing all common image formats including RAW and psd images.
Bug#795803: ITP: lxqt-metapackages -- Metapackage for LXQt
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: lxqt-metapackages Version: 0.9.0 Upstream Author: Alf Gaida URL: http://anonscm.debian.org/cgit/pkg-lxqt/lxqt-metapackages.git/ License: GPL-2 Description: Metapackage for LXQt
Bug#795802: ITP: lximage-qt -- Image viewer for LXQt
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: lximage-qt Version: 0.4.0 Upstream Author: Hong Jen Yee (PCMan) URL: https://github.com/lxde/lximage-qt License: GPL-2.0+ and LGPL-2.1+ Description: Image viewer for LXQt lximage-qt is a simple image viewer for LXQt.
Bug#795801: ITP: lxqt-sudo -- Sudo for LXQt
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: lxqt-sudo Version: 0.9.0 Upstream Author: Palo Kisa URL: https://github.com/lxde/lxqt-sudo License: LGPL-2.1 Description: Sudo for LXQt The LXQt sudo wrapper
Bug#795792: ITP: qlipper -- Lightweight and cross-platform clipboard history applet.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: qlipper Version: 5.0.0 Upstream Author: Petr Vanek URL: https://github.com/pvanek/qlipper License: GPL-2.0+ Description: Lightweight and cross-platform clipboard history applet A Lightweight and cross-platform clipboard history applet. Original: Handle clipboard histroy Original: Allow to use "Sticky" items - a user defined unchanged objects for clipboard. Local: Global keyboard shortcut to raise the history menu Local: Improved menu handling
Bug#795791: ITP: screengrab -- Crossplatform tool for getting screenshots
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: screengrab Version: 1.95 Upstream Author: Artem Galichkin URL: https://github.com/QtDesktop/screengrab License: GPL-2.0+ Description: Crossplatform tool for getting screenshots Screengrab working in Linux and Windows. The program uses Qt and is independent of any desktop environment.
Bug#765773: ITP: lxqt-admin -- Admin tools for LXQt
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-admin Version : 0.8.0 Upstream Author : LXQt team * URL : http://lxqt.org * License : (GPL, LGPL) Programming Lang: (C++) Description : Admin tools for LXQt Admin tools for LXQt, as of now: * lxqt-admin-time * lxqt-admin-user -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017230255.29562.95604.reportbug@localhost
Bug#765768: ITP: lxqt-about -- The LXQt About-Screen
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-about Version : 0.8.0 Upstream Author : LXQt team * URL : http://lxqt.org/ * License : (GPL, LGPL) Programming Lang: (C++) Description : The LXQt About-Screen (long description would come later) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017214212.11964.2019.reportbug@localhost
