Re: Opt out style recommends
Den 08. april 2016 19:31, skrev Josh Triplett: > emacs24-common Recommends: emacs24-el > > I don't think all but the most unusual configurations need the elisp > source of the functionality already provided by the main emacs24 > package. Emacs/elisp developers will want this. > > There is often two sides to such arguments: - An editor needs a scripting and configuration language. emacs has elisp. If you want to be able to see what knobs are available for adjusting, you look at the source. When your scripts have errors, you want to be able to view source to find out what you did wrong. - If you will never be scripting emacs, you are better off with pico or nano as an editor. In other words: not all of the things you mention are quick no-brainers to get changed :-/
Re: Opt out style recommends
Håkon Alstadheim writes: > Den 08. april 2016 19:31, skrev Josh Triplett: >> emacs24-common Recommends: emacs24-el >> >> I don't think all but the most unusual configurations need the elisp >> source of the functionality already provided by the main emacs24 >> package. Emacs/elisp developers will want this. >> >> > There is often two sides to such arguments: > - An editor needs a scripting and configuration language. emacs has > elisp. If you want to be able to see what knobs are available for > adjusting, you look at the source. When your scripts have errors, you > want to be able to view source to find out what you did wrong. As you describe it, the source file have a similar function as the debug files for a library, which are (for a good reason) also not set as Recommends. Emacs (and many of its lisp libraries) are quite stable today; so in the rare case of an error, you could just add the source later and re-run the problem. > - If you will never be scripting emacs, you are better off with pico or > nano as an editor. I use emacs since >20 years, and love it. However, I *very* rarely do emacs scripting, and almost never outside of some configuration. Sorry, I don't see this as an argument. To do scripting, you also usually don't need the sources. For me, the lisp source are really unused, and I think that I am not a rare, exceptional case. Best regards Ole
Re: Opt out style recommends
Quoting Russ Allbery (2016-04-09 03:20:25) > Adam Borowski writes: >> Like: >> xfce4-power-manager -> upower -> libimobiledevice4 -> usbmuxd > >> Is the recommendation from libimobiledevice4 to usbmuxd valid? Sure >> it is -- the library is useless without the daemon. [...] > So, where this goes wrong is the upower -> libimobiledevice4 > dependency. As you say, the dependency is correct (or at least > correct-ish): we don't want to dlopen everything and try to push all > those patches upstream. But this is the weakest link of this whole > chain, yet has the strongest dependency. > > I think a more correct fix would (unfortunately) involve a new binary > package field that we don't currently have: Depends-Shallow (for lack > of a better term) that acts like Depends *except* disables Recommends > processing for anything below the shallow dependencies in the tree. > So if everything you're installing only Depends-Shallow on > libimobiledevice4, you don't get the recommendation; if anything > straight depends on it, you do. I disagree that we need a new field: Simply lower to at most suggest the daemon: It is for the daemon to declare a stronger dependency. Anyone needing the daemon can install the daemon - you shouldn't expect libraries to pull in daemons (just as you shouldn't expect documentation to pull in binaries). >> And, many maintainers could take this as an attack: "what, my package >> is useless?!?". Like, openssh-server -> libwrap0 -> tcpd. I'd say >> pretty much anyone today uses other means for limiting access to ssh; >> tcpd does have near-universal popcon (95.79%!) but protocols listed >> in its description (telnet ftp rsh rlogin finger) and complete dearth >> of new bug reports (it received tons in the past) make me think it's >> not actually used anymore. > > I still use tcpd for openssh-server. (This is not an argument for > keeping the chain, just a data point.) tcpd, unlike iptables, can > whitelist domains. It's weak security, but it's good for defense in > depth and making the constant brute force attacks die down a bit. I agree it is no argument for keeping the chain: Those using tcpd can install that - or install a metapackage that depends on or recommends it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Opt out style recommends
On 2016-04-09, Jonas Smedegaard wrote: > I disagree that we need a new field: Simply lower to at most suggest the = > daemon: It is for the daemon to declare a stronger dependency. > Anyone needing the daemon can install the daemon - you shouldn't expect = > libraries to pull in daemons (just as you shouldn't expect documentation = > to pull in binaries). Sometimes, the daemon is an implementation detail of the library. Or a hard requirement for the library to function. Sometimes it is even a hard requirement for the library to not crash. /Sune
Re: Opt out style recommends
Quoting Sune Vuorela (2016-04-09 10:34:24) > On 2016-04-09, Jonas Smedegaard wrote: >> I disagree that we need a new field: Simply lower to at most suggest >> the = daemon: It is for the daemon to declare a stronger dependency. >> Anyone needing the daemon can install the daemon - you shouldn't >> expect = libraries to pull in daemons (just as you shouldn't expect >> documentation = to pull in binaries). > > Sometimes, the daemon is an implementation detail of the library. Or a > hard requirement for the library to function. Sometimes it is even a > hard requirement for the library to not crash. Such (rare, I suspect) cases would require Depends, not Recommends as is discussed in this here, I believe. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#820520: ITP: r-cran-phylobase -- GNU R base package for phylogenetic structures and comparative data
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-phylobase Version : 0.8.2 Upstream Author : Francois Michonneau * URL : https://cran.r-project.org/web/packages/phylobase/ * License : GPL-2+ Programming Lang: R Description : GNU R base package for phylogenetic structures and comparative data This R package provides a base S4 class for comparative methods, incorporating one or more trees and trait data as these are used in other packages dealing with phylogenetic structures and comparative data. Remark: This package belongs to a pyramid of dependencies for r-cran-treescape and will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-phylobase/trunk/
Re: Remove clamav-unofficial-sigs
On Wed, 6 Apr 2016, Marco d'Itri wrote: [...] > > A year ago a user also mentioned that there is a new upstream version > I have some doubts about the quality of this fork, so I plan to > investigate in detail what has changed before blindly adopting it. What about uploading a new version with the si_dbs line commented out in 00-clamav-unofficial-sigs.conf as suggested last year in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783228 The SecuriteInfo databases are unusable anyway so there would be nothing lost, and this would at least stop the corresponding syslog spam, making the rest of the package that much more usable. And marking bugs 774763 and 784832 as duplicates of 783228 would clean things up a bit too and has no reason to block on fixing access to SecuriteInfo. -- Francois Gouget http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner
Re: Opt out style recommends
On Sat, Apr 09, 2016 at 08:34:24AM +, Sune Vuorela wrote: > On 2016-04-09, Jonas Smedegaard wrote: > > I disagree that we need a new field: Simply lower to at most suggest the = > > daemon: It is for the daemon to declare a stronger dependency. > > Anyone needing the daemon can install the daemon - you shouldn't expect = > > libraries to pull in daemons (just as you shouldn't expect documentation = > > to pull in binaries). > > Sometimes, the daemon is an implementation detail of the library. Or a > hard requirement for the library to function. Sometimes it is even a > hard requirement for the library to not crash. Right, it may be a hard requirement for the library. It may be not a requirement for an user of the library, if that library is pulled only for an obscure feature. The problem is, dependencies are transitive. And in most languages it's tedious to make a library optional at runtime. So some solution would be nice, be it Russ' new field or my moving such dependencies away from libraries. -- A tit a day keeps the vet away.
Bug#820547: ITP: harvest-tools -- archiving and postprocessing for reference-compressed genomic multi-alignments
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: harvest-tools Version : 1.2 Upstream Author : Todd Treangen * URL : https://github.com/marbl/harvest-tools * License : BSD Programming Lang: C++, Python Description : archiving and postprocessing for reference-compressed genomic multi-alignments HarvestTools is a utility for creating and interfacing with Gingr files, which are efficient archives that the Harvest Suite uses to store reference-compressed multi-alignments, phylogenetic trees, filtered variants and annotations. Though designed for use with Parsnp and Gingr, HarvestTools can also be used for generic conversion between standard bioinformatics file formats. Remark: This package belongs to a wider toolset to deal with genomic alignments. It will be packaged by the Debian Med team at https://anonscm.debian.org/git/debian-med/harvest-tools.git
gitlab package (was Re: Opt out style recommends)
hi,
On 04/08/2016 05:33 AM, Pirate Praveen wrote:
> See #819854 for a background.
>
> Currently gitlab recommends letsencrypt, it means someone has to opt in for
> letsencrypt by running something like
>
> apt-get install gitlab letsencrypt
>
> But I would like letsencrypt to be available by default (postinst asks if
> they want t
while i really appreciate all the work you are doing for the gitlab
package, i honestly have the feeling that you are trying to make too
many decisions on behalf of the system administrator who wants to
install gitlab.
i really don't see any compelling reason why a package like gitlab
should force me to use any special means to encrypt my connection.
there are a number of reasons to use the Debian gitlab packages over the
ones provided by upstream (e.g. omnibus), and one of them is being able
to chose the components i would like to have on my system (or not).
but the way the package is heading seems to take away choices rather
than give me additional ones: e.g. using upstream's gitlab-ce omnibus
packages i am *free* to choose whatever method i like to setup an
encrypted webserver (allowing me to e.g. setup a gitlab instance that is
not accessible from the public internet - something that is impossible
with letsencrypt afaict).
i would love if the gitlab package in Debian was as *minimal* as
possible giving *me* (the admin) the freedom to choose the largest
possible set of components - probably (and likely) at the expense that I
(the admin) will need to setup quite a lot of things myself.
i guess there are *many* things to setup and this might make it
impossible for newbee administrators to setup their own gitlab instance.
but i think that there are ways to accomodate both the seasoned admin
(probably in a corporate environment dictating whatever policies) and
the any random developer (who want an instance for their personal use
without worrying too much about administration).
e.g. instead of making the 'gitlab' package work magic and conjure the
perfect configuration for any usecase, you could instead:
- add *good* documentation; with configuration examples, step-by-step
instructions to setup whatever additional service,...
- provide an *additional* package ("gitlab-to-go", but please cose a
better name :-)) which depends on 'gitlab' (and other packages like
'letsencrypt') and which does the magic to provide the "it just works"
experience for selected use-cases.
i really hope that this will simplify your work as a maintainer of such
a complex package. (or put otherwise: i think that the quest to come up
with a satisfying configuration for all potential users is NP-complete
and will indefinitely stall further packaging or make the package
unusable for some users or both)
a nice side effect might be that it would allow Debian gitlab packages
follow upstream more closely (e.g. Debian currently has
gitlab-8.4.3+dfst-12 whereas upstream currently has 8.6.4 (and the 8.4
series is at bugfix release 8.4.7; the numbers might be a bit misleading
though, as Debian might not be affected by a few bugs that triggered
there own bugfix release).
anyhow, thanks again for doing all the work to bring us gitlab.
fgmards
IOhannes
signature.asc
Description: OpenPGP digital signature
Re: /usr/bin/openssl failed on sso.debian.org
On Fri, Apr 08, 2016 at 09:06:33PM +0200, Jonas Smedegaard wrote: > > Which is fine, I guess, for someone living in an ecosystem where > > «authentication via "log in with your Google or Facebook account"» is > > all your users would ever need. > > > > I guess I should stop writing here, as at the moment I can think of a > > lot of things to write, but nothing constructive among them. > > The W3C public-rww list has some possibly interesting references related > to this issue: > https://www.w3.org/mid/https://www.w3.org/mid/20150730174424.GA7779@c > > If similar issues arise, it might make sense to try get in touch with > them: WebID is quite similar to our setup, and therefore face exactly > the same problems from client side. I have seen no sign that Chrome or Firefox developers have much interest in supporting WebID either, and given how I've seen one of the WebID people argue their case[1] with the Chrome and Firefox developers, the little interest they might have had to start with is probably gone by now :/ Enrico [1] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: /usr/bin/openssl failed on sso.debian.org
Quoting Enrico Zini (2016-04-09 22:11:54) > On Fri, Apr 08, 2016 at 09:06:33PM +0200, Jonas Smedegaard wrote: >>> Which is fine, I guess, for someone living in an ecosystem where >>> «authentication via "log in with your Google or Facebook account"» >>> is all your users would ever need. >>> >>> I guess I should stop writing here, as at the moment I can think of >>> a lot of things to write, but nothing constructive among them. >> >> The W3C public-rww list has some possibly interesting references >> related to this issue: >> https://www.w3.org/mid/https://www.w3.org/mid/20150730174424.GA7779@c >> >> If similar issues arise, it might make sense to try get in touch with >> them: WebID is quite similar to our setup, and therefore face exactly >> the same problems from client side. > > I have seen no sign that Chrome or Firefox developers have much > interest in supporting WebID either, and given how I've seen one of > the WebID people argue their case[1] with the Chrome and Firefox > developers, the little interest they might have had to start with is > probably gone by now :/ You can consider both WebID itself and the social skills of its defenders bad, yet still benefit from following their work. But sure, you can also ignore that work (if that is what you imply). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#820561: ITP: dh-elpa-test -- Debian helper tool for running ELPA package testsuites
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: dh-elpa-test Version : 0.1.0 Upstream Author : Sean Whitton * URL : N/A * License : GPL-3+ Programming Lang: Perl Description : Debian helper tool for running ELPA package testsuites dh-elpa-test will try to run the upstream testsuites for ELPA packages prepared with dh_elpa. For ELPA packages, dh_auto_test alone is rarely suitable. I plan to maintain it as part of the pkg-emacsen team. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#820561: ITP: dh-elpa-test -- Debian helper tool for running ELPA package testsuites
On Sat, Apr 09, 2016 at 02:53:05PM -0700, Sean Whitton wrote: > Description : Debian helper tool for running ELPA package testsuites > > dh-elpa-test will try to run the upstream testsuites for ELPA packages > prepared with dh_elpa. For ELPA packages, dh_auto_test alone is rarely > suitable. Any reason this can't go in src:dh-elpa itself? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2016: second call for votes
Sorry for top posting - but wrong year? (and thus wrong selection of
candidates ;) )
On 04/10/2016 12:48 AM, Debian Project Secretary - Kurt Roeckx wrote:
Hi,
This is the 2nd call for votes for the DPL election.
Voting period starts Wed Apr 1 00:00:00 UTC 2015
Votes must be received by Tue Apr 14 23:59:59 UTC 2015
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at http://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate platform can be found at:
http://www.debian.org/vote/2015/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2015".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the platform.
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 4 choices in the form, which you may rank with numbers between
1 and 4. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 4.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
To vote "no, no matter what", rank "None Of The Above" as more desirable
than the unacceptable choices, or you may rank the "None Of The Above"
choice and leave choices you consider unacceptable blank. (Note: if the
"None Of The Above" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"None Of The Above" choice by the voting software).
Finally, mail the filled out ballot to: leader2...@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">") that
your reply inserts.
NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
1455c447-77dc-4237-b0f9-be3897bb2b80
[ ] Choice 1: Mehdi Dogguy
[ ] Choice 2: Gergely Nagy
[ ] Choice 3: Neil McGovern
[ ] Choice 4: None Of The Above
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
--
The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1
mQINBFUbIAkBEAC9uIv5zHSJJzolXSxpGxCR7QsI6jdn93IOd+iz7RiKgOFRRkTA
oj0ZkzN7kcGWGDyebVUPPweOJo7JmftPMKq15pzbVb2N4Cs9rlYFAnnVQ7NDl8l8
qTyWQ7iUX+WSTT5NLU3f0MU0ZO+rY8QO3ha8OWgbiVqIgnthoTwB1pVtM9b9FJtp
9jXMjEjiiwsRywzYiAc7ZVib5514jZCSJrIHS6gfb7MxFOLUPeCbVtJUS4WB+Pl2
LvfhWSSOPn5d1HyaJJyRVVzfDPVnlu6/IbwgxsyQs1vGZfK/UWXfFgjKg/LORGiu
0acWuPwHkEeK6jsDmdXlCdARm2hu4rWnuXIhJQR2UCV7LYZIz5wUDi3TGRsp86Gq
S2wdzzXTgw+Wxtm086WveleyJvhoyQOtWjl4W5d4/NUCP5FynGgt/Qh6eEnzr3jS
PZ2oZ6MLLe6lT9GRl/bRgdu2Q26GtDQ9OyeG+zU9hyGTFfGINaSMhiHa1HTLTFIa
nr+T5vbni14bMMAhuzL/nNiROqGm3DpBqu+MqXFMl7KpoBuY/fHmBSSiQ0pVMnhN
sazg8XZunPHrIW2TBvdozYjTHioZPPYL1PtG7Q6X9hdid8u5z0Gtt8OwrF1RpwSF
0H69trBL7BlltgcAF4oW5IqikQ3OEwu66aMdcu/WbL9sQvTjrsSc8qHh/QARAQAB
tCpEUEwgdm90ZSAyMDE1IDxsZWFkZXIyMDE1QHZvdGUuZGViaWFuLm9yZz6JAj4E
EwECACgFAlUbIAkCGwMFCQAXuwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
EMqaX6zYUX5vszIP/3VMgSI72JGaLKmDJ1XPdP51mXcAW3VtJc0d6L65Vah08DYk
KnLd2eRyR3NXZlAoTMeIWI5ani3BwfT6cUH99hYbxLjiecW3TPZUfN9fer+etKWm
9jPqOjqJf6Sx7XCGqCBrLUUhfjvHO6HpSr11H+jJ77STo4p8ihiURLD7EUs6dqHj
YRp7HkCi83Ol7MvwEPqG6B7ZqMfD8k6QmK8Az/Va4JC2bKj/kHCVMoXZiLulVxsC
xgqlau52duXbF6Qbz1evpoAlvfMraqspq2YoLBugh9dNlVMUAzNU+TWynon9puIe
ExfLEDGQ9REnO37L4DB+ymEtrKeQsopvSfgb9WmVbenSv+3K7PNnfJLbSHLhg5hu
LTOgz4cbd3FIfg7W9td7nXhQ68CPVpRg80Soa1ZLwxeCLdG3DOoB1+khc3Gx5PgJ
vSk+3FjT6e+teRmPu2ZKTTAskxkV3eUGV5kfDuVhfMQD6HG3e7HB37ZcFAbX9JUt
dViHQj7X/jeQpGhnZ7FmodDJjObxUcgqtmY0K0b3B+jEwPudoXeKCmF7lKdVQOeI
kvXlVlx0J6u7d0+Qty96hRxASomGGR8kR/zsDRfEV2TyzjpXfhrTikVyIrj+lp27
fOwHZCDzpTdy6ENYH3s0ZrljtyFCTjfnmISo/k1A9a7Ikir2Sp1U8U7EaCwjiQIc
BBABCgAGBQJ
Re: Opt out style recommends
On Fri, 08 Apr 2016, Russ Allbery wrote: > So, where this goes wrong is the upower -> libimobiledevice4 dependency. > As you say, the dependency is correct (or at least correct-ish): we don't > want to dlopen everything and try to push all those patches upstream. But > this is the weakest link of this whole chain, yet has the strongest > dependency. > > I think a more correct fix would (unfortunately) involve a new binary > package field that we don't currently have: Depends-Shallow (for lack of a > better term) that acts like Depends *except* disables Recommends > processing for anything below the shallow dependencies in the tree. So if > everything you're installing only Depends-Shallow on libimobiledevice4, > you don't get the recommendation; if anything straight depends on it, you > do. Make it "downgrades recommends to suggests" and it might even work well. But since there exists recommends one is much better off never downgrading, we might end up needing a recommends-strong field as well that would never be downgraded, to avoid the need to upgrade such recommends to depends. At least it would end there with two extra headers (or some other way to annotate recommends dependency headers in these two ways), so it is still something that looks like it could work. But how much of a trouble would such changes cause for the dependency solvers? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: gitlab package (was Re: Opt out style recommends)
On 2016, ഏപ്രിൽ 10 12:28:29 AM IST, "IOhannes m zmölnig (Debian/GNU)"
wrote:
>hi,
>
>On 04/08/2016 05:33 AM, Pirate Praveen wrote:
>> See #819854 for a background.
>>
>> Currently gitlab recommends letsencrypt, it means someone has to opt
>in for letsencrypt by running something like
>>
>> apt-get install gitlab letsencrypt
>>
>> But I would like letsencrypt to be available by default (postinst
>asks if they want t
>
>while i really appreciate all the work you are doing for the gitlab
>package, i honestly have the feeling that you are trying to make too
>many decisions on behalf of the system administrator who wants to
>install gitlab.
I just want the service up and running after you install gitlab. Isn't it how
every other service doing it?
>i really don't see any compelling reason why a package like gitlab
>should force me to use any special means to encrypt my connection.
It does not. Even earlier with letsencrypt in depends, it asks in post install
if letsencrypt should be used. Now it is in recommends and you can just skip
letsencrypt.
>there are a number of reasons to use the Debian gitlab packages over
>the
>ones provided by upstream (e.g. omnibus), and one of them is being able
>to chose the components i would like to have on my system (or not).
It is just the first attempt and making all components optional is in my todo.
Patches to speed it up is welcome.
nginx is already made optional in last update. Next is database.
>but the way the package is heading seems to take away choices rather
>than give me additional ones: e.g. using upstream's gitlab-ce omnibus
>packages i am *free* to choose whatever method i like to setup an
>encrypted webserver (allowing me to e.g. setup a gitlab instance that
>is
>not accessible from the public internet - something that is impossible
>with letsencrypt afaict).
Already covered. You can choose not to use letsencrypt.
>i would love if the gitlab package in Debian was as *minimal* as
>possible giving *me* (the admin) the freedom to choose the largest
>possible set of components - probably (and likely) at the expense that
>I
>(the admin) will need to setup quite a lot of things myself.
Already answered.
>i guess there are *many* things to setup and this might make it
>impossible for newbee administrators to setup their own gitlab
>instance.
>but i think that there are ways to accomodate both the seasoned admin
>(probably in a corporate environment dictating whatever policies) and
>the any random developer (who want an instance for their personal use
>without worrying too much about administration).
Making all components optional will do it.
And the configuration files are there to do more tweaking.
>e.g. instead of making the 'gitlab' package work magic and conjure the
>perfect configuration for any usecase, you could instead:
>
>- add *good* documentation; with configuration examples, step-by-step
>instructions to setup whatever additional service,...
>- provide an *additional* package ("gitlab-to-go", but please cose a
>better name :-)) which depends on 'gitlab' (and other packages like
>'letsencrypt') and which does the magic to provide the "it just works"
>experience for selected use-cases.
>
>i really hope that this will simplify your work as a maintainer of such
>a complex package. (or put otherwise: i think that the quest to come up
>with a satisfying configuration for all potential users is NP-complete
>and will indefinitely stall further packaging or make the package
>unusable for some users or both)
>
>a nice side effect might be that it would allow Debian gitlab packages
>follow upstream more closely (e.g. Debian currently has
>gitlab-8.4.3+dfst-12 whereas upstream currently has 8.6.4 (and the 8.4
>series is at bugfix release 8.4.7; the numbers might be a bit
>misleading
>though, as Debian might not be affected by a few bugs that triggered
>there own bugfix release).
Its already 8.5.8. Three new gems are required for 8.6 and we are already
working on it.
>
>anyhow, thanks again for doing all the work to bring us gitlab.
>
>fgmards
>IOhannes
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Bug#820561: ITP: dh-elpa-test -- Debian helper tool for running ELPA package testsuites
Hello, On Sat, Apr 09, 2016 at 10:26:57PM +, Mattia Rizzolo wrote: > On Sat, Apr 09, 2016 at 02:53:05PM -0700, Sean Whitton wrote: > > Description : Debian helper tool for running ELPA package testsuites > > > > dh-elpa-test will try to run the upstream testsuites for ELPA packages > > prepared with dh_elpa. For ELPA packages, dh_auto_test alone is rarely > > suitable. > > Any reason this can't go in src:dh-elpa itself? Yeah. If dh-elpa-test runs the tests for a package, dh_auto_test must be disabled. That's because dh_auto_test runs `make test`, and many ELPA packages will run something that is incompatible with Debian if you run `make test`. If dh-elpa-test did not disable dh_auto_test, every package using it would need boilerplate `override_dh_auto_test: /bin/true`. But the only way for a debhelper helper to disable dh_auto_test is in its sequencer script. If I put the code to disable dh_auto_test in dh_elpa's sequencer script (/usr/share/perl5/Debian/Debhelper/Sequence/elpa.pm), dh_auto_test would be disabled for *all* packages using dh_elpa, which would be undesirable since some of them have test suites that *can* be run with a simple `make test`. So dh-elpa-test needs its own sequencer script in /usr/share/perl5/Debian/Debhelper/Sequence, and so it also needs its own corresponding /usr/bin/dh_elpa_test. But then for ease of maintenance it should be its own source package. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#820561: ITP: dh-elpa-test -- Debian helper tool for running ELPA package testsuites
On Sat, Apr 09, 2016 at 09:14:29PM -0700, Sean Whitton wrote: > > Any reason this can't go in src:dh-elpa itself? > > Yeah. If dh-elpa-test runs the tests for a package, dh_auto_test must > be disabled. That's because dh_auto_test runs `make test`, and many > ELPA packages will run something that is incompatible with Debian if you > run `make test`. > > If dh-elpa-test did not disable dh_auto_test, every package using it > would need boilerplate `override_dh_auto_test: /bin/true`. But the only > way for a debhelper helper to disable dh_auto_test is in its sequencer > script. If I put the code to disable dh_auto_test in dh_elpa's sequencer > script (/usr/share/perl5/Debian/Debhelper/Sequence/elpa.pm), > dh_auto_test would be disabled for *all* packages using dh_elpa, which > would be undesirable since some of them have test suites that *can* be > run with a simple `make test`. If you put that in Debian::Debhelper::Sequence::elpa you could just check for something (an exported variable?) and/or do some magic to detect on your own, without having package maintainers having to do this choice for all those packages, couldn't you? > But then for ease of maintenance it should be its own source package. this sounds kind of ominous to me: we're talking about an alleged helper, maintained in the same team where dh-elpa is maintained. What kind of difficult of maintenance would have it? To me, it looks like it would actually *easy* the maintenance, as I couldn't figure this as something separated from dh-elpa, but only tightly united. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#820561: ITP: dh-elpa-test -- Debian helper tool for running ELPA package testsuites
Sean Whitton: > So dh-elpa-test needs its own sequencer script in > /usr/share/perl5/Debian/Debhelper/Sequence, and so it also needs its own > corresponding /usr/bin/dh_elpa_test. But then for ease of maintenance > it should be its own source package. Hi, I am not aware of any reason why a package can only provide at most one debhelper sequence? If this is the primary reason for having two packages, please assert that this assumption holds. Thanks, ~Niels signature.asc Description: OpenPGP digital signature
