Re: metapackages and setting config files in /etc and /home/dir
On Tue, Jan 12, 2016 at 06:53:01PM -0500, Stephan Foley wrote:
> On Tue, Jan 12, 2016 at 8:34 AM, Wouter Verhelst wrote:
> > That depends to a large extent on what you want to do with it once
> > you've built the package.
>
> I should of mentioned, ultimately it is for a Debian Pure Blend. For
> now, I am just hacking things out.
>
> > If you want to upload the package to Debian, then the answer is a clear
> > no. Debian Policy forbids touching other packages' files in /etc with
> > the strongest wording, as well as doing anything to /home other than
> > ensuring it exists. The former is because it would cause confusion who
> > is responsible when things go wrong, the latter is because /home is
> > meant for local use and we shouldn't touch it as a distribution, period.
>
> I understand the /etc policy and the modular plugins most packages use
> for third party configs (like Apache).
>
> On the other hand, I was really hoping for an install that looks like this:
>
> - install xorg, lightdm, window_manager, etc
>
> - populate /etc/skel
>
> - create user and copy /etc/skel to $HOME
That is something you *can* do, and is perfectly fine. As long as you
don't overwrite files already there, there's nothing wrong with writing
new files to /etc/skel.
However, you should note that it is also of limited value, since
new files in /etc/skel are not written to the home-directories of users
already created before the package was installed or upgraded. For that
reason, Debian policy also states you should not require that such files
exist or have a particular value.
If the goal is to create a pure blend that makes it easy to recreate a
particular environment on a new system, however, then creating files in
/etc/skel may well be the best way forward. You should, however, also
make it clear in your documentation that you're doing so, how it may
fail ("it won't work for users who were created before package X was
installed") and how people can work around that issue ("copy file X, Y,
and Z from /etc/skel to your home directory").
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Re: PHP 5 to PHP 7.0 transition and change of PHP packaging to allow coinstallable versions
Hi all, [...] 9. We expect to ship next Debian release (stretch) only with PHP > 7.0, that means that all packages needs to be made compatible > with PHP 7.0. [...] Mathieu [gdcm upstream] just pointed out to me that Swig does not yet support PHP 7.0 [1], which means that for the time being packages that rely on it to create the language bindings will not be able to support it. Best, Gert [1] https://github.com/swig/swig/issues/571
Re: Debian package non-strict equal dependencies
]] Russ Allbery > Dmitrii Kashin writes: > > Josselin Mouette writes: > > >> In a Debian repository, there can be only one version of D at a time, > >> so this cannot happen. If you want two versions of the same package in > >> the same repository, they need to have different source and binary > >> names (the name can be something like D-2.0 or D-3.0 of course). > > > Wow. Thank you very much for this warning. I'll notify all our personnel > > that we must reconsider our repository publication process. > > This isn't true of Debian repositories in general. The file format > handles multiple versions of the same package just fine, as do apt and > other tools. It's an intentional restriction imposed by dak for the > Debian archive, and copied by some other archive tools (I think reprepro > imposes this restriction, for instance), but other archive management > tools do not. aptly, for example, is perfectly happy to manage multiple > versions of the same package, and dpkg-scanpackages doesn't care. dak doesn't enforce this per se. dak will happily publish multiple versions in the same suite if you don't run dak dominate. (So it's how Debian chooses to run the repository, rather than the tooling forcing it.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#810890: ITP: caddy -- Fast, cross-platform HTTP/2 web server with automatic HTTPS
Package: wnpp Severity: wishlist Owner: Zlatan Todoric * Package name: caddy Version : 0.8.1 Upstream Author : Mathhew Holt * URL : https://caddyserver.com/ * License : Apache 2.0 Programming Lang: Go Description : Fast, cross-platform HTTP/2 web server with automatic HTTPS Caddy is a lightweight, general-purpose web server for Windows, Mac, Linux, BSD and Android. It is a capable alternative to other popular and easy to use web servers. The most notable features are HTTP/2, Let's Encrypt support, Virtual Hosts, TLS + SNI, and easy configuration with a Caddyfile. In development, you usually put one Caddyfile with each site. In production, Caddy serves HTTPS by default and manages all cryptographic assets for you.
Re: Bug#810890: ITP: caddy -- Fast, cross-platform HTTP/2 web server with automatic HTTPS
On Wed, Jan 13, 2016 at 01:27:10PM +0100, Zlatan Todoric wrote: > * Package name: caddy > * URL : https://caddyserver.com/ > Description : Fast, cross-platform HTTP/2 web server with > automatic HTTPS > > Caddy is a lightweight, general-purpose web server for Windows, Mac, > Linux, BSD and Android. It is a capable alternative to other popular and > easy to use web servers. > > The most notable features are HTTP/2, Let's Encrypt support, Virtual > Hosts, TLS + SNI, and easy configuration with a Caddyfile. In > development, you usually put one Caddyfile with each site. In > production, Caddy serves HTTPS by default and manages all cryptographic > assets for you. Please make it clear whether it's HTTP/1+HTTP/2 or HTTP/2-only. The current description makes it sound as it's the latter. -- A tit a day keeps the vet away.
Re: APT 1.2 preview uploaded to experimental -- please test
Hi, Le 13/01/2016 00:18, Julian Andres Klode a écrit : > On Fri, Jan 08, 2016 at 10:13:51PM +0100, Julian Andres Klode wrote: >> Good moo, >> >> I just uploaded APT 1.2~exp1 to experimental. This release includes >> the following highlights: >> >> * Automatic removal of debs after install for apt(8) >> * LZ4 support >> * Recompression of indices >> * Parallel rred >> * Further 15% performance gain in cache generation >> >> It should hit the archive with the next dinstall run. >> >> It will be uploaded to unstable in the coming days, we only want to >> get some testing and fix some other bugs from unstable first. > > There have been no reports of regressions compared to 1.1, so we'll > probably go ahead with an upload to unstable *this week* (Friday > maybe). Sorry, I found one (regression). Before "apt-get update" takes about 20s on my system After "apt-get update" takes more than 5 min on my system... Details in the bug I just filled (#810898). It is linked to the use of compressed indices advertized with this release. That said, thank you for the big improvments on APT you did. Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: Bug#810890: ITP: caddy -- Fast, cross-platform HTTP/2 web server with automatic HTTPS
On 01/13/2016 01:39 PM, Adam Borowski wrote: > On Wed, Jan 13, 2016 at 01:27:10PM +0100, Zlatan Todoric wrote: >> * Package name: caddy >> * URL : https://caddyserver.com/ >> Description : Fast, cross-platform HTTP/2 web server with >> automatic HTTPS >> >> Caddy is a lightweight, general-purpose web server for Windows, Mac, >> Linux, BSD and Android. It is a capable alternative to other popular and >> easy to use web servers. >> >> The most notable features are HTTP/2, Let's Encrypt support, Virtual >> Hosts, TLS + SNI, and easy configuration with a Caddyfile. In >> development, you usually put one Caddyfile with each site. In >> production, Caddy serves HTTPS by default and manages all cryptographic >> assets for you. > > Please make it clear whether it's HTTP/1+HTTP/2 or HTTP/2-only. The current > description makes it sound as it's the latter. > Yes, it will be made clear. It supports both, by default HTTP/2 but it falls back if client only supports HTTP/1. Also http2 can be disabled by flag (-http2=false).
Re: APT 1.2 preview uploaded to experimental -- please test
I have been testing APT 1.2 under the ppa:deity/sid PPA in Ubuntu Xenial. It seems to be working very well, and I am really liking the various improvements. Thanks for all the hard work! Keep it up! :) -- Have a nice day, Simon Quigley tsimonq2 Contact for the Ubuntu US Wisconsin LoCo Team Lubuntu Quality Assurance Tester
Re: APT 1.2 preview uploaded to experimental -- please test
On Wed, Jan 13, 2016 at 03:07:06PM +0100, Vincent Danjean wrote: > Hi, > > Le 13/01/2016 00:18, Julian Andres Klode a écrit : > > On Fri, Jan 08, 2016 at 10:13:51PM +0100, Julian Andres Klode wrote: > >> Good moo, > >> > >> I just uploaded APT 1.2~exp1 to experimental. This release includes > >> the following highlights: > >> > >> * Automatic removal of debs after install for apt(8) > >> * LZ4 support > >> * Recompression of indices > >> * Parallel rred > >> * Further 15% performance gain in cache generation > >> > >> It should hit the archive with the next dinstall run. > >> > >> It will be uploaded to unstable in the coming days, we only want to > >> get some testing and fix some other bugs from unstable first. > > > > There have been no reports of regressions compared to 1.1, so we'll > > probably go ahead with an upload to unstable *this week* (Friday > > maybe). > > Sorry, I found one (regression). > Before "apt-get update" takes about 20s on my system > After "apt-get update" takes more than 5 min on my system... > Details in the bug I just filled (#810898). It is linked to the > use of compressed indices advertized with this release. They never worked well for outside code. That's just a fact. Most stuff will even simply break, dd-list for example. I recently announced a mass bug filing to fix this. For those that work but are slow, it's mostly always a issue of random access to Packages files instead of linear access. Acquire::gzipIndexes exists since more than 5 years, since 0.7.26~exp10 from 12 Jul 2010 to be precise. Let's make sure we get it working now that it's actually fast. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to (`inline'). Thank you.
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
Le 12/01/2016 23:14, Niels Thykier a écrit : > Please have a look at: > > * man apt-file > * The example config in /usr/share/doc/apt-file/examples >- Let me know if they work for you or not. Yes, it works. Many thanks. I did not know the "#clear" directive but I added one more: #clear APT::Update::Post-Invoke; It avoids debtags to be run for more than 5 min... (see #810898) Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: MBF: (Incorrect) use of /var/lib/apt/lists/
On Mon, 11 Jan 2016 17:25:40 +0100, Julian Andres Klode wrote: >Marc Haber > exim4 (U) This is a false positive, the respective point is in an internal make target that the exim4 maintainers use internally before upload, it is never used during package build or package used. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
mass filing bug reports for GCC 6 build issues
GCC 6 is still intended to be the default GCC for the upcoming stretch release. It doesn't yet build on mips and mipsel (gfortran and gnat), however GCC 5 has non-addressed RC issues on these architectures, so maybe better regress on release architectures than toolchain progress. Debian QA didn't yet find the time for a comparative test rebuild on the amazon hardware, so until now I only have data for a test rebuild of the current Ubuntu development series, otoh with a wider coverage on architectures. Lucas Nussbaum assured me that an amd64 test rebuild could be done in early Feb. Now, I'd like to file the issues I found for the Ubuntu test rebuild on the Debian packages. Of course there will be some false positives. Just not having any bugs filed at all is bad, maybe having bugs filed for diverging Debian/Ubuntu versions could be bad too (although it looks like that the version is the least important thing for new warnings, more strictness or symbols file changes). So at least I'd like to file issues for matching Debian/Ubuntu versions, but would strive to file issues for all packages. For regressions build packages please see http://people.canonical.com/~doko/tmp/gcc6-regr/ Issues for all known GCC ICEs were already filed and most of them already fixed upstream (see https://gcc.gnu.org/ml/gcc/2016-01/msg00101.html). Full list of build failures (including those which are not regressions): http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151218.1-gcc6-xenial.html gcc-6 packages are available in experimental. Matthias
Re: metapackages and setting config files in /etc and /home/dir
Hi Wouter,
On Wed, Jan 13, 2016 at 4:37 AM, Wouter Verhelst wrote:
>> On the other hand, I was really hoping for an install that looks like this:
>>
>> - install xorg, lightdm, window_manager, etc
>>
>> - populate /etc/skel
>>
>> - create user and copy /etc/skel to $HOME
>
> That is something you *can* do, and is perfectly fine. As long as you
> don't overwrite files already there, there's nothing wrong with writing
> new files to /etc/skel.
>
> However, you should note that it is also of limited value, since
> new files in /etc/skel are not written to the home-directories of users
> already created before the package was installed or upgraded. For that
> reason, Debian policy also states you should not require that such files
> exist or have a particular value.
>
> If the goal is to create a pure blend that makes it easy to recreate a
> particular environment on a new system, however, then creating files in
> /etc/skel may well be the best way forward. You should, however, also
> make it clear in your documentation that you're doing so, how it may
> fail ("it won't work for users who were created before package X was
> installed") and how people can work around that issue ("copy file X, Y,
> and Z from /etc/skel to your home directory").
Thanks for the guidance. The more I learn about this issue, the more I
understand that the best solution is to contact upstream developers
and request they change their packaging to allow for third party
configurations.
Good advice, I appreciate it,
Steve
Re: MBF: (Incorrect) use of /var/lib/apt/lists/
Hi, Quoting Ralf Treinen (2016-01-13 08:11:40) > On Mon, Jan 11, 2016 at 05:25:40PM +0100, Julian Andres Klode wrote: > > > the following packages contain lines matching the > > expression: > > /var/lib/apt/lists/.*(Packages|Sources) > > > > Those files may be compressed by any compressor > > supported by APT and just hardcoding them is > > wrong. > > [...] > > > Debian OCaml Maintainers > >coinst > >dh-ocaml > >dose3 > > These are false positives: in case of coinst and dose3, the pattern occurs > only in documentation showing examples of using these tools. I'd argue that'd still be a minor bug because teaching users in the documentation to use files in /var/apt/lists directly will just continue to encourage people to do this instead of using the now existing apt interfaces. The right way to access these files will see much more wide spread use if documentation is updated to use it as well. Thanks! cheers, josch signature.asc Description: signature
Bug#810949: ITP: ncbi-entrez-direct -- NCBI Entrez utilities on the command line
Package: wnpp Severity: wishlist Owner: "Aaron M. Ucko" * Package name: ncbi-entrez-direct Version : 3.60 Upstream Author : Jonathan Kans * URL : http://www.ncbi.nlm.nih.gov/books/NBK179288 * License : Public Domain Programming Lang: Perl, Go, Bourne shell Description : NCBI Entrez utilities on the command line Entrez Direct (EDirect) is an advanced method for accessing NCBI's set of interconnected databases (publication, sequence, structure, gene, variation, expression, etc.) from a terminal window or script. Functions take search terms from command-line arguments. Individual operations are combined to build multi-step queries. Record retrieval and formatting normally complete the process. EDirect also provides an argument-driven function that simplifies the extraction of data from document summaries or other results that are returned in structured XML format. This can eliminate the need for writing custom software to answer ad hoc questions. Queries can move seamlessly between EDirect commands and UNIX utilities or scripts to perform actions that cannot be accomplished entirely within Entrez. With all due respect to the Go packaging team, I feel that maintaining EDirect within Debian Med or perhaps Debian Science would be more appropriate, as it falls outside the mainstream Go ecosystem. Yes, one individual tool happens to be written in Go, but EDirect otherwise consists of a mixture of Perl and shell scripts, and the Go tool has no dependencies beyond the standard library. Also, I am inclined to build the tool in question with gccgo rather than golang-go, which is available for fewer architectures and provides no obvious way to obtain dynamic linkage against system libraries, for which Policy 10.1 calls. I'm debating whether to go fully dynamic (yielding, on amd64, a 228K executable depending on a 34M library with hardly any other reverse dependencies) or to link libgo statically (yielding a 3.2M executable with no exotic dependencies). I suppose the fully dynamic approach is better practice, but would appreciate feedback on this point. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: mass filing bug reports for GCC 6 build issues
* Matthias Klose [2016-01-13 18:34]: > Debian QA didn't yet find the time for a comparative test rebuild on the > amazon hardware, so until now I only have data for a test rebuild of the > current Ubuntu development series > Now, I'd like to file the issues I found for the Ubuntu test rebuild on the > Debian packages. Of course there will be some false positives. If you think it would be useful, I should be able to find time within the next 10 days to do a build of Debian unstable on amd64 and probably on arm64. -- Martin Michlmayr http://www.cyrius.com/
