Re: Reviving schroot as used by sbuild
On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote: > On Tue, 25 Jun 2024 at 10:16:20 +0200, Helmut Grohne wrote: > > In this work, limitations with --chroot-mode=unshare became apparent and > > that lead to Johannes, Jochen and me sitting down in Berlin pondering > > ideas on how to improve the situation. That is a longer story, but > > eventually Timo Röhling asked the innocuous question of why we cannot > > just use schroot and make it work with namespaces. > > I have to ask: > > Could we use a container framework that is also used outside the Debian > bubble, rather than writing our own from first principles every time, and > ending up with a single-maintainer project being load-bearing for Debian > *again*? I had hoped that after sbuild's history with schroot becoming > unmaintained, and then being revived by a maintainer-of-last-resort who > is one of the same few people who are critical-path for various other > important things, we would recognise that as an anti-pattern that we > should avoid if we can. > > At the moment, rootless Podman would seem like the obvious choice. As far > as I'm aware, it has the same user namespaces requirements as the unshare > backends in mmdebstrap, autopkgtest and schroot (user namespaces enabled, > setuid newuidmap, 65536 uids in /etc/subuid, 65536 gids in /etc/subgid). > > Podman uses the same OCI images as Docker, so it can either pull from a > trusted OCI registry, or use images that were built by importing a tarball > generated by e.g. mmdebstrap or sbuild-createchroot. I assume that for > Debian we would want to do the latter, at least initially, to avoid > being forced to either trust an external registry like hub.docker.com > or operate our own. Yes, please. FWIW, I want to switch ci.d.n from lxc to podman at some point as well. signature.asc Description: PGP signature
Re: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > ## Upgrading using dpkg directly? > > We already have quite a number of packages that use Conflicts to prevent > file loss in upgrades in a very similar way to #1058937 (Ben's > libnfsidmap1 bug) even in released versions of Debian. For instance, > dhcpcd-base's Replaces were upgraded to Conflicts, see #1053657. If you > employ dpkg, you can still experience the problem there. > > Is it ok to call upgrade scenarios failures that cannot be reproduced > using apt unsupported until we no longer deal with aliasing? I think so, yes. I don't think it's likely that there are people doing upgrades on running systems not using apt. If there are, they already need to deal with doing the dpkg calls in the right order anyway -- basically doing the apt dependency resolution by hand -- that this is just another corner case that they need to handle; there could be already Conflicts in there for other reasons than /usr-merge. signature.asc Description: PGP signature
Re: Bits from the Release Team: Cambridge sprint update
On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote: > Reproducibility migration policy > > > The folks from the Reproducibility Project have come a long way since they > started working on it 10 years ago, and we believe it's time for the next step > in Debian. Several weeks ago, we enabled a migration policy in our migration > software that checks for regression in reproducibility. At this moment, that > is > presented as just for info, but we intend to change that to delays in the not > so distant future. We eventually want all packages to be reproducible. To > stimulate maintainers to make their packages reproducible now, we'll soon > start > to apply a bounty for reproducible builds, like we've done with passing > autopkgtests for years. We'll reduce the bounty for successful autopkgtests at > that moment in time. Will reproducibility regressions block migration to testing? signature.asc Description: PGP signature
Re: autodep8 test for C/C++ header
On Tue, Aug 08, 2023 at 11:35:01AM +0300, Adrian Bunk wrote: > On Tue, Aug 08, 2023 at 06:46:38AM -, Sune Vuorela wrote: > > On 2023-08-07, Benjamin Drung wrote: > > > while working a whole week on fixing failing C/C++ header compilations > > > for armhf time_t [1], I noticed a common pattern: The library -dev > > > packages was missing one or more dependencies on another -dev package. > > > Over 200 -dev packages are affected. > > > > I don't think this is a important problem that some headers might have > > special conditions for use. I'd rather have our developers spend time > > fixing other issues than satisfying this script. > >... > > There are many actual bugs it would catch, that are currently only > caught later manually (sometimes through bug reports from users in > stable). > > There are special cases that might result in false positives. > > Numbers for bugs found and false positives should help determine whether > it should be opt-in or opt-out. While providing this for packages to use is a great idea, this will have to be opt-in. Imposing this on maintainers has a significant technical and social cost, specially in the case of packages where the defaults don't work correctly, that I am not willing to pay. With regards to supporting different corner cases, autodep8 has a standard interface for packages to provide configuration to the runners, and that is documented under "PACKAGE‐SPECIFIC CONFIGURATION" in the manpage. signature.asc Description: PGP signature
Re: debci / salsa ci: support for qemu runner
On Sat, Jul 29, 2023 at 06:02:26AM +0200, Helmut Grohne wrote: > Hi, > > On Tue, Jul 25, 2023 at 09:37:35PM +0200, Paul Gevers wrote: > > For ci.d.n, the issue is not money, but the required work to integrate it > > into the infrastructure. We need volunteers (or pay people to do the work), > > but unless they can and want to figure out everything from source [1], the > > bottleneck remains that the current volunteers would need to help those > > people understand the setup and guide them coming up with good solutions. > > I second this on another level. While the lxc backend is exercised very > often, the qemu backend evidently experiences rare use. The default > --ram-size is 1G and that happens to be too little for a number of > packages already. This soon will be configurable (#1037245). I expect > that there are more aspects where qemu and lxc differ in a way that > causes test failures as most of the existing tests only ever ran on lxc. > Some of these aspects will have to be fixed in tests, but others (like > the --ram-size) will need addressing in infrastructure. Please expect > more work in this area. FWIW, the debci codebase has gained support for specifying a backend on a per-package basis, so we will be able to switch packages one by one, and only the ones that really need (and/or benefit from) running on QEMU. signature.asc Description: PGP signature
Re: Bug#1031634: ITP: gum -- A tool for glamourous shell scripts
On Wed, Feb 22, 2023 at 03:33:15PM -0700, Sam Hartman wrote: > >> A tool for glamorous shell scripts. Leverage the power of > >> Bubbles (https://github.com/charmbracelet/bubbles) and Lip Gloss > >> (https://github.com/charmbracelet/lipgloss) in your scripts and > >> aliases without writing any Go code! . Tutorial . Gum > >> provides highly configurable, ready-to-use utilities to help you > >> write useful shell scripts and dotfiles aliases with just a few > >> lines of code. > > Antonio> This last paragraph above looks like a good enough package > Antonio> description. Save everything else for an upstream README > Antonio> installed on /usr/share/doc/gum/, or some other type of > Antonio> documentation. > > I disagree. > I should not have to chase down links to websites to understand a > description > Please include a phrase or two describing each of bubbles and gloss. I meant only the part that starts with "Gum provides highly-configurable ..." signature.asc Description: PGP signature
Re: Bug#1031634: ITP: gum -- A tool for glamourous shell scripts
On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote: > > On 2/21/23 15:03, Ryan Kavanagh wrote: > > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote: > > >Description : A tool for glamourous shell scripts > > > > > > A tool for glamorous shell scripts. Leverage the power of Bubbles and > > > Lip Gloss in your scripts and aliases without writing any Go code! > > This long description does not provide users with enough information to > > understand what the package does. What are "Bubbles" and "Lip Gloss" in > > a shell script? What is a "glamourous shell script"? > > > > It would be helpful if the package's long description satisfied §3.4.2 > > of the Debian Policy Manual [0]: > > > > The description field needs to make sense to anyone, even people who > > have no idea about any of the things the package deals with. [3] > > > > [...] > > > > [3] The blurb that comes with a program in its announcements and/or > > README files is rarely suitable for use in a description. It is > > usually aimed at people who are already in the community where the > > package is used. > > > > Best wishes, > > Ryan > > > > [0] > > https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description > > > > The package description will be this or close to it: That is just too long, please don't. > A tool for glamorous shell scripts. Leverage the power of Bubbles > (https://github.com/charmbracelet/bubbles) and Lip Gloss > (https://github.com/charmbracelet/lipgloss) in your scripts and aliases > without writing any Go code! > . > Tutorial > . > Gum provides highly configurable, ready-to-use utilities to help you write > useful shell scripts and dotfiles aliases with just a few lines of code. This last paragraph above looks like a good enough package description. Save everything else for an upstream README installed on /usr/share/doc/gum/, or some other type of documentation. https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions signature.asc Description: PGP signature
Re: Q: How about versions/features in bookworm?
On Sun, Nov 06, 2022 at 01:58:21PM +0900, Hideki Yamane wrote: > Q4: Will Ruby3.2 go into bookworm? No. signature.asc Description: PGP signature
Re: faker,ruby-faker: error when trying to install together
On Tue, Jul 05, 2022 at 06:44:15PM +0200, Timo Röhling wrote: > On Mon, 23 May 2022 01:58:56 +0200 Andreas Beckmann wrote: > > Package: faker,ruby-faker > > Severity: serious > > Tags: sid bookworm > > User: trei...@debian.org > > Usertags: edos-file-overwrite > > Control: found -1 0.9.3-0.1 > > Control: found -1 2.20.0-1 > > > > [...] > > Here is a list of files that are known to be shared by both packages > > (according to the Contents file for sid/amd64, which may be > > slightly out of sync): > > > > /usr/bin/faker > > > > This bug is assigned to both packages. If you, the maintainers of > > the two packages in question, have agreed on which of the packages will > > resolve the problem please reassign the bug to that package. > I'm posting to d-devel because I failed to make contact with the > Ruby Team directly: > > ruby-faker primarily ships a Ruby module while faker's sole purpose > is the faker executable, so I believe ruby-faker should yield. > There are two reverse dependencies: > > - ruby-devise-two-factor builds fine without /usr/bin/faker in > ruby-faker > > - ruby-omniauth-openid-connect FTBFS for unrelated reasons with and > wihout /usr/bin/faker > > If the Ruby Team agrees with my analysis, I'd appreciate it if > someone could upload a fixed version (I am not a team member). I just did that. Remember that you need to add Breaks:/Replaces: on your package for upgrades to work. signature.asc Description: PGP signature
Re: Reminder to participate in the Debian Developer's Survey
On Wed, May 04, 2022 at 01:49:01PM +0200, Mathias Behrle wrote: > * David Bremner: " Re: Reminder to participate in the Debian Developer's > Survey" (Wed, 04 May 2022 07:19:34 -0300): > > > Utkarsh Gupta writes: > > > > > A couple of days back we had invited all the Debian Developers to > > > participate in a survey[1] about the usage of money in Debian that > > > we discussed[2] a couple of months back on debian-project@l.d.o. > > > > > > This is just a follow-up reminder to the same. So far we've roughly > > > 140 DD participants who signed up and roughly 100 who have completed > > > the survey. We're hoping to reach 200-300 participants (close > > > to what we get for a GR), so please take the 15-25 minutes required > > > to fill out the survey. > > > > For the record, I gave up on the survey about half way through because > > it refused to let me advance without giving an answer to one of the > > questions. Consider this feedback on the survey design. > > Just another feedback: > > While looking in detail at the issues to vote them up an down I ran after > finishing that page into > > We are sorry but your session has expired. > > and all work done until there seems to be lost. It's not. The same happened to me as I left the survey open overnight to finish it the next day. Just open the original link you received by email and you can continue from where you stopped. signature.asc Description: PGP signature
Bug#1000154: ITP: ruby-rantly -- Ruby Imperative Random Data Generator and Quickcheck
Package: wnpp Severity: wishlist Owner: Antonio Terceiro X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ruby-rantly Version : 2.0.0 Upstream Author : Ana María Martínez Gómez, Howard Yeh, Anthony Bargnesi, Eric Bischoff * URL : https://github.com/rantly-rb/rantly * License : MIT (Expat) Programming Lang: Ruby Description : Ruby Imperative Random Data Generator and Quickcheck You can use Rantly to generate random test data, and use its Test::Unit extension for property-based testing. Rantly is basically a recursive descent interpreter, each of its method returns a random value of some type (string, integer, float, etc.). debian/control I'm packaging this as a build dependency for a new version of ruby-moneta. It seems like a pretty useful library. signature.asc Description: PGP signature
Bug#997663: general: bullseye, system freezes completely when firefox freezes
On Sun, Oct 24, 2021 at 12:25:23PM +0200, jacobkoch...@gmail.com wrote: > Hello Stephan, > > > Possibly relevant: > > - Are you using X11 or Wayland? > Wayland > > > - Do you have proprietary graphics drivers installed? > $ lspci -v | grep -A 10 VGA > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 > (rev 02) (prog-if 00 [VGA controller]) > Subsystem: CLEVO/KAPOK Computer HD Graphics 620 > [...] > Kernel driver in use: i915 > Kernel modules: i915 > It seems to be the open source driver 'i915' in the package: > 'xserver-xorg-video-intel'. > > > - Does the freeze occur without those? > Does not apply. No proprietary graphics drivers installed. > > > - Can you SSH into the machine after the screen/input freezes > Interesting idea. I will install 'openssh-server' and try this the next > time. > > > - Do you have other indications that the machine is still working? > I'm not sure. Maybe I can try the keyboard backlight function? > Or the Fn+Special-Function-Keys like: Volume or Display-Brightness ? Does this only happen when on battery power? There is https://gitlab.freedesktop.org/drm/intel/-/issues/3510 which looks similar, and happens to me. signature.asc Description: PGP signature
Bug#996087: ITP: typeshed -- collection of library stubs for Python, with static types
Package: wnpp Severity: wishlist Owner: Antonio Terceiro X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: typeshed Version : n/a Upstream Author : Several authors * URL : https://github.com/python/typeshed * License : Apache 2.0 Programming Lang: Python Description : collection of library stubs for Python, with static types Typeshed contains external type annotations for the Python standard library and Python builtins, as well as third party packages as contributed by people external to those projects. This data can e.g. be used for static analysis, type checking or type inference. typeshed has been extracted from mypy, and is necessary in order to have type checking work for libraries that still don't provide their own type anotations. Users are encouraged to install individual types-* wheels, but this package will provide all the typing information in a single binary package. Preliminary packaging available at https://salsa.debian.org/terceiro/typeshed and will be moved into the Python team soon™. signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
On Tue, Aug 17, 2021 at 06:51:35AM +, Paul Wise wrote: > On Mon, Aug 16, 2021 at 1:19 AM Paul Wise wrote: > > > 1. the ecosystems I'm talking about include cargo, npm, browser > > extensions, rubygems, pypi, CPAN etc. > > Examples of what current Debian practices are for these ecosystems: [...] > Probably most Ruby and Perl packages come from rubygems/CPAN. On Ruby it's very common to switch from rubygems to the upstream git repo due to missing test files etc, and that's usually non-problematic. IIRC we already discussed making that the default, it's just not implemented yet. signature.asc Description: PGP signature
want help with autopkgtest for your package?
Hi, The Debian CI team would like to encourage and help more maintainers to add autopkgtest to their packages. To that effect, we now have a repository called autopkgtest-help on salsa, where we will take help requests from maintainers working on autopkgtest for their packages: https://salsa.debian.org/ci-team/autopkgtest-help/ If you want help, please go ahead and create an issue in there. To quote the repository README: Valid requests: - _"I want to add autopkgtest to package X. X is a tool that [...] and it works by [...]. How should I approach testing it?"_ It's OK if you have no idea where to start. But at least try to describe your package, what it does and how it works so we can try to help you. - _"I started writing autopkgtest for X, here is my current work in progress [link]. But I encountered problem Y. How to I move forward?"_ If you already have an autopkgtest but is having trouble making it work as you think it should, you can also ask here. Invalid requests: - _"Please write autopkgtest for my package X for me"_. As with anything else in free software, please show appreciation for other people's time, and do your own research first. If you pose your question with enough details (see above) and make it interesting, it _may_ be that whoever answers will write at least a basic structure for you, but as the maintainer you are still the expert in the package and what tests are relevant. If you ask your question soon, you might get your answer recorded in video: we are going to have a DebConf21 talk next month, where we I and Paul Gevers (elbrus) will answer a few autopkgtest questions in video for posterity. Now, if you have experience enabling autopkgtest for you own packages, please consider watching that repository there to help us help our fellow maintainers. signature.asc Description: PGP signature
Re: investigating autopkgtest failures
On Sun, Feb 14, 2021 at 06:18:12PM -0500, Nick Black wrote: > I managed to push an update [0] that unexpectedly died in > autopkgtests [1]. I'm thankful that the tests brought this > problem to light, and grateful for the bug report--chalk it up > as a nice win for autopkgtests! I'm now pondering how best to > track this down, however, and at something of a loss. So far as > I'm aware, the only artifacts left over from the run are the > logs [2], unless one uses the AUTOPKGTEST_ARTIFACTS mechanism > [3] (which I intend to start using ASAP). > > Even with artifacts tweaked to grab a coredump or whatnot, > is there any way to test a modified package in the autopkgtest > environment without a full archive upload? This particular > program is pretty hardware-sensitive, and attempts to reproduce > the bug locally have not yet been fruitful (though given that > the autopkgtest failed on all architectures, it's likely less > hardware-dependent than I'm making out). > > Ideally, I'd be able to run the autopkgtests as part of Salsa > CI, which [4] suggests to be doable. Going even further, I'd be > able to ssh into a failed autopkgtest environment (for some > (short) time), and run some one-off experiments therein. Am I > missing an existing process through which this is possible? I can trivially reproduce your autopkgtest failure locally with: $ autopkgtest -apt-upgrade --no-built-binaries growlight -- \ lxc --sudo autopkgtest-unstable-amd64 If you add a --shell before the --, you will get a shell in the test sytem. To run this against a locally built package, just replace the package name with the path to your .changes file including source, or point to the .debs *and* your local source tree (e.g. /path/to/growlight.deb .). Now, your tests are full of Couldn't get blkid probe for /dev/dm-1 (No such file or directory), retrying... Couldn't get blkid probe for /dev/dm-2 (No such file or directory), retrying... Couldn't get blkid probe for /dev/dm-3 (No such file or directory), retrying... Couldn't get blkid probe for /dev/dm-0 (No such file or directory), retrying... which tells me they should probably not be being executed in a container. signature.asc Description: PGP signature
Re: RFC: raising ca-certificates package Priority to standard or important
On Thu, Jan 21, 2021 at 03:10:47PM +0100, Julien Cristau wrote: > And which of standard or important made most sense (AIUI, standard > means "installed by default in d-i" and important means "installed by > default in debootstrap"). wget is already Priority: standard and recommends ca-certificates, so it seems to me that making it standard would be a noop in practice for most of the systems installed by d-i. On the other hand, all cases that I remember seeing a problem caused by missing ca-certificates was in systems not installed by d-i, such as containers, vm images, etc. Based on that, I would make it important. signature.asc Description: PGP signature
Re: About lintian
On Tue, Jan 19, 2021 at 12:27:31PM +0100, Raphael Hertzog wrote: > Hi, > > On Mon, 18 Jan 2021, Antonio Terceiro wrote: > > FWIW, The ci.debian.net infrastructure is mostly independent from > > autopkgtest, so we could have different types of jobs there. This could > > be used for lintian, but also for on-demand rebuilds, and other types of > > checks that needs to be done to packages in the archive. the debci > > codebase has seen a lot of work to properly handle stuff like this in > > the last 6 years, and it would be a win if we can reuse that for other > > use cases, instead of someone having to start from scratch having to > > learn again everything that I did in the last 6 years working on ci.d.n. > > Can you expand on the kind of features that ci.debian.net offers and what > kind of mistakes we would likely avoid by reusing it? To name a few: - distributed processing - data retention policies - web interface - monitoring > From my (relatively remote) point of view, ci.debian.net seems really > very basic in terms of features related to scheduling of jobs. > > From my own usage in Kali (autopkgtest.kali.org), I noticed you can't > even request to test a specific version of a package... you get whatever > version is available in the specific mirror that you are using for your > test, even if it's not (yet) in sync with the one used by the code that > requested that job. autopkgtest does not support that, so debci doesn't offer it as well. > There's also no possibility to have differentiated workers (qemu vs > lxc-based) and have the jobs dispatched to appropriate workers. > > Scheduling features might not be important for lintian processing but I > believe it's a must have if we want to consolidate more jobs in a single > place. I didn't say it was ready for it now, but that it could be done. My hope is that this, and other use cases, could be enabled by collaborating on existing infrastructure, instead of creating yet another one. signature.asc Description: PGP signature
Re: About lintian
On Mon, Jan 18, 2021 at 02:00:22PM +0100, Pierre-Elliott Bécue wrote: > Le lundi 18 janvier 2021 à 11:31:35+0100, Lucas Nussbaum a écrit : > > Hi, > > > > On 17/01/21 at 22:00 +0900, Norbert Preining wrote: > > > On the infrastructure side, you mentioned on #debian-qa that in your > > > opinion, lintian is best run in a CI pipeline instead of on the > > > lintian.d.o service. While this is certainly true, do you plan to keep > > > the functionality on your rework of lintian.d.o? > > > > > > As part of this rework and the ongoing development, you said you have > > > plans > > > to set up a test version of the Lintian web application on non-Debian > > > infrastructure. How is that going, Felix? Please if you need help or > > > support, > > > don't hesitate to reach out. > > > > I agree that a service that provides an overview of the status regarding > > lintian for the whole archive would be useful (for example, to identify > > packages that need some area of work inside a team). > > > > If there's a lack of interest/motivation to redesign lintian.d.o as a > > standalone service, maybe a simpler architecture to explore would be to > > build it on top of UDD (with lintian runners feeding a table in UDD > > directly). That would make it possible to simplify most of the web stuff > > (and of course would still allow exporting to other services that need > > the data). I would be quite motivated to work on that. > > Hey all, > > Last time me and Felix discussed about lintian, his motivation to have a > fresh and new lintian.d.o seemed, to me, to be high, and I recall he was > mostly dealing with questions about how to do it, in particular about > infrastructure. As I said on that time, I'd be glad to provide help and > support should Felix feel the need for some. I'm quite not the best > developer, but I think I could be useful nevertheless! > > That very topic about an archive-wide Lintian ran on already uploaded > packages did not occur, though, and I'd be really interested in helping > keeping this feature around, if such help is needed! FWIW, The ci.debian.net infrastructure is mostly independent from autopkgtest, so we could have different types of jobs there. This could be used for lintian, but also for on-demand rebuilds, and other types of checks that needs to be done to packages in the archive. the debci codebase has seen a lot of work to properly handle stuff like this in the last 6 years, and it would be a win if we can reuse that for other use cases, instead of someone having to start from scratch having to learn again everything that I did in the last 6 years working on ci.d.n. I don't have a lot of free time to do this myself, but would be willing to guide someone who wants to work on it, as a good part of the time I currenly spend on Debian is already on ci.d.n anyway. signature.asc Description: PGP signature
Re: Split Packages files based on new section "buildlibs"
On Tue, Nov 10, 2020 at 06:52:14PM -0500, Calum McConnell wrote: > On Tue, 2020-11-10 at 10:07 +, Simon McVittie wrote: > > On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote: > > > I'm confused. We are packaging libraries of language X but then those > > > packages > > > will not be used by people who write software for language X on > > > Debian? > > > Intuitively, should I ever start with Rust, I would've thought that I > > > had to > > > install librust-clap-dev if I want to write code using "clap". What > > > else would > > > I install? > > > > The Rust community's expectation seems to be that you would install > > cargo, > > and use that to download and build the clap package directly from > > upstream, > > without apt/dpkg being involved at all. > > I don't know that that means we should abandon efforts to integrate the > debian packages into usable code. > > Rubygems has a similar expectation: however, there is a package (rubygems- > integration) that makes it work anyways. With Ruby, the only (user- > obvious) difference between installing via gem and via deb is the package > version. FWIW, that is not accurate. There is nothing in Rubygems that prevents it from just working. That is orthogonal to what random people who happen to use Ruby think of Debian providing Ruby packages. What happened was that Rubygems was created *after* we already had quite some Ruby code in Debian that was installed differently than what Rubygems expected, and rubygems-integration was created to bridge the two ways of installing code. The Ruby team is slowly migrating the old-style packages to the Rubygems layout, and at some point most, if not all, of rubygems-integration will be obsolete. > What about Rust makes that impossible? In the Rust world there is no such thing as installing a library globably. A crate that provides a library can only be used to build other stuff, and is never made available globally. "cargo install" only applies to creates that provide binaries: https://doc.rust-lang.org/cargo/commands/cargo-install.html signature.asc Description: PGP signature
Bug#971814: ITP: catatonit -- init process for containers
Package: wnpp Severity: wishlist Owner: Antonio Terceiro X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: catatonit Version : 0.1.5 Upstream Author : Aleksa Sarai * URL : https://github.com/openSUSE/catatonit * License : GPL-3+ Programming Lang: C Description : init process for containers catatonic is a very simple init process for application containers. Its purpose is to support only the usage by container managers such as docker and podman, which is /dev/init -- . No other use cases will be supported. It is used by podman as container init when given the --init flag. signature.asc Description: PGP signature
Re: Mass bugs filing: autopkgtest should be marked superficial (new list)
On Sun, Sep 20, 2020 at 12:31:13AM +0100, Sudip Mukherjee wrote: > HI Mattia, > > On Sat, Sep 19, 2020 at 8:58 PM Mattia Rizzolo wrote: > > > > On Sat, Sep 19, 2020 at 08:39:44PM +0100, Sudip Mukherjee wrote: > > > After discussing with few people, I now intend to file them with > > > "severity: important" and I will also reduce the severity of the > > > previously open similar bugs to 'important'. > > > > That's good. > > > > But please also share your proposed text with this list (as the MBF > > rules asks for). Your past filings where IMHO written with a tone that > > could be improved. Also I would like to make sure that you include > > stuff like your plans with the severity, references to the release team > > decisions, etc. > > Apologies for the tone. It was my first MBF and I was struggling to > make the text more generalised so that it will work for all the > packages in the list. > For this new list of packages, how is the following text: > > ** > > Subject: : autopkgtest must be marked superficial > severity: important > > Dear maintainer, > > It has been noticed that the autpkgtest in is running a > trivial command. > - > > Those kind of tests are considered to not provide significant coverage > for a package as a whole, and as such the keyword "Restrictions: > superficial" has been defined [1]. Packages with all tests marked as > 'superficial' are not considered for the reduced migration age from > unstable to testing and also they will not be allowed to migrate in a > later stage of the freeze [2]. > > The Release Team has listed this issue in the list of Release Critical > Issues for bullseye [3] and has mentioned that the test must be marked > superficial if it is not testing one of its own installed binary > packages in some way. > > > [1]. > https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst > [2]. https://release.debian.org/bullseye/freeze_policy.html > [3]. https://release.debian.org/bullseye/rc_policy.txt Maybe you could include something like this (the wording can be improved): Note, however, that such superficial tests are still somewhat useful, as they will be considered, for example, to block dependencies from breaking your package. In other words, please do not react to this bug report by dropping tests from your package completely. More extensive testing is of course better, but even superficial tests are better for the overal quality of Debian than no tests at all. We want to avoid maintainers panicking and just dropping the tests as a response do this MBF. signature.asc Description: PGP signature
Re: Problems with the CI infrastructure?
On Fri, Sep 18, 2020 at 09:43:32AM +0200, Gard Spreemann wrote: > Hi, > > I must admit I don't know much about the CI/autopkgtest infrastructure, > but I've noticed over summer that the frequency at which my packages are > being tested has decreased a lot, especially when it comes to ordinary > tests in unstable (as opposed to tests that pick a few packages from > experimental). > > Has there been some change to the CI infrastructure? Is it experiencing > problems? Am I just missing something? At the moment we are not running the "unstable only" tests automatically. There is work that needs to be done to improve the efficiency of the unstable only scheduling, to avoid overwhelming the system. You can still trigger them using the self-service interface though. For now the only tests that are being triggered automatically are for unstable->testing migration, and the experimental->unstable tests. The process that does that will also trigger pure unstable tests, but not as often as we had before. signature.asc Description: PGP signature
Re: Mass bugs filing: autopkgtest should be marked superficial
On Sun, Sep 06, 2020 at 12:31:22AM +0100, Sudip Mukherjee wrote: > Hi Paul, > > On Sat, Sep 5, 2020 at 1:56 AM Paul Wise wrote: > > > > On Fri, Sep 4, 2020 at 6:53 PM Sudip Mukherjee wrote: > > > > > If the test done in the autopkgtest does not provide significant test > > > coverage then it should be marked with "Restrictions: superficial". > > ... > > > I am still trying to figure out a generalized method to find them but > > > an initial script has found 83 packages. Attached is the dd-list. > > > > This sort of thing seems like something that will be an ongoing > > problem so a more efficient way to solve it would be a lintian > > warning, which should hopefully help prevent new occurrences. OTOH it > > would be pretty hard to automatically check for these without a robust > > shell parser. Perhaps morbig from Project CoLiS could be used for the > > shell parsing and then a script could process the morbig output. > > ShellCheck might be another option but it doesn't yet output parse > > trees. > > We were hoping that this check can be added in lintian, but looking at > #932862 it seems you have already requested that. :) > I will have a look at morbig and see if I can use that in my script. > Thanks for the idea. FWIW I don't think that opening bugs about the packages we already know are using silly tests without "Restrictions: superficial" needs to wait for that. Thanks for your work on this. signature.asc Description: PGP signature
Re: The "which -s" flag
On Wed, Aug 19, 2020 at 01:45:05PM +, Clint Adams wrote: > On Tue, Aug 18, 2020 at 10:55:41AM -0400, Boyuan Yang wrote: > > In theory any Debian Developers may merge, but the debianutils package is > > maintained by clint@ and srivasta@ so they are responsible for this > > package. I > > am adding them to the email receiver list explicitly. > > Now that `command -v` is mandated by POSIX, it would make more > sense to transition `which` out of debianutils. debianutils is essential/required, and there is an infinite amount of shell scripts and even non-shell programs that use the `which` binary without needing a dependency on anything. Dropping it without breaking the entire world is going to be pretty difficult to achieve, unless it moves to another essential/required package. That said, it could very well be reimplemented as a very small wrapper around command -v. signature.asc Description: PGP signature
Re: libraries depending on interpreters
On Sun, Nov 17, 2019 at 04:39:46PM +0200, Niko Tyni wrote: > - for Ruby I only found guidance about application dependencies [2] > but not module dependencies. The standard library seems to come > with the interpreter here, so that's not a reason to depend on the > interpreter package. Still, almost all ruby-* packages do depend on > ruby | ruby-interpreter. FWIW we considered dropping this dependency, and it wasn't done so far mostly due to inertia. signature.asc Description: PGP signature
Re: Discussion tooling (was: Bits from the DPL (August 2019))
On Wed, Oct 02, 2019 at 01:37:58PM +0100, Samuel Henrique wrote: > On Wed, 2 Oct 2019 at 10:48, Mathias Behrle wrote: > > > ...BTW no discussion tool can help in automating > > separate discussion threads when the topic changes. > > > > They can, I think reddit and hackernews are good at this. > That's the "tree-like" structure that I mentioned in my email. Note that email already has a "tree-like" structure, since forever. You just don't see it if you (ironically) use web application email clients like gmail that decided to not show it. Most console/desktop clients that I ever saw do support it. signature.asc Description: PGP signature
Re: Consensus Call: Git Packaging Round 1
On Tue, Aug 27, 2019 at 02:52:01PM -0400, Sam Hartman wrote: > > "Alf" == Alf Gaida writes: > > > Alf> There are things i really like about PRs or MRs - they can be > Alf> reviewed, commented, changed without problems and fast. > > And as Sean pointed out, it's hard to understand the history of the > changes and comments after they hppened. What happens when I'm trying > to review a MR three years later and the MR was rebased 4 times during > the lifetime of the MR prior to merge. FWIW, nowadays gitlab keeps track of every push, including rebases, to a single merge request. It even adds a "compare to previous version", where you can see the diff between the latest, maybe rebased, version of the branch, and the previous one. It _used_ to be the case that rebasing and force-pushing to the branch referenced by a merge request would make you lose the history, but that hasn't been true for a while. signature.asc Description: PGP signature
Re: git & Debian packaging sprint report
Hi, Thanks for the report. On Wed, Jul 10, 2019 at 09:10:40AM +0100, Sean Whitton wrote: > Hello, > > Over the weekend, Ian Jackson and I met in Cambridge, U.K. to work on > the design and implementation of tools and processes relating to git & > Debian packaging. > > Main achievement > > > We designed and implemented a system to make it possible for DDs to > upload new versions of packages by simply pushing a specially formatted > git tag to salsa. > > Please see this blog post to learn about how it works: > https://spwhitton.name/blog/entry/tag2upload/ > > While the cloud service part of this system has not yet been deployed, > and so you can't just tag to upload yet, the blog post explains how you > can run the cloud service in an ad-hoc mode on your laptop, and thereby > get a feel for how it works. > > You can also read git-debpush(1) in sid.[1] If the uploads will be done by a service, this means that all of them will be signed by a single key and not by the DD key. Is ftp-master ok with that? signature.asc Description: PGP signature
Re: wanted: recommendation for webhook queueing library/thing
On Wed, Jul 10, 2019 at 05:05:53PM -0400, Sam Hartman wrote: > I also use systemd.path units for this. > Since it was Ian asking I didn't really feel that was worth suggesting > though. yes, I also though about that but decided to cite prior art anyway. one can always use inotify to achieve the same effect. signature.asc Description: PGP signature
Re: wanted: recommendation for webhook queueing library/thing
On Wed, Jul 10, 2019 at 04:09:11PM +0100, Ian Jackson wrote:
> Sean Whitton writes ("git & Debian packaging sprint report"):
> > Main achievement
> >
> >
> > We designed and implemented a system to make it possible for DDs to
> > upload new versions of packages by simply pushing a specially formatted
> > git tag to salsa.
> >
> > Please see this blog post to learn about how it works:
> > https://spwhitton.name/blog/entry/tag2upload/
> >
> > While the cloud service part of this system has not yet been deployed,
> > and so you can't just tag to upload yet, the blog post explains how you
> > can run the cloud service in an ad-hoc mode on your laptop, and thereby
> > get a feel for how it works.
> >
> > You can also read git-debpush(1) in sid.[1]
>
> The one technical piece missing for deployment is webhook queue /
> dispatcher. Can someone familiar with this space recommend one ?
>
> In more detail, here is what I think the problem is:
>
> * The webhook client expects a quick response. But the bot's
>processing for a tag addressed to the bot takes some time (because
>it needs to fetch a fair amount of data and build a source
>package). So webhook calls must be queued.
>
> * Sometimes it will be necessary to retry a failed bot invocation.
>(The bot already knows whether a particular invocation should be
>retried, and can feed this back to the queue.) The retry interval
>and number of retries must be limited.
>
> * The bot expects to be forked/exec'd.
>
> * Significant protection against DoS is not needed because the
>web hook receiver's webserver will have a firewall protecting it
>from anything other than salsa.
>
> * The webserver and web hook receiver/queue (including the JSON
>parser which will be needed) must be high quality software, because
>we really want to avoid any vulnerabilities.
>
> * I can easily change the bot's fork/exec API to make it conveniently
>fit into whatever queue system.
>
> If necessary I can write my own but it seems like this is a problem
> that there should already be a good solution to.
Enrico has been producing some content that is related:
https://www.enricozini.org/blog/2018/debian/automatic-deploy-from-gitlab-salsa-ci/
https://debconf18.debconf.org/talks/71-autodeploy-from-salsa/
It's based on systemd .path units. the advantage is that you don't need
a new component, you only put the config in place and systemd takes care
of it for you.
another option is rabbitmq; that's what debci uses. and it has clients
for several languages. one advantage is that you can have multiple
worker processes consuming from the queue in parallel, but OTOH you have
do manage those extra daemons, care about not exposing it to the
internet, etc.
signature.asc
Description: PGP signature
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote:
> Hi,
>
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
>
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
As a data point, having "stable" and "testing" stay around is very
useful for CI purposes. For example on ci.debian.net all our setup uses
"stable" and "testing" instead of the release codenames, and it's useful
to have a system that does not need manual intervention when the meaning
of "stable" and "testing" changes.
With that said, I think that for regular user systems, having suites
called debian11 and the like is a great improvement.
signature.asc
Description: PGP signature
Re: Support status for isolation-machine feature from Debian Infra?
On Fri, Mar 08, 2019 at 11:08:54AM +, Mo Zhou wrote: > Hi folks, > > As we know the Debian CI Infrastructure, which runs autopkgtest upon > relevant package updates to help us improve distribution quality. > However, it still doesn't support the isolation-machine feature, which > associates to tests that require interaction with the kernel, such as > kernel module tests. > > zfs-linux has one of such tests. The test loads the zfs kernel module > and trys to do smoke tests such as creating zpools: > https://salsa.debian.org/zfsonlinux-team/zfs/blob/master/debian/tests/control#L1-2 > > For quite a long time debian CI keeps skipping this test, e.g. > https://ci.debian.net/data/autopkgtest/testing/amd64/z/zfs-linux/2068033/log.gz > > | kernel-smoke-testSKIP Test requires machine-level isolation but testbed > does not provide that > | dkms-zfs-testPASS > > I have two questions given the background: > > (1) What is the support status for "isolation-machine" feature? It is supported in debci, but not yet on ci.debian.net because the workers there are VMs that don't support nested virtualization. There is no major blocker, I just need to find some time to do the work. > (2) Is it a good idea to write a test script, that manually sets up > a qemu VM then tests the module[1]? (Such that we can get rid of the > isolation-machine restriction, and make Debian CI test the ZFS > kernel module) > > Or any better idea? > > [1] thanks to @zhsj for a hint: This can be implemented by setting > up a qemu VM with exported ssh port. No, it's not a good idea. In the long run you will be reinventing autopkgtest. Also, since the current workers don't supported nested virtualization, your qemu VM will be very slow. signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Wed, Dec 26, 2018 at 01:04:44PM +0530, Pirate Praveen wrote: > If it has to be completely separate from -backports, it means some packages > will need to be maintained twice, even when they meet the criteria for > backports fully, just because a package in volatile declare a dependency on > them. There is nothing that stops you, or whoever wants to maintain this newn repository from doing it in a way that 1) reuses what's already in backports, even automatically and 2) adds the bits that are not deemed appropriate for backports. signature.asc Description: PGP signature
Re: Would be possible to have a ".treeinfo" file added to the installers' page?
On Fri, Dec 07, 2018 at 08:10:27AM -0200, Antonio Terceiro wrote: > On Fri, Dec 07, 2018 at 10:45:31AM +0100, Fabiano Fidêncio wrote: > > Howdy! > > > > Firstly, sorry if I'm sending the message to the wrong mailing list. > > If that's the case, please, point me to the right one. > > > > Although the subject says it all, let me explain the background of the > > change so you all can get the idea of why it'd help a few projects > > and/or even come up with a better solution than adding a ".treeinfo" > > file. > > > > I'm one of the maintainers of libosinfo[0], which is a project that, > > basically, keeps info about OSes as such: the hardware they support, > > the location for downloading ISOs, the location of online installation > > trees, the minimum/recommended/maximum resources for an OS, scripts > > for automating "JEOS"/"Desktop" installations and so on. > > > > One of the APIs provided by libosinfo is to guess an OS from its > > online installation tree and it's easily done by a treeinfo file like > > the ones that can seen here[1], here[2] and here[3]. For the Debian > > case however, as the ".treeinfo" file is not used, we're struggling > > about having a reliable way to guess the OS from its tree because we > > didn't find a specific file that we could try to inspect in order to > > decide whether the installation tree is for debian7, debian8, debian9, > > debian-testing ... > > Does this work for you? Just realized you meant the _installer_ files, so nevermind. signature.asc Description: PGP signature
Re: Would be possible to have a ".treeinfo" file added to the installers' page?
On Fri, Dec 07, 2018 at 10:45:31AM +0100, Fabiano Fidêncio wrote: > Howdy! > > Firstly, sorry if I'm sending the message to the wrong mailing list. > If that's the case, please, point me to the right one. > > Although the subject says it all, let me explain the background of the > change so you all can get the idea of why it'd help a few projects > and/or even come up with a better solution than adding a ".treeinfo" > file. > > I'm one of the maintainers of libosinfo[0], which is a project that, > basically, keeps info about OSes as such: the hardware they support, > the location for downloading ISOs, the location of online installation > trees, the minimum/recommended/maximum resources for an OS, scripts > for automating "JEOS"/"Desktop" installations and so on. > > One of the APIs provided by libosinfo is to guess an OS from its > online installation tree and it's easily done by a treeinfo file like > the ones that can seen here[1], here[2] and here[3]. For the Debian > case however, as the ".treeinfo" file is not used, we're struggling > about having a reliable way to guess the OS from its tree because we > didn't find a specific file that we could try to inspect in order to > decide whether the installation tree is for debian7, debian8, debian9, > debian-testing ... Does this work for you? on Debian 9: $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/"; and on Debian unstable: $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux buster/sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/"; signature.asc Description: PGP signature
Re: Tainted builds (was Re: usrmerge -- plan B?)
On Wed, Nov 28, 2018 at 07:02:07PM +0100, Bastian Blank wrote: > On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > > Would you be willing to also implement > > Tainted-By: not-built-in-a-chroot > > ? > > What do you want to do with that? Even our own stuff not always uses > chroot, why should it? The idea here is to record facts about the system where a package was built. Building in a merged-/usr system does not necessarily produce a broken package. Not building in a chroot is also not necessarily a problem, but still, we want to know that. Now, as Andrey points out, nowdays a chroot is not the only type of minimal system where one can build packages, so maybe a more sophisticated check would be required. signature.asc Description: PGP signature
Re: Tainted builds (was Re: usrmerge -- plan B?)
On Wed, Nov 28, 2018 at 02:57:52PM +0100, Guillem Jover wrote: > Hi! > > On Wed, 2018-11-28 at 07:52:08 +0500, Alexander E. Patrakov wrote: > > Well, the buildd configuration change has been reverted. What worries me now > > is that there is a risk not yet mitigated, coming from personal systems of > > Debian developers, and we should also check porter boxes. > > > > As long as there is one Debian Developer (or any other person who has the > > right to upload binary packages) who has a merged /usr on his system used > > for building packages, there is a risk of reintroducing the bug through his > > package. Maybe we should somehow, in the short term, modify dpkg to add > > something like "Tainted-By: usr-merge" control field to all binary packages > > produced, if a package is built on a system with merged /usr (detected via > > /bin being a symlink). And a corresponding automatic check that would > > auto-reject binary packages with any Tainted-By control field from being > > uploaded to the Debian archive. > > This is actually a great idea! I went ahead and implemented this, see > attached tentative patch which I'm planning on including in dpkg 1.19.3. Would you be willing to also implement Tainted-By: not-built-in-a-chroot ? (ischroot(1) is from debianutils which is Essential). a few nits in the manpage: > diff --git i/man/deb-buildinfo.man w/man/deb-buildinfo.man > index 5013aa047..8aa333965 100644 > --- i/man/deb-buildinfo.man > +++ w/man/deb-buildinfo.man > @@ -149,6 +149,19 @@ via some pattern match to avoid leaking possibly > sensitive information. > On Debian and derivatives only build paths starting with \fI/build/\fP > will emit this field. > .TP > +.BR Build\-Tainted\-By: " \fItaint-reasons...\fP" > +The list of reasons in the form of string tags (alphanumeric and dash), > +that can taint the current build. Other fields explicitly mention being space-separated, you might want to do the same here. > +.RS > +.TP > +.B merged-usr-via-symlinks > +The system has a merged /usr via symlinks. > +This will confuse \fBdpkg\-query\fP as it messes with the \fBdpkg\fP > +understanding of the filesystem it manages. > +It can also produce packages with hardcoded paths that will be incompatible > +with non-usr-merged filesystems. I would say here: For packages that hardcode paths to specific binaries at build time, it can also produce packages that are incompatible with non-usr-merged systems. signature.asc Description: PGP signature
Re: Confusing our users - who is supporting LTS?
On Fri, Nov 02, 2018 at 08:58:47AM +, Jonathan Dowland wrote: > On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote: > > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo > > wrote: > > > I meant that we would say that stable is supported by the security team. > > > And instead of saying that Jessie was supported by the LTS team, we > > > would say supported by Freexian. > > > > I would object to that, on the grounds that even though Freexian is > > currently the only company paying people to do LTS support, we should > > not encourage the idea that they have a monopoly on doing that. > > In my view, that is a situation we could address at the time that we had > more than one company doing LTS work. Until that time, I don't think > it's a problem. It's consistent with our listing of consultants, and > addresses the problems of the official-ness-or-not of LTS that are why > this thread started. > > > If some other company decides that they are not happy with Freexian, > > then they are currently able to just start their own competing project > > and do things differently. This is a good thing. > > They would still be able to do so even if we were listing Freexian as > being the only entity supporting LTS (which is a statement of current > fact after all): I don't think the hypothetical competing company would > be too bashful to ask us to update the website. And we could pre-empt > the situation by making a clear statement as to the project's position > on listing Freexian (essentially codifying what I'm writing here, > somewhere) It was said in this same thread that Freexian is already not the only company paying people to do LTS work. See signature.asc Description: PGP signature
Re: Planning the removal of c_rehash | mass bug filling
On Fri, Apr 06, 2018 at 12:22:12AM +0200, Sebastian Andrzej Siewior wrote: > Hi, > > the openssl package provides the c_rehash script which creates the links > from .Y to the actual certificate in /etc/ssl/certs/. During the > transition from 0.9.8 to 1.0.0 the hash (for the X part) changed from > md5 to sha1. Since that transition in Debian the c_rehash script > provides both symlinks: the old hash (md5) and the new (sha1) one. > > The c_rehash script is considered by upstream as a fallback script and > will disappear at some point. The recommended way is to use the "openssl > rehash" command instead which appeared in 1.1.0. This command creates > half that many symlinks (one per certificate instead of two) because it > uses only the sha1 hash. There is also the -compat option which creates > both symlinks (and behaves like c_rehash currently does) but as > explained above it should not be required to use it. > > I am planning to fill bugs against 23 packages which use "c_rehash" to > use "openssl rehash" instead. Here is the dd-list of packages I > identified: [...] > Antonio Terceiro >ruby-openssl (U) this is a false positive. the only ocurrance of "c_rehash" is in example code and is a reference to a c_rehash.rb file in the same directory of examples. signature.asc Description: PGP signature
Re: Extended Long Term Support for Wheezy
On Tue, Feb 20, 2018 at 11:48:43PM +0100, Joerg Jaspert wrote: > On 14954 March 1977, Raphael Hertzog wrote: > > > - for ftpmasters, can we keep wheezy/updates on security.debian.org for > > one year more? (it might be possible to archive wheezy and drop it from > > the main mirror, that would be a clear sign to everybody that something > > important changed, and we could reconfigure the buildd to use another > > repository) > > No. > > > - are there other problems related to this extended LTS that need to be > > discussed? > > If this would be "just" extending the current LTS ways for more time, > then it would be OKish to stay on donated, voluntarily managed, > infrastructure. After all it helps all users of wheezy with updates, > nominally over all of wheezy. > > But the proposal is effectively just for a benefit of a few paying > customers, with a very selected set of packages and architectures, all > the rest lost out. Thats not ok to ask volunteers to support, nor > is it ok to use projects infrastructure for. The companies that want it, > should run it. Maybe the proposal needs to be clarified, but my understanding was that some companies are willing to fund a longer LTS for a restricted set of packages and architectures¹, but that the product of that would continue to be available for anyone. I assume that Raphael knows that it wouldn't even make sense to ask if that could be done in Debian infrastructure if it wasn't available to all users. ¹ LTS is _already_ for a restricted set of packages and architectures, so this is just extra constraining to allow for longer support signature.asc Description: PGP signature
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
On Mon, Jan 22, 2018 at 07:38:41PM +0530, Kumar Appaiah wrote: > Dear Debian Developers, > > I am part of a team working on getting Debian on low cost laptops (see > http://www.rdp.in for details) so that they can be sold with Debian > preinstalled. While vanilla Debian largely works, unfortunately, > making Bluetooth and sound work require kernel rebuilding. The patches > and config changes are not likely to be upstreamed any time soon, so > we would have to ship the laptop with a patched (non-Debian > kernel). Our team is, thus, taking up the responsibility of ensuring > that up-to-date kernel (with security fixes) are made available to the > users of our laptop. The patches and configs are adapted from here: > https://github.com/sundarnagarajan/kernel_build Are the the patches you need are really just those in patches/? If yes, they are small enough that if I were in your place I would talk to the Debian kernel team to see if they can be included in the official Debian kernel. Also, the patches being that small, what's stopping them from being upstreamed? signature.asc Description: PGP signature
Re: salsa.debian.org (git.debian.org replacement) going into beta
On Fri, Dec 29, 2017 at 04:11:29PM +0100, Thomas Goirand wrote: > On 12/28/2017 02:33 AM, Jeremy Bicha wrote: > > On Wed, Dec 27, 2017 at 7:07 PM, Manuel A. Fernandez Montecelo > > wrote: > >> If the idea is *not* to move those to @lists.d.o, I cannot see what we > >> should be using instead. > >> > >> Any recommendation? > > > > Someone on your team should create a Tracker Team. Add the packages > > your team maintains. > > > > https://tracker.debian.org/teams/ > > > > Then anyone can simply join that tracker team to easily get > > notifications about bugs, commits, uploads, etc. Visit > > https://tracker.debian.org/accounts/subscriptions/ and customize the > > keywords to get the particular emails you want for particular packages > > or teams. > > > > Thanks, > > Jeremy Bicha > > Nice idea, but it doesn't scale. Am I suppose to add all of the > (currently) 406 OpenStack maintained packages one by one, by hand? And > then upload 406 times just to change the maintainer field? Gregor just > pointed out the 3500 packages of the perl team. There will be others > (think: javascript/nodejs, python, etc.). Even worse: some packages > *will* be forgotten, and there *will* be bug reports that will go to > nowhere because the fields were not addressed. > > I don't understand that there's no consensus we'd be collectively > wasting too much time doing this type of change, when it could simply be > addressed by keeping the current lists. This is a major disruption of > services that we're talking about here. This manual adding is only needed if you don't use a single email address as maintainer ... if you do have a single maintainer address for all packages, you just provide it and the package tracker _will_ group all the packages automatically. signature.asc Description: PGP signature
Re: Debian Stretch new user report (vs Linux Mint)
On Fri, Dec 01, 2017 at 01:22:03PM +0100, Michael Biebl wrote: > Am 01.12.2017 um 13:15 schrieb Arturo Borrero Gonzalez: > > On 1 December 2017 at 12:23, Michael Biebl wrote: > >> Am 01.12.2017 um 07:34 schrieb Paul Wise: > >>> On Fri, Dec 1, 2017 at 1:36 AM, Arturo Borrero Gonzalez wrote: > > * no support for RW on NTFS drives, only RO. This wasn't fixed even by > installing ntfs-3g [0]. > I didn't have the time to investigate the NTFS issue myself, sorry :-( > >>> > >>> Sounds like you need to get him to file a bug against ntfs-3g and > >>> against whichever meta-package or other component should be installing > >>> ntfs-3g. For the latter, perhaps gnome-software/PackageKit needs some > >>> sort of filesystem detector that installs relevant packages. I was in > >>> the same position recently with the Apple HFS+ filesystem. > >>> > >> > >> udisks2 already recommends ntfs-3g. Most major desktops should use and > >> install udisks2. Which desktop environment did your user install and did > >> he maybe choose to not install recommends? > >> > >> > > > > I don't really know, I would say gnome. > > A default gnome desktop installation will pull in ntfs-3g (you can try > by running apt install task-gnome-desktop in a chroot). > If the user had to manually install ntfs-3g, something went wrong. He mentioned that wifi needed a non-free firmware package after the install. I would say the installation was done offline, in which case Recommends: will be happily skipped if the package is not available in the install media. Now, I have no idea whether ntfs-3g is on CD/DVD 1 or not. It's been a while since I installed a system with somethign other than a netinstall media. signature.asc Description: PGP signature
Re: Switching to sysvinit-core fails miserably in buster/sid
Hi,
On Fri, Oct 27, 2017 at 12:04:37AM +0200, Adam Borowski wrote:
> Indeed, sysvinit is somewhat undermaintained, but as a mature piece of
> software it doesn't require much fixing. For example: if you lxc-create -t
> debian -- -r sid, the container created (as of yesterday) doesn't even boot
> unless you switch to sysvinit ("Can't mount API filesystems.").
Can you clarify the environment where you are experiencing this? I
tested creating and booting a sid container a few minutes ago, and it
just worked.
signature.asc
Description: PGP signature
Re: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing
On Wed, Oct 04, 2017 at 05:05:03PM +0530, Pirate Praveen wrote: > Because the shown folly is only in theory and it is never in practice. > As these packages are always uploaded as binary included and never built > on the buildd (as buildds already prohibit network access during build). > If I include pre-built files, nothing changes in practice and only in > perception, hence I'm not convinced. We have the requirement that every package can be built from source. Even if you upload your locally-built binaries, any user trying to build the package locally will be subjected to the issues that pulling random stuff from internet (and running code from it) entails. signature.asc Description: PGP signature
Re: s/python3-sphinx-intl/sphinx-intl
On Wed, Sep 13, 2017 at 12:26:34PM +0100, Ghislain Vaillant wrote: > On 13/09/17 12:21, Ondrej Novy wrote: > > if sphinx-intl is primary application (cli tool, etc.), than binary pkg > > sphinx-intl is better. If it's library/module, than python3-sphinx-intl > > is better. > > Based on the description of the project [1], it looks like it is the former. > > [1] https://pypi.python.org/pypi/sphinx-intl however sphinx itself is python*-sphinx, so maybe having those be consistent with each other is a good idea. signature.asc Description: PGP signature
Re: Let's enable AppArmor by default (why not?)
On Sat, Aug 05, 2017 at 11:30:30AM +0100, Simon McVittie wrote: > On Sat, 05 Aug 2017 at 06:50:00 +, Niels Thykier wrote: > > Can we integrate these LSM policies into our testing frameworks (e.g. > > autopkgtests), so we can start having automated tests of even basic > > functionality. Or will that happen "out of the box" if we enable it by > > default (and, possibly, enable it on our test hosts)? > > In practice probably only if our test hosts change from being lxc > containers to being full virtual machines, which would be good for > other aspects of test coverage too (flatpak/bubblewrap currently skip > many of their autopkgtests, and so does debootstrap). FWIW, my last upload of debci has a prototype qemu backend. I want to switch to that sooner rather than later. signature.asc Description: PGP signature
Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes
On Mon, Jun 19, 2017 at 10:18:52AM +0100, Sean Whitton wrote: > Hello Christian, > > On Sun, Jun 11, 2017 at 08:16:43PM +0100, Sean Whitton wrote: > > Christian Seiler writes: > > > > > Your goal in wanting to stop people from having to deal with > > > patch files manually is laudable, but I see the following way > > > forward to achieve that goal: > > > > > > - Pull requests. > > > > > > - Make it easier to create personal copies of remote (!) > > >repositories in one's own space. (Currently it's still a bit > > >cumbersome.) > > > > This would cover most of the use cases I had in mind. Thanks for > > bringing it up. > > Since writing this I've thought of another usecase, where next/foo > branches complement pull requests. > > Someone might contribute a fix in the form of a PR, and an uploader of > the package might review that fix and determine that it should be > merged. They then look at the master branch and decide that it should > not go into the next upload, for whatever reason. So they can merge the > PR to next/sid. > > This is useful because it avoids accidentally reviewing the patch twice. I would imagine that any PR workflow would allow anyone to add a comment saying they have reviewed the changes and they look good, withing the same "place" where the maintainer is already looking at. signature.asc Description: PGP signature
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Tue, May 16, 2017 at 10:25:54AM +0800, Paul Wise wrote: > On Tue, May 16, 2017 at 12:39 AM, Antonio Terceiro wrote: > > > Right. IIRC that was said to me at Debconf16 about Debian-specific > > services (such as ci.debian.net which was the context of my question). > > Yeah, for codebases maintained by the service maintainer not having > packages seems reasonable (but not for dependencies of that codebase) > and that seems to be the current feeling within DSA. > > Personally I'm leaning towards the feeling that all configuration, > code and dependencies for Debian services should be packaged and > subjected to the usual Debian QA activities but I acknowledge that the > current archive setup (testing migration plus backporting etc) doesn't > necessarily make this easy. The PPA/bikeshed mechanism might make it > more feasible if that happens. That makes sense. I am currently working on a personal project that involves deployment to my private server. I have Debian packaging for it, and I have a make target that will take the most current code, apply the Debian packaging, build a binary package, scp it to my server, and install it. Whenever I am ready to deploy a new version, doing it is just on command away. An alternative to waiting for bikesheds and for waiting for the full archive dance could be DSA providing a similar system for service maintainers. They would upload one or more binary packages (alongside a signed .changes, and maybe we also want the corresponding full source) for their service. On the receiving end, the system would install those binary packages after verifying signatures, and perhaps also a whitelist of binary packages that the service maintainer in question can submit. signature.asc Description: PGP signature
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Mon, May 15, 2017 at 07:53:59PM +0800, Paul Wise wrote: > On Mon, May 15, 2017 at 7:48 PM, Antonio Terceiro wrote: > > > This is a common misconception. DSA does *not* require that the service > > is packaged. On the contrary, they say it's better if the service is > > *not* from a package because this way the service admin does not need to > > have root access on the machine where the service is hosted. > > Uhhh, I think that misrepresents DSA's position. For most things that > might run on a future Alioth replacement, we would definitely want > them packaged properly. Right. IIRC that was said to me at Debconf16 about Debian-specific services (such as ci.debian.net which was the context of my question). It makes sense to prefer packages for something that has a proper upstream that is not us, which is the case in this discussion. In any case, it would be super useful to have this explicitly documented at the DSA website. signature.asc Description: PGP signature
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Sun, May 14, 2017 at 03:04:26PM +0530, Pirate Praveen wrote: > On ഞായര് 14 മെയ് 2017 02:46 വൈകു, Yao Wei wrote: > > Hi, > > > > Are there a discussion list of people working on the issue? I'd like to > > follow and see if there's any I could help. > > > > If no, could this issue be submitted as a Debian bug? > > As far as I understand, the only thing that is blocking is non > availability of pagure package. > > So helping fix this would help move this forward (currently pagure tests > are failing). > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046 > >> > > After we have the package, then DSA standard processes for new service > would follow, I assume. This is a common misconception. DSA does *not* require that the service is packaged. On the contrary, they say it's better if the service is *not* from a package because this way the service admin does not need to have root access on the machine where the service is hosted. signature.asc Description: PGP signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Fri, Jan 13, 2017 at 02:38:28PM +0100, Ondrej Novy wrote: > Hi, > > 2017-01-13 8:46 GMT+01:00 Pirate Praveen : > > > Similar to piuparts auto rejects, I think we should add auto reject when > > autopkgtest of a reverse dependency or build dependency fails (which was > > not failing earlier) or cause FTBFS to reverse dependencies. > > > > just be carefull, because there are some packages which FTBFS in debci > (example: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/swift.html > ) > and it's bug in debci. Build works fine in buildd and in my local sbuild. I think you are a little confused. That links to reproducible builds, which has nothing to do with debci. signature.asc Description: PGP signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote: > Paul Gevers writes: > > I am not sure if you are addressing me or Pirate, but indeed I am > > working on an implementation similar to what Ubuntu does (see the link > > above about the details) which will be used as unstable to testing > > migration blocker. debci is the worker, but all the policy logic will be > > with britney where it belongs. And of course I try to have a full > > release cycle to tune it. > > Will there be a way to override this for the maintainer? Otherwise I > would see the danger that a buggy reverse dependency CI test can prevent > an important update, for example if the reverse dependency uses a long > deprecated function that is now removed. You can either fix the reverse dependency, or get it removed. signature.asc Description: PGP signature
Re: What happened to the idea of using migrations and coordinated uploads when updating packages that has many reverse dependencies?
On Mon, Dec 12, 2016 at 12:38:47PM +0530, Pirate Praveen wrote: > 1. When handling fragile languages (javascript, ruby, go and possibly > more), I think that this view of "fragile languages" is very misleading, and perhaps a little dangerous. There are no fragile languages, but fragile projects. You can write a fragile project in any language you want. Also, that fragility is mostly only perceived on the Debian side, because those upstream communities have mechanisms for locking their dependencies to specific versions, having multiple versions of the same package loaded at the same time, etc. We in Debian *choose* that those practices should not be followed, and *decided on our own* to package their stuff. It is then on *our burden* to handle the so-called fragility. signature.asc Description: PGP signature
Re: Lots and lots of tiny node.js packages
Hello Ian,
This is not a personal response to you, I am just pigging back on your
email.
On Tue, Nov 01, 2016 at 08:50:38PM +, Ian Jackson wrote:
> Sruthi Chandran writes ("Bug#840937: ITP: node-kind-of -- Get the native type
> of a value"):
> > * URL : https://github.com/jonschlinkert/kind-of
>
> Pirate Praveen writes ("Bug#842129: ITP: node-path-type -- Check if a path is
> a file, directory, or symlink"):
> > * URL : https://github.com/sindresorhus/path-type#readme
>
> I picked these two almost at random.
>
> I appreciate you're working hard to package up all this web
> application infrastructure. This is an area that Debian is doing
> rather poorly in and it is good to see efforts to improve it.
>
> But:
>
> These are tiny packages and there seem to be lots and lots and lots of
> them.
>
> Every new source package and binary package is (or causes):
> * An entry in Sources and Packages that everyone, even everyone
>who doesn't use it, needs to download
> * A database entry in each of our package management systems
>(the DAK db, the BTS, the PTS/tracker, buildds, etc.)
> * Processing overhead for every Debian system everywhere on
>the planet, while parsing packaging databases, representing
>package graphs
> * A mail like these ITPs
> * Human effort to review it separately in NEW, ITPs, sponsorship (if
>applicable), etc., which would be easier if aggregated
> * Corresponding edges in the Debian dependency graphs
> * Probably several separate git repositories
>
> Our systems are not really set up for so many packages. They were
> designed with the assumption that a package would represent a
> substantial amount of upstream work, so that the Debian overhead is
> modest by comparison.
>
> Can you explain why you don't aggregate these into bigger packages,
> for use in Debian ?
>
> I don't think it matters very much exactly what the aggregation
> boundaries are but I think given the size of these packages when I
> looked at a couple upstream, you could profitably put many dozens of
> these tiny libraries into a single .dsc and .deb.
As a regular reader of debian-devel, I must say I am frustrated by this
discussion being raised yet another time. We must have had similar
threads, with *the same* arguments, 5 or 6 times in the last year. This
has been discussed to exaustion, and there is no consensus.
Unfortunately if we want to have useful (FSVO useful) stuff that is
written in Javascript/Node.js in the Debian archive, following what we
all accepted as the DFSG and the Debian standards of quality, we will
have to live with it.
I won't repeat any of the arguments that were already provided several
times, because I am tired. If I, who do very little, or none, of the
actual work necessary, am tired, I imagine how the people actually doing
the work feel. I am grateful that there is people willing to put this
work in, so let's please let them do it without rehashing the same
arguments over and over and over every few months.
signature.asc
Description: PGP signature
jquery 3.x uploaded to unstable
To those who care about jquery: I have just uploaded jquery 3.1.1-1 to unstable. jQuery 3.x is supposed to be mostly backwards compatible with 1.x, however there a few breaking changes such as removal of APIs that were already marked as deprecated in 1.x, and change of behaviour on edge cases. jQuery 3.0 was release back in June, so in principle affected upstreams had at least a few months to deal with any fallout. If that's not the case, you can refer upstream to this upgrade guide, which documents the details: https://jquery.com/upgrade-guide/3.0/ A ddlist of affected packages is below. A. Maitland Bottoms gr-radar libiio (U) Adrian Knoth calf (U) Afif Elghraoui pbh5tools (U) python-pbcore (U) Afif Elghraoui pbalign (U) python-pbh5tools (U) Agustin Henze imagesloaded jquery-colorbox nikola Agustin Henze jquery-goodies (U) Al Stone libbrahe Alastair McKinstry fcm libdap Alberto Garcia filetea Alberto Luaces Fernández openscenegraph (U) openscenegraph-3.4 Alessandro Ghedini libdevel-nytprof-perl (U) Alessio Treglia libgig (U) sord (U) Alexander Strasser ffmpeg (U) Alexander Wirt icinga (U) nagios3 (U) Alexandre Fayolle python-scipy (U) spyder (U) Alexandre Gramfort python-mne (U) Alexandre Viau influxdb (U) select2.js (U) Andrea Capriotti autoradio Andrea Veri webdeveloper (U) Andreas Bombe anki Andreas Cadhalpun ffmpeg (U) Andreas Henriksson libgda5 (U) Andreas Moog elycharts.js (U) Andreas Tille ball (U) cimg (U) freecontact (U) libgtkdatabox (U) liblemon (U) librostlab-blast (U) mobyle (U) mrs (U) openslide-python (U) orthanc (U) osrm (U) pynast (U) python-cogent (U) python-fitbit (U) python-mne (U) qiime (U) qtiplot (U) r-cran-shiny (U) Andrew Shadura sparkleshare (U) Andrew Starr-Bochicchio loggerhead (U) python-django-debug-toolbar (U) stackapplet (U) Andriy Senkovych salt (U) Andy Li haxe Angel Abad libmojolicious-perl (U) Angelos Tzotsos pycsw (U) Angus Lees cargo (U) rustc (U) Anthony Towns gitit (U) Antoine Beaupré photofloat Anton Gladky clp (U) coinutils (U) eigen3 (U) esys-particle (U) freeimage (U) lammps (U) libqglviewer (U) libstxxl (U) qtiplot (U) sdformat (U) viennacl (U) vtk6 (U) Anton Gladky freemat (U) Antonio Terceiro cucumber (U) debci json-schema-validator (U) lava-server (U) ruby-builder (U) ruby-jquery-rails (U) ruby-mocha (U) ruby-simplecov-html (U) ruby2.3 Antonio Terceiro ruby-bdb (U) Antonio Valentino epr-api (U) Apollon Oikonomopoulos haproxy (U) APT Development Team python-apt Arnaud Fontaine apachedex Aron Xu opencc (U) Arthur Gautier php-codecoverage (U) Asias He opencc (U) Balasankar C ruby-rotp (U) Balint Reczey erlang-cowboy (U) ffmpeg (U) kodi (U) Barry deFreese box2d (U) libclaw (U) libphysfs (U) Barry Warsaw genshi (U) python-webob (U) Bas Couwenberg gdal (U) geographiclib (U) geos (U) gmt (U) grass (U) libosmium (U) netcdf (U) netcdf-cxx (U) netcdf-fortran (U) openlayers (U) proj (U) protozero (U) pyosmium (U) python-rtree (U) python-stetl (U) qgis (U) readosm (U) Bastien Roucariès imagemagick (U) Bdale Garbee plinth (U) Ben Finney python-coverage Benda Xu scim (U) Benedict Verhegghe pyformex Benjamin Drung flower salt (U) Bernd Zeimetz flask-wtf (U) bertrand Neron macsyfinder (U) Bjoern Boschman phpsysinfo Bret Curtis mygui Brian May billiard (U) celery (U) django-ajax-selects (U) django-guardian (U) python-django (U) python-django-extensions (U) python-django-mptt (U) Cacti Maintainer cacti Carsten Schoenert libcoap (U) Charlie Smotherman openteacher Chow Loong Jin sigx Chris Lamb diffoscope (U) gunicorn python-django (U) simile-timeline (U) Chris Leishman libcypher-parser libneo4j-client Christian Hofstaedtler ruby2.3 (U) Christian Kastner diveintopython3 gitinspector (U) Christian Marillat dispcalgui Christian Perrier geneweb Christine Spang prophet (U) Christoph Berg pgadmin3 (U) phppgadmin (U) Christoph Egger libcsfml (U) libsfml (U) python-icalendar (U) Christoph Haas python-weberror (U) zabbix (U) Christopher Baines osrm (U) Chrysostomos Nanakos xlog (U) Clint Adams gitit (U) libmsv CSILLAG Tamas libmojolicious-perl (U) Cédric Boutillier cucumber (U) nanoc (U) ruby-cri (U) ruby-github-markup (U) ruby-mocha (U) yard (U) D Haley libstxxl (U) Damien Raude-Morvan gradle (U) Damyan Ivanov libdancer-perl (U) Daniel Kahn Gillmor py-postgresql (U) requestpolicy (U) tr
Re: Computing Build-Depends at build time (and other updates to debian/control)?
On Tue, Aug 23, 2016 at 09:30:19AM -0400, Josh Triplett wrote:
> On Tue, Aug 23, 2016 at 01:59:13PM +0100, Ian Jackson wrote:
> > Josh Triplett writes ("Re: Computing Build-Depends at build time (and other
> > updates to debian/control)?"):
> > > On Tue, Aug 23, 2016 at 11:45:03AM +0100, Ian Jackson wrote:
> > > > As people have said: there is nothing wrong with writing a program to
> > > > generate debian/control. You just need to 1. put the generated
> > > > debian/control in the source package; 2. not have the Debian build
> > > > system (ie, the normal rules targets) ever update it[1]; 3. rerun your
> > > > generator manually whenever you like.
> > ...
> > > > I don't understand what your objection to this is.
> > >
> > > Lack of standardization and consistency.
> >
> > I think there should be a standard rules target for updating any
> > autogenerated debian/control. (And perhaps debian/copyright too...)
> > But the lack of a de jure standard does not mean that this approach is
> > not best practice.
>
> Agreed; I'd like to see best practice improved to standardize that
> procedure, though.
>
> > > I've seen various packages
> > > implement this differently (and often not following point (2), insofar
> > > as making a change to the package may cause the control generator to
> > > re-run during clean or build).
> >
> > Please file bugs in such cases. If there are many, you may want to
> > make a MBF.
>
> I don't plan to look for such packages systematically, but if I run into
> one (typically through it breaking the build because I don't have
> whatever extra tools the control generator wants), I'll report it.
>
> > > Even if dpkg-buildpackage doesn't invoke this automatically, and
> > > the source package instead becomes a generated output format not
> > > actually checked into version control,
> >
> > You should commit the generated debian/control to your version
> > control.
>
> Why? That would break the standard principle that version control
> should never contain a generated file, rather than the inputs that
> generate it. (Exactly the same reason "configure" doesn't belong in
> git, only "configure.ac".) I can run the generator, build the result,
> and upload it.
>
> (That would also imply not having debian/control as an input file, since
> the generation process also shouldn't modify any file checked into
> version control either.)
>
> For the same reason, version control wouldn't contain debian/copyright
> if that gets generated.
>
> (This also assumes the package has anything that needs to go in version
> control at all. If the unmodified output of the generator works as a
> source package, then it doesn't have anything to version. I'd only
> create a version control repository if it needed to contain a control
> template or other data to augment the output of the generator, such as
> if upstream doesn't have a sensible Description.)
This is exactly the point of debdry: you only keep in version control
what cannot be derived from the upstram metadata. It even supports
maintaining a partial debian/control that gets merged on top of the
autogenerated one.
It currently supports Python, Ruby, Perl, and Haskell, by calling the
respective packaging generators. Adding more languages is easy.
BTW debdry needs a new maintainer, and could really benefit from some
work to improve its workflow.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813203
signature.asc
Description: PGP signature
Bug#834866: ITP: python-whitenoise -- static file serving for WSGI applications
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: python-whitenoise Version : 3.2.1 Upstream Author : David Evans * URL : http://whitenoise.evans.io * License : MIT/Expat Programming Lang: Python Description : static file serving for WSGI applications With a couple of lines of config, WhiteNoise allows your web app to serve its own static files, making it a self-contained unit that can be deployed anywhere without relying on nginx, Amazon S3 or any other external service. This is specially useful if you want to deploy a WSGI application in an application container (e.g. docker). I plan to import this package into the Debian Python Modules Team repositories, even though I don't plan to get myself deeply involved with the team. I will subscribe to this specific package through the package tracker. signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Fri, Jul 29, 2016 at 05:12:01PM +0200, Alexander Wirt wrote: > On Fri, 29 Jul 2016, Alexandre Viau wrote: > > > On 28/07/16 02:40 AM, Pirate Praveen wrote: > > > At this point, I'm dropping work on gitlab for debian and moving to less > > > controversial alternative pagure. > > > > Pagure looks great and I am happy to see that we are finally moving > > towards something that (more) people agree with. > > > > Thank you for your efforts, I am impressed that you still want to work > > on this project even if we are not going to use Gitlab. > > > > Once again, I would like to mention that I want to help this move > > forward as I consider it very important. > > > > Is there a list of things that have to be done where I can give a hand? > I also looked into pagure and I see two problems: it is not packaged > [...] Note that DSA does not need/want the service software itself packaged, only its dependencies. signature.asc Description: PGP signature
Re: Browserified files and DFSG
On Mon, Jul 11, 2016 at 12:06:57PM +0530, Pirate Praveen wrote: > Hi, > > There is a bug with severity serious filed against libjs-handlebars [1] > (it is also a bug in ruby-handlebars-assets). > > The corresponding source code is present in libjs-handlebars (only in > experimental right now, but it could be reuploaded to unstable once I > have clarity). > > It needs grunt to be packaged [2] to be able to browserify it in debian. Note that this is not necessarily true. In theory, jQuery should require Grunt as well, but I was able to mimic the original build process without using Grunt. It took me a few hours, I would say, but it was way easier than packaging the gazillion dependencies needed to have Grunt itself. The source package contains exactly the source upstream uses for development, and the files shipped in the binary package match exactly what upstream distributes as pre-compiled, modulo whitespace. I even automated testing that this is the case as an autopkgtest test. signature.asc Description: PGP signature
Bug#827375: ITP: auto-apt-proxy -- automatic detector of common APT proxy settings
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: auto-apt-proxy Version : 1 Upstream Author : Antonio Terceiro * URL : https://anonscm.debian.org/git/users/terceiro/auto-apt-proxy.git * License : GPLv3 Programming Lang: Shell Description : automatic detector of common APT proxy settings Description: automatic detector of common APT proxy settings auto-apt-proxy installs itself as an APT proxy autodetector, and detects common setups by checking localhost and the network default gateway for well-known APT proxies such as apt-cacher-ng. . This package is most useful for development environments, and will Do The Right Thing for: . * build chroots, with a proxy running on the host system. * docker/lxc containers, with a proxy running on the host system. * Virtual machines with NAT networking, with a proxy running on the host * system. * any other system, with a proxy running on its default gateway. . The following APT proxy servers are supported and automatically detected: * apt-cacher-ng . This package has a minimal set of dependencies in order to minimize the influence on systems where it is installed. . For corporate desktop/server deployments, where the APT proxy can be located at any arbitrary host, you should probably try the `squid-deb-proxy-client` package instead. This was born when I got tired of automating over and over to make my chroots, containers and VMs use my local APT proxy by creating /etc/apt/apt.conf.d/01proxy with the correct configuration bits. Instead of all that, I can now just install this simple package and it "Just Works". My idea is being open for extending the tool to correctly detect other reasonable scenarios, and specially proxies other than the one I use (apt-cacher-ng). I did some research and TTBOMK there is no similar solution, so I plan to get it in the archive so others can benefit, and also to make my life easier with it. ;-) -- Antonio Terceiro signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Sat, Jun 11, 2016 at 10:51:18AM +0200, Ole Streicher wrote: > Holger Levsen writes: > > On Sat, Jun 11, 2016 at 10:24:48AM +0200, Ole Streicher wrote: > >> We do patching as part of our daily packaging already: to replace (or > >> circumvent) non-dfsg functionality, to integrate into our environment, > >> and everything else that upstream is not willing or able to apply > >> himself but is good in our opinion. Depending on the package, you may > >> find huge patches for our packages > >> > >> I would not see why a missing functionality of gitlab would be different > >> here. > > > > Ole, it seems you didn't understand what Alexander ment when he described > > his > > reasoning with a single word, "nagios"? > > > > Do you know what he is referring too? > > No, I don't. I can speak only from my own experiences when packaging, > and from what I see f.e. as patches in iceweasel. It seems that we are > able to maintain significant patches for quite a while. The fact that we are able to do something does not mean that it is easy, or that we like having to do it. signature.asc Description: PGP signature
Re: Gitlab and the BTS (was Re: Genesis of the git.d.o/gitlab.d.o confusion)
On Fri, Jun 10, 2016 at 10:56:54AM +0100, Jonathan Dowland wrote: > I was wondering what the Gitlab proponent's thoughts are on how the Issue > tracker functionality of Gitlab should be used in a Debian context, > particularly in how it might intersect/interact/conflict with the BTS. Gitlab supports disabling issues (and other features like wiki, snippets etc) on a per-project(repository) basis, as well as making them disabled by default on new projects. A Debian gitlab instance should probably be configured to disable issues by default. I would imagine/expect that all other alternatives mentioned in this thread also support this. signature.asc Description: PGP signature
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 08, 2016 at 03:14:36PM +0100, Iain R. Learmonth wrote: > Hi All, > > On 08/06/16 15:10, Peter Palfrader wrote: > > On Wed, 08 Jun 2016, Marco d'Itri wrote: > >> Since usability is the main reason many people hate using alioth, > > Do people really hate Alioth if they're just using it for git hosting? > You do some ssh and make a repo and then you just pull and push as you > would with anything else. > > >> "because it's shiny" is a reasonable selling point for gitlab... > > It's also far from a feature-complete replacement for Alioth and has > zero integration into our existing infrastructure. > > A shiny web view of repositories is not a reason to run a whole new > service. Just make a shiny theme for cgit. gitlab (and, to be fair, gogs which was also mentioned in the thread) are way more than a "shiny web view of repositories". you are completely missing the point. signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 08, 2016 at 01:57:10PM +0200, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Antonio Terceiro wrote: > > > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > > > On Wed, 08 Jun 2016, Pirate Praveen wrote: > > > > > > > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > > > > > [SN: trimmed Cc list, as this is about what Debian wants] > > > > > > > > > > Hi Alex > > > > > > > > > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: > > > > >> Its more things like: > > > > >> - integration into alioth - aka, how easy is it to integrate the > > > > >> already > > > > >> existing identity data (which we want to keep) into the system > > > > > > > > > > This can be easy (use OAUTH2 against the identity provider) or hard > > > > > (convert all data). Also it speaks ldap itself. > > > > > > > > Does alioth/fusionforge already support becoming an OAUTH2 identity > > > > provider? How do other debian services (like nm.debian.org) use alioth > > > > login? [1] I found this [2] > > > I wrote a minimal exporter for user information (no group or acl > > > information) that gets synced to the dacs host. That enables dacs enabled > > > services to use these information. > > > > for authentication, I think you should probably use the Debian SSO with > > client certificates: > > https://wiki.debian.org/DebianSingleSignOn > Nope, thats http only and doesn't cover ssh. gitlab would not need that for ssh pushes; they are done with a "git" user (like in most sane git server infrastructures), and each user uploads their SSH keys via the web interface after logging in against a central authentication provider. > Client certificates also have several problems, see enricos mails for > details about it. sure. > > for authorization, at least if the plan is to mirror the current alioth > > git infra you will need some scripting to sync the alioth data to gitlab > > (I would suggest starting with a very limited pilot with only one of > > very few projects). > I don't think we will give any third party access to the user and > passwordhashes. gitlab wouldn't need password hashes. as long as the central login thingy lets users login to the gitlab web UI, users can set a gitlab-specific password for git push over HTTP(S). then you would just need to know which users are members of which groups so you can create the corresponding structure on gitlab. since anyone can sign up on alioth today and get that, I don't think this will be a problem. signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: > On Wed, 08 Jun 2016, Pirate Praveen wrote: > > > On Wednesday 08 June 2016 01:07 AM, Bastian Blank wrote: > > > [SN: trimmed Cc list, as this is about what Debian wants] > > > > > > Hi Alex > > > > > > On Tue, Jun 07, 2016 at 08:06:41PM +0200, Alexander Wirt wrote: > > >> Its more things like: > > >> - integration into alioth - aka, how easy is it to integrate the already > > >> existing identity data (which we want to keep) into the system > > > > > > This can be easy (use OAUTH2 against the identity provider) or hard > > > (convert all data). Also it speaks ldap itself. > > > > Does alioth/fusionforge already support becoming an OAUTH2 identity > > provider? How do other debian services (like nm.debian.org) use alioth > > login? [1] I found this [2] > I wrote a minimal exporter for user information (no group or acl > information) that gets synced to the dacs host. That enables dacs enabled > services to use these information. for authentication, I think you should probably use the Debian SSO with client certificates: https://wiki.debian.org/DebianSingleSignOn for authorization, at least if the plan is to mirror the current alioth git infra you will need some scripting to sync the alioth data to gitlab (I would suggest starting with a very limited pilot with only one of very few projects). > Please keep in mind that dacs is not available for non dsa enabled hosts. > > > >> - mapping groups and permissions from alioth to the new system > > > > > > Fusionforge also uses a similar group based permission system. > > > > > > Okay, there is this (hacked in?) "allow every DD to write" permission > > > that some groups use, which is only supported by gitlab EE. > Alioth uses some role based model where specific permissions get mapped to > (pre-)defined roles. We will never be able to get that into a different > system et al. My current plans are limited to group information and admin > flags. Everything else will need to get redefined by the admins to the > specific system. > > We'll have to ask gitlab folks if they are willing to provide that in CE. > I am also not very keen on using a system with a "open core / enterprise" > model. For such a crucial service I would really prefer a real open source > system. But maybe I am alone with that oppinion. You are not. even though I think gitlab is great, the fact that there is a proprietary version with "premium features" has always made me feel weird. -- Antonio Terceiro signature.asc Description: PGP signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Tue, Jun 07, 2016 at 05:16:09PM +0200, Alexander Wirt wrote: > On Tue, 07 Jun 2016, Pirate Praveen wrote: > > > On Tuesday 07 June 2016 10:31 AM, Luca Filipozzi wrote: > > > On Tue, Jun 07, 2016 at 10:19:48AM +0530, Pirate Praveen wrote: > > >> On 2016, ജൂൺ 6 10:37:25 PM IST, Tollef Fog Heen wrote: > > >>> Another prerequisite for d.o hosting is that it runs on a DSA-managed > > >>> machine. > > >> > > >> How do I get such a machine? Since Gitlab Inc, is sponsoring this > > >> hosting, > > >> should we get a new machine and set it up as per DSA standards? > > > > > > I think you start by avoiding us having multiple different git-based > > > services. > > > > > > I don't care which one (gitolite, gitlab) but DSA would prefer if there > > > were > > > only one to take care of. > > > > > > > ok. So I start this process by proposing to move to gitlab for > > git.debian.org (Is there another process I should follow?). If someone > > proposes an alternative (gitolite or something else), we will compare > > the proposed options and decide. > Ok, I should step in here. For some time I am in the process of setting up an > alioth replacement for git.d.o. > > I know that the process is far away from the point where it should be know. > However the plan is still to move to gitolite. > > I don't think that gitlab is able to replace git.debian.org in its current > implementation. Given that gitlab is a monster given its huge number of > dependencies is another point. I would really prefer to have something more > simple than gitlab. > > Alex - with his alioth admin hat on > > P.S. I am on vaction currently, so please don't expect fast answers Fair enough. One cannot plan to replace a service that is maintained by someone else, specially when that someone still has plans to maintain it _and_ disagrees with the replacement. Also, DSA's wish to keep the number of services down to the minimum necessary and avoid redundancy is completely reasonable. It seems to me that the above points means that a gitlab instance would necessarily have to start outside of the official infrastructure. OTOH, in my opinion the status of alioth today is hurting the project. I have been mentoring Google Summer of Code students for 3 years already, and in the first 2 years every single one of them had problems to do simple things as settinup git access on alioth. This year both students were already working on github, me and Tassia (my co-mentor) just asked them to move to gitlab.com to have the project in a free software infrastrucure, and I am happy I didn't have to deal again with the mess that is helping a Debian newcomer start using alioth. Note that I appreciate the work of the people who maintain alioth very much, specially Alexander who has been very helpful on IRC. But I don't really see alioth as having a future. Yes, gitlab is a monster in terms of dependencies, but it also pretty much replaces pretty much every useful feature that fusionforge has, and adds very useful things (such merge requests with code review support, integrated CI, generation of static pages etc), all that without a single user having a real shell account on the server. What some call bloat, others call features. I think the experiment is valid. Praveen, I think you could call this new thing something like labs.debian.net. pkgs.debian.net (the fedora git server is called pkgs.fedoraproject.org), of even dev.debian.net. or anything else, really, as long as it exists, and is not called "gitlab" (I agree that not calling a service by the name of the tool that provides it is a good thing). -- Antonio Terceiro signature.asc Description: PGP signature
Re: ITP: pry-nav -- Binding navigation commands for Pry to make a simple debugger
On Fri, May 13, 2016 at 06:09:13PM +0200, ge...@riseup.net wrote: > Package: wnpp > Owner: Georg Faerber > Severity: wishlist > > Package name: pry-nav > Version : 0.2.4 > Upstream Author : Gopal Patel > URL : https://github.com/nixme/pry-nav > License : Expat > Programming Lang: Ruby > Description : Binding navigation commands for Pry to make a simple > debugger > > Turn Pry into a primitive debugger. Adds 'step' and 'next' commands to > control execution. > > This package will be maintained within the Debian Ruby team. > I'm packaging this, to satisfy a dependency of ruby-mail-gpg [1]. > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823771 pry is a development tool and a library should *not* dependend on it. If upstream has that as a hard dependency the upstream metadata is broken and needs to be fixed. (that said having this is support in pry looks interesting; it should *not*, however, be a precondition for having mail-gpg) > Package name: pry-remote > Version : 0.1,7 > Upstream Author : Mon ouie > URL : https://github.com/Mon-Ouie/pry-remote > License : Zlib > Programming Lang: Ruby > Description : Connect to Pry remotely using DRb > > This package will be maintained within the Debian Ruby team. > I'm packaging this, to satisfy a dependency of pry-nav [1]. > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824198 as above, but this package sounds rather pointless. -- Antonio Terceiro signature.asc Description: PGP signature
Re: using whiptail and translated strings from arbitrary scripts
On Tue, Apr 26, 2016 at 09:32:02PM +0200, Daniel Pocock wrote: > > > It is well documented how developers should create po files for i18n > support in their debconf configuration questions during package install[1]. > > What about arbitrary scripts that are run from the command line and > don't use debconf to store the user responses? How should they interact > with whiptail and translated strings? Is there either a document > explaining how to do this or any existing script that provides a good > example, in a way that makes it easy for Debian translators to support > the package containing the script? the gettext documentation itself? https://www.gnu.org/software/gettext/manual/html_node/Preparing-Shell-Scripts.html All you need to do is make sure is that the installed package puts the compiled .mo files in the right location so gettext finds them. During development, you can probably export some environment variable to make gettext look for translations in your development tree. signature.asc Description: PGP signature
Re: How to deal with "assets" packages shadowing real upstream
On Mon, Feb 29, 2016 at 10:39:26AM +0100, Jonas Smedegaard wrote: > Quoting Paul Wise (2016-02-29 04:30:02) > > On Mon, Feb 29, 2016 at 5:05 AM, Antonio Terceiro wrote: > > > >> IMO both in this specific case, and in the general case, the correct > >> technical decision is to track the actual upstream as a proper > >> Javascript package (supporting both browser usage and NodeJS, if it > >> makes sense), and make the convenience packages for other languages > >> use and depend on the proper Javascript one. > > Do I read you correctly that in your opinion it _is_ a severe bug to not > follow the actual upstream when available. I would agree with that. Yes. > So what next? Do I simply try assume it is a severe bug even if not > written into Policy yet, and see if others agree with that - enough that > eventually we can conclude that yes this should probably be written into > Policy? Yes. signature.asc Description: PGP signature
Re: How to deal with "assets" packages shadowing real upstream
On Fri, Feb 26, 2016 at 10:37:48PM +0100, Jonas Smedegaard wrote: > I do recall our conversation at Debconf. That was however, I believe, > an agreement only between teams. I believe we cannot impose team rules > on Debian as a whole: I can file a _whishlist_ bugreport against a > package requesting it to follow team rules, but not raise severity based > on team rules, I believe. > > What I try ask here is the general logic - not just how to untangle the > concrete issue. What is "the correct technical decision"? IMO both in this specific case, and in the general case, the correct technical decision is to track the actual upstream as a proper Javascript package (supporting both browser usage and NodeJS, if it makes sense), and make the convenience packages for other languages use and depend on the proper Javascript one. I think this situation is exactly the same as convenience copies of C libraries: we always want to have a single copy of each library in the archive, first because of security updates, but also to keep some level of sanity. In most cases we will be able to do that, and in a few cases we will have to make -- temporary, one hopes -- exceptions. -- Antonio Terceiro signature.asc Description: PGP signature
Re: How to deal with "assets" packages shadowing real upstream
On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote: > Hi, > > Do we favor tracking the true upstreams when packaging for Debian? > > Concretely I need¹ a javascript library for server-side use, but the > maintainer considers it adequate² to package that project only > browser-optimized. > > I personally feel it is a bug to not track the true upstream of a > project, but that seems not part of our Policy. Should I respect fellow > package maintainers prioritizing convenience over elegance, or insist > that we should strive towards perfection? > > > - Jonas > > > ¹ I am initially packaging kss-node - bug#816003 > > ¹ bug#809977 requests adding node-handlebars to src:libjs-handlebars (to > cover not only browser but also server-side use), but package maintainer > chose to instead package libjs-handlebars from a Ruby bundling > (re)source (see changelog entry for ruby-handlebars-assets 2:0.20.1-3, > written some months after bug#809977). In the case of this specific package, it seems there is come confusion. I found both src:libjs-handlebars _and_ src:ruby-handlebars-assets, with both providing libjs-handlebars binaries. If you recall, in Debconf we had a discussion between Ruby and Javascript teams, where we agreed that the right place for Javascript is the Javascript team, as proper javascript packages. IMO if that's not possible/pratical from the Ruby POV, at least the Ruby package should not invade the Javascript namespace, and the Javascript should be able to maintain the equivalent Javascript package The Right Way™. I think the issue needs to be communicated, this mess need to be cleaned up, and the correct technical decision needs to be implemented. If you care about the package, and about having it done right, I think you can just report bugs and write patches. I do not think there is any deliberate decision to hijack the Javascript package and not support your use case. signature.asc Description: PGP signature
Bug#805543: ITP: ruby-simple-form -- library to simplify the creation of forms in Rails applications
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: ruby-simple-form Version : 3.2.0 Upstream Author : Plataformatec * URL : https://github.com/plataformatec/simple_form * License : Expat Programming Lang: Ruby Description : library to simplify the creation of forms in Rails applications Simple Form provides a stack of components that can be invoked to create complete HTML inputs on Rails application , which by default contains label, hints, errors and the input itself. Simple Form reduces duplication and helps having a consistent form usage across the application. -- Antonio Terceiro signature.asc Description: PGP signature
Re: init script, installed but not activated
On Tue, Oct 06, 2015 at 10:35:38PM +0200, Michael Biebl wrote: > Am 06.10.2015 um 22:16 schrieb Antonio Terceiro: > > On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote: > >> Hi all. > >> > >> I'm packaging web server for ruby called unicorn. The package installs > >> sysv init script, I want to make it installed but not activated > >> because unicorn itself is useless, user should configure it and > >> activate it with "update-rc.d unicorn enable". Or it may installed as > >> dependency for rainbows, so it's clear that it should not run. > >> > >> So I need something like "dh_systemd_enable --no-enable", existing > >> options for dh_installinit like "--no-start" or > >> "--update-rcd-params=..." does not work such way, so we need to > >> introduce workarounds in postinstall script. > >> > >> Any suggestions? > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709384 > Unfortunately not a lot has happened since the bug was filed. > > > > for sysvinit you need to code that manually in the initscript. several > > packages have their initscripts source /etc/default/$package, and check > > for some variable that says whether the service should start on boot or > > not. > > > > look at varnish for an example. > > Please don't use such ENABLE flags in /etc/default/, this is an > anti-feature. > > If your package does not work unconfigured, a better alternative is to > check for the existence of a config file. Yes, sure. I absolutely agree that doing this is way better then ENABLE flags in /etc/default/$foo. My main point was that however you do, for sysvinit that has to be coded manually in the initscript. -- Antonio Terceiro signature.asc Description: PGP signature
Re: init script, installed but not activated
On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote: > Hi all. > > I'm packaging web server for ruby called unicorn. The package installs > sysv init script, I want to make it installed but not activated > because unicorn itself is useless, user should configure it and > activate it with "update-rc.d unicorn enable". Or it may installed as > dependency for rainbows, so it's clear that it should not run. > > So I need something like "dh_systemd_enable --no-enable", existing > options for dh_installinit like "--no-start" or > "--update-rcd-params=..." does not work such way, so we need to > introduce workarounds in postinstall script. > > Any suggestions? for sysvinit you need to code that manually in the initscript. several packages have their initscripts source /etc/default/$package, and check for some variable that says whether the service should start on boot or not. look at varnish for an example. -- Antonio Terceiro signature.asc Description: PGP signature
Re: Differences between build and CI environment
On Mon, Sep 28, 2015 at 04:31:12PM +0200, Cyril Brulebois wrote:
> Ole Streicher (2015-09-28):
> > The CI tests run here are the same as in during the build process, where
> > they succeed. Since it is a specific test that fails, I guess that it is
> > not just the different location (build tree vs. installed version), but
> > the environment that is different. Specifically, I guess that the
> > problem is the following python test [2]:
> >
> > 8<--
> > PY3_4 = sys.version_info[:2] >= (3, 4)
> >
> > # Used for the below test--inline functions aren't pickleable
> > # by multiprocessing?
> > def _square(x):
> > return x ** 2
> >
> > @pytest.mark.skipif('not PY3_4 or sys.platform == "win32" or
> > sys.platform.startswith("gnu0")')
> > def test_multiprocessing_forkserver():
> > """
> > Test that using multiprocessing with forkserver works. Perhaps
> > a simpler more direct test would be to just open some local
> > sockets and pass something through them.
> >
> > Regression test for https://github.com/astropy/astropy/pull/3713
> > """
> >
> > import multiprocessing
> > ctx = multiprocessing.get_context('forkserver')
> > pool = ctx.Pool(1)
> > result = pool.map(_square, [1, 2, 3, 4, 5])
> > pool.close()
> > pool.join()
> > assert result == [1, 4, 9, 16, 25]
> > 8<--
> >
> > Is there a reason why this could block in the CI context?
>
> A common issue with multiprocessing is the lack of /dev/shm; you would
> usually get something like "function not implemented" though. You may
> want to check things like:
> https://docs.python.org/dev/library/multiprocessing.html
> https://bugs.python.org/issue3770
the CI environment does have /dev/shm, so I don't think that would be
the problem. given the fact that the tests pass just fine under python2
but not under python3, I would start by investigating the difference in
requirements for that code between the python versions.
if you can reproduce the issue locally (you probably want to reduce the
timeout from the default of 2h), you can pass --shell-fail to adt-run,
you will get a shell in the testbed, when you will be able to fiddle
around and try to figure out what the problem is.
--
Antonio Terceiro
signature.asc
Description: PGP signature
building jquery without grunt (was "Security concerns with minified javascript code")
On Fri, Aug 28, 2015 at 10:06:17AM +0200, Vincent Bernat wrote: > ❦ 28 août 2015 08:22 +0100, Philip Hands : > > >>> Or alternatively, by packaging the minifier that is being used with the > >>> package > >>> that needs it. Yes, that's a horrible idea with lots of code > >>> duplication, but > >>> if I understand the problem, every JS file must be minified with the exact > >>> version of the minifier that upstream used, so then every package would > >>> have > >>> its own unique package that it depends on, and in that case they can just > >>> be > >>> merged. But it can't really be that bad, right? > >> > >> Here is the dependency graph of jQuery (only to build it!): > >> > >> jquery@3.0.0-pre /home/bernat/src/jquery > > [ very long list ] > >> ├─┬ grunt-contrib-jshint@0.11.2 > > ... > >> │ └─┬ jshint@2.8.0 > > > > > > I don't know much about this, but I do know that that is a version that > > contains code licensed under the "Do No Evil" license of JSlint: > [...] > > It would be quite easy to not use it at all. Here is a curated list > which removes any tool needed only for testing and linting: > > jquery@3.0.0-pre /home/bernat/src/jquery > ├─┬ commitplease@2.0.0 [...] > └── win-spawn@2.0.0 > > Maybe it can be trimmed a bit more, but that's still 239 unique > dependencies. But no jshint is needed (and for building, its usefulness > is void, so we could just remove the grunt-contrib-jshint package and > keep every other tests). At least for jquery 1.x, I just managed to reproduce the upstream build with ~ 100 lines of code. ~70 of those were basically copied from the upstream grunt stuff: https://anonscm.debian.org/cgit/pkg-javascript/jquery.git/tree/debian/build.js?h=debian/1.11.3%2bdfsg-3 the other ~30 lines are make targets in debian/rules: https://anonscm.debian.org/cgit/pkg-javascript/jquery.git/tree/debian/rules?h=debian/1.11.3%2bdfsg-3 I had to read the source of the upstream grunt build task, understand that it uses something called "requirejs", doing some reading on what requirejs is and how to use it, then extracting the build logic into a file that could be used with requirejs (which is already packages as node-reuqirejs) only -- without grunt -- and there we have it. -- Antonio Terceiro signature.asc Description: Digital signature
Re: Raising the severity of reproduciblity issues to "important"
On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote: > Hi -devel, > > The reproducible-builds team are currently contributing patches with > "wishlist" severity. > > This is because it is not currently possible to build reproducible > packages within sid itself - we maintain a separate repository whilst > our changes to the toolchain are pending review and consultation. > > Filing these bugs with a higher severity -- which would require > developers to use this repository to fully test any modifications -- > would be unacceptable. > > However, based on an informal survey at DebConf (and to reflect the > feeling towards software reproducibility in the free software community > in general) unless there are strong objections I intend to raise the > severity of these wishlist issues to "important" once the toolchain > changes to dpkg and debhelper land in sid. I think that reprocibility is an important issue, and marking reprocibility bugs as important makes sense to me. That, please also include a script to test builds for reprocibility in e.g. devscripts (see #786755) so that maintainers can actually test it themselves. -- Antonio Terceiro signature.asc Description: Digital signature
Bug#794952: ITP: rerun -- tool to launch commands and restart them on filesystem changes
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: rerun Version : 0.10.0 Upstream Author : Alex Chaffee * URL : https://github.com/alexch/rerun * License : Expat Programming Lang: Ruby Description : tool to launch commands and restart them on filesystem changes rerun launches your program, then watches the filesystem. If a relevant file changes, then it restarts your program. Rerun works for both long-running processes (e.g. apps) and for short-running ones (e.g. tests). -- Antonio Terceiro signature.asc Description: Digital signature
Re: diaspora packaging crowd funded work summary
Hello Praveen, On Thu, Jul 16, 2015 at 01:54:15PM +0530, Pirate Praveen wrote: > I ran a successful crowd funding campaign to work full time for a > month on diaspora packaging > (http://www.indiegogo.com/at/debian-diaspora) and here is the summary > of work done. > > diaspora init script updated, diaspora-installer uploaded, diaspora > package is almost ready to upload (two minified js files blocking > upload https://github.com/diaspora/diaspora/issues/5939) > ∘ configures postgres database using dbconfig-common and nginx > ∘ handle package updates > • 23 new gems packaged > • 34 existing packages updated > • moved many packages to unstable from experimental after jessie release > • bootstrap-sass 2 is embedded (debian moved to bootstrap-sass 3) > • debian packaging session at IIT Bombay mini debconf > • diaspora yatra campaign (29 Jan - May 5) - All districts except > Kannore in Kerala; Mysore, Bangalore in Karnataka; Chennai, Trichy in > Tamil Nadu > • Launched first diaspora pod hosted in India https://diasp.in > • Setup chat using prosody xmpp server on https://poddery.com > > Day by day updates > diaspora yatra https://poddery.com/tags/debian-diaspora-month > > diaspora packaging https://poddery.com/tags/diasporayatra > > Originally posted at https://poddery.com/posts/1898205 That's really nice, thanks for keeping us updated. What is the current status with regards to having a proper diaspora package in the debian archive (with all its dependencies also in the archive)? -- Antonio Terceiro signature.asc Description: Digital signature
Re: GitHub “pull request ” is proprietary, incompatible with Git ‘req u est-pull ’
On Wed, Jul 15, 2015 at 03:25:52PM +0100, Ian Jackson wrote:
> Antonio Terceiro writes ("Re: GitHub “pull request ” is proprietary,
> incompatible with Git ‘req u est-pull ’"):
> > But if there is server side support for anyone to push to some ref in
> > the maintainer's repository without any authentication in a way that
> > won't otherwise interefere with the maintainer's regular trees, the
> > client side "should be easy".
>
> Such server side support is fairly straightforward.
>
> Would you like me to write you a proof-of-concept ?
It would be nice, but given the amount of stuff I am already involved
with, it may take a little while for me to followup with some client
side code. /o\
--
Antonio Terceiro
signature.asc
Description: Digital signature
Re: GitHub “pull request ” is proprietary, incompatible with Git ‘requ est-pull ’
On Tue, Jul 14, 2015 at 05:06:31PM +0100, Ian Jackson wrote:
> Antonio Terceiro writes ("Re: GitHub “pull request ” is proprietary,
> incompatible with Git ‘requ est-pull ’"):
> > I have a few ideas about this. I have used gerrit before, and it
> > provides a really nice experience except for 2 little facts:
> >
> > - you have to use a web UI thingy to review patches (although that said
> > web UI does have a really nice keyboard-based navigation support)
> >
> > - the server side is quite heavyweight, so both running your own and
> > packaging it for Debian seems to be difficult.
>
> Right.
>
> > I would be very happy if something that works more or less like gerrit
> > but without the above issue existed. I would imagine something along
> > these lines:
> ...
> > on the submitter side
> ...
> > $ git pull-request submit $ORIGBRANCH $PATCHSET
>
> This syntax requires that the user have some special
> `git-pull-request' tool.
>
> An alternative would be:
>
> $ git push git://some/url HEAD:$ORIGBRANCH
>
> And the server side would do this:
>
> > This would create a specially named ref on the maintainer's
> > repository, and the maintainer should be notified somehow that such a
> > pull request exists. Notifications methods could be plugged, so that
> > you can choose to enable notification by email, IRC, or what have you.
> > Of course notifications by email is the obvious choice, given commits
> > come with email addresses.
Yes, `git pull-request` was a thought experiment, an imaginary tool.
But if there is server side support for anyone to push to some ref in
the maintainer's repository without any authentication in a way that
won't otherwise interefere with the maintainer's regular trees, the
client side "should be easy".
> > on the maitainer side
> > ---
> >
> ...
> > 3.1) git pull-request accept $id
> >
> > I imagine this could be as easy as a simple wrapper around `git
> > merge`. when the maintainer pushes the branch, it would be really
> > awesome if the server noticed which pull requests have been merged,
> > and notify the submitters of that.
>
> Notify by email, you mean ?
yes. maybe it could also be done client side, I don't know.
> > 3.3) git pull-request review $id
> >
> > This would probably be the hardest part, since we would need to devise
> > a reasonable UI for the maintainer to comment on the contents of the
> > patches. I would imagine that being able to record some review message
> > against each hunk of the diffs would be a good beginning. Being able
> > to add line-by-line comments, as gerrit allows, would be awesome.
>
> I think this is probably future work.
>
> One approach would be
>
> git review-push patchbomb-myself $id
>
> which would use git-format-patch and git-send-email in some fairly
> automatic way. Then you could reply to the individual patch messages
> by email.
I guess the point is storing all of if it the repository itself,
--
Antonio Terceiro
signature.asc
Description: Digital signature
Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
ified of the review. It would be nice to somehow support re-submitting a reviewed pull request, and to be able to recognize a second pull request as a new version of a previous one. What gerrit does is assigning a unique Id to each commit at submission time, and stores it at the commit message as something like `Commit-Id: 12037123721983792187398217`, so if you rebase/ammend, it can still associate the new commit with the old one as long as you keep the identifier in the commit message. When you resubmit it knows that that new commit is a new version of the first one. I have mostly no idea on how this could be implemented, and I'm also not sure that these imaginary UI would be the best one, but I hope that these ideas are useful to start a conversation. -- Antonio Terceiro signature.asc Description: Digital signature
Re: Using build profiles in stretch?
On Thu, May 28, 2015 at 08:43:12AM +0200, Lucas Nussbaum wrote: > It seems the early support in dpkg confused me into thinking that it was fully > supported in stretch. > > So, the question is: should we wait until stretch is released to use build > profiles, to give time to all infrastructure tools to support them, or should > we fix our infrastructure using backports? > > I don't mind reverting my changes, of course. But it's probably worth a > debian-devel@ discussion first. > > Note that in most tools, it's not difficult to add basic "support" for it, > because it only means ignoring build profiles entirely. I mostly agree with Helmut, in that we need to push this otherwise it is never going to happen. I was trying to upload a new version of gem2deb myself, and just noted that the build profiles in the gem2deb Build-Depends also break autopkgtest. As a dependency resolver, autopkgtest generates a fake package using the test dependencies of the package under test, which can include its build-dependencies (with build profiles, if any). This fake package is then built with dpkg-deb, its binary unpacked into the testbed, and then `apt-get install -f` is called to fix the world. At the moment what happens is that dpkg-deb blows up at the build profiles syntax, and autopkgtest aborts. I understand that it does not make sense for the build profiles syntax to be supported in Depends:, so I am writing a patch to filter out the build profiles in autopkgtest. -- Antonio Terceiro signature.asc Description: Digital signature
Re: How continious is debci?
On Sun, May 17, 2015 at 09:01:06PM +0200, Ole Streicher wrote: > Dear Antonio, > > Antonio Terceiro writes: > >> Are there currently any problems with debci? Does it really run > >> continiously? > > > > What is happening is that a system that did the job when the load was > > small (190 packages), using a "simplest thing that works" philosophy now > > needs a little bit of work to be adapted to handle a load that is almost > > 20 times larger (3753 packages at the last update). > > Thank you very much for the explanation. I was afraid that it is > something like this. Maybe you could show somewhere the actual length of > the queue (in days, and in packages), so that one could have an > estimate? That is a good idea. However my hope is to finish the parallel execution soon so that the delay is a non-issue. When I looked yesterday, there was actualy an extra problem with the server setup that made iterations be aborted at some point, so some packages at the end of the queue were not being tested. This is fixed now and the situation should be normalized soon. > Another small issue that was misleading me here: The status page shows > that most of the 3700 package (>80%) actually "Pass". I interpret that > as that they all were already tested. Or does "Pass" just mean "Pass or > never tested"? "Pass" means "pass". :-) I don't remember right now how packages that have never been tested contribute to that chart. I would have to double check the code, but my guess is there they are not counted at all. -- Antonio Terceiro signature.asc Description: Digital signature
Re: How continious is debci?
Hello, While I was writing these responses, I was monitoring ci.debian.net, and it seems I spoke too soon. On Sun, May 17, 2015 at 12:33:08PM -0300, Antonio Terceiro wrote: > > Are there currently any problems with debci? Does it really run > > continiously? > > What is happening is that a system that did the job when the load was > small (190 packages), using a "simplest thing that works" philosophy now > needs a little bit of work to be adapted to handle a load that is almost > 20 times larger (3753 packages at the last update). While all I wrote originally is still valid, it seems that *actually* there is a problem, yes. Some change in the data that debci processes is causing it to fail, and I am looking into it now. -- Antonio Terceiro signature.asc Description: Digital signature
Re: How continuous is debci?
On Sun, May 17, 2015 at 08:13:01AM +0100, Neil Williams wrote:
> On Sat, 16 May 2015 21:23:25 +0200
> Ole Streicher wrote:
>
> > Hi,
> >
> > how does ci.debian.net actually (re-)run the tests?
>
> I'm also seeing problems with updated packages not running the tests.
> The News item on ci.debian.net only lists a handful of packages being
> tested per day. With the churn through unstable after the release, I
> would have expected this to be higher.
The "News" box at the homepage only lists state changes, i.e. a package
that used to fail now passes, or the other way around ("no news is good
news")
> I've made a range of uploads for packages which have been running
> autotests previously but two of these packages have not been tested
> since the upload and have now migrated to stretch. One has a false
> status that the tests fail, despite the version being tested only now
> existing in stable.
>
> http://ci.debian.net/packages/l/lava-dispatcher/unstable/amd64/
>
> This package is marked as failing despite not testing the version which
> was uploaded on 8th May and which migrated into stretch on 14th May.
>
> http://ci.debian.net/packages/l/lava-tool/unstable/amd64/
>
> Should be testing 0.12-1
>
> Yet some other packages uploaded at the same time have been tested.
>
> http://ci.debian.net/packages/l/lava-coordinator/unstable/amd64/
>
> 0.1.6-2 was tested on 7th May.
>
> http://ci.debian.net/packages/d/django-restricted-resource/unstable/amd64/
> (9th May)
>
> http://ci.debian.net/packages/d/django-testscenarios/unstable/amd64/
> (9th May)
>
> So some tests are being done, just not others.
They all look like timing issues to me, see my response to the first
message of the thread.
--
Antonio Terceiro
signature.asc
Description: Digital signature
Re: How continious is debci?
Hello Ole, Thanks for bringing this up. Hopefully I will be able to shed some light into the issue. On Sat, May 16, 2015 at 09:23:25PM +0200, Ole Streicher wrote: > Hi, > > how does ci.debian.net actually (re-)run the tests? > > I have several tests added since 5 weeks now, but never got a > successfull test. For example, fitscut [1] got an CI test on April 10, > and appeared in debci about a week later. However, up to now, no real > test was run. Another example is tcl-fitstcl [2]: here the test was > added on April 26, and I got a failure report on May 6. I updated (with > a corrected test) at the same day, but did not get a newer report yet. > > The FAQ says > > | How often are test suites executed? > | The test suite for a source package will be executed: > | * when any package in the dependency chain of its binary packages changes; > | * when the package itself changes; > | * when 1 month is passed since the test suite was run for the last time. > > Also, if I look on the home page [3], I find just a few tests run every > day, which a bit contradicts the total number of packages (which just jumped > from ~1100 to ~3600 in April or May [4]). Shouldn't this number be > > Are there currently any problems with debci? Does it really run > continiously? What is happening is that a system that did the job when the load was small (190 packages), using a "simplest thing that works" philosophy now needs a little bit of work to be adapted to handle a load that is almost 20 times larger (3753 packages at the last update). Let me quote the FAQ entry right below the one that you quoted: | Q: I just added a test suite to my package; how long does it take for it to be | processed? | | Short answer: it depends on many factors and it may take some days, but it will | show up eventually. | | Long answer: the current infrastructure runs tests sequentially on a single | box; think of a loop in which each iteration takes a few days. The delay for | your package to be processed will depend on: | | the size of the current test queue | | the time in which your package has hit the mirror network | | If the package has hit the mirror network at the beginning of the current | iteration, it will take a few days to be processed. If it arrives at the mirror | network in the end of the current iteration, then your are lucky: it will be | processed at the beginning of the next iteration. "A few days" was the estimate when we were a little over 1000 packages, and now we have three times that number. We already came a long way into having a more performant setup, using a distributed setup with multiple workers and all that fun stuff. Martin Pitt started that work back during last year, and I continued that for a few months now. There are still a few details to sort out, but I think we are quite close to being able to migrate to that. -- Antonio Terceiro signature.asc Description: Digital signature
Re: How continious is debci?
On Sun, May 17, 2015 at 09:34:59AM +0200, Ole Streicher wrote: > Stuart Prescott writes: > > I see that fitscut doesn't declare that it has a test suite in d/control. > > While dpkg adds that field into the dsc file for you [1], I don't now how > > that interacts debci which states that the maintainer needs to add that > > field to debian/control [2]. I don't know whether debci looks in d/control > > or in the dsc (or in Sources) to find packages to test. > > My understanding of the documentation is that debci looks into the dsc. > I never used the entry in debian/control, and I already had "failed" > tests, and several entries in ci.debian.net (without tests however), > which means that they at least sometimes look there. debci uses the Sources file, so yes, the data that comes from the .dsc -- Antonio Terceiro signature.asc Description: Digital signature
Bug#785303: ITP: chake -- serverless configuration management tool for chef
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: chake Version : 0.6 Upstream Author : Antonio Terceiro * URL : https://gitlab.com/terceiro/chake * License : MIT (Expat) Programming Lang: Ruby Description : serverless configuration management tool for chef chake allows one to manage a number of hosts via SSH by combining chef (solo) and rake. It doesn't require a chef server; all you need is a workstation from where you can SSH into all your hosts. chake automates copying the configuration management repository to the target host (including managing encrypted files), running chef on them, and arbitraty commands on the hosts. This will be maintained as part of the Debian Ruby team. -- Antonio Terceiro signature.asc Description: Digital signature
Re: oauth2 sprint at DebConf?
On Thu, Mar 19, 2015 at 11:11:16AM +0200, Enrico Zini wrote: > Hello, > > the oauth2 part of our single signon system is in need of a team of > people to maintain it, and my experience so far has been that nobody > seems to understand oauth2[1]. > > I would like, in some future, to completely replace DACS with OAuth2 for > sso.debian.org, but I would not want that to happen until there are at > least three active people in Debian who actually know the protocol > inside out and have an interest in becoming comaintainers of the > sso.debian.org infrastructure[2]. > > Studying the protocol is probably more fun when done in a group, so this > looks like an idea for a DebConf Sprint[3]. > > Who would be interested in joining this? o/. I am still not sure how much of Debcamp I will be able to attend, but in the worst case we can use a few mornings/afternoons/evenings during Debconf proper. -- Antonio Terceiro signature.asc Description: Digital signature
Re: GitHub “pull request” is useful and can be easily integrated'’
On Mon, Apr 20, 2015 at 03:06:04PM +0200, Ondřej Surý wrote: > On Mon, Apr 20, 2015, at 02:09, Brian May wrote: > > I have never actually used GitLab, so I can't actually comment on how > > good it is... > > Perhaps you should, before you start suggesting thing based on > GitLab... ;-) > > Anyway - GitLab is quite good these days and it has matured[1], but it's > a typical Ruby project - impossible to package and constant updates. That is the case for any non-trivial, relatively new, free software project *in any technology* these days. And yet, we will get there eventually. Diaspora¹ is almost done, and GitLab will follow at some point. ¹ not the existing diaspora-installer package, an actual diaspora package with its dependency tree properly packaged. -- Antonio Terceiro signature.asc Description: Digital signature
Bug#777055: ITP: ruby-whenever -- Ruby library to abstract writing and deploying cron jobs
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: ruby-whenever Version : 0.9.4 Upstream Author : Javan Makhmali * URL : https://rubygems.org/gems/whenever * License : Expat Programming Lang: Ruby Description : Ruby library to abstract writing and deploying cron jobs whenever provides a clean ruby syntax for writing and deploying cron jobs. It provides commands to install and uninstall cronjobs, so for example an application can install its cronjobs when it starts, and uninstall them when it stops for maintaince, without messing up unrelated cron jobs for the same user. -- Antonio Terceiro signature.asc Description: Digital signature
Re: credentials config at pkg install
On Thu, Dec 11, 2014 at 11:30:06AM +, Wookey wrote: > +++ Eugene Zhukov [2014-12-11 13:12 +0200]: > > Hi, > > > > I plan to package a perl script to run as daemon. It will update > > dynamic DNS provider with IP changes etc., but for that it needs user > > credentials registered at provider's web site beforehand. > > Is it a good solution to ask for credentials at package installation > > step? These credentials and other configurations I plan to put under > > /etc. > > If that's OK solution, could you please point me to some example > > package doing similar thing? > > AICCU asks for similar details IIRC. Have a look at that? You can look at ddclient as well. -- Antonio Terceiro signature.asc Description: Digital signature
Re: Javascript trigger design
On Fri, Nov 28, 2014 at 10:30:40AM +0100, Tomas Pospisek wrote: > Am 28.11.2014 um 08:19 schrieb Matthias Urlichs: > > Hi, > > > > Tomas Pospisek: > >> At least the Ruby On Rails framework notices an updated JS and will > >> re-compress the whole JS blob from its parts. > > > > Does it call stat() on every constituent of these packed JS files on every > > web request, or does it do that with a periodic background checker? > > I do not know. Now that I am reading the answers in this thread I'm > noticing that RoR might be checking the newness of JS scripts depending > on the mode it's running in (production, testing, dev). In which case > the trigger mechanism could come into play again. So maybe my statement > was mistaken. In case anybody intends to make conclusions, s/he really > needs to look these detail up in the RoR docu. > *t In development mode, it will always serve the latest version of those files in a way that is transparent to the developer, but of course that has a cost. For production usage, Rails provides a build-time task that you run to compile/minify the static assets. So a packaged app should probably run such task during its postinst; using triggers is a perfect way of solving this. Note however that this feature (calle assets pipeline) is optional and not all Rails apps will use it. Redmine for instance doesn't, partially because it exists since before the asset pipeline was introduced and migrating to use it is not always super convenient. -- Antonio Terceiro signature.asc Description: Digital signature
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On Thu, Oct 30, 2014 at 12:36:24AM +0900, Osamu Aoki wrote: > > This would mean a much more expensive build by default, please don't. > > git-pbuilder uses cowbulder by default (not bare-bone pbuilder), so it > is not as slow as pbuilder. Yes, but it is a lot slower than a plain build on the current system just because you have to install all dependencies at every build. > Chroot build is a good thing. Sure. > > I would rather make plain debuild, or just dpkg-buildpackage, the > > default. > > If you need this, set --git-builder=debuild or > set builder=debuild in ~/.gbp.conf > > It is no big deal which ever system default is chosen. I could use the same argument in reverse: if you want to use a full clean build by default you can also just do that. :) -- Antonio Terceiro signature.asc Description: Digital signature
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On Wed, Oct 29, 2014 at 02:32:04PM +0100, Guido Günther wrote:
> On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> > Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing
> > the layout of git packaging repositories)"):
> > > dpkg-source removes it, by default, for 3.0 based formats as it's part
> > > of the default ignore list.
> > > (or rather ignores it)
> >
> > No, it's not strictly in dpkg-source (not in dpkg-source -b, or
> > dpkg-buildpackage8 -B, anyway). The contents of the default ignore
> > list is in dpkg-source, but it is not enabled unless the caller says
> > -I. git-buildpackage passes -I. dgit's build options specify (either
> > directly or via whatever helper they're using) -i\.git/ -I.git
>
> Git-buildpackage uses whatevert builder you want and it indeed
> currently defaults to 'debuild -i -I' which really isn't a good
> default nowadays for several reasons.
>
> I do wonder if we should switch to using git-pbuilder by default and
> rather offer to invoke 'git-pbuilder create' in case we don't find a
> proper base.cow for it.
This would mean a much more expensive build by default, please don't.
I would rather make plain debuild, or just dpkg-buildpackage, the
default.
--
Antonio Terceiro
signature.asc
Description: Digital signature
Bug#765382: ITP: mailman-api -- REST API daemon to interact with Mailman 2
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: mailman-api Version : 0.2.3 Upstream Author : Sergio Oliveira * URL : http://pypi.python.org/pypi/mailman-api/ * License : GPL-2 Programming Lang: Python Description : REST API daemon to interact with Mailman 2 mailman-api provides a daemon that will listen to HTTP requests, providing access to a REST API that can be used to interact with a locally-installed Mailman instance. The packaging will be maintained together with the upstream repository at https://github.com/TracyWebTech/mailman-api, branch `debian`. -- Antonio Terceiro signature.asc Description: Digital signature
Re: Bug#758124: Documenting the Testsuite field in the Policy.
On Wed, Aug 20, 2014 at 01:38:32PM +0200, Andreas Tille wrote: > On Tue, Aug 19, 2014 at 07:35:22PM -0300, Antonio Terceiro wrote: > > > > > > Anybody Developer who thinks that 1) the Policy is useful and 2) the > > > Testsuite > > > field is useful, can participate. What is needed is to read the text > > > below, > > > verify that it reflects the facts, and if yes, send an email containing > > > something like “seconded”. > > > > IMO the fact that close to 600 packages are already using the field > > shows quite some support for it to be documented. :) > > I somehow was guided by this idea when I was raising my hand the first > time. And yes, I agree that we should document what we are using. > > > > > > > + Testsuite > > > > > > + > > > > > > + > > > > > > + Simple field containing a comma-separated list of values > > > > > > allowing > > > > > > + test execution environments to discover packages which > > > > > > provide > > > > > > + tests. Currently, the only defined value is > > > > > > autopkgtest. > > > > > > + > > > > > > + > > > > > > + > > > > > > + This field is automatically added to Debian source control > > > > > > files by > > > > > > + dpkgfrom version 1.17.11. > > > > > > when > > > > > > + a debian/tests/control file is present in the > > > > > > source > > > > > > + package. This field may also be used in source package > > > > > > control > > > > > > + files if needed in other situations. > > > > > > + > > > > Looks good to me. Seconded, FWIW. > > I wonder whether the second paragraph implies something like: "Since the > field is automatically added there is no reason to specify it explicitly > any more." I think this policy change is even implemented in lintian since > I think to remember that lintian stopped warning about the missing testsuite > field (if I remember correctly without checking). There are cases when you want to add it explicitly, e.g. when someone comes up with a new possible value for it that is not automatically added yet. Testsuite: mynewthing or even Testsuite: autopkgtest, mynewthing So maybe we could review the text like this: Testsuite Simple field containing a comma-separated list of values allowing test execution environments to discover packages which provide tests. Currently, the only defined value is autopkgtest. dpkg-sourcefrom dpkg-dev version 1.17.11. will automatically add this field to Debian source control files with the value autopkgtest if a debian/tests/control file is present in the source package. This field may also be used in source package control files if needed in other situations, for example to declare other test suite handlers that are not yet automatically detected by dpkg. -- Antonio Terceiro signature.asc Description: Digital signature
