Re: Maintainers needed for debtags.debian.org
On Sun, Jan 21, 2024 at 10:52:02AM +0100, Jonas Smedegaard wrote: > I can offer to maintain hosting and packaging of debtags code projects. > Would that be helpful, or are/were you looking for new code maintainer? Thank you for your interest! Personally I am not motivated to look after Debtags anymore in any capacity. I see it similar to the old menu system: while interest in it is not strictly zero, I consider it fringe enough that it's not worth my effort to keep going. At the moment things are such that it's taking ages for me to even shut it down, because it would require me to prioritize an afternoon over many other things that have a higher priority for me at the moment. So, if you want to take over the whole leadership of the project, feel free and I'll request that you have access to the Debtags group, maintain the deployed codebase on debtags.debian.org, upload tag updates, and so on, and I can answer some questions on how things work at the moment, and wish you better luck than mine with it. Its design can certainly be downscaled furthermore into something that may keep alive goplay-like use cases. Otherwise, any course of action that means that Debtags is still primarily my problem is not the course of action that I'd like to take. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: /usr-move: Do we support upgrades without apt?
On Sat, Dec 23, 2023 at 01:22:48PM +, Richard Lewis wrote: > Perhaps release-notes should suggest to run dpkg --verify after a > dist-upgrade anyway - i assume it doesnt hurt to do so? In that case I'd recommend to run it both before and after. I only became aware of dpkg --verify from this thread, I ran it in my system for the first time in years and it found a thing that looks more like a bug in a maintscript years ago than a usrmerge issue. Running `dpkg --verify` also before the upgrade can be a way to avoid getting upgrade bug reports for preexisting issues Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Re: Reaction to potential PGP schism
On Wed, Dec 20, 2023 at 10:16:28PM -0500, Daniel Kahn Gillmor wrote: > # Why is GnuPG on Debian's Critical Path? > > In 2023, I believe GnuPG is baked into our infrastructure largely due to > that project's idiosyncratic interface. It is challenging even for a > sophisticated engineer to figure out how to get GnuPG to (probably, > hopefully!) fulfill a cryptographic task in their project. Once that is > done, it's especially painful to consider moving to a different OpenPGP > implementation, because the interface to another implementation rarely > lines up cleanly with GnuPG's interface. I maintain critical code that calls out to gnupg, in part because at the time I wrote it that was the only thing available, and in part because I'm supposed to offer the broadest possible compatibility with what other people in Debian are using, so if everyone else seems to use gnupg, gnupg is the first thing I would consider. I hated and still hate every single moment I spent having to interface with gnupg. The protocol to interact with it is custom, hydiosincratic, poorly documented, and very hard to speak correctly. When in the end I managed to make things work, I was always left with the feeling that there would still be a corner case that I missed, or that will be introduced in a future gnupg release, waiting to become a security issue in our infrastructure, despite having asked for peer review from appropriate people in Debian. New releases make things harder rather than easier. Now gnupg is a mini-ecosystem of security-critical daemons that need to be brought up and killed, that may time out or run partly off sync with configuration, which adds even more know-how to the amount require to survive as downstream consumer of that one single "API". I've been wanting for literally decades something with language bindings, or with a protocol that is built on existing well-known standards, outputting data that I can parse with an existing and tested parser library, using I/O channels that I can manage using an existing and tested communication library. I hate it every single time I need to use gnupg, but still I use it because I understand it's what Debian has been expecting me to use, so I add that requirement to the pile of historical quirks that geologically accrete in our community, which make our barrier of entry so stylishly high, and make us appear oh so fearfully smart. > # What Can Debian Do About This? > > If you are implementing or maintaining an OpenPGP implementation in > debian, please consider encouraging upsteam to add a sop frontend, and > get it tested in the interop test suite! This. I don't know if it should be sop or a protocol or a standard, but I'd like to see Debian clearly document its expectations on its crypto requirements, and stand behind it. I personally believe that we should depend, for our core security, on an interoperable standard with multiple implementations rather than a project that follows the hydiosincracies of a single isolated upstream. Whatever we do, though, I want that to be official. As things stand I'll keep suffering with gnupg until at a DebConf I'll have at least 5 people look at me wide-eyed and say "are you still using THAT? Everyone moved to THIS instead!" I'd like to ask for what mature OpenPGP implementations exist today, pick one I feel I can confidently control, and then when somebody comes and says "my gpg/$TOOL segfaults on your input", I want to be able to point them at a documented decision and say "please report a bug to $TOOL" instead of taking a week off to port everything again to gpg. Thank you for all the work you've done on this over the years! I've appreciated it with great gratitude and a big hope that some day, thanks to you and others like you, those >=5 people at a DebConf will really look at me wide-eyed and show me a way out of the pit. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Sunsetting Debtags
Hello, about a year ago I announced the intention of letting go of Debtags[1]. No successor has happened to carry over maintenance since then, so it's time to follow my own advice[2] and properly let go. # What I tried, what worked, what didn't Debtags has existed for almost 20 years, with the intention of providing a categorization system for Debian packages, as a better way than sections to explore Debian's vast and growing body of packages. At the time I set off, studied some library science, found faceted classification as a useful theoretical foundation, and together with others slowly built a vocabulary of categories that are tailored to Debian's specific structure. I my past I used to try way too hard to be helpful, and ended up with an excessively overdesigned system. In later years I grew up wiser and worked to significantly simplify everything as much as I could (and I could probably simplify it even more). I implemented assisted ways of categorising packages, to lower the barrier of entry for people trying to categorise packages. I wrote guidelines to having a consistent tag vocabulary, and let any DD commit to the vocabulary itself so that it can be community-maintained. I created a way to anyone with a Salsa account to contribute to tagging and be acknowledged for it on contributors.debian.org I tried (and failed) to get an automatic route for categories to move from debtags.debian.org to ftp.debian.org, so that I am not in the critical path of people seeing their work appear in the Debian archive. # What I would have tried next I've been having a plan of mixing debian/control and debtags.debian.org as authoritative sources. The idea is that if a faced is used in debian/control, then debian/control is authoritative for that facet. The final list of tags in the Packages file will then be built by taking all tags in debian/control, and adding all tags from debtags.debian.org for all facets not listed in debian/control. # Accept the grief and let go I understand that the use case of exploring a distribution as a whole is nowadays mostly a minority use case, and people mostly find packages by searching the internet and then checking if what one found is packaged in Debian. As much as I would like to let go of Debtags in a way that it keeps existing without my involvement and other DDs can step in to maintain it, I cannot do it without significant involvement of other teams like ftp-master that have more pressing priorities. It's been a great ride, and I'm happy of what we all achieved. I think this is one of those aspects where Debian has managed to produce nontivial innovation. That innovation however over time hasn't gained enough traction, and it's time to let go. # What next From now on, as I have free moments, this is what I plan to do: 1. upload the latest dataset from debtags.debian.org to Debian 2. take debtags.debian.org offline 3. orphan/remove the debtags package Existing tags will remain in the ftp-master overrides file until ftp-master will decide to remove them. Since the Tag: header is currently optional in package data, applications should continue working fine when the data will at some point disappear. I will make an effort to try to preserve sources and data for everything somewhere purely for historical purposes. [1] https://lists.debian.org/debian-devel/2022/10/msg00248.html [2] https://www.enricozini.org/blog/2023/debian/adulting/slides.pdf#page=18 [3] https://wiki.debian.org/Debtags Thank you all for this fantastic ride! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: What licenses should be included in /usr/share/common-licenses?
On Sat, Sep 09, 2023 at 08:35:27PM -0700, Russ Allbery wrote: > Licenses will be included in common-licenses if they meet all of the > following criteria: > > * The license is DFSG-free. > * Exactly the same license wording is used by all works covered by it. > * The license applies to at least 100 source packages in Debian. > * The license text is longer than 25 lines. I like this. I'd say that even if a license is shorter than 25 lines I'd appreciate to be able to link to it instead of copypasting it. I like to be able to fill the license field with a value, after checking that the upstream license didn't diverge from what it looks like. I'd love to use SPDX IDs there, for example. In an ideal world, I'd like to autofill debian/copyright with SPDX IDs from upstream metadata. Having a link to a file goes closer to having a declarative license ID. In general the less bytes I have to maintain in debian/* the happier I am, and as a personal aesthetic sense I feel like the less bytes we all have to maintain in debian/* the less is our collective maintenance burden. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Re: Behavior change for Python packages built with CMake
On Thu, Jul 27, 2023 at 01:49:33PM +0200, Timo Röhling wrote: > TL;DR: export DEB_PYTHON_INSTALL_LAYOUT=deb_system in d/rules [...] > N.B. It looks like Meson has been affected in a similar way [2]. I have several affected packages and it wouldn't be a problem to export `DEB_PYTHON_INSTALL_LAYOUT=deb_system` (or `deb`?) in debian/rules. However, I'd like to avoid going and doing several uploads only to learn a month later that this was a temporary workaround that is now causing other problems, and the actual solution is something else. Are we at a situation where we can pick one and document it as an accepted standard, until some build tool will set it by default, in which case it'll only become redundant? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1032997: ITP: pylsl -- Python bindings for liblsl
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: pylsl Version : 1.16.1 Upstream Contact: Christian A. Kothe * URL : https://github.com/labstreaminglayer/pylsl * License : MIT Programming Lang: Python Description : Python bindings for liblsl This is the Python interface to the Lab Streaming Layer (LSL). LSL is an overlay network for real-time exchange of time series between applications, most often used in research environments. LSL has clients for many other languages and platforms that are compatible with each other. - - - LSL seems to be a standard for taking data from devices like EEG sensors and making them availale to software that analyses them. I've packaged this for a personal project, and it would be straightforward to upload it to Debian. I can't take responsibility for supporting people with more professional needs besides trying to deal with FTBFS kind of issues, but after asking in the Debian Science Team mailing list, it can be maintained under the Science Team umbrella.
Bug#1032996: ITP: liblsl -- lsl library for multi-modal time-synched data transmission over the local network
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: liblsl Version : 4.6.0 Upstream Contact: Christian A. Kothe * URL : https://github.com/sccn/liblsl * License : MIT Programming Lang: C++ Description : lsl library for multi-modal time-synched data transmission over the local network The lab streaming layer is a simple all-in-one approach to streaming experiment data between applications in a lab, e.g. instrument time series, event markers, audio, and so on LSL seems to be a standard for taking data from devices like EEG sensors and making them availale to software that analyses them. I've packaged this for a personal project, and it would be straightforward to upload it to Debian. I can't take responsibility for supporting people with more professional needs besides trying to deal with FTBFS kind of issues, but after asking in the Debian Science Team mailing list, it can be maintained under the Science Team umbrella.
Re: Configuration files, local changes, and "managed section" markers
On Wed, Feb 15, 2023 at 07:50:10AM -0800, Russ Allbery wrote: > Well, I adore this way of configuring things and think it's way better > than how Debian has been doing it and I haven't used Red Hat since the > late 1990s, so *shrug*. :) > > But the point wasn't to advocate for that approach specifically, only that > if you *do* have configuration that the user is not allowed to change > because the package is going to override it, it needs to not be in /etc, > because if it's in /etc it's going to be really confusing. I don't care > where you put it, but /usr is the logical spot? > > I think your argument is that maybe you shouldn't have a bunch of > configuration the user can't change, and I agree! I think, making a parallel, that there has been since forever a bunch of configuration the user couldn't change, namely the default configuration values embeded in code, and since before the existance of RedHat itself it was in /usr The way I see it, now it is sometimes being made explicit by storing it in human-readable config files instead of code, which is great because I can go and see what the defaults are and override in /etc only what I need to override. A well documented default configuration in /usr is a better interface for me than default values hidden in documentation that risk going out of sync with code. Along this parallel, one useful point I'd make an effort to extract from Marc's rant is that changes of configuration in /usr need to be treated like changes in default values for configuration in code: that is, as interface breaking changes, which users need to be aware of, and need to be convered in upgrading documentation as would any other behavioural change that may break existing configured systems. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Building python extensions with meson
Hello, I maintain wreport[1], which is a simple C++ library with Python bindings. The package builds fine on bullseye and bookworm, but fails to build on sid. On sid, meson tries to install the Python extension under /usr/local instead of /usr. I do not understand what has changed, nor how to fix it. I looked on sources.debian.net[3] for other packages containing `python.get_install_dir(pure : false) but I only found pycairo and pygobject, which however can also use setup.py to build. Or xraylib. xraylib doesn't build the python bindings in Debian, but if I try to make it do that, as I'm supposed to, I get in the same situation as wreport. Did something break between bookworm and sid, in the interaction between meson and Python? Adding --buildsystem=pybuild to wreport's debian/rules didn't help, and indeed, at least according to grep, pybuild doesn't seem to know about meson. This[3] meson issue has a lot of discussion, but I can't tell how much of it is relevant. Can anyone help me understand what is going on? [1] https://tracker.debian.org/pkg/wreport [2] https://codesearch.debian.net/search?q=python.get_install_dir [3] https://github.com/mesonbuild/meson/issues/8739 Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1024764: ITP: python-hdf5plugin -- Python library to make HDF5 compression filters usable from h5py
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-hdf5plugin Version : 3.3.1 Upstream Author : "ESRF - Data Analysis Unit" * URL : https://github.com/silx-kit/hdf5plugin * License : MIT Programming Lang: C/Python Description : Python library to make HDF5 compression filters usable from h5py hdf5plugin provides HDF5 compression filters (namely: blosc, bitshuffle, lz4, FCIDECOMP, ZFP, zstd) and makes them usable from h5py. I am going to maintain this in the Debian Science Team group.
Bug#1024358: ITP: h5z-zfp -- Compression plugin for the HDF5 library using ZFP compression
Package: wnpp Severity: wishlist Owner: Enrico Zini X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: h5z-zfp Version : 1.1.0 Upstream Author : Mark C. Miller * URL : https://github.com/LLNL/H5Z-ZFP * License : BSD Programming Lang: C Description : Compression plugin for the HDF5 library using ZFP compression H5Z-ZFP is a compression filter for HDF5 using the ZFP compression library, supporting lossy and lossless compression of floating point and integer data to meet bitrate, accuracy, and/or precision targets. I'm going to maintain this package in the Debian Science Team salsa namespace.
Maintainers needed for debtags.debian.org
Hello, I would like to let go of the responsibility of maintaining debtags.debian.org. Over the years I did my best to simplify the whole system, so picking up maintenance shouldn't be too hard, if there is interest. I'm going to keep the service in life support until bookworm releases, and if no other DD has picked up its maintenance by then, I'm going to announce a plan for taking it offline. debtags.debian.org is a Django site. Its code is at https://salsa.debian.org/debtags-team/debtagsd Thanks, Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Sunsetting sso.debian.org
Hello, I've just fixed sso.debian.org to work again after the upgrade of diabelli to bullseye. I however have not used SSO certificates in years and don't intend to. This means I'm unable to test if certificate authentication still works, and to effectively maintain the site: I won't be able to do much more to it than fix Django issues. Unless some other DD steps in to take over maintenance, I annouce my intention to decommission sso.debian.org by the end of March 2023. I would welcome better single sign-on systems for Debian than Salsa, and sso.debian.org is not it. I'm posting this to debian-devel as an early heads-up and a call for other maintainers. If nobody steps in my the end of October, I'll post a proper sunset announce to debian-devel-announce. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: /boot partition too small
On Thu, Oct 06, 2022 at 06:16:56PM +0200, Michael Biebl wrote: > Can you clarify? Is the new intramfs generated in /boot or generated outside > of /boot but copied to /boot under a different name so it can be replaced > atomically? > I assume this is done for robustness reasons. Maybe, if space is as tight as > in such situations, one could compromise here? The situation went somewhat like this: 1. I have 2 kernels installed, a new one arrives 2. Installation of the 3rd one fails as usual, /boot contains 2 and a half kernels 3. I remove the kernel I'm not using, /boot contains 1 and a half kernels 4. dpkg --configure -a keeps failing for lack of disk space 5. I manually remove the initrd file of the new, not fully installed kernel 6. apt install --reinstall of the new kernel succeeds (dpkg --configure -a didn't generate the missing initrd) I haven't had a chance to investigate why with a failed configure phase an old initrd was left there, and why configure failed but a new configure didn't regenerate the initd, so it may be that I hit a corner case. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
/boot partition too small
Hello, my laptop runs with a default partition layout created by Debian Installer 4 years or so ago: Device StartEnd Sectors Size Type /dev/nvme0n1p120481050623 1048576 512M EFI System /dev/nvme0n1p2 10506241550335499712 244M Linux filesystem /dev/nvme0n1p3 1550336 1000214527 998664192 476.2G Linux filesystem The boot partition is now big enough to contain 2 kernel version, too small to contain 3, and too small to purge one and install another (somehow a bit more space is needed during install than is used at the end) Boot happens via UEFI and grub, the root partition is a filesystem in a LV in an encrypted PV. d-i now has better defaults for partitioning, so this isn't a problem in newly installed systems, but it seems like a nontrivial issue in upgrades, which deserves a section in release notes. I'm not sure what could be good, default, official suggestions for this situation, thoguh. There's been some brainstorming on #debian-devel, I'll try to summarise what I've seen so far. I'm not sure any of this can be turned into a one-size-fits-all upgrade path, but a collection of tips and workarounds is at least a starting point. # Temporary mitigations ## /etc/initramfs-tools/initramfs.conf # makes somewhat smaller initrd files and buys some time COMPRESS=zstd # makes definitely smaller initrd files, but breaks boot if # dependencies are not computed correctly: risky! And it needs # regenerating the initrd if running on different hardware MODULES=dep ## using dracut Someone reported that dracut creates smaller initrd images ## Using /boot/efi to grow /boot My /boot/efi is 512M and mostly empty, and is contiguous with /boot. One can shrink /boot/efi and use the space to enlarge /boot ## /boot inside the PV grub can understand LVM, so one can move /boot inside the PV, if the PV is not encrypted. ## Encrypted /boot grub can also understand LUKS, so one can move /boot inside the encrypted PV. grub cannot however forward the LUKS key to Linux during boot, so one would have to enter the password twice. One can store LUKS keys inside the initrd (see /etc/cryptsetup-initramfs/conf-hook), which is then stored in the encrypted PV. This allows to boot entering the password only once, but then anyone who can read the initrd file on the filesystem after boot can recover the key, so one needs to at least manage the permissions of the initd file, which is world-readable by default. This will also give another path for extracting the LUKS keys, although I don't know how hard it is to extract the keys from a running system as it is now, so I don't know how worse this would get. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
libgeos++-dev intentionally broken
Hello, GEOS upstream[1] explicitly offers a C++ API, with no API stability across different versions, and a C API, as a stable wrapper to the C++ API with API and API stability guarantees. The Debian libgeos++-dev package has intentionally stopped[2] shipping some include files that are needed to build programs with the C++ API, stating: > The files are explicitly removed because the C++ API should not be used > by others. > > Having to rebuild rdeps for every upstream release is unacceptable. This[3] is the corresponding issue in Ubuntu. I do understand that Debian is not a good match for a C++ library that does not make API and ABI stability guarantees, but the current solution declares that the package exists but breaks builds, not just of Debian packages using it, but also of software not shipped in Debian[4]. I wonder if there can be a better way of stating lack of support for packages in Debian built using the C++ API, than the current situation of shipping a broken package. Even now having libgeos++-dev in Debian, shipping only the C API, would be better than a broken version. Ideas for alternative approaches, that would still honor the desire of the maintainer of not having to deal with the ripple effects of API/ABI changes? Enrico [1] https://libgeos.org/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010002#20 [3] https://bugs.launchpad.net/ubuntu/+source/geos/+bug/1980147 [4] https://github.com/ARPA-SIMC/arkimet/issues/291 -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 12:43:16PM +0100, Edward Betts wrote: > I've been writing some code to work out the gender balance of speakers at a > conference. It parses the pentabarf XML of the schedule and feeds the speaker > names to this module. > > Here's the results for Debconf 22. > > 72 speakers > > male 48 66.7% > unknown 16 22.2% > female 45.6% > mostly_male22.8% > andy 11.4% > mostly_female 11.4% If the library works as the author intended, it will identify "Enrico" as male, which is a gender *I* don't identify with. This kind of extends to anything related to a person's identity: any software trying to determine an aspect of a person's identity is bound to eventually conflict with how a person lives their own identity. That conflict can be quite painful, so it's not surprising you get strong reactions when intending to package something that pretends to tell people what a person is, without asking them first. This external determination of identity will then extend to the library to any software or research using it. I totally understand the good intentions, but the result honestly amplifies the pain. I think the right way to get the statistics you're looking for would be to ask speakers to state their own identity on pentabarf, so that statistics are based on self-determination, rather than external overrides of it. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Bug#1012712: ITP: ai -- PHP library to develop easily SQL queries usable in web pages
On Thu, Jun 16, 2022 at 06:26:17PM +0800, Paul Wise wrote: > On Mon, 2022-06-13 at 13:56 +0200, Georges Khaznadar wrote: > > > So far, the source package "ai" provides the binary package named > > "php-ai": is it enough to fulfill debian guidelines? > > I'd recommend calling the source package php-ai too. If I were a PHP developer, I would find it very surprising[1] that a package called 'php-ai' contains a small, French-only MySQL helper library with a misguided description. I have a strong feeling that this package is not yet fit for upload in Debian, though an actual call about this should probably come from the PHP maintainer community, not from me. I'm trying to move this discussion back to debian-devel, since it was becoming too on-topic for debian-curiosa Enrico [1] honestly, I would feel trolled -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Open Letter to Debian election candidates about Debian vendettas
On Sat, Mar 19, 2022 at 07:04:23PM +0100, Dominik George wrote: > I ask to finally ban Pocock from all Debian lists (and other > communication channels). Daniel Pocock has for a long time been banned from all Debian lists and communication channels: he is "[..] banned from participating in the Debian community in any form, including through technical contributions, participating in online spaces, or attending conferences and/or events. He has no right or standing to represent Debian in any capacity, or to represent himself as a Debian Developer or member of the Debian community." [1] The email you received was not sent using Debian lists: if you look at Received headers, you will notice that the list headers were forged, and recipient were spammed directly from Pocock's mail server, as part of his campaign to harass our community, along with many other communities from which he has also been banned. [1] https://www.debian.org/News/2021/2027 Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Re: What are the most important projects that Debian ought to work on?
On Wed, Feb 09, 2022 at 09:55:24PM +0500, Andrey Rahmatullin wrote: > > I've added "We should have a default standard packaging workflow": > > https://salsa.debian.org/debian/grow-your-ideas/-/issues/24 > This should include ideas what to do with resignations that will follow. Why would one decide to resign based on a standard for a default that nobody is required to follow? I'm talking about suggesting a widely accepted default for people who would love to have a widely accepted default suggested instead of needing to figuring out a workflow from lots of conflicting tutorials. I'm not talking about mandating the way everyone has to do their work in Debian. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: What are the most important projects that Debian ought to work on?
On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote: > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would be interesting to file them as new issues in > the "grow-your-ideas" project and then reply here pointing to your new > issue: > > https://salsa.debian.org/debian/grow-your-ideas/-/issues I've added "We should have a default standard packaging workflow": https://salsa.debian.org/debian/grow-your-ideas/-/issues/24 There's been some good discussion in this direction a few years ago, and it never went as far as I'd have liked. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Re: debtags.debian.org tag vocabulary now editable by all DDs
On Thu, Apr 08, 2021 at 10:02:53AM +0200, Mattia Rizzolo wrote: > > I could still use help from one or more DDs, doing regular uploads of > > tags from the site to the archive. > > > > It means running a script that generates a source package, GPG-signing > > it, and uploading it with dput. It needs to be done once a month or so, > > and I regularly miss doing that. If you're interested, get in touch and > > we can go through the script to make it work on your system. > > I don't remember if this happened, but did you try to get dak to pull > automatically (or the other way around: debtags pushing automatically) > during dinstall, like it's done by i18n? I tried. I went as far as providing always up to date override files over https that dak can pull, but using them got stuck at ftp-master side: https://debtags.debian.org/exports/overrides/main https://debtags.debian.org/exports/overrides/contrib https://debtags.debian.org/exports/overrides/non-free Wrt debtags pushing automatically, I wouldn't mind, but I don't know how to do it without needing a GPG signature to do an upload. Ideas? Help? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
debtags.debian.org tag vocabulary now editable by all DDs
Hello, * Debian Developers can add new tags to Debtags I have now added group Debian to the Salsa repository for the Debtags tag vocabulary[1]. This means that any Debian Developer can now add tags to Debtags. People who are not Debian Developers are welcome to submit merge requests, which any Debian Developer can approve. * Vocabulary updates are automatically deployed Pushing to master triggers a quick CI job that checks the vocabulary for consistency. If the CI passes, the new tag vocabulary is automatically deployed to debtags.debian.org. Hopefully this means that I'm finally removing myself as a bottleneck for one of the maintenance points to Debtags! * I need help with routine dput-ting of tag data I could still use help from one or more DDs, doing regular uploads of tags from the site to the archive. It means running a script that generates a source package, GPG-signing it, and uploading it with dput. It needs to be done once a month or so, and I regularly miss doing that. If you're interested, get in touch and we can go through the script to make it work on your system. Enrico [1] https://salsa.debian.org/debtags-team/debtags-vocabulary -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa OIDC logins for debtags.debian.org
On Sun, Jan 10, 2021 at 11:41:18PM +0100, Alexis Murzeau wrote: > > I've enabled Salsa OIDC logins for debtags.debian.org. > Thanks, I could login with Salsa and set debtags for my package :) Cool! I've added a 'Settings' entry in the user menu at the top right of the page, which allows one to set a "maintainer email" address. That's used to match the email used in Maintainer/Uploader fields, so when one goes to see one's own packages, one gets the right list, and it's also used to report contributions to contributors.debian.org Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Salsa OIDC logins for debtags.debian.org
Hello, I've enabled Salsa OIDC logins for debtags.debian.org. There may be a few sharp edges that still need filing. For example, I'm not satisfied by the usernames we currently get, but it's a start. On debtags's side, I could use help from a DD with doing regular uploads of tags from the site to the archive. It's basically a script that needs running plus a GPG signature and a dput, but it needs to be done routinely, and I routinely miss doing that. If you're interested, get in touch and we can go through the script to make it work on your system. I've attempted a few times to work with ftp-master to get dak to pull data from debtags.debian.org directly, and even though it doesn't look like a complicated issue, it looks like it's low priority enough that every attempt got stuck so far. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: CentOS and Debian/Ubuntu release cycles
On Thu, Dec 10, 2020 at 05:08:36PM +1300, Joel Wirāmu Pauling wrote: > Streams is currently being used by several very large orgs, and it makes > sense to make it really a RHEL-next+ project, which is effectively what it I wish you didn't speak in absolutes, because I find it, in view of my current personal experience, frankly offensive. To be honest, I'm really glad it works for you. But if you try to tell others that it's all a great idea, I'll ask you not to patronize those who are having different problems that yours. The following narration can be considered a work of fiction, based on a true story. Somewhere Critical For Society, during a global pandemic, we're halfway through a Centos7 to Centos8 migration that's been going on for months and will go on for months more. This is part of a specific long term strategy that uses release jumps as opportunities to review and address obsolescence of a technically, socially, and organizationally complex production ecosystem. Halfway through that careful migration plan, IBM switches the annouced and established 10 years of support for Centos8 to "until next year". Suddenly we realise that our careful migration will likely last longer than the system we're migrating to. We however have the option of retargeting everything on the fly to a hypotetical distribution that doesn't exist yet. In our case, containers are not an option, but a nightmare scenario. We are in fact extremely careful NOT to use containers. If containers ever start to be used within the peculiarities of that environment, then 20 years from now we'll have accumulated countless unique black boxes each with their little custom container setup. At some point one of them will suddenly stop working because of whatever unexepected time_t overflow or something else that was managed by a libc transition 10 years before that however didn't happen in that container, and suddenly there's going to be 20 years of technological debt to catch up. Catch up will have to happen literally immediately, because the level of a river just raised above a critical threshold and the component that failed was part of a production chain that computes which of the towns downstream need evacuating. You and countless others will have wonderful ideas of how containers could be used to make even such a setup so much better. I would consider voicing those ideas, without having made a serious effort to understand the peculiarities of the system that is supposed to adopt them, an act of extremely bad taste. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: [nm.debian.org] Front Desk members and application approvals
On Thu, Oct 29, 2020 at 11:27:03PM +0100, Dominik George wrote: > in case I missed it, what is the background of this decision? Are > there so many NM processes that DAM cannot catch up? Will Debian soond > have so many legitimte project members that all the piled up work get > smagically done by all those people? The idea is partly to have a plan B for when DAM is busy and there are obviously good applications in the pipeline. The other part, is reducing centralisation of responsibility at least for routine cases, and delegate a bit more: checks and approvals to Front Desk, and raising issues to the body of Debian Developers at large. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#961726: ITP: publicdecompwt -- Wavelet decompression tool for xRIT files from MeteoSat Second Generation
Package: wnpp Severity: wishlist Owner: Enrico Zini * Package name: publicdecompwt Version : 2.7.2 Upstream Author : EUMETSAT http://www.eumetsat.int/ * URL : https://gitlab.eumetsat.int/open-source/PublicDecompWT * License : Apache Programming Lang: C++ Description : Wavelet decompression tool for xRIT files from MeteoSat Second Generation This is a development-only library with the decompression code for MeteoSat Second Generation (MSG) images, provided by EUMETSAT. . It can be used to build software that can read MSG images. EUMETSAT has finally freed the source code of this library, and I need to package it as a build-dependency for meteosatlib: https://github.com/ARPA-SIMC/meteosatlib/ To the best of my understanding, upstream does not distribute tarballs, does not support shlibs, and provides only a rudimentary Makefile, so I've added a simple CMakeLists.txt to make it build as Debian tools expect it, and packaged it as a `-dev`-only native package. Enrico
Packaging devel-only C++ library
Hello, I'd like to package a new version of https://github.com/ARPA-SIMC/meteosatlib, for which I'm upstram, which depends on the recently freed https://gitlab.eumetsat.int/open-source/PublicDecompWT PublicDecompWT is a C++ development-only library released by Eumetsat, with functions needed to decompress MeteoSat images. Historically it has had a relatively stable API, but no guarantees are made about an ABI as far as I know, and to make matters worse ABI-wise, it's C++. These options come to my mind: - use git submodules and pull PublicDecompWT into meteosatlib, in a way slightly more convenient to the current instructions of obtaining the zipfile from eumetsat and putting it there - package PublicDecompWT as a devel-only library in Debian, and build-depend on it for meteosatlib. Suggestions? Other ideas? Special things to keep in mind in cases like this (Built-Using?) ? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: DebConf20 registration is now open (with caveats)
On Thu, May 21, 2020 at 10:44:01PM +0200, Daniel Lange wrote: > [1]: https://wiki.debian.org/DebConf/20/Faq This says: > The deadline for deciding on postponing, cancelling or changing the > format of the conference is June 8th. The announcement says: > To request bursaries (sponsorship) for food, accommodation, or travel, > you must be registered by Sunday, May 31st 2020. After this date, new > bursary applications won’t be considered. I'm perplexed by the deadline for the bursaries being earlier than the date in which there'll be a decision about what the format of the conference will be like. The call for registration implies that one would be registering to a similar format of conference as the previous years. As such, I will pass on the registration, and incidentally I resent that this pidgeonholes me as "the only thing you want to do is lay low". Can you however confirm that if on the 8th of June the format of the conference will change into something that one would instead feel motivated to attend, and such format would still requires expenses for which one could use a bursary, then the bursaries deadline will be extended? Otherwise, what I see is that you are effectively forcing people who would like to attend *some* form of DebConf, and aren't sure of their financial means, to apply to something they can't participate, in order not to lose the possibility of being funded for something they would like to. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: reopening bugs closed by removal after package reintroduction?
On Wed, May 13, 2020 at 09:27:33AM -0400, jrb3-beckenbach.us wrote: > Offering a naive implementation idea: > On package reintroduction, something (bot?) files a low-priority bug > against the reintroduced package, titled eg “triage bugs from previous > packaging”, > containing explanatory text (cf Enrico's) and the list of bugs which were > open when the package was removed earlier. > No delayed-auto-close of this bug, though. > > The interested maintainer gets the benefit of knowing what those past bugs > were. > Also, of not having those bugs block current progress. > Also, of being able to do the triage on own rhythm without troubling others. > > The uninterested maintainer can just ignore or close this bug. > (Successor maintainers can even go back in history and do triage more easily, > if desired.) Thank you Joseph, I really like your idea! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: reopening bugs closed by removal after package reintroduction?
On Wed, May 13, 2020 at 05:13:45AM -, Sune Vuorela wrote: > But I guess it also depends on if it is one bug that needs work, or a > "Thanks for your contribution to Debian by maintainig this package. Now > also walk thru these 1000 old crap that probably is irellevant > today"-experience I see two imperfect sides to this. On one side, as a user I report a bug, the package drops out of Debian, the bug is ignored for a year, then closed, the package comes back in Debian, buggy as before, and to add insult to injury, I need to go and reopen the bug again. On the other side, as you say, I want to package something that used to be in Debian 5 years ago, get it into the archive, and suddenly have to triage a number of zombie bugs. I think there are extreme cases to both sides: a maintainer who's been unresponsive on an important package leaving tons of users frustrated; an old package which was popular enough to have tons of bugs, whose code has evolved significantly so that those bugs are all mostly irrelevant by now. Even something like, pypotetically, Gnu Interactive Tools dropping out of Debian, getting its bugs closed, then one packages git and gets all the previous git bugs assigned, all irrelevant. I would however guess that, for a majority of cases, we are probably talking about a bunch of bugs to triage, and I would rather introduce a practice of risking having to triage some bugs more, than a way of losing valid bugs along the way. Especially given that the time to triage a bug should in theory be shorter than the time it took to find it and report it, given also that the maintainer could ask users for help. I prefer a default of remembering which bugs were closed by the package leaving the archive, and reopening them when the package comes back. When that becomes insane, I would like to look at how to make it less insane, which might also help in other situations. For example: - a [semi]automated way of writing to the bug saying "this is part of a number of bugs in an old version of the package that disappeared from Debian. The package has now been reintroduced after upstream progressed significantly, and we need help figuring out of this issue is still present. Could you help with triaging? This bug will be automatically closed in 6 months if there is no interest" - a way of previewing the list of bugs that would be reopened, and have the maintainer decide whether to keep them closed, reopen all of them, or pick some to reopen - having a way of marking bugs as "needs-triage", and encourage group of users to go through such bugs, try to reproduce them, and either close them as fixed, or report them as still found, or add clearer instructions for reproducing If the problem is "one'd end up with lots of old bugs to triage", I'd rather improve the way we get bugs triaged. In (too) many other projects I have the experience of opening a bug as good as I can, being ignored for years, except for a bot that occasionally tells me "if you don't reply to this I'll close the bug and it's your fault for not caring". Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Announcing Debian Social
On Mon, Mar 23, 2020 at 08:10:18AM +0100, Marc Haber wrote: > While we're at thiss, what is the tracker.d.o authenticating against? > Since Firefox has removed the point-and-drool interface to client > certificates, one needs to manually meddle around with OpenSSL to be > able to log in. You can find extensive and up to date documentation on how to make it work here: https://wiki.debian.org/DebianSingleSignOn This said, I would prefer not to see this kind of attitude in any of the places I use to work with others. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Announcing Debian Social
On Sun, Mar 22, 2020 at 03:09:07PM +0100, Mattia Rizzolo wrote: > I want to highlight this bit. > In the past formorer said no to this, as he doesn't want salsa to end up > like alioth and be used for too many things. In particular, he said he > wouldn't want anybody to rely on salsa as a user database. sso.d.o. is > the thing that should be used instead (but it's still lacking a proper > guest account backend). For the records, I consider sso.debian.org as it is now, past its "best before" date, and starting to smell quite bad. A replacement attempt was written, but hasn't been deployed for far too long. I'd love to be able to have the current SSO replaced: it's currently far too high a barrier of access for nm.debian.org and contributors.debian.org for non-DDs, to a point that worries me significantly. What we replace it for, is probably not up to me to choose, although being responsible for maintaining the two current biggest consumers of SSO auth in Debian, I'd like it to happen sooner rather than later. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
On Sat, Mar 14, 2020 at 05:41:38PM -0400, Roberto C. Sánchez wrote: > The fact is that given the length of time packages can wait for NEW > processing and the amount of effort package maintainers put into > packaging, it is understandable that they would be frustrated at the > rejection of a package. That said, it does not make flaming the FTP an > acceptable response and is certainly not going to produce any positive > result. But it is not clear that it would be possible to prevent such a > thing. I would like to change the strategy we currently use in Debian to deal with structural issues, from what seems like "people yell abuse out of frustration and teams survive by bearing with it", to something else. I would ideally like to cut on the abuse, and invest in help (both asking for, offering, and accepting help) in dealing with both routine and structural issues. I mean, *abuse in the project cannot possinly be part of routine work*. Please let the Community Team know of instances so they can talk to people, and please let DAM know of particularly bad instances, like personal threats, if they happen. However, if we have a structural issue that causes frustration, having the community team helping people in keeping their cool and DAM taking action on people with a tendency to losing it bad, does not make the structural issue sustainable. For this reason, thank you for asking for help! I hope people who volunteer can expect better working conditions than what was offered in the call, and I hople that one can have a path of growth in the team from something that looks like grunts who do the routine work under enemy fire, to someone who can get appreciation for their work, over time develop understanding and agency in the team, and eventually can help to shape it. I don't mean for this to be specific to the FTP team. I guess this thread gave me an opportunity to voice my more general thoughts. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Thu, Jan 16, 2020 at 01:15:29PM +, Paul Wise wrote: > > No, did I give that impression? Sorry, search is going to stay > > with regex on (I think it's) package names and descriptions. > > Speaking of search, are the apt maintainers aware of apt-xapian-index > and do you have any thoughts on it? Speaking as the original author of apt-xapian-index, I orphaned it some time ago, since nobody's ever built anything, to my knowledge, on top of its index[1]. I assume that the various package management UIs that we have now, are building their own indices on top of appstream metadata, possibly with the advantage of it being independent from the underlying packaging technology. Enrico [1] I went as far as prototyping and sharing a market web UI kind of prototype at the time, then I stopped: https://www.enricozini.org/blog/2011/debian/pkgshelf/ -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Accepted staticsite 1.4.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 07 Jan 2020 15:29:10 +0100 Source: staticsite Architecture: source Version: 1.4.1-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: staticsite (1.4.1-1) unstable; urgency=medium . * New upstream version - Fixes after some use. See NEWS.md for details. Checksums-Sha1: 203f6649a89faabe7dc52084f63b30a9f0047370 2135 staticsite_1.4.1-1.dsc 448f6d81052e123382aa4dccc67ab11d6838939c 1689159 staticsite_1.4.1.orig.tar.gz c86b59f1217ce3fadfaa23b329b6d9482d964c00 3632 staticsite_1.4.1-1.debian.tar.xz 6df666c4049413fe3c6ffb9bad73e5910ee9445b 7439 staticsite_1.4.1-1_source.buildinfo Checksums-Sha256: 6685e0835cdb0017961ca4bbf36b28ba742399c38531ff0b6a6e1284117baca7 2135 staticsite_1.4.1-1.dsc 1cafb7de8028140c00479251e604fedc26ca665c53c2fed24503a015f7dc1c73 1689159 staticsite_1.4.1.orig.tar.gz c4e4bf27887292912b359c7e430255de6a22f8b35d2eeb869355cce88caf4ebd 3632 staticsite_1.4.1-1.debian.tar.xz 83d0585590fbd16b4a461c87b8ef1938541206aa6d7e63d05e4e6ffa3fc64a3f 7439 staticsite_1.4.1-1_source.buildinfo Files: f04cfd9e971596ab885300c2fbbf3062 2135 web optional staticsite_1.4.1-1.dsc f1ef7108fa0057e2bbec9a4097caa428 1689159 web optional staticsite_1.4.1.orig.tar.gz 38035904b46b77f47862031864a77c58 3632 web optional staticsite_1.4.1-1.debian.tar.xz 7aa525cdc41e591f4398a7aaa9474775 7439 web optional staticsite_1.4.1-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl4Ul0wSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+Z3MP/39FPyuMkuMbOJEYdge5u9v+0ygIZhOJ ivKl/qjR9fAJ2UJLWlggbSmLYXaT/my0Vpd/aND+dK278xvhN6tJD5nY5EU97B7b /Td5cF+N1yM6xUjJAcr+QABAkAR8thZyYs0sojvnYiDgxkCWOzuYoBKH4h9Wn5ZW mb1xRm42J98x8bTOrDf4Ky+vlhHNouIIR8AI80/rEK/IY+Wg2cCGZxkicA2ZoK81 iww0INxqGAMoDQOFZNcvU1mtLnfvGL0AUx7mBK5h/gKJw0/Dyp/T812Ay/6Bg/Hy 5SRdYfPrzxnfqKezC7kH476fEJAj4F527Z1NIw0Q0k0lJ0wYQN1+DzyFH69aT4qm HGb93POGzOols9u1arParhNUFH1WIm/qHuhecTBk7wEuJYflgS5QmT4DDwUEnIDS UALUwC5XST3u+fXHO5f3cC7DREIwrrxnTaH8maRWbBWuvxWC5411J+U0kamVbM9D TH/O5fDoUATlgGl28NBlDy2m1KIKlHZeyoo+BPGTGwIqonk2I+wh96sBK5bvRyUd aeNLg9F0U2iReRZUCIYvmOQF8Kv3uJQJxICqJoPcSr4Y/isdbn9akOHX/r5RIqSD GWLqRyeerjKTjN1/zlOmwS+086OKenJDpro4hnj6myqMMfCCw91jnczhi8SQdIBH SLP+DX8yz8oM =MEcx -END PGP SIGNATURE-
Accepted staticsite 1.4-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 07 Jan 2020 14:06:43 +0100 Source: staticsite Architecture: source Version: 1.4-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: staticsite (1.4-1) unstable; urgency=medium . * New upstream version - Polished blogging use case. See NEWS.md for details. Checksums-Sha1: cbabba3f5d702f94ed7f9885a0343511b7aaac6d 2121 staticsite_1.4-1.dsc 8c17c01dcd90fb248cd5de1fd240cb307a00f78e 1687091 staticsite_1.4.orig.tar.gz d464ea71136bc6777a5ba70001560f600a00048e 3608 staticsite_1.4-1.debian.tar.xz 47ff4e1d6ac8561e3aec3d692bf8f7b8892c1b56 7431 staticsite_1.4-1_source.buildinfo Checksums-Sha256: f8af208e83ace0230594d10e85d758565c18224d449b6cf3be6dc1cf913aa829 2121 staticsite_1.4-1.dsc e0464541a60fa7a0d9826bb97a4b570640cb6c100dc23519b78dea74850214f1 1687091 staticsite_1.4.orig.tar.gz 97cba023eab2f76aec96bce4a77fb9b5f5ebff556f9842710a39e2af7ec97262 3608 staticsite_1.4-1.debian.tar.xz aa7dcadefbd9adfd5cdac235ba86ca7ba28912d0261e6ff4d5b1eea2d06ec9b5 7431 staticsite_1.4-1_source.buildinfo Files: 1cab328f73eb291ec2b118c27b4793fe 2121 web optional staticsite_1.4-1.dsc f7ddc94eb371c874ed66f7d3923bcca1 1687091 web optional staticsite_1.4.orig.tar.gz 79eac53c76e24b02df827b322c2653ee 3608 web optional staticsite_1.4-1.debian.tar.xz 17a87ac765bbb33c14e71fac637f5c9f 7431 web optional staticsite_1.4-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl4UhucSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+W5AP/253v0jSJUu/OmkOvG1Gc4S5218YNA+q J90rUp2gHlr4IbyL7Xadn7CTHkKRAxNSGBddhmeJ9m1Ton+yjbIRUfB2h2O2bW5c 6FaML1NKzmLj0P+lKKTwxRdcSeptgdcsCMvfPAsd0nrS7jdUkWOet0c63g8YXxqv mdCCVF5WUrZMFFkFrcdgUj8CvjZPVn7FvcXk44IPwIxvUoD7G0BjRPU58Nh0sOvA nIdbbFrqoC7XZmaHbpRZhiFBfGsezUdl6qa06oJH3fi2zEuWkw6zUaU0vXmj1cQo EgjE4oOXkyMXwNpBJkktuZSrTXDEh7OhHLIzleUvURWQhHZiEvZ2E2fH+eA2fv9V u4w8PvpsCcUTDYoUtHMPEge7O3U8pru5nmu34m2ALip5okyeKE0l6yO6bNyTYPO6 TN8GCuaMtCgZ1rH/TdZUM7/ugjisAlqguEYCcYGPsuodLwr6Wju0tCduFh+xsb1q BpUveMOPcEx/S7zoZadCaSwfOpJNTyGVny1bVmJubOWvYLY3Cuemo6h76MG9tMqE QF4/jKSbA3PSnX6MvgWgX8xUsBPdYS6aAN3X0Sp/Uyc24vVwIPoFpH0wkSw2zfDR gjBHHUbUpgU8OevZnbKxMxPZSPbMwyUdrVQVo5ywzffk4NPdAUxa3IiKf1hLYUGn gFp+XQLICngU =LkCU -END PGP SIGNATURE-
Accepted dballe 8.6-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 29 Dec 2019 16:48:39 +0100 Source: dballe Architecture: source Version: 8.6-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: dballe (8.6-1) unstable; urgency=medium . * New upstream version, see NEWS.md for what's new. Checksums-Sha1: ce9b23744a594938fd7fc8ae986c50e9bcddee25 2490 dballe_8.6-1.dsc f22e3162a0a5b8fc74fd503d62c4150f92a7fa75 1532715 dballe_8.6.orig.tar.gz 9db12fd9a19d6009e5a0409c6cf7f87bf3fd7896 10848 dballe_8.6-1.debian.tar.xz 393c29917efaeb66873a180225d37a8ed0d9319a 9540 dballe_8.6-1_source.buildinfo Checksums-Sha256: ec5a918c3ad805b2f956efed7a67b45aeca2763cd7871e20258d54c40aed78ab 2490 dballe_8.6-1.dsc 9ba03a6e4270acf024712e9b29c2c3781970206f3d3ddf504f08232f62f70577 1532715 dballe_8.6.orig.tar.gz c2d7402e6e76e6ad571492204403de0bf217fc02ffc601b2699e813e495e9b50 10848 dballe_8.6-1.debian.tar.xz b7d74f1fb98590c6165316c34bd0ec98bc46b0ee9ecbb2344d56b37e7498b684 9540 dballe_8.6-1_source.buildinfo Files: 73de81e6bd338db17fcb4e9993176b48 2490 misc optional dballe_8.6-1.dsc e7f48f4b089afc8a5ec0e1735d435f1f 1532715 misc optional dballe_8.6.orig.tar.gz c00f8e7097e22ae08f632da7aafad8b0 10848 misc optional dballe_8.6-1.debian.tar.xz 4a440729baa4463c2fbfaa9b4ba780e6 9540 misc optional dballe_8.6-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl4I1voSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+K4wP/0UASBJORRdiB0gkxXi18eSlQOAiVMoK R1XjrptvfpF/cvzEeCFbfgZOJHhVkDR//VX5hfPbTfpXelcObUHeMVCN7QLtLAX2 DGKOtRzS3SJsgO7uD7rte5od0V4VFG8k51Dhu0mTWZsgVL/yjawIpaAZvRFng6pl A5AAJZLkV4kiralPb3MLf1ZWzGWGSDhYJ7YAk/ABV83+CsRNLBJzKdxwiMr6eM98 JwrE4Vc7GIUjVIgt9mLGZVAOZme0eWc8e0DVWoZv7ayNFU8fUZ+vVuutfl/01C51 8MSl3WoynH5jM0HQr51bzhsii8u1AjjGLbGQhZpuw+hQ27AAOUtoMe1vXwrv20dv GY71z5MUrNRh+WsLux/pES6/x60xAUxhKZMdqZXybiZmHk2lOjPJUQhUl1Y2FuGh HNYqGmTR0fXcIimK0eu56BpsLLxTDBw5RZcnGMmHRw6eyoO5tCfzow2f2/ZJlgHf IH3Mtc+15iHv5xja21/ykRZprd4oxvjNSj+JXPp/44qJzQlS6qzxspaTL8yoO8pR OHeycOggQpTpuuVhPfBG6lvAfVgBTlzwGLt5jsxHvqiyAXqz0Jxmh/aWcOi416Tv VzbjigiywaLsWNwl94cS0S7SaJwFAVb2x+XoTuw/cH3gtZHWLTqTYrHVmb1+G4rX oTnHpqpnNf/l =Qa2S -END PGP SIGNATURE-
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 12:32:24PM +0100, Paul Gevers wrote: > > Now I see that things got stuck for the transition to testing, and I'm > > asking for help figuring out what to do. > > I'm happy to help. Thanks! <3 > The python3.8 transition is not a classical transition, so this normally > helpful comment from tracker.d.o doesn't really apply. Please ignore it. Ack, wonderful. > As explained above, you'll not be interfering, so go ahead. Perfect, I have gone ahead with a new source-only upload. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
https://tracker.debian.org/pkg/dballe
Hello, some time ago I uploaded a new version of dballe, which went through NEW because of a change in binary package names (SONAME bump, IIRC). It took two weeks to go through NEW and I turned my energy towards other things since then. Now I see that things got stuck for the transition to testing, and I'm asking for help figuring out what to do. I have this: > This package is part of the ongoing testing transition known as > python3.8. Please avoid uploads unrelated to this transition, they > would likely delay it and require supplementary work from the release > managers. On the other hand, if your package has problems preventing > it to migrate to testing, please fix them as soon as possible. You can > probably find supplementary information in the debian-release archives > or in the corresponding release.debian.org bug. And I have this: > Not built on buildd: arch all binaries uploaded by enrico, a new > source-only upload is needed to allow migration I was asked to do a binary upload to go through NEW, and now I'm asked to do a source only upload to go to testing. There are surely good reasons for that, and I wish there weren't. I don't really have a new version to upload, but I suppose I need to at least bump the debian version with no other changes in the package for it to be accepted. Then, if I did that, would I be helping the python3.8 transition by enabling a migration to testing, or getting in the way by delaying the transition and requiring supplementary work from the release managers? I feel a bit caught in a bureaucratic corner. Please help me with some directions to get out of that. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Accepted staticsite 1.3-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 28 Dec 2019 22:35:19 +0100 Source: staticsite Architecture: source Version: 1.3-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: staticsite (1.3-1) unstable; urgency=medium . * New upstream version - Consolidated existing features, see NEWS.md - Themes can now extend existing themes - Standard themes are now distributed in /usr/share/staticsite/themes, and it's possible to add/package new ones Checksums-Sha1: 23b2f6ae60ded6d7d850361b2f24e8c70a05177f 2082 staticsite_1.3-1.dsc 678c4adba4e3f4380244288d8250aaee6b382fe1 1627309 staticsite_1.3.orig.tar.gz f7d91d35a9748c803f63ac03ff611148920c377f 3532 staticsite_1.3-1.debian.tar.xz f72ee71c75b207a58f6c3533c0d6157e876bce7c 7062 staticsite_1.3-1_source.buildinfo Checksums-Sha256: 072fb60b3ac3306f5641d0f538e11296a486510c1e440d7291a409863f7d3aa2 2082 staticsite_1.3-1.dsc 30c58bf9327889656c5610bd5358e40d7b4e5a188729ee26dfbfd2643816c4d3 1627309 staticsite_1.3.orig.tar.gz 8808781b2caab6b91b3ebfd3cb39d8a2d9570ceeaa0a0e9854bf5e042fde89de 3532 staticsite_1.3-1.debian.tar.xz ca69b7f90a86c79dd612bb9f2fc3b389fd5939c59f1788e9f9c235270372985a 7062 staticsite_1.3-1_source.buildinfo Files: e0cf6784fdb8ddb592a79cacc9bc3259 2082 web optional staticsite_1.3-1.dsc 09592dc7e483db4c6807b576c45866fd 1627309 web optional staticsite_1.3.orig.tar.gz f59802804595c2042393ff600fcb2984 3532 web optional staticsite_1.3-1.debian.tar.xz 1c8a48b8338969375762c92efc06951c 7062 web optional staticsite_1.3-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl4HzYASHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+BYwP/jM/+VQyKPjYt44x9BCKKaTItVRwQPB6 HFj5NVbbGemD4oPzfmfstlcvX+2wwJ6GzWKcxsplcb+UR912soReX9hSo01deSi1 MXJusZtezzt/zcrUAC9BwLiVIyXLk2oHlzG8Z42aO62tDx07lpAWLa6OvQe7qamQ GpJcQk1A8K3nsq2LOukQ1vgk2L4roegHmFctlz5ipHBH1uW7Rq+3BkuFZTbv0R3E s9L+9TNjr8wPUaaHEhVUFP6rQtV1sEZJQj08rfL9xJ6ANGcbX7Nso6ZRSMHT3YSt DZEf+/93TE6MFMkfjG/wd4IK4mQ7Y420rrqdpflLQ6gfrD5GI9rLc8a/L9ibt7qe P42LyXfkpVFm+gIht+C8iUbNqWw8inDVAEsJ/6YGdhVO2AA2M3mXqVYXHoWKqptk brWlcYT+f145apwHUjkB3BL1x9Gtt/oiQaSKJL7jUWNpiCsAmeMrgjVdrUC+XthN YhZGC3YRy+mEhAXFWkdqmKf1yHm3ulRan3gELtajnQCBsfXy36FcxINXdZ0hUJ6J w/DyScw5NXKKb1UQKtn8mOe6MK1F9kZjLbn6WOHv4npMzN3DX+zezHkrTTgzvKFO KmlgjsgVFQhKhF4QZ8LtSe9ZkzIYXlJvpQQljPmWjI5wHJB/ZgwuTKvt0+PGYF0Z g7dNPPnrPRuB =7YYG -END PGP SIGNATURE-
Re: Sentry for Debian services?
On Thu, Dec 26, 2019 at 12:08:40AM +0100, Bastian Blank wrote: > I don't think we already have a Sentry instance for Debian services > running? Are there other services in need for a Sentry instance? > > I looked at the install documentation[1] and it tells me that I don't > want to run Sentry myself. Any takers? > > Another option may be using the hosted solution, which they give away > gratis to open source projects, which we might be.[2] Caveat: they recently stopped being free software: https://github.com/getsentry/sentry/blob/master/LICENSE Some people have started forks, but I haven't tracked development there. This said, I'd say feel free to use any non-free solution that might help your work, as long as it doesn't become a required part of Debian's infrastructure. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Accepted staticsite 1.2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 19 Dec 2019 18:45:37 +0100 Source: staticsite Architecture: source Version: 1.2-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: staticsite (1.2-1) unstable; urgency=medium . * New upstream version - Significant code and feature cleanup - Requires some porting on existing sites. See upgrade notes in NEWS.md Checksums-Sha1: d02312e5f6840a931d799b12b54d4e4aebb363c8 2082 staticsite_1.2-1.dsc 8d60ce0f90c394d195916204566370fc40758c07 3153038 staticsite_1.2.orig.tar.gz aa626ed5fc5a9e35c1ee8e4120c256810704b02b 3380 staticsite_1.2-1.debian.tar.xz 9b976ca285a568d9f958526a3ecea86fbc21fb82 7062 staticsite_1.2-1_source.buildinfo Checksums-Sha256: d7f4e7d2ed77dac31b2f7e5e5b8e9d799e86d09aa9839ddb873d57bd32aa2505 2082 staticsite_1.2-1.dsc dc385baa96f63c8780db0adedebc63cfba1968e637c0d7258e4a5e470ed912a5 3153038 staticsite_1.2.orig.tar.gz 946de2e1ce5786a79013a3a53f2b02b9549d93370713f886addbc2aa6a655e9a 3380 staticsite_1.2-1.debian.tar.xz f197e2c571862bc6170e7465d0dfa225548bdf742b9a74b902f7965b4a5b1620 7062 staticsite_1.2-1_source.buildinfo Files: bbd3366cec50a324f528424b79c70c57 2082 web optional staticsite_1.2-1.dsc 8e9ee78860599f539271bbf88803000a 3153038 web optional staticsite_1.2.orig.tar.gz 105d273877b0a079dd1dc2fbfb3ff3da 3380 web optional staticsite_1.2-1.debian.tar.xz de2e146c7041da5e67d3e406cf5eb3ef 7062 web optional staticsite_1.2-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl37uokSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+5PwP/3eG5Rp+EFZ0+qtrNVbAJrVWq5w3ErDd GjblmmcLVDQyhX23M1X3eXpRU5+PSKbbN6XgNFzaQqp/AqvlnbWHj6JEVuqrzkXG IZO2xFXPhpxnPRH6OJq3Z+9NWLkmSio9UZmnRN9eCD8sOBAcL6ABVFh0UVEp498Q Zk9PcCIa0JDum3vjLqX3XQzQPPTY31d4R1VNswhdZ9nXY2xBAe+VWM/6h9099C3e Xwyx3pTJlte3Jo0P87aE+BXG56KbbkRitVtkPhiNsL87T0TtqDO8XcRqA7f2Li7q GLsKSXD3nDhOR4xNCzqCEhLql6YPsSkkdoZogAQk0ccNo2mA3RxyHqCaz9QXwHXv d4qmVTXvqCRixy/0nWFIAL8JU0zynVB2qXJPqQQzGX6C2A5PouOAxAZo84aMqQuQ zzHr6QfhO0mfAkfbwkmLVGJ0hpafFrxjtf5xczoSgYCUh19nzA52xFDpbls35mJQ V4fUpUrK4Qvo9T+79JOtcM6FmClxLTS1Rt9ZfFaObI7z6VylGnxREzKYAXMUvHAC UsKARE5zlF/MAQny+Ij1LNO61IzVgdX1t/QrEECl4+1PsJgMhQdKqiOTvTkppf6f LzNkrjir/S+2l1rYa42r4H8s0OUhZo7bYKxrMU9L6oNeAE1xQKmN/Fxhew0LXj2a mY03oVmjcPwi =AoeB -END PGP SIGNATURE-
Accepted staticsite 1.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 14 Nov 2019 17:43:31 +0100 Source: staticsite Architecture: source Version: 1.1-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: staticsite (1.1-1) unstable; urgency=medium . * New upstream version - More 'Feature' features and documentation - Reuse unchanged contents in build directory to speed up build Checksums-Sha1: 29802191c8137c1695b18afe09edb500f876aaff 2059 staticsite_1.1-1.dsc 957ca57c392fbc3df4b0d72b48dc0ae308844087 469023 staticsite_1.1.orig.tar.gz 868b8bf04c02fdc184b841aa460147bb37f5467d 3320 staticsite_1.1-1.debian.tar.xz 3e672e1e8771dfe25c2c214ad5554c0f84fd379f 6880 staticsite_1.1-1_source.buildinfo Checksums-Sha256: 9bf8d2af682841cd7de8c8f1dcbb465721b948a020c8575f12cf9830cbf8ba4c 2059 staticsite_1.1-1.dsc f1a63021bea3baba4156ebbcbf6b27397f545d10f28714d369c0123ea44500b7 469023 staticsite_1.1.orig.tar.gz 9188f3da54f71f9ebc281ce3d57fd728df41f933d26f11ef0d269c2855203027 3320 staticsite_1.1-1.debian.tar.xz e2fce8eebb1f45ce72435fecde493df7525c3990496188530f795b9d11863da8 6880 staticsite_1.1-1_source.buildinfo Files: d918cd77c9cc4817af89d7d97f4e1943 2059 web optional staticsite_1.1-1.dsc dcec552aebb570874c86f35ce461675d 469023 web optional staticsite_1.1.orig.tar.gz 865fb126f87d92f050f1c2413bd0361b 3320 web optional staticsite_1.1-1.debian.tar.xz 42b8a2c864c177ee4d52979505d61a18 6880 web optional staticsite_1.1-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl3Om8USHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+KlgQALrcNgdv8L/GzD/KVlp0nmsu7rB4iDpI uyC7KVxLoV/5VniE+X+vBY+nnrUN82nfwiIotPxgm5fJV2RF8yqv94HqmJ+OjUFv 42mHTd+sMEbLH4auNjsb9UXnTMy96LKCb9aofHTFNFtgP0xctgpLcQhkFxu/patG WEHuWG97NSnJl3PEv5yEGiXDZPfndKj9eqlswdMRNUUiA92il7JSlcB0H6gTz7B9 3Talc3r/Qeu1LpC2x70wZ0lKDptegywD43kM7YtWEUp3b4JchJfd9VKQPprwmM50 2lcuJpNzSL25IjJGrsKnRkvEhkEOAN1ol8saDTyNwlhkX5g4hdfxNk/aA5uMvoSq Xb6azMIKjQDFteZ3lMOqh5jlY+SU6BCepEFOmsBltj+I7GzvEaIPZSxYQd9Gw5jw fOVE6neYI/w8IPIAEmGKDE4S0reA0VAXvtqC4ROqQymfSNFYJSwJJvqrDa50fuO5 6wlstDZRmkjNNYTLikY6KFev8qADVviInAEn8OQRNPLzTHrvPag8v58u7AU/RKDd vg+gL44sv9kLn0lJ7+NJ6dsfOKkM7tXS7LZycHvPu8n+80rkAm5bO8kdj83HnUGQ PVHWYfGTWEeVaK8vaYOPzdro3is08aG1fkWbLWSWGzFeqSKJPHbvu+9B1vtDlQf+ zY2wuZgGhDg0 =naCZ -END PGP SIGNATURE-
Accepted staticsite 1.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 03 Nov 2019 21:21:54 +0100 Source: staticsite Architecture: source Version: 1.0-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: staticsite (1.0-1) unstable; urgency=medium . * New upstream version - Big clean up of code structure - Support for site-specific pluggable features - Implemented data pages to provide pure datasets as page sources - Cache rendered Markdown to speed up site rebuilds Checksums-Sha1: aeb5279920f6ccaef56f106ad4e391748f2889b3 2059 staticsite_1.0-1.dsc b879def2a60dc0db6ac162dc71793b86b5d50247 463735 staticsite_1.0.orig.tar.gz 58c823d7db60b071fe8d5cf43ddbbad828c310d1 3264 staticsite_1.0-1.debian.tar.xz 2ba9001d3a7ad285313432f8243676d26c86bc76 6880 staticsite_1.0-1_source.buildinfo Checksums-Sha256: 0c5812dabdc84313dd79be31b078c23207610cd55721f447c398792d1e7da10b 2059 staticsite_1.0-1.dsc ad2e2a47cf89b02ab6889fb7ec17511988048f982f7d409dc9a4078b7cb252b8 463735 staticsite_1.0.orig.tar.gz 13ed4c12fa3217f8de165ecf515c20cc68dcc8fb31d9206090e9ef364efeabef 3264 staticsite_1.0-1.debian.tar.xz 488e40eed2fb298c2153ca34ac1f07820aa2cc9c98e966f1f838161b56a2035d 6880 staticsite_1.0-1_source.buildinfo Files: 4dac6032959c60d4dcd7e5dea0e53774 2059 web optional staticsite_1.0-1.dsc f4a2a597371e7ffa400bea1c2b6ff9b6 463735 web optional staticsite_1.0.orig.tar.gz 2f9b4e8b4134fe901dbd270cef56c767 3264 web optional staticsite_1.0-1.debian.tar.xz bb8f7cec86ed6a6206092b34494c19d7 6880 web optional staticsite_1.0-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl2/OLwSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+uHAQAJGEC/W5iN+jb4arkcbE7dhTvM0n2PSi sf52+DiX48iIIK6fonUUmllyrHEMMt1fWO1tQ7DhIHDbCbaCNjcORicY610Gpu1c HcSBtYYuZbHBboZcaRdnItXVg1UIJ1ljPDwdp5Wiq080qg1nkC5sMkmp9NMqbgme hgKTXII2uv46CuNodwHTbZGd3L1LEs35Pp5ic700GiiYc/Y+fbe1rCY+q7YpqS+X QVXrNj420xsxuvqoMjrgAX308eof5tgsV/A910ViGOYG2WtOMQnk9TuqysN1XdT1 AiDSWXIkHMG1j9rUQI1sLKtIA5br3A5aG63Ca0xoF4GCcIckdHrP8CRBK+8oTPYB 7GZnXjtNGwaFHPUTy4zc/20Z+7OqdMUYslja8QKGZw8kAN26wZlBXDJu0b6mBKak nxzYmfZu6Q7y2BsmTREAkCIGYjk/3Otah4R3WrJ3NkCQkLZzDCDxWClPKItJJRQD NKZFt1qFv5rtlg75cQrQ4BtXK0YEFhujkCuwylpJ7qrLYkD2LrjtCE4keG0BnSZE nCGQ2VE8S4TY7LFxHYTxpaGEYq8Cd+VDkS87IzaYChkO15Gqd2PJWd55hUDgYA7B A3CiuydNzh6Gnilko6fFREHE8ZQhB2zhbFK3lqSPOv1Gji0JXdnjGJuI3Aazjt1C VNqQ5wVIsB9G =OieB -END PGP SIGNATURE-
Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]
On Tue, Oct 22, 2019 at 09:58:00PM -0400, Sam Hartman wrote: > I think we have about two weeks left in the review period. > Just as a reminder we do need comments. > Even if people generally agree, we do need at least a few comments to > that effect. I like the current proposal for a default suggestion for how to lay out repositories on salsa when one is not working with a team and one has no better ideas. I think it would both ease the path of people[1] (re)learning debian packaging, and of people[1] who can do packaging and, having no particular needs, like to stick to standards to ease further work through uniformity. I liked Ansgar's concern about the standard risking to become obsolete. As a recommendation for a default layout, I think there should be a way to keep the recommendations aligned to current project expectations, and I'd like some upgrading-checklist-style document to assist in keeping things aligned. Hopefully the recommendations won't change too often, or the effort saved by not having to explore multiple options while setting up a packaging workflow, would be spent in keeping the workflow up to date. I have no particular ideas about how to keep a recommendation up to date, though I like the idea of having in Debian the possibility of doing that a lot, as I see it valuable for a broader range of things. While over-normating things in Debian would stifle its valuable diversity, I think that being able to recommend as much standards as possible would make it much easier to navigate that diversity. Enrico [1] like often me -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Rethinking tensorflow build (taking shortcuts)
On Fri, Oct 04, 2019 at 06:25:21PM +0200, Samuel Thibault wrote: > Interesting :) But then if one wants to add some files to the software, > which changes the dependencies, are we able to insert it correctly in > the build process? Being able to change the set of files to be built is > part of being able to modify the software, for it to be free :/ My understanding is that the preferred source of modification will still be shipped, only with the addition of the preprocessed build instructions, to remove the need free software that is not in Debian. If someone wants to add things to the software that change the dependency, I understand, one can regenerate the build trace with the build system that upstream uses (which is free software), and things keep working. Unless I misuinderstood something, I quite like this shortcut :) Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Bits from the DPL (August 2019)
On Tue, Oct 01, 2019 at 02:32:10PM +, Holger Levsen wrote: > On Tue, Oct 01, 2019 at 09:57:38AM -0400, Sam Hartman wrote: > > I'd say it is a consensus of those who prioritize participating in this > > discussion enough to do so, consented to by the rest of the project. > I'm sorry, but I disagree. Silence is not always consent. I understand this is why we have multiple rounds of discussion with summaries inbetween. I personally do not see the length of discussions as much of an issue for consent here. My main worry would be the level of potential heat that I need to accept I have to deal with, if I choose to participate in a discussion. I notice that it takes me a significant amount of self esteem to send mail to a debian list, and not everyday I have it. The thing is, if people generally approve of what I write, the feedback I usually seem to get is mostly silence. If someone, even just one person over many, has an issue with it, then I get criticism. If I say something that 1000 people like and one person hates, the net visible effect in my inbox is probably one angry reply. I think this could still work if the criticism were polite and constructive. Some people in Debian disagree in a way that is pure pleasure to read, as they bring new scope and possibilities to a discussion. We however have frequent examples of feedback that can be very harsh[1], or passive aggressive and not really constructive, and I need to accept that if I post to a Debian list, I expose myself to that. So, as long as long threads are summarised and the summary has a round of review, I don't see a problem with mail or thread length in consensus building. I rather see a challenge in building a discussion culture where people actually feel good in participating, both in reading, and in writing when they have something to ask or say. Enrico [1] recent examples off the top of my head: https://lists.debian.org/debian-devel/2019/09/msg00365.html https://lists.debian.org/debian-devel/2019/09/msg00366.html -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Accepted dballe 8.3-1 (source all amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 30 Aug 2019 10:33:57 +0200 Source: dballe Binary: dballe dballe-common dballe-dbgsym libdballe-dev libdballe-doc libdballe8 libdballe8-dbgsym libdballef-dev libdballef5 libdballef5-dbgsym python3-dballe python3-dballe-dbgsym Architecture: source all amd64 Version: 8.3-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Description: dballe - Database for punctual meteorological data (Command line tools) dballe-common - Common data files for all DB-All.e modules libdballe-dev - DB-All.e C development library for weather research libdballe-doc - documentation for the DB-ALL.e C library for weather research libdballe8 - DB-ALL.e C shared library for weather research libdballef-dev - DB-All.e Fortran development library for weather research libdballef5 - DB-ALL.e Fortran shared library for weather research python3-dballe - DB-ALL.e Python library for weather research Closes: 793229 853367 871272 934814 936368 Changes: dballe (8.3-1) unstable; urgency=medium . * New upstream version. Closes: #853367, #934814, #793229, #936368 - reviewed and extended stable API - significantly more comprehensive python bindings - added dbadb --varlist * Added missing build-depend on libtool, which is called explicitly by test scripts * Deal with gcc7 symbols changes. Closes: #871272 Checksums-Sha1: 39c8a6859c11d8a1d8fce06336235a3dd0183f6a 2487 dballe_8.3-1.dsc 03cfc4bcd1b9b9c2cba64780aa42728bfaaf7266 1569741 dballe_8.3.orig.tar.gz 2533f0805fa74a9ebad3c1dd4c3719a225a40259 11192 dballe_8.3-1.debian.tar.xz 11377fb081052a510e031bc112938b5aced65d7b 40652 dballe-common_8.3-1_all.deb 189b55b81a0959022e52bfd3437bd32113bf7844 658100 dballe-dbgsym_8.3-1_amd64.deb f9aa266b85b4ce5036d5c1b5cd94bdbc61dcbc34 11047 dballe_8.3-1_amd64.buildinfo 2252166ed20c1bacc257142ff3490f9c3813b0b4 54920 dballe_8.3-1_amd64.deb 6d1b67e02a380bd6cbe811e84d3c5bc17285c975 738144 libdballe-dev_8.3-1_amd64.deb fc616acd11753b0b46c039e5ce414133d02591c4 732360 libdballe-doc_8.3-1_all.deb 7d4381f355ddee9057ecc7221a264937b7f5fa0a 10331760 libdballe8-dbgsym_8.3-1_amd64.deb a3541a82d4ace4ff5598d3635cb58b86af6c68c1 498792 libdballe8_8.3-1_amd64.deb 597081567f3985a772d638ed556e1120e4fff6ea 62928 libdballef-dev_8.3-1_amd64.deb 6db3ef23ba6ff2db4a996ba02e8f53cd1fc7 134412 libdballef5-dbgsym_8.3-1_amd64.deb 0eeadeef06c0c0d08a42877c5d3614cb98f637f9 23276 libdballef5_8.3-1_amd64.deb 4614f783397e42682bdb8188ee282fab1648bf1a 1909664 python3-dballe-dbgsym_8.3-1_amd64.deb cc4b50e37a2c180c45c877579922f9065b3dfa33 156872 python3-dballe_8.3-1_amd64.deb Checksums-Sha256: f31c4a61d8e0897210dbd6c3e8be08193d0912f84de0921a3ce1013d9cc8cf4c 2487 dballe_8.3-1.dsc bac6c3bfa128947d1fe5b5c44fe3f304313ee98f40404f4d36fb56be40de1298 1569741 dballe_8.3.orig.tar.gz 7483debdd8a96a4cd540a4bbd1ec450b509273e40258e6d5200b878c283e41ef 11192 dballe_8.3-1.debian.tar.xz 99880d59269da31a2874c35e80440873f6729e1bd843a98a3c25a71e52f2 40652 dballe-common_8.3-1_all.deb 7ce739def8ab9331a5df03a502257a6a4e0e448e22c9bd2eb980d449dcb194fe 658100 dballe-dbgsym_8.3-1_amd64.deb 7b76ea5f44598d62ebd55dd91f20615ca2788a27739b9f0399037d40e053c215 11047 dballe_8.3-1_amd64.buildinfo 180a51e3bca5fe3eea3e68514d8142bf3692ba96b2762dd532cd85a96539dc2f 54920 dballe_8.3-1_amd64.deb 7f444857017c07dd5d83d3d1a7e3ab63c76c0c61b1dc9141a867bbd54b9e5680 738144 libdballe-dev_8.3-1_amd64.deb 368db0826e9de1f32454081a41e312b1d8461b0a3c3e0a0f27f958901bf4 732360 libdballe-doc_8.3-1_all.deb d7cbeb401b979e26d4a6db73f5f9524042fe41487bd647f8685360d55f25a723 10331760 libdballe8-dbgsym_8.3-1_amd64.deb f3e4d51d0e451258bc1c8b2bc8e0343714aaea43e439d836c5010af88a9ded6c 498792 libdballe8_8.3-1_amd64.deb 0469190d552ea35feafd43128b0f2f0e39e370dafbe1fee974f7301089897d8a 62928 libdballef-dev_8.3-1_amd64.deb a07abb54f0ca5b81848f88a4a8be53aa5a6efe4a74262aef545f126734df1d6a 134412 libdballef5-dbgsym_8.3-1_amd64.deb 5dc821beb4a6b643cf62bcaa372d9bab84672b0708f8e32b25e1a655b7aa1e36 23276 libdballef5_8.3-1_amd64.deb 0f564961456b91a065bbecb6b2741603c96ab5dcddc422634a000c1cadab0719 1909664 python3-dballe-dbgsym_8.3-1_amd64.deb 26eae2dc3b5442c4cf03c86fcb9ec28c0ae2563b27c605275c1e0f754bc05489 156872 python3-dballe_8.3-1_amd64.deb Files: e041853c7e6770c1021cbc5bc1cfa13e 2487 misc optional dballe_8.3-1.dsc 4849138e3739467f78fe61d05408a656 1569741 misc optional dballe_8.3.orig.tar.gz 09c4a0509708cb17dc62430e830c6db7 11192 misc optional dballe_8.3-1.debian.tar.xz d1a1b44374aa85fe06ca57f4bd01a0a4 40652 misc optional dballe-common_8.3-1_all.deb 11c10b3a3115d3fb588dd598e3786ea0 658100 debug optional dballe-dbgsym_8.3-1_amd64.deb 3379dd6f63ea4c5be71a3750f846f292 11047 misc optional dballe_8.3-1_amd64.buildinfo 75f3697b37387f5fd0b39a7d0cb93f1e 54920 misc optional dballe_8.3-1_amd64.deb 576328ec9b306cf52be55fb2683586a7 738144 libdevel optional libdballe
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On Thu, Sep 12, 2019 at 03:51:57PM +0100, Ian Jackson wrote: > Well, thanks for the rebuke. I hope I have clarified my thinking and > please do the same again in future. (Or, indeed, right now, if you > think this message is still frightening...) I wish you could learn to *listen* first, then maybe argue. You still proceeded to argue at me without really asking any question about where I was coming from. Sam showed you how the situation in Debian seems to be different from what you understood, and your response was not to acknowledge, try to understand, and map the current status quo, but to consider of a GR to force the status quo to fit to your expectations. This cannot be the discussion culture of a group where I can be comfortable working with others. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On Thu, Sep 12, 2019 at 02:07:52PM +0100, Ian Jackson wrote: > I think this does not demonstrate that I am wrong about project's > overall opinion about this. I am confident that a GR to forbid this > would succeed. For what is worth, I would vote against such a GR. I'm extremely uncomfortable reading what you wrote. I consider you one of the leading actors of the current discussion on improving/cleaning/redesigning default workflows in Debian, and I respect you as such. I see you keep pushing things with a strong cohercive slant rather than working on creating useful and attractive infrastructure to make everyone's work easier. I wish this work would be grounded instead on an acknowledgement and acceptance of the, imperfect, diverse, yet still valid status quo. Thankfully I still consider it to be so, with the exception of the occasional frightening cohercive twist in some of your mails. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Git Packaging Round 2: When to Salsa
On Tue, Sep 10, 2019 at 08:13:15AM -0300, David Bremner wrote: > I'm also not sure if this is a completely rational reaction, but I'm not > currently very comfortable with any DD being able to make global changes > to thousands of git repos. I think we haven't yet developed any kind of > social conventions or rules about when that is appropriate, and we don't > have much project experience with it. That's possibly a seperate > discussion, but if mass changes are the justification for some other > policy/norm/standard/reccomendation, then maybe it should be discussed > first. To me, given that the recommendation is optional, and doesn't apply to teams, it doesn't seem that much different than turning the low threshold NMU[1] idea into a practical workflow instead of a wiki page that one tends to forget looking it up before doing a NMU. So I personally read the proposal as: - besides the option of adding my name to [1], I can also choose to put a package in the debian group in salsa, where it fits in a well known workflow - if a maintainer has no better ideas, we propose this as the default workflow for non-team-maintained packages Team packages will be maintained in whatever way a team chooses to. Packages over which one wants more control will be maintained in a personal repo or wherever one wants, and it's all ok. For the rest, I think this is a definite improvement over the status quo, which I understand more or less as "do something at random and please don't suddenly disappear". Enrico [1] https://wiki.debian.org/LowThresholdNmu -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Accepted wreport 3.23-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 01 Sep 2019 07:55:59 +0200 Source: wreport Architecture: source Version: 3.23-2 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: wreport (3.23-2) unstable; urgency=medium . * Added missing liblua5.1-0-dev dependency on libwreport-dev Checksums-Sha1: 29d2c065375aeaa9f6fe47e1030c51e4d4c0d025 2122 wreport_3.23-2.dsc dab747d930d01089bf3c3349f37b550790378b05 5668 wreport_3.23-2.debian.tar.xz bf9efc369d303ed24e812a777322eb4c1c6ab46d 6871 wreport_3.23-2_source.buildinfo Checksums-Sha256: 2e536ad4f7263c7a64092e462457226cb643a9b94859dcd12f3cc67d2c71799a 2122 wreport_3.23-2.dsc 19a8e57401fbda5d05eb09da531032e535bf672f8ac173e50beec9c6d14d5f06 5668 wreport_3.23-2.debian.tar.xz 65c52ad90a5205325c35267feb1d2f982e897a7d53a454d75fb97f2b0928c60c 6871 wreport_3.23-2_source.buildinfo Files: 679c862864c93e9d768b0177d204e5c5 2122 misc optional wreport_3.23-2.dsc ff2ac1fa5fd0edd67259e295ba27c7f0 5668 misc optional wreport_3.23-2.debian.tar.xz 8c7696cc838ad86dfd5a3e24c5c70e03 6871 misc optional wreport_3.23-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl1rXk0SHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+tqEP/1jlCLbECXwjtSP0Hg2becNF1iVtLwKq AMdRlSHTV3fXb5EVwqXs7SBNkZfNmd8omR4pTdfZh4uf+wmDdLYgW+El8Latttgn UD1WWwuDLakUksLbdBDhcr0Cw7KZDR0Q016J+++br0WX+Ussp7E9yCKzrIAIoqd5 bZ8WAgcsbG4c07y2RbvRktrMK0oL1bejmDpLmieCxADP+IRSP34OYJcaSZTomJ9R cfYOc67TpaF4nn34e/iuiYmH6XEsdH98sVqYdMYKVySeAi3wHPR5XakQChDdaNl7 tM5uDzqYgq/ThBAhMteKX5lX5a4J0XI+/EM2IdVSNTzXKUXrWgKHUR7C4GyflLL+ QCZ7OYy2z9ruvc4dtgMTVGLxQMKYbD+daoJi+dI9xgafXI9iNOeq8Nhg2tgfeH10 I7nZP/2WE3vW/yl3eln1ZvUluQWzgSpa6Y1a9h8hrnJ/HqINqSxGbeorzHrcjiEH Kx9gG53dNudiW8rSRzvL7EyPOp+S/459mBT+pQncv0jiDrNkpbLWo6KloddLHs9Q T5k5n/GA/4L4w8qzft2fFDzJNYI0pDtGEfeT1f8y5cqoXpV43JzPnYqPwGJ9ugr3 H0yEDGGwxl+0xIl0VzljElSSwi7OyKV3U2AxCsl3r8gYsh1BM0OBq0neQHCgo3Jd gJtKsX/tua8l =HF4U -END PGP SIGNATURE-
Accepted wreport 3.23-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 30 Aug 2019 18:53:13 +0200 Source: wreport Architecture: source Version: 3.23-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Closes: 938832 Changes: wreport (3.23-1) unstable; urgency=medium . * New upstream version - Fixed build on 32bit machines * Depend on python3-docutils instead of python-docutils. Closes: #938832 Checksums-Sha1: d84feb84af071e6d773d0ef38012c2cc0e4f96c8 2122 wreport_3.23-1.dsc 66f1df77f3c14bf74f616a952cb912b080305be0 2494486 wreport_3.23.orig.tar.gz c6b7fb7554af05229ba8d9419a93367ff3fdf09e 5652 wreport_3.23-1.debian.tar.xz bbcc56e2548c787e4ac0e7dcd6354c4350058360 6871 wreport_3.23-1_source.buildinfo Checksums-Sha256: 179d5aa0eb2bf4bf72d2a2f1ca6673956beafbbc26f4bf86b2399e5219992bf7 2122 wreport_3.23-1.dsc 64989e2635f36b08e415e82d28d612fbff4dd815ce8a673a885be1fb593e4e01 2494486 wreport_3.23.orig.tar.gz 62323344df15a096486d23d46bd6796d00647da1a800cccd0ba3fe0650d6ded6 5652 wreport_3.23-1.debian.tar.xz b931f817510688c2ae31297d9b972f4fd740247f65f8e86817a7395fd479761e 6871 wreport_3.23-1_source.buildinfo Files: bfed0808f3cd4ad8d2efe2f86346b25d 2122 misc optional wreport_3.23-1.dsc 6183ba8a4634f098cd2be82190af9e18 2494486 misc optional wreport_3.23.orig.tar.gz 29e782648efc0716a3acc58e26347de3 5652 misc optional wreport_3.23-1.debian.tar.xz 502a67496b628f2d967ee9e912689f0a 6871 misc optional wreport_3.23-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl1pVb8SHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+K7UQAJ21F/AO9QHCqopCXthsoBng+OMWp+sG ciKGT0lw/6HT8vQkA2WGdfKOZUotn/bDO4tqrLHkFTQNiDfVF30155uAIvGGkpWZ exAbzBG8XMsbSBNajbtnqKmvx3NqqycDI03gF6A/IGZHJ0chlgBtzdz6Aj5R8X84 2aP6OR8ye4XIKxEe0trKskGArgEFbFPpUpzZ/sbLCBn7RXlTSAZYfjzVpRgCm9KA J3ErkMYZsEZfZsy01PrRzKN4/G7zoykgZwUuSNbV3Ubu0W9vDFOLvf7oZBaNhRn6 FR+ISi+qZtLnIvmg67K3VYh7YPDPuGaUAjdb9tLEwpYEbZogmgKmxZL9NzG9Ay+2 xVmGFcnQTAAatNeNiBwqdkUQkwR3mASf15JMF6eZY2j6I/q9l+THJI6BC0jaCitG Ck8XOJJYQSRNw3HkTvx8qZln5dtG4Qfb5OplnJR9yE+h5F5DuT/YIfZxEvAzX8yl H/zToi+90bnMoxmM1/L1qMf1L7ebIRaOf4sanURZ0hbZUwZ9u+5zp5O6iV4018aZ bt+7SMb0XeUHfxtymagzZQMixMRf0KtTYHooliqIgHx1yq70mrdQNzJ7nS1GqJle KJ/0tMGKZYlRsOCv6VuFuAc5vT3fWUg/myIWEgkAp8iOgI9BLTZPYo4QeQtPkuML hSztno70NR7l =h1sP -END PGP SIGNATURE-
Accepted wreport 3.22-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 30 Aug 2019 09:41:11 +0200 Source: wreport Architecture: source Version: 3.22-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Changes: wreport (3.22-1) unstable; urgency=medium . * New upstream version - python3-only bindings - improvements to BUFR encoding/decoding Checksums-Sha1: bca067e357c819b9ccf2071e65d59794e89a2312 2121 wreport_3.22-1.dsc 624bce24f5e8ec00fc6a49c6d65369ef148f7899 2494516 wreport_3.22.orig.tar.gz 9c5068d2f8d2cdf85edbdb3594d60c1c804971e2 5612 wreport_3.22-1.debian.tar.xz 0e24a0dbed1481647dcb5125f95e82733826023b 7169 wreport_3.22-1_source.buildinfo Checksums-Sha256: 76ef5a2e94fe012e31cd8b435439a465148e7619bee20b59631eea60b5d7b40d 2121 wreport_3.22-1.dsc 6c14618b3cba2509487def90ccf568a4faacd96fb9a4f3d8bc394985dcebba87 2494516 wreport_3.22.orig.tar.gz 301ac2f7a21e96baa5d70bf915169bf5b2d50aae3afdf339b2cbf1da399e7b38 5612 wreport_3.22-1.debian.tar.xz cae52ce661fd646216fd228d58db4df6ba066bf795f0c23b0d516478f51b46c7 7169 wreport_3.22-1_source.buildinfo Files: 7bc0c0e594e236dd96cb68de5abf3ab7 2121 misc optional wreport_3.22-1.dsc 89d9f319a593b18ad62472597e86ccc6 2494516 misc optional wreport_3.22.orig.tar.gz ebbe081ad347ed21b2c3c9601c948f55 5612 misc optional wreport_3.22-1.debian.tar.xz bd9f5a6377b8f42a3a578084c02e633b 7169 misc optional wreport_3.22-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEhmBP21FPcUU+TNNNhMw1v3gTTX4FAl1o3VkSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEITMNb94E01+g1cP/37FmCOEZPwfqPo5RaE6vq5E7HfkZ3T8 g+fYWXl6rWCER5DAZQCZgp6to3pNoz6vDr2nM4L5jFsYT3k0vu/j8uM55m78rniJ /mJNOj5kzW1ji9dDuzv44v+LEYT4gmQcnl4/oPtPCiEvBSWrvI3l/tAGpwK6JuTy RrQJJfWBvT0BWsVd73qVNeS+szVjeY3HfrxS4qlWuQt3v2XPoqgB3MQHtgGBX39a T+fUnB96U+vN1xvK5w9p61UrMS9BzkwWcsS9XK3aasEo4xCb7YX65KQF49cf4vSb 2SYnmhZGIXdGtPC7rKXCzlpMmoWQuoLTsDuDYQnuQE0xJ+5KR75Oj/hzhg5o1iHI +XC25EZ0ZLtLAE7qdo09WF5M1vFrGIVQr/wZLY/1xCl2rVXEb3RRP060yE7Dd2l5 2oPvcCjdxkR8cV4suwhzPCDk9CTZAF5qThI5Bepa4OxOgckMfz4RQM+Cj+jbwBtS uFBg4Au+dcjCyoeROGZuzR4shTQk3aS/8qU0nl3hSPIwc+7DPHdRJTqiGN3wPWAt 9IQ/rzAz+BuckGlJJg8sxnl6bPdGLpz0xuq7v609mhjyWclmujRd7YoeggLjZmMg Tc3Legh8SMqHlF7GVbECTXh7BJBfdLwAovqTDUZKcPXKej8j5QuXzD6Ck2Dirs65 1CGh9x9hgzEG =kDHX -END PGP SIGNATURE-
Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
On Mon, Aug 19, 2019 at 11:55:13AM -0400, Sam Hartman wrote: > Enrico> Those packages that use more unit file features can still > Enrico> ship an init.d script, but at least all those packages that > Enrico> just start/stop a service don't need to bother about > Enrico> maintaining yet another shellscript that bitrots dangerously > Enrico> over time. Here it is: https://github.com/Truelite/python-unitd It is a python library I wrote for a customer who needed to run X clients inside a web browser. It needed extensive process management to do so, and I decided to shape the library API after systemd's primitives, so that the API's behaviour could be trivially understood. I don't think that code solves the problem at hand as it is now, but it could be a basis for a systemd-like start-stop-daemon which can use python's asyncio infrastructure for more complex process control. > I hope we also support the case where we ship a restricted unit file for > non-systemd and a unrestricted unit file for systemd. > I'm imagining a common case for me: I want to use a lot of security > isolation features some of which may not be in the restricted unit file > subset. > But my fallback would simply be to not get security isolation, and I'd > hate to have to write an init script for that. For me, that would be solved by ignoring any directive in the .unit file that the code doesn't understand. Given that we are talking of replacing trivial init.d scripts, not of reimplementing all of systemd's features in a new command, I think that would be sufficient, and the debian or upstream maintainer can take the responsibility of deciding when to shift from the trivial .unit file to a complex init.d script. An alternative idea to all this could be to write a simple "compiler" from trivial .unit files to init.d scripts. > Thanks for working on driving this idea forward; it seems like a really > good one. I've been boggling at the dangerous replication of code in /etc/init.d and in daemon startup code for most of my professional life. I personally switched to systemd and feel much better for it, and even when systemd is not there, I see great value in the standardization of daemon start/stop behaviour and expectations that came with systemd. I'm not sure I'd drive this much forward than having gotten unitd published as a possible starting point, should such a base be needed: indeed, one can also extend start-stop-daemon in that direction. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)
[changed subject because I can't stand the old one] On Fri, Aug 09, 2019 at 08:46:18PM +0200, Simon Richter wrote: > I can totally see the benefit of using systemd unit files as init scripts > through start-stop-daemon, because we could have a common "open socket, > chroot, drop privileges" wrapper that way, most of the code is already > there (start-stop-daemon's command line is a descriptive interface) and it > would still be simple enough to fully understand in a single day. > > If I went and implemented the "API" by implementing all the features in the > man pages, I would indeed get the single property I like the least about > systemd: that its specification is always in flux. > > I am fairly sure it would be possible to define a more powerful API than > init scripts. Alas, that hasn't happened yet, because nobody is willing to > create a normative reference. Alternatively, we can decide on a subset of unit files that would cover the normal start-stop-daemon features, and like 80% of initscripts, and would be very unlikely to be changed anytime soon by systemd upstream, and decide that if that's all you need for your /etc/init.d script, you can just ship the unit file and delegate the sysvinit case to the start-stop-daemon equivalent. Those packages that use more unit file features can still ship an init.d script, but at least all those packages that just start/stop a service don't need to bother about maintaining yet another shellscript that bitrots dangerously over time. I even have a python implementation of most such unit file features that I can offer as a starting point, please give me a few days[1] to talk to one of my customers about putting it into a public git repo. Enrico [1] today's a national holiday in Italy: https://en.wikipedia.org/wiki/Ferragosto -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Survey results: git packaging practices / repository format
On Sat, Jun 29, 2019 at 09:18:11AM -0400, Sam Hartman wrote: > I think it would be helpful for both of us to describe ways in which you > find that there are objectivity problems that would get in the way of > presenting the data in that context. > > I think especially at that bof we'd like to avoid people feeling that > some practice that they cared about was mischaracterized or > misrepresented. > > Yet we kind of need one person to give a short presentation to get it > into something that can fit into a bof. > > So any help you can provide pointing at things that seem too subjective > would be appreciated. Trying to unpack my gut feelings, I think the current table intermixes the presentation of a taxonomy work to Debian as a whole, with an iteration of dgit design work. I'm currently not concerned with dgit[1], and I'm curious to see a mapping of the complex landscape that is Debian in this regard. When I read the table, I see "best practice" links that point to dgit documentation and a "comments" column with judgemental words like "clumsy", "competent", "avoid". Those are getting in the way of my attempt to look at the landscape. I'd like to be able to look at the landscape first, and take it in, and then, as a separate step, see what the dgit maintainers, whose opinion I actually very much respect, are making of it. This decoupling would probably also give those people who are using a layout currently commented as "avoid", "poor", or "clumsy", the dignity of seeing documented the objective fact that they exist and took time to document it by responding to the survey. And at the same time, could give full freedom to the dgit maintainers to be as judgemental of any workflow as they see fit[2], because it will be all well framed in the specific context of dgit design. Enrico [1] I'm quite dgit-agnosting. My currently packaging practice is "burnt out by a complex and changing ecosystem and trying not to do any of it if I can avoid it. Excited at what is currently going on, waiting excitedly at something sane to get established as a standard and gain clear documentation and simple tooling. Possibly, as little tooling as possible over a decently maintained upstream source." [2] you know what I mean, please don't take it as a challenge :) -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Survey results: git packaging practices / repository format
On Sat, Jun 29, 2019 at 01:16:28PM +0100, Ian Jackson wrote:
> The current presentation lists *branch formats* not *workflows*.
>
> Everything in the current page other than the comments and best
> practices columns is objective, but I see it as lower level than what
> I think you are looking for.
Whoops, indeed, you're totally right here.
> It would probably be useful for there to be a wiki page for each
> branch format which has a section for each kind of task ("modify an
> upstream file", "cherry pick a patch from upstream", "switch to new
> upstream version") etc. and describes all the different ways of
> achieving that taxk with that branch format.
>
> That would be "less raw" but perhaps is what you actually want ? :-)
Agreed.
> > I could suggest a descriptive wiki page for each style you identified,
> > that then the users of that workflow can add to, and can serve as seeds
> > for growing comprehensive documentation, if that is doable with the data
> > you collected.
>
> I can probably write a skeleton for most of these workflows. At
> least, for the most popular ones. In many cases a good starting point
> is probably a copy of a README.source from some package which actually
> mentions it, or of course the dgit workflow tutorial manpage.
>
> Maybe I should write one skeleton and then others can help ?
I'd say that seeding the wiki with pages for each branch formats could
both provide a link to details to take some load off the big table, and
create a space where the rest of the documentation can grow.
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
signature.asc
Description: PGP signature
Re: Survey results: git packaging practices / repository format
On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote: > I hope you all won't mind too much that Sean and I have privileged our > own point of view, in the columns which contain value judgements, and > that we hope to retain that property of the page. I have no problem with you making a collation of the results from your point of view, but I would also like to see some more objective presentation of the survey results, even if in a more raw format. I saw in your survey a great potential for documenting the existing workflows, and I'm having a hard time getting that documentation from the current presentation. I could suggest a descriptive wiki page for each style you identified, that then the users of that workflow can add to, and can serve as seeds for growing comprehensive documentation, if that is doable with the data you collected. The current big table might end up being simplified by having links to the detail pages. Thank you for your work on this, by the way. I'm really excited at the idea of a taxonomy and details of debian mantenance workflows! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: getting rid of "testing"
On Fri, Jun 28, 2019 at 11:38:36AM +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: getting rid of "testing""):
> > distro-info-data.deb has this information for Debian and Ubuntu, in a
> > CSV file. It has convenience bindings for Perl, Python and CLI, and is
> > also used by recent versions of Debian's implementation of lsb-release.
>
> TIL! Thank you.
See also:
http://git.trueelena.org/cgit.cgi/software/debdate/about/
http://git.trueelena.org/cgit.cgi/software/debdate/tree/debdate.1.rst
http://git.trueelena.org/cgit.cgi/software/debdate/tree/debdate
:)
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
signature.asc
Description: PGP signature
Re: The Difference between debcheckout and dgit and what they try to accomplish
On Wed, Jun 19, 2019 at 11:51:14PM +0200, Wouter Verhelst wrote: > What if you took away the necessary guesswork? > > Have dgit support a field in debian/control that, if it exists, explains > to dgit (and any other tool that might care) what the workflow type is. > This would require a categorization of all the possible git layouts, and > would initially obviously not support all of them. This reminds me of something that popped up in a dinner discussion a few days ago: mandate documenting workflow in debian/README.source no matter what, and allow to symlink that file to a repository in /usr/share/doc/somewhere/ as we do for common licenses. That way, there is a standard, machine readable way to detect standard workflows, everything is documented no matter what, common workflow documentation can grow without changes to packages, and people are encouraged to adopt a standard workflow, because they come already documented. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Re: NMUs: Do we want to Require or Recommend DH
On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote: > How do we feel about people making build system conversions when those > conversion make it easier to fix some other bug that they are fixing as > part of an NMU? > That is, imagine that a package is mishandling the combination of > systemd units and an init script. As someone preparing an NMU, is it > reasonable to move to dh compat 12 from some other build system if I > believe doing so will make it easier for me to fix the bug and verify > the fix? I see various scenarios: - if a package is generally actively maintained, except the maintainer is currently unresponsive for some reason and there is a RC bug to fix, I could understand frowning upon a build system conversion in an NMU. - if a package has bugs that can all be fixed trivially with a build system conversion, I would see no reason not to do such a conversion, even in an NMU. - a change of build system in a complex package would be more controversial than in a trivial package. - if a package has had an inactive and unresponsive maintainer for a long time, it would indeed be a case for salvaging. I could however imagine someone having enough energy to dust off old packages in the archive, while not having enough energy to pick up maintenance of lots of old dusty packages. I would consider the idea of salvaging+orphaning, like following the salvaging procedure but setting the maintainer to qa instead. - I'd say that orphaned packages can be uncontroversially be converted to dh. With a consensus of having dh as the default build system, and the understanding that some packages have good reasons not to use dh, I'd like a way to tell when a package is not using dh for a reason, from when a package is not using dh because the maintainer has not gotten around to it yet. I'd propose to recommend dh as the default build system, and document in README.source if there are reasons to use something else. At that point, one could look at README.source to see if changing build system would be an possible strategy for fixing bugs in an NMU. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Accepted wreport 3.15-1 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 19 Sep 2018 15:12:56 +0200 Source: wreport Binary: libwreport-dev libwreport-doc libwreport3 wreport-common python-wreport python3-wreport Architecture: source amd64 all Version: 3.15-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Description: libwreport-dev - library for working with weather reports libwreport-doc - documentation for libwreport libwreport3 - shared library for working with weather reports python-wreport - Python library to work with BUFR and CREX weather bulletins python3-wreport - Python library to work with BUFR and CREX weather bulletins wreport-common - common data files for libwreport Changes: wreport (3.15-1) unstable; urgency=medium . * New upstream version - Fixed Lua dependencies in generated pkg-config file - Reverted a unit test check that got in by mistake Checksums-Sha1: 85e0c98e1fd2946a16be9364dc8317ecac5c2886 2252 wreport_3.15-1.dsc 8d775b2f9aa3b21c0e2f9b8380ec02cfd96b709f 2181580 wreport_3.15.orig.tar.gz b07c96a84809e71a61a672cc2e7f31b3d9bcce17 5576 wreport_3.15-1.debian.tar.xz ba84a6386d5c8c7ecab422e3d5bcfce0dac35004 256496 libwreport-dev_3.15-1_amd64.deb 08d5abb4e3027b54afb110e7556cd427f92dc4c9 347220 libwreport-doc_3.15-1_all.deb 9e9c492f230e9c39ac4d1f6c5670a606ab72c8c7 2637592 libwreport3-dbgsym_3.15-1_amd64.deb 7d7e788a1aabb53de2644628edf707b23ec3b274 182736 libwreport3_3.15-1_amd64.deb d57983ded26115a97dd18e1c17d318b1cb64c313 167936 python-wreport-dbgsym_3.15-1_amd64.deb 9f9737cbb21e0881e910d2e27e7174ba61160557 26636 python-wreport_3.15-1_amd64.deb 29d4245ec21f787f049e900b5ef87a670847715c 340696 python3-wreport-dbgsym_3.15-1_amd64.deb 0b5f38fdbef24ad020cae8aceca7bd2ed0462b1a 26804 python3-wreport_3.15-1_amd64.deb 1df535a1f0c1f8e9f0baa859e53344e422d04a80 151352 wreport-common_3.15-1_amd64.deb 01e2044b94201041345b7e413b3c1bc51ba96b5f 9774 wreport_3.15-1_amd64.buildinfo Checksums-Sha256: 0596d0093c9452df16ca0fe109166dbfb3d37456497db102922806729dc57617 2252 wreport_3.15-1.dsc 96806d814e2e9484bba9c76ea288aba1ced2a950743ffe7de24feafb4723d78f 2181580 wreport_3.15.orig.tar.gz 39051a339672a98cae94fcea9a1d50e616ade719a00586466b184bfb0258561b 5576 wreport_3.15-1.debian.tar.xz 9ed250cf89f96024d8e6def6bfba24212de4d1d284de3fdab31eaacc8e627f20 256496 libwreport-dev_3.15-1_amd64.deb 85aa433b82f4dee35d7792b22ec83034efa765491541032e64d418c40e3eca0d 347220 libwreport-doc_3.15-1_all.deb 945b552e2415ed3024ebf02c695f494f63f4c1d316d3ecd5e81ab2abc1344ad2 2637592 libwreport3-dbgsym_3.15-1_amd64.deb 5ad64984784a057ec08af4ce521299aceb4b95df37f9f5e798df819b812be6dd 182736 libwreport3_3.15-1_amd64.deb f04a5211baa189eb01f6f28a077ab91825407ccb6d301ef50307f9d5a6c27a15 167936 python-wreport-dbgsym_3.15-1_amd64.deb 12951d9d76e2c74ee53b092475d35f6b1b88e43634990787cfd8774ca8c18edb 26636 python-wreport_3.15-1_amd64.deb 6d75d160bf9acaade23ace3b4dd61574055e06b4e6a6fad51829bac6161cc59e 340696 python3-wreport-dbgsym_3.15-1_amd64.deb b0f966d55b86f1a5c7f6ca0aa4834559ddd53534085c44c2872f71212c5245a6 26804 python3-wreport_3.15-1_amd64.deb c83692264a867a89d8673e3c21c184d319b1a927f0b48d6d60c4fc31eec9e413 151352 wreport-common_3.15-1_amd64.deb c53c9dac39e4bd2927d718f1052d73b250fdba4f0350cc477882cc8183b96fbc 9774 wreport_3.15-1_amd64.buildinfo Files: 15d8aba72ab8ace04773ab195b3371a1 2252 misc optional wreport_3.15-1.dsc 9a8ea110f3c47c8e3393e005727e21e0 2181580 misc optional wreport_3.15.orig.tar.gz 3e8b3da6106fdd9fcf59a826d064b5a3 5576 misc optional wreport_3.15-1.debian.tar.xz 61537d3fdcf06560647b779723fa 256496 libdevel optional libwreport-dev_3.15-1_amd64.deb 199c2a083b5044db51988a7bc0df35bc 347220 doc optional libwreport-doc_3.15-1_all.deb 89dcd685fa07f16ef85b24f37687302e 2637592 debug optional libwreport3-dbgsym_3.15-1_amd64.deb 3a7fc69e0d214b781bda9c3f89a9535d 182736 libs optional libwreport3_3.15-1_amd64.deb 34c8f4479ca593eea6474009a504cc8d 167936 debug optional python-wreport-dbgsym_3.15-1_amd64.deb c98f80b69a3d60e61d66cab435867b0e 26636 python optional python-wreport_3.15-1_amd64.deb fd9b01a046c21401ad0cb46205e425c8 340696 debug optional python3-wreport-dbgsym_3.15-1_amd64.deb cbeff5e16bc19ffb5001e34f2ce42fa8 26804 python optional python3-wreport_3.15-1_amd64.deb 14d3e6850c2d321bab4107846b0c1ea8 151352 misc optional wreport-common_3.15-1_amd64.deb 576914e5a8620ea37f9ddff4face0e5b 9774 misc optional wreport_3.15-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEECWOFX2srg4dSrhhPiHMvzA1Tr7YFAluiTvkSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEIhzL8wNU6+22zsP/2d7re33xHEDwxmPGF56RGyxDXJ3k4Cx o4U4TVbLsqiOtr6LUlw4iT7B/hqyJld+7fmiqHn64LrIgyHXu/zl2dcdEMK05eR3 h3ZtfYZ9DrR3JJsphqu/5nFJ3EU7Y0rryPhFvkicx2jamh4vnBCW9dkFSyIVoSpD tzhyPPfHJtjYonxO8R1cWwgcPYU+AKXaRYx0/xDuSoCTnt8wr1hzX+JrcyifkOg5 hDLK/A5Kzrj8Hu4DSiSq8KYA4IB949oO5VBz1XVAGuAQoNofyFxzVaP8NanPGjZK lU9LRWHq4bDeyJw/YepqAc50JqWC3tIUl8NBtnY0qCiaweUmg300tw
Accepted wreport 3.14-1 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 19 Sep 2018 14:13:57 +0200 Source: wreport Binary: libwreport-dev libwreport-doc libwreport3 wreport-common python-wreport python3-wreport Architecture: source amd64 all Version: 3.14-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Description: libwreport-dev - library for working with weather reports libwreport-doc - documentation for libwreport libwreport3 - shared library for working with weather reports python-wreport - Python library to work with BUFR and CREX weather bulletins python3-wreport - Python library to work with BUFR and CREX weather bulletins wreport-common - common data files for libwreport Closes: 904714 Changes: wreport (3.14-1) unstable; urgency=medium . * New upstream version - Fixed parallel build of documentation. Closes: #904714 Checksums-Sha1: 6658a74ee526ce1ca0332272d5ef998aff055c61 2252 wreport_3.14-1.dsc 7dcf9001065828dede48588178a4f9af2cd6d7ba 2181790 wreport_3.14.orig.tar.gz a51f1507048ee3f94a3f52c9e8a7b2c7358b8de6 5524 wreport_3.14-1.debian.tar.xz 5f02e512585cb0e347b9a54d7ad87f2fb273c95a 256736 libwreport-dev_3.14-1_amd64.deb 95570fd77f9cf68a931725a4b75161935dd8e2d2 347212 libwreport-doc_3.14-1_all.deb 255bb422a518f994a57279f6e8b868a0c145d849 2637592 libwreport3-dbgsym_3.14-1_amd64.deb d1a1c63a284ebbf348133bed1cee086b2384ff4d 182648 libwreport3_3.14-1_amd64.deb e42899e116ad20ecf3240bbfe65aafd737d108b4 167936 python-wreport-dbgsym_3.14-1_amd64.deb 6f6ed5e87d27df2b623891d60a46f2435cea7dbb 26632 python-wreport_3.14-1_amd64.deb b110651cc55e5ec4e9b463f890128a9775d81239 340680 python3-wreport-dbgsym_3.14-1_amd64.deb 77e0c9892c4adf28b457701e7c53ce898350e35e 26760 python3-wreport_3.14-1_amd64.deb a153b7b0ea53df9bec21d1fa1f9d59e04a8221a8 151176 wreport-common_3.14-1_amd64.deb 62dfa1e674f224d7ba8eff19a24957749e5d0cb8 9774 wreport_3.14-1_amd64.buildinfo Checksums-Sha256: e5712ff620246c91ea78d2ae672ad323db8386b7983d7da508ede7f71530764c 2252 wreport_3.14-1.dsc e7dcba5306d2bb8b14c108d29954bbd00f492a6a44a3fa0f38898b8d49dd8a17 2181790 wreport_3.14.orig.tar.gz fe38ad1332c3d68e2c0dab03ad4ab969acb2f7f79c60535803e601350788f443 5524 wreport_3.14-1.debian.tar.xz c6bfd4afa39cb6966d4ba4aeb2573974e90ad440b979a7e795bdbb5bdf558979 256736 libwreport-dev_3.14-1_amd64.deb db29161aae818e284046be94b31a46b8b415b523673ba12799ef0e0baca457d9 347212 libwreport-doc_3.14-1_all.deb 7e690c81b716547886e6a432e54fdc3a13afd340e55b643fb1d5115c03fed35f 2637592 libwreport3-dbgsym_3.14-1_amd64.deb d5f61d17bb43709c59e622d6f6779591c3d4348f411ff908d4d998eb2bd5ed3a 182648 libwreport3_3.14-1_amd64.deb ceba19a6b3bdad09d9496b7a7bbb785f1cd4da0c528efa6c23e63910c57e0be2 167936 python-wreport-dbgsym_3.14-1_amd64.deb 99514d8235a27ecec7181e2b5ef86da08bd8c305e4effdb07bf3bce671673c4e 26632 python-wreport_3.14-1_amd64.deb 339cf9957307bb5aae64e9cada5959a52cd81f9e574cd68ce4454dd29b8d8232 340680 python3-wreport-dbgsym_3.14-1_amd64.deb 097a187779f8dd270ceb84d78b4fc949e3242cddc5a0df73d4eef9822f6bd869 26760 python3-wreport_3.14-1_amd64.deb ee8e54c8afc0e85c79f43aed36eb9d06e597f3341803718ac3b9647a89cfac49 151176 wreport-common_3.14-1_amd64.deb 385001d18e8782d2caf6c9ea9e2e5aa71996208b9b802df054e77827f1acdce7 9774 wreport_3.14-1_amd64.buildinfo Files: 5b5d7f624685d7d471bf5e4bac968da3 2252 misc optional wreport_3.14-1.dsc 30f7febd1759e0ac2249a7e23f548f7d 2181790 misc optional wreport_3.14.orig.tar.gz 3962cdd973dc3a1dfc91b35f1a87dbaf 5524 misc optional wreport_3.14-1.debian.tar.xz 2bf98d7196342213fd7fec870c99d013 256736 libdevel optional libwreport-dev_3.14-1_amd64.deb 8b02d49771d94991a46b212742f98f90 347212 doc optional libwreport-doc_3.14-1_all.deb 7afac4a7daeec885ef019077e738105a 2637592 debug optional libwreport3-dbgsym_3.14-1_amd64.deb aa657e1492e7813e991cca6c81424304 182648 libs optional libwreport3_3.14-1_amd64.deb aa8b9762b2f77aa32884c22dd7de5e4d 167936 debug optional python-wreport-dbgsym_3.14-1_amd64.deb ea7af643763f9d9e414979833160d56c 26632 python optional python-wreport_3.14-1_amd64.deb 7b90cbc041a05104f5e18961994a2236 340680 debug optional python3-wreport-dbgsym_3.14-1_amd64.deb f2119f56f8f108144010f687a4741552 26760 python optional python3-wreport_3.14-1_amd64.deb 2d855a34265c710db36e8e4e9c46019d 151176 misc optional wreport-common_3.14-1_amd64.deb eb4b54a104ea28296a2eaa1a7d9b11f0 9774 misc optional wreport_3.14-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEECWOFX2srg4dSrhhPiHMvzA1Tr7YFAluiPpcSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEIhzL8wNU6+29lwP/jhvbB05C0V8aPOk7gIH2NK+z3K9zDfE 23yP7PeF/w3khAMqU0I/hkoLrjBmuU+id89tXavG3UnHA3inMsS9cYLE0NCHrrkp qRwKenYbcF8UxfrY6tyXFx4H6KgKpCQBK4uvJ8GFD46GGP3bSSY+piP1pY3zQCq6 wZExA+baWVNeS7togxco6nYJN/Cr8BS1wR14257Pp2U4Qsa6w3y4Cj/n6UDHF2do 1fquXFhY6FTLGU8vlrfidH9oH2OG9U8dvZE13w0UISxZj5IqfeuZbp4v+A2eSYBZ opR6nfTR+rxfR+M3hh4FoKQRc5qo8wlMIm0D58XdWHcNUUj0DOJeX6jd3pPEB8q1 HvBCIbmJsKLS5
Re: New layout of debtags.debian.org
On Tue, Aug 14, 2018 at 02:01:30PM +0200, Andrej Shadura wrote: > > Let me know if you like it, or if I broke something. > "add tag role::program" button on the right (hints and checks) stopped > working, with "add_tag is not defined" in the console log. Thanks, good catch! I should have fixed it now. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
New layout of debtags.debian.org
Hello, I have ported debtags.debian.org to Bootstrap 4, it should now be easier for development, and work better on mobile devices. Let me know if you like it, or if I broke something. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Accepted wreport 3.13-1 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 26 Jul 2018 20:54:17 +0800 Source: wreport Binary: libwreport-dev libwreport-doc libwreport3 wreport-common python-wreport python3-wreport Architecture: source amd64 all Version: 3.13-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Description: libwreport-dev - library for working with weather reports libwreport-doc - documentation for libwreport libwreport3 - shared library for working with weather reports python-wreport - Python library to work with BUFR and CREX weather bulletins python3-wreport - Python library to work with BUFR and CREX weather bulletins wreport-common - common data files for libwreport Changes: wreport (3.13-1) unstable; urgency=medium . * New upstream version Checksums-Sha1: 18f6f86cb28ba6ceb028c5372f6724b9a8ba9fa7 2252 wreport_3.13-1.dsc 9c0b2f883aab27cdd99a46b42e114adad7b04474 2179459 wreport_3.13.orig.tar.gz ede254e2ad9e3f90ab73a524459f77bac4f078d3 5492 wreport_3.13-1.debian.tar.xz 3c7bdf44edf3dccaccf14cd03cd37709ed8d592f 256608 libwreport-dev_3.13-1_amd64.deb efbe2316d1c0c40ca249dae140877ff7cc6b29e3 347112 libwreport-doc_3.13-1_all.deb 1add86b2ceaaeb2072429762f5480bb013c63d95 2637800 libwreport3-dbgsym_3.13-1_amd64.deb 2d35f5373ea3b295eb33b59284c455f1e30cc491 182516 libwreport3_3.13-1_amd64.deb 9ce91274c0bac3b23451713e2f6053e485ca5d87 167860 python-wreport-dbgsym_3.13-1_amd64.deb 0e782e9d5d88a436b5134c731dcc398ed41cc1c7 26604 python-wreport_3.13-1_amd64.deb 3bd25cf4fb7b18d11c8b0b38fad287f9721d6b7d 340900 python3-wreport-dbgsym_3.13-1_amd64.deb bba7966baa067818eb683dac40bbbe0f021b6b79 26696 python3-wreport_3.13-1_amd64.deb 9fb9c38a9fa37f4381c95e16ee73e1665f8406c1 151328 wreport-common_3.13-1_amd64.deb a355624796a4f954a88d5b2a8e132ff85841d469 9814 wreport_3.13-1_amd64.buildinfo Checksums-Sha256: b058fc8323a9f56433a3cd6d39637424c092ff0158a108482c77646a2d8bacf2 2252 wreport_3.13-1.dsc d9f7261b32d56c917859b12856e2842617e44e3696d163c012252e7449822cd7 2179459 wreport_3.13.orig.tar.gz e3b82156136c474a01567ffbbe6e35b9f8470438b09d87dcbab94fec0062460a 5492 wreport_3.13-1.debian.tar.xz ce1e8b1d851e19f25e5edce780d3641662215644c372e112eb6ef84b47bc4b57 256608 libwreport-dev_3.13-1_amd64.deb 54774a96df95533ccc44a996850bff9b5e18f6185f5a28bcd770fdd83788db24 347112 libwreport-doc_3.13-1_all.deb 33661590470d59ba82449dc4b1cff9726b060ae3a7279dee8968c6644f001efa 2637800 libwreport3-dbgsym_3.13-1_amd64.deb 882e5c103b85822cb2500331acfd1f4616b9eae0f154d964d046c7b0d84d2a25 182516 libwreport3_3.13-1_amd64.deb a8772acf6aef01f07ae04719ed62202b4a1b99bc0194e6bbc6ade07add4da9c9 167860 python-wreport-dbgsym_3.13-1_amd64.deb 290e1ca399fef6a53f3e8468411d4e5221e7d27e165515ad6921a50a8420 26604 python-wreport_3.13-1_amd64.deb 35bf112cbf2ab669b38f7533e89513dcc7cfbf29935f379f8a395e0e572d99ed 340900 python3-wreport-dbgsym_3.13-1_amd64.deb 891d86c1c7db92b08f88afef2d811df5572a44e5d5d1a6dab515712cf5bedb3a 26696 python3-wreport_3.13-1_amd64.deb 0b5972cd0df05e05921966a51c5b61232230b93a1f558b8a3c93878aca1d478d 151328 wreport-common_3.13-1_amd64.deb e6b07a9511bf48d211b6a40880049391f30a79782b0e0d6f89243f91b070ec67 9814 wreport_3.13-1_amd64.buildinfo Files: 3e07588db69283ba6d51d940b32140eb 2252 misc optional wreport_3.13-1.dsc 9102548cb9a4c6d5fb8d3bb38f5ae20f 2179459 misc optional wreport_3.13.orig.tar.gz 46efcd578f75252bfc8d6b551407497f 5492 misc optional wreport_3.13-1.debian.tar.xz 809c39555937fb55f36448048faf76fd 256608 libdevel optional libwreport-dev_3.13-1_amd64.deb 89bd0c53a9a7cd090cd9f3cd50971b33 347112 doc optional libwreport-doc_3.13-1_all.deb 6e543e2a56b26a185e9dc2d32a577e1f 2637800 debug optional libwreport3-dbgsym_3.13-1_amd64.deb 5c7f4717324fba37e085baf436a86c91 182516 libs optional libwreport3_3.13-1_amd64.deb 26d8ae6d33badef2ba13bb129e32dfcd 167860 debug optional python-wreport-dbgsym_3.13-1_amd64.deb 75da57bc2faea60b7582a379bd132ccd 26604 python optional python-wreport_3.13-1_amd64.deb 1c5a4494a22289db3df403b4ef5e275f 340900 debug optional python3-wreport-dbgsym_3.13-1_amd64.deb 8533081064652537ae4c8a1dbae162b7 26696 python optional python3-wreport_3.13-1_amd64.deb 46357e67a088cb200abf22c1ad0b5483 151328 misc optional wreport-common_3.13-1_amd64.deb 111405758bf7af60149222b8dcd6d20e 9814 misc optional wreport_3.13-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEECWOFX2srg4dSrhhPiHMvzA1Tr7YFAltZxp4SHGVucmljb0Bk ZWJpYW4ub3JnAAoJEIhzL8wNU6+2kXAP/28WrRgqkEE+hKsEaRiKCpSlsawpoWgi K2YWWsJx05+KUtUJHwDaXk/G8G3UFNW39Vw0rIpVe1eC4Js4i6ZbX20TuTqfEwq5 0gz4+62EVHJxIBVg8I8u2E1yjpSPuRKDJ1XFLhXI2jihXp39mnk2AvCej9QZz6HC QvoAchLuM+VvTyXaDIdc5ASt8lRygykrthS4D3MF/HdTUzRpFJ0PH89qp0Rog/9/ HrvUm/s7f2MCJi6JEf44H6tO+pemeG6qBjlSWoA+2sjonE3XTGRFs0nfd+CeSxzN 5SCzC+guI9NdcfAjYY4xbnGUuRpnQXMJQb2CJL3w8nxaZrv7IU5cvCIH0mclxsMa MH1afdH/zEEQ32cMqi3h7yVvkCKrnVzkrrMDC3ekO/EUBDJe4ifV9oMz/nRDId3R mXd5Wkf663SJ0hzEPgusBsTwftnbCsxsIX+Qh
Accepted wreport 3.12-1 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 25 Jul 2018 09:42:00 +0800 Source: wreport Binary: libwreport-dev libwreport-doc libwreport3 wreport-common python-wreport python3-wreport Architecture: source amd64 all Version: 3.12-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Description: libwreport-dev - library for working with weather reports libwreport-doc - documentation for libwreport libwreport3 - shared library for working with weather reports python-wreport - Python library to work with BUFR and CREX weather bulletins python3-wreport - Python library to work with BUFR and CREX weather bulletins wreport-common - common data files for libwreport Closes: 890487 Changes: wreport (3.12-1) unstable; urgency=medium . * New upstream version * Remove absolute paths from doxygen tags file, thanks Chris Lamb for the patch. Closes: #890487 Checksums-Sha1: 1ddf0bcea8d0ccda018e941805023d1f855eee69 2252 wreport_3.12-1.dsc 6de1aa26a6359a68d3e68246310973f42220173b 2179130 wreport_3.12.orig.tar.gz ed29da97d019f63a3a050cad1217e83aa12ab0cd 5476 wreport_3.12-1.debian.tar.xz bacfbec13e714932da89dbfce8628a7888bf06a8 256444 libwreport-dev_3.12-1_amd64.deb ff606f45dca8c22a56b020decce48a4451c1c409 346976 libwreport-doc_3.12-1_all.deb d2f6164a2c44ab13175ab41ec95d20ef39bd54cb 2638104 libwreport3-dbgsym_3.12-1_amd64.deb 8fa8a54eb561d4bc7c2f12f0adcef5961cf4a23c 182408 libwreport3_3.12-1_amd64.deb f93aea775d12be26b83fadd844855ab6e8b21906 167860 python-wreport-dbgsym_3.12-1_amd64.deb 5021e86de855a6ad2f8c9ef27add6f6bf6b327d9 26580 python-wreport_3.12-1_amd64.deb f20ebd14086cf7c3c6a85bef63b369b7573be7b5 340900 python3-wreport-dbgsym_3.12-1_amd64.deb 8d4e9d398b349e0b568bde715bcd7bd44b629b5a 26724 python3-wreport_3.12-1_amd64.deb 0fd374666a17eb1eaf5806b550acbd58ab91c8c9 150996 wreport-common_3.12-1_amd64.deb 0b8eb64560e6a803287be60e820ef89120f2e2a9 9814 wreport_3.12-1_amd64.buildinfo Checksums-Sha256: 5e85b6d14ba848c3abad80374f3d57058598bd8a523b02cfb17458977180f99e 2252 wreport_3.12-1.dsc e1a6d1041de225dac044924888649b8325daea0b2241e6721d8271d37732a0e1 2179130 wreport_3.12.orig.tar.gz 66a2287b03b0631d584cbbb2701f7dc1afac88a38bbf8ff979b2da61e16a531e 5476 wreport_3.12-1.debian.tar.xz f9e6fbd4663ed8e956bac070f8a697c18ee49adcc37b23c6e3c2bd1057bc2a49 256444 libwreport-dev_3.12-1_amd64.deb 473d834130f06c82a6a2359c3943309d6d34605fe289ba720bba7c3198f31d9e 346976 libwreport-doc_3.12-1_all.deb c368566ebd539dda5ece2238da26ed992d07448f4c4a85254da5194b09f0bb30 2638104 libwreport3-dbgsym_3.12-1_amd64.deb 7225970e4acf5eeb2777cde70f549d0542f04a09d03598f644a028f0cb07a840 182408 libwreport3_3.12-1_amd64.deb 3b9dc6cee1e28d3e242fbc8e0512e52e3615403434d2db2c024f53e953d68b0b 167860 python-wreport-dbgsym_3.12-1_amd64.deb b61b1738382f34e17d78fba3cd8a5d514116dce5a2a0b4000d755fc00cf8af6a 26580 python-wreport_3.12-1_amd64.deb 6fc2043f5131e9e84f8af959a02b7dc68bf855103e9d11b822cd16e38c3b 340900 python3-wreport-dbgsym_3.12-1_amd64.deb 5d74ecd571922c2eab9f3743dc967b1d3b856ba10641aa4eda8b1c1a55dfe7ba 26724 python3-wreport_3.12-1_amd64.deb cfa9f09795b3d2f10831374ed3fc94f755d60b2e47f9c2215dbb1c8b3aa3d188 150996 wreport-common_3.12-1_amd64.deb 572e53508f75981db2e1af688f4eb59772fc2e062ed595814f099eab4c83aef6 9814 wreport_3.12-1_amd64.buildinfo Files: b1e6118b76fefe42b56455e9ca5e6e1f 2252 misc optional wreport_3.12-1.dsc 84eb6934be8be4be4044375685b99db7 2179130 misc optional wreport_3.12.orig.tar.gz 02271ea696e91ba165bb2bc91562c54f 5476 misc optional wreport_3.12-1.debian.tar.xz 9cb7626b830608189cc75b0feb752278 256444 libdevel optional libwreport-dev_3.12-1_amd64.deb d6e87781e571a290a88e640c6b5a7d81 346976 doc optional libwreport-doc_3.12-1_all.deb bbc085bd8daa502255c43917fe0e7e5f 2638104 debug optional libwreport3-dbgsym_3.12-1_amd64.deb 18465d113fe71a41b3cac0de94585aa9 182408 libs optional libwreport3_3.12-1_amd64.deb 319f40e7910950075b42194a57b01aa4 167860 debug optional python-wreport-dbgsym_3.12-1_amd64.deb 97c66fb33fa05b3502016109ac08e8c2 26580 python optional python-wreport_3.12-1_amd64.deb 0f0eb38758229684fbd91e116e63de2f 340900 debug optional python3-wreport-dbgsym_3.12-1_amd64.deb 775c6cbca65181ff92ea813058be98d8 26724 python optional python3-wreport_3.12-1_amd64.deb 58d1aeac4fdc72599f9756f7f8908c08 150996 misc optional wreport-common_3.12-1_amd64.deb 63be518ac510f123abe85693985361f3 9814 misc optional wreport_3.12-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEECWOFX2srg4dSrhhPiHMvzA1Tr7YFAltX3PYSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEIhzL8wNU6+2Z9wP/3eaUGLK2lO2xLpq/J9dk2YAaYQuMDKb wBWFgDaIjs+MM12aYwgZsBiH6F7669bk6Y59Qcg7JynlJbhjzpwkBRDIoSPuix7W ZF6ZLKML1S6IuWFhOpbEh95eiA1Oxg2K0M7fGjTnE3O4T/bXkwRo6Ze/ekaaiVeT XSKZOxruWAxYuN7a8/e2ryuKEMql4khaDBf/SZhSfnAPe0GFV0GF/tDpDWMV3bnh 8ujLQ/441bgbpIrEY+SMEEwJL4BLt/nflyNpSUlqPb1w1pxY0fJNvLdPs1D/1H34 32J8U5Cf2SKbUonF7ovZaDuMAVbpfF4pkmv+z+q4KJdD
Accepted staticsite 0.5-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 24 Jul 2018 10:51:34 +0800 Source: staticsite Binary: staticsite Architecture: source all Version: 0.5-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini Changed-By: Enrico Zini Description: staticsite - Static site generator Closes: 860305 Changes: staticsite (0.5-1) unstable; urgency=medium . * New upstream version * Added copyright of example assets to debian/copyright * Made livereload an optional dependency * Depends on python3-tz. Closes: #860305. Checksums-Sha1: dc8aa1f366ce181e5d95b24b2b4731a188451cca 2059 staticsite_0.5-1.dsc 16f43706638c67ff61c39e30a70371c9e70b864c 469923 staticsite_0.5.orig.tar.gz 22351998c5be936361bd6a70bca14555fb63efe6 3088 staticsite_0.5-1.debian.tar.xz 4493da1dcdf6a7d6d69bae38eff61b897ba89620 41024 staticsite_0.5-1_all.deb ff2f5df624cfbeba99a712a6e6710ce3df6baf30 6609 staticsite_0.5-1_amd64.buildinfo Checksums-Sha256: 66a29f4781a9d06318a23b5bfa4849776ab8e3cbcca9eff18d5508cf65a9293e 2059 staticsite_0.5-1.dsc ba0f88b52ee31bca2bbbcf7ae2e3832c84c261eaa795ad9414d56411003303d6 469923 staticsite_0.5.orig.tar.gz 957dd13a9849dd8eb1a48d4daaf764450fbd0490ec7b7b65821709e4a676ca46 3088 staticsite_0.5-1.debian.tar.xz f1cfe55191f0f1c0ab2786da44521febcee65c7b068f93a441812c98d4dadf48 41024 staticsite_0.5-1_all.deb 8479a681aaf00d601ebfb38b6250d3822bcd676830a5f81c1caff3d3d0303f66 6609 staticsite_0.5-1_amd64.buildinfo Files: 8011b7d72f37059055999d2d276e1964 2059 web optional staticsite_0.5-1.dsc c899b99c2f0d8ddaa9738bae958d158a 469923 web optional staticsite_0.5.orig.tar.gz 286e85a1c94ebb22bb401b656c224236 3088 web optional staticsite_0.5-1.debian.tar.xz a55ca06556a83ef7e5c8006ae83a55de 41024 web optional staticsite_0.5-1_all.deb f14534c391e6b4b163e2d93a539eb0c5 6609 web optional staticsite_0.5-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEECWOFX2srg4dSrhhPiHMvzA1Tr7YFAltWnpgSHGVucmljb0Bk ZWJpYW4ub3JnAAoJEIhzL8wNU6+2jskQAIy/cpdU4LhAqchsh++Yb5+gh0yGJXOD XCGapRiDIHIjY8hVKLaS7CVSSq4nRMxyXk2ADS5V3Fnlnqb9R3D9vmC93uA08IoP pXsQf656nmnlzKR78A1dI2QAgB4kqpiYkvI5vTa017H57aG0ociQ5iiCTPMjRX9c /3PDcM0RXDgGcFGuMx2jCtwMPtUpfa9/ATHBUp5+mU1jU2rqS7NTHZ9+VGwcvfVP Ui7CF7S5H+8ON/MNlUc+X4+yhM69RJalr42dvcQc13e2jJvgqMz4WUFM17t33Y2k vVK6jfQH1/gkV6ZpKMPwlnwwzJXBo865K7ckAdHFZ2apzYe6BoJw6yyoxeO32xEX 05Ld0uMTvzkmvAZWKcdXFPQALawnf++7m7wkUSjgF3lYk5SQwg77NPxH6mAa7hbD Oh0u3MMUs2fa+WpbNhPmzn1qQ2WOLDPXlF5VS8DTlnVFpdhTtZNMitvnE5uvdGBg 2rim/NJbSzW9fLrsby4ROG7AElO7srzauYohs42jKvBrAFqjsIizaTGLFpQSEoF4 u/dGUxOHyE+ecL0uuH+eQBegiEJTFESLDFdroLPGnWTadxvKfY9XSC7/zMlxqRDU BBCuTNudwdXukvHVc9iTpoh0nZusrqWiamFCp7vZhnhOttSd1sVd9xpAWEA48S+B dxazhJwRQkT9 =DOuP -END PGP SIGNATURE-
Bug#894551: ITP: fascism -- Exhaustive exploration of Fascist theory and practice
Package: wnpp Severity: wishlist Owner: Enrico Zini <enr...@debian.org> * Package name: fascism Version : 19190323 Upstream Author : Too many forks to list * URL : https://en.wikipedia.org/wiki/Fascism * License : All rights revoked Section : non-free Description : Exhaustive exploration of Fascist theory and practice Fascism is a form of radical authoritarian nationalism, characterized by dictatorial power, forcible suppression of opposition and control of industry and commerce, which came to prominence in early 20th-century Europe. The first fascist movements emerged in Italy during World War I before it spread to other European countries. > - why is this package useful/relevant? I believe this is the development trend most of the world is currently aiming for, and that, like with other recent questionable development practices, Debian should at least acknowledge its existance, but not embrace it. > - is it a dependency for another package? No. Historically, once fascism has been launched, there has been little space for anything else. > - do you use it? I do all I can to avoid it.
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Fri, Feb 23, 2018 at 03:49:06PM +0100, Alexander Wirt wrote: > > Are there other ways in stretch of getting apache to authenticate > > against gitlab? > I would wait for the gsoc project. And on the alioth sprint, several people > decided against using salsa as backend for sso, but the other way round. > So please don't. Please do not switch Alioth off, nor disable creation of new accounts on alioth, until then. Being able to get a SSO certificate as a non-DD is currently a required step to become a DD. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Fri, Feb 23, 2018 at 03:49:06PM +0100, Alexander Wirt wrote: > I would wait for the gsoc project. And on the alioth sprint, several people > decided against using salsa as backend for sso, but the other way round. > So please don't. Ok, fine with me. I'll stop worrying about it for now, and refer people who ask me about it, to this thread. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Raising the problem of Debian Single Sign On + Alioth (again)
On Sun, Feb 11, 2018 at 10:08:31PM +0800, Boyuan Yang wrote: > From a user (non-DD)'s perspective, current best plan should be the > integration > with Salsa GitLab user database. Works on such implementation are surely > needed > though. Well yes, work is needed, that much has always been clear. At SnowCamp[1] I gave it a try with the help of aurel32. Integrating sso.debian.org with $THING is simple as long as apache can authenticate against $THING. sso.debian.org's codebase just trusts apache's REMOTE_USER variable, and actual authentication is done at apache level. This means that the sso.debian.org codebase does not need to have access to ldap and other authentication backends. We tried deploying libapache2-mod-auth-openidc to authenticate against gitlab, but that ended up in submitting https://bugs.debian.org/891224 Are there other ways in stretch of getting apache to authenticate against gitlab? Enrico [1] https://wiki.debian.org/DebianEvents/it/2018/SnowCamp -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Help, I broke sso.debian.org for chrome - Found reason
On Wed, Sep 06, 2017 at 01:36:55PM +0200, Enrico Zini wrote: > I found the reason: python-cryptography writes the certificate issuer > as UTF8 String while the CA certificate has it as Printable String. > Because of that, the subject names don't match bit-by-bit. Fixed: https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/commit/?id=39280a19fd00493580d840dc2fff89ecc8461e5b Thanks to reaperhulk on #cryptography-dev for the help with making that workaround work. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Help, I broke sso.debian.org for chrome - Found reason
On Wed, Sep 06, 2017 at 01:36:55PM +0200, Enrico Zini wrote: > On Tue, Sep 05, 2017 at 11:37:01AM +0200, Enrico Zini wrote: > > > I refactored the certificate generation code for sso.debian.org, and the > > certificates it generates now still work in Firefox but not in Chrome. > > I found the reason: python-cryptography writes the certificate issuer > as UTF8 String while the CA certificate has it as Printable String. > Because of that, the subject names don't match bit-by-bit. Massive, massive thanks to Luca Filipozzi for assistance! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Help, I broke sso.debian.org for chrome - Found reason
On Tue, Sep 05, 2017 at 11:37:01AM +0200, Enrico Zini wrote: > I refactored the certificate generation code for sso.debian.org, and the > certificates it generates now still work in Firefox but not in Chrome. I found the reason: python-cryptography writes the certificate issuer as UTF8 String while the CA certificate has it as Printable String. Because of that, the subject names don't match bit-by-bit. For openssl, encoding does not matter for comparison, while for libnss3 it does. I do not know if this is: - a bug in openssl, which should be stricter in matching - a bug in libnss3, which should deal with encodings - a bug in python3-cryptography, which should do a bit-for-bit copy when copying attributes over: https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ca/ca.py#n429 Please help me report the bugs, while I try to implement a workaround on sso.debian.org. I'm attaching a test case that reproduces the issue. Unpack the tarball and run ./test to reproduce. This is the output of a run: $ ./test + trap cleanup EXIT + cleanup + rm -fr newcerts + rm -f index.txt index.txt.attr serial '*.old' + certtool -p --outfile=testkey.pem + certtool --load-privkey=testkey.pem -s --outfile=testcrt.pem --template=testcrt.conf + mkdir -p newcerts + touch index.txt + touch index.txt.attr + openssl genrsa -out client.key 2048 + openssl req -new -sha256 -key client.key -batch + openssl ca -batch -config testca.conf -in client.csr -create_serial -days 7 -keyfile testkey.pem -cert testcrt.pem -out client.crt + openssl verify -CAfile testcrt.pem client.crt client.crt: OK + certtool --load-ca-certificate testcrt.pem --verify --infile client.crt Loaded 1 certificates, 1 CAs and 0 CRLs Subject: O=Internet Widgits Pty Ltd Issuer: O=Test client certificate,CN=Test CA 2017-09-06 Checked against: O=Test client certificate,CN=Test CA 2017-09-06 Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. + ./utf8ize --crt testcrt.pem --key testkey.pem testcrtutf8.pem + openssl x509 -noout -nameopt multiline,show_type -subject -issuer -in testcrt.pem subject= commonName= PRINTABLESTRING:Test CA 2017-09-06 organizationName = PRINTABLESTRING:Test client certificate issuer= commonName= PRINTABLESTRING:Test CA 2017-09-06 organizationName = PRINTABLESTRING:Test client certificate + openssl x509 -noout -nameopt multiline,show_type -subject -issuer -in testcrtutf8.pem subject= commonName= UTF8STRING:Test CA 2017-09-06 organizationName = UTF8STRING:Test client certificate issuer= commonName= UTF8STRING:Test CA 2017-09-06 organizationName = UTF8STRING:Test client certificate + openssl verify -CAfile testcrtutf8.pem client.crt client.crt: OK + certtool --load-ca-certificate testcrtutf8.pem --verify --infile client.crt Loaded 1 certificates, 1 CAs and 0 CRLs Subject: O=Internet Widgits Pty Ltd Issuer: O=Test client certificate,CN=Test CA 2017-09-06 Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Subject: O=Internet Widgits Pty Ltd Issuer: O=Test client certificate,CN=Test CA 2017-09-06 Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Chain verification output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. + cleanup + rm -fr newcerts + rm -f index.txt index.txt.attr serial index.txt.attr.old index.txt.old Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> testcase.tar.xz Description: application/xz signature.asc Description: PGP signature
Re: Help, I broke sso.debian.org for chrome
On Tue, Sep 05, 2017 at 12:16:47PM +0200, Christoph Berg wrote: > My guess is that the new-style certificates are missing some > attributes: > > Old certificate from 2015: > > X509v3 extensions: > X509v3 Basic Constraints: critical > CA:FALSE > X509v3 Key Usage: critical > Digital Signature, Key Encipherment, Key Agreement > X509v3 Extended Key Usage: > TLS Web Client Authentication > > New certificate from this week: > > X509v3 extensions: > X509v3 Subject Alternative Name: > email:m...@debian.org > X509v3 Basic Constraints: critical > CA:FALSE > > I'll see if I can add that. I should have managed to do it, but chrome still doesn't seem to like it. Can you generate a new certificate and see if you still find differences? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Help, I broke sso.debian.org for chrome
Hello, I refactored the certificate generation code for sso.debian.org, and the certificates it generates now still work in Firefox but not in Chrome. Steps to reproduce: 1. Back up and delete all Debian certificates in Chrome 2. Go to one of these links to generate a new one: https://sso.debian.org/debian/certs/enroll_csr/ https://sso.debian.org/alioth/certs/enroll_csr/ 3. Go to chrome://settings/certificates and import it (remember to combine key and certificate in a .p12 file, the enroll_csr has a command line example 4. Visit https://sso.debian.org/ca/test/env: chrome doesn't even ask for which certificate to use Can you help me find out what is in the certificates it generates now that chrome doesn't like? This is the code that generates the certificate: https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ca/ca.py#n402 This is the code before the refactoring: https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ca/ca.py?id=926d5ca1c448fdd4f02ae7247ef5f695d8e2f22e#n331 Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Single Sign On for Debian
On Sun, Aug 20, 2017 at 04:28:05PM +, Luca Filipozzi wrote: > As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two > related but orthogonal things: > 1 collapsing user management into a single user store (LDAP)** I really, really like the idea of having all the accounts in a single LDAP, regardless of the SSO system used. +1 to that! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: What's a safe way to have extensions in chromium in Debian?
On Thu, Mar 23, 2017 at 10:20:00AM +0500, Andrey Rahmatullin wrote: > On Wed, Mar 22, 2017 at 09:51:12PM +0100, Jeroen Dekkers wrote: > > If we already know this is going to be major issue, why aren't we > > doing the sensible thing and enable extensions by default > The story of extensions in Debian Chromium is a strange and sad one. > See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856183 > I cannot list all previous bugs included in that story, I think you can > find them in the changelog. Thanks, I've added a link to that bug page to https://wiki.debian.org/Chromium so that it now contains some information also on why they are disabled. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: What's a safe way to have extensions in chromium in Debian?
On Wed, Mar 22, 2017 at 11:41:16PM +0500, Andrey Rahmatullin wrote: > On Wed, Mar 22, 2017 at 08:16:14PM +0200, Jonathan Carter (highvoltage) wrote: > > so what's going to be the best way to make these > > available to Debian stable users? > https://wiki.debian.org/Chromium#Extensions Thanks, that tells me the proper way to re-enable extensions, and I think it's valuable given that on the internet people describe all sorts of dirty way to reenable them. On top of that, I'd like to have some more context for what's going on, what I lose, what I gain. Like: What is the amount of phoning home that I get if I enable that? If I enable extensions that way, do they get updated as new versions come out, or do I open a security nightmare of extensions making my browser more and more vulnerable as they age? (I noticed that I can manually trigger an update in "chrome://extensions/", enable Developer Mode, click on "Update extensions now") Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
What's a safe way to have extensions in chromium in Debian?
Hi, now we have extensions disabled in Chromium by default. If I did my homeworks correctly, that prevents Chromium from phoning home by default, and prevents a previous scenario where extensions could be installed but not upgraded, becoming security issues over time. Now, suppose I need an extension, what is the proper way to have it in Debian, so that it gets upgraded when needed? With that proper way, what amount of phoning home is going to happen? Since this looks like it's going to be a major issue with stretch, can I have some authoritative wiki page / FAQ entry that tells me how I can deal with it cleanly, and that I can easily send to confused people? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Accepted debiancontributors 0.7.6-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 11 Dec 2016 08:15:50 +0100 Source: debiancontributors Binary: python3-debiancontributors python-debiancontributors Architecture: source all Version: 0.7.6-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team <python-modules-t...@lists.alioth.debian.org> Changed-By: Enrico Zini <enr...@debian.org> Description: python-debiancontributors - Manage submissions to contributors.debian.org python3-debiancontributors - Manage submissions to contributors.debian.org Changes: debiancontributors (0.7.6-1) unstable; urgency=medium . [ Daniele Tricoli ] * New upstream release. * Apply modifications from Enrico Zini: - Deal with bytes as input in python3. - Deal with the input stream to the parser being a stream of bytes. - Link bts urls with archive=both. * debian/control - Bump Standards-Version to 3.9.8 (no changes needed) Checksums-Sha1: 2bfcbbb275e0a72544b02a739910c8ec789f0f74 2346 debiancontributors_0.7.6-1.dsc 3c8b308fe13c3272fe2266085c77584fac6bb0ef 40958 debiancontributors_0.7.6.orig.tar.gz e65b84bf080c70dceeaf4fda4d20d12704f51b8c 2888 debiancontributors_0.7.6-1.debian.tar.xz d94612e6b8e5bbf0ed9415e763cf222376b6f41b 6392 debiancontributors_0.7.6-1_amd64.buildinfo 7c8873f5d5b539245fa502d4efd9ddbd4085775f 22508 python-debiancontributors_0.7.6-1_all.deb 4039a36d8685a6ee3a0ccf6e8a8b0ab2582e0c30 29406 python3-debiancontributors_0.7.6-1_all.deb Checksums-Sha256: 7e6d15a0cd8cf47acc7cd258f87f3f0239c1056065770910b700953658894e7d 2346 debiancontributors_0.7.6-1.dsc e236f58ada85b750ad21ac12cd552c18a61110ef1b4b77c8323996bc0829da29 40958 debiancontributors_0.7.6.orig.tar.gz 5f316a1af37fd13a328955c469b07397c3c3fb8b0b7b7092c7a2624dac3ee9aa 2888 debiancontributors_0.7.6-1.debian.tar.xz 70d0cc62cf7a9bef9fee543ee3cbda7b0da3a84ab55185da7d4b7fe1f77e510d 6392 debiancontributors_0.7.6-1_amd64.buildinfo 3662e9399434471e7622ac381ea203eac309b0b78af5047a9400b3cba077bd0b 22508 python-debiancontributors_0.7.6-1_all.deb 4d7eacee6c04e012ec61af703b901ead792aabb15deec2fed505216f5d2efa63 29406 python3-debiancontributors_0.7.6-1_all.deb Files: 77fdfc880ef9efd02ef613613249fb2a 2346 python optional debiancontributors_0.7.6-1.dsc 30ed857a4f125536c0bdbcdf8f4636fa 40958 python optional debiancontributors_0.7.6.orig.tar.gz 30c8f48ccfbcf781e023718086af2437 2888 python optional debiancontributors_0.7.6-1.debian.tar.xz c0fe110ad43c329d1cfea566c134b106 6392 python optional debiancontributors_0.7.6-1_amd64.buildinfo c3bb99afce996a16936c594883923516 22508 python optional python-debiancontributors_0.7.6-1_all.deb 0a14472b59cf8b052a9d7aea10b8cfe9 29406 python optional python3-debiancontributors_0.7.6-1_all.deb -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEEHMASZwB/q+ZYRmhXA9ZWjINydakFAlhM/yESHGVucmljb0Bk ZWJpYW4ub3JnAAoJEAPWVoyDcnWpHQMP/3Rao8yhxMFrqdMxwLfrnfuJ3dw+aaWb AydeHkJI9XzFB0hXGFndH4tSG9RIRH/LtAJs9x2dO2FA1XEwrAWdCTcvExPhxl8C yflYJVV3niMhYsUhLrOQhnsAwcPL/rFud3KwZ5s2v/OGIaK9oqBZ9Z8dd1eeULaD qreRRevPuZNWgc/n6v+vdYKlPG8UEaDYUqrxRSOs6T/j0KdJZPk2LTlaWU7u75Pa kPQqxd2PKjvntkfJzzev4Se4eZPNN07khTrMlAxusAKKbKiEYmZugBFK0FnhiQG0 VLOOz2bZSAjZL5TRfskLeewHu+UTaaitr1zj0bLoWFwbd38O3QsUstbkOt7kqAsj W5mxSoEJ2jIssKVJOmT5Bw3DveNmPVQ7wPr7nOyCISZarhP/mnFJaTUoLyT3Uyty CHpvPbx4l9C61ceBef307eZan0TOLFxTW9YDTCDQG4opPWHIo2Fb2PhH1qGS+zAz rMcjuQXgPbbop0/6UilmucHKrJiyP5mY9ApY9UNFEgP9Ejr3xR007r7fvI6yjg4g vwelhLn1KC2t3Q6fsGikUIZI86Vq64+om47TzqTBHuvgGpj4LQ1TeYHoLJyPuiQ1 QXPk0jLNcz7DVqi69+hpHFE5wWpVIcqUhqovjA1v+JhDAAGwEuZUnrB1EaQ0bG5f zKQm/5Qcjtgm =BXcz -END PGP SIGNATURE-
Accepted dballe 7.21-1 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 09 Dec 2016 11:27:58 +0100 Source: dballe Binary: libdballe-dev libdballe-doc libdballe7 libdballef-dev libdballef5 python-dballe python3-dballe dballe-common dballe Architecture: source all amd64 Version: 7.21-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini <enr...@debian.org> Changed-By: Enrico Zini <enr...@debian.org> Description: dballe - Database for punctual meteorological data (Command line tools) dballe-common - Common data files for all DB-All.e modules libdballe-dev - DB-All.e C development library for weather research libdballe-doc - documentation for the DB-ALL.e C library for weather research libdballe7 - DB-ALL.e C shared library for weather research libdballef-dev - DB-All.e Fortran development library for weather research libdballef5 - DB-ALL.e Fortran shared library for weather research python-dballe - DB-ALL.e Python library for weather research python3-dballe - DB-ALL.e Python library for weather research Closes: 845833 Changes: dballe (7.21-1) unstable; urgency=medium . * New upstream version * Build-Depend on default-libmysqlclient-dev. Closes: #845833 * Updated debhelper compatibility level to 10 Checksums-Sha1: 213fadd8f525f74d4fc43eef0c2d45fed6f2d0d9 2566 dballe_7.21-1.dsc a02d246613c45f3682594e16a74885eb38d668cd 1589282 dballe_7.21.orig.tar.gz 6cf77dd739caf0a34bd0122d051ad3cfb27a37de 10796 dballe_7.21-1.debian.tar.xz 50070d219942c9883fa9b13a10224747ddf496e4 40748 dballe-common_7.21-1_all.deb 5d3d278de6bcac97e2c7ce93c5d52fdb583514f9 424200 dballe-dbgsym_7.21-1_amd64.deb 78753f77be124d1cd7f4467b12418455dfd6227c 11216 dballe_7.21-1_amd64.buildinfo 52e4c4a13fbe7b283c72df4c89d365d73fa68e81 54788 dballe_7.21-1_amd64.deb 843491adb5aec6bc4b321c1f31e40abccc967abe 634356 libdballe-dev_7.21-1_amd64.deb d23b50c52cb854098898c20b8bbb5241cbd8863e 726896 libdballe-doc_7.21-1_all.deb 7f7fbc76cf5d04472dbc09b6e03a0cc4c509097d 6844794 libdballe7-dbgsym_7.21-1_amd64.deb 02e1820b54bf41590ab0e653b028fc1fffaa3529 409454 libdballe7_7.21-1_amd64.deb 500a2581665b4bf72aaf76e731590f737b89e7dc 64496 libdballef-dev_7.21-1_amd64.deb 8def9c90c40f4220df2ae410c0ce07f9aa9fb881 57854 libdballef5-dbgsym_7.21-1_amd64.deb b35b7a4e9912de9bd2e5d40838685a5a5b30d3fc 28128 libdballef5_7.21-1_amd64.deb fd28b71414516271c84bb4eac1a4ee713d19074c 286278 python-dballe-dbgsym_7.21-1_amd64.deb 568f7aa76814df8c4be8e85c5ab0db62518ecb97 59808 python-dballe_7.21-1_amd64.deb 6e19960fe93869fd7f6911c75cb1b25165da3632 290340 python3-dballe-dbgsym_7.21-1_amd64.deb b93ea488a63f215269c1d547ecf0fd4f200d4c10 47406 python3-dballe_7.21-1_amd64.deb Checksums-Sha256: 2ec960a546673b06811993529a4ebf661a79f93e97c53d94fda1338ca4b709fb 2566 dballe_7.21-1.dsc 1173dd278bf6756d8a982e0cf86e2911785fe2892dc0cde2206c8f8aaa408726 1589282 dballe_7.21.orig.tar.gz 7357045f5ad9f8e68118f470a22549080b83354bbb6b697dc0bf04d35303b105 10796 dballe_7.21-1.debian.tar.xz 2507d47690a76087cc47a7d283154084bf77ed218cef3a37b4cc9fd70fe8b57b 40748 dballe-common_7.21-1_all.deb 28b8476528c112922c75439f89119e456a9a2b79606f712573505ca5832ed692 424200 dballe-dbgsym_7.21-1_amd64.deb c1d4af10eea1150b7d02cf2ff6b4d938397c5ba13e2ca04837bd84c9034ad1df 11216 dballe_7.21-1_amd64.buildinfo 241de9753404cd057bc17cfb875cc9472925d5f4153fbd06ba6d0c1bfaa9c24b 54788 dballe_7.21-1_amd64.deb 58b356e09e19bedb0b8ba24a30dd01b0c71769a2ae55d8f6d01e7572077f729d 634356 libdballe-dev_7.21-1_amd64.deb bfe2323b755ab6b30fcf42954b332ee1461b7d6e50731dc9c7ac934d18f2e175 726896 libdballe-doc_7.21-1_all.deb 69fbc19a03fb5a732c611217ed53623a4bf23729292065d3e4dff22dfd87f6d2 6844794 libdballe7-dbgsym_7.21-1_amd64.deb 1cf7145ea573cc90d01051d7308159c2533f52c997e0c8faa80291d574e43a38 409454 libdballe7_7.21-1_amd64.deb 97315edf4b0bda0a57d23d0f42b2b4a9ce87d1326c500df4161266de93b63ca6 64496 libdballef-dev_7.21-1_amd64.deb 302fbebe12533d0f2906d134330b74ae052cda506b0caf9c7c4aeb6f1746a8d8 57854 libdballef5-dbgsym_7.21-1_amd64.deb da61c978aae99fe71afd29a6104afa95eaf343ccd723f58b5dbb50c9a2701ccf 28128 libdballef5_7.21-1_amd64.deb a3a8e213be596cdae36d71c4f9d89d76afe5f7759db5e796eb170aa5c12f4190 286278 python-dballe-dbgsym_7.21-1_amd64.deb 76e4cdfa3ce47d58dd53b4021e913a7660ae5d092c1b63f2ed1e3dbbe65b85ae 59808 python-dballe_7.21-1_amd64.deb 2019f7c0ca8547ddb040a3159073458a36bfc1997dc72929e88c54640c315f40 290340 python3-dballe-dbgsym_7.21-1_amd64.deb 2a5214b1ac73c5e91b0245bc18cdf865fab0ec13c1d6255e1d8e884145d65a27 47406 python3-dballe_7.21-1_amd64.deb Files: e9de0363dd8a25dfdd0f489c4f65cc23 2566 misc optional dballe_7.21-1.dsc b41d38f78b3577deee62494a31a4dd5d 1589282 misc optional dballe_7.21.orig.tar.gz b6f2708201756457ed10fa76d61e6e26 10796 misc optional dballe_7.21-1.debian.tar.xz 9b639fb171b0f98682d1beef5e1b70ae 40748 misc optional dballe-common_7.21-1_all.deb 6d144db66208a06973bf759cafed 424200 debug extra dballe-dbgsym_7.21
Re: Automating importing sso certificates into chromium/chrome
On Sun, Sep 11, 2016 at 02:25:34PM +0200, Philipp Kern wrote: > Did you try pk12util with a PKCS#12 file (bundle of key and certificate) > already? (-d, -i as above, and -W for the password of the PKCS#12 file, > which can be the empty string.) I tried now, and it worked, thanks! I've added instructions for it to https://wiki.debian.org/DebianSingleSignOn#chromium_.2F_chrome This now paves the way for adding automatic key generation and refresh features to https://github.com/spanezz/debsso-client Exciting! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: backup server running out of space
On Mon, Oct 03, 2016 at 06:13:30PM +0200, Martin Zobel-Helas wrote: > Debian's resources are not infinite. Please `touch .nobackup` in a > directory containining unimportant / trivial to regenerate content. The > backup software will exclude from back up the files and subdirectories > of any directory containing such a file. Hello, Thanks for your DSA work, I'm very grateful and I'd like to help with reducing backup pressure as much as I can. I'd like to have a look at what I have scattered around and see where to add .nobackup files, and I have no idea where I might have data that is being backed up. Would it be possible to generate a report of where is (and how much is) stuff that I own in all bits of filesystem that are being backed up? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Automating importing sso certificates into chromium/chrome
Hello, I manually generated a new certificate with sso.debian.org, then combined them into a PEM: cat enrico.crt enrico.key > enrico.pem I then tried to import them into chromium using certutil: certutil -d sql:/home/enrico/.pki/nssdb -A -i enrico.pem -n sso.debian.org -t u -u C But the certificate shows up in chrome://settings/certificates under "Other" instead of "Your Certificates". I could not find any combination of -t and -u that would make the certificate show up in the right place. Is there a way to do it automatically with certutil? If so, The process of enrolling with chrome could be easily scripted. Help? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Accepted dballe 7.19-1 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 19 Aug 2016 15:07:21 +0200 Source: dballe Binary: libdballe-dev libdballe-doc libdballe7 libdballef-dev libdballef5 python-dballe python3-dballe dballe-common dballe Architecture: source all amd64 Version: 7.19-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini <enr...@debian.org> Changed-By: Enrico Zini <enr...@debian.org> Description: dballe - Database for punctual meteorological data (Command line tools) dballe-common - Common data files for all DB-All.e modules libdballe-dev - DB-All.e C development library for weather research libdballe-doc - documentation for the DB-ALL.e C library for weather research libdballe7 - DB-ALL.e C shared library for weather research libdballef-dev - DB-All.e Fortran development library for weather research libdballef5 - DB-ALL.e Fortran shared library for weather research python-dballe - DB-ALL.e Python library for weather research python3-dballe - DB-ALL.e Python library for weather research Closes: 834784 Changes: dballe (7.19-1) unstable; urgency=medium . * New upstream version - fixed rounding error on i386. Closes: #834784 Checksums-Sha1: 2e6f6d8d650c4ae8458c9de66b6db68bcfaa599b 2518 dballe_7.19-1.dsc 86355f0e262a89e363ecdd708df22d59e1439040 1573512 dballe_7.19.orig.tar.gz 41fe116dc6834c49a99b4c7fb2c3b558fcf4c40b 10848 dballe_7.19-1.debian.tar.xz e8ae631742287a7cdc4642a275d5ef7356b68de9 40644 dballe-common_7.19-1_all.deb 162e1d6cfeb70911953255c30a5196a447947e30 411646 dballe-dbgsym_7.19-1_amd64.deb 335428e33ebd31ae7d5e3405ee982dc2dc233a76 51788 dballe_7.19-1_amd64.deb 66bbad71b58b28547c02baa86fde06dcfa33bf57 610646 libdballe-dev_7.19-1_amd64.deb 64f8d6189933ebd2587d94dd4b093f4810e479d5 717672 libdballe-doc_7.19-1_all.deb f7ae17177c637ed3119dda0a3c7e254bb3f6f814 6803604 libdballe7-dbgsym_7.19-1_amd64.deb b9ba4ccc69e1e9611bc86f92242e2e9b160bd9ad 398954 libdballe7_7.19-1_amd64.deb 9634838354758ca239b13b005cae1ab0f275a824 64100 libdballef-dev_7.19-1_amd64.deb 0034e89ce0c2c96adc4ead46bd4e10a43cb87675 57720 libdballef5-dbgsym_7.19-1_amd64.deb 513dd761953c67bea3b2f0d77c015afd4188e25b 27810 libdballef5_7.19-1_amd64.deb ebe45eb8ba36cc5ca5da43d9537ca03cca224ba1 285730 python-dballe-dbgsym_7.19-1_amd64.deb b4283b578c0020440c70c860f3c10dbc597e2221 59726 python-dballe_7.19-1_amd64.deb f3cbd89635b3bf72b660f40a99b8ae274be09159 289388 python3-dballe-dbgsym_7.19-1_amd64.deb 16c591d66c8257e593435b6f928a31b5a793 47440 python3-dballe_7.19-1_amd64.deb Checksums-Sha256: 0041b4891ed91c29b2be50273e1239fad04aa51fe9733a6ccd84fbc5f5d09257 2518 dballe_7.19-1.dsc 04a1c129e1200639503deb38f93df6d7db6e054be30ee40ac2e857cef019fdbb 1573512 dballe_7.19.orig.tar.gz a6c777b74b08df42bf238409f96f4d4c5e8843ca6d21575c39c9d28fc4492d85 10848 dballe_7.19-1.debian.tar.xz 92f3c4339266c5716eaf84aa3915f4c1a53abf70750d1c608fb30b6105d80ae5 40644 dballe-common_7.19-1_all.deb 50f09d9425c99e24090f2bd53cd4ff7aaf0a498bcf9e354262ed899e0325b754 411646 dballe-dbgsym_7.19-1_amd64.deb be889933fdb4289ea8bc3413afb65cb017c8d9aadd9f7d15be87972e02d6855c 51788 dballe_7.19-1_amd64.deb 0dcd4d59854dfbcbb7617ddcd101dde7e440c6e408475fae5a44d9e0e73cfdb0 610646 libdballe-dev_7.19-1_amd64.deb fea273ba03c12ed428076255395672f73b8b5aecd0bfafcb7efde451bd78a8c3 717672 libdballe-doc_7.19-1_all.deb 6a110a0faee82263d9497c6d4ef75a0784b5f3eb34f6e3e60e5d81483f6a5834 6803604 libdballe7-dbgsym_7.19-1_amd64.deb 35d0157b7d4493cc2d14fc2ffb0acc0fccc214997da0835f4b70e9fa9f17e4b9 398954 libdballe7_7.19-1_amd64.deb cd547ef4e65f721b2b6d4b3fc40467d2b055df1cb3b2e9d4cfb48aa0b8c31eba 64100 libdballef-dev_7.19-1_amd64.deb b99183d4c27049b9a986e564e80649ccf69141d97e501535c5d96faf679b2d41 57720 libdballef5-dbgsym_7.19-1_amd64.deb f616245cc76ca9cc9b82889402c70a20ff9c3c000d9f1d0e14cd886c19c07190 27810 libdballef5_7.19-1_amd64.deb 9017552b93d1b5edcdb03a0e8b0ada4ffa956ffe04f110247c521c26a4a7a99d 285730 python-dballe-dbgsym_7.19-1_amd64.deb dc2512f491436dd7fddda230e5c6785c9169265d95094d95fc568a413ec94aca 59726 python-dballe_7.19-1_amd64.deb dcd2d6794d8f11c283dba47dbc6130ed6a835aa75fc9e51d24a18b49ba1b72ee 289388 python3-dballe-dbgsym_7.19-1_amd64.deb be897ca8062d659ea2008480f938785c6f8a4fc1b7b3286c1cdf02a0f54c3d28 47440 python3-dballe_7.19-1_amd64.deb Files: a7bac9099487be0fc358c59eebe1a1f7 2518 misc optional dballe_7.19-1.dsc 4b025c8752961bee6fc6f3ed306427f2 1573512 misc optional dballe_7.19.orig.tar.gz 8e0a95e3185d72a30221ea0b036751bd 10848 misc optional dballe_7.19-1.debian.tar.xz bec045ac46c51400d6aa74ee91b46fd8 40644 misc optional dballe-common_7.19-1_all.deb 5e59d9f0270e813f3313b8ffa284bc92 411646 debug extra dballe-dbgsym_7.19-1_amd64.deb 7671a6f2778bc80347462358e2c16585 51788 misc optional dballe_7.19-1_amd64.deb 617adc77fd7d53c29ecbfc4de5d58e4f 610646 libdevel optional libdballe-dev_7.19-1_amd64.deb 161347d411227076902c8d0b61667c28 717672 doc optional libdballe-doc_7.
Accepted dballe 7.18-1 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 18 Aug 2016 16:27:42 +0200 Source: dballe Binary: libdballe-dev libdballe-doc libdballe7 libdballef-dev libdballef5 python-dballe python3-dballe dballe-common dballe Architecture: source all amd64 Version: 7.18-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini <enr...@debian.org> Changed-By: Enrico Zini <enr...@debian.org> Description: dballe - Database for punctual meteorological data (Command line tools) dballe-common - Common data files for all DB-All.e modules libdballe-dev - DB-All.e C development library for weather research libdballe-doc - documentation for the DB-ALL.e C library for weather research libdballe7 - DB-ALL.e C shared library for weather research libdballef-dev - DB-All.e Fortran development library for weather research libdballef5 - DB-ALL.e Fortran shared library for weather research python-dballe - DB-ALL.e Python library for weather research python3-dballe - DB-ALL.e Python library for weather research Changes: dballe (7.18-1) unstable; urgency=medium . * New upstream version - depend on newer libwreport * Added missing help2man dependency Checksums-Sha1: ab2749f52e3f8e339e120ac22d06e515ddadfbb7 2518 dballe_7.18-1.dsc adf8a51962fb1058222a35388b9578ea741f7b70 1573648 dballe_7.18.orig.tar.gz 85092de32021c62b86b6fecc15a26d9d9d59a136 10820 dballe_7.18-1.debian.tar.xz 53b5163eff3c1d632c5a3f3b5d9060f2cf4e8ac6 40638 dballe-common_7.18-1_all.deb 769faffb5cb85850e61ec14ea5f46d954c4af095 411732 dballe-dbgsym_7.18-1_amd64.deb 3ec4d77d63a828be3843afe93874e699518f1b76 51836 dballe_7.18-1_amd64.deb a82fde7aabc02b308fc58a28742c1e455ce5e79e 610390 libdballe-dev_7.18-1_amd64.deb 274426f6baf7ccea10fb1f8c95a261826d39bf7f 717712 libdballe-doc_7.18-1_all.deb 67a2ca52ca43a50c07513bb7d96d871b4ca5288f 6802614 libdballe7-dbgsym_7.18-1_amd64.deb 2fb568cf8aa66b2e921b3b7c4199e90857e0e28e 399008 libdballe7_7.18-1_amd64.deb 6fba4f51ee9b45d728e37e521b755ca14c2b2fcb 64050 libdballef-dev_7.18-1_amd64.deb 47f363ba11d66058e41f9e4e4c5c51cd4d309079 57756 libdballef5-dbgsym_7.18-1_amd64.deb d39a53f9af703a8258073da8ec1decca5642bac6 27822 libdballef5_7.18-1_amd64.deb f101bfc052cc9d7bb876176fee05d6af1c0ea3de 285782 python-dballe-dbgsym_7.18-1_amd64.deb 3bfedc85333f2e2e6ef8ae4fcf739ce2a5dae793 59674 python-dballe_7.18-1_amd64.deb 4c3c26743fb75f27e3dd00e7f2750aa07b247540 289374 python3-dballe-dbgsym_7.18-1_amd64.deb cdd7ae3845a390499ea0548874ebfd465a6de2a4 47348 python3-dballe_7.18-1_amd64.deb Checksums-Sha256: f2d4bd6f4bc95782cf263f83bb476e198533e0f5414cac2c9016ba8820010874 2518 dballe_7.18-1.dsc b96defa6811de320f659fcd83ff19a917efbe0927f789f5395cf8889f7e0f3cb 1573648 dballe_7.18.orig.tar.gz bcf136fa2c9bdbf9b7b1dadb37f7a04072ac0584e6bfacbdbe0174e89d153764 10820 dballe_7.18-1.debian.tar.xz 0e0ff28c92257235ce2ff51e9aa2001f15d4f71b81f602a109117be871c3cc8c 40638 dballe-common_7.18-1_all.deb 197d28cc61ed40f43f3ea4b1885127ae8b9c538861c3a3d570b7c0fb129d674b 411732 dballe-dbgsym_7.18-1_amd64.deb 116a5951c48d63264a31585f801a7db5d86a1993990216fd4d5996b8d6cbed98 51836 dballe_7.18-1_amd64.deb 9a5cb3f7703a5329a4c0318ce62362089cec464fee8548ebf3ca02e57cc8adc0 610390 libdballe-dev_7.18-1_amd64.deb 0059036cd430396b6dfa8baa4fee5f548d58debd51c0b564880b2208196f80d3 717712 libdballe-doc_7.18-1_all.deb f3b7bd39b9c2bbe34897cc263431f26fbde0e86d7cb8cf92167d1f61ee3a396d 6802614 libdballe7-dbgsym_7.18-1_amd64.deb c8c1c6afca35bff496b588ab452b345461a494868a2d14da38164695b72c0688 399008 libdballe7_7.18-1_amd64.deb 4681c29db86a07cf2a44d25c96128f859708d2dddb53cb9d8826a00ffc029824 64050 libdballef-dev_7.18-1_amd64.deb c566256cf7aa65da18881af42024bb9415c90841de7185044b0179483c417172 57756 libdballef5-dbgsym_7.18-1_amd64.deb 98b315e5e509c013c224a6f993e59f8da6b3a85dc86a706e9cc0c3e664f2a736 27822 libdballef5_7.18-1_amd64.deb 20ae0b11df9ddb457157c1a75542bc204c24f0fe646bfae3a33ed90d3406d230 285782 python-dballe-dbgsym_7.18-1_amd64.deb cc5922efa803be7f62b37db51de3c4b7c8196e6f6370c94c9b30b0676f5675bf 59674 python-dballe_7.18-1_amd64.deb 49435eba5e50e841ac804c5e5fbf24022cefadd4834ad7a7e7f9be9adac7c9fe 289374 python3-dballe-dbgsym_7.18-1_amd64.deb 4846243e855840f6c439dbf8854615bf56d2ccc9e62f0cd68cac7263a4b7f25b 47348 python3-dballe_7.18-1_amd64.deb Files: 8beda8d97eff83fa12c9e478dd7be483 2518 misc optional dballe_7.18-1.dsc 8072ed2a5528ee407282bc8807a9c53b 1573648 misc optional dballe_7.18.orig.tar.gz eaf644fdf840eedb000c9402d94730e5 10820 misc optional dballe_7.18-1.debian.tar.xz d9353dfa36fd9d5e4aaa237ed9b927ca 40638 misc optional dballe-common_7.18-1_all.deb 5297ee7bed3756eab3c08a3a3495d22b 411732 debug extra dballe-dbgsym_7.18-1_amd64.deb d3123e7964a8eee84d71ba54000ac25f 51836 misc optional dballe_7.18-1_amd64.deb ba3578aa4b3b00b80ffa51316312ab68 610390 libdevel optional libdballe-dev_7.18-1_amd64.deb cf80d9f15eb12db79caaeb1e010fdf28 717712 doc optional libdballe-doc_7.
Accepted wreport 3.6-1 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 18 Aug 2016 15:32:18 +0200 Source: wreport Binary: libwreport-dev libwreport-doc libwreport3 wreport-common python-wreport python3-wreport Architecture: source amd64 all Version: 3.6-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini <enr...@debian.org> Changed-By: Enrico Zini <enr...@debian.org> Description: libwreport-dev - library for working with weather reports libwreport-doc - documentation for libwreport libwreport3 - shared library for working with weather reports python-wreport - Python library to work with BUFR and CREX weather bulletins python3-wreport - Python library to work with BUFR and CREX weather bulletins wreport-common - common data files for libwreport Changes: wreport (3.6-1) unstable; urgency=medium . * New upstream version - fixed comparing Var values with doubles in test functions * Updated standards-version, no change required Checksums-Sha1: a094f7778cb539ef212f2ff0666ed4bce5a6ed69 wreport_3.6-1.dsc 17c5bc90d7c059b8797956d65a46f3f7d8fa0f4d 2038741 wreport_3.6.orig.tar.gz e895122e90e14d9441fbee93353006ccc9ba21a0 5356 wreport_3.6-1.debian.tar.xz 99ab60805f87c6adc7d925ca6fefc8290a6db514 232630 libwreport-dev_3.6-1_amd64.deb a4263ff3664652bb5030c29c109a9231f3370857 281038 libwreport-doc_3.6-1_all.deb 505b7c44b2fe63539a362b7dc611710aa077be16 1578250 libwreport3-dbgsym_3.6-1_amd64.deb ed946afbb8fdd2120b4648d71d7ce4cd20d41296 150180 libwreport3_3.6-1_amd64.deb 2d5156d5be62f9be0f3d8dcfe242490dbba455b9 123762 python-wreport-dbgsym_3.6-1_amd64.deb 1b773bb333cd7ce81fcd50775e4329626bc1f4d1 25760 python-wreport_3.6-1_amd64.deb f16f5c361f39f01f939ca2f933291527a2f77c32 126798 python3-wreport-dbgsym_3.6-1_amd64.deb b701e97e0fc3e3a64f3f68d711be7134f887f921 25792 python3-wreport_3.6-1_amd64.deb ffbab51bfa6fddf4df4eaeb11624d2d2a0663bbf 150892 wreport-common_3.6-1_amd64.deb Checksums-Sha256: 9a6afe9466cbbbae097768bb935c25c3f4af029190517fa234e9f779d7bcfa9d wreport_3.6-1.dsc 7127c3f71c3666995e3c1b0917da2ea5d9deba4fdff1562abd47a73f70ba1124 2038741 wreport_3.6.orig.tar.gz a6ba41dc8d9fb39ee62aff5b44f11f6e0b20b2eb1062745c446c232beab34b47 5356 wreport_3.6-1.debian.tar.xz 7a09ae374a3cd6a2d18d8d8fc0b13070720af75f8cf9d63d1e47f4c9387c6289 232630 libwreport-dev_3.6-1_amd64.deb d78b1237cd47461428b5e8a0a02ec278709adf9a429455f17349cef01348746b 281038 libwreport-doc_3.6-1_all.deb 705e0b73222d4a56c8e8bd98abcbae148378c31e9c0072a95f98c94d7039b670 1578250 libwreport3-dbgsym_3.6-1_amd64.deb 0863c66178d0f3a5679a6248a176cde07f4e729f81de179de88d4ec4a4ed47e9 150180 libwreport3_3.6-1_amd64.deb 0f42980fd8a7fd445bed4aad84b2f26dca730cf89c29e6d8f9833af6b65e04ff 123762 python-wreport-dbgsym_3.6-1_amd64.deb 25821a2d37938422c7da256a502e25fe517d575dac4c815863ebd09343f2bffe 25760 python-wreport_3.6-1_amd64.deb cbfd579c7425cd762ba7d9808cc12297325ac5dd6d98fd797cde0a1e6e3cc16d 126798 python3-wreport-dbgsym_3.6-1_amd64.deb 452710af5c2e84ab83acf785a5ec5352e8a9ddf0d67e677036630a65084d5142 25792 python3-wreport_3.6-1_amd64.deb 9ba1c85894ab54727c5125624df33c94c3f2111d1806d45b45d4a0d6c8082b6a 150892 wreport-common_3.6-1_amd64.deb Files: 22cbb3effaaab646181c5f70ab91bb5a misc optional wreport_3.6-1.dsc f6cc5fa02cc0b8e4e1f48cc203b95bda 2038741 misc optional wreport_3.6.orig.tar.gz 84d23187c74fa85a9ce368aa9778210c 5356 misc optional wreport_3.6-1.debian.tar.xz 438042c94d9dc5492bc1674323331b62 232630 libdevel optional libwreport-dev_3.6-1_amd64.deb 4a7a4d9bbf9eb2f2bd3eb179e3e5b02c 281038 doc optional libwreport-doc_3.6-1_all.deb 08a80c5928498effe9d4936459d192ef 1578250 debug extra libwreport3-dbgsym_3.6-1_amd64.deb 942b56c05ee056c58fe0902bb33f303d 150180 libs optional libwreport3_3.6-1_amd64.deb 7f57c62db81778e99d0fea4c747aef23 123762 debug extra python-wreport-dbgsym_3.6-1_amd64.deb 8273de777046f44e75033c0259a79a5f 25760 python optional python-wreport_3.6-1_amd64.deb 3d77c88aed7fa078129b7f478d38fee5 126798 debug extra python3-wreport-dbgsym_3.6-1_amd64.deb 77e083ed76bdcfe5e0ca2dee210d19a9 25792 python optional python3-wreport_3.6-1_amd64.deb 1b9c820cf6df050bb52f3eb20a14738e 150892 misc optional wreport-common_3.6-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJXtcZPAAoJEAPWVoyDcnWp8gsP/RfP74Cn/vuP2s0tiEXA3sLb qeWijeK/QoBWmGmnVHkq6EQZCpj7/NiLVZyDQHZnR/f56/fQnUfVj4Xldp9wXaKe dgOx+GYUDPdIJ3mUjmM4/mwy2yCI+QCo0uh2EYJD8dJ2YiD4QVwL7d0c6r1UmBn1 sv5WAkZwOdQi6pqLbW3gaLVZ4ELd8U/pmGm44pdbFv9OvjSpW/iENLOk+SVtvYr0 HvrO8ulygYlUscaiNSU29K1XYpJKg8LS2NfMho6f7P1jEJWmnVC6fWFjxEZipAYf 2lR+lVMUcqVppFDz11/G4BEcyvfuDGu6Zwdxu5Gm2CQ68rsCMr5997HXoxn+Gqd8 OqKSC15+Nepo9ahTtf2Aak/HV7i/AknhdSBe7nXBk5rUB5za5DwX91QjsXmbymNk FLmK88sU0k0u9Ph9a7TbfJ05RrOqCK6VVAHOHrnk6A3azK8yxKlImIZ0qBZRDhFb QIQVbtBee6f7Ikf1cbHFUoJ1uviH5BzYNzH5YtVAhXG1WJBlglPd4ZRDyL12RH1f fVAfcJVk9l4tG32yriqT2xCUDDClGNWTokHt+6xMYgcBQEFdhpzG6JWqnqg2TEmT QoKPGsEIymBUMon
Accepted dballe 7.17-1 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 18 Aug 2016 11:11:43 +0200 Source: dballe Binary: libdballe-dev libdballe-doc libdballe7 libdballef-dev libdballef5 python-dballe python3-dballe dballe-common dballe Architecture: source all amd64 Version: 7.17-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini <enr...@debian.org> Changed-By: Enrico Zini <enr...@debian.org> Description: dballe - Database for punctual meteorological data (Command line tools) dballe-common - Common data files for all DB-All.e modules libdballe-dev - DB-All.e C development library for weather research libdballe-doc - documentation for the DB-ALL.e C library for weather research libdballe7 - DB-ALL.e C shared library for weather research libdballef-dev - DB-All.e Fortran development library for weather research libdballef5 - DB-ALL.e Fortran shared library for weather research python-dballe - DB-ALL.e Python library for weather research python3-dballe - DB-ALL.e Python library for weather research Changes: dballe (7.17-1) unstable; urgency=medium . * New upstream version - fixed build failures on 32bit machines Checksums-Sha1: ba76247ec33bf34e6766dc7590b83519e7a01152 2508 dballe_7.17-1.dsc 30af4d50f3276217c3184aac931c102db9d0a70d 1573562 dballe_7.17.orig.tar.gz 9cfe62c3eccf1b5dd85b91227d7496b6d08bb0b3 10804 dballe_7.17-1.debian.tar.xz e3519b900520ba0c0fc555afeff610cfdc59aa3c 40596 dballe-common_7.17-1_all.deb 01501847b370644161b16d13835b8e27d6fb4fa5 411740 dballe-dbgsym_7.17-1_amd64.deb 4d79b2db259f5f9c62d879473fa161c1affcd4bf 51764 dballe_7.17-1_amd64.deb 037f43542dfcb890c5f55b26dea4f2649b770f22 610272 libdballe-dev_7.17-1_amd64.deb 7f6206b6c922d60ff15cff8a3ff20def675dfe99 719662 libdballe-doc_7.17-1_all.deb 5d068f4f379e16e37051defaa89bfe0d20207d73 6802324 libdballe7-dbgsym_7.17-1_amd64.deb 277d561c592951dd719bb32fb5fedd6aa1e6bbc5 398962 libdballe7_7.17-1_amd64.deb bba55836693f3f332d9358048c933d3fe62cd196 63980 libdballef-dev_7.17-1_amd64.deb e9329035ed0ebd98d8f000915640a3c3e717c321 57770 libdballef5-dbgsym_7.17-1_amd64.deb d8b84e572d9143a3637717aa37f278ed7513a203 27778 libdballef5_7.17-1_amd64.deb 5dfc4088dce8b8c1181cd366edff0c300808b86a 285716 python-dballe-dbgsym_7.17-1_amd64.deb 68249fd76de64a79aed3be82cdf3935a21e45f42 59630 python-dballe_7.17-1_amd64.deb 6a3c0fdffca27a3137aead505de6902526dbd653 289370 python3-dballe-dbgsym_7.17-1_amd64.deb ff418b8b817b01d2df4437f09ba7419d80fb5093 47312 python3-dballe_7.17-1_amd64.deb Checksums-Sha256: cbe18e72d0292faad8896fcf1c0543dcf00047e6c50c79bc30e3096e6f32384f 2508 dballe_7.17-1.dsc 76a6a3986b5f9eb3c98595f113dd7432b961087ed3637235069e9e2fcb7635f8 1573562 dballe_7.17.orig.tar.gz 5e2879d3415daec0cc8312a44fd0d953c288fad8014a9157b270527dd47a74de 10804 dballe_7.17-1.debian.tar.xz b0b35607ffa41b06ff0417da3642dbfcba9a444e191aee712ebb894b15fbae77 40596 dballe-common_7.17-1_all.deb ee3bb76a33a56f94039db9028de126cd438ff44454cd30a0f60d43a7ae30cdfe 411740 dballe-dbgsym_7.17-1_amd64.deb e52958a26d461beb390b977f20e87b4b2b10ffedad15b10b87f9653213403119 51764 dballe_7.17-1_amd64.deb 1831134830c36f0aff93b118c252468b489bbb62abe0ac1a480e1caf655c1d2e 610272 libdballe-dev_7.17-1_amd64.deb 95a4d7ed87883cd13594ccd10d52d94bac56f2529e1989ffd561f3d89788bb56 719662 libdballe-doc_7.17-1_all.deb ab84f8bac3f7bf10fec5450ce5886850d8a7088f0e3baec81dd0d577d42441f1 6802324 libdballe7-dbgsym_7.17-1_amd64.deb c460b28d9f64e3e45e890203220a66c2b4522136d510fa4c4a9d0b65a1666b9b 398962 libdballe7_7.17-1_amd64.deb cc7c474cc72eeeb04672b970c290bdbd6498927a1fc958c10e0b81bc974db72d 63980 libdballef-dev_7.17-1_amd64.deb 3ef36e9730c4f0a3bf0b2758aa61af457cb4d995b46804bb143e6f0abb3b2869 57770 libdballef5-dbgsym_7.17-1_amd64.deb 19df1d3706f89b06c9e674ddf7e12a7be79ba4a7ba2f34e2e2818845e988a49c 27778 libdballef5_7.17-1_amd64.deb 5817b6e0fb1a64d9ae96d010ef4e85cdd2ec1c3728b07fead73932d93ea0a25e 285716 python-dballe-dbgsym_7.17-1_amd64.deb 540535399ea1819269f9cfb2d6fdb048391f86437c3ddfca8fcfd3b4bdedaac1 59630 python-dballe_7.17-1_amd64.deb cf350866f29dd9d46202822f06bc0cc152a72860ae78d0147f5b78e292651f94 289370 python3-dballe-dbgsym_7.17-1_amd64.deb 194b94229cfecba7f2f4c58210a2b4f24aa672b36e7b843d20a6c5b788379bdb 47312 python3-dballe_7.17-1_amd64.deb Files: f7b6403c76c4f3595d9726f78326899a 2508 misc optional dballe_7.17-1.dsc 759a4f7f50347bd8ac44abd8ba66e2e0 1573562 misc optional dballe_7.17.orig.tar.gz 78e981250b8050936009a465ae13e1de 10804 misc optional dballe_7.17-1.debian.tar.xz b69a23c04a4a847111848578f816d610 40596 misc optional dballe-common_7.17-1_all.deb 995b21beee8ec638fa8dbb2af5697be9 411740 debug extra dballe-dbgsym_7.17-1_amd64.deb db0b89984e52d4336e0e01db983c99d4 51764 misc optional dballe_7.17-1_amd64.deb fe45d480a461817a7e116804147eedb1 610272 libdevel optional libdballe-dev_7.17-1_amd64.deb 63258c2123e60798f7df063b68590379 719662 doc optional libdballe-doc_7.
Accepted dballe 7.16-1 (source all amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 17 Aug 2016 11:09:02 +0200 Source: dballe Binary: libdballe-dev libdballe-doc libdballe7 libdballef-dev libdballef5 python-dballe python3-dballe dballe-common dballe Architecture: source all amd64 Version: 7.16-1 Distribution: unstable Urgency: medium Maintainer: Enrico Zini <enr...@debian.org> Changed-By: Enrico Zini <enr...@debian.org> Description: dballe - Database for punctual meteorological data (Command line tools) dballe-common - Common data files for all DB-All.e modules libdballe-dev - DB-All.e C development library for weather research libdballe-doc - documentation for the DB-ALL.e C library for weather research libdballe7 - DB-ALL.e C shared library for weather research libdballef-dev - DB-All.e Fortran development library for weather research libdballef5 - DB-ALL.e Fortran shared library for weather research python-dballe - DB-ALL.e Python library for weather research python3-dballe - DB-ALL.e Python library for weather research Changes: dballe (7.16-1) unstable; urgency=medium . * New upstream version - Redone documentation from LaTeX to Markdown - Introduced new SQL schema "V7" - Refactored Fortran bindings to not need CNF * Dropped LaTeX dependencies * Dropped CNF dependency * Increased libdballef soname * Updated Standards-Version, no changes required Checksums-Sha1: 1558a9a292ffdda8a30abe75aa4aa3433151b4f2 2508 dballe_7.16-1.dsc 01eb9b042883d0a254c8e94e095afaebed0ffe5b 1573640 dballe_7.16.orig.tar.gz 192155cf0334ae460ba5169b58dcad189ca88ee5 10760 dballe_7.16-1.debian.tar.xz 1183ead113945c79463478fa12c641a399a28b80 40624 dballe-common_7.16-1_all.deb e354ad3c47ef0227d849f940a0b54d619dc93a1c 411630 dballe-dbgsym_7.16-1_amd64.deb 05973709aa37a00258212785dbcc0eca5b8b3590 51736 dballe_7.16-1_amd64.deb e32c6c0a548f6d0e5ea7027d9d07b2b5130cd619 610154 libdballe-dev_7.16-1_amd64.deb e0ef99fa4e816504b1c61248b906d5dcc40e1645 719656 libdballe-doc_7.16-1_all.deb 88514c8e3092227ac8cc255689de1c1800bb2cba 6803090 libdballe7-dbgsym_7.16-1_amd64.deb 343fb5b4dc4169b38b57c5305ac5272f3ae0a61f 398328 libdballe7_7.16-1_amd64.deb f62e55af85b1e8b4a91234380b65b77d0c68c6c6 63956 libdballef-dev_7.16-1_amd64.deb 5f8e07822773acd4b5a98a3f722d5f573585b05d 57762 libdballef5-dbgsym_7.16-1_amd64.deb bbd72aeac2239d244c661d8c61588beab0a67d29 27714 libdballef5_7.16-1_amd64.deb 7c2f4608d6bd4422bebe1e7584bdaa2992489bb8 285786 python-dballe-dbgsym_7.16-1_amd64.deb b4060a2a9263a9141ffc476f952fc6e4bc7bd7c0 59646 python-dballe_7.16-1_amd64.deb 10c83e099e736a4acd4d78a4c16646e82be8821d 289350 python3-dballe-dbgsym_7.16-1_amd64.deb 148e8e013cbb6f34b265d53dcd1ebdd15381bc56 47364 python3-dballe_7.16-1_amd64.deb Checksums-Sha256: 9c6b8bf708789ef4d6c61e15882e5ac4f45f4682f81e6c0ea8fcc060846257f6 2508 dballe_7.16-1.dsc 676802e728397d0f54e7875ce0f11fbba4db66dae5fc4ffa53a14b19890c47f2 1573640 dballe_7.16.orig.tar.gz 87206d95c6a5b043a72a820f54f375ccc176e9290f90b7907e5e566029f1049e 10760 dballe_7.16-1.debian.tar.xz 99ffc5dcc5b0b99bb2def11bfefd2c9100188649644981445b6625ff3d504a53 40624 dballe-common_7.16-1_all.deb fd3df5785086961231e9d01277d719a3d38f06283a19976827fca5a67908d33d 411630 dballe-dbgsym_7.16-1_amd64.deb ba7a8f8bd30655b406dddf49649a6ac1b5748ee9c9eff82cc01dba019ab6e437 51736 dballe_7.16-1_amd64.deb 303fd68f7bb2d05663db2daed495f7808863baf315f05f443a32fb9eeb473e69 610154 libdballe-dev_7.16-1_amd64.deb 53d0610509b896183c1f5d8e489ad5337c4ea602c9f7c3aece8b1844502f1629 719656 libdballe-doc_7.16-1_all.deb 680f582fbc764214f7b12ae7578f1b1c521474a8443b996f58ff541ddfe50178 6803090 libdballe7-dbgsym_7.16-1_amd64.deb e3d3ac1c8fcdfdcfc75daf75badd2927b03668324753724587f301456a6a92c1 398328 libdballe7_7.16-1_amd64.deb 51675cb8304ea5fd2cd587c1ad94565988b916ec20e15a0e494a8c4d050c57b4 63956 libdballef-dev_7.16-1_amd64.deb 0cf2f308bccf04035cc4210a3dec13784f12fdd689ddd312b9038d6ddae5586f 57762 libdballef5-dbgsym_7.16-1_amd64.deb e09a3ba2ad1fa2979a178d7cdc9bce3704f69dce56f8d08526e6906629b2632a 27714 libdballef5_7.16-1_amd64.deb c687d584231bb118a985918fa065bde30612acc99dda9b4095d535cae9d33e0b 285786 python-dballe-dbgsym_7.16-1_amd64.deb a290c7dde36c123e1390af792309d69bbb6c09689fc91478cd739c3e66710b3e 59646 python-dballe_7.16-1_amd64.deb e81cd1add79ad1e7e98d6c6b3373a0f0cca57ce7ee60cd6f4b98517fd09e3ec3 289350 python3-dballe-dbgsym_7.16-1_amd64.deb 4585da9d113d99dea21c190e1b8f999b0cbc0a85f9e6a085610c0a0d70b9c749 47364 python3-dballe_7.16-1_amd64.deb Files: ae109eb73f1b1490b490b8998072f74c 2508 misc optional dballe_7.16-1.dsc d61b5ff825a410ae48064159f6e2072a 1573640 misc optional dballe_7.16.orig.tar.gz 14b8e291ec6bdbac2792b7d47924cbf4 10760 misc optional dballe_7.16-1.debian.tar.xz c9abcfbaf30c17c41c14e3196b50aa3f 40624 misc optional dballe-common_7.16-1_all.deb 66887ed05b9b7ea763a8fc6a9a6d8057 411630 debug extra dballe-dbgsym_7.16-1_amd64.deb 29dd2d303b
Accepted staticsite 0.4-1 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jul 2016 12:22:22 +0200 Source: staticsite Binary: staticsite Architecture: source all Version: 0.4-1 Distribution: unstable Urgency: low Maintainer: Enrico Zini <enr...@debian.org> Changed-By: Enrico Zini <enr...@debian.org> Description: staticsite - Static site generator Closes: 830582 Changes: staticsite (0.4-1) unstable; urgency=low . * Initial version. Closes: #830582. Checksums-Sha1: fb189b454b3fec30217e398733cb1d6a5bd878da 2020 staticsite_0.4-1.dsc 64196f6946d8bee469b5d09f86586bf6ffabe94d 448208 staticsite_0.4.orig.tar.gz cd821036386d790d405c50a09fda658d70100a7b 1716 staticsite_0.4-1.debian.tar.xz 8149e6b90c21636c973615f8a62810823d252152 33094 staticsite_0.4-1_all.deb Checksums-Sha256: e746a83b2e8ff92132b5bcb896e30494b1eacdc95ac89e20cf786832ebca7e53 2020 staticsite_0.4-1.dsc f0c0814600370ec77ecd05f0b0db0a8c874b960d6dffb8360b788721477babfc 448208 staticsite_0.4.orig.tar.gz 95fa49c0776b9c75e0ae01955b6cfbfab73d87c5c341514df751e0a18761b2f2 1716 staticsite_0.4-1.debian.tar.xz 8e1cc674706502e3461c4693a1ea38f415f3e08363fde7fa7449efe1bb0b6260 33094 staticsite_0.4-1_all.deb Files: 5ddc1d0b80caf0fe6edaf8c8367e8407 2020 web optional staticsite_0.4-1.dsc 0e0710aa219f259f095da6e28fb083d6 448208 web optional staticsite_0.4.orig.tar.gz cdc49b0f982b8eafa95122d2511d5114 1716 web optional staticsite_0.4-1.debian.tar.xz c46d8d4fc59e676bc25c683a3b85b772 33094 web optional staticsite_0.4-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJXgiLcAAoJEAPWVoyDcnWpQ8IP/2wdsecG9mpqZNgf7o4YvU0y y5ZODUv3lIk1ODnkTDZ3d4XDJb4clcWURxktr0uHYrP68a4bblsc2tJGbXBZYyZ9 qCC48y7A3xq6ncebn0f5fBBgNl8hCNLi9ZrgY+qE58JBpNuHghQPws0iONT29MDC 1IO8iGUSE1QbppaLRgoaWnDHNK7ZrKd+cEoDZTsjkYiXfpaa0xYRSiArw7ZVpwfN QgMmI58PX9t4xdTy0mkG0cv4AWu2F6kmg+zb9EPrjYndTPLW2vdVaF0O1B3WTjlk DkQKmTWko2kTrqb3KRFSK4bz/OyVbawkmHTmQkQPguMsobrdPmL2REbOF8syHm0s N/nO/mD51cYpKEGD6neMhV3jgpRhJanrvST8RuPkmbZ8TUPoXSqJVwSacaE8eqV/ 4mr5PyEJJyFsy3flzyNsHpFjBGTUpjgxPgI7ZZBsDYurG0cIyyXL81oIq6YbRm5R dubHC+dGOZ+LK2cBxFfWihy2yWHJH6ajxEbGeNGpHsvKxInfRhD+f4syy1O0fpb0 mnKuwoRD6fk4Xer/gAS6f9Ehjcvtuc58CatCB1ofyDJ8EwiyP1NZlZLRbTXEXFPW V+FUr5hLOG35KJ+2IjfqBYynEkXcNYIKgWkQ9d/yIjWfHc2QSOnvnz26eyuycWYa QGv3ZsMthnVBFyS5Vevx =wUxc -END PGP SIGNATURE-
Re: Replacing web assets with symlinks to packaged versions
On Sat, Jul 09, 2016 at 02:06:36PM +0100, Ian Jackson wrote: > As I understand it, your problem is that: > > * Upstream wants the upstream tarball to contain a copy of bootstrap > * Debian wants the copy of bootstrap removed from the source package > * But none of our source formats can replace files with symlinks ? > > ? It turns out that Debian does not want the copy of bootstrap removed from the source package, and that it's ok to just replace them with symlinks using dh_link. That lowers massively the bar, and my level of despair. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Bug#830582: ITP: staticsite -- Static site generator
Package: wnpp Severity: wishlist Owner: Enrico Zini <enr...@debian.org> * Package name: staticsite Version : 0.4 Upstream Author : Enrico Zini <enr...@debian.org> * URL : https://github.com/spanezz/staticsite * License : GPL Programming Lang: Python Description : Static site generator Static site generator based on markdown and jinja2. . Features: - themable - free content structure - hugo-style archetypes and front matter - live preview server I wrote this, have been using it for some months, so far I'm very happy with it, and I'd like to see what happens if I try and share it with the world. The reason I ended up writing yet another static site generator is here: http://www.enricozini.org/blog/2016/static-site-generators/ and more information about it is here: http://www.enricozini.org/tags/ssite/ and here: https://github.com/spanezz/staticsite#staticsite Some people have expressed interest in it, but were put off by it not being in Debian. Since now, thanks to Hugo Lefeuvre[1], all its dependencies are in Debian, I'm giving it a try. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816727 Enrico
Re: Replacing web assets with symlinks to packaged versions
On Sat, Jul 09, 2016 at 08:00:48AM -0700, Josh Triplett wrote: > > On ശനി 09 ജൂലൈ 2016 07:01 വൈകു, Pirate Praveen wrote: > > > You just add a links file in your package to replace the js to symlinks. > > > And add dependency on the js package. > > > That's all you'll need. [...] > No, you don't have to remove bundled third-party software from the > source package unless it doesn't have a Free Software license. > Third-party Free Software packages can stay in the source package; you > just want to have the binary package use the packaged versions instead. Perfect, thank you both, that seems to solve my problem entirely, and it's far far easier than I feared at first. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Replacing web assets with symlinks to packaged versions
Hello, as upstream of https://github.com/spanezz/staticsite I want it so that when people git clone it or open a tarball of it, it just works, with no need of installing twitter bootstrap in example/theme manually. As Debian packager of it, I want twitter bootstrap in example/theme to be symlinks to what's in libjs-twitter-bootstrap. As both, I do not want to have to build two tarballs or something weird like that. We already use fakeroot to tweak the view of the file system when building packages. How about a similar trick for web assets? Could we have another LD_PRELOAD hack that replaced instances of jquery.min.js to symlinks to libjs-jquery contents? I drafted a proof of concept here, as a FUSE file system, because it was easy to do by tweaking a passthrough FUSE filesystem example: https://github.com/spanezz/debassets Could someone pick this up and turn it into something that integrated well with our toolchain, so that I can turn my staticsite tarballs into Debian packages with minimal effort, and so could everyone else[1]? Enrico [1] Alternatively, could someone package staticsite for me, and I can stop worrying about this? :) -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
