Bug#567377: ITP: lal -- Lal is a clock for the dock. Nothing more, nothing less.
Package: wnpp Severity: wishlist Owner: Michael Lustfield -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: lal Version : 1.1 Upstream Author : Dave Foster * URL : http://projects.l3ib.org/lal * License : GPL Programming Lang: C Description : Lal is a clock for the dock. Nothing more, nothing less. Lal is a clock for the dock. Nothing more, nothing less. It is a very simple tool especially helpful for those that are using openbox. It can use various colors, sizes, formats, etc. It can accept any POSIX date format. . Window managers that are reported to work well with lal: - FVWM - OpenBox - Enlightenment - ion3 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkth3t0ACgkQ3y7Nst6YLGUwkQCgj4EjmTlVPMky0KhxY3xhfwAb R+cAoJNGsrXYWov6i8Eh1MwMwQ3mkvUY =p3mD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574913: ITP: lal -- dockable clock applet for various window managers
Package: wnpp Severity: wishlist Owner: Michael Lustfield -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: lal Version : 2.0-1 Upstream Author : Mikael Magnusson : Dave Foster : Thayer Williams * URL : http://projects.l3ib.org/lal/ * License : GPL Programming Lang: C Description : dockable clock applet for various window managers Description: dockable clock applet for various window managers Lal is a clock for the dock. Nothing more, nothing less. It is a very simple tool especially helpful for those that are using openbox. It can use various colors, sizes, formats, etc. It can accept any POSIX date format. Note: Version 1.1 is currently sitting in the upload queue. I am hoping to finish version 2.0 within a few months that will come with many new features such as a calendar. One goal of the new version will be to check through the code to see if this tiny file can be stripped down at all to make it even more light weight. I'm working with the upstream authors to bring this release which is why I refer to anticipated features for this version. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkum0ZoACgkQ3y7Nst6YLGX9tACggPO7tHb1OCPmBCWu98sc0j+K lDYAn0Klh5YnSuQg6K9M6MVp5chydLXg =Y0kR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100322021039.1702.21480.report...@michael-desktop
Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon
>>> > I can say that it does: start-stop-daemon misses some functionality you >>> > need for programs that don't daemonise and log to stdout/stderr, which >>> > is something I needed only last week. Having said that, I think that >>> This looks like a job for systemd. >>> >> >> Yes, all problems are just nails for that hammer! > > Systemd does starting/stopping and managing services very well. > The tool you want to use in this case is systemd-run, which starts a > transient service for the command you want to run in the background. > Cheers, > Matthias Of course, we shouldn't expect everyone to use systemd-run because that's locking into an init system which should quite obviously be avoided. It does seem like daemonize serves a very unique purpose where start-stop-daemon is a bit overkill or cumbersome. It's obviously something that would never be used in an init script where start-stop-daemon is actually appropriate. However, I can see a few situations where I would launch this from a script. Not only that... but I can see myself rewriting some scripts to make use of this if it were included in Debian. Just my two cents. -- 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/CAL4L7=AtLW0RfiM0-v0Y=bpwsa9om3ky0epo4d-_qwyptiz...@mail.gmail.com
Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon
>> Of course, we shouldn't expect everyone to use systemd-run because >> that's locking into an init system which should quite obviously be >> avoided. > > That, again. > > The person who suggested using systemd merely pointed out that the task > of turning a regular process into daemon is trivially solvable using > systemd-run. This kind of implies that if the OP uses systemd, they > could just read the appropriate manual page and have their task solved. When I read it, it came across a bit different from that. It sounded like that was to be considered "the" approach instead of one option. Related to a bit further down... >> It does seem like daemonize serves a very unique purpose where >> start-stop-daemon is a bit overkill or cumbersome. It's obviously >> something that would never be used in an init script where >> start-stop-daemon is actually appropriate. However, I can see a few >> situations where I would launch this from a script. Not only that... >> but I can see myself rewriting some scripts to make use of this if it >> were included in Debian. > > Two points: > > * It seems you have missed a message in this thread mentioning the > `daemon` package which is in Debian (since ages) and is able to > daemonize a regular program. You're right. I missed (spaced on) that note. Which helped contribute to my feelings above. I guess my argument is invalid. I'm sorry for the noise then! > * Not to bash the maintainers of `start-stop-daemon` but this program > is sort of a hack as it can't do most of what's expected from a > daemonizer: it can't capture the standard output streams of the > child it spawns and redirect them to syslog, and it can't restart the > child when that dies. It can be a pain in the bum, but does (mostly) work... I need to start playing with daemon! -- 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/CAL4L7=d7dpzvsfixytjkkammqqgaqgwuma7a0axylkmhyx-...@mail.gmail.com
Re: please document why a package has been dropped from Testing/Bullseye
On Sun, 9 May 2021 07:30:04 +0200 Harald Dunkel wrote: > Hi folks, > > https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so I > wonder > what is the recommended way to find out why rsnapshot (or any other package) > has been dropped from Testing? I was wondering what the easiest and most sensible way would be to find/share this information. My first thought was feeding something like 'aptitude search ~o' into a script that checks for RM bugs in the bug tracker. It seems like it would be an easy enough trigger to write, but it would be time-consuming to run and would add a fair bit of load to the bug tracker. > rsnapshot is still in Sid. I found #986709, of course, but this information > should be much easier to access. I should have asked that the removal include sid. For personal things, I've been fairly happy with restic+b2 as a replacement. For servers, -- Michael Lustfield
Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]
On Wed, 14 Jul 2021 18:48:24 +0200 Philipp Kern wrote: > On 14.07.21 13:47, Michael Biebl wrote: > > Am 14.07.21 um 12:59 schrieb Simon McVittie: > I do recall that the FTP masters would've been generally open to have > such an auto-approver (but maybe I'm wrong), but that no-one stepped up > yet to code it up? A few of us came up with some proof of concept designs/models, but we ultimately dropped the effort when it became clear the team wasn't interested in such tools. We considered continuing with a tool that would work for individual users reviewing their own work, but there just wasn't enough interest for that either. I'd be happy to help resurrect (the personal-use version of) the project/effort if there's any chance I won't be working on it by myself...
Re: General Resolution: Voting secrecy: First call for votes: corrected ballot
YP/3ra2wGH/L5TWI2ohEkvFmg53/NAE33wmgjtjnbU > tZkEQPWvCbeg6iJKgk7O4AAx9XgUu0HFRY+FQSN4lsC+SyaG53WQ9baDGia6jc4Y > iHMgELdOPNC47yp4qC30AV6nBptjjJv2QyYq8gOej/I2hSf5YtpdnA7Q3lsymA9E > +iPIcV1QO9IX0WU3+6Hu3PP7rKugJTsM1YjlrOzjHB3WAPyngw38drcIxBc/d7Uy > 1FRD/l2I5SBvRPOEiZH/2hZXbeT1yQkphwTVpHfsBtkPxnv5ERILBWRVOW5lKcg4 > yyXASzkbngaIbfacgC0b17WfEvX+yeKWFAeEn2/A0uRrVkgjY1yT7kfFq8OFNqRc > v9FW3PQDG6pFMKdtvzaI0PMujclXhtp29FzHqBGdLiOuJgn6qJ0IfUoKPtGR7J6o > AiB7ojGH14wiXxWJA8cQpyxz1+6x3bCvxlDU+TW3qn1WNYDON+1USVpwOvUct8ru > jn2a2OoFYxI2gun1ZPuqQdhHyTKuVhNJ5674NlmBVGG1YlQWQVxElEreMkqUdS17 > w8CjNEu+yCkl3dsQuZLdOrIcgEqSZt22i6HA5hldWD8JiJ46iMsEZIfYelqHBuDe > J+OmT4PR0Q/klrwA3Jq06xEr/o2RvDzzvT39KW4QBOVZiQPwLV/8BIQ/TDqoIvoI > NjoyiQIzBBABCgAdFiEE5eUlYN2RxVbdvaXQIGTFNkHCXl0FAmIs0yoACgkQIGTF > NkHCXl2QpQ/8CHQeNMwzDqxu6mR9wrOuM37J5QoHX1wUbr5yXVqOXpVjPHLvbRWW > OVf798x+jQ92NFUi1ANYn2nr9Fgtp0YNkpX3w8nd32j3SivtB1+TeoFXJbvtJbT+ > F3KI0X63FTFiuNLU3rcupO+b78jRO3awJnxw3eiWM6KGAraE146mqVIk5PBJFF0h > RJkg+GK5SLZ0otRpNAquoN6HcX9ToLGc2HlDL8S4IWVqFKPh8R8Eb6RbKEjM4htj > 2azL06CCHZlACrg3I68zO9bhRXdwbyOzbQ6M3jymvSqJl0fB9DTDAFzaG1LhF+00 > ghXqqJeAexQzcN5tZ0Xc4ZZfNFjvGBVmBoucHHO11L2CwNZPzH2DrLPuH6KzsmoE > wq/XHiLAonqHIsc/YM32l98v+8Ro1LreyGqc1KYKvKnvlDg1C3KKK6ObcDsL02IL > yw2Ksu4ZJLv73aqOjw/B04Qyf82JKVGkmVe7FwjjsZLDDrH1ZcZ03g2057Du0A/r > 2bm6Y6+dmYyrjWfKmAVJRbPHttnt7T2OUJSg8oThBBe3FKTq5O1i5Vba+cjHP/QR > YLZtumRi9JdACs6VI6KcJbf7rvTd6NcOp3NNjog5NgjAhuVjTQAi5364QAlYO2q/ > 7KA/UlciI2jyYOu5oirFeOGLCo98rqeoIi+tf7whXT6z+cqCvcv0L/+5Ag0EYizS > 0wEQAMi+pNlhNpgmUW8NGNKowBbj1HjZnSMNCeuJl4J0pit6WzF6ulLY0uuA9rEu > /EO46tGU2iHu1QzLTmtpj480mm9FPLiJAv8dooKRCyjdkR9hw33iCZSI/u8pKI1i > +EbovJEVVvX2g5ci1cMQ7G8uRhC3GQ/63yBiWQ6OT+retorKFAnQY14S1i8r8eU1 > gEuTOJsUU/J8XylrMOSSfkU5NnyE9fZzB07+1e8mrsXlq9qQhntcdCQ46q7f87vw > iG5gzdXhy7tYpNHUd9syZyQMTYxxq4gaU8B9cHX5RUFqvwTR9WqBrv8qMeWNzZbg > IYnVCyS6f44lWtyopSUSw5aAOwYyYyIfIL9iym1rRJqReIUYA5fT5kSchbR9LUAI > Pfo/mZII8uCqirD+l3cDn9syiuATW5ubnVlCGWLFdbtZkrPmwU7n38Q7YrZK59o7 > cHR1lQ5qwim5B0fF90Qo/nRgwOk4fWNxhlwMCdUoeHtoAZSmuDPK8oDp6SqVdxaW > Qrsx2hnG6rKoclVMwTyEyNazcDaq9ZzMlIFRArw791J/lK3MtxnsXz3t2vonbEe1 > mvblJ8celOd3NwZU1JDtJxSrNXgI1YJxtyu53m3rlWE7G9/s7JrEpS1fbyDux+Uo > dWc8LifnOD/AKKINNM0mJOyfcZa9wg1/rtyKMJ1zgHkZA25RABEBAAGJAiUEGAEI > AA8FAmIs0tMCGwwFCQAbr4AACgkQiJt5aSvVtOONlBAAqbbaZ3+iVNxppqjxB3+Q > /v/olcD2OHBT7qRG5Lflkg/NucjxfF/6OGcRk2dX4kRxefEBG1B2gLsbrUKXnPCP > Z97ElV5OuMXOrWmYa8XYLLK3nee/b5wxAKQp60qhcD7qdmWigAnZXOLhZjeRsRym > QsC2Zqs4vRFKKgZ+SftMRIZ1C9lLXeaWvyZm+szxUz6v82hpwVhHMirJCBa+DM/b > WXwOnlEF7j/8M1noMzUJaYXXOYVHjJSCJkWV4vvlVwKp1MNKdbYwq7jKHZxdxBMB > y9w4TReIlNYLgaGzo94rBA9MVF4OOniLjEHZKx303IOSFqZlnFtEAHZUGON6uVBC > 40nISOGgLON2BKej8kRR+5u46m1x7mleeX0cUMLZGTvTNSfgedpCaGGcyWXRTJjh > Nl/tEb6FJ5n2YAmNg7rx6EgGw7KcGzhLwcEIhess4zAjjOMYMXsG+xHe8jLMMA+v > dl/h62M+KKWne7zTraPvruPfSNazi4dZ+OQSGd1IU7THIQeLzPQy3xmaGODCT2Rb > rgG5a3UmG3beq8INyM32dTCPBdaylVEvHCFV7pLJQqV4rbsjI4y1Pj80Q1nKAWd6 > KaEdm9RLst8dlGr/yqF2eKW6Anrq0BnIk2P+1WUNT6kYw3uR54zEMJsEyHhGthHv > rBx9Eic2hgSnl4hB+jxtJJ0= > =anKA > -END PGP PUBLIC KEY BLOCK- > -- Michael Lustfield pgp0Y_kvkV8z1.pgp Description: OpenPGP digital signature
Re: General Resolution: Voting secrecy: First call for votes: corrected ballot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> VOTING FORM
>
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 6acf7f89-3eb2-492c-8715-98ae65b5f9d2
> [4] Choice 1: Hide identities of Developers casting a particular vote
> [1] Choice 2: Hide identities of Developers casting a particular vote and
> allow verification
> [3] Choice 3: Reaffirm public voting
> [2] Choice 4: None of the above
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
>
> --
>
> BALLOT OPTIONS
>
>
> Choice 1: Hide identities of Developers casting a particular vote
> =
>
> Rationale
> =
>
> During the vote for GR_2021_002, several developers said they were
> uncomfortable voting because under the process at that time, their name
> and ballot ranking would be public.
> A number of participants in the discussion believe that we would get
> election results that more accurately reflect the will of the developers
> if we do not make the name associated with a particular vote on the
> tally sheet public.
> Several people believed that the ranked votes without names attached
> would still be valuable public information.
>
> This proposal would treat all elections like DPL elections.
> At the same time it relaxes the requirement that the secretary must
> conduct a vote via email. If the requirement for email voting is
> removed, then an experiment is planned at least with the belenios voting
> system [1]. belenios may provide better voter secrecy and an easier
> web-based voting system than our current email approach.
> If this proposal passes, adopting such an alternative
> would require sufficient support in the project but would not require
> another constitutional amendment.
>
> [1]: https://lists.debian.org/yhotrixtz3aip...@roeckx.be
>
> This proposal increases our reliance on the secretary's existing power
> to decide how votes are conducted. The lack of an override mechanism
> for secretary decisions about how we conduct votes has not been a
> problem so far. However, if we are going to rely on this power to
> consider questions like whether the project has sufficient consensus to
> adopt an alternate voting mechanism, we need an override mechanism.
> So, this proposal introduces such a mechanism.
>
> Summary of Changes
> ==
>
> 1) Do not make the identity of a voter casting a particular vote
> public.
>
> 2) Do not require that votes be conducted by email.
>
> 3) Clarify that the developers can replace the secretary at any time.
>
> 4) Provide a procedure for overriding the decision of the project
> secretary or their delegate. Overriding the decision of what super
> majority is required or overriding the determination of election
> outcome requires a 3:1 majority. The chair of the technical committee
> decides who conducts such votes.
>
> 6) Codify that our election system must permit independent verification
> of the outcome given the votes cast and must permit developers to
> confirm their vote is included in the votes cast.
>
> General Resolution
> ==
>
> The developers resolve to make the changes to the Debian Constitution
> embodied in git commit ed88a1e3c1fc367ee89620a73047d84a797c9a1d.
> As of February 23, 2022, this commit can be found at
> https://salsa.debian.org/hartmans/webwml/-/commit/ed88a1e3c1fc367ee89620a73047d84a797c9a1d
>
> For convenience a word-diff of the changes is included below. In case
> the diff differs from the commit, the commit governs.
>
> @@ -179,9 +179,27 @@ earlier can overrule everyone listed later.
>
>
>
> [-In case of-]{+Appoint+} a [-disagreement between-]{+new secretary.
> In the normal case ( §7.2) where+} the project
> leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary,
> [-appoint a new secretary.-]{+this power of+}
> {+the developers is not used.+}
>
> {++}
> {+Override a decision of the project secretary or their+}
> {+delegate.+}
>
> {+Overriding the determination of what super majority is required+}
> {+for a particular ballot option or overriding the determination of+}
> {+the outcome of an election requires the developers to agree by a+}
> {+3:1 majority. The determination of the majority required to+}
> {+override a decision of the secretary is not subject to+}
> {+override.+}
>
> {+The chair of the technical committee decides who acts as+}
> {+secretary for a general resolution to override a decision of the+}
> {+project secretary or their delegate. If the decision was not made+}
> {+by the chair of the technical committee, the committee chair may+}
> {+themselves act as secretary. The decision of who acts as secretary+}
> {+for such a general resolution is not subject to override.+}
Re: General Resolution: Voting secrecy: First call for votes: corrected ballot
Eh, I obviously forgot to fix up the reply-to bit. Sorry for the noise. -- Michael Lustfield
Re: Bits from the DPL (August 2019)
On Tue, 1 Oct 2019 14:32:10 + Holger Levsen wrote: > On Tue, Oct 01, 2019 at 09:57:38AM -0400, Sam Hartman wrote: > > I'd say it is a consensus of those who prioritize participating in this > > discussion enough to do so, consented to by the rest of the project. > > I'm sorry, but I disagree. Silence is not always consent. ^ 100% agreed- silence does not mean consensus/consent When it comes to things like forcing the use of Debian's Gitlab (& other topics), I've remained silent because my disagreement was already voiced by others, with more detailed reasoning than I would have provided. Am I really expected to add a "me too" response every time I agree with what someone else took the time to write... making it harder for people with limited time to follow? This seems especially cruel to those that don't speak English natively, and those that rely on translation services. -- Michael Lustfield
Re: Idea: frontend tool for more efficient license reviewing based on tree-structured IR
On Fri, 27 Dec 2019 01:56:07 + Mo Zhou wrote: > [...] > My idea > --- > > ## Motivations I've had similar motivations. Since becoming a Trainee, I've found the review process to be rather painful. I think the slow and klunky tools we use are a big problem and likely contribute significantly to the burnout this team sees. > ## Core It sounds like we have similar ideas--a bit of automated review, and more convenient manual review. > How to proceed > -- > > * a group of interested contributors. > > * GSoC / Outreachy sounds good. > > Several months ago I've already started a python script based on this idea. > I'm struggling with UI programming (I'm really not good in this area). > Specifically, when I found myself stuck at adding custom keybinding under the > urwid framework, I postponed the idea indefinitely. > > [1] -project: "Do we still value contributions?" > [2] -project: "possibly exhausted ftp-masters" > I started a similar effort when I first became a trainee. Unfortunately, a lot of our non-trainees seem to be burned out, which means no reviews, and no reviews means a lack of confidence in whatever system I'm building. I can handle basic UI design and know a couple people that are very good at it. I'm also able to host some infrastructure for what I have in mind. Can you share the source you've been working on? I'm currently turning my notes into something a bit more intelligible. -- Michael Lustfield
Re: Idea: frontend tool for more efficient license reviewing based on tree-structured IR
On Sat, 28 Dec 2019 13:49:18 + Mo Zhou wrote: > On Fri, Dec 27, 2019 at 04:00:33PM -0600, Michael Lustfield wrote: > > I started a similar effort when I first became a trainee. Unfortunately, a > > lot > > of our non-trainees seem to be burned out, which means no reviews, and no > > reviews means a lack of confidence in whatever system I'm building. > > Is it published somewhere? Not really... What I have is more a specification than anything. It's pretty long-winded, so I'll send it to you directly (and anyone else interested). -- Michael Lustfield
Re: call for ftpmaster's transparency
On Thu, 06 Feb 2020 10:32:42 +1100 Dmitry Smirnov wrote: > IMHO it is disturbing that one of the most essential processes in Debian > -- acceptance of new and modified packages -- operates almost in secrecy. This is an understandable perspective, but secrecy probably isn't the best word. > To make matters worse ftp-masters rarely leave their comments in ITP > issues. As I've recently learned that have profound effect on processing of > new packages. I personally think this sounds like a fantastic (and not very difficult) idea. Where do you propose the bug mail be sent for NEW/binNEW packages without an ITP? > One of my packages spent a year in the NEW queue at some point raising to > position number 4. Apparently before release of Buster (2019-07-06) member > of ftp-masters team left an internal (invisible to the public) comment on > my package that was not communicated to me until 7 months later when my > package was rejected based on that comment. The comment could have been > addressed without delay if it was left on the corresponding ITP issue where > it belong. I suspect when you say, "member of ftp-masters team," what you mean is "FTP-Masters Trainee." FWIW- Trainees are not technically part of the team. We get just enough access to be able to provide package reviews. Those reviews are then either discussed with us or sent back in a rejection/prod message. I agree that it could be valuable to see comments; however, they're almost always going to be from Trainees. Since we're not technically part of the team, it's important that we don't speak on behalf of the team. Publishing Trainee comments would effectively be doing that. > A precious time was lost but more importantly one can see that current > process requires an extra effort to communicate with maintainers -- a > something that would not be necessary if ftp-masters use the official > channel that exist specifically to discuss introduction of new packages -- > ITP bug reports. > [...] I would personally *LOVE* to see ITPs be a requirement for *ALL* new packages. Making it a requirement and expecting ftp-masters to ignore any upload until the ITP has existed for at least X days would be absolutely fantastic. It would fix some redundant library uploads (see golang/nodejs/etc.) and it would provide a mandatory level of review by the wider community. Back when I tried to get gitea packaged for main, I had a number of ITPs commented/closed mentioning the alternate library name or a reason it can't be packaged. > I'd like Debian project leader to engage in the matter of improving > transparency of ftp-masters team operations and procedures. This feels a lot like starting a GR and not allowing appropriate discussion. It's heavy-handed, isn't going to get anywhere, and is going to hurt feelings. > As very minimum I recommend to change current ftp-master procedures to use > ITP bugs instead of internal comments whenever possible, for the sake of > transparency and to optimise communication. I replied to this idea above. > I want to encourage a public discussion regarding opening of the ftp-master > mail list to the public. Currently reasons for unjustified secrecy of ftp- > master processes is not explained... It's often said that emotions don't play well with productive discussions. Adding phrases such as "where it belong", using "secrecy" over "privacy", calling it "unjustified", and immediately jumping to demands of the DPL are accusatory and inflammatory, and will likely just get you ignored or start an unproductive flame war. I too would love to engage in a civil discussion about ways to improve the situation. Let's start with this- Why do reviews take so long? - The team is tiny - Much of the team seems very burned out - The ones that are active tend to stick to source or "unloved" tasks - There are some very large and/or messy packages that need review - There are a lot of redundant tasks and frequently-made mistakes + A little more automation could help that - (my opinion) The tools are archaic, cumbersome, and inefficient + Fixing this would be a very (non-technically) difficult task + An idea I have would help to bring transparency to the process... ^ it's missing an interest requirement :( -- Michael Lustfield pgpsLUD8ax93J.pgp Description: OpenPGP digital signature
Re: FTP Team -- call for volunteers
On Sun, 15 Mar 2020 05:10:21 +0100 Adam Borowski wrote: > On Sat, Mar 14, 2020 at 08:04:01PM -0400, Scott Kitterman wrote: > > On Saturday, March 14, 2020 6:37:46 PM EDT Martin wrote: > > > On 2020-03-14 13:37, Sean Whitton wrote: > > > > (packages in NEW must not be downloaded from ftp-master.d.o to your > > > > local machine) > > > Just curious: Why is that the case? > > Out of an abundance of caution. Until after the package has been reviewed, > > there's no knowing if it's distributable and downloading a package from ftp- > > master.d.o to another machine outside debian.org is a distrubution. > [...] > This "abundance of caution" rule is utterly obsolete this millenium. It > made some sense when distributing software was done by snail-mailing a > floppy or a stack of them. My knee-jerk response is to agree. There is a lock which also applies to reviewing a package. This means only one person can be looking at it at a time. We often just open a github/gitlab/etc. page if multiple people need to discuss the package (usually team member asking a trainee something). The content has already been distributed. Why should this be any different from mentors.d.n, where such practice is required? The problem is that this server is *the* distribution point for the Debian archive. This feels like a weird gray area that shouldn't be messed around with. Personally, I was shocked when I found out we do review on the same server that hosts the archive. I would have expected a separate server for review. However, my expectation comes from younger environments, where CD/CI and extensive code review processes are expected. When I try to picture how the current system evolved (more evident as you dig into dak source...), it makes sense. Making a new server to push reviews to would remove that gray area, since it would effectively be identical to mentors.d.n; especially considering how easily one could upload to ftp-master instead of mentors... (guilty) Something like this would take a pretty deep dive into dak, and a new server, and all the goodies that would go along with such a transition. Unfortunately, from my view, such a change would be nearly impossible. I can't even get documentation fixes merged into dak or even reviewed. I don't imagine such a large change would ever get accepted. If we could even just do something like an DNA, saying we will definitely destroy everything we download, we'd at least be able to write our own review tools. :/
Re: DFSG of disk image with contrib package
On Mon, 16 Mar 2020 18:25:17 +0100 Emmanuel Kasper wrote: > Am I right in keeping these disk image as "contrib", or I am > overcomplicating by keeping these multiple disk image builds ? Yes, this seems logical. It matches how we handle other packages; if it requires non-free to build, then it's non-free. -- Michael Lustfield
Re: What to do when DD considers policy to be optional? [kubernetes]
On Mon, 23 Mar 2020 18:47:18 -0700 Sean Whitton wrote: > Hello Dmitry, Janos, others, > > On Mon 23 Mar 2020 at 05:32PM +11, Dmitry Smirnov wrote: > > > What would be best to do in such situation? > > [...] > > I think that I would start by filing an RC bug. +1 If you run into issues, then you'll want to contact the ftp-masters team. It would be helpful if the bug mentioned the two solutions I'm aware of: - Revert the offending changes - Migrate from main to non-free The latter would be much easier, but would destroy all the work you put in. :( > > [...] > > As a person who originally introduced Kubernetes to Debian I can say that it > > is indeed a lot of work to maintain this package and to reuse packaged > > libraries. But I've demonstrated that it is possible at least to some > > extent. As a person who temporarily introduced gitea into Debian, I fully understand. Unfortunately, I've found that such problems are often a result of poorly written code where the approach tends to be, "I don't know how to do this thing, so I'll copy a module that does this and 200 other things just as poorly." The lesson I learned was- Just because something /can/ be packaged, does not mean it /should/ be packaged. (pabs warned me about this hundreds of hours prior to me giving up) > > I don't recall a situation when policing of how a package is maintained > > would > > be necessary long after package is accepted... It's rare, but it happens. My most recent experience was with bitlbee. Unfortunately, our current auto-reject system is quite limited. Catching things like this automatically is (currently) not possible and Debian relies of folks like you. (btw- thanks for this report) > > What do we do to ensure quality work in situation of technological hijack > > when maintainer is unwilling to follow the practice or comply with policy? > > > > This is not a technical disagreement so I think that involving technical > > committee may not be the right way to handle the problem... Or is it? TC is not needed. This is a clear policy violation that the new maintainer appears to have known about, even before the upload. It concerns me that they thought this package warranted an exception... -- Michael Lustfield
Re: What to do when DD considers policy to be optional? [kubernetes]
On Tue, 24 Mar 2020 10:14:08 + Paul Wise wrote: > On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote: > > > Kubernetes is already using Go modules. They happen to have decided to > > keep shipping a `vendor/` directory but this is not uncommon. It is > > often considered as a protection against disappearing modules. So, there > > is nothing to be done upstream. And BTW, there are currently 616 > > dependencies, pinned to a specific version. > > I wonder if the existence of Software Heritage could convince them > disappearing modules aren't a problem, or if another service is > needed. I think this is a symptom of the tools being used. Using 'go vendor' is a documented step in nearly all golang-based "release tutorials." Most never even get as far as considering that maybe their source should have a version, because the toolset mentality is "download latest at build time." The 'go vendor' approach is especially bad within the Debian context because it will download any/all modules that are referenced. In some cases, 'go get [..]' can go from downloading a single repository to downloading 200+ because one (1) extra dependency was added for one (1) extra feature that almost nobody will ever use. It's nearly guaranteed that at least a large handful of those will have no license at all and at least one is going to have large embedded non-dfsg blobs. Or, to summarize my rant... These lazy young whipper snappers don't know what good source looks like! .. back in my day, we coded on paper, had real bugs, and that's just the way we liked it. -- Michael Lustfield
Re: What to do when DD considers policy to be optional? [kubernetes]
On Wed, 25 Mar 2020 02:07:13 +0100 Marco d'Itri wrote: > On Mar 24, Russ Allbery wrote: > [...] > The main reason for mostly forbidding vendored libraries has been that > the security team rightly argues that in the event of a security issue > it would be too much work to 1) hunt each package using a vendored > library and 2) patch and rebuild all of them. > This does not really matter for Go and Rust software because 1) the list > of (vendored) dependencies can be extracted automatically at build time > and 2) all this software would have to be rebuilt anyway since these > languages do not support or do not use dynamic linking. > > Also, shared libraries save memory when multiple programs using them are > run concurrently, but nowadays this kind of saving is rarely meaningful. My point earlier was that it's not just a security problem. We have established that Debian does, and will continue to, care about fulfilling license obligations, including distributing license and copyright information with the package. Bluntly put, I have yet to see a project that doesn't treat 'vendor/' as a black box of collected libraries. These directories are rarely reviewed and it is trivial (default) to wind up including extra libs between builds. Even if it's possible to restrict that list, I doubt it would be done. I was (pleasantly) surprised to see d/copyright updated in this package. However, this is not maintainable- https://sources.debian.org/src/kubernetes/1.17.4-1/debian/copyright/ > Because of these reasons maybe we should consider supporting vendored > libraries in some cases. My opinion is still a very hard "No." This sounds (to me) rather akin to- "since app devs tend to be lazy, should we be the same?" One last thing to consider... NEW reviews are already an intense process. If this package hit NEW /and/ we allowed vendored libs, you could safely expect me to never complete that particular review. I doubt I'm the only one; that's essentially ~200 package reviews wrapped into 1. -- Michael Lustfield
Regarding vendor/ libraries... [Was: Re: What to do when DD considers policy to be optional? [kubernetes]]
On Tue, 24 Mar 2020 19:25:49 -0700 Russ Allbery wrote: > Michael Lustfield writes: > > > One last thing to consider... NEW reviews are already an intense > > process. If this package hit NEW /and/ we allowed vendored libs, you > > could safely expect me to never complete that particular review. I doubt > > I'm the only one; that's essentially ~200 package reviews wrapped into > > 1. > > I'll repeat a point that I made earlier but put a bit of a sharper point > on it: We should thoughtfully question whether the current approach to > license review that we as a project ask ftpmasters to do is a correct > investment of project resources. > > The current approach to NEW license review is not a law of nature. It's a > choice. Other choices are possible, such as trusting license declarations > by upstream and then handling upstream mistakes that are later discovered > as RC bugs. The project is much better at sharing the load of handling RC > bugs than it is at sharing the load of NEW license reviews. > > Most of the ecosystems that make extensive use of vendored packages also > make extensive use of license metadata. Sometimes that license metadata > is wrong, and we will have to have a process for dealing with those > errors. But the purpose of Debian is not to be a license checking service > for the entire free software world. It's to build a distribution adhering > to a set of principles but with the understanding that we will sometimes > make errors and fix them later as bugs, not be perfect and error-free at > any of our principles, including our licensing principles. For everything > other than licenses, we accept the risk that we will incorporate upstream > errors in our distribution until someone points them out via a bug report. > > We do not *have* to do a detailed file-by-file review of the correctness > of upstream's license metadata when packaging. This is a choice. By > choosing to do this, we absolutely catch bugs... just like we would catch > bugs if we did a detailed file-by-file review of any other property of > upstream code. For many other types of bugs (including ones that arguably > have a more severe impact on our users than licensing bugs, such as > security bugs), we often make trade-off decisions in favor of accepting a > risk of upstream mistakes and having to fix them later. Scott K. reminded me that the policy in question is a "should" and not a "must." This is a pretty important distinction that I forgot about. In practice, it's useful for when a single file is taken from a large project, sometimes including weird build tools. Assuming d/copyright is actually correct (it's not..), then it's not a policy violation. However, for all of the reasons mentioned, and especially because most of that work was already complete, I have to agree with the term sloppy. We obviously need to continue the vendor/ discussion, but I think switching threads would be a good idea. -- Michael Lustfield
Re: What to do when DD considers policy to be optional? [kubernetes]
Ehm... perhaps we should practice some de-escalation techniques, please. :/ On Wed, 25 Mar 2020 13:55:50 +1100 Dmitry Smirnov wrote: > On Wednesday, 25 March 2020 6:08:23 AM AEDT Janos LENART wrote: > > Debian Policy, paragraph 4.13 states: > > There are several problems with how you did it too. You did not use anyone's > advise, ignored Salsa repository, threw away _everything_ and made no effort > to understand how and why things were implemented, let alone appreciated > prior work or tried to improve it. What you did is technological hijack of > the package, a gross violation of practices. > > Imagine I'll upload a package to NEW, get in reviewed and accepted for what > it is then re-upload as something entirely different bundled with 500+ > dependencies that were not reviewed then claim that policy allows it? I missed this earlier... With regard to the kubernetes package, I don't see anything to indicate it was abandoned. I'll also assume that the current maintainer (Dmitry) was not contacted by Janos. Considering how quickly this started after the upload, this seems like a safe bet. Janos- If that's correct, then this would indeed be considered a "hostile takeover" of the package. It would be nice to assume that this was simple oversight of forgotten communication. No matter the actual facts- please remember how important communication is to our community. So... with Dmitry still active in Debian and still holding interest in the package, the path forward seems obvious, doesn't it? One person is interested in maintaining the package per our standards, and another is interested in getting it updated.
FTP-Master Review Process
Hello fellow masochists, ... err, I mean Debian Developers, There has been a lot of talk lately about the FTP-Masters team and how some issues should be fixed. Back in December, I alluded to a proposal that I was working on. I hoped to get a little further into writing source prior to this point, but life happens and now seems to be a much more appropriate time than later. In my "proposal" [1], I outline the concerns that have been noted (from mailing lists, IRC, and private discussions) and then provide a few potential solutions. Although some source code exists, this is a discussion for later. I want to take a very systematic and structured approach to this. To outline... 1. Identify a problem 2. Evaluate the cause 3. Consider solutions 4. Evaluate the solution - Does it solve the problem? - Does it introduce new problems? - What will it take to implement? - Would any developer be willing to work on it? - Will it be maintainable in the long-term? - etc. 5. Build some prototypes 6. Re-evaluate the solution (copy #4) 7. Finish design requirements 8. Start building 9. Lotsa testing 10. Start discussing implementation Note... I am using the term proposal because very little of what I put forth is in any way a design document. It's just many thoughts tossed at a page that now require critical review. (critical -- be picky, not rude) Once the discussion is over (or degrades), I will begin writing a design document. After complete, I will ask for additional comment and interested developers. Side note- An important road block to be aware of is that implementing almost any of the proposed solutions will require significant (time & effort) changes to the main archive server. It will also likely require some legal counsel. I'll omit the gritty details since this is mostly just FYI, but it's also worth considering team size and availability (see: $current_issue) when it comes to implementation. [1] https://salsa.debian.org/mtecknology/ftpmaster-proposal -- Michael Lustfield
Re: How much data load is acceptable in debian/ dir and upstream (Was: edtsurf_0.2009-7_amd64.changes REJECTED)
On Tue, 15 Sep 2020 08:55:40 +0200 Tobias Frost wrote: > On Mon, Sep 14, 2020 at 03:32:54PM -0500, Richard Laager wrote: > > > >> Don't forget to mention the copyright information. > > > > > > In principle yes, but these data are not copyrightable as far as I know. > > > Nilesh has mentioned the origin of data in debian/tests/README to > > > provide a reference. If you consider this information not sufficient > > > please let us know a better way. > > Note, IANAL; > I don't know if DATA itself is copyrightable, however, the act of collecting > data can to my understanding constitute copyright. Nor am I, but I can assure you... it gets absurdly gray after data has been published. Many publications reference data from other existing publications. The assumption is generally- it's silly to re-create all the work all over again to investigate a new idea when other sources have already gone through the effort of producing that data. Copyright law is also kinda interesting in this regard; not just because of "fair use" laws, but also because because published scientific data is generally intended to be re-used and verified. Taking published data and sticking it into tests to ensure the same data results doesn't just verify published data was correct; it also provides potential new discoveries when the results no longer appear to be correct. Citations are typically expected, but so is data re-use. (citations -> d/copyright)
Re: UID and GID generation
> [...] In the original scenario, the concern was was with shared media having uid/gid numbers that don't match what's on the system. In that scenario, this was viewed as a security concern. This is not a security concern because once someone has physical access to your unencrypted data, it's no longer your data. That's just an unfortunate truth. You can give me a HD w/ Windows on it, tell me you set up the file system permissions to be really super duper secure, but... I'm just going to walk around the file system as if you gave me higher than administrator access. Whatever isn't encrypted is now something I have access to. For the above scenario, the let's say the data is encrypted. If you're giving the other party the key so they can open it... it's no longer your data. The next scenario I recall from this thread was about the small business scenario. The typical response to that is obviously centralized authentication. I know scenarios where that's not possible or the logistics are absurd. The next best thing is configuration management utilities. In my personal opinion, if your company is large enough to have servers, it's large enough that config management is no longer optional. If you can go along with that, you can get something like this (salt example): local_users: - michael: uid: 4001 gid: 4001 pwd: keys: - ssh_key1 - ssh_key2 - timmy: uid: 4002 gid: 4002 pwd: - freddy: terminated: True When tools like sssd take a remote uid/gid and translate that to a local translated uid/gid, I don't believe that's a security concern so much as a concern of things breaking if you start getting collisions. Ya, that's a security concern if sssd generates uid/gid numbers that collide with numbers that other tools that want to use those specifically, but I'm convinced this behavior has nothing to do with security. This behavior only makes collisions unlikely, it does not, in any way, guarantee that collisions will never happen. In fact... Story time! One of the first times I started playing with sssd, I was rolling it out in a mid-size enterprise (~24,000 employees). One a few servers, the uid/gid numbers that sssd came up with collided with over 80% of the existing local system users. This was a design issue that needed to be resolved, not something that needed a band-aid. Because centralized user management already existed, miscellaneous uid/gid numbers were sent up river to AD and then every system was migrated to using those numbers. End result... collisions can't happen because we don't let them. tl;dr -- Randomizing uid/gid numbers does not improve security, it just decreases the probability of that security hole being accessible. Enforcing the same uid/gid everywhere *will* prevent collisions. Sorry, I got a bit long winded. That's what I get when I write fun emails on my break. :(
Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET
On Thu, Aug 18, 2016 at 12:17 PM, Marcin Kulisz wrote: > On 2016-08-18 16:27:23, Luke W Faraone wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Luke W Faraone >> >> * Package name: powershell >> Version : 6.0.0~alpha9 >> Upstream Author : Microsoft >> * URL : https://github.com/PowerShell/PowerShell >> * License : Expat >> Programming Lang: C# >> Description : scripting language interpreter built on .NET Heh... ya' know what... I can recall a time when I had to scramble to figure out how to deploy a windows system in a particular environment so that I had Windows available so that I could load up a powershell script. In typical Windows fashion, the effort it took me to deal with the "enhanced security features" windows provides was quite frustrating, on top of having to find a way to run some queries to grant myself domain admin rights because 20,000 people were impacted and people didn't think it was a problem worth staying late for. Anyway, if I could have run "aptitude install powershell" and run the queries directly against our problem child from my debian workstation, well... that'd have been quite swell, pardon my language. As a Debian guy that gets cranky outside of *nix-land, I think powershell is a pile of garbage, but I've been in positions where having it in the repos would have been like a gift from god delivered on a silver/gold platter. Side note... I'm actually incredibly impressed that microsoft released powershell with such a free and open license. I don't get the impression this is actually the powershell-in-windows source. I get the impression it's just a portion, but... whatever. It also seems like it's sort of a trial to see if they want to continue open sourcing MS SQL (I don't think they did, yet...). I've cried a few times in meetings where they decide that's the DB of choice. Why? MariaDB is just so much nicer and easier and has support and dummy-proof docs... anyway, I would have been much less frustrated at the decision if aptitude install mssql-server were a thing. I can still deploy that with a config management system! :D
Re: Is missing SysV-init support a bug?
> >> sysvinit or another alternative. > > Barely noticeable: > > > > https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 > > This graph only shows that systemd users tend to install popcon package > too. I don't think you can rely on this statistics to argue that > sysvinit is no longer used by users. > Heheh... Who would have thought that the people choosing to remove sysD and install sysV would also be the ones removing popcon (and 288 others from the minimal no-tasksel install...)? I actually remove popcon because I don't want my level of insanity to impact others. :p My understanding, before the debate ever popped up in the first place, was that maintainers get to ignore (NOT close) minor bugs with non-default xyz and that they are absolutely not allowed to stand in the way of anyone willing/able to continue maintenance. It seemed pretty simple to me... As people stop using xyz, they stop supporting it, if that happens, xyz as a whole will deteriorate and eventually gave the chopping block. Nice, easy, and gradual removal by consensus. :) Maybe I missed something, but ya... the case reported looks like an incredibly excellent example of what we've agreed is a big no-no.
ITP: gogs -- self hosted git service
retitle 792101 ITP: gogs -- A painless self-hosted Git service. owner 792101 ! thanks Updated Details: * Package name: gogs Version : 0.9.97 Upstream Author : The Gogs Authors * URL : https://github.com/gogits/gogs * License : MIT Homepage: https://gogs.io/ Programming Lang: Golang Description : A painless self-hosted Git service. . Gogs is a self-hosted service aiming to provide a similar set of features to gitlab and github while remaining lightweight and easy. I intend to package gogs. I have reached out to the gogs developers to make them aware of this intention and have offered to discuss what that may mean for them. Although upstream makes frequent releases, these seem to rarely have security fixes so I don't anticipate any significant concerns backporting security issues. (feel free to double check me!) -- Michael Lustfield pgpQ5tJiDtmWa.pgp Description: OpenPGP digital signature
Bug#840588: ITP: golang-github-lunny-log -- A compatible log extension
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
* Package name: golang-github-lunny-log
Version : 0.0~git20160921.0.7887c61-1
Upstream Author : Lunny Xiao
* URL : https://github.com/lunny/log
* License : BSD-3-clause
Programming Lang: Go
Description : A compatible log extension
log GoDoc (https://godoc.org/github.com/lunny/log)
.
简体中文 (https://github.com/lunny/log/blob/master/README_CN.md)
Installation
.
go get github.com/lunny/log
.
Features• Add color support for unix console• Implemented dbwriter
to save log to database• Implemented FileWriter to save log to file
by date or time.• Location configurationExample For Single File: Go f,
_ := os.Create("my.log") log.Std.SetOutput(f)
.
.
For Multiple Writer: Go f, _ := os.Create("my.log")
log.Std.SetOutput(io.MultiWriter(f, os.Stdout))
.
.
For log files by date or time: Go w := log.NewFileWriter(log.FileOptions{
ByType:log.ByDay, Dir:"./logs",
}) log.Std.SetOutput(w)
.
About This repo is an extension of Golang log. LICENSE BSD License
http://creativecommons.org/licenses/BSD/
(http://creativecommons.org/licenses/BSD/)
I am packaging this as part of an ITP for gogs. This is a dependency for one of
the gogs dependencies. (and far from the only one)
Bug#841279: ITP: golang-github-gogits-go-gogs-client -- Gogs API client in Go.
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: golang-github-gogits-go-gogs-client Version : 0.0~git20160830.0.d8aff57-1 Upstream Author : Gogs * URL : https://github.com/gogits/go-gogs-client * License : MIT Programming Lang: Go Description : Gogs API client in Go. Gogs API client in Go This package is still in experiment, see Wiki (https://github.com/gogits/go-gogs-client/wiki) for documentation. License This project is under the MIT License. See the LICENSE (https://github.com/gogits/gogs/blob/master/LICENSE) file for the full license text. This is being packaged as a build dependency to gogs.
Bug#842433: ITP: golang-github-gogits-cron -- a cron library for gogs
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: golang-github-gogits-cron Version : 0.0~git20160810.32.7f3990a-1 Upstream Author : Gogs * URL : https://github.com/gogits/cron * License : Expat Programming Lang: Go Description : a cron library for gogs GoDoc (http://godoc.org/github.com/robfig/cron) Build Status (https://travis-ci.org/robfig/cron) TODO: perhaps reasoning
Bug#842434: ITP: bluemonday -- bluemonday: a fast golang HTML sanitizer (inspired by the OWASP Java HTML Sanitizer) to scrub user generated content of XSS
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: bluemonday Version : 0.0~git20161012.0.f77f16f-1 Upstream Author : Microcosm * URL : https://github.com/microcosm-cc/bluemonday * License : BSD-3-clause Programming Lang: Go Description : HTML sanitizer to scrub user generated content of XSS Bluemonday takes untrusted user generated content as an input, and will return HTML that has been sanitised against a whitelist of approved HTML elements and attributes so that you can safely include the content in your web page. I'm packaging this library as a dependency of gogs, but this seems to be a useful and well written library for preventing XSS.
Bug#842435: ITP: golang-github-microcosm-cc-bluemonday -- bluemonday: a fast golang HTML sanitizer (inspired by the OWASP Java HTML Sanitizer) to scrub user generated content of XSS
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: golang-github-microcosm-cc-bluemonday Version : 0.0~git20161012.0.f77f16f-1 Upstream Author : Microcosm * URL : https://github.com/microcosm-cc/bluemonday * License : BSD-3-clause Programming Lang: Go Description : HTML sanitizer to scrub user generated content of XSS Bluemonday takes untrusted user generated content as an input and will return HTML that has been sanitised against a whitelist of approved HTML elements and attributes so that you can safely include the content in your web page. I'm packaging this library as a dependency of gogs, but this seems to be a useful and well written library for preventing XSS.
Re: wording: "reverse dependence" vs "depender"
On Jan 1, 2017 4:37 PM, "Ben Finney" wrote: Adam Borowski writes: > Oi you lot! Wassp!? > I wonder, would it be better if we switched to using the word > "depender" in place of "reverse dependency"? I don't know a simple term in English that carries that meaning. To me, “depender” feel like a neologism and does not make me confident the reader would know what is meant. I vote −1 to that term. I imagine any non-English speaker would significantly oppose creating new slang for this. I had to scratch my head when I read the subject wondering if it was a typo for defender. I can't, at this moment, think of a decent alternative.
Re: Python 3.6 in stretch
On Mon, Jan 9, 2017 at 1:54 PM, Ben Finney wrote: > Adam Borowski writes: > >> On Tue, Jan 10, 2017 at 05:35:34AM +1100, Ben Finney wrote: >> > Andrey Rahmatullin writes: >> > >> > > On Sun, Jan 08, 2017 at 06:55:45PM +0100, Galbo Branbert wrote: >> > > > Thanks for the info, didn't know that the transition freeze was >> > > > actually the version freeze for minor versions of Python. >> > > A minor version upgrade would be 3.5.3 -> 3.5.4. 3.5 -> 3.6 is a >> > > lot of changes. >> > >> > Galbo is referring correctly to the minor version, as specified in >> > https://www.python.org/dev/peps/pep-0440/> and Semantic Versioning >> > http://semver.org/>. >> > […] >> >> Not every project uses semver. > > We're not talking about “every project”. We are talking specifically > about Python, where “minor version” has the meaning Gablo used. I agree, Python intends to use semver. However, in practice, they do not. If 3.5 to 3.6 was a typical "minor version," our expectation would be that the update comes with security updates and bug fixes (not feature changes). Python uses the microversion position for this. More importantly... is this really a point that matters? Is not the point that matters the fact that 3.5 to 3.6 introduced significant changes? As such, it seems the argument about whether this is a minor version bump, a significant one, or whatever we wanna call it are moot. The version change /does/ introduce significant changes and this carries substantial risk to even consider rolling at this point. Remember, we have a long freeze, not so we can continue to sneak in cool features, but rather so we can ensure a high quality release.
Bug#853084: Solution
After seeing the resolution, I would say the solution should be adding pulseaudio to either recommends (most likely) or to depends of the plugin. On Jan 29, 2017 10:30, "Fredrik Nyqvist" wrote: > Hi, > > I may have sent the bug report too early... > > I noticed now that I have to install pulseaudio first. After I did this > the plugin works. > > Should pulseaudio be installed by default? > > /Fredrik > >
Re: Depends/Recommends from libraries
On Mar 9, 2017 12:22 PM, "Russ Allbery" wrote: Sure, but hopefully we find and report those as bugs. I personally run without recommends on Debian unstable on several different types of systems and report these problems whenever I run into them. I'm in this same boat. I disable installing recommends on all but one of my systems, including my laptop's and other devices. If (when) I have issues or check out new software, I take a look at those lists to see what I might want. Heh.. I remember using gnome, kde, xfce, etc. and they all seemed to have this problem in one way or another. After enough battling, I eventually arrived at the conclusion that these desktop environments were written to be super complete, not super lean. They were for everybody, not for me. I ended up switching to openbox and a whole different selection of "desktop" utilities and even had to write some myself. Issues like this have completely evaporated for me.
Re: The deal with our old logo[s?] (the penguin one)
On Mar 15, 2017 19:06, "Samuel Henrique" wrote: As some of you may not know, Debian used to have a penguin logo[1]. Thanks for making me feel young! The only reference i could find of it does not tell much[1]. I heard rumor once that, as a newer DD, it's possible to cast votes on previous decisions. This makes me want to cast another vote for that comforting, friendly, and correct swirl. There's just something about it that I've always loved, something that's always made me feel like I'm home. I could also find some (almost none) detail about the first logo from a cool guy's blog[2]*. Thanks for this as well! I genuinely love it and might make it my next tattoo! I was six years of age when it was published and my life has been spun 4,140 degrees by it's existence so it actually seems fitting. Where can i read more about our logo's history? (at least for how long they were used) If you learn of anything outside of this thread, could you keep us updated?
Re: Bug#857394: Debian Policy violation -- libgegl-dev contains duplicate copy of openCL library files
On Fri, Apr 14, 2017 at 11:40 AM, Enrico Weigelt, metux IT consult wrote: > On 14.04.2017 14:34, ian_br...@mail.ru wrote: > [...] > By the way: is there any automatic way for creating the -dfsg trees out > of the upstream ? (I prefer working directly w/ git repos instead of > additional patching) We do indeed have magic for this! https://pkg-perl.alioth.debian.org/howto/repacking.html#2.1._Copyright_file Add Files-Excluded to the first paragraph in d/copyright. Add two version mangle options to d/watch. Let uscan be awesome. :)
Re: website maintenance
>>> Our users are really complaining about our look&feel in the web I expect that less than ten people on earth would disagree with you. > Unfortunately, I don't have the web abilities (web technologies, > design, UX, whatever) that this task requires. [..] > Someone have suggested to invest a bit of our money into some paid > work. I believe this idea is something worth exploring too. I've been working on packaging gitea but I'm reaching a point where too much needs to change in either unstable or experimental for it to be sensible until after freeze, so I now have some time available. I don't claim to be an expert by any means, but I do have some background in website development and know of some resources that could be helpful. (google can fill in any blanks here, no I'm not proud of my PHP knowledge) If we're going to seriously discuss reworking www.debian.org, can we talk about what changes actually need to take place? Let's start the requirements gathering phase, ya? What functions does the current implementation not provide? What do we need to see out of the next option? We have a lot of web services that share a similar theme. The minimalistic design provides an easy way to keep a unified theme across all services and makes it easy to render correctly across all browsers regardless of the latest and greatest ecmascript or $foo. You can safely assume Debian is a group of people that will not be okay with requiring javascript to correctly render pretty much anything [1]. I'm sure it's been discussed before, but I don't know what functional requirements we face, what services utilize the same theme/design, what their templates need to look like, what kind of resources are typically accessed and under what load and why, how content updates are deployed, etc. Before even beginning any work, I think it's important the requirements phase for a project like this be completed in relatively painful detail. [1] That's why our updates are so clean. ;)
Re: website maintenance
On Tue, May 16, 2017 at 2:22 AM, Michael Lustfield wrote: >>>> Our users are really complaining about our look&feel in the web [... blah blah ...] For some reason, the entire other chunk of this thread found it's way to my junk folder. I'm not sure why that happened but I see there's actually been some discussion started so please ignore me. I'll follow up when either I read through a wiki page or create one to start keeping track of opinions. :)
Re: Switch default installation image link?
I'll chime in to what others have said. I think DVD images should not be the default/main download venue. Even though the careful package ordering by (alleged?) popularity, I am sure a great deal of Debian installs use under half of the packages provided by the first DVD (and many that are not there, of course). A completely offline user will have to juggle no matter if they got the DVD, and a connected user (no matter their available bandwidth) will spend more time waiting for the network if they choose to install from DVD. Usually, when I hear about people downloading the DVD over a slow paid-per-bit connection, they do it so that they can burn multiple copies and share so that what people have to download is kept to a minimum. I'm sure other reasons exist where the DVD is the sane option, but the netinst iso is the only thing I ever considered using.
Re: UMASK 002 or 022?
I personally prefer a global 0027, but I've heard arguments for 0077. I also did a quick web search and found wiki pages meant to discuss the default. I imagine the most helpful course of action would be to read through the existing discussions and then contribute facts that haven't been shared... ideally without the emotions and opinions present here. I never read anywhere that a form decision was made, just that there hasn't been cause for change. My preference of 0027 doesn't make sense for the typical family. Their default doesn't make sense for me. I got the impression this was never changed was because people that care can do a search for how to change it, change it, and no longer care. I use configuration management to set it and haven't thought about it again.
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
On Jul 12, 2017 03:39, "Holger Levsen" wrote: On Tue, Jul 11, 2017 at 10:44:47AM -0500, Don Armstrong wrote: > On Tue, 11 Jul 2017, Bjørn Mork wrote: > > Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now? > > sudo ip link; sudo ip addr; no need for sudo, this is enough: ip link ; ip addr or even shorter: ip l ; ip a I don't believe the point had anything to do with ifconfig vs. ip. Rather, it's no longer possible for people doing remote troubleshooting to make an educated guess what the name of the interface in question is. Imagine destining to the lay user how to read and parse the bits from the ip command output that you're after. Now, instead of knowing it's the add-on card and asking for bits of "ip addr show eth1", you're now along them to run "ip addr" and figure out which of the devices might be what you're looking for. In another scenario, system automation doesn't often involve management of network interfaces, but it's also not rare. I had been able to look at DCIM and know what address ethX would have assigned. At the moment, I'm not really sure how to handle the new naming scheme. I miss simple and (globally) predictable.
ITP: golang-github-bsm-pool -- simple connection pool in Go
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: golang-github-bsm-pool Version : 0.0~git20161215.0.502d32d-1 Upstream Author : Black Square Media Ltd * URL : https://github.com/bsm/pool * License : Expat Programming Lang: Go Description : simple connection pool in Go BSM Pool implements a simple connection pool for Go. . Features: - thread-safe - lock-free - stack-based rather than queue-based + connections that have been used recently are more likely to be re-used - supports pool shrinking (reap idle connections) This is being packaged as a new dependency to golang-github-bsm-redeo. pgpOF1Qlhw0JT.pgp Description: OpenPGP digital signature
ITP: golang-github-mitchellh-go-homedir -- detect the user's home directory without cgo
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: golang-github-mitchellh-go-homedir Version : 0.0~git20161203.0.b8bc1bf-1 Upstream Author : 2013 Mitchell Hashimoto * URL : https://github.com/mitchellh/go-homedir * License : Expat Programming Lang: Go Description : detect the user's home directory without cgo This golang library implements methods for detecting the user's home directory without the use of cgo, so the library can be used in cross-compilation environments. . Usage: - homedir.Dir() + get the home directory for a user - homedir.Expand() + expand the ~ in a path to the home directory This is being packaged as a new dependency of golang-github-spf13-cobra, which is being packaged as a dependency of gitea.
ITP: golang-github-ssor-bom -- small tools for cleaning bom from byte array or reader
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
* Package name: golang-github-ssor-bom
Version : 0.0~git20170302.0.6ed919a-1
Upstream Author : Asher
* URL : https://github.com/ssor/bom
* License : Expat
Programming Lang: Go
Description : small Go library to clean bom from byte array or reader
This golang library implements a utility to clean bom from a byte array
or byte reader.
.
Example(s):
.
bs := []byte{bom0, bom1, bom2, 0x11} result := CleanBom(bs)
.
bs := []byte{bom0, bom1, bom2, 0x11} result :=
NewReaderWithoutBom(bytes.NewReader(bs))
This is being packaged as a new dependency of golang-github-jaytaylor-html2text,
which is being packaged as a dependency of gitea.
pgp_2zE_PcMvK.pgp
Description: OpenPGP digital signature
Re: OpenSSL disables TLS 1.0 and 1.1
On Aug 7, 2017 8:23 AM, "Joerg Jaspert" wrote:
On 14757 March 1977, Kurt Roeckx wrote:
> This will likely break certain things that for whatever reason
> still don't support TLS 1.2. I strongly suggest that if it's not
> supported that you add support for it, or get the other side to
> add support for it.
In many cases this isnt possible.
I can think of a lot of "enterprise" tools that have been built for older
versions of Java. In most cases, the vendors have no interest in doing
anything required to get away from a TLSv1.0 requirement. I'm also aware
some of the well-known search engine bots that support only TLSv1.0.
Is there an actual need for the removal of TLS v1.{0,1}? Are either
considered broken or unsupported by upstream? If not, I'd be much more
concerned about what's going to start breaking by making this change.
Shouldn't a change like this at least start with packages such as nginx,
apache, etc. and seeing if they can drop those from the default
configuration? Heck, I'm sure we could even include a comment along the
lines of "if you need to re-enable older TLS versions due to application
compatibility, please respond to bug #123".
I'm not sure what exactly would be a better idea, but disabling globally
with no easy workaround sounds like a recipe for pain and very angry users.
ITP: libjs-jquery-minicolor -- Tiny color picker built on jQuery
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: libjs-jquery-minicolor Version : 2.2.6 Upstream Author : 2017 A Beautiful Site, LLC * URL : https://github.com/claviska/jquery-minicolors * License : Expat Programming Lang: Javascript Description : Tiny color picker built on jQuery This package provides a library with methods to display a mini color picker using jQuery. . API Documentation: https://labs.abeautifulsite.net/jquery-minicolors/#api This JS library is being packaged as a build dependency of gitea (a gogs fork). There are a lot of build dependencies and I would love some help. If anyone is interested in handling this package, please feel free to contact me!
ITP: libjs-cssrelpreload -- JavaScript to load CSS asynchronously
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: libjs-cssrelpreload Version : 1.3.1 Upstream Author : 2016 Filament Group * URL : https://github.com/filamentgroup/loadCSS * License : Expat Programming Lang: Javascript Description : JavaScript to load CSS asynchronously This JavaScript library provides functions to load CSS asynchronously. . Referencing CSS stylesheets with link[rel=stylesheet] or @import causes browsers to delay page rendering while a stylesheet loads. When loading stylesheets that are not critical to the initial rendering of a page, this blocking behavior is undesirable. The new standard enables loading stylesheets asynchronously, without blocking rendering, and loadCSS provides a JavaScript polyfill for that feature to allow it to work across browsers, as well as providing its own JavaScript method for loading stylesheets. This JS library is being packaged as a build dependency of gitea (a gogs fork). There are a lot of build dependencies and I would love some help. If anyone is interested in handling this package, please feel free to contact me!
ITP: libjs-pdfjs -- PDF reader in JavaScript
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: libjs-pdfjs Version : 1.8.188 Upstream Author : 2012 Mozilla Foundation * URL : https://github.com/mozilla/pdf.js * License : Apache-2.0 Programming Lang: Javascript Description : PDF reader in JavaScript This JavaScript library provides a Portable Document Format (PDF) viewer that is built with HTML5. This project aims to provide a general-purpose, web standards-based platform for parsing and rendering PDFs. This JS library is being packaged as a build dependency of gitea (a gogs fork). There are a lot of build dependencies and I would love some help. If anyone is interested in handling this package, please feel free to contact me!
ITP: libjs-vue -- JS library for building interactive web applications
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: libjs-vue Version : 2.4.2 Upstream Author : 2013-2017 Yuxi (Evan) You * URL : https://github.com/vuejs/vue * License : Expat Programming Lang: Javascript Description : JS library for building interactive web applications This Javascript library implements functions for building interactive web interfaces. It provides data-reactive components with a simple and flexible API. . Core features: - Declarative rendering with a plain JS object based reactivity system - Component-oriented development style with tooling support - Lean and extensible core - Flexible transition effect system - Fast without the need for complex optimization This JS library is being packaged as a build dependency of gitea (a gogs fork). There are a lot of build dependencies and I would love some help. If anyone is interested in handling this package, please feel free to contact me!
ITP: libjs-swaggerui -- Assets to dynamically generate documentation
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: libjs-swaggerui Version : 3.1.4 Upstream Author : 2017 SmartBear Software * URL : https://github.com/swagger-api/swagger-ui * License : Apache-2.0 Programming Lang: Javascript Description : Collection of assets to dynamically generate documentation Swagger UI is a collection of HTML, Javascript, and CSS assets that allow anyone to visualize and interact with an API's resources without needing to have any implementation logic in place. It provides visual documentation, making it easy for back-end implementation and client-side consumption. This JS library is being packaged as a build dependency of gitea (a gogs fork). There are a lot of build dependencies and I would love some help. If anyone is interested in handling this package, please feel free to contact me!
ITP: libjs-semantic -- JS framework based around principles from natural language
Package: wnpp Severity: wishlist Owner: Michael Lustfield * Package name: libjs-semantic Version : 2.2.13 Upstream Author : semantic-ui.com * URL : https://github.com/Semantic-Org/Semantic-UI * License : Expat Programming Lang: Javascript Description : JS framework based around principles from natural language Semantic allows developers to build beautiful websites fast, with concise HTML, intuitive javascript, and simplified debugging, helping make front-end development a delightful experience. Semantic is responsively designed allowing your website to handle multiple devices. Semantic integrates with frameworks such as React, Angular, Meteor, and Ember. This JS library is being packaged as a build dependency of gitea (a gogs fork). There are a lot of build dependencies and I would love some help. If anyone is interested in handling this package, please feel free to contact me!
Re: ITP: libjs-pdfjs -- PDF reader in JavaScript
On Sun, 13 Aug 2017 15:24:47 +0200 Guus Sliepen wrote: > Is this not the same as libjs-pdf, which is already packaged? > Yup, it's the exact same. Thanks for noticing and mentioning it! :D pgpog7LscUIwo.pgp Description: OpenPGP digital signature
Re: openssl/libssl1 in Debian now blocks offlineimap?
On Aug 15, 2017 08:05, "Kurt Roeckx" wrote: > Do you really think that big companies like cable provides give a > about what Debian deprecates? I was personally fighting with similar > problems in Firefox and the internal side at my university. My problem is that if we don't do something, TLS 1.0 will be used for an other 10 year, and that's just not acceptable. So I would Nobody said we should do nothing, but it should be clear by this point that this total removal is going to cause a lot of problems for admins and users. like to do something so that hopefully by the time Buster releases you can disable TLS 1.0 by default, and that almost no users would need to enable it again. If Debian is going to be the only motivating factor for change then the pressure that causes the change will be from system admins hosting applications. These admins will *NEED* to re-enable older versions. Companies might not listen to customers, but vendors listen to the money providers. It's rarely a fast change, though. It's usually a ticket tossed into the wishlist pile until enough people make noise. I'm currently working on a project with a client to replace TLSv1.0 with TLSv1.2. We're hoping to have this rolled out in a lab in the next four months, but it's been a "priority" project for over two years. It's not for lack of motivation or effort; there are a lot of interesting roll-out issues. This is when motivation to change already exists. "Some distro disabled support for it" is going to lead to vendors outright saying, "use a different distro and wait until we get around to it." I imagine users would be more inclined to just switch to a different distribution that doesn't break their chrome/firefox/internet's. If a client came to us and said their agent broke because their OS dropped that support, our choice would be to say tough luck. Having TLS 1.0 (and 1.1) enabled by default itself is not a problem, it's actually using it that's a problem. There are clearly still too many that don't support TLS 1.2, but it's getting better. I don't think it was answered... Is there an actual reason that this needs to be handled urgently? Is TLSv1.0/v1.1 considered broken? Is there a reason there was no discussion on this list before the decision was made and pushed? Disabling the protocols is the only way I know how to identify all the problems. And I would like to encourage everybody to contact the other side if things break and get them to upgrade. It might be the only way you know, but this list has lots of admin types that could probably help out. Perhaps you could upload a fixed openssl so we can open that discussion about what's appropriate? I've already suggested dropping it from all default configs for a release cycle. It's not until the next release that we can assume a majority of pro-active admins will have been made aware that we(Debian) are deprecating older TLS versions. Dropping out-of-the box support sounds like a great idea, but the back-out option needs to be easy and should be able to be toggled per-application, giving people a chance to react to this change instead of making them scramble for a patch.
Re: Single Sign On for Debian
On Tue, 22 Aug 2017 18:10:39 +0200 Geert Stappers wrote: > On Tue, Aug 22, 2017 at 04:29:49PM +0200, gregor herrmann wrote: > > On Tue, 22 Aug 2017 09:45:10 +0200, Alexander Wirt wrote: > > > > > Specifially one LDAP (db.d.o.) Backend and one Oauth2 (gitlab) Backend? > > [...] > [...] This seems like backward thinking to me. > Thing that I hope is that Alioth successors will have the various services > on separate machines. So that we have not again the situation when replacing > a Source Code Management system we also have to replace the machine > with all the -guest accounts. I whole heartedly agree! One of the current challenges with replacing Alioth is because of how many services it's providing. If Alioth were not being used for guest accounts, this wouldn't even be a discussion. Using Gitlab (or any VCS) as the user db for guest accounts means adding a dependency that could block future upgrades... kinda like now. This is not a future-proof design and will come at a future cost. I'm happy to help implement an SSO solution that Gitlab is capable of using, but I argue against using Gitlab as a future user database. Side note... I got cert-based SSO working on https://gitea.debian.net/. It actually ended up being pretty easy and kinda fun. I have a ticket with upstream to support populating the email address, but that'll be a while. Cheers, -- Michael Lustfield
Re: New httpd-fastcgi virtual package
On Tue, 19 Sep 2017 16:47:33 +0200 Xavier wrote: > Hi all, > > The authoritative list of virtual package provides: > httpd a HTTP server > httpd-cgi a CGI-capable HTTP server > httpd-wsgi a WSGI-capable HTTP server (python 2 API) > httpd-wsgi3 a WSGI-capable HTTP server (python 3 API) > > I would like to propose this: > httpd-fastcgi a FastCGI-capable HTTP server (or server > plugin) As much as it rubs me the wrong way, I don't see many reasons to avoid creating this. In fact, the only reason I have is that it could encourage people to think fcgi is okay to use. This virtual package could probably be satisfied by libapache2-mod-fcgid, fcgiwrap, or spawn-fcgi. I believe fcgiwrap has some systemd magic-sauce that would, in theory, provide a relatively simple way for apps to listen on a well-known unix-socket path (similar to the way uwsgi works). Personally, I always recommend uwsgi over any of the avaialable cgi/fastcgi servers, such as php-fpm, ruby-fcgi, python-fcgi, etc. When you have uwsgi available, and it's capable of handling all those languages, including legacy raw-cgi apps, it seems kinda silly to use anything else. ;) (even mailman runs great behind it..) -- Michael Lustfield
Re: ftp master uploads disappearing?
On Mon, Oct 2, 2017 at 2:49 AM, Andreas Tille wrote: > Hi Carsten, > > On Sun, Oct 01, 2017 at 06:00:05PM +0200, Carsten Schoenert wrote: >> Guido pointed me some times ago to the following additions to my local >> setup in ~/.gbp.conf. That do the trick always create a *source.changes >> file too. >> >> > $ cat ~/.gbp.conf >> > ... >> > [buildpackage] >> > ... >> > pbuilder = True >> > pbuilder-options=--source-only-changes --hookdir /home/carsten/.pbuilder >> > ... >> > >> >> You can also use the command line to add this option(s). >> >> > $ gbp buildpackage ... --git-pbuilder-options="--source-only-changes ..." > > I tried both but with no success. :-( Then you obviously need a third option! I use `SOURCE_ONLY_CHANGES=yes` in `~/.pbuilderrc`.
Bug#882090: ITP: node-yamljs -- JavaScript YAML 1.2 Parser & Encoder
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-yamljs
Version : 0.3.0
Upstream Author : Jeremy Faivre
* URL : https://github.com/jeremyfa/yaml.js#readme
* License : Expat
Programming Lang: JavaScript
Description : JavaScript YAML 1.2 Parser & Encoder
YAML.js is a stand-alone YAML 1.2 parser and encoder. It works under
node.js and all major browsers. This package also includes some command
line YAML/JSON conversion utilities.
.
Example Usage:
// load string to object
nativeObject = YAML.parse(yamlString);
// load file to object
nativeObject = YAML.load('file.yml');
This is being packaged as a dependency of semantic-ui, which is a dependency
of gitea.
pgpVjHXCkPjKL.pgp
Description: OpenPGP digital signature
Re: Debian Stretch new user report (vs Linux Mint)
On Mon, 4 Dec 2017 23:41:34 +0500 Andrey Rahmatullin wrote: > On Mon, Dec 04, 2017 at 10:34:05AM -0800, Russ Allbery wrote: > > For the discoverability, I would be quite comfortable with putting both > > the free and the non-free download links prominantly on the page with the > > non-free link going to or closely tied with a page that discusses the > > issues, explains why we have this installer even though we don't really > > want to, and maybe links to the FSF Respects Your Freedom pages to suggest > > a hardware alternative. > There are alternatives? As long as I avoid Nvidia, I usually have excellent luck finding systems (specifically laptops) that work well without anything from non-free. With servers, I usually need something for the networking drivers but nothing else. -- Michael Lustfield
Re: gitlab package (was Re: Opt out style recommends)
On Mon, Apr 11, 2016 at 3:41 AM, Jonathan Dowland wrote: > On Mon, Apr 11, 2016 at 03:18:58PM +0530, Pirate Praveen wrote: >> 1.Most people in the world including myself thought encryption was an >> optional thing two years back. >> >> 2.automating ssl was not possible before letsencrypt. Now you just need to >> click/press yes button to get an encrypted service running. > > The "normal" way this was done before letsencrypt was with the 'snake oil' > local SSL CA/cert and self-signing. Obviously not suitable for production use, > but perfectly fine for an initial install/testing; it is also simpler than > worrying about talking to LE (especially in a postinst/root/possibly > unattended > context) and a more appropriate initial state for a private/corporate install. > I feel like tossing in my two cents as well since this would likely impact me down the road... I'm also against a package such as gitlab (or drupal, wordpress, dokuwiki, etc.) trying to mess around with my TLS certificates. I'm also very much opposed to it even being a prompt during installation. I'm well aware that gitlab-ci is a beast (and a kludgy mess... god save your soul taking on that feller), but an initial installation should be getting things going and being out of the users face. In most situations, I would venture a guess that gitlab is sitting on internal servers and not publicly accessible. That kinda puts a damper on nice automated ssl with letsencrypt, doesn't it? (k.. not always, but in the typical situation) However, that old option with snakeoil... that still works in these environments. I personally use the letsencrypt infrastructure for some projects, but refuse to use their incredibly bloated client stuff. I use alternative client tools that suite my needs much better than the letsencrypt app does. If anything, shouldn't it be the web server (nginx, tengine, etc.) that would "suggest" letsencrypt? They won't recommend/suggest that package because SSL is a separate thing entirely. I would dare say, at this point, most admins that care about encryption also implement automation tools such as salt and ansible and already have well tested systems in place for certificates. In this particular case, I would suggest first making letsencrypt a Suggests. Then, I would suggest considering snakeoil for the https or just installing with http-only and providing a documented tool for moving to using letsencrypt. You and I both know that we're only talking about a web server configuration... shouldn't the web server be the one suggesting it? ... it doesn't because the web server packages consider SSL/TLS to be its own thing entirely that shouldn't be mixed in with other package deployments. tl;dr .. my opinion: letsencrypt should be a suggests; gitlab should do either https or do a self-signed cert; and letsencrypt integration should come post-install Just my opinions/thoughts. :)
Re: gitlab package (was Re: Opt out style recommends)
On Apr 12, 2016 00:34, "Tollef Fog Heen" wrote: > > ]] Michael Lustfield > > > In this particular case, I would suggest first making letsencrypt a > > Suggests. Then, I would suggest considering snakeoil for the https or > > just installing with http-only and providing a documented tool for > > moving to using letsencrypt. You and I both know that we're only > > talking about a web server configuration... shouldn't the web server > > be the one suggesting it? ... it doesn't because the web server > > packages consider SSL/TLS to be its own thing entirely that shouldn't > > be mixed in with other package deployments. > > The web app might well need to know whether it's being accessed over TLS > or not. If it is, any cookies it sets should be marked with «secure» so > they're never sent in plaintext. An app should know about HTTP vs. HTTPS, yes. However, that's not relevant to this discussion because an app should be finding that information via a header the web server sends it. It's one of the standard headers that nobody pays much attention to. :) I think party of the problem here is the whole omnibus logic that wants to configure the whole environment which immediately steps on sys admin toes. The best thing I can think of is to stick with HTTP out of the box and have another utility that handles modifying configuration. You could have all of these prompts (http vs. https; managed certs vs. letsencrypt) be debconf questions with a post install script that reads those answers. If nothing was selected, use the default. Otherwise, do whatever else. This would provide flexibility to rerun and modify later as well. At least this would be suitable to how gitlab-omnibus likes to configure itself and it's "modules." For admins with config management tools, they can pre-answer your debconf questions and have SSL right away if they so choose. The reconfiguration can easily be triggered via dpkg reconfigure, which tends to be a first step for extra config in Debian. This lets you deploy gitlab out of the box in a manner that is the most likely to work on all systems and leaves the ability to configure extras to your heart's content. Either that or I'm missing something. If I am, please teach me my lesson! :)
Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen wrote: >Thanks for this nice summary. It helped me understand things better. I'm... actually gonna save this for later because it helps me understand the alioth workflow. I'm still relatively fresh to Debian dev and can say, without any doubt, alioth was (continues to be) the hardest part, by far for me to wrap my head around.
Re: why, nicely explained (Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 8, 2016 at 12:39 PM, Milan Kupcevic wrote: > On 06/08/2016 02:55 PM, Michael Lustfield wrote: > > On Wed, 8 Jun 2016 15:47:46 +, Holger Levsen > > mailto:hol...@layer-acht.org>> wrote: > >>Thanks for this nice summary. It helped me understand things better. > > > > I'm... actually gonna save this for later because it helps me understand > > the alioth workflow. > > > > [...] > > Great sarcasm. > > Milan > This was not in any way intended as sarcasm. If it came across as such, please accept this as my apology. Alioth has been, and continues to be, the hardest thing for me to wrap my head around. Whatever option (gitlab, gogs, gitolite) is rolled out and is able to eventually replace at least the git (and projects) functionality of Alioth would very much help me, and others, dive into other projects. Currently, I don't like to even poke at other projects that I'm not already familiar with; I'm scared I'll break something because I don't understand the workflows and processes involved. I /did/ star that message and save it for future use because I /did/ find it valuable. Again, I'm sorry if I came across sarcastic. Hopefully elaborating helps explain what I meant originally. :)
Re: Keysigning via Video Conferencing
On Thu, Jun 23, 2016 at 9:28 AM, Lars Wirzenius wrote: > On Thu, Jun 23, 2016 at 09:23:07AM -0700, Nikolaus Rath wrote: > > As I said in my other email, I am wondering if the extra burden is worth > > the gain in security. > > Is there an extra burden? Seems to me that it'd happen naturally if > you contribute to Debian and as part of that interact with other > Debian people. > I would consider this an extra burden, yes. I've been playing with Linux for over a decade, have many DD's that know me by IRC handle, email address, and nothing else; a face to face meeting has never happened organically. The one time in my life I found a DD to sign my key, I had to schedule a time where work conveniently had me within an hour drive (one way) of that person. I would, personally, consider having an established relationship with someone you can recognize the face of because of face-to-face meetings as a bonus. It would allow you to feel comfortable verifying identity over a video conference. Just a bonus, though, I wouldn't ever make that my requirement. What is it we're really trying to protect against? Signing a key doesn't mean you trust that person's work, it means you trust that person is who they say they are. We want to prevent an evil doer from getting a key into the keyring by pretending to be someone else. We have a completely different process for establishing trust of a persons work and that's all outlined in the DM/DD application process. Our face-to-face meeting and chat is a way to see if their government says they are who they claim to be. Obviously, documents can be forged. You can ask what forms of ID they'll be bringing and use the search-o-matic to figure out signs of a counterfeit, but almost nobody is going to have the equipment to fully check every type of ID. Verifying a legal identity by means that are good enough for other organizations is only the first step in our identification process. Next up, we take the piece of paper home and start our own extended verification process (typos, existing work, etc.) followed by sending that encrypted signature back to the user via email (an address you should have verified has no typos) where the user needs to decrypt with their private key. I believe there's a document out there called Trusting Trust which discusses drawing a line between what is and is not practical. We trust C developers to not create bugs that introduce authentication back-doors during future builds. Why? Because, even if we /could/ read through the C source and review everything that's changing, we're still not going to catch everything for the same reason that bugs exist in the first place. Heck, we can't keep bugs out of our applications written in C even assuming C itself is entirely bug free. The point I'm attempting to make is that it's not practical to check every anti-forgery feature of every document. It's not (always) practical to verify an identity based on a long history of in-person interactions. Meeting someone, checking the features that don't require special equipment, having a chat with them, verifying no typos exist, and looking at existing work signed by that key, and sending an encrypted signature to that address is what we have decided is practical. Is this not why we require DD signatures in the first place? We're trusting that all DD's have put in enough effort to ensure the identity of every key they've signed. Kinda like being an op in a #debian* IRC channel; you're automatically held to a higher standard when accepting the role. I feel like the established policies do a good job of meeting in the middle of the two extremes that have been discussed. We're trusting all DD's to follow the policies that have been decided on as the practical line. If a few DD's choose to adhere to a higher standard, so-be-it, but a lower standard should be avoided. I know DD's that trust something signed with my key is me. None of them will sign my key because they've never met me. It would be concerning if they were willing to because it reduces the overall integrity of the Debian project. Somewhere, I saw it mentioned that you should be able to verify based on history only and their legal name doesn't matter. I don't entirely disagree. The chances of the NSA building a super computer to contribute to Debian, become a DD, and add backdoors into unwatched packages are pretty low. However, this does create hurdles for someone that has left the project under poor circumstances to build a new identity that they use to harm the project. It's also comforting to imagine every DD/DM is real person, just like the rest of us, and is the person they claim to be. tl;dr -- +1 existing policies :)
