Re: Validating tarballs against git repositories

[Vincent Bernat]

On 2024-04-01 12:44, Bastian Blank wrote:


So in the end you still need to manually review all the stuff that the
tarball contains extra to the git.  And for that I don't see that it
actually gives some helping hands and makes it easier.

So I really don't see how this makes the problem in hand any better.
Again the workload of review is on the person doing the job.  Aka we do
fragile manual work instead of possibly failing automatic work.


I think that if Debian was using git instead of the generated tarball, 
this part of the backdoor would have just been included in the git 
repository as well. If we were able to magically switch everything to 
git (and we won't, we are not even able to agree on simpler stuff), I 
don't think it would have prevented the attack.

Firmwares (was Re: Bits from the DPL)

[Vincent Bernat]

On 2024-04-01 18:05, Jonathan Carter wrote:

The included firmware contributed to Debian 12 being a huge success,
but it wasn't the only factor.


Unfortunately, the shipped firmwares are now almost a year old, 
including for unstable. I am following the progress since quite a few 
years and I have seen many possible contributors trying to help and 
fail. The current situation is that Debian does not work well with 
recent AMD-based laptops due to firmware being too old. Therefore, we 
are back at users trying to update the firmware by copying them from 
random places (as for myself, I am using the deb generated by upstream's 
Makefile).


My personal impression is that we are repeating a common scheme in 
Debian: maintainers don't have time to move forward due to the task 
being non-trivial for reasons of our own, people are proposing to help 
(6 people in [1]), but this is ignored by the maintainers as they don't 
have time.


[1]: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests

Re: inability to resolve localhost to 127.0.0.1 in IPv6-only environments

[Vincent Bernat]

On 2023-12-01 12:30, Simon McVittie wrote:

This does not prevent to have 127.0.0.1. I don't think this is a good use of
time to fix builds broken because there is no IPv4 loopback. This is the
same kind of artificial conditions as the 1-core builders.

Unfortunately, no, it's a bit more complicated than that.


Thanks for your explanation on that!

I retract my position about building on IPv6-only environments and agree 
you should be able to build with an IPv6-only connectivity.

Re: Clarification for broken packages in IPv6-only environments

[Vincent Bernat]

On 2023-11-30 22:42, Dale Richards wrote:

I recently submitted a patch for uvloop that was FTBFS on IPv6-only
builds (#1024079) and it really didn't take very long. While
building/running in IPv6-only environments is not currently mandated in
the Policy it's a fairly safe bet that it could/should be in future
updates, so it makes sense to start making all packages agnostic of IP
version now.


This one seems to be because localhost was resolved to ::1, which is not 
Debian-default configuration where localhost is 127.0.0.1. Also, the 
patch is overly complex and is not upstreamed. While correct (even if 
the original test was testing with and without name resolution), this 
may become a maintenance hurdle in the future.

Re: Clarification for broken packages in IPv6-only environments

[Vincent Bernat]

On 2023-11-30 21:38, Paul Tagliamonte wrote:


Now I would like to know if being able to run in an IPv6-only environment is
a must have feature for any debian package?


I run an IPv6 only LAN on my home network, where I use `jool`, and
`dns64-prefix`+`unbound` to interoperate with legacy IP space. There's
no assigned IPv4 addresses for hosts on that LAN.


This does not prevent to have 127.0.0.1. I don't think this is a good 
use of time to fix builds broken because there is no IPv4 loopback. This 
is the same kind of artificial conditions as the 1-core builders.

Re: Bug#1052004: libcbor: requires source-only upload to transition

[Vincent Bernat]

On 2023-09-15 21:04, Sebastian Ramacher wrote:

Source: libcbor
Version: 0.10.2-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://qa.debian.org/excuses.php?package=libcbor

Issues preventing migration:

 Not built on buildd: arch amd64 binaries uploaded by bernat
 Not built on buildd: arch all binaries uploaded by bernat, a new 
source-only upload is needed to allow migration


What's the status of throwing away the binaries when doing a 
non-source-only upload? This is a major pain point for me. You upload 
the package a first time as a source-only upload and get an error 15 
minutes later telling you it's NEW and you have to do a binary upload. 
Then, it gets accepted and you need another source-only upload.

Re: Potential MBF: packages failing to build twice in a row

[Vincent Bernat]

On 2023-08-10 14:38, Lucas Nussbaum wrote:

On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:

Are we ready to call for consensus on dropping the requirement that
`debian/rules clean; dpkg-source -b` shall work or is anyone interested
in sending lots of patches for this?


My reading of the discussion is that there's sufficient interest for
ensuring that building-source-after-successful-binary-build works.


There is a bias asking d-devel@. You'll get people with enough time on 
their hands to care about this. Nobody ever complained about not being 
able to build twice in a row for years. We are asking a lot of people to 
fix problems that don't really exist.


I don't have time to deal with the amount of bug reported against my own 
packages (most of them with Python) and just having the social pressure 
to spend time on them make me wonder if I really want to invest time at 
all. If these bugs become RC, so be it.

Re: Potential MBF: packages failing to build twice in a row

[Vincent Bernat]

On 2023-08-05 17:06, Lucas Nussbaum wrote:
Should we give up on requiring a 'clean' target that works? After all, 
when 17% of packages are failing, it means that many maintainers don't 
depend on it in their workflow.


Yes, please, this does not make sense anymore to enforce such a rule 
when it is now easy to use "git clean -fxd" or to build in a chroot. 
Moreover, binary packages in the archive are now built by an official 
builder.

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Vincent Bernat]

On 2023-07-12 07:54, Gioele Barabucci wrote:


1) It's an extra layer. [...]

2) It's a layer that you cannot ignore when editing the config. [...]


I'd also add 3) It requires Python and various Python libraries. At 
least the CLI tool does.


In some circumstances installing Python and a bunch of libraries is not 
going to be a big issue (e.g., in desktop installs), but for many server 
installations that is an unnecessary new burden.


(To be fair, Lukas opened his email stating that for minimal 
installations sd-netwokd is a more fitting alternative. I just wanted to 
explicitly mention one reason supporting that statement.)


If Python is an option, ifupdown2 is IMO a far better candidate than 
netplan:


1. It reuses the familiar syntax we have with ifupdown
2. It knows how to converge to the provided configuration from the 
running configuration (this makes notably the trivial workflow "let's 
modify the IP address of this interface" just works, but more complex 
scenario like "let's put this interface and IP address in a VLAN on a 
bond devices").


It has been some time since the latest release (almost 3 years), but it 
looks still maintained.

Re: Please, minimize your build chroots

[Vincent Bernat]

On 2023-01-28 13:59, Adrian Bunk wrote:

I am not saying that trying to force maintainers to spend time on such
issues by making them release critical is better, but you are also
creating extra work and frustration for the people who are doing QA work
in Debian.


It also pushes some maintainers to give up on packages. I gave up on 
maintaining any Go package after the whole "everything should compile 
with only one CPU because policy says so" fiasco. The most rare resource 
we have is volunteer time. Creating artificial problems is not helping.

Re: Please, minimize your build chroots

[Vincent Bernat]

On 2023-01-28 00:20, Santiago Vila wrote:

Release Policy exists as a canonical list of what should be RC and > what not, 
and it's intended to avoid stupid discussions like this one.


Extending build-essential is easier than asking many people to do 
pointless work to satisfy a set of non-existing users. It is not like we 
had several reports of people complaining they can't build a package 
because they are in an environment without tzdata. It is not OK to 
create problems to force many volunteers to do extra work.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Bernat]

On 2022-09-29 15:01, Michael Stone wrote:

On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote:

* Finally, I can use bluetooth on linux with reasonably good audio
 quality!


Aren't they both using the same backend? ldac/aptx weren't in pulseaudio 
for a long time, but they are now. Or is there something else?


Pipewire has AAC, but not in Debian because libfdk-aac is still 
considered non-free by us while everyone else, including the FSF, 
consider it free.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Bernat]

On 2022-09-09 04:51, Paul Wise wrote:

On Thu, 2022-09-08 at 17:58 +0200, Dylan Aïssi wrote:


I have been asked several times regarding when Debian will switch its default
sound server from PulseAudio to PipeWire without having an official answer.
Thus, I suppose it's the right time to start a discussion about that.


I switched to PipeWire some time ago. I don't have particularly complex
audio needs (just AUX/headphones on a desktop). When the system is
under load and the CPU throttled, I get choppy audio, which is
especially annoying when the load is caused by a video. That doesn't
happen with PulseAudio and setting the quantum to 2048 is a workaround.

pw-metadata -n settings 0 clock.force-quantum 2048

Probably there are more of these sorts of issues, so I agree we should
switch to it by default sooner rather than later to find the problems.


I also had this issue. This was greatly improved since May and I am now 
using it instead of PulseAudio. Check that you have rtkit-daemon 
installed. It helps.

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

[Vincent Bernat]

On 2022-08-27 15:53, M. Zhou wrote:


That's why I still hope ftp team to recruit more people. This is
a very direct and constructive way to speed up everything.
More volunteers = higher bandwidth.
Recruiting more people doesn't seem to have a serious disadvantage.


It does not seem to work. Either people don't want to do that, either 
the FTP team is too picky on the candidates.



I forecast this thread will eventually end up with
"calm down and take a break" solution again.


Yes. Unhappy people will just continue to silently wind down their 
involvement in Debian.

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

[Vincent Bernat]

On 2022-08-19 23:14, Andrea Pappacoda wrote:

Would alternatives really be that bad? What if the current /usr/bin/muon 
was moved to /usr/bin/muon-kde, muon-build was installed to 
/usr/bin/muon-build and /usr/bin/muon was shared between the two 
packages? What issues could it cause?


I don't think users really invoke KDE Muon via the terminal that often 
anyway, it is a Graphical APT frontend...


I think your best bet is to ask KDE maintainers if they can rename the 
executable on their side. As it is likely started from a .desktop, they 
may not mind that.

Re: A mail relay server for Debian Members is live

[Vincent Bernat]

On 2022-07-16 23:49, Pierre-Elliott Bécue wrote:

In the past months, it's been clear that sending mails from an
@debian.org address to some mail providers, including GMail, has become
harder and harder. While user DKIM feature (documented on [0]) can help,
we thought providing a relay server for our users to send their Debian
mail was a more long-term solution.

This service is now operational behind mail-submit.debian.org (AKA
stravinsky.debian.org). Documentation about how to use this service can
be accessed via [1]. The page behind [0] will be updated on the next
release we make of userdir-ldap-cgi.

Mails sent via this server will be DKIM-signed if the from is a
debian.org, debconf.org or ftp-master.debian.org address. If any
additional domain should be considered, feel free to ask.

This server requires an active Debian Account, and that one sets their
mailPassword up (again, see [1]) to be able to use the service. I've
tried to provide some useful tips on the doc.

If you have any question or issue, please don't hesitate to reach out.


Hey!

Would it be possible to also make it available on port 465 without 
STARTTLS? I am using smtp_tls_security_level=secure and 
smtp_tls_wrappermode=yes with my other providers and having 
mail-submit.debian.org on top of that is adding a bit of complexity that 
I would like to avoid if possible.


Thanks.

Re: A mail relay server for Debian Members is live

[Vincent Bernat]

On 2022-07-17 10:29, Dominik George wrote:


tl;dr: DKIM-signed mail is verifiable, but only the headers; the body can be 
tampered with


That's not true. The body is always part of the signature (in a strict 
or relaxed way).


> The Signer/Verifier MUST compute two hashes: one over the body of the
> message and one over the selected header fields of the message.

Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Vincent Bernat]

On 2022-07-14 17:14, Russ Allbery wrote:

(Also, due to the limitations and history of naming conventions, the
software is inherently trying to map into a gender binary, which if one is
attempting to capture self-identification is likely to be unhelpful for
many populations, such as ones with lots of people under 30, due to not
having a way to represent nonbinary people.)


This one does not. It maps a first name to male, female, androgynous, 
mostly make, mostly female, or unknown.

Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Vincent Bernat]

On 6/30/22 16:16, Sam Hartman wrote:


However there are some other features from the ITP:

-Support NTLS (formal GM dual-certificate protocol) handshake processing, 
according to GB/T 38636-2020
TLCP
-QUIC API support


Is it compatible with QuicTLS, which is another fork of OpenSSL? Some 
context here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011391. 
QuicTLS has some users already: curl, haproxy, apache, nodejs, ngtcp2.

Re: Firmware: Scope of non-free-firmware

[Vincent Bernat]

 ❦ 10 May 2022 14:30 -06, Sam Hartman:

> 2) We value being able to build from source when we can. We value
> being able to have reproducible builds when we can. We don't want to
> take steps backward in those areas in order to get hardware working
> better.

Is there any firmware that would match this? This seems like a
complication without any current application.

> As a reminder, firmware does sometimes run on the CPU (microcode, UEFI),
> sometimes is software, sometimes is more like data.

I see microcode as a firmware for the CPU. It is loaded into the CPU and
is not executed by the CPU in the regular way (loaded in memory, PC
point to it). We do not distribute non-free UEFI implementation and I
don't see how it would help to use hardware (usually, this is shipped
with the hardware). All the firmwares we are interested in are the ones
that get loaded to a piece of hardware.

[...]
> * Proprietary Nvidia graphics drivers.
>
> Personally I think most if not all of the above are in the same category
> as firmware at least in terms of how I think about them and software
> freedom.

This is quite a stretch. Maybe discuss this later. Otherwise, we will
never have anything.
-- 
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan & Plauger)

Re: faciliter la contribution ?

[Vincent Bernat]

 ❦  2 April 2022 16:53 +02, Jérémy Lal:

>> > En fait reportbug fait aussi fuir certains développeurs debian
>>
>> je metterais bien les pieds dedans pour en extraire les parties
>> intéressantes mais c'est du python: un vrai tueur de toute motivation
>> chez moi.
>>
>
> Du perl:
> https://salsa.debian.org/debbugs-team/debbugs/-/tree/master/lib/Debbugs

Le code de reportbug est ici : https://salsa.debian.org/reportbug-team/reportbug
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Seeking consensus for some changes in adduser

[Vincent Bernat]

 ❦ 10 March 2022 11:34 -05, Michael Stone:

 On systems that don't use usergroups for all/some users, doesn't this
 change make all files writable by other users by default?  That would
 seem like a very unsecure change on upgrades (or as a default).
>>>
>>> AFAIK systems that don't use usergroups are already not running in
>>> standard Debian configuration, since we default to USERGROUPS_ENAB being
>>> 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf).
>>
>>Has it always been the case? On my oldest system, my primary group is "users".
>
> It was always configurable, but was enabled out of the box in hamm...

My system was installed on Potato if I remember correctly (or maybe
Woody, but definitely not older than Potato). But maybe my home was
imported from a SuSE installation and I tweaked something.
-- 
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Seeking consensus for some changes in adduser

[Vincent Bernat]

 ❦ 10 March 2022 11:21 +01, Philip Hands:

>> On systems that don't use usergroups for all/some users, doesn't this
>> change make all files writable by other users by default?  That would
>> seem like a very unsecure change on upgrades (or as a default).
>
> AFAIK systems that don't use usergroups are already not running in
> standard Debian configuration, since we default to USERGROUPS_ENAB being
> 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf).

Has it always been the case? On my oldest system, my primary group is "users".
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Bug#1006885: ITP: lumin -- pattern match highlighter

[Vincent Bernat]

 ❦  7 March 2022 18:33 +01, Adam Borowski:

>> lumin highlights matches to a specified pattern (string or regular
>> expression) in files, using color. This is similar to grep with
>> colorized output, but it outputs all lines in the given files, not
>> only matching lines.
>
> .--[ ~/bin/hl ]
> #!/bin/sh
> sed 's/'"$*"'/\c[[1;33m&\c[[0m/g'
> `

grep --color -C4000 pattern

There are other suggestions here:
https://stackoverflow.com/questions/981601/colorized-grep-viewing-the-entire-file-with-highlighted-matches
-- 
Let the data structure the program.
- The Elements of Programming Style (Kernighan & Plauger)

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Vincent Bernat]

 ❦ 14 February 2022 22:39 +01, Jonas Smedegaard:

> I am trying hard to read good faith into your last sentence above, but 
> have quite some difficulty reading as anything but you describing 
> unbundling as inevitably leading to disaster.

That's how you should read it.

> Maybe my point was unclear, so let me try again: When maintaining a 
> package with embedded code copies, then please if giving up on 
> unbundling at least file RFP bugreports so that others can help.  Help 
> *you* the package maintainer, who has the final say on when and how such 
> separately packaged dependencies is used to *improve* your maintenance 
> (not make your work harder or drive you towards giving up).

The current state of Chromium is that it wasn't able to catch with
security updates for months (even before Bullseye release). Adding more
source-dependencies is a recipe to make it even more difficult to
provide timely updates.

As I don't maintain Chromium, my opinion has little weight. I am just
stating it to counter-balance the peer pressure on the subject.
-- 
Write clearly - don't sacrifice clarity for "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Vincent Bernat]

 ❦ 14 February 2022 10:56 +01, Jonas Smedegaard:

>> I've finally give up and am just using ALL the bundled node packages: 
>> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
>> 
>
>> It's not ideal, but at least with this we'll match all of the node 
>> stuff with what upstream is testing, with the single exception of 
>> nodejs itself (which we're still using from debian). The only other 
>> alternative I can think of is to get all the node packages into 
>> debian, and they'd also need to be backported to bullseye. I haven't 
>> looked into this yet, but it might be necessary if upstream breaks 
>> compatibility with nodejs 12. So, uh, if anyone is bored and looking 
>> for some node packages to maintain :)
>
> I fully recognize the pain of maintaining a big package and then on top 
> of that paying attention to packaging a pile of Node.js modules.
>
> It is also, however, a pain to maintain a pile of Node.js modules and 
> then on top of that paying attention to big packages struggling with 
> bundled Node.js modules.
>
> Suggestion: Please consider filing RFP bugreports for each Node.js 
> module that you give up on unbundling.  That is far more helpful towards 
> delegating the work than mentioning deep inside a mailinglist thread 
> without "help needed packaging Node.js modules" as subject.
>
> A next step (independent, not necessarily by you) could then be to 
> user-tag RFP bugs tied to unbundling, to help prioritize those among the 
> many WNPP bugreports.

Unbundling also means that each update may require waiting for many
dependencies, leaving users vulnerable in the meantime. Firefox has a
very good track record with updating both in unstable and in stable
thanks to glandium uploading new version the day after the release. I
don't know what the bundling state is, but even with such a good track
record, it sometimes lag a bit behind upstream due to dependencies.
Currently, Firefox 97 is waiting for a rust update and nothing seems to
go forward. Once someone will move forward, it seems we will have to
also wait a bit on the NEW queue due to the rust update (most of the
time, I think rust gets quickly approved in a day or two). I have myself
switched to the binaries provided by Mozilla. I'll switch back once
unstable is up-to-date again because I am confident this won't happen
often, but I suppose at some point, I will switch to the Flatpak, like I
did for Chromium.

My point is that packaging dependencies independently will just lead us
to difficult to package browsers with maintainers giving up.
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Unplanned freeze?

[Vincent Bernat]

 ❦ 28 January 2022 22:52 +01, Sebastian Ramacher:

>> > http://bugs.debian.org/1004272
>> > I agree that it should have been announced somewhere in addition to the
>> > #debian-devel topic.
>> 
>> Running unstable, are we at risk having problems? Are the packages
>> updated in the last few days being rebuilt?
>
> All potentially affected packages have been rebuilt over the last couple
> of days.

Great, thanks!
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Unplanned freeze?

[Vincent Bernat]

 ❦ 28 January 2022 12:34 +05, Andrey Rahmatullin:

> http://bugs.debian.org/1004272
> I agree that it should have been announced somewhere in addition to the
> #debian-devel topic.

Running unstable, are we at risk having problems? Are the packages
updated in the last few days being rebuilt?
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Cloud team plans for cloud-hosted mirrors

[Vincent Bernat]

 ❦ 26 January 2022 10:04 +01, Marc Haber:

>>> Are the IP ranges of the Cloud Providers registered that badly that
>>> deb.debian.org wouldn't reliably point to the mirrors inside the
>>> provider's infrastructure? Or are the cloud providers' mirrors
>>> differnet from what we expect from a Debian mirror?
>>
>>deb.debian.org is served from fastly and AWS CDNs - so it's outside of most
>>cloud provider's infrastructure.
>
> So it is not possible to hook arbitrary mirrors into deb.debian.org
> and we're dependent on Fastly and AWS here?
>
> I thought it was something more flexible.

This was redir.debian.org. I was very happy with it. I never understood
why we replaced it by something centralized. There were problems with it
and nobody was fixing them, but I think we have never been told exactly
what the problems were. But I can understand how using an external CDN
is less a burden than maintaining a redirector like our customn one or
something like MirrorBrain (not packaged in Debian but used by many open
source projects).

deb.debian.org is just a CNAME to Fastly.

At my location (France, 1st ISP, FTTH; was the same in Switzerland),
Fastly is very slow from time to time (once every two months? less than
100 KB/s). Their support fix it in a day or two once you tell them. I
have switched back to geographic mirrors: ftp.fr and ftp.ch never failed
to deliver good performance.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Vincent Bernat]

 ❦ 25 January 2022 21:51 +01, Jonas Smedegaard:

>> I didn't comment at first because I thought someone else would raise 
>> the idea. But it seems people still like the idea of a NEW queue. Not 
>> me. The NEW queue is a hindrance.
>
> For the record, I don't "like" the NEW queue.
>
> I don't like current copyright laws, and I suspect a fair amount of 
> people involved in Free Software doesn't.
>
> I just don't think the solution is to ignore copyright or licensing 
> statements.

I mentioned it. No need to ignore, just file regular bugs. I said:

> For me, the copyright check is just a bad excuse. People upload
> non-distributable stuff everywhere and it seems the world continue to
> go round. What amount of non-distributable packages is stopped by the
> NEW queue?
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Vincent Bernat]

 ❦ 21 January 2022 09:51 -05, M. Zhou:

> I'd rather propose choice C. Because I to some extent understand
> both sides who support either A or B. I maintain bulky C++ packages,
> and I also had a little experience reviewing packages on behalf of
> ftp-team.

I didn't comment at first because I thought someone else would raise the
idea. But it seems people still like the idea of a NEW queue. Not me.
The NEW queue is a hindrance. I have stopped contributing to Python
stuff for this reason. Packaging something can take weeks because you
need to upload one package, wait for it to be reviewed, then package the
next one, etc. You could upload many packages at once, but it makes
testing and building more difficult. New contributors may just give up
by the time their first package is accepted. I think we have many
unmaintained packages for this reason (no real stats on my side, but
when a package is several versions late, it's usually a sponsored upload
or one of my packages).

I would propose that there should be a reputation system. You can get
points by uploading stuff without issues and lose them if there are
errors. If you have enough points, you can spend them to skip the check.
But someone would have to implement it and the team being understaffed
for whatever reason (and maybe not convinced by this system), I know
this won't be done (we don't have PPA because FTP team wants to
implement it but no time, we don't have autosigned packages because
nobody has time to implement it, etc).

For me, the copyright check is just a bad excuse. People upload
non-distributable stuff everywhere and it seems the world continue to go
round. What amount of non-distributable packages is stopped by the NEW
queue?

I think we should forego the NEW queue. If people want to check
packages, they can do it once they are in unstable with regular bugs.
Current checks are partly done by Lintian and I suppose people could
watch new Lintian warnings and detect bad packages quickly. This could
be done when src is not NEW as a test. People could loose their upload
rights if they are caught abusing the system (and get DM rights for some
selected packages instead). This could be opt-in if people find this
idea offensive.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)

Re: ungoogled-chromium?

[Vincent Bernat]

 ❦  7 December 2021 23:35 GMT, Simon McVittie:

> I believe what Vincent meant is that the generic non-Flatpak binaries
> provided by the "Ungoogled Chromium" project are compiled on unknown
> machines and require trusting their submitters, whereas the Flatpak
> binaries provided by Flathub are compiled from the same source
> code provided by the "Ungoogled Chromium" project, but compiled on
> Flathub infrastructure.

Yes.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)

Re: ungoogled-chromium?

[Vincent Bernat]

 ❦  7 December 2021 21:46 +01, Mathias Behrle:

>> (I have been running an ungoogled-chromium for a while (ca. a year 
>> ago?), however at that time their chrome wasn't extremely stable so I 
>> gave up again. Does anybody have experience using it recently?)
>
> (Using chromium only as fallback browser if necessary):
>
> Since the removal of chromium from Debian was announced I gave 
> UngoogledChromium
> on flatpak a try and it runs very stable so far.

Same here. And they are now following security updates closely (in the
past, there could lag two or three weeks behind). Flatpak compiles it
from source (while UngoogledChromium let contributors compile it and
publish the binary because GitHub CI does not allow such resource-heavy
build).
-- 
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 13:04 -05, Richard Laager:

> Are you saying "everything breaks" as in:
> A) the change is not applied (correctly) in the way that it would be if
>the system was rebooted, or
> B) the change is applied, but the human made a mistake in the config and
>the change breaks things, or
> C) B + the human gets cut off from e.g. SSH due to the error?
>
> I would say (generally) that A is a bug, B is inherent to any tooling
> applying a human's instructions, and C can be addressed by a rollback 
> function.
>
> `netplan try` covers C (and thus also B).
>
> `netplan apply` (and thus `netplan try`) have a caveat that they don't
> remove virtual devices that are no longer described in the config.
> This feels like an example of A, though it's arguable how much it
> matters.

I am saying: remove the IP address from an interface, move it to a VLAN
instead. You'll get a duplicate IP.

>> ifupdown2
>> is smart and will converge to the new configuration. Network Manager can
>> restart and minimize impact. AFAIK, systemd-networkd is as dumb as
>> ifupdown and does not know how to converge.
>
> What does converge mean in this context? Is something needing to apply
> parts of the changes iteratively to arrive at the desired state?

It makes a diff between the current system state and the desired state
and applies actions to move to this state. The current system state
could be from a previous application of the tool or from manual action
from the operator, it does not matter (this is a second advantage of
such a tool). The above situation is handled perfectly.

>> My point is that ifupdown2 was a possible successor to ifupdown but was
>> never adopted because written in Python. As netplan is written in
>> Python, ifupdown2 seems a far better replacement.
> Am I understanding correctly that ifupdown2 is an alternative to
> systemd-networkd and NetworkManager (as opposed to netplan, which is a 
> layer on top of them)?

Yes.
-- 
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 11:16 -05, Richard Laager:

>>> As to what should be the distro default, I'm not sure I am convinced
>>> either way, but to argue the other side... There is some value in
>>> using netplan by default. Some random thoughts:
>> [...]
>> OTOH, netplan is just an abstraction above existing systems
>
> Agreed.
>
>> and does not
>> allow proper reconfiguration.
> What do you mean?

Make a change, reload your configuration, everything breaks. ifupdown2
is smart and will converge to the new configuration. Network Manager can
restart and minimize impact. AFAIK, systemd-networkd is as dumb as
ifupdown and does not know how to converge.

My point is that ifupdown2 was a possible successor to ifupdown but was
never adopted because written in Python. As netplan is written in
Python, ifupdown2 seems a far better replacement.
-- 
... A solemn, unsmiling, sanctimonious old iceberg who looked like he
was waiting for a vacancy in the Trinity.
-- Mark Twain

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 01:29 -05, Richard Laager:

> As to what should be the distro default, I'm not sure I am convinced
> either way, but to argue the other side... There is some value in
> using netplan by default. Some random thoughts:
[...]

OTOH, netplan is just an abstraction above existing systems and does not
allow proper reconfiguration. ifupdown2 is also written in Python and
has an implementation of "ifreload -a" which just works.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 10:31 +02, Ansgar:

>> I give myself password less sudo to "apt update" (without additional
>> options), "apt upgrade" (same), "apt full-upgrade" (same). I was
>> thinking this should be safe, but now I need to check if the pager is
>> properly restricted when displaying NEWS file.
>
> These are not safe to be run under `sudo` without giving the invoking
> user full access. As a random example: dpkg's conffile prompt offers to
> open a shell.

Ack. I'll avoid this from now on.
-- 
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 11:38 +05, Andrey Rahmatullin:

>> >> I just ran across this article
>> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> >> the attacks on Debian 11 and they work successfully giving me a root
>> >> shell prompt.
>> > I don't think calling this "privilege escalation" or "attack" is correct.
>> > The premise of the post is "the user should not be a root/admin user but
>> > has been assigned sudo permissions to run the package manager" and one
>> > doesn't really need a long article to prove that it's not secure.
>> 
>> I think the article is interesting nonetheless. Some people may think
>> that granting sudo on apt is OK. 
> Some people may think granting sudo to vim is OK, but we need to educate
> in general that some programs can run other programs, and so restricted
> sudo is not as restricted as it sounds.

That's the point of the article, isn't it? Your example is how I got
fast-forwarded admin when I was at school/uni. So, it's unlikely to
change.
-- 
Habit is habit, and not to be flung out of the window by any man, but coaxed
down-stairs a step at a time.
-- Mark Twain, "Pudd'nhead Wilson's Calendar

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:

>> I just ran across this article
>> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> the attacks on Debian 11 and they work successfully giving me a root
>> shell prompt.
> I don't think calling this "privilege escalation" or "attack" is correct.
> The premise of the post is "the user should not be a root/admin user but
> has been assigned sudo permissions to run the package manager" and one
> doesn't really need a long article to prove that it's not secure.

I think the article is interesting nonetheless. Some people may think
that granting sudo on apt is OK. In the past, I think "apt install
./something.deb" was not possible.

I give myself password less sudo to "apt update" (without additional
options), "apt upgrade" (same), "apt full-upgrade" (same). I was
thinking this should be safe, but now I need to check if the pager is
properly restricted when displaying NEWS file. A similar
"vulnerability" was fixed in systemd:

 - https://gtfobins.github.io/gtfobins/systemctl/
 - 
https://github.com/keszybz/systemd/commit/612ebf6c913dd0e4197c44909cb3157f5c51a2f0

Maybe it would be worth to also set LESSSECURE (less is not the default
pager on minimal installs but I think it is the most common, more cannot
be secured this way).
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Vincent Bernat]

 ❦ 11 August 2021 11:27 +02, Steffen Möller:

> I have no exact idea what to change, though. A rolling Debian would be
> cool, yes, but also a bit late when compared with environments that
> Conda offers or the ease that comes with multiple installations of conda
> to e.g. avoid name conflicts. If we had a chroot for which you do not
> need to be root, then together with snapshot.d.o we would be darn close
> to what Conda is offering. I have no idea how to get there, though. With
> singularity maybe?

We package only a very small subset of Conda, I don't see in what
universe we could be competitive, rolling or not rolling.

I think we have more systemic issues. I am quite impressed how Nix/NixOS
is able to pull so many packages and modules with so few people. But
they use only one workflow, one way to package, one init system, etc.
Looking at Arch, one workflow, one way to package, one init system, etc.
Looking at Fedora, one workflow, one way to package, one init system.
Let me take again the example with Nix. Anyone can do a simple pull
request and gets its change accepted. Each package has a maintainer, but
the ownership is quite weak. The maintainer may say no, but if they are
just busy, someone else may merge the change if it looks reasonable.

In Debian, we have many workflow (BTS, MR to submit changes, Git, not
Git, Git workflow 1, Git workflow 2, Git workflow 3), many ways to
package (just one makefile, old debhelper, new dh), many init systems.
And the ownership problem prevents people to help from time to time.
There are so many packages I come accross that could just be updated to
a more recent version and looks like semi-abandoned but I just don't try
any more because there are so many ways to fail.

I still trust Debian to be the most technically excellent distribution,
but that's not all it makes to stay relevant. My point is that it would
help to reduce the technical liberties we take in Debian. However, I
don't think that's who we are.

Today, it is very difficult to only use Debian own packages. We just
tell people "just add random repositories". Nix and Arch are able to
have almost everything packaged. Nix is able to include into a single
workflow most other language ecosystems.
-- 
The last thing one knows in constructing a work is what to put first.
-- Blaise Pascal

Re: Making Debian available

[Vincent Bernat]

 ❦ 23 janvier 2021 15:39 +02, Jonathan Carter:

> But the sentiment above and in other similar messages were that the
> completely free images are broken for many users that might need some
> non-free firmware. This is simply not true. I've only ever installed
> using the free images, and then afterwards just install the firmware
> packages I actually need. On all my thinkpads this was typically just
> the intel wifi firmware, which is super quick and simple, on my AMD
> laptop I needed some amd graphics firmware which wasn't on the media,
> but also a very quick install and it works flawlessly, so I think
> implying that the free images are completely unusable for people who
> might need firmware is an unreasonably large stretch. I also like that I
> know exactly which non-free firmware packages are installed on my
> system.

This is an anecdotical evidence. To my knowledge, it's not possible to
make a wireless card work without a proprietary firmware. As laptops are
getting thinner, the Ethernet port is getting away and dongles to get
port the RJ45 port are not bundled anymore.

> Again, I'm not saying that there shouldn't be images that contain
> non-free firmware, but dismissing the images that don't have firmware on
> as useless is harmful and misleading.

If a novice user is presented with "download this image if you need
non-free firmware", "download this image otherwise", they will likely
choose the second, won't they? We would just succeed in confusing our
users and send them to a more friendly distribution.

As for myself, firmwares were burnt in a ROM before, they didn't get
less free by being side-loaded but at least they can now be updated. So,
I really don't care about how many firmwares I have on my laptop.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [External] Re: Intel SOF audio firmware packaging

[Vincent Bernat]

 ❦ 11 décembre 2020 20:36 -05, Mark Pearson:

>> They seem to say future releases will be tagged. So, I think you should
>> use in gbp.conf:
>> 
>> upstream-tag = v%(version%~%-)s
>> pristine-tar = False
>> 
>> No need for upstream-branch since you won't use "gbp import-orig" as the
>> origin lives directly in git repository.
>> 
> Got it - I've made these changes and pushed them to the repository

You need to use "~rc" instead of "-rc", otherwise, users won't be able
to upgrade to "1.6" when they have "1.6-rc3" installed.

#v+
diff --git a/debian/changelog b/debian/changelog
index 1b404ac5e2e6..a5a29a905188 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-firmware-sof (1.6-rc3-1) UNRELEASED; urgency=medium
+firmware-sof (1.6~rc3-1) UNRELEASED; urgency=medium

   * Initial release. (Closes: #960788)

diff --git a/debian/gbp.conf b/debian/gbp.conf
index 12bd6acf629c..ac06bdd3b375 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,5 @@
 [DEFAULT]
 debian-branch = debian/latest
-upstream-tag = v%(version%-%-)s
+upstream-tag = v%(version%~%-)s
 pristine-tar = False

#v-

> What do I need to do going forward to look after this? Is there anything
> in particular that is needed as new sof firmware is released? Just
> wanting to check what expectations are going forward and if there is
> anything I should be looking out for etc.

We wait until monday and then we can upload. When a new firmware is
released, you upgrade your repository on Salsa, ping me, I'll review and
upload. At some point, you may want to become a DM (Debian Maintainer)
to do upload of known packages yourself.

>> Also, did you test the package on real hardware or do you need me to
>> test it? I can test it, I just need to spend 10 minutes doing it.
> Tested on my X1Carbon7 and it works well. I have a bunch of other
> platforms I can try it on too if that helps but it will have to be next
> week.

No need, I'll test it on mine during the week-end.
-- 
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Re: [External] Re: Intel SOF audio firmware packaging

[Vincent Bernat]

owner 960788 markpear...@lenovo.com
quit

 ❦ 11 décembre 2020 12:15 -05, Mark Pearson:

>>> I did have to comment out "overlay = True" in the gbp.conf - it gave me
>>> an error that I'll have to dig into.
>> 
>> That's because you went for the first "classic" solution. I was pushing
>> for the overlay solution as the upstream git repository is pushing some
>> big files at each release and your git repository will become bigger and
>> bigger. With the overlay solution, you only have a debian/latest branch
>> and the user is expected to retrieve the tarball to make it work (this
>> is automated by uscan, thanks to the debian/watch).
> Ah - that makes sense.
> Should I be looking at changing what I've done or is the current
> solution OK? I'd like to get it as right as it can be.
>> 
>> However, you can keep your repository as is and add to gbp.conf:
>> 
>> upstream-branch = stable-v1.6
>> upstream-tag = v1.6-rc3
>> pristine-tar = False
> Great - I've updated the repository with this change. Thank you.
>> 
>> This should do the trick. You may want to tag the upstream commit
>> yourself with upstream/1.6 if you upstream is not consistent with
>> tagging (which seems the case).
> I'm not sure what I need to do here - do I create a tag on my repository
> with the name 1.6 on the v1.6-rc3 branch?
> Just want to make sure I do the right steps :)

Well, for all these questions, upstream versioning strategy is
confusing. There is the branch stable-v1.6. There is the v1.6-rc3 which
is not part of the stable-v1.6 branch. We need to have a stable version
number. Either the branch stable-v1.6 doesn't move anymore or there are
tags, but upstream is inconsistent because there is no tag others than
v1.6-rc3. Other users are complaining about this as well:

https://github.com/thesofproject/sof-bin/issues/25

They seem to say future releases will be tagged. So, I think you should
use in gbp.conf:

upstream-tag = v%(version%~%-)s
pristine-tar = False

No need for upstream-branch since you won't use "gbp import-orig" as the
origin lives directly in git repository.

And you need to use 1.6~rc3-1 in debian/changelog since this is the
version you are packaging (1.6~rc3 and the -1 is the Debian part).
1.6~rc3 orders before 1.6 while 1.6-rc3 orders after, that's why we want
to use "~", while upstream uses "-".

Also, debian/watch is incorrect as it is watching branches instead of tags.
You need to fix it with:

version=4
opts="filenamemangle=s%(?:.*?)?v?(\d.*)\.tar\.gz%@PACKAGE@-$1.tar.gz%;s%-rc%~rc%"
 \
 https://github.com/thesofproject/sof-bin/tags \
 (?:.*?/)?v?(\d.*)\.tar\.gz debian uupdate

You can test with "uscan --report --verbose".

As for using an overlay or not, let's stick to your current strategy. If
the repository becomes too big, it's always possible to start a new one.
Not using an overlay is easier for everybody since it's the most common
workflow.

>> You may want to either rename firmware-sof-signed.install to install or
>> rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is
>> missing at the top of the postinst script.
> I think I've fixed this now

You also added "#v+" and "#v-" markers. It was not part of the file.
Some mailers use this to mark code blocks, that's why I have added them.
It was unclear, sorry.

Also, nitpicking, but either use:

 - firmware-sof-signed.install and firmware-sof-signed.postinst
 - install and postinst

Since you have only one binary package, it's equivalent, but it's just
better to not mix the two.

Everything else looks good.

> As I understand it the next step is to find a DM or DD who can sponsor
> this? Any recommendations on how that process works?

Usually, you can go through mentors.debian.net, upload your package
there and file an "RFS" (request for sponsor). But you don't really need
to do that as I can upload it for you. So, fix the last details above,
I'll do another review and I'll upload if anything is correct.

Also, did you test the package on real hardware or do you need me to
test it? I can test it, I just need to spend 10 minutes doing it.

We should also take over the RFS. We were a bit fast in this process. I
am doing that in this email as well for you (with you as owner). We'll
wait a few days if anyone protests.
-- 
Be careful of reading health books, you might die of a misprint.
-- Mark Twain

Re: [External] Re: Intel SOF audio firmware packaging

[Vincent Bernat]

 ❦ 10 décembre 2020 12:57 -05, Mark Pearson:

> I did have to comment out "overlay = True" in the gbp.conf - it gave me
> an error that I'll have to dig into.

That's because you went for the first "classic" solution. I was pushing
for the overlay solution as the upstream git repository is pushing some
big files at each release and your git repository will become bigger and
bigger. With the overlay solution, you only have a debian/latest branch
and the user is expected to retrieve the tarball to make it work (this
is automated by uscan, thanks to the debian/watch).

However, you can keep your repository as is and add to gbp.conf:

upstream-branch = stable-v1.6
upstream-tag = v1.6-rc3
pristine-tar = False

This should do the trick. You may want to tag the upstream commit
yourself with upstream/1.6 if you upstream is not consistent with
tagging (which seems the case).

You may want to either rename firmware-sof-signed.install to install or
rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is
missing at the top of the postinst script.

Most firmware-* packages seem to ship to /lib/firmware, not
/usr/lib/firmware. As I am using a usr-merged system (this is the
default now), I don't see a difference. From my understanding, in the
future, packages need to ship this way. I think Linux will look into
/lib/firmware only and therefore, this will fail on non-usr-merged
systems. You can fix that by modifying the install file with:

builddir/usr/lib /

In debian/control, you also need to add Vcs-Browser and Vcs-Git fields
to point to Salsa. Also, maybe the source pakcage could be
`firmware-sof` instead of sof-bin, to match your repository name. Just
update debian/control and debian/changelog.

Everything else looks OK for me.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Intel SOF audio firmware packaging

[Vincent Bernat]

 ❦  7 décembre 2020 08:57 -05, Mark Pearson:

> I'd like to solve the lack of Intel SOF audio firmware & topology
> files being available on Debian - I know it's impacting a lot of users
> on some of the newer Thinkpads. I figured I should have a stab at this
> exercise myself and see what happens.
>
> I did a bit of reading this weekend, and started the process. Having
> created appropriate files under a debian sub-dir, and messed around a 
> bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of
> the sof-bin git repo I end up with a .deb file that I can install and 
> makes audio work. Feels like progress :)
>
> There are plenty of warnings along the way, and it's my first time
> doing this so I'm sure I'm doing all sorts of things wrong (there
> seems like a lot of different options on how to do this); but I
> figured I have a good starting point. I wasn't sure where to go with
> this next.
>
> Is there anybody in the Debian community with the expertise to spend a
> bit of time guiding me through the next steps? I think I need someone 
> who can review what I have done and point out where it needs
> fixing/improving. Once it's good enough then I think I need someone to 
> help me actually get it uploaded and into Debian. There is a bug
> already available (https://bugs.debian.org/960788) if that helps.
> Obviously happy to share all the work I've done in an appropriate
> format if that helps too.
>
> Note - I'm new to packaging, I'm not a SOF expert and I'm not a DM or
> a DD - so someone with patience for dumbass questions would be a
> bonus.

Hello Mark,

I can help you, using the easy way: shipping binary firmwares as
non-free. I don't think this is worth the effort trying to compile from
source while it is not possible to use the compiled firmwares.

You can either use salsa.debian.org or mentors.debian.net to expose your
current work. Tell me if it means something for you or if I need to
explain.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)

Chromium outdated in unstable

[Vincent Bernat]

Hey!

Chromium is stuck at version 81.0.4044.92 since April. Current stable is
83.0.4103.97 and, like often, it includes many security fixes. It seems
Michael is not currently available and no work is done to update
Chromium to the latest version, both in unstable and stable. Is there
someone familiar enough about the process to update, build and test
Chromium?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958450
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: default email client from gsettings

[Vincent Bernat]

 ❦  4 mai 2020 11:23 +02, Jeff:

> The Fedora maintainer for a package for which I am upstream has pointed
> out that it still uses gconftool or gconftool-2, which is way out of
> date and should use gsettings[1].
>
> Unfortunately, my search engine foo is failing me and I can't find the
> right incantation to get gsettings to tell me the default email client.
>
> Would someone mind putting me on the right track?

Maybe:

 xdg-mime query default "x-scheme-handler/mailto"

But unsure if it uses something from gsettings.
-- 
As to the Adjective: when in doubt, strike it out.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Re: Salsa update: no more "-guest" and more

[Vincent Bernat]

 ❦ 26 avril 2020 15:04 -07, Russ Allbery:

>> This is not how this is implemented. I am using GitHub and GitLab with
>> 2FA enabled and I am rarely asked to enter any token. Once you get
>> authenticated on a device, it remains for a long time.
>
> Pretty much every time I go to salsa.debian.org, I have to log back in
> again.  The "long time" seems subjectively to be a week or two (or maybe a
> month).  Am I doing something wrong?

You are right. I don't have this issue on hosted gitlab.com, but maybe
it's because I work with it everyday. I have just enabled 2FA on Salsa.
I'll see if you also have to reenter 2FA each time.
-- 
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Salsa update: no more "-guest" and more

[Vincent Bernat]

 ❦ 26 avril 2020 20:29 +00, Jeremy Stanley:

> You're already seeing quite a few folks responding that being
> required to use an additional application or device each time they
> authenticate would be an inconvenience to them. This is a signal. I
> personally wouldn't enjoy being prompted to activate my TOTP client
> software every time I invoke `git push` so I can understand the
> resistance to your proposal.

This is not how this is implemented. I am using GitHub and GitLab with
2FA enabled and I am rarely asked to enter any token. Once you get
authenticated on a device, it remains for a long time. The model threat
is to prevent someone stealing your password through
phishing/spying/guessing to login into your account. SSH keys being
asymmetrical, they are not covered by this.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#958908: ITP: bgpq4 -- automatic BGP filter generator using IRR routing data

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: bgpq4
  Version : 0.0.6
  Upstream Author : Job Snijders
* URL : https://github.com/bgp/bgpq4
* License : BSD 2-clause
  Programming Lang: C
  Description : automatic BGP filter generator using IRR routing data

bgpq4 eases BGP filter maintenance by automatically generating prefix
lists, (extended) access lists, policy statement terms and AS-path lists
using RADB data. It features IPv6 prefix-/access-list support,
aggregation of generated filters and output compatible with Cisco,
Juniper, Mikrotik, Nokia, OpenBGPD and BIRD.

It is a fork of bgpq3.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl6lpMkSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5Bw8P/007Ol3MXLxs2b68J0nxz0wLsqw4q+Cb
WMEdff8Hw2isNQuBkaZmOIcR19v7SjuLH1cYi/GgJEtBtTvxSrU/j85/+OHz5wY8
VwAhM8I7qBigwlyvH2GoWq119RyEAcDP+mH+0dekwiG5Rq60m9TuTpaKjx1fkkP2
Q5Zxz+GIxf2XXYOMoDF9ekJIS1H0gh6zqniQS5PV5zmkk7Yc5wI+0ar8QmuiAGMa
8ihn+o0NpANRCOmaRhFpTb/I0CoCX1pw0lpuPTeIQreKddyEKrFLRGjAnOOHQy/r
FarNfDd7ql0RZcU+MSND/KIxy5zSyrY3KdGDi9FunZ6fIGegSMRRWADUtX8waqwF
LmgaGeNZ06va2AvUUp6uBd7qAmHi0I1QzLRY2zDIKkPckOhbqAkB1NYYU9jUjcgc
pyLzy0cyxV4oKawjLB2kuN8tgzJCQRVLiEjze9sFO8tIB3Zb+of6yZiHI9GbI3gD
QUPii0rqZkzwegxbUHXm0l3VbnYC4xqHGhW1SjlZTGnE/Q7uTNBl8UIIbwe8YbpK
DrRJGuLnwZwhYQb0FutfPyEbaLFs7vV7VxhNZ8xGfoK8emDRQuJbyq0aPpBtZGiA
UUycJgn31Itjp6ZBzt4mekD2OOlIBqyrr7lWfjwdiv2TYKrrd71cJ7XvE/Ggo3gT
XHpzescaJu/S
=4Oxg
-END PGP SIGNATURE-

Re: Salsa update: no more "-guest" and more

[Vincent Bernat]

 ❦ 26 avril 2020 14:07 +02, Bernd Zeimetz:

> There are even cli tools that do the same stuff. I'd guess there is at
> least one on Debian.

There is oathtool.
-- 
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 25 mars 2020 15:57 +01, Jonas Smedegaard:

>> rpm packages record the package license information in a one-line License:
>> field.
>
> Is your point that 9 lines can be reduced to one, or that 100 lines can 
> be reduced to one?
>
> It is legal in Debian to write debian/copyright files looking like
> this:

Redhat also drops the license files in /usr/share/licenses/packagename
without much structure.
-- 
Don't over-comment.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: new kubernetes packaging

[Vincent Bernat]

 ❦ 24 mars 2020 16:30 -07, Russ Allbery:

> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes extensive use of the fact that different packages can
> pin to different versions and this doesn't matter for their intended
> output format (a static binary).

Go supports shared libraries since quite some time but I don't think
it's widely used. Notably, the tooling around it is quite primitive.
Even the plugin system (which is mostly like dlopen() and could be
useful in many cases) is seldomly used.
-- 
This night methinks is but the daylight sick.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: new kubernetes packaging

[Vincent Bernat]

 ❦ 24 mars 2020 16:30 -07, Russ Allbery:

> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes extensive use of the fact that different packages can
> pin to different versions and this doesn't matter for their intended
> output format (a static binary).

Go supports shared libraries but I don't think it's widely used.
Notably, the tooling around it is quite primitive.
>
> Trying to shoehorn the latter into a shared library update model is almost
> certain to fail because it's working at intense cross-purposes to
> upstream.
>
>> This isn't necessarily such a new thing - the scale is new, but the
>> practice isn't. There are several C/C++ libraries in Debian that are
>> specifically designed to be vendored into dependent projects (either
>> because they are not API-stable or to simplify dependency management),
>> like gnulib (which exists as a package, but I think it's only there to
>> facilitate vendoring bits of it?), libstb (which does exist as a
>> separate package with a shared library, but I don't have a good picture
>> of how API- and ABI-stable it is), and libglnx.
>
> Indeed, I have a package, rra-c-util, which is vendored into every C
> package that I personally maintain and package, because it's my version of
> gnulib plus some other utility functions.  I recognize the potential
> concern should a security vulnerability be found in any of its functions,
> and accept the cost of providing security updates for every one of my
> packages that use it.  This still is, in my opinion, a better maintenance
> choice, not so much for Debian but for many non-Debian users of those C
> packages who do not want to (and often get confused by trying to) install
> a shared library as a prerequisite to installing the thing they actually
> care about.  (Also because, like gnulib, rra-c-util consists of a lot of
> different pieces, most of which are not needed for any given package, and
> includes pieces like Autoconf machinery that are tricky to maintain
> separately.)

-- 
This night methinks is but the daylight sick.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 24 mars 2020 14:18 +01, Julien Puydt:

>> There are other reasons, notably that you speed up builds by having
>> all the source code ready.
>
> Sorry, I don't know much about how go works, but : can't the developer
> just have the deps ready -- and just not commit them to the repo and
> not ship them?

These projects heavily rely on automated builds. Depending on platform,
it may or may not be easy to have shared cache for these builds. If they
have, you have to debug them as well. From their point of view, it's
simpler to deliver the artifacts with the rest of the source code.
Fast, simple and more reliable.

Moreover, the vendor directory is absolutely not a problem for Debian
(except for licensing where you would have to do a repack for stuff not
distributable). Debian just has to ignore the vendor directory and have
all the dependencies ready. The tooling around Go in Debian already
handles that. The problem is the number of dependencies.

> From what I have read in this thread, go developers seem to be about as
> sloppy as javascript ones : put junk together and throw it to the
> world...

That's not comparable. Go is not using micro-dependencies. However, they
don't have optional dependencies, so anything cloud-based has a lot of
dependencies to manage.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 24 mars 2020 05:37 -05, Michael Lustfield:

>> > Kubernetes is already using Go modules. They happen to have decided to
>> > keep shipping a `vendor/` directory but this is not uncommon. It is
>> > often considered as a protection against disappearing modules. So, there
>> > is nothing to be done upstream. And BTW, there are currently 616
>> > dependencies, pinned to a specific version.  
>> 
>> I wonder if the existence of Software Heritage could convince them
>> disappearing modules aren't a problem, or if another service is
>> needed.
>
> I think this is a symptom of the tools being used. Using 'go vendor' is a
> documented step in nearly all golang-based "release tutorials." Most never 
> even
> get as far as considering that maybe their source should have a version,
> because the toolset mentality is "download latest at build time."

With Go modules, that's not true anymore. It will use the minimal
version satisfying the minimal versions specified in go.mod.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 24 mars 2020 10:14 +00, Paul Wise:

>> Kubernetes is already using Go modules. They happen to have decided to
>> keep shipping a `vendor/` directory but this is not uncommon. It is
>> often considered as a protection against disappearing modules. So, there
>> is nothing to be done upstream. And BTW, there are currently 616
>> dependencies, pinned to a specific version.
>
> I wonder if the existence of Software Heritage could convince them
> disappearing modules aren't a problem, or if another service is
> needed.

There are other reasons, notably that you speed up builds by having all
the source code ready. If the vendor/ directory wasn't there, the
presence of `go.sum` would ensure you get something reproducible by
downloading all the deps, but I think it implies a full checkout of all
deps, which can be lengthy. There is also a caching mechanism (local and
remote).
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 24 mars 2020 03:11 +00, Paul Wise:

>> Specifically, as README.Debian states, the vendor/ subdirectory of the
>> source package contains more than two hundred Go libraries.
>
> There are a *lot* of embedded code/data copies in Debian already.
> While it would be nice to remove them, sometimes it isn't possible.
> Often the copies are forked, or upstream refuses to remove them,
> sometimes even though they forgot why they were added in the first
> place. In addition the developer culture in various communities
> encourages embedded copies. I think the best action we can do is send
> patches to upstream projects to switch from vendoring to using the
> native dependency system of the package manager for the related
> language community. ISTR reading that Go has one of those now.

Kubernetes is already using Go modules. They happen to have decided to
keep shipping a `vendor/` directory but this is not uncommon. It is
often considered as a protection against disappearing modules. So, there
is nothing to be done upstream. And BTW, there are currently 616
dependencies, pinned to a specific version.
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: tmpfiles.d and docker images (was Re: opentmpfiles & opensysusers, and its use in the Debian policy)

[Vincent Bernat]

 ❦ 19 février 2020 13:55 +13, Michael Hudson-Doyle 
:

> So in Ubuntu we got this interesting bug
> https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140 which can be
> summarized as saying that haproxy doesn't work out of the box in a docker
> container, because it installs a tmpfiles.d snippet but nothing processes
> it (I haven't tried, but I very much expect that the behaviour is the same
> between Debian and Ubuntu here).

The shipped init script contains the appropriate code to create
/run/haproxy. If the user is using the systemd unit file, the directory
was created by tmpfiles.d. If they are using the init script, the
directory is created by the init script. If the user uses neither of
them, there is not much we can do. We cannot create this directory at
install time, since /run can be wiped out on boot (the fact Docker
doesn't do that is likely an implementation detail).

> But the approach I outlined seems simplest and easiest to implement. Does
> it make sense to people here? I can try to work on a patch (although my
> perl isn't the greatest).

The simplest path would be to not do anything. Docker users can add "RUN
install -d -m 2775 -o haproxy -g haproxy /run/haproxy" in their
Dockerfile or work on a solution where the tmpfiles present in the image
are processed when spawning the image (like the fact that
`/etc/resolv.conf` is updated to match the current network
configuration). Adding more non-declarative stuff in postinst scripts
does not seem a good solution for me.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Heads up: persistent journal has been enabled in systemd

[Vincent Bernat]

 ❦  6 février 2020 10:45 +01, Svante Signell :

>> To not have logs duplicated in two places.
>
> If this is your motivation for the change it is a _very_ weak one, right? Disk
> space is not a crucial problem anymore. Additionally, what would be the 
> defaults
> for non-systemd systems running GNU/Linux? There are still a large number of
> Debian users opting away from using systemd (and still use Debian, not
> derivatives). And what about non-linux systems?

For individual systems, not running an additional daemon and not wasting
space on disk doesn't seem to be that a weak motivation. On my
workstations, I am disabling the syslog daemon since a long time since I
prefer browsing logs through journalctl and its superior abilities for
filtering (grep, date ranges, services).

People can still install the syslog daemon on their choices. On servers,
I prefer syslog-ng to rsyslog and I configure it to use journald as its
source for local logs as it gives me access to structured logs and more
information.

On non-Linux systems, a arch-specific package could just pull back
rsyslog.
-- 
A man was reading The Canterbury Tales one Saturday morning, when his
wife asked "What have you got there?"  Replied he, "Just my cup and
Chaucer."


signature.asc
Description: PGP signature

Re: Heads up: persistent journal has been enabled in systemd

[Vincent Bernat]

 ❦  6 février 2020 09:50 +11, Dmitry Smirnov :

>> and 2) continuing to use rsyslog isn't an option if the default changes.
>
> No. I just don't want default to change. IMHO rationale for this is weak but 
> everybody keeps arguing that it would not be a big deal. In time we will see 
> how that goes (what could possibly go wrong?) but why do the change in first 
> place?

To not have logs duplicated in two places.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Heads up: persistent journal has been enabled in systemd

[Vincent Bernat]

 ❦  5 février 2020 01:01 -05, Scott Kitterman :

> Not particularly useful IMO.  In /var/log/mail.log I can see log entries from 
> all the programs configured to log to the mail facility.  That way I can see 
> the interaction between them.  On a typical server that is for sending mail I 
> often need to see log entries from postfix, clamsmtp, and dkimpy-milter 
> together to understand how a message is (or isn't) making it through the 
> system.
>
> Of course the fact that I can't use all the tools available to manipulate 
> text 
> files to follow or analyze logs is problematic.  If I'm using journalctl, how 
> do I replicate 'tail -f /var/log/mail.loog'?

You can use:

journalctl -f SYSLOG_FACILITY=2
-- 
Its name is Public Opinion.  It is held in reverence.  It settles everything.
Some think it is the voice of God.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Heads up: persistent journal has been enabled in systemd

[Vincent Bernat]

 ❦  4 février 2020 11:30 -08, Russ Allbery :

>> As a heavy user or Rsyslog features I feel that switching default
>> logging system yields no benefits to say the least.
>
> As a heavy user, perhaps you're not the target audience for a default?
> You're going to install rsyslog no matter what, since you know it well and
> use it heavily.  The only effect of this change on you will be a one-line
> change to whatever you use for configuration management for new
> systems.

rsyslog even knows how to directly pull logs from the journal, which
gives you access to stuff not logged to syslog (stdout/stderr of service
files, applications logging directly to journal), as well to structured
logs (comm pid, user, unit and more when the service supports journald
directly).
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Accepted exabgp 4.2.4-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 23 Jan 2020 19:58:25 +0100
Source: exabgp
Architecture: source
Version: 4.2.4-1
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Changes:
 exabgp (4.2.4-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Use secure copyright file specification URI.
   * Set upstream metadata fields: Repository, Repository-Browse.
   * Remove obsolete upstart support.
   * Fix day-of-week for changelog entries 3.0.11-1, 2.0.6-1, 2.0.5-1,
 2.0.2-1, 2.0.1-1, 2.0.0-1, 1.3.4-2, 1.3.4-1, 1.3.3-2, 1.3.3-1, 1.3.1-
 2, 1.3.1-1, 1.3.0-1, 1.2.0-2.
 .
   [ Vincent Bernat ]
   * New upstream release.
   * d/patches: remove patch applied upstream.
   * d/NEWS: fix name.
   * d/exabgp.*inst: remove migration steps for very old ExaBGP versions.
   * d/rules: remove spurious /usr/etc directory with samples.
Checksums-Sha1:
 3af9b51221aca670edafdf79a707f0136aa8d1c8 2024 exabgp_4.2.4-1.dsc
 4a8da8e1b7674e6b0111450ee1948b546459f2cd 2922485 exabgp_4.2.4.orig.tar.gz
 3301eaa2c038ace14880bf5ad9ea2437f29b34fa 9932 exabgp_4.2.4-1.debian.tar.xz
 8a3d2f284f0621b156ebf7e89195aa25cc20d14f 7140 exabgp_4.2.4-1_amd64.buildinfo
Checksums-Sha256:
 c56d7094b0cb6f2b330bc197b08d6d3fc8c31507cc48ac7860679c67b9f6dca4 2024 
exabgp_4.2.4-1.dsc
 f70ab656a1973b4c614a769e9829341df2028481a43ce246756e39828f5ab9bd 2922485 
exabgp_4.2.4.orig.tar.gz
 e045608dc2475a4ab4fd2522a401a8010d547dd8dd6cb86b6f887f13776577c6 9932 
exabgp_4.2.4-1.debian.tar.xz
 4908e03fad9a5fa2bd979dc7cf76f6faf2c42312452f102b6b28b3346472 7140 
exabgp_4.2.4-1_amd64.buildinfo
Files:
 906039edf0cfab224bdc1b68e3a0c980 2024 net optional exabgp_4.2.4-1.dsc
 5a0ec24aedb224dd444a8e422cba77e4 2922485 net optional exabgp_4.2.4.orig.tar.gz
 cc399084b07ccbc6d11ed3d075a43150 9932 net optional exabgp_4.2.4-1.debian.tar.xz
 bf2209174032df38f6b515412eb3e6d5 7140 net optional 
exabgp_4.2.4-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4p7VISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5w0QP/1O9r2U0SHckRZFe6Jk2mBRxFpdIAeMp
XWrKtRbF7YsDGiTTsSK3d4eYv6DWeM1nhETGVpopy91qL0d3E/03PyDRqCxesjC+
+2J7DAnKGYQ4B5EEjhr5TdXCS+YVQnB+nejz7761+/OhYPJ2f/NL24t1onNLf0Ef
DSGQkIv2TOEN7W/h35LWII1LSZ7j9WSflTXiEdFYi2cLbuldu1S8OMYmFwYyNIX+
WwohHmWBXq+QJUBK8zlCT5sMJz3UPAJ04CuziOUm+vL7eU4lonH3cvrz5IOGTFXb
6kYeho0Fl5pgkSw/GGBxV0+OAEHGI5bWJZJCAjFRhPpkr5zaIET9RBbOe44MLOl3
FYWpkHQRXt0w5vOQ61mzI4SQ5MULFnXsYyhMQcWbw7XkCKpxwPkO91xrVbMIoFl3
GLvYlsGe09oyJ2VJymvnIljU8WU7ZXEwEAFWvNwCDWxujEZ1SF8+8ROm6AB2ta1D
xj+eypEeAHwOkBBj7w/eji+fTqu/8WVnHxJh2s+YC7fk27QJzTPsN1EhWpsdIiqT
3e1QvDTIJ/MC1s2HUTANqQIxZL3UHx5EsvYpS+9ajjkcPbrlBSgkE3fTDlNYED0U
zZBzMxK0VhC+mZzstQb//I8G0DWMhEqH1WSetdMyw0GUzl9/PNHOt8Ulj2Vmm7lQ
XB6DPbLW8dBn
=X0j6
-END PGP SIGNATURE-

Accepted binaryornot 0.4.4+dfsg-4 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 17 Jan 2020 08:13:17 +0100
Source: binaryornot
Architecture: source
Version: 0.4.4+dfsg-4
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Closes: 948971
Changes:
 binaryornot (0.4.4+dfsg-4) unstable; urgency=medium
 .
   [ Ondřej Nový ]
   * Bump Standards-Version to 4.4.1.
 .
   [ Vincent Bernat ]
   * d/patches: fix FTBFS due to a change in python-hypothesis.
 Closes: #948971.
Checksums-Sha1:
 fa4fe8dae439aff3471d35e4f0179716dc2445f0 2162 binaryornot_0.4.4+dfsg-4.dsc
 4f8d9dceeb71d330fafeb40c6c0becb0dc6146bd 349192 
binaryornot_0.4.4+dfsg.orig.tar.gz
 734cc4205bc0a0e9979b32625da9647f955feb60 3304 
binaryornot_0.4.4+dfsg-4.debian.tar.xz
 960b486465df5bf12379e98a32cc3946315424f5 7088 
binaryornot_0.4.4+dfsg-4_amd64.buildinfo
Checksums-Sha256:
 3a084509b88d75e0d1894bb3afd9aec52f643edf183be443469c303304fa83c0 2162 
binaryornot_0.4.4+dfsg-4.dsc
 f10faaa6bb5bb9d21dab4c129049a87c2d1c24989d970f8e915d78f9d6a75439 349192 
binaryornot_0.4.4+dfsg.orig.tar.gz
 177d14d67ec03a50176fb124e8ba2b06670d5c1570607515fc5272eb810b8970 3304 
binaryornot_0.4.4+dfsg-4.debian.tar.xz
 2dd31f1fe05037cfea27074fa8b7091c9a2e4c935906745ef4863f491234c1b5 7088 
binaryornot_0.4.4+dfsg-4_amd64.buildinfo
Files:
 ea79bc96c3632c1c3e11acc1af2d903b 2162 python optional 
binaryornot_0.4.4+dfsg-4.dsc
 fd574fa55a11c4601f8d91d9f7bc8f0a 349192 python optional 
binaryornot_0.4.4+dfsg.orig.tar.gz
 f72475036e4d1116778388f59583cef0 3304 python optional 
binaryornot_0.4.4+dfsg-4.debian.tar.xz
 351cdbca0e1778a30d88bc70df246b25 7088 python optional 
binaryornot_0.4.4+dfsg-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4hX64SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5uZAP/AlMSggCdBcotqKBxw2t2mFkBv2mtnnr
xtFzOIxJoF4rgN9qFT88vwaTQvkx0iLGbmjYH/1RCdXaGJx0AyjpCOy4vPJdhDZB
YWC7LC5FR4/9JxCQQ5x8m7YKhkMDSRK1ZtjdxKEZaGH89b713rR/6FVO3wd6UpSy
fhUhJLACCe/rkyfLpftxpZ2B3+nDQcyJ+KK45Lb3mEvXPxfenhjriXeoFYyB5XAf
+O+naUD8Vd5hPr62rDfkuqY7hvs8mH/uBraHZQPAQR2c7oPl0hmUhnk/QSJi+Lo2
LplbICF8i2igBrGoz/gqP1xfJuHOY9/ScnfeCuGLpQ3+iOkekgR81LPFvVL/kRRK
1MoNmcMnk5/wDUIeuKzeyb/TQqhZ357D77Mr+JVVRY/BqenSbpyjGjBbpQboRTZv
guTqkXrpMKB58eHh0aehBvxr04jjwtaJ/fsROcnLOxeiFC5F/tG4RghxRi/55WrD
7vhA/O7WqoThSf3nABnXlBp/PHubRVlE0gRNavRxBhadMIMo2ilyTbdsqgp61cw2
GEDz5qJQi/pj2d8g3yL3gcf7/2cbUtY3mPmNk1UYhnvUsTIbNmmCNC9K0XkQXbpt
F6wyCOM325ir0/cShQBwulsjvhl0Y05F5kVF8k8dHqRE1nld3U7Q2Fub1CY5rG0R
GtuFm8INSTZ9
=Po7A
-END PGP SIGNATURE-

Accepted bpftrace 0.9.3-2 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 12 Jan 2020 08:13:51 +0100
Source: bpftrace
Architecture: source
Version: 0.9.3-2
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Changes:
 bpftrace (0.9.3-2) unstable; urgency=medium
 .
   * Source-only rebuild.
Checksums-Sha1:
 cc63693767de82dd8ebd328328a2066271ab3dd2 1977 bpftrace_0.9.3-2.dsc
 c9cec426dff49c1fa9886558e8307e3f537babf9 3296 bpftrace_0.9.3-2.debian.tar.xz
 f182551741813fee7330b03e6287799084892efb 8543 bpftrace_0.9.3-2_amd64.buildinfo
Checksums-Sha256:
 2142f01a580bb25661e8222d261669e5b18dc68832542f5d9bff8aa36a2c4ea4 1977 
bpftrace_0.9.3-2.dsc
 5bf4a323b600142c0019d6b5aeceee39e9d535b8a2ce595fcbb91e0a3497ea0f 3296 
bpftrace_0.9.3-2.debian.tar.xz
 3fbaace981e51cd468e049fa05da3b3be2d8a935566c3fe46313c3891e3754c1 8543 
bpftrace_0.9.3-2_amd64.buildinfo
Files:
 e7cd9fcf4f33d874a0c0129d5936d618 1977 utils optional bpftrace_0.9.3-2.dsc
 06149c9680b0a82cbd3b79cbd67a5509 3296 utils optional 
bpftrace_0.9.3-2.debian.tar.xz
 716e8414b9a638196570bac6dcd4b81f 8543 utils optional 
bpftrace_0.9.3-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4ayNESHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5lQ0P/2zr3I7OrWHikOLcXqm+M0cdeXVdBBGC
5Md4zzZhl/g30Dk85qxtOjc7CNoAx5MfmdtfjU6azOE8D9hVOdukLVKUSJzYnrKp
Dqxge5O2OnMQwAKpTUAVWk2iRfabd7i/sbFDlTcp3tW8/RjemotfJxW7D/az5Kzq
pfdoo1zHA63qGETLgVATYrnfJbU0R0zrJKcWRcCpfK1ixhBcxaAWpyy33KT6yuq2
8T+ibUYMuVNCGQZ3hovBA+h45z6bYdsn/PjKa8lPE/U/Fp/R+Rs/WhX5gpE0v39Z
rA5lldEKEEAIDeGfXW37Vcwj0QQr31InZ4wMVTfjgBN4T3l6K3ZNKqY9lV3W44UA
yqzvXdlHbaBOW3FbMfNfRI9LVDqAsnxwRH4jlD3R+YjrEQw2xXHy4tFcNTgoUdjo
03WayeiSZt07/lu8kUpHVvPsTnLRYrR634KxUhFMDBL4o3E1ZjNktnbyKaRV1kyG
GrRTGebj5ypZkSQhMGDt+sdglgkxeSyjMy5sQXvJRdXXlngQRE1wpgZMOjoyxW1h
yeBoc8QRWkyAqIg+3KfdyFUiGQIdxi7lxiSn9RHUbgx5sXb50zryTf3wNby2BvPr
1f3dZ/QMMKJXvXkQJ0ftrvuLeiyvk3N3VPJFkjmIeYXvxnGxhUY4n4wEuYR5VqDv
ZrvuiijY9vlf
=QOAk
-END PGP SIGNATURE-

Accepted bpftrace 0.9.3-1 (source amd64) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 27 Dec 2019 09:16:59 +0100
Source: bpftrace
Binary: bpftrace bpftrace-dbgsym
Architecture: source amd64
Version: 0.9.3-1
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Description:
 bpftrace   - high-level tracing language for Linux eBPF
Changes:
 bpftrace (0.9.3-1) unstable; urgency=medium
 .
   * New upstream release.
Checksums-Sha1:
 035b6abf4b9b3f599b094d3d8f34ea3d2fed1961 1977 bpftrace_0.9.3-1.dsc
 c795730d0af54c0e9af2e6042c20acc4c4965360 743506 bpftrace_0.9.3.orig.tar.gz
 56e6f30adc286505f964ba22b5b26748bae21f04 3264 bpftrace_0.9.3-1.debian.tar.xz
 deb7bf88c27af8637098e1a029567c6fb609e853 10130516 
bpftrace-dbgsym_0.9.3-1_amd64.deb
 4d1570e9a1ab8f1e9d76f921d4db872d935ee1f9 9052 bpftrace_0.9.3-1_amd64.buildinfo
 456349c846528023fafb25b3df97db36cb55c184 439760 bpftrace_0.9.3-1_amd64.deb
Checksums-Sha256:
 c49ac786ee25d06fe5e5a4d0d9a4a8f0fc01ed7a9a6f012b4fca2874a9c8c0f9 1977 
bpftrace_0.9.3-1.dsc
 06e207df236d1e5187fb8a9a954c8ba437dd8258975577cc57d77f350d35cac0 743506 
bpftrace_0.9.3.orig.tar.gz
 e8ec3797e64ea5b21015b704285bac92a6fd5d5945c34b3c3a3f80955b6dbe3d 3264 
bpftrace_0.9.3-1.debian.tar.xz
 3331f984e406623dce3b8f170d82644926e000b10c97924cfa1d1182d224d52f 10130516 
bpftrace-dbgsym_0.9.3-1_amd64.deb
 02e6c6565b592664c7b5d9c576eba22d10871862024f0b1e1dfabd840672f82c 9052 
bpftrace_0.9.3-1_amd64.buildinfo
 64a3a11f46eb50872afad66c74c3f490fb0c5477a6a77e425def535fe33a91b9 439760 
bpftrace_0.9.3-1_amd64.deb
Files:
 e96375ec5c12fb2b2b678f00f7717bec 1977 utils optional bpftrace_0.9.3-1.dsc
 026f3339b37edc3da04b5ea349033949 743506 utils optional 
bpftrace_0.9.3.orig.tar.gz
 056a0322d0fb7db3fe7b375305a6bef2 3264 utils optional 
bpftrace_0.9.3-1.debian.tar.xz
 1f54ffb2cf4047ce6ee3f1737371d2da 10130516 debug optional 
bpftrace-dbgsym_0.9.3-1_amd64.deb
 43636cf33f887c1bb9c5028fc6ce4cf0 9052 utils optional 
bpftrace_0.9.3-1_amd64.buildinfo
 abf9797107ab22604f52646088d81bb6 439760 utils optional 
bpftrace_0.9.3-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4Fww0SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5YDgP/A6Iwpnm6MEsGoIIdIQ0tlIQJVovFFyZ
eenA2lz03DuNuL2jR3qXHJ9v7vSnRuPjIpjfaUX+QmRvg+zU8kj7OZl2lYLc1iDm
BSTNAO/Q2JC8tSQCgvqqg1/ht7Z4m9AAJOnzirN+9bqoIkaFzaSW6TX0Q9Ndd3ds
kCHv2xtohZ3l/rKgsJm4sod8lwL/EjKeHSb9ljvEeBZruOR5isIr0DV8U0Kfvrlv
yPLabVe0W8jcZRHNpkc/BRkYF3I3IgbSlqHP45J9yl38zLG2vvRvxmBD58yqIT2W
YrX2Hjm52v1u1c6MYmD+Bjt4E/B5Hl24c3gU39rHKz4+rtwUf8dqYpN5v1KnfyK1
oUbKvHs88ajQH5E0FEnCGggoyTV3vjpBV0UhWeQIbmAdJ/mL0HDIKa8zsvJ4otq3
aoXiweGnhaJbPut5+Ux1XQX/++aJhuJb3FgqCm98D8DTRqcnV31NS9j0fV93/Hmk
RODrEdjazlOpM35zx0pBNpjdOZLL7oilkYz1d36oBmYndhhBsmurroMDL43oLA5T
nI+yI5u9+tUU7XIJM/6yMuviK6BorKTO3E2fnLcZQzLJVlS+onxrFd6bOLJuKz1M
PgRmZK/Pb6sW1pJaxEwAnMEORjvHu125e7hmScUUn32WzNLg71j6fTkckZxdpVgG
RlYRVjB45byL
=vT0a
-END PGP SIGNATURE-

Accepted bpftrace 0.9.2-3 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 27 Dec 2019 09:10:54 +0100
Source: bpftrace
Architecture: source
Version: 0.9.2-3
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Closes: 947436
Changes:
 bpftrace (0.9.2-3) unstable; urgency=medium
 .
   * d/control: switch to clang 9. Closes: #947436.
Checksums-Sha1:
 1db3ec903f2e4fd4cff2d59fdadfff5a8995feba 1977 bpftrace_0.9.2-3.dsc
 f35927be0719e7537e10cab1f4bee28705270ff8 715019 bpftrace_0.9.2.orig.tar.gz
 0091b5ea770ee39cfff1b3c7f056cac0a1c82b9f 3260 bpftrace_0.9.2-3.debian.tar.xz
 3f9db7589582d91c0b6be7205b55f6d8ccbf4f26 9049 bpftrace_0.9.2-3_amd64.buildinfo
Checksums-Sha256:
 d76ed9a51b48cb4adc38c74b7ac3572c451f9218ad269dd190c99f0a2a520693 1977 
bpftrace_0.9.2-3.dsc
 3b3bad09bd3702d852900b3721739d9e9ea9271373222f317c6aaa33c4630020 715019 
bpftrace_0.9.2.orig.tar.gz
 6ec9ab4ff317417671ac91580b43f71ac0486ce34e5a618808e0a761e112e0cc 3260 
bpftrace_0.9.2-3.debian.tar.xz
 3f8974ce87296936903f0ff4e8ede5970f187e00b2b9a0eedcdda164cf1d50e4 9049 
bpftrace_0.9.2-3_amd64.buildinfo
Files:
 d7ddafab722576565c15bf0266b36764 1977 utils optional bpftrace_0.9.2-3.dsc
 fef806c17fcfb280aac97c01286ae827 715019 utils optional 
bpftrace_0.9.2.orig.tar.gz
 eaa7c70f2c4367a19ad5790ffe7f2407 3260 utils optional 
bpftrace_0.9.2-3.debian.tar.xz
 c66f63d0056257e377185d07b12ef155 9049 utils optional 
bpftrace_0.9.2-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4FvZwSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5qigQAJNeV3hMaUxVQk0IKtPR7z9JCZpL6i/W
hJnZEdCA00XJssgNX873J2AidHpodyxkynPwPty4vrSV0m+XSHtI6XueFLlSuJ8r
sKjyYEv5qK4dSByhMuLZAYv8HafXTrxbsAKvMLOyz7qVw6FInSPE5N3nEzwOjb7i
xTc/oqkd/b0PoM9EjSQ5nc6FSoDXR6ABrGAGRKEwZZ6BjO1QeHMQHuGXzknPeXr0
8lmwVJhQsrbhL2xN94Obi0adbVezxRSaLxmtbydmuzucmT5imF4ii2Du3g4mDyvN
SvIPaqPgB7KLZ6n7XxiZwRxrjIGy0mFRHil5VJKTiHL34cYqd6UYs/KBof9qxLWZ
GKNsCqaQpGKdqJzFHb9gca9qKxPWx+EnRPSnov9wRZOSuhmsggaD4nOt4G3joEwe
+WsGG+7JASkNj+9S88TZHjQ976IcapkOz5EuOZKLBIYYi/cYcibJiXQTYXVqsvxv
5sTq7pZPALq4Eb7nVUCa3FBvXLpCKWlr5uWNvVoyXJSNV1eAD2v3FlMYtME0SGBh
lGgrlYuenTOG/QRc8Yu80S3IOBNWJl3X8ttrcjRsnsTZc1n/ZCgeniXdr55CZVOh
zmHQZ4bxHRm7+X0Azb+a2z0y+8HW/pgTa7ivqdMTJLUFlQmmYoK5yvzNYq1lfor4
8SI05U2d/3vt
=x7lX
-END PGP SIGNATURE-

Accepted xtl 0.6.9-1 (source amd64) into unstable, unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 14 Dec 2019 18:27:18 +0100
Source: xtl
Binary: xtl-dev
Architecture: source amd64
Version: 0.6.9-1
Distribution: unstable
Urgency: medium
Maintainer: Debian QuantStack Team 

Changed-By: Vincent Bernat 
Description:
 xtl-dev- basic tools (containers, algorithms) used for xtensor and xeus
Closes: 939936
Changes:
 xtl (0.6.9-1) unstable; urgency=medium
 .
   * Initial release (Closes: #939936)
Checksums-Sha1:
 f76bbb8177be504e64f920a0443063c8ce7f6e53 1928 xtl_0.6.9-1.dsc
 ca3a40fa2eae71bf22ed6fc0f625c728a3cdf956 112087 xtl_0.6.9.orig.tar.gz
 9fb03ada9b8d9af623c54d24370a2f0e44c5261c 2520 xtl_0.6.9-1.debian.tar.xz
 ab384b35f998acfe147682c7b6f718d85d1bafa3 58416 xtl-dev_0.6.9-1_amd64.deb
 c1c5bf14d99cbaaf49b040e2b0ec30e376855be3 7001 xtl_0.6.9-1_amd64.buildinfo
Checksums-Sha256:
 71281a78436b5442e4cd9952e4e419b7a9b34e95c814452c693b622069f01cc5 1928 
xtl_0.6.9-1.dsc
 c348fcf53dd2b355d143ad28e77f1ede7e1d5e6a196d2d5b9c478b1c005dedd0 112087 
xtl_0.6.9.orig.tar.gz
 466dd4966f148a975a1b0ad37b40999341eb58b63072a2a9eda2c4e5337cf945 2520 
xtl_0.6.9-1.debian.tar.xz
 8bf2e5dd87c073da57b8a82a257e76d84922feb86c48c150eb2e7c2ee25ddef8 58416 
xtl-dev_0.6.9-1_amd64.deb
 b9b68f509fa9fa94faec1f08b970d20d5e810da27229f48e930187963acf15ee 7001 
xtl_0.6.9-1_amd64.buildinfo
Files:
 0a35465334b502086a72fa662e6bfa1b 1928 libs optional xtl_0.6.9-1.dsc
 b15d735923ef3dea9fefa9b8bce3b1d8 112087 libs optional xtl_0.6.9.orig.tar.gz
 e401b07524e535a7000a9c488996cde6 2520 libs optional xtl_0.6.9-1.debian.tar.xz
 734397fd7bbcebca15799e742ff4a7f9 58416 libdevel optional 
xtl-dev_0.6.9-1_amd64.deb
 3d3dc3efb6964aad00953b981a497124 7001 libs optional xtl_0.6.9-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl31HSwSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5bDEP/23fAiUtuUHag2+4FP0QmeNdkVxIbtum
CxA6JVEQuEyAVDR6it09Jx827l/w62XyFrSggZiX4DsZoWSIo67ehk5Ll3PsS1pI
FyiStqG3voIvVaRqGrGD36oG79jSadGYwbxsLQ4FCLcgsTzBwGFETqtByzLUDrGk
Kd8FQekt+dcSQCoNfT8cYO+7xmRuojVNKPuE7gyWxjEpj0QPz50spnLk9tBp36RK
0l8MIivn02X1HxYI0iec/TWkCGPRpNhPm7zQh8xQONmIfSpOcBlmcfawusmoxaNF
XTKF1e+S0uRSvYGlnBAx0ppXI2sXMUTAidYs8cQJcp57zDKWFnn8lkKr9EImia1C
A2fVGRrQoOnjyASS5OY5SxStQKiVX3ZUH5dAQsBtv0ShHHKxk7XgBKgU9ppefkki
NyNHHCjd/5O2UqU/QuuIcWarrwTFNBCwH2s/wVk+/nolpQOp7CtBnctDK24ngBSt
Wl3MPLuHfi/wAXYr1YAV57sIY9/HzqTYbQ5QfhBhP3QYdp0+zzT/HWCcV8tqq5sb
MfuH09sbBGmZkPN8rQ5IOoCOc80OSJIY4fFwLqYMdxoskF358Mqda/VHvSQ8aDl+
6DVAVfGJH+7/7OYQfo4ZEBa53B1RtVMd0cyFncJ8KFYJFyDmORYyy3rGddglcAx6
TpHSBGyHpQoh
=Wusp
-END PGP SIGNATURE-

Accepted haproxy 2.1.2-1 (source) into experimental

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 20 Dec 2019 08:20:33 +0100
Source: haproxy
Architecture: source
Version: 2.1.2-1
Distribution: experimental
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Closes: 946973
Changes:
 haproxy (2.1.2-1) experimental; urgency=medium
 .
   * New upstream version 2.1.2.
 - BUG/MAJOR: task: add a new TASK_SHARED_WQ flag to fix foreign requeuing
   * d/logrotate.conf: use rsyslog helper instead of SysV init script.
 Closes: #946973.
Checksums-Sha1:
 96637d6d6745b042d7c8310aad4ff594201c9a0d 2301 haproxy_2.1.2-1.dsc
 9f9b84504590ad937ea680e6b136d461fbe23f77 2663193 haproxy_2.1.2.orig.tar.gz
 8fe0d4edd1bc426900e59ef8e172b7b8ec00ce5d 68548 haproxy_2.1.2-1.debian.tar.xz
 6df9ba0981778ebadea179d0f0aa672e63b85c32 8915 haproxy_2.1.2-1_amd64.buildinfo
Checksums-Sha256:
 1896d1e99cc81a52b3097c201a094250fc776d868f297be6b20c03e68b7f1ac9 2301 
haproxy_2.1.2-1.dsc
 6079b08a8905ade5a9a2835ead8963ee10a855d8508a85efb7181eea2d310b77 2663193 
haproxy_2.1.2.orig.tar.gz
 3a9792f420fc03683bde1a9e880a4d2c1851f378399741a71b7eda1afca6f369 68548 
haproxy_2.1.2-1.debian.tar.xz
 f5d0969df176cce2a06cc6e12475314a6f8745c8ebb6aca1ca9ee562fa013e24 8915 
haproxy_2.1.2-1_amd64.buildinfo
Files:
 73e03bb3a5b1046f85142b987fa944bd 2301 net optional haproxy_2.1.2-1.dsc
 476a91a5eacc023efe6211dea4651f63 2663193 net optional haproxy_2.1.2.orig.tar.gz
 66d98a8707d71a96ceb348dbd165e33c 68548 net optional 
haproxy_2.1.2-1.debian.tar.xz
 268529e1d9a45d77a6aeca070b000822 8915 net optional 
haproxy_2.1.2-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl3+S6MSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5oIEP+wWsn/HWVpVMMJNEOT+Sd+EO3xPnOJQy
NypjB/PDVFj3FodwfSXxHp8k4dvudhFMBD2j87HmZ7T6rUUPzbvKFvr6HpAdtAHb
rANTT5gll0PX57YGqYn7qvdFabgVJzCAjW6zBGcGsO+mkYbAZBDirmWdZEgnIwiv
M+S39zI21oCLnrVawxcuVuxDuLgncoBfxDp7sr3L9MfMlSS0KR2ow4zFIGNc+2u7
KT0BGvIZiYruaaWs4Js3/X09yYxxzeGLPyPnOxCLJsdygzEeZs+n2OypqYuyCno8
1rj11PG7l7HnvSklNT9Dw90K1H7Mzjv0Wo2mfRJm/9Zv+W4YC1K+4aCVoewuRiA5
xplvAWduuHavkh22MeJjyDB/2O7gQseV7hF7SW38tmHHLOHfzFLHmVQW6WVEWMmD
BwxaNNzAeHQrODnQl/zkgJztB066p4/gEGgPN59+G2GhLbw6kYKMAwQD+zOxf9A7
bAVllSGm5Bs2AjByhF4JDI+8wZXANnyNwE0LX+nl81+Nh7JcnA5rjH5zljqu+lJ0
yDH9meyYUruc4srywELdF8nf2aIZglZB/ojrBvtPx6kOQD45JcRJlZpTTrJ+nV2x
k+Mm8ahwrCMDBPs7OcP2iFn6p2YbiGqG62ttNDuz9ktDAOGdTrsdQCHtJv3e7PIB
GdshXdEjqLRV
=/0rL
-END PGP SIGNATURE-

Accepted haproxy 2.0.12-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 20 Dec 2019 08:20:33 +0100
Source: haproxy
Architecture: source
Version: 2.0.12-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Closes: 946973
Changes:
 haproxy (2.0.12-1) unstable; urgency=medium
 .
   * New upstream version.
 - BUG/MAJOR: task: add a new TASK_SHARED_WQ flag to fix foreign requeuing
   * d/logrotate.conf: use rsyslog helper instead of SysV init script.
 Closes: #946973.
Checksums-Sha1:
 c760f5071c691d9a5e8c17b116485ecccf83710b 2302 haproxy_2.0.12-1.dsc
 69c5ca5c99ddd3f8a4ef886cb45e7c77666230b3 2634202 haproxy_2.0.12.orig.tar.gz
 4080808f2b5b113c432f712c11bba8057882cd6b 68404 haproxy_2.0.12-1.debian.tar.xz
 f917e9c62226595e2b2b0ba99c4459679d7d97ce 8932 haproxy_2.0.12-1_amd64.buildinfo
Checksums-Sha256:
 9f7dc21b2f7c6672a55696369b9ac965429e2f9463b7ba0f01afd2e07803cf8a 2302 
haproxy_2.0.12-1.dsc
 7fcf5adb21cd78c4161902f9fcc8d7fc97e1562319a992cbda884436ca9602fd 2634202 
haproxy_2.0.12.orig.tar.gz
 33d2fd963a289058d451199096977e298ad458fa5a9dc74c9a48ef910f2ad2e0 68404 
haproxy_2.0.12-1.debian.tar.xz
 32de2fe018610c92e983a1d6b650df754f919184a03a7c4f2c711ca422542b11 8932 
haproxy_2.0.12-1_amd64.buildinfo
Files:
 0a5dbd01a33a3d280463b677e8543aad 2302 net optional haproxy_2.0.12-1.dsc
 b3c41a852e63fc840319c66e5e5ebe29 2634202 net optional 
haproxy_2.0.12.orig.tar.gz
 ebb4aca640657426688753dd6dadfa09 68404 net optional 
haproxy_2.0.12-1.debian.tar.xz
 276eb5c5f8f957c8b0e8949f8688029c 8932 net optional 
haproxy_2.0.12-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl3+TpMSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5z2sP/i9dixGYcjc8cVOenJHkwo/uJrjxRQHW
UTVX12m3Nsv58XXuCHASDX2ZyQtdmgirvbyiItazUWvENaU+PfzC5K2jWCnomEKn
mPOPUzOOY5+t+Y11/oXYZBneJYFzgmJxwn+p75fC16Fyl/fCc3XspKRTXnPpc9Vt
GNAR83+591UyHDPgIghjT/OcssWWZtvCfjkwc6Ylojst49i7jsNrzyYhwrLrAxlp
jylUMCfUAr3I3wnxQRzokMZ6+kgGMCILsS1qIl7YqALF2wdTbz64YGAAra8e/tzc
DtwaUpkk46uaCAPaI5dVlvkJHKn2PuV91DRTv9r//x6XYT0qqBWj0v5hLenOrVMI
Ykl+YPdR1sJE2TPycLWXUDQEXWrA9MTZHd9JppzH6de6OYTsPK1XrOWjw2r2HGdY
YLKR9AXVUOS3GISNj0+o8lgxkiarDs9yG7WV+rf21FCNHCMFIiFo2OYcW8AOlGjU
RdgIzFtGVmUrV7270GIH3FeCar8pCxPp1FPmxtLvJbHfN77iN/eE8IA8oLbJmFZO
CYuzi/b8id8dmYYZCOKhEk5GcXOYRKHNrGv8ttHNetQzF1ivhKBPLpj9+LK5+uFd
Cr7pzRDbO+Bs2YiEd7qSy2QRru+ZwRkaNF7eUpKal1d9wZTBuBmj7CUctOcPYJgf
wrCZCHeu3E+f
=FdZo
-END PGP SIGNATURE-

Accepted gobgp 2.11.0-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 15 Dec 2019 13:18:00 +0100
Source: gobgp
Architecture: source
Version: 2.11.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 

Changed-By: Vincent Bernat 
Changes:
 gobgp (2.11.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * d/control: adjust build-depends.
   * d/service: update systemd unit file to use notify and a dynamic user.
   * d/patches: patch to make tests work with more recent version of protobuf.
   * d/install: don't ship gobmp (removed by upstream).
Checksums-Sha1:
 ed25f329d150001cb0bc51fca64ac1f925299823 2636 gobgp_2.11.0-1.dsc
 cd3a834955dc281ec6d31fc1cf3f83f7713f8fe1 839560 gobgp_2.11.0.orig.tar.xz
 a3dc46ccd2fb497d781742f682c9e9c2b9af1b30 5376 gobgp_2.11.0-1.debian.tar.xz
 ee9cd9c7370014ea12bd2c60ee4c2074071cd7fd 12586 gobgp_2.11.0-1_amd64.buildinfo
Checksums-Sha256:
 ee81ef8d86996076ef847afd8a032e49afca17db43b40933d61f1d3b9accf1ff 2636 
gobgp_2.11.0-1.dsc
 d719005442c568fce58f1cfce27179931c396fa7479e98db245ec540bf2cec6c 839560 
gobgp_2.11.0.orig.tar.xz
 46d76e5929e87b9f3117b291d77e1e4ff72aa14f71b2988df5c48da35bae2ce2 5376 
gobgp_2.11.0-1.debian.tar.xz
 3c747bc68225424c520c4aaccfc4540b026f2b7f15cfd3c8d14e0121c54ba2a5 12586 
gobgp_2.11.0-1_amd64.buildinfo
Files:
 83b7e2e030b9dea5e3a86e6006f0dbb5 2636 net optional gobgp_2.11.0-1.dsc
 0efa9258ed0e66304dc7c3dafc2cd5c8 839560 net optional gobgp_2.11.0.orig.tar.xz
 14ada8f0e00551b1212995f012483229 5376 net optional gobgp_2.11.0-1.debian.tar.xz
 e73d29f62f8c2315a5470f60f113bdf6 12586 net optional 
gobgp_2.11.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl32KI8SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5hJ0P/R19Vceq5bw0I6yRmfDm3YwsIo+QbkB8
x4fFpCAwG5nAR79cnUP334FgJm2z1FRf4muwOkXZN3t/E5HxHaTc8WTQVAsUoEai
dQJhzU0luTJtr4I95IgmgUB3SduLFWl/qngE8N9UBb0s3SB3KQv9kIoe6CHvQeRr
RtZEGX46Eklv+7GgiezIo/UZ+UK3cKsJOGfCnSmRnIxjzsErXh9JO85/pzNhHmm5
8bvjUnyx0ObMGKAcwKbLCpcrdK/+t2w/nE/3Qmg16jkRwVyZvONegdZ+WHQjno3h
wigQGyMkilR7IvBS4Z+ZGt1lBwmnQ27WfZS2ONXu3Qeyt6ANJ7bJxkPn1eCi3sSr
fHBdZuxpUcdhndkRfWIEPaM7tTux4zMhzkRfSHkgpWw6d3LIZcMq0wBkdqfzLJz3
id6ltmlfZOfh+u3nRz6wV3G7eXM3bjcanqFzNkjoS6AMBagM9Kbb4D1vpw8JYIzP
oqPISUTol6y4UcbgCs9/GHpVm/V4R+MILBlFoJC6VM70eo/8tF+bM1d/SfeyrHWA
M3zzxG8bOt0i2rxW64LjcP2WlatyG6vgra89qwrpRpgNoiZlcw8V5T0P0G/ra0D0
KRdfK0BF2KkXc9jNE7akLXZvfotiO1PV4N6btLYt7gPeA4oIbSyxAZVzJ9fhttAA
z/xeAs/QtxDo
=ZWsU
-END PGP SIGNATURE-

Accepted haproxy 2.1.1-1 (source amd64 all) into experimental

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 14 Dec 2019 11:20:32 +0100
Source: haproxy
Binary: haproxy haproxy-dbgsym haproxy-doc vim-haproxy
Architecture: source amd64 all
Version: 2.1.1-1
Distribution: experimental
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Description:
 haproxy- fast and reliable load balancing reverse proxy
 haproxy-doc - fast and reliable load balancing reverse proxy (HTML documentatio
 vim-haproxy - syntax highlighting for HAProxy configuration files
Changes:
 haproxy (2.1.1-1) experimental; urgency=medium
 .
   * New upstream version 2.1.1.
 - BUG/MAJOR: dns: add minimalist error processing on the Rx path
Checksums-Sha1:
 d22be161140efcd5043d58603dcb41247ce5a122 2301 haproxy_2.1.1-1.dsc
 9caea7da89cd6c33e62472d67942679b35f5cd30 2660997 haproxy_2.1.1.orig.tar.gz
 b248689becdd5cccf8a6d57fc72adb0cfd8b8b56 68536 haproxy_2.1.1-1.debian.tar.xz
 d89a920afaad019aef771e17e615a57d06831259 3486040 
haproxy-dbgsym_2.1.1-1_amd64.deb
 2136b4e30bbfdd61f090f80e7641902b80198e8f 619772 haproxy-doc_2.1.1-1_all.deb
 f41459ccb18c5c8de38254d4b0ea6edad6753a08 8898 haproxy_2.1.1-1_amd64.buildinfo
 6d401c687be6a447c0900292e120b3e73682009f 1788196 haproxy_2.1.1-1_amd64.deb
 5f247332e6852faef6874d947d742c1b41792f2e 243308 vim-haproxy_2.1.1-1_all.deb
Checksums-Sha256:
 cbedb13987e4d1c7a151d099336ea85902e0cf2f906c3e9073dbf7f5231826f2 2301 
haproxy_2.1.1-1.dsc
 57e75c1a380fc6f6aa7033f71384370899443c7f4e8a4ba289b5d4350bc76d1a 2660997 
haproxy_2.1.1.orig.tar.gz
 017c13bad0038482fa4c8371939a47044a77d5a647c9ead4ac80e096f0b1cb7f 68536 
haproxy_2.1.1-1.debian.tar.xz
 8075e2f5807ed900d19e4132e4477436e99302c7e90019ecfde822b576d70163 3486040 
haproxy-dbgsym_2.1.1-1_amd64.deb
 f1a31cdadc8d30e98317880f4e78153934bec0f62414f6e4dc22b9a51c20 619772 
haproxy-doc_2.1.1-1_all.deb
 6d761cc535abe461ead8aa3933ef5652532a499f65459fbb05c083a26aa10cad 8898 
haproxy_2.1.1-1_amd64.buildinfo
 39fb1bd47d0ab029be316daff97f4f14690b01eb7b73ef1d90564ec01c4f4868 1788196 
haproxy_2.1.1-1_amd64.deb
 10a461c119b05807e626fb32181e3278f01ac01eb1792fa53601fd33a1c808c4 243308 
vim-haproxy_2.1.1-1_all.deb
Files:
 56f92511eabf4d298abb0bd0c2b6e6b7 2301 net optional haproxy_2.1.1-1.dsc
 bcd4789d7bd72bb51bdf8d41485aeea5 2660997 net optional haproxy_2.1.1.orig.tar.gz
 41acedf379c70c711efe73530880945e 68536 net optional 
haproxy_2.1.1-1.debian.tar.xz
 22aca18a84044f250e527bc3eb9b075b 3486040 debug optional 
haproxy-dbgsym_2.1.1-1_amd64.deb
 66d18f72f45e28908f81c8ffda8a4978 619772 doc optional 
haproxy-doc_2.1.1-1_all.deb
 807b64a6187abe03ae5db4a57537eb86 8898 net optional 
haproxy_2.1.1-1_amd64.buildinfo
 82b2fd91ee479d3f67b878979d6ecf20 1788196 net optional haproxy_2.1.1-1_amd64.deb
 5f817e28332f8bdc9549938262e6816d 243308 net optional 
vim-haproxy_2.1.1-1_all.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl30uBYSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX55xIQAIYfu96ZVBaBQIzfwQp68KTtj9su0oUB
yJfnXBVX9Oia9G4y73t0pyKT6q/E9DWQfWk928P/pY398aPI3wOUw/y+sKZqJzmO
AF8lYx8xRMwIczP076sHNlvcykv/icrL+878UJ+WKti9sVdoKkHmfvdU5YIZzEER
pbQr0rw99aU+/UFZqw1JPNajvQTAUWVirmaQCVZ3l2fIBrvlz/AtgwQXcSStdK2z
XUe6x8CT78oz3LULnFhqmMThBTPO3PbghAHo6ylLbJjZz8VRiV8oEgYzMo+7vSR/
Eb2jGWdKuABInJw59l+rF5RQ80PVxCBAgnQlHavdHSmK88/+6BMJBw9uxPWSyS8v
avyAc1g7/7Ive7At7nOeTMwfUP3uooqA0utMpCjO4IS4em2sGY9qtBIcSlO8qmOY
JUss77m+0JD6/fVadJEBVYe0Ockw/zvv8g/IDCMkhy8rCBEudMs68dTBHAMl9yFD
XtxayLJFH2G567EQf2BpJqh5D8HCiTDit4YVkV/AjFUv+Y7G8S2qVOrW3QPXG6Fw
8UqdKIh9czgEyM92PAl3Amc5CTb/2PbxvN+LjqepIFDUChE6uhYMy9clsQ2hIov/
Vs7SViZnA4W54bCcrVfe4CiAlahwFX3j1wSmQP6vUD/q4M/YDmTRM4jbR2x1suQ1
LBHOLTERDn/g
=tBHO
-END PGP SIGNATURE-

Accepted haproxy 2.0.11-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 13 Dec 2019 19:22:03 +0100
Source: haproxy
Architecture: source
Version: 2.0.11-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Changes:
 haproxy (2.0.11-1) unstable; urgency=medium
 .
   * New upstream release.
 - BUG/MAJOR: dns: add minimalist error processing on the Rx path
Checksums-Sha1:
 04904c4c72ffcfd0132ff4ac11f1e115cfbaf40d 2302 haproxy_2.0.11-1.dsc
 f5a60edaf432ca2e472b1c7fd7dbf96be7643bfa 2633162 haproxy_2.0.11.orig.tar.gz
 e7776a7b9584cda068855aeff4a742a11d1ebcbe 68372 haproxy_2.0.11-1.debian.tar.xz
 b2c80f87747bbb835b7ca93bf66a5c12b7c57952 8915 haproxy_2.0.11-1_amd64.buildinfo
Checksums-Sha256:
 2e8f5aa3275a8e4820b6633148aa63d16a3fc7a52b76ff9d8dcf8e4dc434071c 2302 
haproxy_2.0.11-1.dsc
 31b2b025922d726fabfccc5b054e2d412c80cef027a2456bde7fdf7f307d18d4 2633162 
haproxy_2.0.11.orig.tar.gz
 575d70524b7a5478066fd44ca0bc06eae28c6fbc6c6479e52506056e4736b80d 68372 
haproxy_2.0.11-1.debian.tar.xz
 1ece5a113343d8de77b0a1e8037ef48098df5c1e78f723ff4e5aafcb906497df 8915 
haproxy_2.0.11-1_amd64.buildinfo
Files:
 ef09920aadd51e06c5702a68430c1670 2302 net optional haproxy_2.0.11-1.dsc
 e8a501f7b116c3ad0502564cde4f160b 2633162 net optional 
haproxy_2.0.11.orig.tar.gz
 fb269f15c037f59d4b17145b2537c71e 68372 net optional 
haproxy_2.0.11-1.debian.tar.xz
 0aa49383266ab7d9b0075c08a0669ad8 8915 net optional 
haproxy_2.0.11-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl3z4BsSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5Mh0QAJlTGz3yIo0HJ9gEjbN2crssCypRwEpN
wN4DVYoeBmeYJ3uHgmnM/Jkfo6ZHBN9bCWgD7UzX0xyMZDMi5b6kmkDMKaz6PxSb
NVkMV1ef2pzZ6EoJIHelwzyO6zPbJJqMtMa2hvd8rhE4N5HbMOtD4ZL+Ml/mVERi
iMTlcD0h8deAYJsAZerBiS7LSoNiXElDP5w/emCuReHVK87zl3sOHCsLVryDTiEK
86msGfsDMP2fYZcl5dMRRSKnCc90J1Pazfw904Dl+R0kC2yQR2KGsmUEUvpnRAIG
1pLVJOo/H+ZBG3fM5qI+3/BMPgu6nim9ujpFdVm0gHkEIBfHWN2KSD4HRh9XA4+W
dA/BVUu9s3S/gECHD8gerKdsSnMxDMGNv2u+n1ZW2qWqtfUbjulMa0hlhm1yZnKk
sHG5V0K22b8dnqlwi6s13n362MksLI9UwPYpRuP56i7R25TpN0dBFiRxtBS32GiH
aq+eaE0V0ilRpQa5NIx8kLgGARw/8iRsDeVieWozWDTdqrsutHzb5M3gTnvWUKBp
pXJx0cOaqgSzwZJumdRbhk6gtKSrbQirtWu6a0aqg5l1t2JqUugcKGx0vugfM7hp
T7QjKrvwwI9zTHCz6BJoG56rVeVpcey0wPjkKxrr8fabSGc0hLfK2hREi7+MDh81
YLgWUfkqNZ0i
=ucWB
-END PGP SIGNATURE-

Accepted haproxy 2.0.10-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 26 Nov 2019 13:22:17 +0100
Source: haproxy
Architecture: source
Version: 2.0.10-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Changes:
 haproxy (2.0.10-1) unstable; urgency=medium
 .
   * New upstream release.
 - BUG/MAJOR: h2: make header field name filtering stronger
 - BUG/MAJOR: h2: reject header values containing invalid chars
 - BUG/MAJOR: mux-h2: don't try to decode a response HEADERS frame in
  idle state
Checksums-Sha1:
 31bea2aa3c7ef1ce812c57cfc148aa60a1041a68 2302 haproxy_2.0.10-1.dsc
 7a81094c367621a981012480cebc7c152c482d75 2557865 haproxy_2.0.10.orig.tar.gz
 f21ce7da5ed9ba87c933cee3183d1e758b2c4706 68332 haproxy_2.0.10-1.debian.tar.xz
 14ebb20635d5ac16ea8e4e0d80f9088d0eea8c4b 8521 haproxy_2.0.10-1_amd64.buildinfo
Checksums-Sha256:
 ed14ff7233084091c97518940740165d62cdf47799e34994551fcb5620275558 2302 
haproxy_2.0.10-1.dsc
 1d38ab3dd45e930b209e922a360ee8c636103e21e5b5a2656d3795401316a4ea 2557865 
haproxy_2.0.10.orig.tar.gz
 29cfdb0b18e3f0e37449fa9ba9562ad59b50b1ef8f9dc97a16bdd2f9abe5fe46 68332 
haproxy_2.0.10-1.debian.tar.xz
 c1354cc2e0493426e471f330833aad79745986375c0a8a6e0509454ca863e631 8521 
haproxy_2.0.10-1_amd64.buildinfo
Files:
 e71ef897cc31b9159feaca9b320e01f2 2302 net optional haproxy_2.0.10-1.dsc
 501f490f0fb6c01099686d2f0e02f644 2557865 net optional 
haproxy_2.0.10.orig.tar.gz
 c1b400140d46975156c2085b3c90ddb1 68332 net optional 
haproxy_2.0.10-1.debian.tar.xz
 40e3d76a4742ccedf342aa1553f71ea0 8521 net optional 
haproxy_2.0.10-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl3dGggSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5vn0P/3pdYJ75a3NEJd/HwcHaEWOebvVg/Mxz
ikz+ZAQZ3KgZxQEelCSlEdEQA6N6p+BrdkPDT4kRIbugcwM/dd63jlmCEMevuXa1
2x/IQJUJ234ga3WIeQGxbijX+lM0pX20rFwzt3HxF7iXHv6Ls8GnY+qIaYSJfaI4
Yvf1Og9PGra02/HosfP0IPvEb6nojTbgbf8UwEz8Za9G8uJHDquFVL+JKQyC0x3m
Y3yL4yEsxEAKgbd+hFiDaAJF5BfEUgp5ANo5JTUFuuQllmBehU5wtWu3BTUJqF3R
HksqABzR6e63Zf8gtG2DEMW7urtr1VPQrKz9NWOlRfQklC5lUoJv76y2LtKYwrxv
Cm+aNhuC5hwDRcZYjRnDivFXeR5UbQ61wemxhBK4ZirFGCufWQxgTn3ICr0Wtv78
BHmxZotvAlb9R9j7xJu47EyF+Wrdla3K4guH55BhcDviiagP1B0xJmZ4+tDirS6A
Wg2WQppPhUSq9EALFUaq5bB+6nFGOUb2NIVE1Fbj+ll91uTd3B4yPo1OIbHFHHGS
/ub0oJEHiEd5UVJa1Ffbuefxd4dy4wErUuHrz+KCdwBru8QhUz8ztZFtYkYKWwwO
EVoqDTob65N6K79nuyb5ZuyZeLYGmIBG67W72zQoDtTIQh2iWEOXZ9U2T77c9+9q
jKpQmfLsx2QV
=cQlk
-END PGP SIGNATURE-

Accepted haproxy 2.0.9-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Nov 2019 17:38:51 +0100
Source: haproxy
Architecture: source
Version: 2.0.9-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Changes:
 haproxy (2.0.9-1) unstable; urgency=medium
 .
   * New upstream release.
 - BUG/MAJOR: stream-int: Don't receive data from mux until SI_ST_EST
  is reached
Checksums-Sha1:
 ebdb5039a4bb2c24e1c48ec8b7bafef4cf89c544 2295 haproxy_2.0.9-1.dsc
 e4aa07defd004fc5340562f599ed16e485fb4113 2547818 haproxy_2.0.9.orig.tar.gz
 f421631c89e32224cfbba195ef9a4389d1c7ca5e 68256 haproxy_2.0.9-1.debian.tar.xz
 17e8075c2b5304f889cdd6d83a76f0ca06c3040d 8854 haproxy_2.0.9-1_amd64.buildinfo
Checksums-Sha256:
 61d32287869e94a9445f301b7d10892087e45ec15235c4965c4a98c0f0e783c4 2295 
haproxy_2.0.9-1.dsc
 35692801abfd6dde4976cb42fe5cee8aaf61959e743003426073c3141494c589 2547818 
haproxy_2.0.9.orig.tar.gz
 cb80c2581e8847a69826cb3b05be9b983fb9b734f833f308e85da82004168c81 68256 
haproxy_2.0.9-1.debian.tar.xz
 cc0b813764e86795b521d553641a85bf8164de253018703afb607cd477c51aea 8854 
haproxy_2.0.9-1_amd64.buildinfo
Files:
 62eeba5109a0e0412e5fe3cf02cf6e7b 2295 net optional haproxy_2.0.9-1.dsc
 dd1112a210392fa9232019a6e69e1d3c 2547818 net optional haproxy_2.0.9.orig.tar.gz
 624d3416d03cd50d3bfe92d6b0ca1f78 68256 net optional 
haproxy_2.0.9-1.debian.tar.xz
 3619e21589285a51a24de56368ee62e3 8854 net optional 
haproxy_2.0.9-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl3QJ4ESHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX570YP/0OAWDWNAVbVLBHNFsUXBNyrnC1CKbD2
a7jKQlHeTGhdwikVrowBL++pv1ACHIwFMPL8GXU6voZ24Vm+P2wq3dpbFr3KA1VQ
gT53zGMQln/Zb3lBWfKydSEhNVpWWcw+AQZFy3W52ZjybMA0T3K/Gv6GSo3mQqPt
icOT8sqDyv9KA1gw8DX/CfejHf7jFe4Vy8Gk7oDGdkMZ6d4eegDnWFwRL5gsO4FS
slKApk5LnznpmgnNplDMiXgl8gxjX0UQd5Df73YRazRDFY9L2jP72LMoC6EW5Qn1
kd7mkm+MZ1FqmGnwwXdtvxJt34nbgehbdv0HkhMtv5yp3nzpaxexl//ljrrvgfHb
jfbJp3IGwOsKGhTBwypZdC7SVnPIBcmgPY0TkkV6A/M7D466omTIbEVgBgcf860g
oBadSUy61gZawpTc0EQoCQwBJHCtTMz9ktuQvbrnO/pL4Qp9YYg6M4srprxmz1bJ
5NN5qT4GmJzBpy/hBLM9pXD3jm5nF2yfmPdD45RJQBq1M65Yl6rzBS42cABF1lX0
jukGMvmkJrYw17vDbLA/PCPlPJpJQSin1mCDD/Ac4bFekmEAw2sqoTg2ZzbZSoLi
XcEbbHijxQ7mBqCloQ5jIU8EpfoI42HDy7JlWd7Rnai/NCZbCgKlaZfkJpnaetcG
3EhGlp1rO9+C
=sAR6
-END PGP SIGNATURE-

Accepted bpftrace 0.9.2-2 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 05 Nov 2019 08:22:07 +0100
Source: bpftrace
Architecture: source
Version: 0.9.2-2
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Changes:
 bpftrace (0.9.2-2) unstable; urgency=medium
 .
   * Bump version to rebuild against newer version of libbpfcc.
Checksums-Sha1:
 60eed1150896a9e80026c575bb546cf471557704 1977 bpftrace_0.9.2-2.dsc
 44c449df3e074fbd62df6ec9ed6cca84090d9b4a 3228 bpftrace_0.9.2-2.debian.tar.xz
 d1f8b321cf42efa56c436909025f09208201f0bc 8055 bpftrace_0.9.2-2_amd64.buildinfo
Checksums-Sha256:
 c4623b83989cb077ded50abe944cb8cdeb75ff0f74035616dbffc6f71df09a40 1977 
bpftrace_0.9.2-2.dsc
 4685166b52fbef41b4513af8b67f0dbf29eb10a9cd59d9ff5c53c7b2d4d733d9 3228 
bpftrace_0.9.2-2.debian.tar.xz
 66d4dd6a663ca107ca6b536e700e11bbda666828d2502994be6337c1221ce632 8055 
bpftrace_0.9.2-2_amd64.buildinfo
Files:
 6440758f942e493ef66b184c099310b0 1977 utils optional bpftrace_0.9.2-2.dsc
 a1a6c1f549b4adc1faaf4a07fd3d2489 3228 utils optional 
bpftrace_0.9.2-2.debian.tar.xz
 bf45ca5f817df174acd6a849dcc068dd 8055 utils optional 
bpftrace_0.9.2-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl3BI7QSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX563oQAJ/uCOmtrkvvosENIBt+q6DkwSoO7+dC
GlGndTY07Pw8eRlfrmZA2jBDG+03F/mfpbGKW0jbWMQAQNqNd2RofyLwCu+DDrxG
7en96avFVXC9TuNA/LzfNqYQDsEcAJAzI1uWo9mhaC91yD9yDM/s/ABrBacS7Vin
yoVUaYygjzsyIesDfWh9HYIr4OgzwttqJQsLne5es3UCW6Twac7uhBoxHMY9cO9S
ocVEfaX9glH3YlG9nPaxkYXJrFEpsMnCFJQHlyYQ6r74Psp8RgA5OCE1kB26YSVV
QAutRDzEY0YJ8Ipxuysf22suSsF/Gdb99BTBm3NOvH/HtvT24pKL1cDerDnXFyUX
lFIeqnLAx21exwY+wTmTVxUKItqeBdSPEtmOtKPiayJB7wNFQmQbq+1ow3D9XP9E
5PVcEwFXhI8OvCHGZiS3Dgmr2aW3IAHDEu/Ryj0PabX5QWStbXftzLZxdtwjVoSc
M2ibTTe4i6m7/dGAUAM7sJzdejCKDrrxSFL5Nxx1maJyHdN2HWjDM+M/SkkzDIbi
OowKR0PVZVta0jkkHjVW0VxhV8A1k9lVEwpOrfAp00AvcJ/2QlaW9ByZG9aIx7W7
jsZsahsiV5Re4rJryjaEfooe4Rc6/3axiXUkY0yxWYy4Syp+xez4fGXmhLz6k4Iu
vfymKMjF5FwZ
=Bysw
-END PGP SIGNATURE-

Re: BITS from the DPL For September/October 2019

[Vincent Bernat]

 ❦ 31 octobre 2019 21:49 +01, Thomas Goirand :

> The idea has always been that it would be on best-effort from people who
> volunteer, without forcing anyone to do any sysv-rc support if they
> don't feel like it. What you describe goes along this line.

I have raised my concern about this a few months ago and it seems this
is not the consensus:

 
 

My impression is that there are some people pushing sysvinit related
work to all maintainers through this policy item but keeping quiet
during discussions like this. A GR would give us a better view of what
the project thinks.
-- 
I do desire we may be better strangers.
-- William Shakespeare, "As You Like It"


signature.asc
Description: PGP signature

Re: Integration with systemd

[Vincent Bernat]

 ❦ 31 octobre 2019 17:51 -07, Russ Allbery :

> I think we should adopt sysusers.d fragments as the preferred mechanism
> for creating system users (with some rules, such as a standard for how to
> name the users and a requirement that the UID be specified as - unless one
> goes through the normal base-passwd registration process).  It supports a
> declarative syntax, doesn't require putting runes of code into a shell
> script, moves us farther down the path towards reducing us of maintainer
> scripts for most packages, and avoids the whole dependency and
> pre-dependency mess with adduser that took forever to sort out.  The
> syntax for sysusers.d is straighforward to parse, and support for
> non-systemd init systems via a trigger or boot-time script (or both) via
> adduser could be easily written, hiding the distinction between init
> systems.
[...]

An alternative for many system users is to use the DynamicUser feature
of systemd.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Accepted unoconv 0.7-2 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 26 Oct 2019 17:07:44 +0200
Source: unoconv
Architecture: source
Version: 0.7-2
Distribution: unstable
Urgency: high
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Closes: 943561
Changes:
 unoconv (0.7-2) unstable; urgency=high
 .
   * d/control: update Vcs-* fields.
   * d/patches: don't update linked document by default. CVE-2019-17400.
 Closes: #943561.
Checksums-Sha1:
 e5a67084dfdb53c706feb58187e5b53bca7ee736 1851 unoconv_0.7-2.dsc
 2cf73259c57b3b5bb8fec049e20bf9a260f48621 6240 unoconv_0.7-2.debian.tar.xz
 dee5cb45c6506cdbe0d2652b1d69feead9fcc623 6491 unoconv_0.7-2_amd64.buildinfo
Checksums-Sha256:
 85d88c85b5087f041718e865dc6c2972c4045356c92ee227be97928f39f5a0f9 1851 
unoconv_0.7-2.dsc
 c8b3913951c092608840c69dd61654e76f63f929fbc0d4c2926fd94cca953431 6240 
unoconv_0.7-2.debian.tar.xz
 2ab2fe6e6e43794df4d1f4a05eb0617bf722a0ac1cf0eee0536edfe80b2602fb 6491 
unoconv_0.7-2_amd64.buildinfo
Files:
 e34f0e462dd5e41f92dce1d4aebfb089 1851 text extra unoconv_0.7-2.dsc
 318802d36863955809f86c06cb9ec955 6240 text extra unoconv_0.7-2.debian.tar.xz
 4119b360624c11e047f0394a4914590b 6491 text extra unoconv_0.7-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl20ZcASHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5FRkP/iSk1yxIxcnWZUaDsSTkThIlBAIhvul1
VYKDwItQtpEcaHdrRDfMEweNx10EakIhtSMXvupMAjtJZxdoyzDNeISALNDRhHaN
h9MMNrJh1ki2InAbyIdEE3HCPpz/dXEzA9KAAZuaCPLJINShf9ZFMwpByAsV75tl
IKRukdgRqm109t3hOq/4biEUpH1mgQeAl44aNH/DJbcSSNqCuZz9KGRTTN8lzcOy
XOIIMRkrnbFdbO4nuW4b5/KgwNeZW5frDDd/MApk2h3vvJ8JIA9FJ0hZevAiIcJK
SlmrOEB+7ZJNZ6LX0JQTxqGXhsV89/s/cVtOw+KqCFoHCqGpveN8oXL7q9bZkgAr
4sA08r6PA37apR6mYXf8QJfh20mlJOf+6tRSKu/GR10B5ADiBgvv1AJFmEO8T79y
GVljaGf7fXxdlulsYSUe6r2GRRJpykFjIpsBOboOotUoqJZg8eHy4dRlwt0kVxrZ
rViNWR700cH/0DTt5jAkcQoN8ZpsIdpxEP4B5q7QGeOT7+s4NO1R4z/k2J7I+EUP
OYa0Ia2KTOd7Wq9KM7FQ8bmgFeWaT+qvaF4do+X1zygFZfUP9PLVQ/BzY7U3MW0b
US5wrPqNjDH1l3j1MfKh1VetkgC5bvSsZ+snGjqi+dzkrqiX8TnbQIuPcP68Yh6g
Gq5IL48y90jU
=dQnW
-END PGP SIGNATURE-

Accepted haproxy 2.0.8-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 23 Oct 2019 08:55:55 +0200
Source: haproxy
Architecture: source
Version: 2.0.8-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Changes:
 haproxy (2.0.8-1) unstable; urgency=medium
 .
   * New upstream release.
 - BUG/MAJOR: idle conns: schedule the cleanup task on the correct
  threads
Checksums-Sha1:
 4a25b6b73a820f915a797c1c4f78fd06cb8bd6bf 2295 haproxy_2.0.8-1.dsc
 9819196b323b954dd41fa5dde746d8a0c701440a 2546661 haproxy_2.0.8.orig.tar.gz
 4efe7e2f8f3c8c887c2c7b8b440914ee18f82163 68212 haproxy_2.0.8-1.debian.tar.xz
 ecbf34f6b3de98952a188e17af153cdf8f814b16 8834 haproxy_2.0.8-1_amd64.buildinfo
Checksums-Sha256:
 fd01d63a89ba1b049f7157e092d7e62bde2dc07ba07546217ce267b08e30497f 2295 
haproxy_2.0.8-1.dsc
 c37e1e8515ad6f9781a0ac336ca88787f3bb52252fb2bdad9919ba16323c280a 2546661 
haproxy_2.0.8.orig.tar.gz
 f83b28c67df6d71c43491af349f43f87e528759cad3106f25b39077d277bbdcd 68212 
haproxy_2.0.8-1.debian.tar.xz
 21a68a346a55b7a7b0c1ca9cce5d055abc072da887a7ca1606d50bf47d385abb 8834 
haproxy_2.0.8-1_amd64.buildinfo
Files:
 99fc8cc19b76fce801820a2c1e6030e0 2295 net optional haproxy_2.0.8-1.dsc
 745fe3f6625bb0f49380c2b6c6b350a7 2546661 net optional haproxy_2.0.8.orig.tar.gz
 9ccdce571cfc785e4d9b4841439667c4 68212 net optional 
haproxy_2.0.8-1.debian.tar.xz
 1d85453b3be6a75d7eaf6ab95a4ba5ca 8834 net optional 
haproxy_2.0.8-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl2v+r0SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX59k8P/3GjLnmyWqUxV9Xei6U/0Y+6YR5UEF7p
2Fd8LkNZGFIj4EPyfQiwp4fEZeG2paKwcq2tSK9c0b2P8Xh9HRcUZ/einyCD3OoV
mzQqYlF4MVPzs3VgIqBs1NDPso7DnJBY0dJgTXLKo/IO/8nzM8+KpRhwyZlmaID4
yU1HbPIdWbq8NhL2VTfP1K7p9stZr/fMxIcvH3ymHsK4KsSUAPrm8i1nobBE79Fy
o/kw2g9QyI6ksVCiqZ6zTAX/luXhD3FSPbCquOb206rTfmRnrvzQATCkt6pMLfhp
5icHqPezMICqT97EtcsbroUo4B0NMlP1WNvuzfMx12YwQ3+yFDF6sf1ulWGhy4mb
9Xb1orjQVzVf0WAmoRP5m3q+Ihy543hiSYXkMUPulgIJFm/+vb4nhG810KE4DD5N
a/RDwzi6jxuf08eGXwnvAdZ78tK8ZVbwqT5RP5jD9QQpZvT9BHYqMJ3/27KNbPq9
PJvdrfxj6Y2evwuiCHx7qqmZT8NS982PJXNTnykrzKfjgg3L/YExf+y44oR6oO+a
lPQJntr2ekejIyHf2rbkTaDl4SXZy1U1THNNDgZ038xdISKbCHKzerQo9SZS/h8z
B0tio5LCkjV0iF7em95rtk3yz5uWA3BxXi/icXfG9A7wTHFhrABs2X3rdhzhfr6N
JZp5rI7DcukE
=fk2U
-END PGP SIGNATURE-

Accepted kafkacat 1.5.0-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 04 Oct 2019 17:07:58 +0200
Source: kafkacat
Architecture: source
Version: 1.5.0-1
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Changes:
 kafkacat (1.5.0-1) unstable; urgency=medium
 .
   * New upstream version.
   * Enable avro support.
Checksums-Sha1:
 a62ead567a524c3f27c048c688ea3d5ee56d2120 1989 kafkacat_1.5.0-1.dsc
 fd178d37a604d3022695045536df3b6e120c84ec 124682 kafkacat_1.5.0.orig.tar.gz
 16e487593c15846aae634fd733e85856f7bbc1cc 2548 kafkacat_1.5.0-1.debian.tar.xz
 247883e86a7ea4c937272cfb617f778105352df7 6309 kafkacat_1.5.0-1_amd64.buildinfo
Checksums-Sha256:
 9acf80581392c2dcb585a66de435d2f3fc98351d4fdb609a254a49f2ddd4b6d4 1989 
kafkacat_1.5.0-1.dsc
 16f358fab258cbefc328cf642f72ee8b5dae1648657d508997279ca5bd0fbef0 124682 
kafkacat_1.5.0.orig.tar.gz
 f4331123f570eab9dcc4e0630f805714864ade14c4de48729cbfd3da8efa4928 2548 
kafkacat_1.5.0-1.debian.tar.xz
 deeed43e43b58800ea041c9af80511905f6e287fda9a1d7a2e68c4aebb22fdeb 6309 
kafkacat_1.5.0-1_amd64.buildinfo
Files:
 953a972ef71a9e551100692e9233ef10 1989 net optional kafkacat_1.5.0-1.dsc
 d5fae3f7f19ce25f120af4f6a29b7692 124682 net optional kafkacat_1.5.0.orig.tar.gz
 35c5cd7c611fb6d68183569af8fccfa6 2548 net optional 
kafkacat_1.5.0-1.debian.tar.xz
 cae41027147acf1d927b416d7c382806 6309 net optional 
kafkacat_1.5.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl2XYYASHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5A+QQAIVFJr1ZEOrGXHtr+ZInT+Bc22hWZO6N
a4hgguZ5oN2PvHHmSg53qviLqByKhY6UIWeFNtDRrBWL+VZ2GFdTEg5fbt4dEdeE
ihCU7NTa0c15gOOVXZ2BTHKxRdj8aaNfDZWdVeLWMCCx/Kjylf1ltpDv3xywN2VF
v4tpdQo13kUhycpS0ZVwAdslArkrY6ufLXRzVWuCBw62+io2B+jN1cW5/SK51qMn
vq0C522p/ckwhtqMron2aD0MyQAj3JWhiRjmOzphwYo9WPldxWF8IteWNzvRH3kP
vVmfnlC++yBfXhKKF9xKl3uDCpRJvqyinJEmciIHUqDJ6UHcZ/siIu4WljgaOzYE
/nwpSdv6P0C0KBMuq4GQIAe6Vu82Cb1VOXvaY961Amt3TDUZ0W+/3P5/sdgl3uP6
dAYE1WpgF/n4Wsvtc9nMGdPPFwwWcwjrmg2zqgu5bSSZXLDsU+Vw5b3cUavcPHAU
8b8YhCmrfnTHgK/1pisSjAIDyEYpOxE1e336hJt32Sk94pnNiXi0KeBXtHFioIlr
s4hF8ox4CcKqOLHLSZh14AxPX3X+HwOqH1KyzO7Gre0BkymDsWW0QWmnhBAjLvw3
5TKS8KYws+OpK6kL77Orh4TXPFl3jAB3u88Rk8MeE68vqNdhSBdCB5+zxld2nd6T
g5pVdzCFqxgH
=A7MX
-END PGP SIGNATURE-

Accepted xnee 3.19-4 (source amd64 all) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 02 Oct 2019 05:53:09 +0200
Source: xnee
Binary: cnee cnee-dbgsym libxnee-dev libxnee0 libxnee0-dbgsym xnee xnee-doc
Architecture: source amd64 all
Version: 3.19-4
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Description:
 cnee   - X event recorder/replayer - command-line flavor
 libxnee-dev - X event recorder/replayer - development files
 libxnee0   - X event recorder/replayer - library
 xnee   - X event recorder/replayer - metapackage
 xnee-doc   - X event recorder/replayer - documentation
Closes: 941553
Changes:
 xnee (3.19-4) unstable; urgency=medium
 .
   * d/control: build-depends on texlive-plain-generic. Closes: #941553.
Checksums-Sha1:
 f32caa861e071eb55b7430a56052f80d139f971f 2214 xnee_3.19-4.dsc
 18da85cb5c010ce15401e7f8546cbb2fe30c225c 13203068 xnee_3.19-4.debian.tar.xz
 ee8c579acf6130069de270a6e42e98edcb2ec44d 106368 cnee-dbgsym_3.19-4_amd64.deb
 8e9931176484b49d832166e21ab98798a9c72b22 51920 cnee_3.19-4_amd64.deb
 44f0f892eb54ced6f95ca1c6e753724be9df74db 136096 libxnee-dev_3.19-4_amd64.deb
 c0f713842712e6f3fd158fea795ac0dc6800a565 580208 
libxnee0-dbgsym_3.19-4_amd64.deb
 7ae132f94c265361309468bbb31bbf2f9566e497 108044 libxnee0_3.19-4_amd64.deb
 c1f73b2023509a3ffc3cce97bed650a14e97994b 600640 xnee-doc_3.19-4_all.deb
 9f8384ddd9e53976dcbe54c5527cbdf3e0f417f0 34600 xnee_3.19-4_all.deb
 298ff6fb449673259c5af4ee977cbff3bc87dd31 12547 xnee_3.19-4_amd64.buildinfo
Checksums-Sha256:
 6de91ddcdb606c117289fb8868d6c456198e8f39997376ce3c3e6723b1ad562c 2214 
xnee_3.19-4.dsc
 eab1bce6da50fcb601fccfc54806bdcdca2774cd738eea617c84d7e1dcf93a1d 13203068 
xnee_3.19-4.debian.tar.xz
 ecb48e6ead5e412217d7282a68934fd4ee3e8f23dfe4510143c38fe6d04d4410 106368 
cnee-dbgsym_3.19-4_amd64.deb
 173be99e4988211ebc568e548e79e1fe30c84fefe417a0cc4213e160ef129cc0 51920 
cnee_3.19-4_amd64.deb
 b41d41193440b10942c27f608dd726c44e22d3948c51f2e71f3b1884d4116eee 136096 
libxnee-dev_3.19-4_amd64.deb
 2891c80cb4ac8b36921357a883b251ce4cc0d56d0de459a05a9e2384e4e34264 580208 
libxnee0-dbgsym_3.19-4_amd64.deb
 7388f0b442a839ccc7266ef0284a68268d04ff672ac4fdf8bc89e0b6287f917e 108044 
libxnee0_3.19-4_amd64.deb
 fa5a3a7841fb4c9eec3a21bfcb0bc152f6cd02ec716367ee17f8c3000765e8af 600640 
xnee-doc_3.19-4_all.deb
 f54dee881f87ecc19f4b68916945bd848095820c1c163db83dfad8f78b6c89bc 34600 
xnee_3.19-4_all.deb
 1e5456a0ab2375b746734e696e13ccb2936680bd1691dc0b3030ec9da3ea3c04 12547 
xnee_3.19-4_amd64.buildinfo
Files:
 4ee57380bd0e7c29c7ca73eb94fe6333 2214 x11 optional xnee_3.19-4.dsc
 15c4ae2b86977336e8cdf122a7e1de34 13203068 x11 optional 
xnee_3.19-4.debian.tar.xz
 946c16a0545ba11390504c2ffb6f48a7 106368 debug optional 
cnee-dbgsym_3.19-4_amd64.deb
 b2692e3b89ab24976b952384a4441484 51920 x11 optional cnee_3.19-4_amd64.deb
 25de28d89c7a1646a3d12d46c05fa3b5 136096 libdevel optional 
libxnee-dev_3.19-4_amd64.deb
 b98befdf8ec8249330c897165118bd6d 580208 debug optional 
libxnee0-dbgsym_3.19-4_amd64.deb
 613e8fce339c359fe2204272e7eff617 108044 libs optional libxnee0_3.19-4_amd64.deb
 5371d00db0563acb1395047ede4c16d9 600640 doc optional xnee-doc_3.19-4_all.deb
 64791225e92d0b2305f040e9b634088e 34600 x11 optional xnee_3.19-4_all.deb
 45a1cf37138439b3039c45d029141a3b 12547 x11 optional xnee_3.19-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl2UIAASHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX54E0P/A1dG4i9lN/BkE9XwxHzoC9LBEANZDxX
d6+cH1eaH7RVAWIi1ixwJ9d0oaNYmKY6P8cbxFRSSUGLjcMaNHQ4eG90aDKwM9qT
e2SwWdMqv++aFb4I/NG1Z5DVdH8GZLPrNGA2fgIN6ZEgJhIhHkwF+v1g1w+bFqiD
jLStqCvfFdljnCOP25DHaJ3qIJe/dVVh/l7HAyAEExYRIqb/M0yFAZSvwoDell21
1RTd1K4TJ8arC64+8gaq5deAiXG/e11bDrsnin7ufyhi0GfgvXK6CizJgq84JBt/
4cAKJiPa7ivQ+QgLt22HNuB+ELK7f+U/2DrXR8jQLN0n5KyHMy+N7hEDUGw/tMaX
PAkDPeleNZurQqgKt2eUlWAsFf57P3C0Qo4jnfCrRhtB0UEY2mKtIqiVZ/j1V1dI
R4cviRxh/Bfmt0ObihbGeNPKNeyh6vsK+rDFKX6compcqfPlx3Q6HrSFu8S3ZmbQ
oM9Wwk24cJJ5GmJsouOOgHrMxi9o9NrxKR33QRvF2K9WuJe7THVvVSHwgoDrky9o
HiQYmKBB4p2pJH3RrVZSsYSs2asvNGnYuO8dRXqFGjasMVvcIzGS3ntdWu77c+th
9DRjDH4aiP6B/HcAuMg6kV78iNWV9nGArPwW70wJY4+kCvvomM93yOE7a4/HjLfQ
C0eu+kr27xFd
=OoKE
-END PGP SIGNATURE-

Re: Bits from the DPL (August 2019)

[Vincent Bernat]

 ❦  2 octobre 2019 05:47 +02, Jean-Philippe MENGUAL :

> An idea: establishing a time of discussion. At the end, if there is not
> consensus (as Gitlab), there is not. If there is, ensuring every DD can
> still have an opinion via GR or changes proposals in some guidelines
> (Debian Policy, etc). While mails are too much and so long to be
> followed by "silent" DDs, no DD can ignore a GR or a change in the
> guideline, or he is respnosible. Would help for ensuring a full
> consensus, limiting some repeats mails. We do his successfully for DPL
> election.

If a consensus is needed on debian-devel@ldo to get to the next step, we
will never have it. When was the last time we did get a consensus here?
-- 
Whenever you find that you are on the side of the majority, it is time
to reform.
-- Mark Twain


signature.asc
Description: PGP signature

Accepted haproxy 2.0.7-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 27 Sep 2019 19:14:12 +0200
Source: haproxy
Architecture: source
Version: 2.0.7-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Changes:
 haproxy (2.0.7-1) unstable; urgency=medium
 .
   * New upstream release.
 - BUG/MAJOR: mux-h2: Handle HEADERS frames received after a RST_STREAM
  frame
 - BUG/MAJOR: mux_h2: Don't consume more payload than received for
  skipped frames
 - BUG/MEDIUM: checks: make sure the connection is ready before trying
   to recv
Checksums-Sha1:
 dffaac5dad9a7ed4339d45e8796c4c38d93f97da 2295 haproxy_2.0.7-1.dsc
 27bdeebafad30eb37e442e1f62ccb9da3214934f 2542573 haproxy_2.0.7.orig.tar.gz
 68115f65482466a23a62db92448d98babe159857 68196 haproxy_2.0.7-1.debian.tar.xz
 962fa3a33e051c4406f7fcb8a25381b068eda99a 8885 haproxy_2.0.7-1_amd64.buildinfo
Checksums-Sha256:
 a93b8aeea57da3c0520a48edc516c234e1aad3743a861dd8a2b33276699ee40e 2295 
haproxy_2.0.7-1.dsc
 3873cd72028ed1bd2506dd174e01a92620e92683092f34234c96e067dcb113dc 2542573 
haproxy_2.0.7.orig.tar.gz
 035aac0e9143902438a70f75c4295d5b1a9e8ecc28eec848354b0c4314232e4f 68196 
haproxy_2.0.7-1.debian.tar.xz
 6eb1f96f09ed9088c55fef9f5cc3f96477cf3547f59718df46229066ac8c7355 8885 
haproxy_2.0.7-1_amd64.buildinfo
Files:
 657a6664ce11b6e920f708d57fee9677 2295 net optional haproxy_2.0.7-1.dsc
 1db3d8bedb3482ffd3a930e24e414b55 2542573 net optional haproxy_2.0.7.orig.tar.gz
 3c78939edf09e6550b232d329e2378b5 68196 net optional 
haproxy_2.0.7-1.debian.tar.xz
 c49d3b52bcf1eabb87cfbfee104d6a8c 8885 net optional 
haproxy_2.0.7-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl2ORtISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX54ZgP/15Smhbi6x5spbxpLTQe9VHHcmatu5/u
Ux9SxFX9N8CPXCzOfsQqqSLiL5pnA5cYO37O64YHx+S7nVUp2UGEUufYnUpJ1kzK
BcO6KSk7gVOYMQ+wverPYykt7xNzHWAu2J2sLecr2mYQZDiq2i5hoKNyjXfcfDzg
VkjAcUKBJVLD5rVTKP1I7UipQdthb7GmFotOxhVq0dvD0ua8OqodWc/hDBpVS7JE
kWWF88/8wtzBZWLPX93GaI9bRL4SSIRC43Hkm/IqSZh9Dv9EeniHKaDKEykDrf9W
OrW+MaG4/eWkLSkX/janpA21AX2t3RxVeg7apuHjrxwfyRrPdHT6gq3YKWhpYHbp
A99NfJuTKCpU8mu+ca/uIUQrPWhD9SUyxr73KsczTO2fsOQmEawUMQxllTQ+G/uu
1ft0ktKZD60er6HiORpfHaK296Iz+6ZpMVgEDbf9UU4p0/ex9o6L53xvSJj09A9B
MYFEeUL4QCSoLOBC5gUvGWyzJZqxzLD8UVyn6vm4I/rppNi9C4bdTfLTiYoosK4U
ijF9CTIqpOo4/chOY1MczUVoJZM9OytwBlYaAdDxkiA/vYVaPhSmCc4qXF9rGVei
YO5iDqEK6lSjG0kOftxmxsR1XV85NKOHqUGcGvo7dOWFJ9LDeWm/R1dPFO2aHDzo
riBUQr8muS0Z
=OkHd
-END PGP SIGNATURE-

Re: GPL for package under MIT license upstream; repack?

[Vincent Bernat]

 ❦ 24 septembre 2019 10:41 +02, Gard Spreemann :

> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
> including the current version in the archives. Since then, upstream has
> switched to an MIT license, but with the caveat that many parts of the
> code has GPL dependencies and that "for practical purposes this code is
> GPL-3 for the user" [1].
>
> Instead of having to carefully figure out precisely which parts of the
> code should be considered GPL for the Debian package, I'm tempted to
> consider the whole codebase GPL for this purpose.
>
> Does this sound sane? Are there some particular steps I should follow?
> Should I create a Debian repack of the source where every file's
> copyright header reflects the above, or do I only need to do this for
> (header) files included in the binary packages? Or does it suffice for
> d/copyright to reflect it?

You cannot change the header files. The MIT license requires you to
leave them intact. Just document the license of each file in
d/copyright. No need to tell the whole work is licensed as GPL-3+ (you
may use GPL-3+ in the "wildcard" section of d/copyright if you want to
highlight it).
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Accepted exabgp 4.1.2-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 21 Sep 2019 21:05:46 +0200
Source: exabgp
Architecture: source
Version: 4.1.2-1
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Closes: 936492
Changes:
 exabgp (4.1.2-1) unstable; urgency=medium
 .
   * New upstream release.
   * d/control: remove support for Python 2. Closes: #936492.
   * d/patches: add patch to make tests succeed when only python3 is
 available.
Checksums-Sha1:
 af3f71e466873c77d46c2db168358902e325cd1a 2027 exabgp_4.1.2-1.dsc
 73712e4f20a5956890052467ccf3b01022977f87 2912897 exabgp_4.1.2.orig.tar.gz
 0f6a643edeb010308dc10e88cdb5263db3ce6f19 10500 exabgp_4.1.2-1.debian.tar.xz
 492437f9a0ffb014f44d7cb8f8bd07e723434b60 6892 exabgp_4.1.2-1_amd64.buildinfo
Checksums-Sha256:
 82ab4ce8432f27ab578f14703e3cf60ca01aae8ae7a8a9e4fea7684e62061bc7 2027 
exabgp_4.1.2-1.dsc
 5921e002f196e814d02349a15c250b1fc8bf45c7299b6b652d2fed04eebb529a 2912897 
exabgp_4.1.2.orig.tar.gz
 2060488a250c0ef720f894a5dabb64f026ca0528de74279d31320753ea2114ba 10500 
exabgp_4.1.2-1.debian.tar.xz
 feed8f828226398365c6d1707e15d76e4f2ea8d3007890910671be90188a9f65 6892 
exabgp_4.1.2-1_amd64.buildinfo
Files:
 db73aee35dd8df248f27918d8e24be52 2027 net optional exabgp_4.1.2-1.dsc
 cf36ca988159da337048a80148e66877 2912897 net optional exabgp_4.1.2.orig.tar.gz
 3c5bc926abd383e698649665decbee45 10500 net optional 
exabgp_4.1.2-1.debian.tar.xz
 22349e5abf4c6f6691177ddde240bd5c 6892 net optional 
exabgp_4.1.2-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl2GelUSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX53X0P/jz6UPz558GZ0wfY9drn7tEnfAFQab8S
w3rYt4ZenCjNFXGRc9No0vdKAoeUufMooLKvLT9XwEkzLCYR+PNbOIOdb86j8MSe
tz/HZHvCt+JGr1icAHs2yFDPW7elV1rlhBWFLDDBsZLMoHPRZKi5IeO1+r6Y+ZsI
IP/U2xeZNp3rKUQWkLwfIr5/foBKJaIe9oKblB8H82yW5aeE9nd6SjbvUXC/M4oP
wXyVAf/zUVdDw2TlFrj2HzBWunjx8JdfCx5PqPOODKeJIrjRzyCq7iQb0cdIH21U
U0m1UslHzTtdcVs2cAaqKnJjDZnAwbftBsZSrSuxZ9u9JV28nBWvJsI3SyUVE9Ff
2nlVYuL8CbYVFvnixRYhrXJl6bsG2fSYHRcM4mZApWvXssqo09Ki34blRim89gyr
XiMzeB/Yr/TQimX+368WtjHpuD/nRAq3hhYmPEV1lOeVEEPcMgEVWc7rwKkSIqWh
Vt37ukTijFtmo3W7P93nPVpuPXi/z5z+5MkKIS3jS7Bxw++tM7XO/wA5UDirMYe9
7rpjVMRwfTvlt0d98bfytyL8uh5hSsy3YkjWsB0/XzK1NkaMV90ePwSMrrl1TFQH
X/PUJfAYUdfHW08uSGwaAGw7EIJ4A8gECk3kkobUTpZMo9eQon6ZXqizj3/Ke4cH
emR9JG98xXwb
=WPPb
-END PGP SIGNATURE-

Accepted haproxy 2.0.6-2 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 18 Sep 2019 08:02:53 +0200
Source: haproxy
Architecture: source
Version: 2.0.6-2
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Changes:
 haproxy (2.0.6-2) unstable; urgency=medium
 .
   * d/patches: fix regression with checks.
Checksums-Sha1:
 6791b68c96cbf928935b827acfb0d81468ea7de2 2295 haproxy_2.0.6-2.dsc
 2b9e13473c02c43bad5ad508f62734ea940a7e4d 68688 haproxy_2.0.6-2.debian.tar.xz
 b8d0f5d79f5eda474e152f82d0cf01bb07753468 8884 haproxy_2.0.6-2_amd64.buildinfo
Checksums-Sha256:
 e4f2197388c08cc1ecc727d2972cbcbca2e16a3414b335e0c64eea92929ff522 2295 
haproxy_2.0.6-2.dsc
 5bfe7cd5d063e2250241ee389599295b470b6199a7a5fee85aca061856076eab 68688 
haproxy_2.0.6-2.debian.tar.xz
 f1474771ae9b2cc1ba53b37c70984f868862090a24b8d1b6510f5f2339f4a0da 8884 
haproxy_2.0.6-2_amd64.buildinfo
Files:
 95938b287bed06408e330d8c6d0904f2 2295 net optional haproxy_2.0.6-2.dsc
 ff73594024c5e88109c14d3c78cf0b66 68688 net optional 
haproxy_2.0.6-2.debian.tar.xz
 60ba719ba1b0dbb70d36495e32575462 8884 net optional 
haproxy_2.0.6-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl2ByccSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5uR0P/RXYbUwAR+dpYA/8d2kWB83fP3PVykNT
bbXaqcUHVkQpxeXyvOWEiA4ZW1/ECARqiRUWQ30XczS+YCIwl7evwalwZ14zI1eH
bD3MOjQUASstK04EthmrblyG9lJMA08paGUxdHNIwy8jGdxrtt5sPCGbxa0i5jQY
8rCui4ligkhUtrenOELWqfH7VgcdhF4xaPQ3NtJFqH1S93P5I8ApXgbXeV0usBb/
e4WIZLYYhRAt1BS+Dawuw1e9ZVGq6FriC9wz2aA8S70Do5cdTUB3XozNJtGsiTtd
qMa312Kn+wkZpXjcxd5QtlyGxhCm0FvJFPhafFH4Ifbtlw2K3MYa1maG6mShQd8I
uI1h2CHwyMMphiuwr8b4m0s0oFX4MOe/8uKBndx9bX3YrC1jKB4T8eeCpk0Y/5Vn
DZ5UzjGUzYGRd8A9hViVadsvzlpK9dfFG7eLNp0k2nZkZqHG/opBAo+dZkJzfcy2
LVdVUgyn0euJ9FlsP/XY0H6S54Maqy6ufs8evX++tqB5i0UzNy3rptlPURzBGY2U
J9rX+JeOf3GF5lckrqT8+o5oNjOo/igZfPUF8FvfJE/xziXodqh+RP+2BLZeYM+0
XLcZ6cXXpIdYgPBNa2xJLqfkXzWnbARRXxmvEefCQ2/uP+i7eRuFgj73HgfgoeAX
C1ST/KKY4QCt
=TDE6
-END PGP SIGNATURE-

Accepted haproxy 2.0.6-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 13 Sep 2019 21:25:38 +0200
Source: haproxy
Architecture: source
Version: 2.0.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Changes:
 haproxy (2.0.6-1) unstable; urgency=medium
 .
   * New upstream release.
 - BUG/MAJOR: ssl: ssl_sock was not fully initialized.
Checksums-Sha1:
 15d96883ea804c4056c330cc75f8eeb65443145d 2295 haproxy_2.0.6-1.dsc
 090530f959af9c5801edacf9a9f6341a71da232e 2541637 haproxy_2.0.6.orig.tar.gz
 92cc22b5c2dad8cbfb7818e3ae5e3daa5f516bb1 68088 haproxy_2.0.6-1.debian.tar.xz
 2c07a9b868f7259953cc848901398db774c3efe2 8853 haproxy_2.0.6-1_amd64.buildinfo
Checksums-Sha256:
 16e3180cc0a66fb54d06abecba9134acb8e42ec2051d12c00fb0fcf7eba4263c 2295 
haproxy_2.0.6-1.dsc
 01e1da0945201007ca1b3a8b7f1927731ba0fe4380bacae1c626fdc521e4 2541637 
haproxy_2.0.6.orig.tar.gz
 928f85ccfaf857c4162190fbcccd0117554aad41c627aa2b7765787a1e8be4a0 68088 
haproxy_2.0.6-1.debian.tar.xz
 eb8037fc313391322939bbb361477b5adbcc5b73fd9b9f7bf9f95a1f7e376dd4 8853 
haproxy_2.0.6-1_amd64.buildinfo
Files:
 e7b00718997967d74245e5af81193834 2295 net optional haproxy_2.0.6-1.dsc
 3c600ff322bb89f66e3f51fb283b988c 2541637 net optional haproxy_2.0.6.orig.tar.gz
 9111776143e98314b9c6cacac7e320df 68088 net optional 
haproxy_2.0.6-1.debian.tar.xz
 4c5e1e88ca3c028d5eaead5e50f91cb1 8853 net optional 
haproxy_2.0.6-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl177lYSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5mI0QAKGyzipK9JnqwKSSHUJQ3Dt2ksUmsYVx
K/l/p+PnpA+kwPGdwv6cw7KNH3UBER4w26avEwubzB6OnYc1VTpQGywvME4Yweq7
ZHW4Glyqx+KyRvVfmGhzy+YAMhSLC7tpLnW1/DsIvgU5gKa1KKpGTnbTa4ukhmiF
VzmnbtbVrpcxr0JLh4NqUsiiwUH6Z3sFpRH+mRJSviKC3nXYt8imQqV9qeLGzmyd
68nBG8IJCsxGiwfxW8hV0SM1LzycrcjzKhrBXkcx4R4C84VtAWWOb9Dmedh3ZddX
b8lXOg22eyBJH23xqu8uHvcBLEMxW7qEWnsGCrWopfJUffd2oVvpZLL+imqD0Kb+
im/+LT4BFqa8nZe2ViKUW3vK693Inl9v2DOrlH/S5FbypGHPHRZ0EJfu2WSrpI58
aIbCE1iBFxrfZ17bXWidV6qxk3wdRJQS8BuqDC1CtNc5mg4/bZyfZi2NRN3WQ98W
eZo55CiSnGYTqOT/nOHFehHwRHxeeYdXJFHN1v7I6BP2utv7GJNU0Yo++JS+y1TL
o12WbP5IG7E8PXxRoAJJv2dqGR8xEth41Pq3wCsIuSex2FLpEFKvKy4hasZ3QQGx
flAYdsSAmv75xmaKyoNL9fa8ZQVdbtNjA28KHALSkXk6BGBci2KPnDmE3b8ySwNn
oaW1UtAZ1/eV
=SJ6i
-END PGP SIGNATURE-

Accepted netmiko 2.4.2-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 13 Sep 2019 19:14:59 +0200
Source: netmiko
Architecture: source
Version: 2.4.2-1
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Closes: 937130
Changes:
 netmiko (2.4.2-1) unstable; urgency=medium
 .
   [ Ondřej Nový ]
   * d/control: Set Vcs-* to salsa.debian.org
   * d/copyright: Use https protocol in Format field
   * d/control: Remove trailing whitespaces
   * Use debhelper-compat instead of debian/compat.
 .
   [ Vincent Bernat ]
   * New upstream release.
   * d/control: drop python2 package. Closes: #937130.
   * d/control: add dependency on python3-textfsm.
Checksums-Sha1:
 4d2b254472e3bd5a3c490e8d4ab95b1e2bdb4b06 2082 netmiko_2.4.2-1.dsc
 1b4f6d1dcf9a1dea6ae87b75ee4d4e18703b1634 88802 netmiko_2.4.2.orig.tar.gz
 9dcffd9972dc8f44489faec1a2ee029a0f627aa6 2764 netmiko_2.4.2-1.debian.tar.xz
 3acb59c0d82f683f39751ff39f4229964cf69e27 7284 netmiko_2.4.2-1_amd64.buildinfo
Checksums-Sha256:
 de5b8d3e99dceba56ef632a9d30957a4356e9d44d531433542eeb1dc78e3be0a 2082 
netmiko_2.4.2-1.dsc
 e6b0cb98afb51fd1fb1d04d024d7572a0b5297dfa0bd18405ee36580deea65a1 88802 
netmiko_2.4.2.orig.tar.gz
 88013ebcedc5bd73a8a1664813ae67db76a9ad7b0b39db200b83346ed7e56202 2764 
netmiko_2.4.2-1.debian.tar.xz
 2a93c6d2f6e8147583792f11376217d4964f64643bd9ad3726b076b11e8b1b99 7284 
netmiko_2.4.2-1_amd64.buildinfo
Files:
 4fd337e7b5716a65bdd27d26822d682a 2082 python optional netmiko_2.4.2-1.dsc
 3419399e6f644819d3aacef0dc9a2296 88802 python optional 
netmiko_2.4.2.orig.tar.gz
 d9082d5261f2fd433b710ecadff8d1dd 2764 python optional 
netmiko_2.4.2-1.debian.tar.xz
 b218070182cd3109f78e7f688cb0db8b 7284 python optional 
netmiko_2.4.2-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl174mYSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX56a4P/2MhqVvbG0GNL/DdKpVpdCwHWOj3M6B5
9dBebOE7ulQbYI73SRXKkkfbE+uyaCTLdl6ZAMNJsvkLXE3YukiclfMAokGGrRdU
eLNIzvUxtxpMevd7PztOHTcBaKAwlg1xkZUktzBpkspl7bEbFRjnxLJ/wprB9ag5
we2BZ1XhLi8+KxCWsLzaAlaS5yh/195SZOlTOfNMH3J6qfQ6fweAgg0K2/OXRh68
p7ELiiHm2HAr0+6+iiiZzkknLf6GoF9iCdMOQem6BuBff2BT+VPs8gf8NR/Lg4r5
JSdcV4vSIA31VhmFrrfUZklSUCvIJ1V7XVOi80zsAqbb5gj0ZEW9APSEg8aToSQ9
VL7dSoKYXwIrsIsvqhFw14w6L00Ioah9G3lbf0mCC/Q48cNhdMoCNvXjVLrw/kFq
NjmeA1LwLmI2Sypp4OaepQO4YL+c4bugI/P7A1Qqz5Lg05QLAb/c9YosE1qPzk8q
jWk5lysmH7sD8uUe7K7dTOumeEIEUfo1+b9BgJ95NaHU5PiDfxA2+DPcSJLSZaad
R9j5BRyaRnvVbLAphhrHcZP2/Y6HrT63DW9KgUlsxnEcx6A1ZSNDeof7g9L3L5oZ
6m6SmJzvndXR3LAdS55X3Rd1JEKdakrATFHVDK0H70XP76qHnBNcCl7lV0Ac41Tr
/0ZCmPhLEgjM
=0cMO
-END PGP SIGNATURE-

Accepted gtextfsm 1.1.0-1 (source all) into unstable, unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 12 Sep 2019 08:29:32 +0200
Source: gtextfsm
Binary: python3-textfsm
Architecture: source all
Version: 1.1.0-1
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Description:
 python3-textfsm - template based state machine for parsing semi-formatted text
Closes: 936671
Changes:
 gtextfsm (1.1.0-1) unstable; urgency=medium
 .
   [ Ondřej Nový ]
   * d/control: Set Vcs-* to salsa.debian.org
   * d/copyright: Use https protocol in Format field
   * Convert git repository from git-dpm to gbp layout
   * Use debhelper-compat instead of debian/compat.
 .
   [ Vincent Bernat ]
   * New upstream version.
   * d/control: update homepage for textfsm.
   * d/control: convert to Python 3. Closes: #936671.
   * d/control: rename binary package.
   * d/watch: update location on Pypi.
Checksums-Sha1:
 f077477607bb2010b9e3768a4c7ff9913f703d40 2045 gtextfsm_1.1.0-1.dsc
 909833d5bcf547f1cd93f99aea2eb41dd84cf0ac 51104 gtextfsm_1.1.0.orig.tar.gz
 0040835b4d1732044c653b877409a9d53c6edab9 2008 gtextfsm_1.1.0-1.debian.tar.xz
 4ecd3006dec2b8e5800a9337f4031e5630dfc889 6616 gtextfsm_1.1.0-1_amd64.buildinfo
 bf81a6f925be8a649b31fcef4fe13a2ad19a4794 28108 python3-textfsm_1.1.0-1_all.deb
Checksums-Sha256:
 2291e2ea993032c71dd98e318410ccb45ddfc4352ae16c3904f68c4b3afc40b0 2045 
gtextfsm_1.1.0-1.dsc
 b750de2986ef78696e686b510a96aa23206a575580daf2b1eb7e17525ed33045 51104 
gtextfsm_1.1.0.orig.tar.gz
 e089183e8a787cf421d44ef4a82216158c28db8a196b7c55f2139870be157261 2008 
gtextfsm_1.1.0-1.debian.tar.xz
 2269c6255259507ab601361579599a5d7f6b7882aaaff8b450a0b1f6a7638079 6616 
gtextfsm_1.1.0-1_amd64.buildinfo
 f577f7e25952ac7aa13dc9a806980a55b66a5702e1b2de5d6a7d9b39e2515fd8 28108 
python3-textfsm_1.1.0-1_all.deb
Files:
 13b996aee506c81f4f249656f2a0958c 2045 python optional gtextfsm_1.1.0-1.dsc
 c3f8a1b0615e10c27fd63df5abf0f6e1 51104 python optional 
gtextfsm_1.1.0.orig.tar.gz
 618ec0575d7a16715ca4f37a9ac911e7 2008 python optional 
gtextfsm_1.1.0-1.debian.tar.xz
 abef09c22425efe2f6d70e9805a25fdf 6616 python optional 
gtextfsm_1.1.0-1_amd64.buildinfo
 ee0740609498fa83f5286fd932fc8970 28108 python optional 
python3-textfsm_1.1.0-1_all.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl16K+wSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5X6AP/33bptHoxMFhPNM5xgeowM6dcQ0GHe1r
2Ztx8Z77VJJUcv6BaEP26OXZnVxHC79m0FUzeDi5LKjjhXjzrRNh/CEDuZpI6AmH
CNx/fqbLInELvaqC+AE9mXaJH08hpPu4gi4txFxtpEejwIgWs23SyGDrJnC4aip8
PMRiL+0C+t01KGZRhIwpTcILiROX9FlBXCc4ZH+ASUtS4ikmahV5pBIXs5S03+pJ
haHdr1gwKE8/JUOQk64qG+Mb4ix5HJUoK2Gy/MweIGjJCeQ2iD4KSF2bgQhDAFHq
62PqgpYkE0w2H1knTyVIUwqrjwI5vAERZNHwKhuRLaQLLtqlW1odoFYMPNip+lDq
/ph6BLSzK2KZZlBhRua0WXNa7qLFs3u1tfukvwqyDHLSOH/rkkkV2RJK1ApjiP4S
EfJdZU9J0eg2K3E3wOcZ3qmafn45j+a48wldB1zqC6weh3FBWF0hGT5lFpch2yf+
oukwKP+tT4uu8HvNN/d1AKyeYGnjL+jWo5NEye8ESdDPkRtvUmW5nSt/cX10a3TT
cflFc1RYRBAYm7+pbcIv/9J7ArQ3NhHfiky4gbhdjMq/85R97SJ4n+3qKmZ4adH6
W20SDUBj4d/gqmgjUb8rR8vjApgfmBycPedNCrSC02XBOhUjCiEwK3UtNWzcMQgs
d9pXjIn1rrvz
=f5Al
-END PGP SIGNATURE-

Bug#939936: ITP: xtl -- basic tools (containers, algorithms) used for xtensor and xeus

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: xtl
  Version : 0.6.5
  Upstream Author : QuantStack
* URL : https://github.com/QuantStack/xtl
* License : BSD
  Programming Lang: C++
  Description : basic tools (containers, algorithms) used for xtensor and 
xeus

This package contains additional containers and tools missing from STL
C++14.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl13dsISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX50i0P/2hQdi8/hP/3VkEOEd5IHmOg3qzADUcY
FxoRxQ0jnL8Ula0QjCRiCU/aQKD7aQKVlNKeAW1++Trq5UILwG/Q7vLWVJk/7j6C
x8bRusrRMd3txIn8q+XAiFdoaEiZgvmcy+kNd88S92ANBnpDFO95Xcqc7o6eZfXz
HFPvmeN3EpgzJGNp3SjqNyR7/yl3+7tCobx98smfRJVKRODWHdNcMk0kKqoQVH2U
JAjc7FhF+AJtV4z4cGXoQA4XPCiZJtKNa6y+YRQvgw9XXUd4TUMkvExK5Eryidid
N5ad+/hDF7syN/wP4mbQ5iS0Mq1BAfmKU8srDtIFQtFbSeiw12kMAfNOHdxEfXrx
+3lahGCCcXpQLrz+KuCMp1V3jQBFqBO3GjIHHHADKNIOmGGKtJzmF37OZknlVlO9
vlQ8G9PyXTgIK919tFxi62KyVEoucpgLuhaj/tYo/lQ714sI6yTKOGqlvMm4uLnt
6AC5ZVSoLOZeC8xnfchR/GAewhjvCeODFeHLQ840s1aYLI4gbleCtb1kvfP71Z1e
/szgk4HjJ1VwV9CnhybTBXsYc+AzvcxST+cqUeldGTN74dAsNIGqkHsJd4XqIGw+
E1sTsg7SlfQhVR2NzoXLU8hBoxIzf3LIbNOyeDWfIxx1MObOgtPitiTTp82wv0Ob
h0ohhmsQKSSq
=+wJw
-END PGP SIGNATURE-

Accepted jinja2-time 0.2.0-2 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 02 Sep 2019 14:46:08 +0200
Source: jinja2-time
Architecture: source
Version: 0.2.0-2
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Changes:
 jinja2-time (0.2.0-2) unstable; urgency=medium
 .
   [ Ondřej Nový ]
   * d/control: Set Vcs-* to salsa.debian.org
   * d/copyright: Use https protocol in Format field
   * Convert git repository from git-dpm to gbp layout
   * Use debhelper-compat instead of debian/compat.
 .
   [ Vincent Bernat ]
   * d/control: remove Python 2 support.
Checksums-Sha1:
 1aad5ac3bba098a2608151548a1bc40660f7f1f5 2117 jinja2-time_0.2.0-2.dsc
 221bfa647b3da79004bd67cd5df40b419c00807a 2132 jinja2-time_0.2.0-2.debian.tar.xz
 aecb5e82ae31fa930e95c557357fc576948dc855 6799 
jinja2-time_0.2.0-2_amd64.buildinfo
Checksums-Sha256:
 03a63dec13d738d4c867bd4b8e32074c90f039b0dcb96d424aabd2e22ffc5ebf 2117 
jinja2-time_0.2.0-2.dsc
 3d78b06845443caff005edbe5d90826cc6c5239cabb4b55e2d0f84b015d734f6 2132 
jinja2-time_0.2.0-2.debian.tar.xz
 eab64a664a2e958d91e7605da32c7acca15e41e05993a28d3b15630778830ae4 6799 
jinja2-time_0.2.0-2_amd64.buildinfo
Files:
 cf83f2fa732e1aeae8d030f05563796e 2117 python optional jinja2-time_0.2.0-2.dsc
 2247037d87a58a16cf08d99628e4d041 2132 python optional 
jinja2-time_0.2.0-2.debian.tar.xz
 136e68fbb98963ece596549fddfa3988 6799 python optional 
jinja2-time_0.2.0-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl1tEB4SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5jR8P/3mq5FgYd4vi6DESRm0QrN7+t+91H40c
X5s74f62/oVtQRm/U5X8huvPJB9myOX/eOh7zKmSoCj6xK5NSUb8R8XVQ6VV9+2z
H2MYCbrlcsvbOnzGJqa7MXseJsdge7hURXq0dReCFpW4vx1ekz+XRTfniK658xEL
TOJNmksKakhRPbGDnus6Zm2ZMru1RKTWmIoWty+DmuWZLB5D2h9jGM9HTfE1QBgg
TrmbP/M5fNUjGMwW6T2QB2vq5TJTTKu1EbeuqsLjzA7sAvlPeCvazGsBqZpepOBe
F3nWm+KKEvMBDj0cuXwDR9F0K8knA4v3PR+8emIKTYFInf/daJm4BkyLCsy/Rjdx
x5h8hTVjpSmOx4JWT6Of6b8JlbRIYVpYZWcwZKB6XywnBOY7HbM0+xhBJeZRLTWS
jBPMLHABpc5xuBy16tlSJ9sRee/6snhc5pHQuq07vTjUmFKQIQALwZEf4Jy1dWDA
hYwbkV/N6IvlWMfVdGb9ujEd4KjtuzZ+1ZSkx+T5+CJr/rMQ32uC0S4rDhDPbnlR
+3TzhLp89u8cj62Osos5+PFeFUbkkYaZWaYhmVZmdJkZrII3vT0zD8hI1XieVAg7
/FstCnQ5bChujixcPz6VvU3x1JHLm6tjmLYuxtxmAhjxmY3qD0STYUD2ZKcjJLWW
Tf6CQyKq4DdJ
=Zl/5
-END PGP SIGNATURE-

Accepted cookiecutter 1.6.0-4 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 01 Sep 2019 17:01:10 +0200
Source: cookiecutter
Architecture: source
Version: 1.6.0-4
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Closes: 936334
Changes:
 cookiecutter (1.6.0-4) unstable; urgency=medium
 .
   [ Ondřej Nový ]
   * Use debhelper-compat instead of debian/compat.
 .
   [ Vincent Bernat ]
   * d/control: drop Python 2 package. Closes: #936334.
   * d/patches: add a patch to make tests work with only python3 installed.
Checksums-Sha1:
 1834ddface1fafe053288b573a1b20303cf9be3c 2504 cookiecutter_1.6.0-4.dsc
 2d223d61b49437e1c07056951bb46170633baa64 6932 
cookiecutter_1.6.0-4.debian.tar.xz
 371e643a32a02d576082e6a732aa9ae9396b69f6 10062 
cookiecutter_1.6.0-4_amd64.buildinfo
Checksums-Sha256:
 da82a50e35d84725b8e900e59a431b10503a3b6a7dcc48b7bcdfeb95f72ec427 2504 
cookiecutter_1.6.0-4.dsc
 255b32b3ed0249386ca315736942655c512045ce8dfff3a2c2bf73bbf3996959 6932 
cookiecutter_1.6.0-4.debian.tar.xz
 7101821c85ab3372c87f8440617b4b334f350b1d904872220b33472b3099a941 10062 
cookiecutter_1.6.0-4_amd64.buildinfo
Files:
 fb3702ecca99e7fdabc3822b2ccadd5a 2504 python optional cookiecutter_1.6.0-4.dsc
 f9d52df3b36951abb0e7961d15ee5a85 6932 python optional 
cookiecutter_1.6.0-4.debian.tar.xz
 944a7e47c0b81efb40a03297e4378ba5 10062 python optional 
cookiecutter_1.6.0-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl1r4CESHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5/G4P/ApbDIAiJV7ide2aCpwwXU/9XeU0pzFm
NulcimtLwLqeamrJbx8cnJv9q9Du5SQdqvAZlretZY1j4Da42EFVx3BBQ6hHCWHA
11xkYl169iSnkcNcQrO5DSUeIWudf8LJRnmw5P/7L9PSaqZOB+dWYk859byYvyEf
Vf02BrM+SpEKGykpH1QfmlzFCrnTok7kF7sfTHlefx3GsWb/9wePM2+mrJa3+jiH
+CN2qv6c5mjuCntvj7osx9vPx3tATaNOFnCK9uar12d8Mpfi84ofgUR54JiZwWrj
hQvt4fC0pJHt49VDE+nvv9ss6fGy+TdwFrRo5R5z8jWZf+OwTwsMUMADlYaEvYyN
fFM9CA5LUKesiFt+VzlQKmo0i1wRBFo/ZmhvIYlyYxerSmNJvB3fTwe1zLGkGXYJ
4elF63mjxKbZgai8hl58ptfsijZQrf/5juKL2hBn/yjEJua2IXQhHFqYdxJeCKic
LnXmCQLihmMORojlzUPp0YcyJgKWkPOOB7IU2RphBg7r7/Pd+sKy91WtXqx5ADHg
IXs3IglZPuEhi/gQZsLwi4++jurWVfWRW0fL3ZlBb2JZukCSGvlLzd1GIF2D+BWx
BMMwBTB9ahhyGHOoZLu+pW2Lq1wAoF1A5BB4YdBd4BrgX1uK4LW6lSFZ/sVay+vL
8CFBQBh9CEg4
=mOmM
-END PGP SIGNATURE-

Accepted snimpy 0.8.13-2 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 31 Aug 2019 07:22:33 +0200
Source: snimpy
Architecture: source
Version: 0.8.13-2
Distribution: unstable
Urgency: medium
Maintainer: Vincent Bernat 
Changed-By: Vincent Bernat 
Closes: 938508
Changes:
 snimpy (0.8.13-2) unstable; urgency=medium
 .
   * d/control: drop Python 2 support. Closes: #938508.
   * d/control: add back Vcs-* fields.
Checksums-Sha1:
 863ed546ba54ef7723b8ea6c1647ff63efd3ca3e 2116 snimpy_0.8.13-2.dsc
 43324a5317e1c0c26ef5f0cf7651926153843388 4256 snimpy_0.8.13-2.debian.tar.xz
 a21e1c9c481a70e995627aa026cdb55110a50ed4 8368 snimpy_0.8.13-2_amd64.buildinfo
Checksums-Sha256:
 8df94cb29457744ac087088e880922a03a9097ea7c900d378904e450346c2fbd 2116 
snimpy_0.8.13-2.dsc
 d30771b5e4afc51bfc985cd58298e3c457986d622b15ca8fcfc91c46f717f323 4256 
snimpy_0.8.13-2.debian.tar.xz
 2d9459231edce07047d0316adb4a4f42a063477912b37bc4fe5ec1bc25ed1416 8368 
snimpy_0.8.13-2_amd64.buildinfo
Files:
 63a57e75101ffd6d12de189e962fee26 2116 python optional snimpy_0.8.13-2.dsc
 85eac11ac36e407313be2048fab4ac15 4256 python optional 
snimpy_0.8.13-2.debian.tar.xz
 ea6fd7e18e9837b4f471570fa3051670 8368 python optional 
snimpy_0.8.13-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl1qB8YSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5100P/1fDpH3RFYGE7qm+nA8OtBwoXLxn1XAh
zpjN5CVQ6SQUhw7Wn7uCpLjPcylCu6v8MKnL9O//2b/grZoV/QqjgkKASy+cIzVH
KEKoe+wf0Q90IPuueCtap+UadlyOLOMZWBx+T5SZu97kZBgtAk44nR6EGIZmXnf1
g6UwWXNNqXjg5Y0qEjOhJMVXR1Oc93IY0/+ntc+2k8bVKrdyLvMSZgE7hyBBWXqv
0pfVkLXGeQSGvadX1auBJ8S0HQzXMQdvChxfcNxHAIUW88xL6CbvRnimCYHENFIL
Ye5gacnCGi9+7HJoV2LoazEPYB6/PXYs3wmcpmdSh2mhONTp+UNfI6V7TsI6lrvd
fYZ5E7n7VAfOLdmvuk0HUCWZL3djtpXLaSpJFKwo+In8bQkK2BVgOsldCeYlVINi
4keP3nMI0T+7vLJy75Pv1++Ut7GuixGCF6DL4fewKRbClTa1fN8b++//jDPGYnRn
EkhUVjU7aUZvU61u7TZhTtR7Ea8bl6D+SxuyLbiExO0b6tOa8W0slfOij8f6y03h
peuLR61ucVt00xwtpkYK6vSZam2evDE8sMzhyN22h84vHxAP/VS2sHl8x98uN+M0
7Zx+T55jVUTMnQH6a46YeRqQY0ITshYm1fqFYayZvy8B5lczL/TCs8o+UZBTvAsV
CAr/qSoiLtK6
=KyF0
-END PGP SIGNATURE-

Accepted haproxy 2.0.5-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 16 Aug 2019 19:51:24 +0200
Source: haproxy
Architecture: source
Version: 2.0.5-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Changes:
 haproxy (2.0.5-1) unstable; urgency=medium
 .
   * New upstream release.
 - BUG/MEDIUM: mux_h1: Don't bother subscribing in recv if we're not
   connected.
 - BUG/MEDIUM: mux_pt: Don't call unsubscribe if we did not subscribe.
 - BUG/MEDIUM: proxy: Don't forget the SF_HTX flag when upgrading
   TCP=>H1+HTX.
 - BUG/MEDIUM: proxy: Don't use cs_destroy() when freeing the
   conn_stream.
 - BUG/MEDIUM: stick-table: Wrong stick-table backends parsing.
Checksums-Sha1:
 ea2a0d382e81774938c06f9f952fc81f50a6a966 2295 haproxy_2.0.5-1.dsc
 4843adc37ffcc0bd618bce13a194501e13258403 2539226 haproxy_2.0.5.orig.tar.gz
 e92723140593fcfee5aee45983c1d9df702ae2c8 68012 haproxy_2.0.5-1.debian.tar.xz
 66945dcf3edf5a42c802ad7e47c3d165ba5d 8703 haproxy_2.0.5-1_amd64.buildinfo
Checksums-Sha256:
 5a11803c89ef395d762e8b829dead7f296683507117dd4d787e460d55533cf65 2295 
haproxy_2.0.5-1.dsc
 3f2e0d40af66dd6df1dc2f6055d3de106ba62836d77b4c2e497a82a4bdbc5422 2539226 
haproxy_2.0.5.orig.tar.gz
 f44761e902c41b510baa7a78ee739d06d21e7fe06df6f0787d7af259243b03cf 68012 
haproxy_2.0.5-1.debian.tar.xz
 4463ddb03f042c2acc1206494cf98c3b3d8541a9a794dfd3b822b3e19d7a 8703 
haproxy_2.0.5-1_amd64.buildinfo
Files:
 2563100167e218516746b8b31a598327 2295 net optional haproxy_2.0.5-1.dsc
 497c716adf4b056484601a887f34d152 2539226 net optional haproxy_2.0.5.orig.tar.gz
 88ab70b5108ca81a578228a709839f04 68012 net optional 
haproxy_2.0.5-1.debian.tar.xz
 5dfce8d6822d48d306d336c0f2ee464c 8703 net optional 
haproxy_2.0.5-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl1W7icSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX52egP/iPNrg5t3+qDJAPQUOpyquwd3pK8X+uB
C0Hp5asRgfrK/arwC3cSGxsiW2RQoAPzZI4Fv6xvzBzaOCSe0Bhbqlmi64vFfYJI
NKz6jMgZWK3zC8i52+wOZ5xqCEkZBIeYHmL1w58D2C5wn1MVBq3S+tfdQJ5tjhfW
HHDDtw28WWscfeE+OzbXXudnsXxlMKDljgEYPI03biCu5tLfJl57n1sFCjlWZv4M
p5B7P4VU7VmjFYHJOcVddbKpHZrqQawp7H4K4AlgdhU7GjqhUNiAqbDPKtFJUd3U
9wBbFkzge9bm65Yz5MBnD6aqZ7Sf2CLimoE5tSAEBtoF25vaK8WrQW7oe/NxS6WA
kjUr5eZ28UHTi7Fa/8DdgG6q3lOVhKirkJATMXvzEVbsSohV0yid/4o4sfPXJ+dy
b8iE2Bidnyk345lycB3E0i+6tMCclilbR+TfhGSmZdRnJOux4bo3o/kGuoxOZg/G
vFTiSaQew7K8C5jbkldc+HSyxFqod8SYxYUM/7z/0S8Q+xbeI/AfFU51MKjqhFZf
G+9g3KgME31CeLA6o7APDXQvovdPsS6y8V57bznyUVxgHkBs6LYLrxiNSP8LmeGP
gMjrZyCpXfpMw64LoWTnwFsak7zUkYbDS5DPKc2R4szbORKK/L0M+FOn2Ofy+/w+
H7D0hFzJ41Ek
=n54m
-END PGP SIGNATURE-

Re: Git Packaging Round 1: Hopefully Easy Stuff

[Vincent Bernat]

 ❦ 14 août 2019 22:32 +00, Holger Levsen :

>> I systematically turn off Gitlab MR support for projects I am involved 
>> in, because I am not confortable and efficient using it myself, it is 
>
> what helps me is having a note with this line:
>
> git config alias.mr '!sh -c "git fetch $1
> merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2" -'

If you prefer, you can avoid to create a local branch with:

git fetch $1 merge-requests/$2/head && git checkout FETCH_HEAD
-- 
"... all the modern inconveniences ..."
-- Mark Twain


signature.asc
Description: PGP signature

Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)

[Vincent Bernat]

 ❦ 15 août 2019 14:11 +02, Simon Richter :

> So we might have to invent magic comments still and/or convinve systemd
> people that it might be a good idea to have unit files that can support
> both immediate and on-demand start.

It's already the case. Require the socket for on-demand start, require
the service for immediate start.
-- 
I do desire we may be better strangers.
-- William Shakespeare, "As You Like It"


signature.asc
Description: PGP signature

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Vincent Bernat]

 ❦ 11 août 2019 10:27 +02, Marc Haber :

>>* Better restart semantics and monitoring of services/ways to configure
>>  restart.
>
> We have, however, failed to make use of that. "systemctl restart" is
> nearly useless in Debian because a non-negligible part of our daemon
> packages make systemd think the daemon is running while it is actually
> not, and systemd does for some reason not to anything in this case.
>
> I have watched myself involuntarily changing to a systemctl stop;
> systemctl start scheme, because this has a way higher chance of doing
> what I want. I haven't dug in deeply in this matter though.

systemd cannot guess if a SysV init script should leave a daemon behind
or not. Therefore, they are converted as "Type=forking", "Restart=no"
"GuessMainPID=no" and "RemainAfterExit=yes". So, when a daemon stops
unexpectedly, it is not restarted and "restart" doesn't work because the
unit is still active.
-- 
Tell the truth or trump--but get the trick.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Accepted haproxy 2.0.4-1 (source) into unstable

[Vincent Bernat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 09 Aug 2019 14:22:23 +0200
Source: haproxy
Architecture: source
Version: 2.0.4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HAProxy Maintainers 
Changed-By: Vincent Bernat 
Closes: 932763
Changes:
 haproxy (2.0.4-1) unstable; urgency=medium
 .
   * New upstream release. Upload to unstable.
 - BUG/MAJOR: http/sample: use a static buffer for raw -> htx
  conversion
 - BUG/MAJOR: queue/threads: avoid an AB/BA locking issue in
  process_srv_queue()
   * d/haproxy.cfg: update default cipher lists to more secure defaults.
 TLSv1.0 and TLSv1.1 are disabled, as well as TLS tickets (they are
 breaking forward secrecy unless correctly rotated).
 Closes: #932763.
Checksums-Sha1:
 127230ba559a1d8e882541829871415f99b42007 2295 haproxy_2.0.4-1.dsc
 164624c82e8fdfc7496b6185b19ac65a6e94376e 2538442 haproxy_2.0.4.orig.tar.gz
 1757a6165cacbedaaf194b3f93bb1fd07d78acea 67956 haproxy_2.0.4-1.debian.tar.xz
 ac5dd86aa67667688ada99c9f12f196ab32500d7 8532 haproxy_2.0.4-1_amd64.buildinfo
Checksums-Sha256:
 0f236c1614c18ed83af9e490079af60543e031e367eaff9e391c96a542975bb0 2295 
haproxy_2.0.4-1.dsc
 e2680696032c8b957cd26fd948fff239d2cfc17b00964e6d2dc5adf8155fcef1 2538442 
haproxy_2.0.4.orig.tar.gz
 ef14c211603703e3f4fdc590c9f18cf0551845689218675565f3a3acfa09 67956 
haproxy_2.0.4-1.debian.tar.xz
 c1c4497c58aaa2de9db751e3a896ef5a89a18b8b67369b4d400fe34a09bb2047 8532 
haproxy_2.0.4-1_amd64.buildinfo
Files:
 109707bfc55163a2b667a56bf2610a85 2295 net optional haproxy_2.0.4-1.dsc
 e0a295b3aa468f70ba261cc5ae9a5f83 2538442 net optional haproxy_2.0.4.orig.tar.gz
 bcf181225498132604b57f6c74c41137 67956 net optional 
haproxy_2.0.4-1.debian.tar.xz
 f57005284e946c0bfeb055a19fa6f015 8532 net optional 
haproxy_2.0.4-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl1NZykSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5xEcP/RKlOvHKeQWebtm45KKel8LDs34oJtvw
jN1GmqXDnX0oKDm5h9FieFO+CZAeG4ZZRUBT2iHdH2VxMZLK+JJyPa4OACvIOXpc
el0crsiMYyIiPQ3l0mmgJ67ikbHBnuo2mbuifNhA8aE8Wv6nwmpSr3UTWsi66eE4
+g01VUdGLUhoyKULf/025a2ghGYAOCqyD4gJv5QK4Z1ujfPZMHj9kxS+NTqsQnlJ
6CL2oF8hW4684sbeK5s7/YTR8Vsf4JZC7/CYFXZ22a54nI67FifCIk1PmVweh8OF
o96Ega+rYSX45uKPSsA8wPZLf+zW1idl/Whj61mZgkNTYDX+JmJuaBSDKLyVYQgv
OMMXSt7yazl2gvPmDMGp/PVP/wtN+s4Z9PSfXJkPtmTaP13t2Wm2Qo4sJsKnL/ic
wRNIVD8s2OfIgFMHPM2MFgCKIlL5avTfzZj3dNg8FAtdLrRqy3HbDNYAuXs6pudf
TChfqWeM1on10WfDS9TFyq60/nzjMz/uUKG2UvmZNAFHvIOCADCo/5TNL6HEpwxf
Qi9SC7mxHJDt2hi3QSmt1V7Kd0E6M7EdbFdh4O/iACx5eiOB0u731NPp7Iz17Ty8
ba9VDIuPr9W2AAgof9M5KeURgM5bzNBVbi8NsRBQdgpDfkuDChNCKRaYzbE17FGA
KOq2wwMiJgxb
=bEL/
-END PGP SIGNATURE-