Re: Validating tarballs against git repositories
On 2024-04-02 11:05, Russ Allbery wrote: Meson honestly sounds great, and I personally love the idea of using a build system whose language is a bit more like Python, since I use that language professionally anyway. (It would be nice if it *was* Python rather than yet another ad hoc language, but I also get why they may want to restrict it.) If Python is what you want, you could use waf, but there is one big downside... You have to repack the upstream tarball: https://wiki.debian.org/UnpackWaf -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Another take on package relationship substvars
On 2024-02-22 12:32, Niels Thykier wrote: I am omitting Breaks, Conflicts, and Replaces because I am not aware of any users of these at the moment. I am open to adding them, if there is a strong use-case. I think you should include them (and Enhances as Sam Hartman mentioned) for consistency. It seems potentially confusing if some of the relationships fields are included and some are not. This proposal sounds generally good. I'll have to defer to others who know more about potential corner cases. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Re: systmd-analyze security as a release goal
On 2023-07-03 14:21, RL wrote: Russell Coker writes: https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity I think we should make it a release goal to have as many daemons as possible running with systemd security features to aim for a low score from "systmd- analyze security". It would be great if we could get a lintian check for this. The wiki page says, "systemd-analyze now supports working offline" (i.e. it can operate on files in the filesystem rather than talking to systemd about only installed services). Lack of that was previously a blocker for such a lintian check. This repos from Trent Buck has a lot of research - https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES Indeed. -- Richard
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
I know I haven't thought about this as much as others, so I might be
naively missing something here.
Is the broader context here that this is an alternative to teaching dpkg
about aliasing? That is, we just arrange the transition correctly such
that we get out of the aliased situation as part of upgrading to trixie?
On 2023-06-09 13:47, Helmut Grohne wrote:
I caution that this protection mechanism of symlinks is a property of
the installation and not of dpkg. Depending on what dpkg is operating
on, we expect it to handle this or not. So we'd need a way to tell
whether an installation needs this kind of special handling.
Because you want to support non-usr-merged systems, e.g. for
derivatives? They aren't going to want to delete /bin either, so I don't
see how a special-case preventing deletion of /bin would be problematic.
On amd64, we'd upgrade libc6 before dpkg and then /lib64 would go
missing, because libc6 already is the last package that ships files in
/lib64.
Am I understanding the problem correctly?
1. src:libc "moves" /lib64/ld-linux-x86-64.so.2 to
/usr/lib64/ld-linux-x86-64.so.2, i.e. it builds bin:libc6:amd64 such
that it ships the latter path.
2. bin:libc6:amd64 gets upgraded before dpkg. The normal unpacking
behavior of dpkg results in /lib64/ld-linux-x86-64.so.2 being deleted
and since /lib64 is now empty, dpkg deletes /lib64.
3. Everything breaks, because /lib64/ld-linux-x86-64.so.2 is special in
the ELF ABI.
What would happen if, for trixie only, bin:libc6 shipped two identical
copies of ld-linux-x86-64.so.2, one in each of /lib64 and /usr/lib64?
Then at step 2, /lib64 does not get deleted and nothing breaks.
Later, whatever replaces /lib64 with a symlink needs to deal with this,
but that's not significantly different than whatever it was going to do
anyway, right? Just do this:
1. Whatever safety checks are appropriate.
2. Unless already verified to be identical by #1, hardlink
/lib64/ld-linux-x86-64.so.2 to /usr/lib64/ld-linux-x86-64.so.2. This
might be just a particular instance of the more general case of hardlink
everything from /lib64 into /usr/lib64.
3. Unlink everything from /lib64.
4. Unlink /lib64.
5. Symlink /lib64 to /usr/lib64
However, note that this cannot be a shell script, as then step 3 would
delete /lib64/ld-linux-x86-64.so.2 and everything after that would fail.
At that point, everything is fine, EXCEPT that dpkg now thinks it has a
/lib64/ld-linux-x86-64.so.2 file installed, but really that is aliasing
/usr/lib64/ld-linux-x86-64.so.2. When bin:lib6:amd64 is later upgraded
(e.g. in forky) to a version that stops shipping
/lib64/ld-linux-x86-64.so.2, dpkg will unlink
/lib64/ld-linux-x86-64.so.2 and then everything breaks.
The fix to that is either whatever separate general case fix is being
done for aliasing, or if the whole point is we are trying to avoid
having that sort of thing at all, then just put in a special case that
dpkg will not unlink /lib64/ld-linux-x86-64.so.2.
So we end up with something roughly like this in dpkg (please excuse
syntax/pointer errors):
Wherever file deletions are handled, make this change:
- unlink(pathname);
+ special_unlink(pathname);
to use this:
char *SPECIAL_PATHS[] = {
"/bin",
"/lib",
"/lib64",
"/lib64/ld-linux-x86-64.so.2",
"/sbin",
NULL,
}
void special_unlink(const char *pathname) {
const char **special;
for (special = SPECIAL_PATHS ; *special ; special++) {
if (strcmp(pathname, special) == 0) {
return;
}
}
unlink(pathname);
}
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On 2023-06-09 11:26, Helmut Grohne wrote: When upgrading (or removing that package), dpkg will attempt to remove /bin (which in its opinion is an empty directory and the last consumer is releasing it). However, since dpkg has no clue about file types, it doesn't actually know that this is a directory and takes care of the /bin -> /usr/bin symlink using unlink(). And this is where /bin vanishes. Oops. This might be a dumb question, but could we just special-case this? That is, dpkg would simply not remove /bin specifically? If the list of directories is small, known, and relatively fixed (e.g. /bin, /usr/bin, /lib), that might be workable. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
I support transitioning to 64-bit time_t. Thank you for taking this on! Gentoo has a similar migration: https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration They mention, "We likely have to complete Modern C porting first to remove any instances of -Wimplicit-function-declaration otherwise the redirects in glibc for e.g. time->time64 won't actually work." That links to: https://inbox.sourceware.org/libc-alpha/874js2iqlg@oldenburg.str.redhat.com/ Has that issue been considered here? (I can't speak intelligently on it at this time. I just want to make sure it's on your radar.) On 2023-05-16 23:04, Steve Langasek wrote: * For a small number of packages (~80) whose ABI is not sensitive to time_t but IS sensitive to LFS, along with their reverse-dependencies, filter out the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. Maintainers may choose to introduce an ABI transition for LFS, but as this is not required for time_t, we should not force it as part of*this* transition. My gut feeling is that this is a mistake. I think Debian should just bite the bullet and force the LFS transition too. First off, it seems that would simplify the planning, as you don't need to determine "[i]f there is a package that depends on both a time_t-sensitive library and an LFS-sensitive but time_t-insensitive library". Furthermore, that state could change in the future. In other words, someone could upload a new package that meets that criteria, which would then force a library to transition at that point. But would that requirement to transition get noticed, or would we end up with subtle breakage? Also, how many separate times would someone have to do those LFS transitions vs just doing it all now in one shot? I know it's not my place to volunteer you/others to do more work. But I worry about doing something half-way rather than just pulling the thread now. Doubly so since it's a relatively small set of additional packages compared to the size of the rest of the transition already being planned. Back to time_t... Application-level workarounds can complicate things... Upstream NTPsec and gpsd had some conversations about the optional 64-bit time_t. They (and other projects) can have a shared-memory connection where the size and layout of the struct varies depending on sizeof(time_t). The glibc optional 64-bit time_t makes that complicated, as it's possible for the two applications to be mismatched. The conclusion we came to (which has been implemented in gpsd, but has not yet been implemented in NTPsec) is to split the time_t and put the high bits into a spot that was reserved/padding, but only in the case where we have optional 64-bit time_t and 32-bit ints. This provides compatibility between modified and unmodified applications until 2038, and modified applications work together thereafter. If you're curious, the relevant subthread is: https://www.mail-archive.com/devel@ntpsec.org/msg09645.html With the Debian transition, we could end up with a mismatch where one side (gpsd) is sized with 32-bit fields and doing the split thing and the other (NTPsec) will be sized with 64-bit time_t, which is incompatible. Whether that happens is dependent on how exactly the applications implement the check to decide to do the split thing. I've raised that question on the gpsd bug: https://gitlab.com/gpsd/gpsd/-/issues/152#note_1395291465 There are certainly solutions to that. In no way am I suggesting that should block the transition. By all means, transition and we will sort things out. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Upgrade package from init script to Systemd, move config folder
On 4/20/23 14:48, Perry Naseck wrote: Hello! I am in the process of updating/upgrading a package from an init.d service to a Systemd service. Are there any recommended guidelines for this process? My generic advice would be: start your thinking from a perspective of "how should this work in systemd anew", not "how do I 1:1 convert the init.d unit". That is, start in a "systemd native" approach. You may need to pull back from that for backwards compatibility reasons, or consistency with the init.d unit or whatever (and I maintain a package that is that way), but make those decisions intentionally. Looking through some current packages I see that a lot of them have both an init script and a Systemd service in their debian folder. Do dh_installsystemd and dh_installinit handle this smoothly by default if both files exist? In my experience, if the files are name the same (i.e. /etc/init.d/foo and /lib/systemd/system/foo.service), everything should Just Work, both in terms of the Debian bits and the systemd bits (discussed below). When upgrading the package on a machine will it stop the init service and start the Systemd service? There is no such thing as an "init service" on a systemd machine. If you have only /etc/init.d/foo, systemd is dynamically generating a foo.service unit. You can see this with e.g. "systemctl status foo". For example, on my system: $ systemctl status openipmi × openipmi.service - LSB: OpenIPMI Driver init script Loaded: loaded (/etc/init.d/openipmi; generated) When you install a foo.service unit file, that will take precedence over the generated one. So (assuming they have the same name), they are the same service. This package also stores its configuration in /var/lib/packagename and it should really be in /etc/packagename. Where is the best place to deal with auto-migration? Should this go in postinst or is there a debhelper that I should use? Take this with a grain of salt, and defer to more knowledgeable folks, but... If I were in that situation, I'd start with the idea of moving it in a preinst script. I would probably also guard it with version checks (as opposed to only checks for the existence of the folder). So something like (where the "2" in version-2~ is the package version one _higher_ than the version where you made the change, i.e. if you changed in -1, use -2~): #!/bin/sh set -e if [ "$1" = "upgrade" ] && [ -n "$2" ] then if dpkg --compare-versions "$2" le-nl "version-2~" then if [ -e /var/lib/packagename ] && ! [ -e /etc/packagename ] then mv /var/lib/packagename /etc/packagename fi fi fi That said, I'm not sure what Policy has to say about this. It seems to me that you want the package to do things right moving forward, and you want to support clean upgrades, so this seems like the approach that gets both of those. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Yearless copyrights: what do people think?
I maintain a package where upstream has dropped the years. I was told that multiple big tech companies with serious lawyers looked at this and felt it was fine. I fully support: - upstreams dropping years from copyright notices - Debian not requiring maintainers to preserve years in debian/copyright files. On 2/22/23 08:39, Sam Hartman wrote: I think our users are better served by knowing when the Debian packaging would enter the public domain. In theory, I agree with you. In practice, copyright lengths are so long in many countries that software effectively never enters the public domain (at least not while it is still of useful/non-historical value). -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Enabling branch protection on amd64 and arm64
On 10/26/22 13:20, Moritz Mühlenhoff wrote: Wookey wrote: So the immediate issue now is whether or not to enable this by default in bookworm? The majority of packages will not be rebuilt until the release How hard would it be to rebuild everything? I don't actually know what facilities Debian has for that. Would it be a binNMU of everything? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: application tool
On 9/8/22 23:07, Qx wrote: 1)i have coded a tool which I would like to release for ubuntu. Can someone please advice as to how this is correctly done? You sent this to a Debian list. If you want to package the software for Debian (which will then flow downstream into Ubuntu), start with the Debian New Maintainer's Guide: https://www.debian.org/doc/manuals/maint-guide/ 2)I would like to become a motu member/contributor. That's a question for the Ubuntu folks. But, as some general suggestions, you will probably want to A) package software, and/or B) contribute fixes to existing packages. -- Richard
Re: Python installation paths
On 6/2/22 14:15, Alec Leamas wrote: Hi Audrey On 02/06/2022 20:16, Andrey Rahmatullin wrote: On Thu, Jun 02, 2022 at 07:19:56PM +0200, Alec Leamas wrote: Dear list, I try handle a package which installs a partly compiled, architecture-dependent python module. Until now this has been done in /usr/lib/triplet/python3.10/site-packages. This scheme has basically worked fine. However, here is an Ubuntu bug [1] where a user runs into problems because this installation path is not in sys.path by default. I have been trying to look in the python policy docs, but cannot find the exact way to install code like this, in the policy [2] parlance an "extension module". Not sure where is this documented but you can easily check on your system. It should be /usr/lib/python3/dist-packages/*.cpython-3*-x86_64-linux-gnu.so Hm...this is not what I have. Did I get get the term "Extension module" wrong? There are a couple different ways to do Python to C. I think the terms are CFFI (or FFI or ctypes, maybe some of those are different though?) vs CPython extension, but I'm not 100% certain of that. I maintain the ntpsec package. IIRC, upstream is transitioning (but I think still supports both at the moment). On an older version, I had this (from the python3-ntp binary package): /usr/lib/python3/dist-packages/ntp /usr/lib/python3/dist-packages/ntp/__init__.py (other .py files omitted) /usr/lib/python3/dist-packages/ntp/ntpc.cpython-38-x86_64-linux-gnu.so I believe that is the extension approach. I think the way this works is that if you import ntpc, it imports the .so. Note that there is no ntpc.py. On newer python3-ntp, using the FFI approach, I have this: /usr/lib/python3/dist-packages/ntp/__init__.py /usr/lib/python3/dist-packages/ntp/ntpc.py (other .py files omitted) /usr/lib/x86_64-linux-gnu/ntp/libntpc.so /usr/lib/x86_64-linux-gnu/ntp/libntpc.so.1 /usr/lib/x86_64-linux-gnu/ntp/libntpc.so.1.1.0 In this approach, ntpc.py has explicit code to load libntpc.so from /usr/lib/x86_64-linux-gnu/ntp/ (that path being subst'ed in to ntpc.py by the build process). I hope that helps. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Adding epoch to node-markdown-it to correct a wrong upstream version
On 5/19/22 05:42, Pirate Praveen wrote: So current version in the archive is 22.2.3+dfsg+~12.2.3-1 The fixed version we want is 10.0.0+dfsg+~cs16.6.17-1 I have no dog in this fight as they say, but... How fast does upstream bump versions? With a 10.x, I wonder if it might be relatively frequently. Would they likely exceed 22 in the near future? If so, you might just do 22.3+really10.0.0+dfsg+~cs16.6.17-1 and when they get to 23, it goes back to normal, without the epoch. -- Richard
Re: Advice for package needing stuff installed in /srv (node-shiny-server)
On 4/27/22 12:57, Nilesh Patra wrote: I am looking for more opinions. Patch every instance of /srv/shiny-server to /var/lib/shiny-server. The admin can customize from there. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
If you use ntp, I would appreciate if you could test the transition to ntpsec. ntpsec 1.2.1+dfsg1-5 has been uploaded to experimental and cleared the NEW queue. Bernhard Schmidt suggested and I used 1:4.2.8p15+dfsg-2~$(DEB_VERSION_UPSTREAM_REVISION) as the version for the transitional packages. The first part (before the ~) is the current src:ntp version, but with the Debian revision bumped from 1 to 2. This allows for potential security or stable fix uploads to existing Debian releases, if needed. Barring bugs, I believe the next steps are: 1. Upload to unstable. 2. Request ftpmaster removal of src:ntp? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: proposed MBF: packages still using source format 1.0
On 3/15/22 10:36, Ian Jackson wrote:
Lucas Nussbaum writes ("Re: proposed MBF: packages still using source format
1.0"):
As explained in https://lists.debian.org/debian-devel/2022/03/msg00165.html
I proceeded with the MBF for packages that match
not (debian_x or (vcs and vcs_status != 'ERROR' and direct_changes))
or, maybe easier to read:
(not debian_x) and ((not vcs) or vcs_status == 'ERROR' or (not direct_changes))
I did not file bugs for packages that are likely to use a VCS-based
workflow (category (2) in the mail pointed above, or in
https://udd.debian.org/cgi-bin/format10.cgi)
At least the following packages of which I am the maintainer or
sponsor were includined in the MBF, despite the fact that they are 1.0
native packages with Debian revision:
its-playback-time
spigot
vm
vtwm
chroma
I picked one of these, spigot, at random.
Clearly the it aakes no sense to have filed bugs saying "please switch
to this other source format" when the other source format cannot
represent the package.
I don't see any reason that 3.0 can't represent the spigot package. It
looks like a straightforward package. It seems to have an upstream:
The top changelog entry says "Merge from upstream".
debian/control points me to:
http://www.chiark.greenend.org.uk/~sgtatham/spigot/
That site has a tarball available. The Debian package is NOT using that
as its .orig.tar.gz. It doesn't have a .orig.tar.gz, presumably
indicating it was built built as a native package (even though it has a
Debian revision), which is the issue under discussion. To be honest, had
I stumbled across this package outside of this conversation, I would
have been confused by this.
My understanding is that Debian values the idea of using the pristine
upstream tarball. Granted, sometimes that goal has to yield to higher
priority things, like DFSG compliance.
How do you feel about the pristine tarball concept?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On 3/9/22 23:47, Marc Haber wrote: On Wed, 9 Mar 2022 14:35:52 -0600, Richard Laager wrote: If the admin can change the default DIR_MODE that applies to system user home directories, then any postinst script doing `adduser --system` needs to also explicitly chmod its home directory if it needs anything more permissive than 700 or more restrictive than 755. This is true today and remains true whether or not the default DIR_MODE is changed. Anything that NEEDS to be written in postinst scripts is bad. I'd rather implement a SYSTEM_DIR_MODE setting that applies to directories created during creation of a --system user. Would that help with the issue? Yes that would _help_, as that would allow the system administrator to change DIR_MODE without changing SYSTEM_DIR_MODE. However, if SYSTEM_DIR_MODE is configurable, you end up with the same problem: unless a given package can work with _any_ reasonable mode (700 to 755), it must explicitly set its own mode. Otherwise, if the administrator sets SYSTEM_DIR_MODE to something too restrictive (scenario A below), some packages will break; if they set it too permissive, some packages will become insecure (scenario B). Having a hardcoded default for system users would at least allow packages certainty, and those that were happy with the default would not need to chmod. Further, my assumption is that there are two different scenarios: A) The system user's home directory needs to be open. For example, if there is a socket in there that needs to be world-writable, which I think you were talking about. B) The system user's home directory needs to be private. For example, there is sensitive data in there. (Another, perhaps better, answer is that the _files_ should have restricted permissions.) _If_ it is the case that both of these scenarios exist, then no single value (default or hardcoded) can satisfy both. So the default should either be the most common mode, or the most restrictive (reasonable) mode. This should probably be my last email on this subtopic. Hopefully I've conveyed my points for your consideration. I don't feel that I'm an expert on the use of system users in Debian. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On 3/9/22 14:00, Marc Haber wrote:
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager
wrote:
On 3/8/22 10:49, Marc Haber wrote:
(1a) would it be necessary to handle --system accounts differently? I
think yes. > (1b) should we stay with 0755 for --system accounts?
I don't see why system accounts need to be different.
avahi-daemon has /var/run/avahi-daemon as its home directory and
places its socket there. I'd guess that having this directory not
accessible for the world will kind of influence the usability of the
daemon. We have many packages that are configured like that.
dnsmask even has /var/lib/misc as home, which is not even owned by the
account, so setting that one to 0750 would probably be even more
destructive.
Having thought about this some more:
If the admin can change the default DIR_MODE that applies to system user
home directories, then any postinst script doing `adduser --system`
needs to also explicitly chmod its home directory if it needs anything
more permissive than 700 or more restrictive than 755. This is true
today and remains true whether or not the default DIR_MODE is changed.
How would chown handle the dot case intelligently?
Something along the lines of see if the user exists.
If I was to take a stab at an implementation (Python-ish pseudocode
here; yes I know chown is C):
group = None
if ':' in arg:
(user, group) = arg.split(':')
elif '.' in arg:
# This could be:
# user.group
# us.er.group
# user.gr.oup
# us.er.gr.oup
# Or user and/or group could have multiple dots.
# Idea A) Exactly one dot can mean either user.group or us.er
arg_split = arg.split(',', 2)
if len(arg_split) == 3:
# There was more than one dot.
user = arg
else:
# Split on dot.
(user, group) = arg.split('.')
if not getent(user):
# Treat the whole thing as a username.
user = arg
group = None
# Idea B) Loop over each possible split and see if any work.
# Exercise for reader.
else:
user = arg
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: proposed MBF: packages still using source format 1.0
On 3/9/22 10:38, Ian Jackson wrote: This prohibition exists solely because of a doctrinal objection to native-format packages with Debian revisions. As I understood it, the idea was that you could just increment the "actual" version number. I'm failing to see the advantage of incrementing "a" vs "z" in something like x.y.z-a. There's not really a disadvantage either, if it all works (which you said it does). But the doctrinal issue, I think, is that definitionally a native package has no Debian revision (corollary: a package with a Debian revision is non-native). If we revise that definition, to allow Debian revisions in native packages, then what distinction is left between native and non-native packages? Could we only have "3.0 (quilt)" then, no "3.0 (native)"? Or, put differently, if you had a "native" package that is using a Debian revision and we allow that, what difference is left between "3.0 (native)" and "3.0 (quilt)"? To be clear: I genuinely don't know. I'm not implying that there isn't a remaining difference. IMO there is nothing wrong with native format packages with Debian revisions. They work just fine. For a small paockage, this is often a good choice, because it avoids dealing with patches at all. I don't follow the "avoid dealing with patches at all" piece here. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On 3/8/22 10:49, Marc Haber wrote: (1) #202943, #202944, #398793, #442627, #782001 The bug reporters are requesting the default for DIR_MODE to be changed from 0755 to 0700, making home directories readable for the user only. Policy 10.9 states that directories should be 0755, but the policy editors probably didn't have user home directories in mind when they wrote that. As a data point, Ubuntu moved to 750 a year ago: https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04 At my day job, we then followed that across the board (despite not yet being on an Ubuntu release where the change was made), and it was essentially fine. We already considered home directories on our file server to be "private", and on everything else, there are only accounts for admins (who can use sudo in the rare event they need a file from someone else's home directory). (1a) would it be necessary to handle --system accounts differently? I think yes. > (1b) should we stay with 0755 for --system accounts? I don't see why system accounts need to be different. (1c) does a change to 0700 for user accounts make sense? Yes. (1d) should it be 0751 (#398793)? Pro: That helps ~/public_html. Con: That seems like a trap for non-expert users. It _feels_ like other people can't get at things, but they actually can, if they know the next directory down. I (and probably everyone reading this list) understands the "1" in 751, but do end users? (1e) how about ~/public_html that would break with 0750? As a comment on the bug mentioned, public_html not a default thing. Changing DIR_MODE and/or ACLs are also options for those who want a ~/public_html concept. All those bugs referenced have more or less heated exchanges ranging from "it's fine" to "we should issue a DSA ASAP", most of them a decade old, so the times might have changed since then. Please note that the DIR_MODE _IS_ configurable in adduser, we're just discussing the default (which also applies for home directories created while still inside the Installer before a local admin can properly configure adduser). I think there is merit to defaulting to the most secure (but still reasonable) option, and letting people loosen it if desired. (2) #774046 #520037 Which special characters should we allow for account names? People demand being able to use a dot (which might break scripts using chown) and non-ASCII national characters in account names. The regex used to verify non-system accounts is configurable, so the policy can be locally relaxed at run-time. For system-accounts, I'd like to stick to ASCII letters, numbers, underscores. I support dashes, as was already discussed. That's already in use. I think the idea of dot in a username is perfectly reasonable on its own. For some people this is very desirable. My wife, for example, uses a dot in her email username as her first name plus my-now-her last initial makes a word that is awkward. (This sort of problem is not uncommon in usernames, especially at companies that make them via some algorithm.) I always use colon for chown, which is what is documented, but I'm aware it takes dot too. Is there any code in chown to handle the dot case intelligently? Non-ASCII does feel a little concerning to me (since those code paths won't be exercised very often). But to recognize my bias, I have no need for a non-ASCII username. I'd probably feel quite differently if my name wasn't correctly representable in ASCII. Put differently, if usernames were currently required to be Han or Cyrillic characters, I'd certainly be up in arms asking for Latin character support. On the other hand, Debian probably can't go it alone here. If, as people have mentioned, systemd isn't going to support those usernames, there's not much point in adduser allowing them. (3) #625758 --disabled-password just does not set a password for the newly created account (resulting in '*' in shadow) while --disabled-login places a '!' in shadow. On modern systems with PAM, both variants seem to be identical, allowing login via ssh. Aside from the documentation needing change to document reality Simon McVittie's explanation matches my understanding of what the current behaviors of '*' and '!' are (but I haven't tested the empty password nuance). While I get the general idea of locking in a way that allows unlocking later (and keeping the original password hash), I don't see --disabled-login as being particularly useful for adduser, since it leads to an identical result as --disabled-password. should we introduce a --no-set-password option and deprecate the two older options (to be removed in trixie+2)? I wouldn't add another option. I think --disabled-password is fine. Just keeping that reduces the amount of change people need to make. I'd probably just document --disabled-login as being deprecated and functionally equilvalent to --disabled-password. (4) #979385 #248130 The default
Re: The future of src:ntp
On 1/19/22 15:04, Bernhard Schmidt wrote: On 19.01.22 20:34, Richard Laager wrote: 2. I create transitional binary packages in src:ntpsec: I got to thinking about this more. This won't work, because src:ntp is 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's transitional bin:ntp package to be newer than src:ntp's bin:ntp package. It might be technically possible to build a binary package with different versioning, but even if it is: 1) I don't know how, and 2) I'm not sure whether that's a good idea, especially compared to the alternatives. What do you think about the other approach of having src:ntp build the transitional packages? I think that looks like this: 1. I split out ntpdig, as suggested in #1003966. This is presumably ntpsec-ntpdig for consistency with the rest being ntpsec-*. 2. You (or I adopt and) create transitional binary packages in src:ntp, as 1:4.2.8p15+dfsg-2, 1:4.2.8p15+fake, 1:4.2.8p15+transitional, 1:4.2.8p16~transitional, or something else > 1:4.2.8p15+dfsg-1, with an empty upstream tarball: ntp -> ntpsec ntp-doc -> ntpsec-doc ntpdate -> ntpsec-ntpdate sntp -> ntpsec-ntpdig with an sntp -> ntpdig symlink 3. Upload that to experimental. People review. 4. Upload to unstable. 5. After bookworm releases, you (or I, if I adopted src:ntp) request removal of src:ntp. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: using epoch to repair versioning of byacc package
On 1/23/22 10:04, Thomas Dickey wrote: In #1003769, Andreas Metzler wrote: 1. The upload introduces an epoch because the upstream version went from mmdd to 2.0.mmdd. Given that the new version scheme seems to have found acceptance in e.g. Fedora /I/ do not see a better way. Could you ask about the epoch on debian-devel (as per policy https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly ) - TIA. As background, byacc was packaged by Dave Becket in 2005, switching to my ftp area as upstream. In doing that, the versioning of the package changed: from -- LaMont Jones Fri, 26 Nov 2004 18:49:09 -0700 byacc (1.9.1-1) unstable; urgency=low to -- Dave Beckett Sun, 14 Aug 2005 10:14:12 +0100 byacc (20050505-1) unstable; urgency=low I see no other way to correct this but to add an epoch. As we see in this case, switching from version numbers to date-based versions is dangerous because it's impossible to go back without an epoch. A better version would have been something like 1.9.1+20050505. Lintian flags on this, but (according to the name and description) only for new packages: https://lintian.debian.org/tags/new-package-uses-date-based-version-number Personally, I'd like to see that lintian check fire if the date-based versioning is new. That is, it should fire if the previous changelog entry did not have a date-based version. Even better would be a dak (or whatever ftp-master tool is relevant) hard fail if going from non-date-based to date-based at the front of the version string. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
On 1/20/22 8:04 AM, Thomas Goirand wrote:
On 1/19/22 20:34, Richard Laager wrote:
For people that want something more than systemd-timesyncd, e.g. to
get NTS, I think either are acceptable choices. It seems that the
consensus for new installs is towards chrony over ntpsec. But I don't
think we as the distro need to push either over systemd-timesyncd. For
people who don't care, systemd-timesyncd should be fine.
Do you disagree on that point (that systemd-timesyncd is fine for
people who don't care about NTP)? If so, can you elaborate?
Well, could you elaborate why you didn't write "chrony is fine for
people who don't care"?
Because that question is about changing the status quo, where
systemd-timesyncd is the default.
I fail to understand why you're having a
preference on systemd-timesyncd...
Let me separate the two scenarios:
A) Imagine we had no NTP support by default and we are considering
adding NTP support to the default install.
B) systemd-timesyncd is currently the default and we are discussing
whether it should be changed.
In both scenarios, I assume that most users don't particularly care
about their NTP daemon. They don't generally interact with it. They just
want their clock to be "accurate enough". (And for people who don't
care, "accurate enough" is pretty wide. If you need extremely precise
time, you presumably know that and thus care about things like NTP or
even PTP.) This is no different than other system components: some
people have preferences (sometimes strong ones) about certain
components, but essentially nobody cares about every single one.
In scenario A, any of chrony, ntp, ntpsec, or systemd-timesyncd will
achieve the desired objective of having an accurate enough clock by
default. So we would consider other things, for example:
One might say ntpsec > ntp, because ntpsec comes from the same history
(so has the same advantages) plus the codebase has been cleaned up
(which has security and maintainability advantages). Also, the ntp
maintainer wants to discontinue maintaining it.
One might say that chrony > {ntp, ntpsec, systemd-timesyncd?} because
chrony is more accurate. FWIW, I can't personally weigh in on that
argument, as I haven't researched it well enough myself.
One might say that systemd-timesyncd > {chrony, ntp, ntpsec} because
it's part of systemd, which we're already using by default.
One might say that {chrony, ntpsec} > systemd-timesyncd because they
support NTS. Of course, there are problems with configuring NTS by
default, as I mentioned.
These, and potentially other factors, would need to be weighed.
Different individuals might come to different conclusions.
In scenario B, it's the same calculation, PLUS we need to overcome the
inertia of the current default. The new default must be sufficiently
better to be worth the change.
Personally, my take is:
It's not practical to deploy NTS by default right now. If we had
multiple operators of geo-diverse, high-capacity, non-smeared (or
consistently smeared and a consensus that this was desirable by default)
NTS servers, that'd be different. So NTS is not currently a
consideration for the default.
systemd-timesyncd is good enough for people who don't particular care
about their NTP daemon. For people that do care, they are free to
install software of their choice, be that chrony or ntpsec.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: The future of src:ntp
On 1/19/22 3:13 PM, Bernhard Schmidt wrote: I agree we should have a look at this (either ntpsec or chrony, both do NTS), but I think this should be done completely independently of the ntp.org->ntpsec migration. +1 that promoting NTS is orthogonal. If the bigger problems below are solved, it's also theoretically possible to add NTS support to systemd-timesyncd. - AFAIK there is no pool.ntp.org (or similar) service only containing NTS enabled timesources yet. This is the most serious problem. As the world stands right now, we'd have to do something like use CloudFlare's NTS service (and only them). I don't know how it would work either, since you need to verify the peer with a standard X.509 certificate and you don't know the expected CN from a DNS RR NTS does referrals, so it is theoretically possible for the NTS server to hand you off to a pool of NTP servers, with which it is coordinating keys. AFAIK, nobody has implemented this yet, outside of maybe CloudFlare's internal thing (but I don't recall off the top of my head). - Since NTS leverages X.509, how does it work with a broken clock on boot that is ticking outside of the certificate validity period? This is a concern too. I did some brainstorming about this on the NTPsec list a couple years ago, but neither I nor anybody else has implemented this (nor do I have plans to do so myself): https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
On 1/19/22 9:49 AM, Bernhard Schmidt wrote: AFAICT other than systemd-timesyncd being installed by default we don't have a "default" NTP daemon in Debian. I'm not sure how much more "default" it can be than installed by default. So I'd say we do have a default: systemd-timesyncd. So we should most probably decide on a "default" and have all of them changed to $newdefault | time-daemon +1, except that my position is we already have that answer: systemd-timesyncd | time-daemon As default both ntpsec and chrony are challengers. For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus for new installs is towards chrony over ntpsec. But I don't think we as the distro need to push either over systemd-timesyncd. For people who don't care, systemd-timesyncd should be fine. Do you disagree on that point (that systemd-timesyncd is fine for people who don't care about NTP)? If so, can you elaborate? And then there is the migration from src:ntp. I think only ntpsec would be an option here Agreed (as I stated already; just agreeing here again). sntp could depend on on the ntpdig package from #1003966, but it would probably need to carry a compatibility symlink Good point. ntpdate and ntp could be transitional packages on the ntpsec counterparts as well, but since ntpsec/ntpsec-ntpdate has Conflicts/Replaces on the src:ntp binary packages it needs coordination. For this reason building the transitional binaries from src:ntpsec would probably be easier. Sure. How do we feel about this process then: 1. I split out ntpdig, as suggested in #1003966. This is presumably ntpsec-ntpdig for consistency with the rest being ntpsec-*. Maybe upload this at this step, to start the NEW process. 2. I create transitional binary packages in src:ntpsec: ntp -> ntpsec ntp-doc -> ntpsec-doc ntpdate -> ntpsec-ntpdate sntp -> ntpsec-ntpdig with an sntp -> ntpdig symlink 3. Get a review from you (Bernhard) if you're willing? 4. Upload. 5. Then Bernhard requests ftpmasters remove src:ntp. Is that how that works? Can be done in any order: N. Mass bug filing on that list of packages, that they should use: Depends: systemd-timesyncd | time-daemon If we're going to promote chrony instead, then I think we need some more discussion and there would be more work, as it seems we should then replace systemd-timesyncd with chrony in default installs too. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
[I'm the Debian ntpsec maintainer.] On 1/18/22 11:21 AM, Paride Legovini wrote: > I'd prefer making ntp a dummy package depending on ntpsec rather than > having src:ntpsec takeover bin:ntp. If I understand correctly, you're suggesting src:ntp builds bin:ntp that is a dummy package which depends on ntpsec? Another option would be to have src:ntpsec build the bin:ntp dummy package and remove src:ntp entirely. Either seems fine to me. I don't have a strong preference. I can implement whatever is necessary on the ntpsec side. And for either option, probably likewise ntp-doc -> ntpsec-doc, ntpdate -> ntpsec-ntpdate, and if I broke out ntpdig as suggested in bug #1003966, sntp -> ntpsec-ntpdig. There are some differences. For example, ntp stores its configuration file at /etc/ntp.conf while ntpsec uses /etc/ntpsec/ntp.conf. [1] But bin:ntpsec's postinst already handles that transition. On 1/18/22 5:03 PM, Paride Legovini wrote: > bin:ntp has always been a specific NTP implementation, I think > it's OK if it's replaced by an almost compatible fork, less OK if a > completely different implementation is brought in instead. I'm biased here, but I agree. I think it makes the most sense to transition existing ntp installs to ntpsec, not chrony, as ntpsec is a drop-in replacement with a shared code history. This is my position even if we think that chrony should be the default for new installs. On that topic, I think the current default of systemd-timesyncd is fine. [1] When I was first packaging ntpsec, I was going to have it share as many paths, service names, etc. with ntp (as upstream NTPsec does). But this lead to issues with certain tooling (e.g. around init scripts) and ultimately I decided it was better to use a different namespace. This does mean that Debian ntpsec is patched and diverges a bit from upstream NTPsec. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: merged-/usr transition: debconf or not?
On 11/17/21 8:18 PM, Zack Weinberg wrote:
However, I think it was the responsibility of the developers of usrmerge
to find out how bad that problem actually was, rather than dismissing it.
And, as it has proven to be a genuinely critical problem, it is also their
responsibility to fix it, per the 'no one can be forced to do anything' rule.
At least for this email, I'll stipulate to everything above.
Is this particularly hard to fix, though?
Can't we just do something like the following pseudo-code:
/* At dpkg start... */
usrmerged = FALSE;
if (the_flag_is_set) {
usrmerged = TRUE;
} elif (bin symlinked to /usr/bin) {
usrmerged = TRUE;
/* Update e.g. /bin/foo to /usr/bin/foo in the database. */
update_database();
set_the_flag();
}
/* As dpkg is deciding to write a file path into the database. */
/* e.g. the package is trying to install to /bin/foo, put
* /usr/bin/foo into the database. */
if (usrmerged) {
path = canonicalize(path);
}
(I've used /bin -> /usr/bin as an example, but the canonicalization must
deal with the other merged paths too.)
The second bit ensures that all new operations write canonicalized paths
(e.g. /usr/bin/foo) into the database regardless of whether the .deb
shipped with /bin/foo or /usr/bin/foo. This ensures the database stays
in sync with the filesystem moving forward.
The first bit performs a one-time canonicalization of paths in the
existing database. An on-disk flag ensures that this is run only once
(for performance reasons only, because it's already idempotent). This
corrects the existing database-filesystem mismatch.
The one-time canonicalization can be removed once non-usrmerged systems
are no longer supported. The second bit needs to live (probably a lot)
longer, until it's no longer reasonable to install a .deb containing
non-usrmerged paths (which might be old or from a third party).
Am I missing something here?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?
On 11/11/21 1:23 PM, Michael Biebl wrote: Nowadays I'm not so sure anymore, e.g. I'm even considering disabling GnuTLS support in librelp. Just wondering if anyone would object to such a change? I would not. I force OpenSSL anyway. That is at least in part so we can use tls.tlscfgcmd to set CipherString, Ciphersuites, and MinProtocol per $DAYJOB's general TLS policy. It may also be because of issues with GnuTLS, I can't remember (and my comments/config messages don't indicate that). -- Richard
Re: dash and hidden bashisms in configure scripts
On 11/10/21 12:50 PM, Andrej Shadura wrote: On Wed, 10 Nov 2021, at 19:18, Sam Hartman wrote: I understand that it's generally better to fix bashisms in configure scripts. Is it possible to force autoconf to prefer bash for a given configure script if it's difficult or undesirable to fix bashisms in a configure script? Yes, passing CONFIG_SHELL=/bin/bash to configure with do the thing. Can we just enable LINENO in dash then, let the other packages FTBFS, and people who care about the packages that FTBFS can either: A) Fix the bashisms, or B) Add CONFIG_SHELL=/bin/bash to their ./configure invocation. bash is currently Essential, so there's no need for a Build-Depends on bash for option B right now. A might be easy, and B is definitely trivial. It sounds like there are real benefits to enabling LINENO in dash. LINENO support is apparently required by POSIX, so this fixes dash in that regard (582952 comment #10) and for those packages using autoconf without bashisms, dash will speed them up (842242 comment #5). Bug #582952 (the first time LINENO was enabled in dash) was from 2010. I understand reverting the change to dash if it was near a release. But that's not the case right now and at this point, it's been ELEVEN YEARS. It's time to move forward. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Not running tests because tests miss source code is not useful
On 10/7/21 11:35 AM, Russ Allbery wrote: Richard Laager writes: I haven't looked into the specifics of this situation, but in general, tests should be run against the same versions of dependencies that the actual code will use, for what should be obvious reasons. If Debian has the dependencies with different API versions, then it's all the more important that the tests run against the Debian versions of the dependencies. I believe the dependencies in question are test dependencies. In other words, they're dependencies required to drive the test suite machinery, not dependencies of the code under test. Thanks for the clarification of the specifics! In that case, I personally don't see a big problem with them being vendored as opposed to using system copies. But AFAIK, they do still need to be DFSG-free to be in main if they are in the source tarball. And I personally would not consider minified JS (if that is indeed at issue here) to be "source code". -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Not running tests because tests miss source code is not useful
On 10/7/21 4:40 AM, Pirate Praveen wrote: What you are proposing would require the package maintainer to adapt these tests to versions available (many times with different API versions) in Debian and the easier choice is disabling tests. I haven't looked into the specifics of this situation, but in general, tests should be run against the same versions of dependencies that the actual code will use, for what should be obvious reasons. If Debian has the dependencies with different API versions, then it's all the more important that the tests run against the Debian versions of the dependencies. Running tests against vendored dependencies one isn't going to use at run-time is of limited usefulness. Presumably upstream is already running those tests against the vendored dependencies, so the odds of Debian finding breakage in the _source_ at packaging time is low. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#995189: RFH: isc-dhcp
On 9/28/21 11:49 AM, Vincent Bernat wrote: ❦ 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. 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. 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? 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)? Can you articulate why ifupdown2 is better than e.g. systemd-networkd + netplan? I'm not looking for an exhaustive comparison or anything, but just a brief statement or two if you're willing? I've never used it, and if it's better than systemd-networkd + netplan, I might consider switching. -- Richard
Re: Bug#995189: RFH: isc-dhcp
On 9/28/21 8:44 AM, Vincent Bernat wrote: ❦ 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 Agreed. and does not allow proper reconfiguration. What do you mean? -- Richard
Re: Bug#995189: RFH: isc-dhcp
On 9/27/21 9:15 PM, Marco d'Itri wrote: On Sep 28, Noah Meyerhans wrote: Should it be mentioned what the new recommended DHCP server for general use will be? ISC Kea? I haven't converted to it, but that's their replacement for dhcpd. I think that a good default would be systemd-networkd for servers and NetworkManager for systems with Wi-Fi or a GUI. That seems reasonable. I don't think we should install something like netplan by default. I agree: it only adds complexity. I personally use netplan everywhere. 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: This default would match Ubuntu. (I value reducing that delta. Not everyone does, and that's fine.) netplan can configure both systemd-networkd and NetworkManager (though I've only used it with systemd-networkd). In my non-trivial configurations, the netplan YAML input is half as many lines as its networkd output. This is with the input including a bit of comments and the boilerplate, disabling dhcp, and using YAML's more verbose list syntax (separate lines vs one line). I don't see anything wrong with its output that I could simplify. Again, in this non-trivial configuration, I think it's more useful to have one netplan YAML file than 24 separate networkd files. This is especially true when I'm building this file from an Ansible template and most of it (by volume) is built by loops. In the trivial case, it's 19 lines of netplan (16 if you exclude the stock comment) vs 25 lines of systemd-networkd, both in single files. That's not a huge difference. -- Richard
Re: next steps after usrunmess
On 8/27/21 10:20 AM, Theodore Ts'o wrote: Does someone need to create patches to dpkg which attempt to teach it that /bin/foo and /usr/bin/foo are the same file, if there exists a symlink from /bin to usr/bin? Yes. I can't speak to the dpkg internals, but conceptually, this seems like the right thing to do. Even if we eliminated usrmerge entirely, I'm not sure what's harmful about dpkg canonicalizing filenames. In fact, it seems very much like the right thing to do. So unless the patch is very invasive, I don't see why one would object to this change on its own. And then with some kind of process, maybe with the blessing of the technical committee, upload it as an NMU over the objections of the dpkg developers if they continue to refuse to engage with solutions that proceed forward with /usr-unification? Yes. If the dpkg maintainer does not accept a reasonable patch, then this may need to be presented to the TC to overrule him, which requires a 3:1 TC majority. One might argue the existing TC decision implies this, but the least ambiguous procedural option would be to have the TC explicitly overrule the maintainer once a specific implementation is available. It is my view that the usrunmess utility also needs to be dropped before the bookworm release. That quite clearly follows from the existing TC decision, which is that only the merged-usr layout is supported, so I don't think that needs further TC action. However, I think removing that utility should wait until such time as we have the other issues reasonably resolved. Should a single DD have the power to overturn a techical committee because they are the maintainer of a highly important package? No. This is settled in the Debian constitution. If a DD wishes to override the TC, they need to propose a GR. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: What are desired semantics for /etc/shells?
On 6/14/21 7:39 AM, Helmut Grohne wrote: At this time, my personal preference would be turning /etc/shells into a symbolic link to an autogenerated file. Is there a harm in /etc/shells containing shells that are not installed on the system? If not, then we could ship a single /etc/shells in base-files and be done with it. The file would only need to change when a new shell is packaged for Debian, which is infrequent; such a change would be trivial to make. One downside would be that third-party repositories, e.g. for a new shell, could not add to /etc/shells, in a policy-compliant way. That said, Debian Policy is not binding on them anyway. If it _is_ harmful for /etc/shells to reference shells that do no exist, then maintaining the list automatically (by whatever mechanism, including the current approach but fixing the bugs) makes sense. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Epoch bump for kernelshark
On 5/23/21 8:34 AM, Sudip Mukherjee wrote: And, as a result, upstream kernelshark is now at v2.0 but the Debian packaged version is at v2.9.1 and I will need to add an epoch to the version to package it directly from its new upstream repo. Current version: 2.9.1-1 Proposed version: 1:2.0-1 How close is upstream to 3.0? If not close, are they willing to bump to 3.0 anyway to avoid this versioning issue? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: DEP-14 update, second attempt
On 11/29/20 10:11 AM, Paride Legovini wrote: > I tried to do a synthesis of past August/September thread on the > finalization of DEP-14 [1], see: > > https://salsa.debian.org/dep-team/deps/-/merge_requests/1/diffs This all looks great to me! > I tried to stick to what I believe we had consensus on, however I think > that point (3) has a shortcoming: it allows / branches, > but doesn't cover cases where has no development _suite_. For > example it wouldn't allow the kali/kali-dev branch, as Kali doesn't have > suites (IIUC). This case could be covered by adding: > > However, when `` has no concept of suite for the > development release but has a fixed codename for it, the > use of the `/` scheme is accepted. Assuming the acceptance of the other text, I think the consensus is that kali/kali-dev is perfectly fine. I'm not sure if additional text is necessary to clarify this, especially since this isn't actually binding on Kali anyway. But at the same time, I have no objection to that additional text either. -- Richard signature.asc Description: OpenPGP digital signature
Re: Proposed changes to sbuild and debootstrap
On 11/29/20 1:33 PM, RhineDevil wrote: > A viable solution for achieving this may be using an optional -f/--flavour > parameter Is flavour intended to be something like Debian vs. Devuan vs. Ubuntu? If so, could you please use "vendor" instead, since that is the pre-existing term for that distinction in various places, including dpkg-vendor. -- Richard signature.asc Description: OpenPGP digital signature
Re: epoch bump for libtraceevent
On 10/13/20 11:40 AM, Sudip Mukherjee wrote: > libtracevent is currently being packaged from the linux kernel source > and as such it has the version of '5.8.14-1' same as the kernel. As > reported in #971976, the upstream libtraceevent now lives in its own > repo and has a version of '1.1.0' > So, I will need to add an epoch to the version to package it directly > from its upstream repo. Have you asked upstream if they would be willing to bump the version to 6.0 or something? -- Richard signature.asc Description: OpenPGP digital signature
Re: Allowed to build-depend a pkg in main on a pkg in non-free?
On 9/30/20 4:45 PM, Paul Wise wrote: > The > official buildds, for packages in main, seem to include contrib but > not non-free binary packages in the chroot's apt sources.list files. > Both contrib and non-free source packages are available in the chroots > apt sources.list files. This appears to be the same for all three of > main, contrib, non-free. I would expect that: 1. main builds include main repositories 2. contrib builds include main, contrib, & non-free repositories 3. non-free builds include main, contrib, & non-free repositories This would match the Policy allowed package dependencies. Including _more_ than this wouldn't break builds, but could allow non-Policy compliant dependencies to sneak in. For example, a package in main that Build-Depends on a package from contrib should FTBFS on the buildd, but would not. Including _less_ than this could break builds. For example, if I have a "free package in contrib that require[s]... non-free packages" (Policy 2.2.2) and the buildd doesn't include non-free, it will FTBFS when it should build. Am I missing something here? If I'm understanding everything correctly, this seems buggy. -- Richard signature.asc Description: OpenPGP digital signature
Re: How much data load is acceptable in debian/ dir and upstream (Was: edtsurf_0.2009-7_amd64.changes REJECTED)
On 9/14/20 2:04 PM, Andreas Tille wrote: > in the Debian Med team there are two GSoC students very busy to write > autopkgtests for (in the long run) all our packages (if possible). That is an excellent thing to do. > On Sun Sep 13 18:00:08 BST 2020, Thorsten Alteholz wrote:[3] >> please don't hide data under debian/*. > > Sorry, Thorsten but I think "hiding" is not the right term. FWIW, I agree that "hiding" seems wrong here. > We have no > other dir to add extra files than the debian/ dir. Assuming a "3.0 (quilt)" package, you have the option of adding another source tarball. [1] I'm not sure if that is better or worse here. It just moves data from one source tarball (the debian one) to another. But it is an _option_ at least. >> Don't forget to mention the copyright information. > > In principle yes, but these data are not copyrightable as far as I know. > Nilesh has mentioned the origin of data in debian/tests/README to > provide a reference. If you consider this information not sufficient > please let us know a better way. I would put the explanation in debian/copyright (instead of or in addition to any other location). If you're using machine-readable copyright, use "License: public-domain", and and note that 7.1.1 _requires_ an explanation of why it is public-domain, as public domain is commonly misunderstood. [2] [1] https://wiki.debian.org/Projects/DebSrc3.0#How_to_use_multiple_upstream_tarballs_in_3.0_.28quilt.29_format.3F [2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name -- Richard signature.asc Description: OpenPGP digital signature
Re: [Pkg-javascript-devel] How to switch to DEP14 automatically for > 1000 existing repositories
On 9/11/20 11:26 AM, Xavier wrote: > $ salsa --group xx-team --all --no-fail rename_branch \ > --source-branch=upstream --dest-branch=master Should "upstream" be "upstream/latest"? As I understand it, "master" is correct if it is the upstream git "master", but "upstream/latest" is correct if it is the gbp upstream-branch representing imported upstream tarballs. -- Richard signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 9/7/20 5:33 AM, Raphael Hertzog wrote:
> On Sat, 05 Sep 2020, Richard Laager wrote:
>> I do not see why we have to prohibit occasional uploads to experimental
>> from debian/unstable. If this is permitted, then that also avoids the
>> busywork of creating debian/experimental in that scenario.
>
> To me it feels awkward to allow this. You can't really get it both ways
> IMO. If you decide to use codename-based branches, then you should use
> debian/experimental for an experimental upload.
That view is: A > B.
FWIW, my justification for B > CD is:
Since the parallel branch scenario is already debian/unstable &
debian/experimental, then I'll take a small inconsistency for the
occasional upload to experimental to be able to use a strict subset of
those choices (debian/unstable) as the normal scenario, rather than a
whole new thing (debian/{master,latest}).
> The "clarity" of debian/unstable is limited to Debian developers, upstream
> developers might not know that unstable is the development branch. Random
> outsiders neither.
Whatever it is called, the main development branch will normally be the
HEAD, so an unqualified `git clone` will give that branch. (Exceptions
include when the repository is mixed upstream and packaging.) That
probably covers the upstreams and random outsiders.
> But what I meant is that "unstable" is only applicable to Debian and
> that derivatives have different models and that we should not impose
> too much to make sure we cater to the needs of derivatives too.
I think you were following, but to be clear, the proposal isn't
/unstable, it's /. So
debian/unstable, ubuntu/groovy (changes as time moves on),
kali/kali-dev, etc.
I do acknowledge that /latest is undoubtedly easier for the
tooling to implement, and that is a serious advantage of C.
> Without having read your precise diff, I would believe my personal view
> would be: C > D > B > A
That is what I expected your view to be. You might be A > B rather than
B > A, though, as discussed above.
Anyway, I think I'm into dead horse territory here. Unless someone else
speaks up, I assume the next step is for you to pick an option, which I
assume will be C (in principle; not necessarily my wording).
Thanks for taking the time to hear me out and thanks for DEP-14!
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/31/20 8:53 AM, Raphael Hertzog wrote: > I already agreed that we can tweak the wording to document that it's I don't think the people on the list saw that message, as it had an attachment. It's below (unabridged). > OK to use debian/unstable as default branch even if you are not a > complex package that require multiple branches, provided that you will > not use debian/unstable when you decide to push something to > experimental. I do not see why we have to prohibit occasional uploads to experimental from debian/unstable. If this is permitted, then that also avoids the busywork of creating debian/experimental in that scenario. On 8/30/20 4:27 PM, Raphael Hertzog wrote: > Hello, > > On Sun, 30 Aug 2020, Richard Laager wrote: >> You could use debian/experimental all the time and then merge down to >> debian/unstable only when you're ready to upload and have chosen >> unstable. But I suspect your objection would be: that's unnecessary >> busywork. And I see that point. I would probably make the same >> objection, which means I think I agree with the debian/latest concept in >> your situation. > > You perfectly understood my reasoning. Thank you for making that effort. > >> I'm not sure if most package maintainers are doing this or not. I've >> always assumed that most people are targetting only unstable most of the >> time and that use of experimental is relatively rare. I could easily be >> wrong on that. > > I don't think that you are wrong. Most packages definitely only target > unstable and never use experimental. Then why give up the simplicity of only one choice and the clarity (and tooling advantages) of debian/unstable as the typical case, in favor of debian/latest? > But most packages also never need to maintain two development branches > in parallel. Only very big packages, linux or django for example, will > maintain different upstream versions in two parralel branches. > > Another thing that's quite certain is that you never know what the future > will bring you. And while you never had to use experimental, you might > have to at some point. > > In that sense, I find debian/latest more future-proof but I also > agree that for the few cases where we would have to use experimental, > it's not a big deal to have to create debian/experimental. > > Another thing to take into account is that DEP-14 has been drafted > as a vendor-neutral recommendation. I use it in the context of Kali > and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu > only has codenames even for their development release. What's wrong with kali/kali-dev? I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would be better there. From my point of view (as someone who occasionally SRUs something in Ubuntu), having ubuntu/ is the right choice. When a new development release opens up, you would branch e.g. ubuntu/focal into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs (stable release updates). To me, my proposed branching model feels like it matches the Ubuntu development model 1:1. > Thus /latest is a better default for tools like git-buildpackage > and it makes sense for DEP-14 to endorse such a default branch as the > recommended name. > >> That is, I'm generally always targetting unstable and _not_ regularly >> using multiple releases, so the DEP-14 language "prohibits" me from >> using debian/unstable. This is what feels backwards to me. If I'm always >> targetting unstable, debian/latest (and previously debian/master) is >> less clear than debian/unstable. >> >> At a minimum, can we rework this in some way so the language does not >> require me to be regularly using multiple releases to use >> debian/unstable as a branch name? > > That seems entirely reasonable, yes. Can you try to make a proposal ? > > I attach the current markdown file with my not-yet pushed change that I > submitted for review here. > > Cheers, DEP-14 starts this section with a broad, "In general, packaging branches should be named according to the codename of the target distribution." On that, I think we all agree. Then it continues, "We differentiate however the case of development releases from other releases." Fundamentally, the scope of that exception is what we are discussing. Diffs available here (since this list refuses attachments and I can't figure out how to disable line wrapping in Thunderbird): https://paste.debian.net/1162793/ Proposal "A": My original position was that we limit that exception to using "unstable" and "experimental" instead of "sid" and what (I later learned) may or may not be "rc-buggy". This has the advantages that ther
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/30/20 12:02 PM, Sean Whitton wrote: > Hello Raphael, > > On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote: >> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn >> index 0316fe1..beb96ea 100644 >> --- a/web/deps/dep14.mdwn >> +++ b/web/deps/dep14.mdwn >> +In the interest of homogeneity and of clarity, we recommend the use of >> +`debian/unstable` over `debian/sid` as it better conveys its special nature >> +as opposed to other branches named after codenames which are used for >> +stable releases. > > I think we should recommend debian/sid because for some years dgit has been > generating branches called dgit/sid. I think it would smooth the integration > between branches on salsa and branches on dgit.debian.org if both always used > codenames. Using debian/sid makes the branch name inconsistent with debian/changelog, which traditionally uses "unstable" not "sid". It also makes debian/experimental an outlier that cannot be made consistent (because there is no character code name for experimental AFAIK). -- Richard signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
I think I now have a better handle on how/why I disagree with the DEP-14
recommendation language.
On 8/30/20 8:36 AM, Raphael Hertzog wrote:
> On Sat, 29 Aug 2020, Richard Laager wrote:
>> That said, I do understand we give a lot of deference to developers'
>> workflows. So I have no objection to DEP-14 supporting this workflow
>> with debian/latest. But I would like to see it (debian/latest)
>> recharacterized as the alternate approach rather than the recommended
>> method.
>
> Your approach is perfectly valid but I don't really believe that it should
> be the recommended approach. It doesn't seem to match the most common
> workflow.
>
> Most package maintainers are not actively working on two different
> development branches, instead the single development branch keeps moving
> between:
> - ready for unstable/upload to unstable
> - work in progress on a new upstream release
> - possible upload to experimental to gather feedback (buildd, users)
> - back to ready for upload to unstable
So you are regularly using multiple releases (unstable and experimental)
where the DEP-14 language allows you to use either debian/latest or
debian/{unstable,experimental}, but you feel debian/latest makes the
most sense most of the time in that scenario.
I think I see your point. You don't always know a priori when you are
going to want to upload to experimental. (Where you do know that, it's
because you expect the experimental piece to live in parallel for a
while and you'll use a temporary debian/experimental branch.) So you
have one debian/latest branch that can upload to unstable or
experimental as needed.
You could use debian/experimental all the time and then merge down to
debian/unstable only when you're ready to upload and have chosen
unstable. But I suspect your objection would be: that's unnecessary
busywork. And I see that point. I would probably make the same
objection, which means I think I agree with the debian/latest concept in
your situation.
I'm not sure if most package maintainers are doing this or not. I've
always assumed that most people are targetting only unstable most of the
time and that use of experimental is relatively rare. I could easily be
wrong on that. But that is definitely _my_ practice:
My package branch typically moves between:
- ready for unstable/upload to unstable
- work in progress on a new upstream release
- back to ready for upload to unstable
That is, I'm generally always targetting unstable and _not_ regularly
using multiple releases, so the DEP-14 language "prohibits" me from
using debian/unstable. This is what feels backwards to me. If I'm always
targetting unstable, debian/latest (and previously debian/master) is
less clear than debian/unstable.
At a minimum, can we rework this in some way so the language does not
require me to be regularly using multiple releases to use
debian/unstable as a branch name?
Preferably, can we change this to convey the following (probably using
better language):
1. If you (have one line of package development and) regularly
alternate between uploading to unstable and experimental, use
debian/latest.
2. If you normally only upload to unstable, use debian/unstable.
3. If you will have a separate line of package development for upload
to experimental, name that debian/experimental. If that is
long-lived, the other branch should be debian/unstable.
#1 covers your use case. #1 is listed first per your view that this is
the common case. #2 covers my use case. #3 allows either a #1 or #2
style to add debian/experimental temporarily, while recommending the
debian/{unstable,experimental} pair if the experimental branch is
long-lived (because it's confusing for debian/latest to not be the
latest version).
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/29/20 5:16 PM, Simon McVittie wrote: > On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote: >> However, this is still saying that one should prefer debian/latest over >> debian/unstable, and that debian/unstable is (sort of) only for use when >> you're also uploading to experimental. > > The way I think of it phrases this a bit differently: whether or not you > have a version targeting experimental right now, if you *were* uploading > to experimental, what would you do? I think that's a perfectly reasonable way to look at the issue. I don't think that's what the DEP-14 language says, though. > I think the workflow used in packaging dbus (with the newly proposed > naming: debian/unstable as default, and a debian/experimental branch > that runs ahead of it) is fine. This is good if you want to draw most > attention to the version in unstable, with experimental being for early > adopters and not recommended for general use. > > I think the workflow used in packaging gnome-shell (with the newly > proposed naming: debian/latest as default, and a debian/unstable branch > that lags behind it) is *also* fine. This is good if you want to draw > most attention to the version in experimental (when there is one). In both cases, I would have debian/unstable and debian/experimental branches. I would draw attention to the main line of development by making that as the default branch on the server: debian/unstable in the first case and debian/experimental in the second. That way, someone who doesn't know the package's branch style gets a hint on clone; someone who does already knows which branch they want and can pick it explicitly. Of course, the same server-side HEAD setting also works (and should be used) if debian/latest is in use. -- Richard signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/29/20 5:19 PM, Russ Allbery wrote: > The problem in my case with not putting a branch name in Vcs-Git is that, > for packages for which I'm also upstream, the default branch in the > repository named in that header is the upstream development branch, which > contains no Debian packaging files and thus would be a very confusing > thing for debcheckout to clone. So I have to name *some* branch, which > right now is debian/master and would be debian/latest. If the packaging is on Debian Salsa (which I would recommend), then I'd set the default branch to the packaging branch. If upstream happens to live there too, then people can switch to that explicitly. Rationale: The packaging is the more relevant thing to Debian. While there are Debian native packages and some people are both upstream and packager, the common case is software packaged from another upstream. Then you don't need a branch name in debian/control. -- Richard signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/29/20 3:33 PM, Russ Allbery wrote:
> I think the primary thing that bothers me about this workflow is that
> experimental becomes an ephemeral branch, which appears and disappears
> based on the vagaries of the release cycle.
To me, that feels like the branch is an accurate representation of
reality. The packages in experimental are ephemeral and appear and
disappear too, right?
> That said, one way in which this becomes concrete is the Vcs-Git control
> field. What do you put in the branch field for your experimental upload?
> Naming debian/experimental is clearly wrong; that branch is highly likely
> to not exist when someone later checks. Naming debian/unstable is also
> clearly wrong; the package is not based on that branch.
I wouldn't (and don't) put a branch name there. I don't think it serves
a practical purpose. If it does, I guess a corollary is that I/we should
be specifying debian/buster there for stable updates and likewise
debian/buster-backports for backports. Is that a thing people actually
do? I haven't been, but I can do so if that is a best practice.
I currently set the branch name in debian/gbp.conf because that actually
has a practical effect on the tools.
Putting the branch name in debian/gbp.conf leads to a small amount of
churn for things like stable updates and backports. I had forgotten
about the effects of that in your case. That does undercut my argument a
bit in the immediate term, as you'd have to change that when going
between experimental and unstable, which means they aren't just
fast-forward merges. But if we standardize on this naming convention as
I propose, then gbp could default to these branch names, which means we
wouldn't need to set branch names in debian/gbp.conf. That seems like
the best long-term outcome.
> It's valid to say that it's okay for me to feel odd and I can cope with
> feeling odd and follow the convention anyway.
To be honest, I lean towards that view. But you've been doing Debian
development more and/or longer than me (and more to the point here,
actually use experimental regularly), so I'm very hesitant to dismiss
your viewpoint. I could easily be missing something.
I would love to see other people weigh in on debian/latest vs
debian/unstable as the default. Assuming the silent majority is using
debian/{master,latest}, is that out of a considered preference over
debian/unstable or out of inertia / following other packages / following
DEP-14? In other words, how many people _care_ either way?
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/28/20 6:01 PM, Raphael Hertzog wrote:
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
I think this is a change in the right direction.
However, this is still saying that one should prefer debian/latest over
debian/unstable, and that debian/unstable is (sort of) only for use when
you're also uploading to experimental.
I think this is backwards. I think the default should be
debian/unstable. If you want to use experimental, then also use a
debian/experimental branch.
The big advantage of this approach is that the branch names are always
consistent with changelog names. This works well when you need a
debian/buster for a stable update and/or a debian/buster-backports for a
backport. Aside from being helpful to humans, this consistency then
makes for a reasonable default in the tools (e.g. git-buildpackage). It
also extends perfectly to use with downstream distributions, with things
like ubuntu/bionic, ubuntu/focal, etc. FWIW, I have a package using all
of debian/{buster,buster-backports,unstable} and ubuntu/bionic right now
and it works great.
When I last brought this up [1], Russ Allbery said that debian/latest
was desirable (to him, at least) because, "My normal use of experimental
does not involve maintaining unstable and experimental branches
simultaneously. I essentially never do that; instead, I maintain one
development branch, which I upload to either experimental or to unstable
based on things like where we are in the release cycle or whether I need
to stage some change." [2]
I believe that "git branches are cheap", so I don't really see the
problem in switching back and forth between debian/unstable and
debian/experimental in that case. Given that he further said, "If I'm
uploading to experimental, I don't fix bugs in unstable until the
experimental release is ready for upload to unstable.", the merges would
be fast-forward merges anyway, so they wouldn't take any actual hand
merge work. Using separate branches would inherently allow for proper
handling of the "exception" he described of needing to upload a fix to
unstable while debian/latest is the upload to experimental.
That said, I do understand we give a lot of deference to developers'
workflows. So I have no objection to DEP-14 supporting this workflow
with debian/latest. But I would like to see it (debian/latest)
recharacterized as the alternate approach rather than the recommended
method.
Previously, my proposal would have required a fair amount of branch
renaming--from debian/master to debian/unstable. However, with the
change from debian/master to debian/latest, branch renaming would "have
to" occur anyway, so renaming debian/master to debian/unstable is no
more trouble.
[1] https://lists.debian.org/debian-devel/2019/11/msg00084.html
[2] https://lists.debian.org/debian-devel/2019/11/msg00085.html
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: Pimp your shell - Debian developer tips?
Some notes from our defaults at $DAYJOB. I can't take credit for most of
this. These were ideas I've picked up from various people along the way.
# Prevent users from accidentally overwriting files with redirection.
set -o noclobber
Warning: While I'm the one that added it, sometimes I don't love
"noclobber".
# Fix some spelling errors in tab-completions
shopt -s cdspell
shopt -s dirspell
# Allow ** to recurse
shopt -s globstar 2> /dev/null
# Make globs case-insensitive
shopt -s nocaseglob
# Tell less to not ring the bell (Q) and pass through color escape
# sequences (R).
export LESS="QR"
# Save and show timestamps in the command history.
HISTTIMEFORMAT='%F %T '
We also colorize the hostname, which can act as a subtle hint as to
whether you are on the right system. (It's basically an subconscious
thing; it's not like we memorize which system is which color.) These
days, the per-host color is calculated with Jinja templating in Ansible.
The example below is the older code where bash calculates it. My email
client is going to word-wrap this, so you'll have to reverse that, but
it's straightforward.
# We use dircolors instead of tput to determine which types of terminals
# support colors. Otherwise, we can end up with an inconsistency
# between bash and ls, et al. For example: a vt100 on OpenIndiana.
if (LS_COLORS= ; eval $(dircolors 2> /dev/null) ; [ -n "$LS_COLORS" ])
then
# Colorize based on hostname: green, yellow, blue, magenta, or cyan.
ps_h='\[\e[1;'$((32 + $(hostname | cut -d. -f1 | cksum | cut -c1-3)
% 5))'m\]\h\[\e[0m\]'
if [ "$(id -u)" = "0" ]
then
# Make the username and # red when logged in as root.
PS1='${debian_chroot:+($debian_chroot)}\[\e[1;31m\]\u\[\e[0m\]@'$ps_h':\w\[\e[0;31m\]\$\[\e[0m\]
'
else
PS1='${debian_chroot:+($debian_chroot)}\u@'$ps_h':\w\$ '
fi
unset ps_h
if [ -r ~/.dircolors ]
then
eval "$(dircolors -b ~/.dircolors)"
else
eval "$(dircolors -b)"
fi
alias ls='ls --color=auto'
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
It's not shown in the example above, but we also use white text on a red
background for the hostname if it ends in -new. This is our convention
when a new system is being setup: we set the hostname (in Ansible in our
case) for a system replacing a host named "name" to "name-new". This
prompt helps you keep track of whether you are on the current production
system or the -new system you are configuring. It is functionally
equalivalent to:
ps_h='\[\e[1;37m\]\[\e[1;41m\]\h\[\e[0m\]'
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: +1 (no hidden directory, please) Re: [Summary]: RFC: Standardizing source package artifacts build paths
On 5/3/20 5:54 PM, Holger Levsen wrote: > On Sun, May 03, 2020 at 10:56:32PM +0200, Simon Richter wrote: >> Frankly, I don't see the point in hiding the directory. The only person >> who'd ever look into that directory would be someone inspecting what >> happened during a build process, and all that hiding directories >> achieves is adding more mental load to them where they have to remember >> to use ls -a, and type a dot before trying to tab-complete anything. >> >> Basically, it would just be annoying with no good reason. > > my thoughts exactly. Agreed. Nothing else in the debian directory is hidden. I think the burden should be on justifying why this should be the one hidden directory. -- Richard signature.asc Description: OpenPGP digital signature
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
On 3/30/20 2:34 PM, Sean Whitton wrote: > The text quoted from the -private IRC channel is a bit misleading. I > was the one who rejected the upload, and it was not actually because of > the QR codes, but for other reasons. I think it was pretty clear from the original email that there was another reason, not under debate, for why it was rejected. This thread was only to address the QR code question. -- Richard signature.asc Description: OpenPGP digital signature
Re: DFSG of disk image with contrib package
On 3/16/20 12:25 PM, Emmanuel Kasper wrote: > For extended functionality, I build some of the disk images with a > package from contrib, namely virtualbox-dkms Could you use KVM (and if necessary, libvirt) instead? -- Richard signature.asc Description: OpenPGP digital signature
Re: Best practices for Debian developers who are also upstreams?
On 2/8/20 7:57 PM, Simon Richter wrote: > In my experience, it was often a good idea to separate my upstream and > Debian hats. +1 My current situation is that I'm a Debian packager who has then over time become more involved in upstream and eventually ended up with a commit bit. On a different package, I'm in the process of taking over packaging for something where I am already an upstream developer (or perhaps should say "was", as I haven't been active upstream in some time, though that may change here). That sounds like it may be different than your situation, but I hope I can still offer some useful comments. > At the same time, Debian packages have a well-defined installation > procedure, so it is often possible to build a quick fix for a bug that > will give users a working package, but where the patch is not suitable > for upstream inclusion, like changing an init script or unit file. +1. In such a case, you can clean that up into a more general solution for upstream and later drop the Debian patch. I've had that exact thing happen. >> - have debian/ in upstream repository, and a CI that does the bulk of >> Debian QA on every upstream commit and immediately gives feedback to >> upstream devs that "break" something from Debian QA point of view I'm in the process of packaging something where upstream (which is not me) puts their debian directory (for CI purposes) as packaging/debian. That allows them to do real Debian packaging for CI, and update that as necessary, but keeps it out of the way of the real "debian" directory. You might consider that option. Upstream's CI presumably has to move/copy/link ./packaging/debian to ./debian before kicking off the Debian build, but that's just one extra step. >> - bonus: import upstream releases as git operations Do this either way! :) In the packages I maintain, my debian/README.source says: The `master` branch is upstream's `master` branch. ... The `upstream/latest` branch contains the unpacked contents of the orig tarball. It is branched off the `master` branch, so the delta from `master` (at the branch point) to `upstream/latest` contains generated files that exist in the tarball but not in the upstream repository. That said, I prefer to keep separate git checkouts for the package and upstream to avoid the potential for accidents like pushing upstream pull request branches to Debian Salsa or, far more likely, accidentally pushing the current master to Debian Salsa. > Maintaining debian/changelog inside a version control system is a bit of > a category error, because it is a form of version control system log, I'm a big fan of using git-buildpackage and `gbp dch`. My current workflow (somewhat "copied" from e.g. lintian) is that debian/changelog contains a stub like this until it is time to tag a Debian package release: ntpsec (1.1.8+dfsg1-4+git) UNRELEASED; urgency=medium * UNRELEASED -- Richard Laager Sat, 11 Jan 2020 22:49:28 -0600 Note that it is critical that the version in Salsa NOT be the same as the version in the archive if you are using Salsa CI to test changes. That's why the +git is added. If they are the same, when the CI code tries to install the package, you'll have problems because of the conflicting version numbers. -- Richard signature.asc Description: OpenPGP digital signature
Re: packages that are touching /srv?
On 2/6/20 9:41 AM, Daniel Baumann wrote:
> On 2/6/20 4:10 AM, Richard Laager wrote:
>> That's been my interpretation too. My expectation as a sysadmin is that
>> /srv is available for my _exclusive_ use.
>
> in the case of vsftp and tftpd-hpa, there's a debconf question asking
> the admin for the location of these directories, for which /srv/{t,}ftp
> are the default values.
>
> or in other words: I agree with you that /srv shall not to be touched
> without consent from the admin.
That's a very interesting point! I hadn't considered the difference
between a fixed default and a debconf default.
FWIW, at $DAYJOB, our stance is to accept all debconf defaults (e.g. use
"hit enter at every prompt" or use noninteractive mode) and then
configure after / on top of that (via debconf or not). So to me, in
practice, debconf defaulting to /srv/tftp is the same as not having a
debconf prompt and making it a fixed default. I understand that's not
the same in theory, where a reasonable argument can be made that the
admin accepting the debconf prompt is giving their permission.
In terms of these particular packages, I'm not using vsftp and I'm using
tftpd-hpa with its default of /srv/tftp. I don't have strong feeling
abouts debconf-default vs fixed-default, so I probably don't have much
to add further.
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: packages that are touching /srv?
On 2/5/20 7:36 PM, Paul Wise wrote: > AFAICT from Debian's FHS > documentation, since /srv is laid out differently on different hosts > packages should not rely on a particular layout. My interpretation is > of this is that packages should never touch /srv unless directed to do > so by the sysadmin. That's been my interpretation too. My expectation as a sysadmin is that /srv is available for my _exclusive_ use. > FTP servers that default to using /srv/ftp to serve files. > TFTP servers that default to using /srv/tftp to serve files. > These also use those dirs as user home directories. I actually use both /srv/ftp and /srv/tftp, but I still don't think those are acceptable defaults. > I wonder if any of these should be changed? FWIW, I would say yes. -- Richard signature.asc Description: OpenPGP digital signature
Re: Salsa CI news
On 2/5/20 5:05 PM, Dmitry Smirnov wrote: > It should be on abuser Saying "abuser" is inflammatory, especially as no abuse has been proven. Please stop. > to explain that it was not possible to build a > service in a fully DFSG compliant manner Why is the current solution not DFSG compliant? > only from components provided by Debian. While I agree it would be better in Debian to use a Debian image instead of an Alpine one and to use Debian packages, that is separate from DFSG compliance and a much lower severity issue. -- Richard signature.asc Description: OpenPGP digital signature
Re: Adding security features (was: Kernel parameters protecting fifos and regular files)
[ Note: I have reordered the quoted text blocks. ] On 1/29/20 8:28 AM, Marvin Renich wrote: > On the other hand, I do agree with using unstable and testing to > determine the level of disruption, on the condition that there is a > _commitment_ to removing the feature before stable release if the > impact on usability is more than minor. +1 I don't think we're that far apart here. There are plenty of shades of grey in this, and what counts as "minimal", "medium", or "massive" is going to be at least somewhat subjective. > Even medium disruption is the > wrong balance for a general distribution's default. I'm willing to go a bit further than you, as I would take (again, my subjective) "medium" disruption for a real security win, generally speaking. > I would like to give big kudos to the AppArmor team for providing > Debian developers and users with an exemplary experience while adding > a security feature as a distribution default. +1 AppArmor had the potential to cause massive breakage, and has not, primarily due to it being opt-in. I think this has been a big success. I would characterize AppArmor as being on the low end of "medium" breakage. AppArmor is something that I need to care about on an on-going basis as a sysadmin. I need to be aware it exists, how its problems will manifest, how to debug it, and how to fix it. I can't completely ignore it, as it does break things from time to time. This is not to say it breaks things out-of-the-blue. It breaks things when I change configurations away from the default. That's totally fine. I figure it out and go add the appropriate bit to the local/tunable file. Something minimally disruptive would be something like Address Space Layout Randomization (ASLR). While that may have impacts on maintainers enabling/disabling compiler flags, it is not something I ever have to think about as a sysadmin. It is never the problem. I never need to do anything related to it (as a sysadmin). Something like SELinux in the RedHat world is probably still at least on the high end of "medium" these days and could probably be characterized as "massive breakage" in its early days. "Massive breakage" is the sort of thing where large numbers of experienced sysadmins respond with "just turn it off". With what I know about this particular change right now, my assumption is that it will cause little to no breakage. I would characterize the expected impact as "minor". Further, I expect that any breakage will be "one-time" breakage that can be addressed by application developers and/or package maintainers, and it will not cause on-going work for system administrators. > > Unless massive breakage is expected, the default should > > be the most secure option. > The above > statement implies that the default should be the maximum security that > does _not_ cause _maximum_ disruption. I'd say that "massive breakage" (breaking lots of things) is not the same as "maximal disruption" (the most disruption). Maximum disruption would be, for example, breaking things that were "fully correct" (not doing something "dodgy") before the change. This would be a "flag day" change. That level of disruption needs to be avoided if at all possible, and carefully managed if completely unavoidable and worth the pain. > Time and time again I see security expert "wannabes" pushing for the > most security possible. Even real experts sometimes lose sight of the > balance between usability and security. Unfortunately, there are a lot > more "wannabes" than real experts, and the "wannabes" are typically much > more vocal. While I understand your point, I think it would be better to focus on the arguments rather than the people making them. -- Richard signature.asc Description: OpenPGP digital signature
Re: Kernel parameters protecting fifos and regular files
On 1/28/20 9:23 PM, Craig Small wrote: > My personal preference is to lock them down by default, by setting both > to mode 2. FWIW: I agree. Unless massive breakage is expected, the default should be the most secure option. If you default to secure and that breaks something, people will be motivated to fix it (either the root issue or by changing the setting). If you default to compatible, very few people will find the option and tweak it, so most people will lose out on the security. If there is massive breakage, you can back it off, of course. -- Richard signature.asc Description: OpenPGP digital signature
Bug#949979: ITP: talkatu -- GTK+ widgets for instant messaging clients
Package: wnpp Severity: wishlist Owner: Richard Laager * Package name: talkatu Version : 0.1.0-dev Upstream Author : Gary Kramlich * URL : https://bitbucket.org/rw_grim/talkatu/ * License : GPL-2+ Programming Lang: C Description : GTK+ widgets for instant messaging clients Talkatu is a collection of Gtk+ widgets that are useful for chat applications. -- "It was started as a rewrite of the GtkIMHTML widget found in Pidgin, but quickly expanded to include most things related to conversation windows." This is the successor to Pidgin 2's GtkIMHTML widget and is a dependency of Pidgin 3. My intention is to package this for experimental only, until such time as it and Pidgin 3 have stable releases. Having this in experimental will make it easier for people to build Pidgin 3 and will ensure the packaging is ready when Pidgin 3 is. This package will be maintained on Debian Salsa at (not yet created): https://salsa.debian.org/debian/talkatu -- Richard
Bug#949977: ITP: libgnt -- GLib Ncurses Toolkit
Package: wnpp Severity: wishlist Owner: Richard Laager * Package name: libgnt Version : 2.14.0-devel Upstream Author : Pidgin Developers * URL : https://bitbucket.org/pidgin/libgnt/ * License : GPL-2+ Programming Lang: C Description : GLib Ncurses Toolkit GNT is an ncurses toolkit for creating text-mode graphical user interfaces in a fast and easy way. It is based on GLib and ncurses. It was born out of the console-based UI, Finch, for the libpurple project. -- This code is currently part of the Pidgin upstream tarball and thus the pidgin source package, but is being broken out upstream for the next release. Accordingly, I am breaking it out into a new package in Debian. I am working with Ari Pollak, the pidgin package maintainer. My intention is to prepare the package using a development snapshot so that everything is ready in advance for the 2.14.0 releases of libgnt and Pidgin. Given that this is already a stable library and going to be a dependency of the next minor release of Pidgin, I am leaning towards uploading to unstable rather than experimental, but I can be convinced otherwise. This package will be maintained on Debian Salsa at (not yet created): https://salsa.debian.org/debian/libgnt -- Richard
Bug#949978: ITP: gplugin -- GObject based plugin library
Package: wnpp Severity: wishlist Owner: Richard Laager * Package name: gplugin Version : 0.29.0 Upstream Author : Gary Kramlich * URL : https://bitbucket.org/rw_grim/gplugin/ * License : GPL-2+ Programming Lang: C Description : GObject based plugin library GPlugin is a GObject based library that implements a reusable plugin system which supports loading plugins in other languages via loaders. It relies heavily on GObjectIntrospection to expose its API to the other languages. -- This is a dependency of Pidgin 3. My intention is to package this for experimental only, until such time as it and Pidgin 3 have stable releases. Having this in experimental will make it easier for people to build Pidgin 3 and will ensure the packaging is ready when Pidgin 3 is. This package will be maintained on Debian Salsa at (not yet created): https://salsa.debian.org/debian/gplugin -- Richard
Re: https://tracker.debian.org/pkg/dballe
On 1/17/20 6:55 AM, Sam Hartman wrote: >> "Johannes" == Johannes Schauer writes: > > Johannes> or have a mechanism that allows maintainers to tell buildds > "please build this > Johannes> source package with build profiles X and Y enabled". That would > then build the > Johannes> binary packages necessary to do a full build in a second upload. > > That doesn't help. > > If I need version y+3 of rustcc to build y+5 of rustcc and only y is in > the archive, no build profile is going to help me. If I'm following correctly: The packager would use rustcc >= y+3 (in practice, likely rustcc y+5) to locally build rustcc y+5 and then do a binary upload. But if dak (or whatever, I'm not so familiar with the server side here) throws away the binary, then we're sunk. So there needs to be a way to note that the binary needs to be kept. Assuming I'm on the right track, here are a couple of questions: In such a case, would the source package have a Build-Depends of >= y+3? It seems like it would. Could that be the way to indicate a bootstrap upload? In other words, if the package has a Build-Depends on one of the binary packages it produces that is _not_ satisfied in the suite it's being uploaded to but is satisfied by this upload, then it's a bootstrap upload, and the binaries should be kept. This would avoiding adding a new field for this and would ensure the Build-Depends are set correctly in bootstrapping scenarios. Regardless of how the "keep the binaries" flag is implemented... should the uploaded binary be published, or should the package be rebuilt? I think I'd argue for the latter. The uploaded binary package should be installed on the buildd and then the package should be rebuilt from source, with _that_ result being put into the archive. This doesn't protect against the trojaned-compiler problem, but it does at least ensure that the package builds from source. -- Richard signature.asc Description: OpenPGP digital signature
Accepted up-imapproxy 1.2.8~svn20171105-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 12 Jan 2020 21:22:54 -0600 Source: up-imapproxy Architecture: source Version: 1.2.8~svn20171105-2 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Changes: up-imapproxy (1.2.8~svn20171105-2) unstable; urgency=medium . * Move from GitHub to Salsa * Set Rules-Requires-Root: no * Run wrap-and-sort -at * Convert to machine-readable debian/copyright * Add upstream metadata * Use Standard-Version 4.4.1 and modern debian/rules * Switch to debhelper-compat 12 * Convert debian/prepare-config-file to a patch * Make debian/upstream/signing-key.asc minimal Checksums-Sha1: 47fb9ad8b842dc03772f7435113b770c27ea2d67 2094 up-imapproxy_1.2.8~svn20171105-2.dsc a27f1133cefc92327ae73d4e4325ae1198c96523 29040 up-imapproxy_1.2.8~svn20171105-2.debian.tar.xz 9113c1d2d00a07dc2fd13625b37778a2d0902d4f 5930 up-imapproxy_1.2.8~svn20171105-2_source.buildinfo Checksums-Sha256: ac8bc20f970c0a0bcb7372475050f192399490c575018767f6faa19d519b7193 2094 up-imapproxy_1.2.8~svn20171105-2.dsc 90dd3eef66fd3e355f285f4bc30ba5526d0903d23e04a0549027d97bebba796e 29040 up-imapproxy_1.2.8~svn20171105-2.debian.tar.xz 4be2536b0a2418891b0651c40a925d54afbe88b8f0e5f7501cc207d7f537c633 5930 up-imapproxy_1.2.8~svn20171105-2_source.buildinfo Files: 3859f282fb4dbb7c3e466fc7fd69de18 2094 mail optional up-imapproxy_1.2.8~svn20171105-2.dsc f3afa4791e2a76867e43de7e684fc19c 29040 mail optional up-imapproxy_1.2.8~svn20171105-2.debian.tar.xz c83ad98669169e81470ca7899fef0e36 5930 mail optional up-imapproxy_1.2.8~svn20171105-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAl4b7JQACgkQ+HlhmcBF hs5eAxAAoKCg77Y4Pf2XXdPyQr8NwNUozabal509BidK9GBH8eeZIora+BK0oi/N e9e6yIQE4Yu+UxsIiisNeAXa/CReRQwEk7CDkNQw90JpYUGnXhdLmrt71YJjkq9H /SLqy77cWaiq4+wVISe7DhodcrESLDgo8eKot8UhUmhztd60xCkjQ51lutommkKo sRFUlF9b/mMTvdfGYwLqqdjK0EpGBeu4aKa6a6j4IvwCxt9hRK3R7c9X4HSrqLH7 agtMXMgNUGTSRx/pYHSGdnnmqgAWyn0Jp1y/UAn8Iy3Gkvqutt2VbxkSjPRdgWBc /Qet6uwQZtysTgXx+n2U42xUuEMjjJs+g+vdYR/rh1DgiS3T2n8OsySMWUwYSlrv BP7RBe5fkAbL0EX9XWCSE8A/Urzqrud9+2iQULsfhg09ZiIpsLkoIs4EJ7LmsWeb 0VafJ5fGZ9VVIp3dtkzX2tdpX6enz5bJRCbhac7LVKiRUwizYBo/UfM7jCQZ8PfV NFV45RtUZnUiP0dKiWBVZhYcTn/qCV8F7MgnRg75e5mzKB4avhVSQGSoBgNt2Vj3 jtn8EPXQbruuoXHHtz2cOx4hdQJBKYybsdvU9tHdmyrQjNGFWQyC8LZUAnQlM3sX ACHurZ2rZjnYYgs/MejJX9V003woNt/GFefw6t0RoKFrHxGLQT0= =ZjsK -END PGP SIGNATURE-
Accepted gbonds 2.0.3-14 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 12 Jan 2020 21:18:06 -0600 Source: gbonds Architecture: source Version: 2.0.3-14 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Changes: gbonds (2.0.3-14) unstable; urgency=medium . * Resync man page text from debian/control * Update copyright year to 2020 * Add Yavor Doganov to debian/copyright * Add upstream metadata * Add redemption data through 05/2020 (sb201912.asc) Checksums-Sha1: 3c8fa3188b4184b152387d57eaae5d1569798dfa 1992 gbonds_2.0.3-14.dsc 3b0f178b5ae823beb03abc815785f6ed79ffad57 93708 gbonds_2.0.3-14.debian.tar.xz dcc4c29bcafd590f74c0b425f8347a1779ae 14443 gbonds_2.0.3-14_source.buildinfo Checksums-Sha256: 5930d0c8c7db12754ae29cac5a5d83be4dda85b314c5bb1c7b64cfca0d7c21ef 1992 gbonds_2.0.3-14.dsc d09136d563353f7c2e69261d1461b1bd1f6749e57d15e7ff6145cf5a1f8bf1f0 93708 gbonds_2.0.3-14.debian.tar.xz f3e9e3c7c536691de6ab1fd64d9dba3de5c266761b564d5126e3872133cd0f1d 14443 gbonds_2.0.3-14_source.buildinfo Files: 6471c4e0f83d4a4f0aee7feb7dbea8d2 1992 gnome optional gbonds_2.0.3-14.dsc dfd1f7b2e8b9032ef84e9aa527dcfecb 93708 gnome optional gbonds_2.0.3-14.debian.tar.xz 9a3934c4749b8f77195f430902ad2bc4 14443 gnome optional gbonds_2.0.3-14_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAl4b4ioACgkQ+HlhmcBF hs7ifA//UKYZ6KSUFQrBwT7UTvbWk3omqDUuHyzm1EEGF8d8chgBWt9L1iFDuhdq KfwoclPkIViXb+KtlOQYvS9jjE8m5hvAY7+5TQleUq3mwVHy+38otuGMRQeUm/o0 tP4M7n0a2+blJ8s+mTt/GwFckOIL56uJ9nSjPm3dUveXivkYuQOjUGGlEcyficAu fcFN0jXt4s+nrKjShRHy4zX6s5GWe0ZZnqLprzB3IbHfJW1jQuiGBLkcxrW4HsrN ZeVAkOzStZeJUP+Rt+2SqDl5zDT3yOUnF3GEV3CfQmqwWzeTOYp1KMHUsOy7YZwl i0ZeAcL6/T5Basl1tJvJ2GK0nILorOmrhryVdcXeOKadQgmUItFIshxJk2nlwxSp BgMZeSZ+tgdT1SmHFYJtT+7aZ1FU2WsmVgS/YrPUZEsvIJVJY68qy7Vs9bY1DOd1 nis3l29acItsWLAcOm8FBzXfEsQ666BfKPa6sMMgcBUzx68HHibca8iufOm5UUQn LvOkJGU2lCagGwTGzKg32AuR3iJGnUh1zCthIBToL3f0icintXtAqSeA69zaBlE2 4gni2vRg1MbZmaxlLkMHXQ4/JmM5+7OgU1JpNhK1FmuII4bVkAWZnlai/I7RK7Yj b2dYh40mVU6PulD9NHfpHziJdyrGToapXV/JEqy/flUHrLSxDaw= =JY66 -END PGP SIGNATURE-
Accepted gbonds 2.0.3-13 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 11 Jan 2020 23:59:20 -0600 Source: gbonds Architecture: source Version: 2.0.3-13 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Closes: 943342 Changes: gbonds (2.0.3-13) unstable; urgency=medium . [ Richard Laager ] * Move packaging from GitHub to Salsa * Update package description * Run wrap-and-sort -at * Bump Standards-Version (no changes) * Set Rules-Requires-Root: no * Suppress lintian false positive * Bump debhelper compat to 12 * Drop libgconf2-dev B-D (Closes: 943342) Thanks: Yavor Doganov * Add debian/README.source . [ Yavor Doganov ] * Remove GConf migration code Checksums-Sha1: 8ffedef3b6e4a8c8b830c7dabcd80a2897d9963b 1992 gbonds_2.0.3-13.dsc 4cc4d3e797b8862838f41871bf0e193cd84db9ec 1165574 gbonds_2.0.3.orig.tar.gz 7fb8864e452a904f7d2134da97c5b17e2a7db8bf 89408 gbonds_2.0.3-13.debian.tar.xz 25a2f0db43971344e2fd36542b56f68f38008416 14443 gbonds_2.0.3-13_source.buildinfo Checksums-Sha256: f0e68355543c305a984909b353596eb43cf17513a1a59010d4700a35cf9f0743 1992 gbonds_2.0.3-13.dsc 0b07a82ed198553dcfdf5ac011087ee3cf1070f59a7eb48d7afd0b97c606dc0c 1165574 gbonds_2.0.3.orig.tar.gz 7b70476a7f024d8cc3cf01e531f39275cf9b44d5d55f9410c7d01a52c1800fdc 89408 gbonds_2.0.3-13.debian.tar.xz 7a41007d1c8f7cc2cb6f0a09e51e0024be27efbf78b8384cb40bab25aa46c7ee 14443 gbonds_2.0.3-13_source.buildinfo Files: 0c54336dad30d2d129186f2424772331 1992 gnome optional gbonds_2.0.3-13.dsc 4d9b9d7065fa3d013f21edefc10cb27a 1165574 gnome optional gbonds_2.0.3.orig.tar.gz c60a14f0950bd9f9a27d0ef365fc76cf 89408 gnome optional gbonds_2.0.3-13.debian.tar.xz 34bf2df1e7939a8aad5d1530200a7c51 14443 gnome optional gbonds_2.0.3-13_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAl4athEACgkQ+HlhmcBF hs5kgQ//WXP0U87FF0G5E3d4NMp7jECAz2hqiSGuXp1R2+/v+aX6w0umX99AK6MX 4Bn4VeJpW+bHzxKv6LBvaVz7/Q6nOmzV3lXe0fgN/jQ5rzqzBrAiS0QlEJCgohnY HXq6ikQlTTP1suJo5PtWJI7IOmKiMvG4OKBAgIeBCnuGwUBjsl/9SqlrtJ6QY5rt jDHVxWjdNsqqNCS4tptzo28ipbPe6W5txPy/76j04oQeNJq+wLL1dio+bfuoEmjE zL4l5y+NouiMAYsXu/jGg8csl03MPg4JtA0DYkZeZKEtAJzBacepR7aoO8LuUwDa 0/kU8bHRNnNyoMbdyx891Jxe+PuHULF4yaL2XiJiaTmYtBhrpMIh9c/4BFYLQYJy UFOSs41F3/83jB3lqTHVaBqwyn57bYX/ila6VVW68Qc+0ws9pmf3fNC1DrH/yhLj ruWz5t+egLnNjh7egAPt8x8VGN33/30VsmU7w0mJt+nk6Gr/Uv1QDApxC02oRJ07 0KcL5XnZp9xY9cPfw8S4LtAIbzQsjH0FbYYMaPgufaFUnsf+61mYB7YMvpMF5cch nAa9Rk2LZX3r3zJfIhbwl5nIt+YJifiuqB94FTNUpAsPZ34q93daHzhh6KCJMZR9 Xxf+TgMGoOy0j1XaodSWSvkwSwILGeJj+GlzBY2Cfd6AFRfrSL0= =NhdL -END PGP SIGNATURE-
Re: migration from cron.daily to systemd timers
On 1/8/20 1:02 PM, Michael Stone wrote: > As a third party with no particular ax to grind on this, I do wonder > what the advantage is to adding another mechanism for this particular > use case, given the need to somehow handle upgrades involving an > existing (presumably working?) solution. At my work, we recently converted all our cron jobs to system units (service and timer pairs). We see the following advantages: You can use systemd's dependencies. This allows you to do things like automatically stop a related scheduled task if its service is manually stopped (e.g. for maintenance). This can keep the scheduled task from interfering with your work (e.g. a watchdog script restarting the "dead" service) and/or throwing errors (because the service isn't running). In the latter case, that might mean that you avoid needing to suppress errors because of this normal occurrence, which means you aren't suppressing real errors. The service unit can be started manually. This makes it a lot easier to debug/develop with systemd than cron (where you have to manually change it to run at the next minute and wait). Obviously, you can still run the scripts directly, but sometimes the problem you're working on only manifests when it is run under cron/systemd (e.g. because of different environment variables being missing or different [1]). The timer units can be randomized over arbitrarily sized windows, customized per service. This avoids load peaks, e.g. at cron.daily time. Your scripts can write non-error debug/status information to stdout without it resulting in an email. This info shows up in the logs, which can be convenient. [4] Obviously, one can use logger(1) or syslog, depending on programming language, but for trivial in-house scripts, it's hard to beat the simplicity of just printing to stdout. Yesterday, we implemented a new script that uses a web API where you request an action and then poll until it completes. We wanted a timeout. With systemd, since the service is Type=oneshot, we can just set TimeoutStartSec= and we're done. This will kill the script if it hangs for any reason at any step. We obviously could have implemented a timeout in the script for that particular step, or in general, but this was simpler. For new/junior sysadmins, there is more overlap. Everything they learn about systemd services applies to both scheduled tasks and those that start at boot. That's not to say that cron is harder to learn, just that it's another thing. Recent versions of systemd have an analyze option to show you the next iteration(s) of a calendar specification. This makes it easy to verify that your calendar syntax is firing at the right times, and you haven't mixed up hours/minutes/seconds, etc. It will also show you the normalized form (which we prefer to use to avoid confusing humans). Some examples from my history: systemd-analyze calendar --iterations=5 'Mon..Fri 01:50' systemd-analyze calendar --iterations=5 '*:0/5' systemd-analyze calendar --iterations=5 '*:27,57' We do lose the automatic cron emails, which some would see as a downside, though there are ways to get them on a service-by-service basis. [2] [3] In our particular case, anything that is _expected_ to send an email was already doing so manually (i.e. calling mail(1)) for other integration reasons. In our particular case, though, using systemd units was preferable from an alerting perspective, as we already have an Icinga check that runs `systemctl list-units --failed` and alerts if any service (scheduled or daemon style) has failed for any reason. The systemd units are "fluffier" (more lines and more characters of overhead) than crontabs, but that's not a true increase in complexity. All told, with this change, it feels like things are a bit simpler and easier to work on while achieving a bit better results. It's a modest "quality of life" improvement. This is _not_ my blog, but I read it regularly and comment periodically: [1] https://utcc.utoronto.ca/~cks/space/blog/linux/SortCronLocaleDanger [2] https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimersAndErrors [3] https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimersMailNotes This one quotes my comment on article [2]: [4] https://utcc.utoronto.ca/~cks/space/blog/sysadmin/NotificationsVersusLogs -- Richard signature.asc Description: OpenPGP digital signature
Re: migration from cron.daily to systemd timers
On 1/8/20 4:25 PM, Josh Triplett wrote: > (I would suggest doing the same for the cron job, for new installations: > put the script itself in /usr/lib/spamassassin or similar, and document > that people can enable it by either enabling the systemd timer, linking > the script from cron.daily, or copying the script to cron.daily if they > really want to modify it.) It seems like this would work well. That's better than my previous proposal and the current commit, as it doesn't result in a cron.daily script starting just to exit. It looks like the existing commit uses /usr/sbin/spamassassin-maint, so I'll use that instead for the example. I personally wouldn't put this script in the PATH, but that's a separate issue. The migration would then look something like this: [ -e /etc/default/spamassassin ] && . /etc/default/spamassassin if ! [ -L /etc/cron.daily/spamassassin ] && ! TODO_check_for_local_changes ; then if [ "$CRON" = "1" ] ; then if [ -d /run/systemd/system ]; then systemctl enable spamassassin-daily-maintenance.timer rm -f /etc/cron.daily/spamassassin else ln -sf /usr/sbin/spamassassin-maint \ /etc/cron.daily/spamassassin fi else rm -f /etc/cron.daily/spamassassin fi fi So, if the user changed it, just leave everything alone. If they didn't change it and aren't using it, remove it. If they didn't change it but are using it, replace it with a symlink or a systemd unit, depending on whether systemd is in use. This covers everything except the case of: they're using it, but did not modify it, and are using systemd, but don't want systemd timers. In that case, the user would have to disable the systemd timer and add the symlink. I'd mention this in the NEWS. With this proposeal, the maintenance script should also stop checking CRON= (or for the systemd timer), and CRON= should be removed from /etc/default/spamassassin (though that needs to be done AFTER the check above fires). -- Richard signature.asc Description: OpenPGP digital signature
Re: migration from cron.daily to systemd timers
On 1/7/20 3:18 PM, Noah Meyerhans wrote: > Current the cron.daily script is a no-op by default, and functionality > is enabled by setting CRON=1 in /etc/default/spamassassin. For users > running systemd, I'd expect to ship a timer unit that is disabled by > default, and have them enable it with: > > $ systemctl enable spamassassin-daily-maintenance.timer This seems correct. It is the systemd native way to do it. > For upgrades from versions that did not include the timer, should I > enable the systemd timer if the user has set CRON=1? Or should I leave > the timer disabled and preserve the original behavior via cron.daily? > Since the cron script is a conffile, and may have local modifications, I > think it should be left in place, but would take confirmation. It'd be > possible to perform the migration while still preserving local > modifications, e.g. by having the shipped cron script enable the unit > file, but IMO that would be gross. Could you check for local modifications and only enable the timer if there were NOT local modifications? [ -e /etc/default/spamassassin ] && . /etc/default/spamassassin if [ -d /run/systemd/system ] && [ "$CRON" = "1" ] && ! some_check_for_local_modifications then systemctl enable spamassassin-daily-maintenance.timer fi > If the timer and the cron activity are both enabled, the cron script > will be a no-op. This is accomplished with the following in the cron > script: > > if command -v systemctl > /dev/null 2>&1 && >systemctl is-enabled spamassassin-daily-maintenance.timer; then > exit 0 > fi > > Would you do this a different way? If it was me, I'd just check for whether systemd is running (e.g. [ -d /run/systemd/system ]), not whether the timer unit is enabled. That way, at least moving forward, you're only supporting two scenarios (systemd uses the units, non-systemd uses cron) rather than three (those two plus the option of systemd systems still using cron). If you were doing this new, I would suggest that you use cron.d instead of cron.daily. Then check for systemd by prefixing your command with: [ -d /run/systemd/system ] || ... This way, if the user installs systemd-cron (which replaces crond and generates systemd service & timer units from cron files), it will not generate units for the cron job. See: https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator.py#L335 Unfortunately, there is currently no equivalent for /etc/cron.daily, as systemd-cron just runs run-parts. It does not convert each cron.daily script into a separate service. I filed a feature request for that back in 2016, and it's gotten another look recently. I may have some time to work on it again this year and propose a patch if nobody beats me to it: https://github.com/systemd-cron/systemd-cron/issues/47 If you wanted, you could migrate from /etc/cron.daily to /etc/cron.d and then apply this approach, but you'd still have the "local modifications" problem. If you are willing to drop support for direct local modifications, then you could use cron.d and disable the script in cron.daily. This would give you the simplest solution moving forward, but would require explicit action from anyone who had customized the cron.daily script. -- Richard signature.asc Description: OpenPGP digital signature
Accepted ntpsec 1.1.8+dfsg1-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 29 Dec 2019 00:22:24 -0600 Source: ntpsec Architecture: source Version: 1.1.8+dfsg1-4 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Changes: ntpsec (1.1.8+dfsg1-4) unstable; urgency=medium . * Switch to python3-gps * Fix asciidoc version check (and FTBFS) Checksums-Sha1: ac0937bfcc7e9ca0c80d5943ed88245374911b0e 2420 ntpsec_1.1.8+dfsg1-4.dsc 9bc0fb723ae2834b26dc8e9d084f3384eb00d1ce 56800 ntpsec_1.1.8+dfsg1-4.debian.tar.xz 28e3d764a308ae1c477dedc3f6a19754e48276d4 7932 ntpsec_1.1.8+dfsg1-4_source.buildinfo Checksums-Sha256: 3a32ca572743e31bfb13e4789720606bdfe7b2fbf448e109f122448b68a9c668 2420 ntpsec_1.1.8+dfsg1-4.dsc 516c4d1dcaed4d0df87ceb2b1eb7734adfb1d96ea419add2df654fdd62d2e521 56800 ntpsec_1.1.8+dfsg1-4.debian.tar.xz 24ff8cd30524bda8605f3b4d788205fafab15121e269d3392e121d4b38dc90c8 7932 ntpsec_1.1.8+dfsg1-4_source.buildinfo Files: 4e49f35929013caea186f2a8b3efc422 2420 net optional ntpsec_1.1.8+dfsg1-4.dsc 12c7467c05e1b81bff3b9e1000c4fb76 56800 net optional ntpsec_1.1.8+dfsg1-4.debian.tar.xz 658528521ddc80e45702fa56ded0bd81 7932 net optional ntpsec_1.1.8+dfsg1-4_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAl4IRmcACgkQ+HlhmcBF hs7e+g//WLDOu63hT52SMQ47wn4fqaio/Y6yihRS85VrtO+TudNfd2f9yyTggvm3 JG0oTBGPyySBhQhXR2yf2mDFv6kr7ObdDMPsXIAGmyW13vtdFUeqMsSW5gUn3nLJ a4oGiVrb94pRN1onmsJMNDBv6d7Llbcz1dg7umwDk+Yf2YRWGYAR4ZcMfXi7zuOH 0nw+b/CoH+gLVYOMN4sNCX9U78tZx2DcBqDip2xc5BeR3lmIHy/uTRNd2U05dJcp OSCwO6n/9rJI0T0Ax6Qh2NJUG+iiIPEAF4cE7797xrZBOBko9aZigyN/i65LuOXj ouzEsHwBiid/HphI/uMwiyaUKrIn+YQCis5373AAlM6kXlQsCUXVcgb5pg49Huww mPBPRbOnhlgq80Re6JvrtZ8tBjPB4JmxbMe2tzlfqaBMX8J/iBccoy7kTocXPB73 XLa+G9zQ5twn6lsdtL9oe3ta1t+zvzXdgymYa5GFL4VOnGQ8PIkImSKzISrC149H rvLzram5BhYj151bNsnkr7Upr0GV9NTdudmJIDqymsm/JueO8mRhY197GGiKfdIg TOeH5aY/mbBeGEZYmjutgSLUJ7fy+TnN+TrOJRr2FWhTZAAVotNLU0TlXoNR2ElS 1+T6B5RWxNaXWKRp+rE9rYjifb3U3wwWismsrrAJ9abzv7UCI0Y= =OBv9 -END PGP SIGNATURE-
Re: watch files and .gitattributes export-ignore
On 12/12/19 2:48 AM, Jean-Michel Vourgère wrote: > Upstream of phppgadmin has nice unit tests in its github.com repository, but > they use a .gitattributes file [1] to strip these tests files from the > distributed tar files: All the unit tests are missing from the orig.tar. Have you asked upstream to ship the tests in the tarball? -- Richard signature.asc Description: OpenPGP digital signature
Accepted ntpsec 1.1.8+dfsg1-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 05 Dec 2019 21:53:36 -0600 Source: ntpsec Architecture: source Version: 1.1.8+dfsg1-3 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Changes: ntpsec (1.1.8+dfsg1-3) unstable; urgency=medium . * Backport fixes to NTS logging * Backport a fix for clock fuzz errors Checksums-Sha1: 78bf49abf872378ef1b3da69ead7d48e924e23a6 2436 ntpsec_1.1.8+dfsg1-3.dsc 4497320c853a64e2f286e2d04b71c79fa56269a9 56312 ntpsec_1.1.8+dfsg1-3.debian.tar.xz 1ad5becf45f9f80a8de8b3c92b18e1867626ff5c 9549 ntpsec_1.1.8+dfsg1-3_amd64.buildinfo Checksums-Sha256: 5392f0fa9e6927c6de240955734bcf100221eee1731d2f3c4cecec8ed81d94f6 2436 ntpsec_1.1.8+dfsg1-3.dsc 16d768733b3e4f60f8180887556ddfec3908bda0894c4021ec52d1b6a00a8fa8 56312 ntpsec_1.1.8+dfsg1-3.debian.tar.xz 437600925dc1048d002f9e07ab85b9668229805cf2a0d15cc74ff5b7bfd2b936 9549 ntpsec_1.1.8+dfsg1-3_amd64.buildinfo Files: 3f4967b11609f8244f643d50b68dca70 2436 net optional ntpsec_1.1.8+dfsg1-3.dsc 66e28c2700f2e69adb52877630b54f83 56312 net optional ntpsec_1.1.8+dfsg1-3.debian.tar.xz a0e094948ea281664d8857746e038838 9549 net optional ntpsec_1.1.8+dfsg1-3_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAl3qZyMUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpag5A//dj2tM9DHjR7gAefn8cKyOC+rMTvx u1MvFvrUwJ1mPlXXRb2wrjJK5NLjLZC8abi7N1JdQP0aZj6BXwBKkGEcpsEwW8um +YqqxqXm9UnOrtEwJQdhWB7s31w79VK8Nzek8vCkjyQOMkn7H8Xo+3uFzsQ3FbW9 ZT5QIKjo76+grkUrWUVmNo28hNEVIKwFZiNxNuLhrKSvVbHyf09H2q6gCPLo9Pgl yN0T9565u+fN6eEVVjPk2iIeK8rX3W2sfnmE/fEOfGVFCWKn9psZqvSuBJnuf3Uc bn8bBUqqB++xaL9QG0Mm41Gd0Jr1OAjL7UetuAdspiI8h8//onF+/gkHQLQrMqnB zgACSvRxGpACS+tAmLiNWCEBxfUqWRoXYSRMhwOaGjLLTSpBxblC2QRbtXiFTqLR xsga+K83YjLlDAHYpHDREvQOXtTVUwWTEeW9Fk/a+6OObwizott5zZgeKMxdkYOA MFwGpoQUdGSHpZyuwu6SURo7GRUPQsDx+wH5Ud4lumyS6RVkRthanyc+If+Q5D/9 QkhOs6O5pIkovhzkKaKfP7VA44efqTrO0xFqJP/mkpMsv0Z4gfE4FOrJz6opkinv WT4wDWtipuxg+zFTBvjWc1d43O1QF2LC3lT2mfjUngfRnj5YqX5Y87k1oaX5mnRZ Z1M6K+FX7O2z9JY= =gPJJ -END PGP SIGNATURE-
Accepted ntpsec 1.1.8+dfsg1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 05 Dec 2019 00:04:11 -0600 Source: ntpsec Architecture: source Version: 1.1.8+dfsg1-2 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Closes: 945754 Changes: ntpsec (1.1.8+dfsg1-2) unstable; urgency=medium . * Changes as of ntp_4.2.8p12+dfsg-3 have been merged as appropriate: - rotate-stats: Limit to specific filename patterns. Thanks to Bernhard Schmidt with changes for NTPsec by: Richard Laager - AppArmor: fix path to Samba NTP signing socket. Thanks to Bernhard Schmidt * Patch out a docs reference to /var/db * Update quick.adoc to use /var/log/ntpsec * Add default cert & key files to apparmor policy * Update the Ubuntu example in quick.adoc * Fix some mentions of the "ntp" user * Use /var/lib/ntpsec for driftfile * Move ntp.keys to /etc/ntpsec (Closes: 945754) * Use /etc/ntpsec in the code and docs * Cleanup the ntpleapfetch documentation * Workaround ntpconf failed expansion * Add an ntp.keys HOWTO to README.Debian * Do not install panda.adoc * Remove the ancient SMP notes from README.Debian * Remove the ancient hwclock notes from README.Debian * Reorder README.Debian * Require python3-ntp version to match Checksums-Sha1: 59d58cfc41dcb14018d904d54034d0d524ebd309 2436 ntpsec_1.1.8+dfsg1-2.dsc 995640df290456fa0613e76e441b598ab86af807 52116 ntpsec_1.1.8+dfsg1-2.debian.tar.xz dccd0008d03f35b52fc6137e08536fd041c373b3 9549 ntpsec_1.1.8+dfsg1-2_amd64.buildinfo Checksums-Sha256: 0c77f5a7509c98d34aa127a29eabac0f07ad561149c9ceca6dad1b97db7cf68a 2436 ntpsec_1.1.8+dfsg1-2.dsc ac0af9c15e788ef7b07069388a5c3cc3a2246b44b50f0a8943777ba06a338b4d 52116 ntpsec_1.1.8+dfsg1-2.debian.tar.xz 15f788e27fc967b64e77a3280c9e344073c415fe1db57a2ee2a8525e6c159ce0 9549 ntpsec_1.1.8+dfsg1-2_amd64.buildinfo Files: 1490faa103a0b9dc48bc765f7d6b889f 2436 net optional ntpsec_1.1.8+dfsg1-2.dsc 317c9612dfba68cd78fc2494166a6e95 52116 net optional ntpsec_1.1.8+dfsg1-2.debian.tar.xz 4adaaf63ec6a7c75c54863edb1d91df3 9549 net optional ntpsec_1.1.8+dfsg1-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAl3pzDQUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpaGDRAAgDNU6wnRgqfVNCj6OQFbsXWaqrKY foDv/yYvkCi+WnxFnXn+7BE3NF0Z0YojHcl/84e4U2Uy0FAludElneHieCp6j/mL 6G6rlr+e8j7KWaklSKE6fBj7MOfs2yoOvGaOoe6NXx7nZwUbG88Np5Mk8By2Y6cP Nd2IHT6Xb6uh8zrKraTQCpd0kl9m26XeRfGsAnXQIW1owGLo2DR0W0Og1A6mzTFo NOWJ2ZRoDhYW20I+dijF0tLxqSLczyOvMeAjpYgIjCxo3YTSOkVxW4bPOyajfb/q femUiMQxNjSB+omFgAOqq0bVnSPUnrdW1pxBvtB8HVKmDHJISgIKiyOyskssDEMr rCjDtWfV/DCoU4w2FGPWsbyte2B3Q+/yBYOFY+t5XiEHsuGll4NYFpxDiMCPFNRL okeA32Zuzrv+y1CdpTUlJ9xTCmA4wuS6wtxOOQxFk1tW2JkDpT+xkEBT2V4RvSlN /HuNL4btoRWWIwusigVn6/9it0WeKcKzLc1DqLMqn0unQZVmOznceKyqjkKz30XM 54mjV7nOOzCbWW5Kr5GdHoFo1JfOELwSbi0bmMLaaKKLCyb+6+mL0cnP6QX3p4Vv XPhcFprwbcwKfn1fCWWc+GxM4O545+uDAqxDEllbY8Y8LSPGTDht/P6q5GZy2mqx Lswami6n4fpPtXw= =Lrry -END PGP SIGNATURE-
Re: Namespaces for Lintian Tags
On 11/20/19 3:01 PM, Sean Whitton wrote: > For example, I would request obsolete-national-encoding@debian/copyright > rather than national-encoding@debian/copyright. Or perhaps obsolete-encoding@? -- Richard signature.asc Description: OpenPGP digital signature
Accepted ntpsec 1.1.8+dfsg1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Nov 2019 23:30:18 -0600 Source: ntpsec Architecture: source Version: 1.1.8+dfsg1-1 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Changes: ntpsec (1.1.8+dfsg1-1) unstable; urgency=medium . * New upstream version - Fix/tweak several NTS logging messages - Make ntpq -c :config work - Fix potential buffer overrun in nts_client.c ALPN checking - Fix broken variable substitutions in documentation - Add OpenSSL version logging - Use the -4/-6 flag for both NTS-KE lookup and NTP lookup - Repair ugly crash from NTS client if broken ca filename - Fix logging hostname/null bug in dns_probe * Drop two patches (merged upstream) * Refresh Debian-specific patches * Add upstream metadata (DEP-12 / UMEGAYA) * Remove lintian ...install-key overrides * Remove debian/compat * Update git branch structure to follow DEP-14 * Document the use of "unapplied" patch format * Remove __pycache__ directories when repacking * Update repack-waf for uscan version 4 * Rework debian/README.source * Make debian/repack-waf shellcheck-clean * Remove an old bug note not applicable on Debian Checksums-Sha1: 8b577722479b2f14b873e2f020160f686587ab9c 2435 ntpsec_1.1.8+dfsg1-1.dsc 6d98234751119024fbb63bdb9861fb509d26a2e8 2620698 ntpsec_1.1.8+dfsg1.orig.tar.gz fc71fb3f1ebe51150440b8ae3c1796755492f3b6 46984 ntpsec_1.1.8+dfsg1-1.debian.tar.xz 265bacd537f5a9e236e5f5c1c00f01ad883799ea 9578 ntpsec_1.1.8+dfsg1-1_amd64.buildinfo Checksums-Sha256: 80f68e149a68085ab43ead036520b0b89adeead4d2c933883806e9ad7d2c522a 2435 ntpsec_1.1.8+dfsg1-1.dsc b3e882de7b7d333f4da6b987484f2e5326289d6b25f48f40e3ff7ea8e291e0b6 2620698 ntpsec_1.1.8+dfsg1.orig.tar.gz 11035ffcb35b3c1b6cf74aeec9783e8551467a9c34d0983b28e356abd0967682 46984 ntpsec_1.1.8+dfsg1-1.debian.tar.xz a7e4989b9a2bdd0a8ee52b198e4663809bd36afb2aaa8fa90d89b7ee6160022e 9578 ntpsec_1.1.8+dfsg1-1_amd64.buildinfo Files: 8bfd30e2656de9b15b0d0c593212b25e 2435 net optional ntpsec_1.1.8+dfsg1-1.dsc 4715078d0d62000f344fc602730a860f 2620698 net optional ntpsec_1.1.8+dfsg1.orig.tar.gz a05de7871d2c7334f9388796e592e880 46984 net optional ntpsec_1.1.8+dfsg1-1.debian.tar.xz 03ddec5290f70f0b977cb015a27abf52 9578 net optional ntpsec_1.1.8+dfsg1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAl3TQiwUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpbHHRAAgfJ5TIZc2bo9ULanN28uUBvmJmEZ 3jVYUiuJl21STdqxDgySX40QlSamnQP6AR7RmRiKLJl18rwAQX8x3VpgoLaRpWWV nLaLHkr+oB+NqH6xroYh9r7srqLiqhmeHdWBcV+fbAbJIhRMK8ZTLTHN+M0G85yR T//R8n5MlRAmiNKh1GY9w3nLByWYoRCbX91eAYjtNXhpfWWNPAuw+ib4Q1QuAjEU OSXg7CLkDivpfRwygcvpiWu6RYRyl6+umUQOC/4EP7ezlsg6qReJZPoFp0sU4Ikm d7YqcURLOuFxw3kXXa3RcSqh9oBNot+ZWz1xygkE1AJrpW+kG7sFYxLYMlB5QVOw 5wPs21djzciMgFqjs3wBdhUzyRTWNhhSiWRNORdhohba2L6uPV+KXuYcD0SrwKVF 1E0KtPQAIj0ydbjCWFs3+bL4A4mEzaauLPCp948uQIk0Fvnl7B9xMlJR4goIwjtu MVdpcEdyFZ9LUanUWt61guW4ypXJmJp7n7dpheor9HVTEbZ4i3X/fHSj255I7m4W njqK1Kr+Aq4IpDc6aWw3l/3cAr1W+saVK55szc1LGpgTqvOu5Y5TqbopmiLzZJTy JUii2+9EOlc5j1LjgLtDUnG2f8aX79+g34rCSk/g/O/8pumuLrhc2s0nFXMiZMjH MW5I28qCZqXCuZc= =PjKZ -END PGP SIGNATURE-
Re: Usage of DEP5
On 11/7/19 7:40 AM, Thorsten Glaser wrote: > I also often deal in software which > has more… flexibility than the DEP 5 format allows, or where it is > plain simpler. Would you be willing to share an example, at a minimum just the name of the package? -- Richard
Git Branch Names / DEP-14 (Was: Re: Summary: Git Packaging Round 2 [comments by 11/05/2019])
On 11/5/19 9:51 PM, Nicholas D Steeves wrote: > Richard Laager writes: >> I'd love to see more information about a recommended branch >> structure. FWIW, I've been using branches named for each release >> (e.g. "sid" is the default, but I also have "buster" for a (proposed) >> stable update, will likely soon have "buster-backports"). This works >> really well, and also scales to also having branches for Ubuntu >> (e.g. I have "bionic" and "cosmic" too due to some SRUs). It also >> keeps "master" available for the upstream master branch. This seems so >> obvious and wonderful to me, but I'm not sure how popular it is. As I moved my first package to Salsa and was rethinking everything, I switched from "sid" to "unstable", for reasons that will come up below. > https://dep-team.pages.debian.net/deps/dep14 > > It sounds like you're already using something similar :-) I had forgotten about DEP-14 until it was mentioned earlier today by Feri . I'll likely rename my branches again to add the debian/ prefix, to be in compliance with DEP-14. DEP-14 specifies three options for development releases: debian/master (the recommended default) debian/sid debian/unstable Having three names increases inconsistency between packages, which seems to me contrary to the goal of DEP-14. If someone is working with both unstable and experimental, then they must use two branches to differentiate them. DEP-14 says to do so with debian/experimental for experimental. So far, so good. For unstable, DEP-14 says to use debian/sid or debian/unstable. Why not A) pick *one* of those, and B) always use it, never using debian/master? As for _which_ one (debian/sid or debian/unstable)... The DEP-14 recommended branch names for stable release are debian/CODENAME. The recommended branch name for experimental is debian/experimental. These, plus debian/unstable, but not debian/master or debian/sid, are consistent with distribution names from debian/changelog and the .changes file. [0] Therefore, it seems like one should use debian/unstable. [0] https://www.debian.org/doc/debian-policy/ch-controlfields.html#id25 -- Richard signature.asc Description: OpenPGP digital signature
Accepted ntpsec 1.1.7+dfsg1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 04 Nov 2019 20:14:44 -0600 Source: ntpsec Architecture: source Version: 1.1.7+dfsg1-2 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Closes: 944084 Changes: ntpsec (1.1.7+dfsg1-2) unstable; urgency=medium . * Set maxclock in the default config * Split nts config across lines * Fix ntpmon/ntptrace version string expansion (Closes: 944084) * Move packaging git to Salsa * Backport NTS-KE hostname fix * Remove old lintian overrides * Add an NTS section to README.Debian * Add README.source * Rename default branch from sid to unstable Checksums-Sha1: 4a229568852059d2f4cb62fe1389c48664e1febe 2419 ntpsec_1.1.7+dfsg1-2.dsc edd6f3c1e05390b73826589a1443b29609143b02 46940 ntpsec_1.1.7+dfsg1-2.debian.tar.xz 16306a4515a1e2721be1bf47339bfeb5ccd1f523 9572 ntpsec_1.1.7+dfsg1-2_amd64.buildinfo Checksums-Sha256: 39e5750294823f187c3c745690c0068102db6fb23522b9167673c1fe470e8263 2419 ntpsec_1.1.7+dfsg1-2.dsc 516386a882516b74aeb31f285d3cad3d58a654d4ae09be25f56ef8e2d55e5eba 46940 ntpsec_1.1.7+dfsg1-2.debian.tar.xz e82cb29a4455d1ac676586a9acf59c460712bab69012b71cd83e2bafe3693555 9572 ntpsec_1.1.7+dfsg1-2_amd64.buildinfo Files: 91e3e421440c3a4fba0bed375a5d506b 2419 net optional ntpsec_1.1.7+dfsg1-2.dsc c1fb438d74e9ba8ae51988909d66f365 46940 net optional ntpsec_1.1.7+dfsg1-2.debian.tar.xz 4c16062f21ced31de08c034a004fead2 9572 net optional ntpsec_1.1.7+dfsg1-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAl3BioMUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpY4NA//Q3AIvl9xL9sy2orB1FfQcZakYg5D 7jLtj00XFYQqX+rlPuHeMU+hInAdUJ5yQOXa+hCi6bYFA2xNxC0NI6KSXRceJZoy C7JuR3iQQz4GDejWBxv79dEY2relwC4D7nzhxhgw/Ej4hNCancO9ZBImR0/K1gSG QcHu8n7n6jrJCtDgZ+uTiBfgOyrqL29pquacpVeonZNFveBRImtz/WVQHaMmfquM 9GeBLH11wCIukT4V7dup4bn0IwgaRSA1yT5x09eNDSPkGD4IdSVlogSyq0RxiQYf GI4LhodRV+WrJnfV3EoNrzC1AJzOtNF7dp8Jl+jklDd8K6Jq7kLtGyA0BZnqKPBu gZRY8Ih4iWk7eXrRAC5SmhPdlNOSfirAKLt9Q8mO43Dyqd/aqTRrRql4QwKkAwCI rMQhqDqf3aQbeN0+OMd6wVb7qsGVa+mBbmURCHSrMDYIlOoJazvOBx5dUPSTS+re z8LSTCJXsF1Vc95gvA97NZ4uF0I9twoZNJ3lu4IXqRoisCFHlmFenaOAsjJgHn/p o3VEbETKwoyEI36JR7/xjvqynwE/5l1R2WFV6cB5qoe4cq/75myWG5pgFx1h3B/o GACPq/dx8AisJvXmoLcYhymBD+beJOmSGvjxb+WITrOFl3iaDRzvhUXVzemiUngA KA+ixuGD7VRXj4Q= =4NGr -END PGP SIGNATURE-
Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]
This all looks very good. Presumably the repository / Salsa project name should match the source package name? If so, that might be good to note, at least as the default. I'd love to see more information about a recommended branch structure. FWIW, I've been using branches named for each release (e.g. "sid" is the default, but I also have "buster" for a (proposed) stable update, will likely soon have "buster-backports"). This works really well, and also scales to also having branches for Ubuntu (e.g. I have "bionic" and "cosmic" too due to some SRUs). It also keeps "master" available for the upstream master branch. This seems so obvious and wonderful to me, but I'm not sure how popular it is. I'm currently maintaining my packages on GitHub, but I'm going to move them to Salsa shortly to follow the consensus recommendation. I'm not a DD (and not a DM either, though I'm finally getting around to applying). Unfortunately, this means I have the, IMHO obnoxious, -guest suffix on my Salsa account. I certainly don't want to create things under that namespace, and it's doubly painful because if I ever become a DD, my username would change. So I'm asking my sponsor to create projects in the debian namespace. Of course, that's the recommendation anyway, so the -guest might be an inadvertent feature because it's encouraging me to use the debian team. :) I understand that DMs are quite literally second-class citizens (and non-DM package maintainers are third-class), but I really wish that things like Salsa usernames didn't call that out. If this message is threaded wrong, my apologies. While I am now, I was not subscribed to debian-devel at the time. I have tried to set In-Reply-To directly, but this is my first attempt at doing so. In these situations, I would normally download the mbox archive, import it, and reply to the message that way, but mbox archives are seemingly unavailable (at least to non-DDs?) for Debian lists. -- Richard signature.asc Description: OpenPGP digital signature
Accepted ntpsec 1.1.7+dfsg1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 29 Sep 2019 22:27:38 -0500 Source: ntpsec Architecture: source Version: 1.1.7+dfsg1-1 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Closes: 924192 926877 929756 931327 931414 Changes: ntpsec (1.1.7+dfsg1-1) unstable; urgency=medium . * New upstream version (Closes: 931327) - NTS is now implemented. https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp We thank Cisco for sponsoring the NTS development. - Lots of fixes and cleanups to PPS, both implementation and documentation. - Allow "prefer" on a "pps" peer to use it with any source. - NIST lockclock mode is now a runtime option set by the (previously unused) flag1 mode bit of the local-clock driver. - The numeric literal argument of the 'time1' fudge option on a clock can now have one or more letter suffixes that compensate for era rollover in a GPS device. Each "g" adds the number of seconds in a 1024-week (10-bit) GPS era. Each "G" adds the number of seconds in a 8192-week (13-bit) GPS era. - The neoclock4x driver has been removed, due to the hardware and the vendor having utterly vanished from the face of the earth. - Update libjsmn with upstream sync - ntpviz: Add -T TERMINAL option. - Fix slow DNS retries (Closes: 924192) * Return to new upstream GPG key * Drop many patches (merged upstream) * Refresh Debian-specific patches * ntpdate.8: Remove duplicated -o option * ntpdate.8: Remove -p option (Closes: 926877) * ntpdate.8: Remove -e option * ntpdate.8: Remove inaccurate BUGS section * Update ntpdate-debian.8 to match ntpdate.8 * Fix ntpdate -s (syslog) to fix the if-up hook (Closes: 931414) * Fix cron jobs for systemd-cron (Closes: 929756) * Sort debian/ntpsec.install * Give the CloudFlare server as an example with NTS * Add a hint to ntp.conf for NTS servers * Add nts-keys file to AppArmor profile * Add ssl_certs and ssl_keys to apparmor for NTS * Update Standards-Version to 4.4.1 (no changes) * Use python2 instead of python for ntploggps * Fix a spelling error in ntp.conf.5 * Update to debhelper 12 * Fix/suppress dh_missing warnings Checksums-Sha1: ddf02e52abbc7984d85e22e3ecf257953bee40e7 2417 ntpsec_1.1.7+dfsg1-1.dsc f985392f654c5718d0fcf3ec6da42eeb4da707a1 2566278 ntpsec_1.1.7+dfsg1.orig.tar.gz 66a6598d1613db595322b55709e3e14b29ffb3d7 45004 ntpsec_1.1.7+dfsg1-1.debian.tar.xz aac880d38cdf9ce47fa0c465981f0ad5357b15b5 9558 ntpsec_1.1.7+dfsg1-1_amd64.buildinfo Checksums-Sha256: c4d7633b3d91a578e52b45c8b43608e06130a199250ff02d3507854a877dcab1 2417 ntpsec_1.1.7+dfsg1-1.dsc 2d448957d03ea8caa7b52e36b0b58d9eaddc02079c8f942653802d87815aff78 2566278 ntpsec_1.1.7+dfsg1.orig.tar.gz 628a0db41a180cf65e4dc2ca369e0089f7c8d195446e2763ef96df57e57b4d3f 45004 ntpsec_1.1.7+dfsg1-1.debian.tar.xz f3a684291f79933a536672bc607ff5e7952c6240b0eb9fcfd17734ee13129db6 9558 ntpsec_1.1.7+dfsg1-1_amd64.buildinfo Files: 382d9fef4e12065a3ca56adba21b2ade 2417 net optional ntpsec_1.1.7+dfsg1-1.dsc e45bcf4b1afd68383b77e71c7c574709 2566278 net optional ntpsec_1.1.7+dfsg1.orig.tar.gz ea7d24facb99caca4bd304c065013044 45004 net optional ntpsec_1.1.7+dfsg1-1.debian.tar.xz 3c8ce8496e03951ee67ac02f2036bfcf 9558 net optional ntpsec_1.1.7+dfsg1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAl2SA38UHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpZH2g//aSbc/BFhG4Udy864ZS2de3uFny/e EYbK3Bs8hVUWwALmPLJD5bWCukreeNV2B1rocjuyskxgdMFtWCWs66r0EGqfO8ip 5vSG0TQkyOIsu+o3RUF5olz0MwQTrpGX0sf7qAuV8R2EAxfhfR1+PiWO7ZU1y+9t yqwDPMUMBsOn1Zf/SIZc/Ua2eLtnkGl71NoT/4tMT0ATZnn6gYTpamcRcQQg15ur C7B0Tl//uOXK1lwiF1Csygw8fT2WdDoRLhVhkg07GAVZTyEMJjhddIh86k8ji/Cc 6alLyi9LJKi9JttBlkhN/vyq9EiG1ZHdWT/++5Mg6ipoNDhhTjgDnefTo7cJiFrp K1jQQo4RJBX3o9LS64HGbkkO2/dLUIM3JPtcFgmkSs17r0R2316VsaA4+jL0fM+K wTsWPC4Y7jXjPaGW2DjBFc5g9Vgd65fso3R8lHYAgmiRUkrvJcvVmZutKkTHDROo 2IhPPnoLDThfTGskSUje+ywYB2TK3v1OrhMIP8FzompGY/xWBFI8slLQMr3eY2XY VxkEJyPaBJHp6EUmg/kG08nO1T9TVXlPTN1MIgs380wS9HTh36y/14eXoMMcOg/Y oCiKaxU4FhGFtkd4gfu8Sf2mlXT6kSuITL7ODc42F9aujWp6qLiX1lYpHVuUBWfF bPT35CvHA8uKtjE= =YCdz -END PGP SIGNATURE-
Accepted ntpsec 1.1.3+dfsg1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 04 Feb 2019 01:38:48 -0600 Source: ntpsec Architecture: source Version: 1.1.3+dfsg1-2 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Changes: ntpsec (1.1.3+dfsg1-2) unstable; urgency=medium . * Suppress lintian warning * Backport a KOD rate-limiting fix * Backport control key error handling in ntpq * Backport PPS doc updates and "prefer" support * Backport pool documentation updates * Backport "Add security fixes to NEWS" * Backport neoclock crash fix * Backport ntpkeygen/ntploggps versioning fix * Backport strncpy/strncat => strlcpy/strlcat fixes * Backport various documentation fixes * Bump Standards-Version to 4.3.0 (no changes) * Backport Python egg .info file * Fix broken version substitution in ntpleapfetch * Use SOURCE_DATE_EPOCH from pkg-info.mk * Make debian/upstream/signing-key.asc minimal * Explain why the tarball is repacked * Remove an unused lintian override * Remove unused code from debian/rules * Suppress lintian manpage warning * Fix a spelling error * Suppress lintian warnings for systemd [Install] * Add Documentation= to ntp-wait.service * Add Documentation= to ntpsec-systemd-netif.* * Remove GPL/OpenSSL lintian override Checksums-Sha1: 34c8054d4c82c3f538a0d559c130383fbf052981 2385 ntpsec_1.1.3+dfsg1-2.dsc 2bff4f78df0da774715ce14e2c65f7be8c43e9d4 66088 ntpsec_1.1.3+dfsg1-2.debian.tar.xz 6ff604cacce3de4c0268b93fa4933b8d86e0e3d1 9009 ntpsec_1.1.3+dfsg1-2_amd64.buildinfo Checksums-Sha256: 70fbafe24e46b5e2efd6780fa412fdb7f56366e08b4473b36151c5cd1860f3ca 2385 ntpsec_1.1.3+dfsg1-2.dsc f6edb805cf02de01f59e34498c7da625ef4c5c5a857e1aec3e2764d82c1072ab 66088 ntpsec_1.1.3+dfsg1-2.debian.tar.xz b8556ccbedee3a6df87104b30b82472e3bc6365323ae3565bf1352578593f3d4 9009 ntpsec_1.1.3+dfsg1-2_amd64.buildinfo Files: 5327d1eb8e75c50876decf90c9de0afe 2385 net optional ntpsec_1.1.3+dfsg1-2.dsc b460d38c0ffde5663f9ef2bfef70ac82 66088 net optional ntpsec_1.1.3+dfsg1-2.debian.tar.xz 28fadf651a1a78414226a3b82ea41869 9009 net optional ntpsec_1.1.3+dfsg1-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlxZEnkUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpYjLRAAoDQ34ofk1y/iT7/PrO1jiNbM5KMl NuBJZHGh+mEYvCZANvhU2M5oDP7TsxQ6ScsxwQJTmTceUZ4lk69uF+hPocXoEW3G 0I8QEGl9H3O1lEYyUXWksSFlQOENUniCNgVBoNwx2BDgH4HVc9kk0JXmTtcz2Wg/ 5n0Tl7jf5KXATiwn69PW7JJMoUDUiynYCvUC72Eu0IKdpffHYjsvl7jgJP3a+Aqe N8EwMxK63PfXlbpYWQklg3HyXqyeWgdtlOzRS/Z2gvP4VquTcFBouebQj4cE0iWL ZRAVpW+6V98jYk/Cx0bkMjCAtEsTAiNaZJ7M1xdUJPlMU5T3CA863SWViWP6N2Lf iuM93qUBWbcXdPChHVCpx+Pvl6goLvw8BFqfQ/zjhyVnzJr810E7/vEBoAmJCnDz XIAN+AYEFnAyPaQB6WqUpDSHMovV/o9wMLbt52AF5i8dtKXlWojK6TUGCwPPFJEj AA0GnpsI7QVtuKpkQYF9o07cflmFH7vXjTq4VN0KobEVBqTsgFQ9JuubyrF/v+t9 qTNi2yAIMAgdB871vt7RYBt28oUZ9BIC9gWUmUv12DNoz+gcfPaKQeDDXDmX4hGd yc1Y0aP/XL1gWfqdpengj2HvSnthkidDGCr9wICwNXjMskB35vJJ1uCnFqk1nTtJ d1P28yuuOwVRLXk= =fkcs -END PGP SIGNATURE-
Accepted ntpsec 1.1.3+dfsg1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 17 Jan 2019 04:17:46 -0600 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.3+dfsg1-1 Distribution: unstable Urgency: high Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 919513 Changes: ntpsec (1.1.3+dfsg1-1) unstable; urgency=high . * New upstream version (Closes: 919513) - Lots of typo fixes, documentation cleanups, test targets. - CVE-2019-6442: "An authenticated attacker can write one byte out of bounds in ntpd via a malformed config request, related to config_remotely in ntp_config.c, yyparse in ntp_parser.tab.c, and yyerror in ntp_parser.y." - CVE-2019-6443: "Because of a bug in ctl_getitem, there is a stack-based buffer over-read in read_sysvars in ntp_control.c in ntpd. - CVE-2019-6444: "process_control() in ntp_control.c has a stack-based buffer over-read because attacker-controlled data is dereferenced by ntohl() in ntpd." - CVE-2019-6445: "An authenticated attacker can cause a NULL pointer dereference and ntpd crash in ntp_control.c, related to ctl_getitem." * Drop debian/patches/fix-ntploggps.patch (merged upstream) * Refresh patches * Revert "Use python3-gps" At this time, python3-gps is only available in experimental. * Disable the waf PYTHON_GPS check * Update debian/copyright * Fix ntpdate.8 documentation of -B * Changes as of ntp_4.2.8p12+dfsg-3 have been merged as appropriate: - Update ntpdate.8 from ntpdate.html Thanks to Bernhard Schmidt - Update ntpdate.README.Debian Thanks to Bernhard Schmidt - As a notable exception, while the ntp package has removed the ntpdate hooks, I have not (yet?) done so in ntpsec. * Set Rules-Requires-Root: no * Sort debian/ntpsec.maintscript Checksums-Sha1: cb7a77e51c191d2cffac80dfdf15e020a1e0fc16 2385 ntpsec_1.1.3+dfsg1-1.dsc a4edb6006102f5c641d7c3a786c7bb8eaee91f49 2490447 ntpsec_1.1.3+dfsg1.orig.tar.gz 89a0f0c26e20893495478f6a4c4af013d3a3a674 44248 ntpsec_1.1.3+dfsg1-1.debian.tar.xz c4377c8a7c7cd5f16b8f3e174d9bf41405b27d25 9185 ntpsec_1.1.3+dfsg1-1_amd64.buildinfo Checksums-Sha256: 583ba864f845177857516279e1a08f60d9f52b4dd5176b91371da00ecc7b56ce 2385 ntpsec_1.1.3+dfsg1-1.dsc 5e5525ea8ea2e75ce9fb6dbf47cb4cd919e8929ee9f99f2e00bfcf3d2f1a7410 2490447 ntpsec_1.1.3+dfsg1.orig.tar.gz 98725fc86f92d6b0fc104bfc6b6310fde40c3c3dd756aabe156996b5cd7a8fc2 44248 ntpsec_1.1.3+dfsg1-1.debian.tar.xz 3ca0393599113f307e56f2c2f7da8c8f27f93cb62c4b6fb8c9be24edd7c9d59a 9185 ntpsec_1.1.3+dfsg1-1_amd64.buildinfo Files: 57b2538607e125e188f9c559be5b7677 2385 net optional ntpsec_1.1.3+dfsg1-1.dsc 7dac3394aa446a5799ca0f66bfa30217 2490447 net optional ntpsec_1.1.3+dfsg1.orig.tar.gz b150a0f0ca14139b74e4eb596584161e 44248 net optional ntpsec_1.1.3+dfsg1-1.debian.tar.xz f891b7fd3b55d77f13cfe34d93b6aaa4 9185 net optional ntpsec_1.1.3+dfsg1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlxAlGMUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpZXSBAAkE/E9rUMMSBLJHQuSKqUPh/T32sD MH0NbGGEkjKiX2A4oG54UEXGlqKHK7FSigDXS9RyAUzZEBMTYHp6L3H/jsQrEsF1 33gnIJEaxAu3Yos/030Xwlf7n45JFnbFiBt6XWp3yVHnDtR7MBeYQngWQT5lRR8u n7lCgtfU8ENlTCBtMV+rRb7JwmeJZnrX/BDb97y/AcQvwMgpB50gG3KCMMsg694/ rSNTKtCRLQwUSpENKnGw6+WtvEC23FsPCTXe2/Qv6ox8+/RIuN26s6sOc6ImEAj3 YmpRcKxgCPy3cnOKKs/EVFtp7SNCpiQyfZRVlyR396ncC78RD9kRoinOz1TVUsSA gQfccVxNqVojta90NZTwUIv3CdNxiB/dYRA0EAoaVTt7kYUa1e9kkRbIOhCj9ZiR FXho1UeGDYiLLhYzReMpWjgZCMnlSdjRGnGHp7JsDNn1YIrh5bCq5SxU+8AGTGia qBiK+hlAHt7ljkPiqnGfHPuWuMGrCAt6pir/RrTDn47peR7G5EZbi3xG6QrvtHJ9 TEIrvrIp6wUfjzbnz7ZP14BDTbLL53/OJ/wQMuQPX8HtEUaO/6IccRwe6TP5GmPM pPfbPCa7hbm+H36yLSkhMmcJxBxaCh6MKXfJXcUF+AOcv8WJNhO0kUv2VAk/ukGu dkC6zuUjbFFKOyA= =CM5C -END PGP SIGNATURE-
Accepted gbonds 2.0.3-12 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 18 Dec 2018 14:25:57 -0600 Source: gbonds Binary: gbonds gbonds-data Architecture: source Version: 2.0.3-12 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: gbonds - U.S. Savings Bond inventory program for GNOME gbonds-data - GBonds data files Closes: 868413 885638 886080 Changes: gbonds (2.0.3-12) unstable; urgency=medium . [ Richard Laager ] * Update Standards-Version to 4.2.1 (no changes) * Add redemption data through 05/2019 (sb201812.asc) . [ Yavor Doganov ] * Port to GTK+ 3 and GIO (Closes: 868413) * Port to GSettings (Closes: 886080) * Get rid of rarian-compat B-D (Closes: 885638) * Remove gnome-common B-D Checksums-Sha1: 355a2688cacbb3b99fed871889741ce6154c30fd 2027 gbonds_2.0.3-12.dsc 531d3bb395344eae582d1b5a0eb76b0b0c19aac4 89548 gbonds_2.0.3-12.debian.tar.xz 4a0d0d6f835cff2ca9bbec98a2df68b0539b30ee 15274 gbonds_2.0.3-12_amd64.buildinfo Checksums-Sha256: 25c2b5086c4fb1c7a042ffbedaeddd57a5d03684b2225ca6133749b7a0355f14 2027 gbonds_2.0.3-12.dsc 5adf36476a8073a2a0c7318d01e7567a25f10527e9b4cc504af503b3a056897f 89548 gbonds_2.0.3-12.debian.tar.xz 8b5780e97f9f17d03718a9997849ff3c283dfc378653f176c9a2f7d3ec3d508b 15274 gbonds_2.0.3-12_amd64.buildinfo Files: 8bcf094963df82dc6669a34d004b71fd 2027 gnome optional gbonds_2.0.3-12.dsc ef6573c965e7b1ff91c9098ef058d093 89548 gnome optional gbonds_2.0.3-12.debian.tar.xz c88899c19f85ed922b5b453a896dff96 15274 gnome optional gbonds_2.0.3-12_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlwZvGgUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpbflxAAgbUIoPEt/v25HCIE8FqHnUrccwcb 60R8AO2Oewuawi/s7AYBVMUY9YarS8x5tdE/RWjN7v4YRzqIY+7ajv6ozx8TLMCU wgRSyXTJSTwl72+JfXgUrTbmagVRv/trZQXeMrO95Zz7YxfnI7wXdT+wM3ano1cs SSHKdC2JNhFH11hDj6ei9uPA/YHTH6TAb+0vGihB9SmAZ26Abs+Ogj+uZ6ksyMUV eWSYGrR39w0PEZSbnUG8gj8syVb9I7Tw5sVtX9h7I2FxZV17NtRMAMH26TsXYLkd hd30bd+ltkFlmf2t2Uyf+XQaK9Pno45KqfSRy+rnWedrvIhtNy8u+UFG90DiDMeq oYc8ESR4REUXTmQuSdQMuox9qZONU9uDGc316xWgZL2Pm7JdNuooNHoL4sjk/WaM LxXGWNYvhMe4DrTFc4/cUapRjirBFAxzmD7gF3lChpRgHkTXYtB1xebgYHuB6n/N mvgElKtQUjC0AOIF48VZBsLzsnl5WiPeQffkQ70amBr9SQKPeG0z0cQDl8Rrpk2I Q4bbKEA2yyRGeOWMxTtMSRUcA3WAHWdNzdsI6u8qVlGGwG9ooD6yCQnxfm7oRMzr iYtvUVhl+jyjbFPDHH9pyjLAjygZWsgFeq6NPF833H/iPddz6OhX07orGMBS7KXu NOOlDdu9/BlNZGE= =dpmD -END PGP SIGNATURE-
Accepted ntpsec 1.1.2+dfsg1-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 18 Dec 2018 13:30:35 -0600 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.2+dfsg1-6 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Changes: ntpsec (1.1.2+dfsg1-6) unstable; urgency=medium . * Use python3-gps Checksums-Sha1: 8cc9f532c66a5daf24e00f62594341b0ce05fb7c 2385 ntpsec_1.1.2+dfsg1-6.dsc 88a468a6784766e312ed0469fe330d84bea360de 43564 ntpsec_1.1.2+dfsg1-6.debian.tar.xz cd7568f8823a31492ec761dcb6deceb0dfa9c621 9180 ntpsec_1.1.2+dfsg1-6_amd64.buildinfo Checksums-Sha256: 95423e8ff617669ca115484c4f79113074903cacb019540eb8a10e2f83c0f1b7 2385 ntpsec_1.1.2+dfsg1-6.dsc 9fcf08ea91f61be352c570a4da411d2bea7f730b0f56da50836d63e89c031e6d 43564 ntpsec_1.1.2+dfsg1-6.debian.tar.xz 280cce6f1aec2586eaddf96f171a5431c2203984eaaab18fd638229c70ecb0eb 9180 ntpsec_1.1.2+dfsg1-6_amd64.buildinfo Files: d830d06273a209b80a9b566ed11d2829 2385 net optional ntpsec_1.1.2+dfsg1-6.dsc bd3bf09e24b9dd42de4e5f153c89f4cb 43564 net optional ntpsec_1.1.2+dfsg1-6.debian.tar.xz b163a5d911f0c40e2cae1a33ec75b4d1 9180 net optional ntpsec_1.1.2+dfsg1-6_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlwZup0UHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpaVxQ/+IB4UMPmdoY4+pxEoe3T1Tq+NLmVT 3YFX+zafbdUT/UbLP5hN/7zt1vyiz5OrOO1O3SOGIV1wzrxuZl6I5yh/D0N4vDkH JqOUBXmNKXYbREBdWaW1cnIZDNwT6PL8VwmCk2qxCaI17yWAdPCqvU/9AbUNNXqy zt6uAHZAdvvivIwAvUDpMz9EB1EPtdcqjPM1tJ1mQZFw0+AosJ8NXf7cxlX9ViP/ QWsoiPqplbM4DPuK/SzefzNgFqECdII6zicapFnYu1x9v4/bOY2bavKK3vJuIfEe hdcU/y7n260GHDd6y2RKUcKI+0k3wxN3Sqr9ararOLM58n85l0A5d0ykm2GZzIBO g+NWSlFVZ0JZpXR5wvh78l01tTh05KHCsc3peCWyHMpTPqlt7oNqAZse2XO+KyLK Fd8VkrkvwbrTMtRSDPzeT1RBitLINEwaB383eGpe12TxvXfOdxHAddnIA3CVxj05 iR6QnU2mUWOgNiq4z6+weHUqQwGnFnYZhfNpnRt1p/28CTxSmgWbfNw9doQG/IJZ zKzGRhaSemX9feTcXuejd9TjJzXaKWsOpl10WIPqTayBAUxl3pXcPqBKF9KZt8k3 eB2jmoIVCza6n1Omd8NiJotwcaCmb6fXkZ27AgP1nUuZmHyVWiSyAZyYkrnw0vnV 7o1Qc+P9eTVm33E= =RYrw -END PGP SIGNATURE-
Accepted ntpsec 1.1.2+dfsg1-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 07 Dec 2018 23:11:13 -0600 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.2+dfsg1-5 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 915937 Changes: ntpsec (1.1.2+dfsg1-5) unstable; urgency=medium . [ Bjarni Ingi Gislason ] * ntpdate.8: Some minor corrections to the manual (Closes: 915937) . [ Richard Laager ] * Update ntpdate.8 Checksums-Sha1: be39847c28a176da635524bdca1d50feaf9c7398 2385 ntpsec_1.1.2+dfsg1-5.dsc 335de8e8312b5baee1fbe3618d20721a43717170 43644 ntpsec_1.1.2+dfsg1-5.debian.tar.xz 66d60fc0190c956ac5b571da0a1d00cf7d0585fd 9172 ntpsec_1.1.2+dfsg1-5_amd64.buildinfo Checksums-Sha256: 79c3894951cb1fe63b7ef1f05d65b83a9bc4e8a0b7eee2eeabc18ac312cce701 2385 ntpsec_1.1.2+dfsg1-5.dsc 87d407a4e40b12e68fcd3df3e7193d37c1ab64f0c21a03cca089e97dfc459ad7 43644 ntpsec_1.1.2+dfsg1-5.debian.tar.xz b934d7007e73a59b6469dc30c6f993075105957db80418d33144e4a62048651d 9172 ntpsec_1.1.2+dfsg1-5_amd64.buildinfo Files: 08c73d91e09705a5a615e0a62c2ec354 2385 net optional ntpsec_1.1.2+dfsg1-5.dsc 1e81c5d9dcad25718a15a519b7bbf1ed 43644 net optional ntpsec_1.1.2+dfsg1-5.debian.tar.xz 9bcfe33797e0ba081d5deba6c0d2e2a2 9172 net optional ntpsec_1.1.2+dfsg1-5_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlwL3F0UHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpZjFg/9GKI5J6qIenRG7IDpc1IRsJu7Nbqw l3stHMiupCq/YpnIaFLz8fBfB++JX3EyFt7a4/tN/pkjPcaBc2gq3GMAcRQE1CPY IywkwPwdShDC1eI/yizIxlmn3SgMF5nFJHh9IM8fMm8uLgHR/XimodpqZ8LNKSbI o6icATjYHR9BVREKtO1+Cs2SuKW+hbo9tH6VRhFa6WJ06OqH1ILW3jr18pdqW+Qq 7/zDnzVG42ME1zwQeSN25TYpy/H7sHJDlYJinMcR+0KHWnQv0V9jg73npZ85jEw9 NqTisJ1yyy6pQKxXMxPtUVJGndhi4aIAQt/EBjKynrMOLkWUe/LPYrmFMKOxjcZq /6CCHAGNiTwWxe8dZ13IexiCLFRRHZUHbzuHATt5r0tMfBem1f1KhD3Kk2ZqXUYx NCfQ6Q0ijindJ5js9lTTne6ARwsbumyHQZIywjxrTIrwDruimfrwBoVqWhB1ajuq I78Jf4k8vGXRt33ueR5vSSeTsWW0Ydy69G7lvogY8/d4pTdsd5e2TJCCR1HSMFtI +iB+WsX+AXOEJlxQijGz8eBvj4u+ER0q0KIg3CBVOHRhIZTgfzwNx2nS0mJjDlYX gKkzRWX1FFkrDgKPKKkbrwMjO4xMgwqgqdHkw+dXPrAgGpVoCy0sWUyyNVxP/ra3 ZzvY7xIjnHaaZ8o= =NHBn -END PGP SIGNATURE-
Accepted ntpsec 1.1.2+dfsg1-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 18 Nov 2018 04:11:00 -0600 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.2+dfsg1-4 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 913964 Changes: ntpsec (1.1.2+dfsg1-4) unstable; urgency=medium . * Strip tos lines when using DHCP servers (Closes: 913964) Checksums-Sha1: 0f2abb47446fbd81a16dd2a49e63aef49eeb25f3 2385 ntpsec_1.1.2+dfsg1-4.dsc 2c8947ad5575186c1249a2026cfe27cb8cb56866 43524 ntpsec_1.1.2+dfsg1-4.debian.tar.xz 647a2e5d29b3668b96768a12aa44110d26410ccf 9122 ntpsec_1.1.2+dfsg1-4_amd64.buildinfo Checksums-Sha256: 01e5337a94f88feb3c36644187cbe58c0cb58a845a708ef3381429eeeb1c2e0e 2385 ntpsec_1.1.2+dfsg1-4.dsc dee82420c6822a934babef06c79a195667b3019a53882a415b4f4e5fdda35c03 43524 ntpsec_1.1.2+dfsg1-4.debian.tar.xz e0af393b28b544c49f24c99629cd34e2aea6cf75b9a420739c40dc4dd041acdd 9122 ntpsec_1.1.2+dfsg1-4_amd64.buildinfo Files: f69aa3fb8aa4e2fedeb46063c5ab94b3 2385 net optional ntpsec_1.1.2+dfsg1-4.dsc c3cf9daaff31fdc77574395d252c5ddc 43524 net optional ntpsec_1.1.2+dfsg1-4.debian.tar.xz ba848c0e2ca8edfaa1efc59e44ba7744 9122 net optional ntpsec_1.1.2+dfsg1-4_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlvxiU0UHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpay5RAAz1s4EN00rOn8IyoqNhQsK8iU3eFd YIVPPt5cqeclWTV/loh/4ar9nU1YLMzktDuY+VWw0j1go85Gu/zvZjt6jSc4SPoj cMZsN7QZKIH1lXIONXol2EKDD3FaeHJtaulX8KGVOLfJJynlkWVN0T1nn0qopjI2 R3YgLLPhgQ25xZnJEG8NoyCt5R0XGCwMQGbW7CiIrnfXHDi0Xw4ffkMxpd6JP+/f AnjiZDhJG1V/JjByV6vAmZ29xkJYuKN6kkjkIIfyDVUmLNwj2GquioQfIi44wWqX b1fgUO0yVRzD4ka/0j+y5BdwWVqWfvbplMSG1fSPpPsO13iXbYXtYHgC5qfhXp2L 7ao6nYazAdcJuIBcG6/VDEYVdLGnCq+rdEeEcic3ZWW1ANnD/G3pA3kIZaIUjREW fmBa9/2qDvF6VWqTNQ54uq32UVkHadrrS4muWhfHPfROmeAJdSKA2anwcitkQOi0 GmAyarlsyRg1hjK2qZiZwW4fimxIIPrwXg/1UoZQPbXK8qd+eWA0Rzb3KmWRWMtE T8zdIpMtc7FJ7L+SWZSF/KzcKQOHxi7ew/SXEJaTYmeV48rJKwLEPibvSIBxAGx4 uOXagYc8XLqLYTULNSPnn1hpXcuOeESQRRq/1LM+1nkRrJ9SGDmKaKQ5yhJTpnAo pZyFYZtY0vcGU3g= =9z0C -END PGP SIGNATURE-
Accepted ntpsec 1.1.2+dfsg1-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 30 Sep 2018 03:59:25 -0500 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.2+dfsg1-3 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 909923 Changes: ntpsec (1.1.2+dfsg1-3) unstable; urgency=medium . * Cleanup /var/lib/ntpsec on purge (Closes: 909923) Checksums-Sha1: d3db5dcf9a26b309663db8cfbcfb3dad26a8a842 2385 ntpsec_1.1.2+dfsg1-3.dsc 86bffaa4ea8334f47b2077c9df6ea2b0388763f0 43508 ntpsec_1.1.2+dfsg1-3.debian.tar.xz 24dcea2440887f891a9cf206e24dd4c0d6baa704 9176 ntpsec_1.1.2+dfsg1-3_amd64.buildinfo Checksums-Sha256: 5d2cd5b506c216e238bf8fe67a4df281824ddde6b80fe49afe682c4ef326f2af 2385 ntpsec_1.1.2+dfsg1-3.dsc db5a269ac8a129100702213a510d8da5a48adfa14430d2253997312e85b32000 43508 ntpsec_1.1.2+dfsg1-3.debian.tar.xz 4ea266ab19589d41c7a2e3b7e8f13fe4c328d2c9db6b5d1a4263816d9082363b 9176 ntpsec_1.1.2+dfsg1-3_amd64.buildinfo Files: 8a048f8287a5928716db434a7873009a 2385 net optional ntpsec_1.1.2+dfsg1-3.dsc 0f6d68b0c30afd70567e2ede32c07c43 43508 net optional ntpsec_1.1.2+dfsg1-3.debian.tar.xz 0ba0a9b6e4acb444e18f1818a2e81e42 9176 net optional ntpsec_1.1.2+dfsg1-3_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAluxESYUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpZb9RAAkemcHCJp2nPTlad8Gw9PUhC66dVy yHO9UB8yy2wBh6QGB30GRq71fL0fkf0iq6Yq3/kVgxaXsJxt3qx0OCMTR17nMQx4 nwHc+1aMAhspYuqHzt0pAk6qcl5fpYMD/3Xj/w3I1Znp7ngulU98fpwY7po4fxw3 xCZUKVocD5hZhGQhsl9H+puc0+6i7l9nTsL6YYJQMlS7Ehqh/NYxImPE/4w5PyxY L1fH/Boii13yUkmWY9K/PZs9NlmKkMJdVkkvfxkqT/Rz2pBaOvKbcmrRueBBJvkM WpuHuD/PWchTj7j8Brwd0XlfVT9lya9po4Zd9zoJPzuAjbrc0dmJ0DV9zuppPxEZ VgQgoEO1NM43tDpdFU1hzNtRlIL3ApSvdrIM59r/hulnbgIYeZtuO0sqctM8o62L YCjPbMDfX7mpryFYU7xvIF2aO9LOGRrbNZ58DZqmU/58elI+SB4esVg1QOm6UmwR G3IdEpKacOBA1rEQSwxzdEuGGeWLGB9QpbOqitl5d2GQXLW48pXyYXeU+4imLhkC W7+TD/HHoX3cZQ7uEKwWrBYKM0Nmp7Eac5AmlVum5Lt/WX8UQm6DNV0SX/1+Aiil QSIq5Zoof3gL8TRmcxqo7P4j6vPhoxsMjKgAruRGAswEOvJ9MXnzHXBO+3B8ctJG g/gHtG/i1LeL61I= =HeXv -END PGP SIGNATURE-
Accepted ntpsec 1.1.2+dfsg1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 27 Sep 2018 06:42:19 -0500 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.2+dfsg1-2 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 909731 Changes: ntpsec (1.1.2+dfsg1-2) unstable; urgency=medium . * Drop dependency on python3-all-dev (Closes: 909731) Checksums-Sha1: 883d1b7a0b868d1e4058af0b5eb89a31ad477379 2385 ntpsec_1.1.2+dfsg1-2.dsc 682082709b8906e9a1765841ccd543829c4c9a81 43476 ntpsec_1.1.2+dfsg1-2.debian.tar.xz e0aead2bb9a43ce3dcfc5c9ab700a3c11eca2a5c 9157 ntpsec_1.1.2+dfsg1-2_amd64.buildinfo Checksums-Sha256: a808292389fa060702b0fd06b5f738a1f9fdbd5f9fa4b1f11f415e1511947a82 2385 ntpsec_1.1.2+dfsg1-2.dsc 495f64169b5a694ff0bb661776400e4097053b3e15ba92396cff18ac956734f2 43476 ntpsec_1.1.2+dfsg1-2.debian.tar.xz 5ef6df475868fa8642ea7e86bba39d9093c2b4e31db414d96f771c4952be5f73 9157 ntpsec_1.1.2+dfsg1-2_amd64.buildinfo Files: e40c39526956fdd2d4fe93d50879ea4f 2385 net optional ntpsec_1.1.2+dfsg1-2.dsc 52cf52aa491cbd9ac42db552fb378009 43476 net optional ntpsec_1.1.2+dfsg1-2.debian.tar.xz 5f38cd1b286f919af82286c1a3d6bbac 9157 net optional ntpsec_1.1.2+dfsg1-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlus2mcUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpYxBQ//dk5TGRj4qqie5L063O5pj02oZxu4 CWT/nXywAzY2NFcyKKSqe8HzP+tkPwIbBlX7Qv0fORGUDNl56IURhXj0qdvGhFzY r6QZ2kVri3OCKrT5xoY75wP0E6BhK/O+OH31FX9jeNKvrE6qWzjzeZd1HdeT2tfS /dq6pBaXVU1K2J0Y0wmriTI5+vADYw3cv7rNhVMlWH0GX2nukBVt8xHNz9ywu1Cd XMhmtpXEljQN3mp3zABmXScwCLMcoeKGuQ7m/pcZq5VLQQ6+Nse+St+nLHeq7sh0 DrGZNtZv/KJTR07p2GRgE7K/Q0R8sTGrqukU9D6XnZ/lbsU2/+ADAKuh6O0rutYV HQRdZvdrTX3iggLijPI4/NARrmZmLLq0xwWY+u1W9FstRRN8uux5uAcnTkPGs1L8 PjC6fEyoXvSudT1SxT7Nl026rvSewuCAc8a2BIT4i9Pss3yetXx0ShGnoFC50OmQ LoBKHMC2PJ3Cz/3sIhMRQtZseI+Mf3CJev5nEQCJbBYB7uVgrYeAx+5UUwsehX2R JAkjj0/f/lcxMnkoIlTrzAmTBD5xwwe/aWKml+LS+BaRqYckgFd2x7WZ5w3GuofT uwajNHk+OOCsOW2kcwbl1nWOkEAGYI9LqcLpS7OcT6L5wt+crzyqZzq8ioramBNM 8RPpagWd+lBiqqw= =ZQ2K -END PGP SIGNATURE-
Accepted ntpsec 1.1.2+dfsg1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 02 Sep 2018 00:37:48 -0500 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.2+dfsg1-1 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Changes: ntpsec (1.1.2+dfsg1-1) unstable; urgency=medium . * Revert to old upstream GPG key * New upstream version - Use data minimization on client requests https://datatracker.ietf.org/doc/draft-ietf-ntp-data-minimization/ - Support AES-128-CMAC for authentication https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/ * Refresh patches * Drop get-orig-source rules target * Add --enable-warnings * Raise Standards-Version to 4.2.1 * Fix ntpviz to use /var/log/ntpsec Checksums-Sha1: d93e36e5e60ca8df45dba9c838443cd371f30b40 2402 ntpsec_1.1.2+dfsg1-1.dsc 28bc68c5e92d5dcfec743d3a5d6e2773f63614b8 2487994 ntpsec_1.1.2+dfsg1.orig.tar.gz a144c02f800078ed5ee188802c12d92c712206d9 43456 ntpsec_1.1.2+dfsg1-1.debian.tar.xz b40426777a0083eceedc83279dc72a1455777607 9475 ntpsec_1.1.2+dfsg1-1_amd64.buildinfo Checksums-Sha256: 034dd2572659db015b4f9d602c6097f1665e79fc771200468af55183de03e7c4 2402 ntpsec_1.1.2+dfsg1-1.dsc 6777340bc83893710de99661381566a5a049ba2dea6ea17fabaa13103d29f77f 2487994 ntpsec_1.1.2+dfsg1.orig.tar.gz 3fe2f04de4e03acd13ddcd6556f73615264e75ab65b004d02760b8dbe5f63185 43456 ntpsec_1.1.2+dfsg1-1.debian.tar.xz 36ba9fc346f84db43472dffe96517babfd5231780d75073d752b8e7d4db9c06a 9475 ntpsec_1.1.2+dfsg1-1_amd64.buildinfo Files: 4bc3c8224866a2f6f5036708780f0568 2402 net optional ntpsec_1.1.2+dfsg1-1.dsc e5ffecfbb561eeab6268ae404be420ee 2487994 net optional ntpsec_1.1.2+dfsg1.orig.tar.gz 588f79a5f7ed64093885a0f659eb35bf 43456 net optional ntpsec_1.1.2+dfsg1-1.debian.tar.xz a3c6cb7a71fd7661109de0e881b5affc 9475 net optional ntpsec_1.1.2+dfsg1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAluMVkcUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpaVTxAApXyBKoKj/jQHdHDrZKP7VRxMVH5N amSThb8HYSn50652adlzCUgd+gMMne5K1/GtPLr53MN9Th0LHRvXsp0yOWH3S/nT NPUKPG1ghhjWpticmkmETSNKeDwk/F5sPBDzfgq64/kIxrau5yVDPtbDgBeLyGAF irPF6Ahqi+3o4eyCXBScJvUPBVNOa+hzC1U4DGo9PjwBt8iCZ9sQcWDjXJYxCQzk xYtXPjCn5lwBoJwOM7mN1g8kyWTTMqBzCMxivY8UyvrH4kB5HBm4LaFEEOCC9yyV rqJ4oOx7F8sW0PMcbs8aCOkF5ZAHGiRTTx28LSxwDKQ6GsKxTUXZ/EXJRWCurIMM MH3pEaHYGnBKNi2JMFh+UnIXk4QtOm9o815rID0edgfMUpoaY3zlk/nBzVF/ii9E gjcsLxWo8j7NLBDXrQTkmyHVByhQYgKj6odBXqilYou5TZFeO5pVR4PSEvLkUSXF 5Iu4woQs173FPtXo/uOtjCrj9d+cZttKNQRqYB14OZSZHTp5zzSQJ9wzjvaDEA1W wYnlQ5PInRyf/qLXbG1o2W4PmvLUNROScE7YNXHPYmbAppH9OE1ee7Shszs+LJdH 7yUePMaNZUa6YwgUfcmcOgTd0JsVsXx0y2ThiebBWEwJu8iOtTeEoV2QUeRNmyEs G7gKjrLkayzqE+k= =wDww -END PGP SIGNATURE-
Accepted ntpsec 1.1.1+dfsg1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 07 Aug 2018 09:11:08 -0500 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.1+dfsg1-2 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 905678 Changes: ntpsec (1.1.1+dfsg1-2) unstable; urgency=medium . * Fix syntax error in ntpsec-ntpdate DHCP hook (Closes: 905678) Checksums-Sha1: 56f9d87b1dd06ee0957e57256481b528685a6f5d 2402 ntpsec_1.1.1+dfsg1-2.dsc 234a9ba4cd124551c83da3e18aa659a8682cf2d2 44192 ntpsec_1.1.1+dfsg1-2.debian.tar.xz 3611a3ff861addb6161bf4f809d2357c11fdfda6 9452 ntpsec_1.1.1+dfsg1-2_amd64.buildinfo Checksums-Sha256: 03abea3432d1a082115f3d0b1b21655657cf9154e1c3f8b6e597ef503c755f0f 2402 ntpsec_1.1.1+dfsg1-2.dsc 98605bba65d3589e0c16349c50b96603150de866e0b4a89d99ba002ff6e1a807 44192 ntpsec_1.1.1+dfsg1-2.debian.tar.xz 514dc2d9471429569c6f046d1836a4264a30fc170907b023a109d450aaf5d773 9452 ntpsec_1.1.1+dfsg1-2_amd64.buildinfo Files: 5a7d00ac8d029e50197ed49bd4705e6e 2402 net optional ntpsec_1.1.1+dfsg1-2.dsc 24d16d8c891377e6ceab7f3f5462b2a4 44192 net optional ntpsec_1.1.1+dfsg1-2.debian.tar.xz 690c4a6dedcd571120eb76b3b6a960d3 9452 net optional ntpsec_1.1.1+dfsg1-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAltqLuEUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpb8MBAAnL0G0gZsvHYRH604Lmc6+AlvbgKR gjstmlJxvFDby2tXfOSwTQZcLh50jnf0D4soo9El0StjZbLe8GvUrYLg3xOyhc+9 huhH4p3Sbwkw/HJdhiNTxwRIP93d93VC90WHmyJqfOYycHRiaMnj1NT3eh1SZW67 r3LsgC2blX98QUa3ZgkLji3RwmCqJ92FDopCPySJe4YifpbfedPLhDo8bdCDz8Tf tn7IiG0OtTzenZPraDZ/Qu5PaoXlZvPYzdoHDyf4mgz85PbFT8dimnV9Ow/KZQdS bfmWOd5hIiIhA2MN7QTrH2BVxWf+hxmZl7uNvZCZY6cP3WqWLdQSVfdxJLVSkTlA +ZwSrWNZiIYWiGN4IHhb/j0WKsyMBSx+p7uH4seJl2ZQJLY2oM0oAO3Gxsmpsb1x RHkjJvtSSCYDC8292VENtkBACrQWo+v+aCMIH+ciRjFGGBBs1M7RWw2S1qMYRVEb 28x1bHRkJY4cAPMSFWKCSeGuSlDT0CrKja4Gb3TrVNC9eXZXk8AXMHw+ygHKVUce MHk6sCnkSrNICdOqnspQ7sAGbhGEnIruCia8emx3etcEYUo3PiK+P2vdaHKQp0Z5 UktiJpxDk2RxCnG3QfDReb0GYY31u4MH5RaFM2CehayMuecOqiuknrA3AM1Mywrw Q27wvOakNZCfVsY= =u+NK -END PGP SIGNATURE-
Accepted ntpsec 1.1.1+dfsg1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 02 Aug 2018 22:04:20 -0500 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source Version: 1.1.1+dfsg1-1 Distribution: unstable Urgency: medium Maintainer: Richard Laager Changed-By: Richard Laager Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 893542 898402 Changes: ntpsec (1.1.1+dfsg1-1) unstable; urgency=medium . * Changes as of ntp_4.2.8p11+dfsg-1 have been merged as appropriate: - Drop old versioned build-deps. Thanks to Bernhard Schmidt - Sync AppArmor profile changes from Ubuntu. Thanks to Bernhard Schmidt * Update apparmor for new drift temp file * Drop preempt from Ubuntu ntp.conf * Use ntp.conf.dhcp if it exists, rather than only if it is newer than ntp.conf * Add an option to ignore DHCP-provided servers (Closes: 898402) * Update upstream GPG key * New upstream version - Log timestamps now include the year. This is useful when investigating bugs involving time-setting and -g. - Many internal cleanups to clear the way for upcoming major features. They should generally not be user visible. Refer to the git-log if you are interested. - Restore support for peer (MODE_ACTIVE) packets * Drop autorevision-related code * Refresh Debian patches * README.Debian: Update bit about dhclient.conf * README.Debian: Fix broken link to NTP servers * debian/copyright: Use HTTPS for Format URL * Update URLs in debian/ to HTTPS * debian/copyright: Merge in full CC0 text * Rename ntp service to ntpsec * Rename ntp-wait.service to ntpsec-wait.service * Rename ntp-rotate-stats.service to ntpsec-rotate-stats.service * Rename ntp-rotate-stats.timer to ntpsec-rotate-stats.timer * Refactor DHCP hooks. Thanks to Dimitri John Ledkov for the networkd example. * Rename the ntpsec DHCP hooks * Rename the files used by the DHCP hooks * Rename the ntpdate hooks * Add NetworkManager support for ntpdate DHCP hook * Remove ntpdate logcheck rule * Rename /etc/ntp.conf to /etc/ntpsec/ntp.conf * Rename /etc/ntp.d to /etc/ntpsec/ntp.d * Rename /var/lib/ntp to /var/lib/ntpsec * Rename /var/log/ntpstats to /var/log/ntpsec (Closes: 893542) * Add net_admin to the apparmor profile Checksums-Sha1: 90190021cfcec7aafef4b476c8e845d40b4df671 2402 ntpsec_1.1.1+dfsg1-1.dsc 95fffe104e168d3450b0b2d8d4fbe4f84c7b748f 2481572 ntpsec_1.1.1+dfsg1.orig.tar.gz a058c44a011abec301321be7a832e3c6f5764d2d 44152 ntpsec_1.1.1+dfsg1-1.debian.tar.xz fcde0134ef31032a26972801dda38c33cda293af 9454 ntpsec_1.1.1+dfsg1-1_amd64.buildinfo Checksums-Sha256: 74c10eba5135d058dbedbd8f046acc8a45ee1754727564c6c2f5537e4142be89 2402 ntpsec_1.1.1+dfsg1-1.dsc 6c6480f86bdc7c5c80fe0f64989441a85487e5cd03b27869ee65eeaa6f93ab0d 2481572 ntpsec_1.1.1+dfsg1.orig.tar.gz 78b1ebce9232190e7bec5726960bbf319fb4a5ce28e339080c2f4e5dfdc81267 44152 ntpsec_1.1.1+dfsg1-1.debian.tar.xz 197d515760e7388e1df7535e683b2179f50d63a20855043797c9a5b39c4c0e63 9454 ntpsec_1.1.1+dfsg1-1_amd64.buildinfo Files: c903774a25764ca9dae89a867901ebcd 2402 net optional ntpsec_1.1.1+dfsg1-1.dsc b25f7e70f9b9f962e36921ce911b1ee1 2481572 net optional ntpsec_1.1.1+dfsg1.orig.tar.gz 86a53dce10201ca6aaf6859f6ad43378 44152 net optional ntpsec_1.1.1+dfsg1-1.debian.tar.xz 438d944597041b1b8e6d5141f1010110 9454 net optional ntpsec_1.1.1+dfsg1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAltmcjEUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpbt7hAApsZr/dP16RFK6sWVmF8iszBvAF9H Mr8sgH9YamoqnlvRi28oS1lc8amoEdfNiZ7NPsgzEliMBxjqzZQ24ht5hHDI40Sm axCTYeQn8i2AJhGkCasLtBIR3S0F618GDOi8VSYBNzomtIiOh51kQlyKZ5r78KXZ UmryDzGrG/qTZeT9NKMkFXmkoxmHxAaam4hNhySBcZc4gFZnMYNV7/P27zz6G+hx hF4uNbGCUhR56lMoiLZTIoFvysWKsPQ0yqjs83hW6NUInqgNl4rgQiwlfr76WjOZ 2sWlGt9ROydwq2oeHiiY6QR4I+JqkIc9nCJfB0LLNdja3WCY+ooFS0JJcrkSAYMm BsfIw0tdlQrkYEvIEdmB4CKlyB2qDNAQuTqPgJu0H7cs/ilO2e13X1R77Iyg9XpH 93wpmHcpIAJP4Wv8RDl9HyjgcfSt/xWK2Iyc0jJKpS4PrNFHn47cmQZi8skcJ7w5 cqDuhabAkV+8g6uSqkEpmbVi39eFHNqDqO5NgUC6IDFGmOw3qiz8ohqjzSY6SmAb 74TxnwTVwX0BWBvS0zHBw2jSwHO/5dnVs2cbAR47cG2QDjeTYwr8rAyQZv7N/JcP vXAalsqxrpQrDZTiXdI1lmdgsIMGV2nDqv8ngagKRMcQC17kZkgF/bhGzpjzk0bU SM0l+aUud4mbSsI= =A6uu -END PGP SIGNATURE-
Accepted ntpsec 1.1.0+dfsg1-1 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 16 Mar 2018 00:42:24 -0500 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source amd64 all Version: 1.1.0+dfsg1-1 Distribution: unstable Urgency: medium Maintainer: Richard Laager <rlaa...@wiktel.com> Changed-By: Richard Laager <rlaa...@wiktel.com> Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 892966 Changes: ntpsec (1.1.0+dfsg1-1) unstable; urgency=medium . * Make ntpsec Conflict with ntpdate - Use ntpsec-ntpdate instead of ntpdate. * Stop deleting /var/lib/ntpdate/ (Closes: 892966) Thanks to Bernhard Schmidt <be...@debian.org> for the suggestion. * New upstream version - Digests longer then 20 bytes will be truncated. - We have dropped support for Broadcast servers. - A bug that caused the rejection of 33% of packets from Amazon time service has been fixed. * Drop patches merged upstream - fix-ntpdig.patch - systemd-remove-extra-dependencies.patch - fix-name-of-psutil.patch - fix-spectracom-log-prefixes.patch - fix-ntpviz-file-encodings.patch - systemd-remove-remainafterexit.patch - systemd-use-high-priority.patch - systemd-ionice-ntpviz.patch - systemd-cleanup-ntp-wait-service.patch - fix-ntploggps.patch - systemd-use-usr-sbin.patch - systemd-do-not-restart.patch - systemd-allow-running-in-containers.patch - Merge-Classic-fix-for-CVE-2018-7182.patch * Update copyright Checksums-Sha1: aaf97c2ee09c1d7ab7023c5892adb30e23884627 2440 ntpsec_1.1.0+dfsg1-1.dsc ac613a395d0e22ecd07c19b2eea6f6a740b891d3 2473481 ntpsec_1.1.0+dfsg1.orig.tar.gz c8eb6829a2670de181a316202cf60333b282ab3d 41340 ntpsec_1.1.0+dfsg1-1.debian.tar.xz 7969df35af303358bc6bb2797886c28c7f9cf0b9 604392 ntpsec-dbgsym_1.1.0+dfsg1-1_amd64.deb 25300674746f67799b47008b6fe183c50b460cd9 1225884 ntpsec-doc_1.1.0+dfsg1-1_all.deb b7097daf4acabbe146c29730eec1561341a80b84 30220 ntpsec-ntpdate_1.1.0+dfsg1-1_amd64.deb 122546faf60fa389d207c2cae65f1e9c6e60b60f 47668 ntpsec-ntpviz_1.1.0+dfsg1-1_amd64.deb 252d618e8fce8bd0b2c334e673aa3329d74d957f 9183 ntpsec_1.1.0+dfsg1-1_amd64.buildinfo b01bc0cde946d7c11e7d53fe8047118a6b4662a7 282592 ntpsec_1.1.0+dfsg1-1_amd64.deb 4a020497dc97a0bfeb070c4cfe8fdf739b07e6ee 62120 python3-ntp-dbgsym_1.1.0+dfsg1-1_amd64.deb 5c3db4cd1b7f2a7f1fe0bf57254188d9ebaf6230 77320 python3-ntp_1.1.0+dfsg1-1_amd64.deb Checksums-Sha256: cd35145728431484e0044896b22154733e1a239483a8002a73738f94de16 2440 ntpsec_1.1.0+dfsg1-1.dsc 459f3eb870521d124fbcf27dcd1757dd895345cb0ad93eb4c215e39be61d082a 2473481 ntpsec_1.1.0+dfsg1.orig.tar.gz 4bf44ce785b80deab095549ac2c3809a2db9eb3f1d6716648db21cceb6cccf17 41340 ntpsec_1.1.0+dfsg1-1.debian.tar.xz 43b1488922297660b7ed649009460434cb0755ddd05c1d66f7bfcba67bc1549a 604392 ntpsec-dbgsym_1.1.0+dfsg1-1_amd64.deb aeb8acd7c325084fdcf87f1244b54b5ee2c6efc44fc016aab6c2881465eedf2c 1225884 ntpsec-doc_1.1.0+dfsg1-1_all.deb 5cc537fecb1519fd0a449e41210356a193f17fc6ba07febc2e5af0a6ba422f42 30220 ntpsec-ntpdate_1.1.0+dfsg1-1_amd64.deb 2dc89c3388ca9a5d09d30298ec954ee9ed979f3dc5c7685895d4030b75f6598f 47668 ntpsec-ntpviz_1.1.0+dfsg1-1_amd64.deb d739a6c5e536d2a9893023d49c7e3d49c738c89d6e257ca52e83c40134213092 9183 ntpsec_1.1.0+dfsg1-1_amd64.buildinfo 3fd1ae2c9b565e5237f9ca316f655d2291feea874dc8a613529b3df69262005a 282592 ntpsec_1.1.0+dfsg1-1_amd64.deb c345a611b2e65a841609cb7401014fc26469c9698a15bcc3dbc3ba96736a128f 62120 python3-ntp-dbgsym_1.1.0+dfsg1-1_amd64.deb 924881ad11b0580ab3817c31d5c5a1115469c23b8b5a5478942c79410f517b3d 77320 python3-ntp_1.1.0+dfsg1-1_amd64.deb Files: 9f146c0ae0603a4623039681c61f2772 2440 net optional ntpsec_1.1.0+dfsg1-1.dsc 0435bc58be05315661aa1efcce1c5129 2473481 net optional ntpsec_1.1.0+dfsg1.orig.tar.gz 5d60be01c9c965fb7329e1f0880977a1 41340 net optional ntpsec_1.1.0+dfsg1-1.debian.tar.xz 0a0c9a02662aa7b687c99414246b067d 604392 debug optional ntpsec-dbgsym_1.1.0+dfsg1-1_amd64.deb 9197770867c218e0a381813378f58540 1225884 doc optional ntpsec-doc_1.1.0+dfsg1-1_all.deb 518a3db628abd259b4f5937a51acd5c5 30220 net optional ntpsec-ntpdate_1.1.0+dfsg1-1_amd64.deb 1ff85c8f68a14b12814f7fdf293b2838 47668 net optional ntpsec-ntpviz_1.1.0+dfsg1-1_amd64.deb 3d479f7c7c9e1fefdd1ffb5a7320c29f 9183 net optional ntpsec_1.1.0+dfsg1-1_amd64.buildinfo d491e1a65a24a27537be46d80f118335 282592 net optional ntpsec_1.1.0+dfsg1-1_amd64.deb 800de817fb81adb2dd3a821f23a1fe4e 62120 debug optional python3-ntp-dbgsym_1.1.0+dfsg1-1_amd64.deb 71de992e6958fba2b8619cee46271c02 77320 python optional python3-ntp_1.1.0+dfsg1-1_amd64.deb -B
Accepted ntpsec 1.0.0+dfsg1-5 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 07 Mar 2018 19:47:34 -0600 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source amd64 all Version: 1.0.0+dfsg1-5 Distribution: unstable Urgency: high Maintainer: Richard Laager <rlaa...@wiktel.com> Changed-By: Richard Laager <rlaa...@wiktel.com> Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Changes: ntpsec (1.0.0+dfsg1-5) unstable; urgency=high . * Fix CVE-2018-7182 Checksums-Sha1: 371ad5b8bd42445f141f8a3dd63048b6326faa21 2440 ntpsec_1.0.0+dfsg1-5.dsc eca9a85ae0341bdc572a755c8dac26655ffe7853 47820 ntpsec_1.0.0+dfsg1-5.debian.tar.xz 7bb99f3d1f9a5010a580ee674fa361d53bb65d15 613800 ntpsec-dbgsym_1.0.0+dfsg1-5_amd64.deb 46cd6f7d943fb293ba40ca11c316d0e7195435ec 1208284 ntpsec-doc_1.0.0+dfsg1-5_all.deb 900ece39844095c9e0033142b61e14eda435382e 29824 ntpsec-ntpdate_1.0.0+dfsg1-5_amd64.deb f542984b71336be54e4274b03844151820aace8b 47080 ntpsec-ntpviz_1.0.0+dfsg1-5_amd64.deb 6bab764d3b8edb06bde28dca9235b4b16d3bc175 9141 ntpsec_1.0.0+dfsg1-5_amd64.buildinfo 81997f991736b76ac2452dabf96d7fe3beff1587 282176 ntpsec_1.0.0+dfsg1-5_amd64.deb 0a30619947933d5c98560d4b8ba21e888e9c0786 66400 python3-ntp-dbgsym_1.0.0+dfsg1-5_amd64.deb 32303a63c8a48f6a67efa4cc24a72f4e8ccf5238 71660 python3-ntp_1.0.0+dfsg1-5_amd64.deb Checksums-Sha256: df239d8164baa0f4f86271fb895ab711ebfea935fc5392478571f66bbab613a2 2440 ntpsec_1.0.0+dfsg1-5.dsc 5f12505d4505fea875e33ed17ab2a3466b612db31aa51e05f66ac09913fb8f35 47820 ntpsec_1.0.0+dfsg1-5.debian.tar.xz b5907e0fd93bce28c0a41935b5dd52e8d260f7488c08b7a3b24c4d3ad5a30bd8 613800 ntpsec-dbgsym_1.0.0+dfsg1-5_amd64.deb 86813108223e947dee708ee41ab7c28c095a941e13368020ccbcaca7f0516a41 1208284 ntpsec-doc_1.0.0+dfsg1-5_all.deb 0376da377bb7e48777d923a5a9ec967bd6dc90c8c04204cdc7e9a6258ec98e46 29824 ntpsec-ntpdate_1.0.0+dfsg1-5_amd64.deb 3e6b9c57038d77e8e213af8c74209f9f1142b0e88c3831ec36f94b5ca53863cc 47080 ntpsec-ntpviz_1.0.0+dfsg1-5_amd64.deb f2a0164695304bebbcad7dc777248c6cc32da56258f773bc40299044d7eeecc6 9141 ntpsec_1.0.0+dfsg1-5_amd64.buildinfo 410038c3dd2aa598770a23448a578e07071caf8f20335075282a260c5fb32447 282176 ntpsec_1.0.0+dfsg1-5_amd64.deb 1e22c3cd3aa80484aa51b3e3a9285858e2ef1b2902c2662b9502d35eb3a8ad60 66400 python3-ntp-dbgsym_1.0.0+dfsg1-5_amd64.deb ac1218ef00591b00050b63fcd21640293792fee4d090521358af698effbd1135 71660 python3-ntp_1.0.0+dfsg1-5_amd64.deb Files: feba07c7f1ea293de7a0d8e555168db7 2440 net optional ntpsec_1.0.0+dfsg1-5.dsc c6a61b732f00ab03af6461ad0f55daba 47820 net optional ntpsec_1.0.0+dfsg1-5.debian.tar.xz 034a6cfbef5ae58f5d3dec01feb8008d 613800 debug optional ntpsec-dbgsym_1.0.0+dfsg1-5_amd64.deb d197e25bd18e158c2ef2f6af1f54b9c8 1208284 doc optional ntpsec-doc_1.0.0+dfsg1-5_all.deb 59a837b522ba1a7940dd1877a2a1d4a7 29824 net optional ntpsec-ntpdate_1.0.0+dfsg1-5_amd64.deb d6883a176a42d7adc4cdcedf0c001337 47080 net optional ntpsec-ntpviz_1.0.0+dfsg1-5_amd64.deb eff5a1397c5187ecbaf2dee7371aead0 9141 net optional ntpsec_1.0.0+dfsg1-5_amd64.buildinfo 74adc58327664ebe1d3f4040de27c4f5 282176 net optional ntpsec_1.0.0+dfsg1-5_amd64.deb eb2de7e7d96c02a20a222696511e3b53 66400 debug optional python3-ntp-dbgsym_1.0.0+dfsg1-5_amd64.deb 1ad4c6fe13b5b45f45fdc2bfade58154 71660 python optional python3-ntp_1.0.0+dfsg1-5_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlqgyaAUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpanyBAA0jmu9tQmkGXvkbwNho+y5VyHgpLJ 6++IHV7S8mK32GO+emQRTMsgRlYY3wrgV190oFiHDaVB1fCIoKmvaX5+WF7xsKcR mexpCy7b7yNWy+a6IRz3+UAhx+zZclnmO6JEDtQ/vNVsPBncHoj1dbvdz3okCc6T GgwlodtxdvY/JkjLxxLqt9CxA2wYw7Szgtr03+RU1D055dawBdwO5ifx12gBA915 /sJoYaOE0rvMULNDeqowPA1kZcVqxL34HgycHpVsSNw3NGTO85ji8rN5q/zA9O/W 2gwIhSeUGPGuYDB59tgwlAVMO6aJnyEelv4mvfbxNd3xGW5ZAOL+s0ETrFyffzfx k56yKbSs9oihFiH5G2u/9ECBs1Nef6M25qfoDeQfeocokpXiP0GH9zNpZO3qwyKX 4b8T66le3VrLf0lKQNgr2Q3Zg3UbyZrB+JyP9ut62YEpoh0H7aRR2wVifuWCJLYY d25qY8HZHXoYpEwZxK5aP7/9+I7b1yXlqmYAcIKGxenogXVXFM4vq4AXPBfDdYmR SVyMEP7p6bHLwjZ8uYzKumXujXmn7MSmfBrTavo9SJtvKFbIOIMx6VW7GvEhCuZK 6aBCUo7BGIVvh4xKYFEfbLbGoeu6J9n2KexlJJn4oMMDp43R7kdCCc1lG/ohxWoq Z83+L0jOMwxU6b8= =hXAS -END PGP SIGNATURE-
Accepted ntpsec 1.0.0+dfsg1-4 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 04 Mar 2018 15:06:58 -0600 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source amd64 all Version: 1.0.0+dfsg1-4 Distribution: unstable Urgency: medium Maintainer: Richard Laager <rlaa...@wiktel.com> Changed-By: Richard Laager <rlaa...@wiktel.com> Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 890771 891278 Changes: ntpsec (1.0.0+dfsg1-4) unstable; urgency=medium . * Remove empty /var/log/ntpstats on ntpviz removal * Fix installing ntpsec-ntpviz without ntpsec (Closes: 891278) * systemd: Allow running in containers (Closes: 890771) Checksums-Sha1: 5055303e498f76eb6611dfc831a7753c2f5f81b9 2440 ntpsec_1.0.0+dfsg1-4.dsc f28664fb569621deafb1f45b6c7ebfcc9f3e5629 45844 ntpsec_1.0.0+dfsg1-4.debian.tar.xz 2ceb6be558e2edf42eefaf6927b64adca42c52b8 613952 ntpsec-dbgsym_1.0.0+dfsg1-4_amd64.deb 6902f3f372e55a0b7206902c756de735bdd9c58c 1208112 ntpsec-doc_1.0.0+dfsg1-4_all.deb b7e676025fb47bd3e6ee2c563d007e616bb94cd9 29768 ntpsec-ntpdate_1.0.0+dfsg1-4_amd64.deb 687e4ba7eb2786294f27abd2d5aa5bc257a594f8 47068 ntpsec-ntpviz_1.0.0+dfsg1-4_amd64.deb af8d232d0dcc0e785a359ed8a019db4dc261972e 9141 ntpsec_1.0.0+dfsg1-4_amd64.buildinfo 7b4e9006a4021d9691db4b4aae87b1a6b159c5e0 282448 ntpsec_1.0.0+dfsg1-4_amd64.deb b10a8606595931bf2016e908c92287feb02fecce 66396 python3-ntp-dbgsym_1.0.0+dfsg1-4_amd64.deb 743b29968b75c449d5faff3232f98a6261ad0b11 71596 python3-ntp_1.0.0+dfsg1-4_amd64.deb Checksums-Sha256: 499db647bda890eacca5c674717b87e0dfcb3859df929634ebf8dea7752a37a4 2440 ntpsec_1.0.0+dfsg1-4.dsc d2e03dfb515d192d092d1d4d580177ebda3b86134dc7061ad1db383397c17da6 45844 ntpsec_1.0.0+dfsg1-4.debian.tar.xz 460bcea18728734b510dc14c531cacd4eefb4e17fc972de8e647c23ede69ffd3 613952 ntpsec-dbgsym_1.0.0+dfsg1-4_amd64.deb cfc28431bd29484d4d57c8247d5cb913affb9030b7ec3af9b171b764e7b75385 1208112 ntpsec-doc_1.0.0+dfsg1-4_all.deb 5fffa4489c8b9a790ee470c7f96dbfd9dd24f00359a5a4bc974ec82a40ce3c62 29768 ntpsec-ntpdate_1.0.0+dfsg1-4_amd64.deb c850e4695e34bea0852589951b827dab5eccfcbc1567fe16bf413ea51695898d 47068 ntpsec-ntpviz_1.0.0+dfsg1-4_amd64.deb b39c2731920c5bff0a69669aca6d0bd68af9cb0bb380e9d55db89923d4fbe536 9141 ntpsec_1.0.0+dfsg1-4_amd64.buildinfo c51e2988e0acbf3ae410aa7af67eb38940d01a3d3398dfe77c5712eae2cbe4bf 282448 ntpsec_1.0.0+dfsg1-4_amd64.deb 53815730a51fa0b9e3c2a91fec63a7d815d38b4378de5a350bd3e0b3f9fdd5e9 66396 python3-ntp-dbgsym_1.0.0+dfsg1-4_amd64.deb 64810a705e59ee7756dccb468aec456df800ec96ec7976a5e79ad2389d23168e 71596 python3-ntp_1.0.0+dfsg1-4_amd64.deb Files: 96b5dce7e03fa23e21e63f7e8bd97ddd 2440 net optional ntpsec_1.0.0+dfsg1-4.dsc e73146632553ea7b7d0d95fb2bc8ac71 45844 net optional ntpsec_1.0.0+dfsg1-4.debian.tar.xz ec2c72d4c1d487ef2f50fb97af75f641 613952 debug optional ntpsec-dbgsym_1.0.0+dfsg1-4_amd64.deb 1972841fd1759bdef496f00f83913e56 1208112 doc optional ntpsec-doc_1.0.0+dfsg1-4_all.deb 3a40967c4574eeb61fb24a6091bb6af3 29768 net optional ntpsec-ntpdate_1.0.0+dfsg1-4_amd64.deb 61f978b1ccf357ca2ece352900b17ac4 47068 net optional ntpsec-ntpviz_1.0.0+dfsg1-4_amd64.deb c213fe1edbfbf3cb4f17a9e03e0eec40 9141 net optional ntpsec_1.0.0+dfsg1-4_amd64.buildinfo cab99512d3bb95b221011da3e171a336 282448 net optional ntpsec_1.0.0+dfsg1-4_amd64.deb 79bbb2cff031b1e0a04fda402a79e4e9 66396 debug optional python3-ntp-dbgsym_1.0.0+dfsg1-4_amd64.deb 7644f7832c8f109366a6133e3a12e0b8 71596 python optional python3-ntp_1.0.0+dfsg1-4_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlqclH8UHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpYGfA/6Aq+OWvsNNC1t8mvg6QoeHQeLBjuW BxgXIzDKrm2R6BoABpmMFsCrOsUnuIFddY4d3+ZuVKBXqGALquLC6n1E7YZt9GO6 3wgIp7S1cjPyA/iI3Mj2WTTjnCoddu5PeNX9OdBlGYLXz6XH8H7sRd51MWKbLDbO 0J/VYVVThpQYNna85BSp16esPCVoxMepOFeiYnTbfkYsds0FC1jtCHEF+YYEQK6h USGYuyw+m63F3LSly7LgJnehg5OJVu4EjbvAdzckZd3GZ/DfzkMjQn5jba9w3TWY fGu2UOBpXdvHhf1FT2blQJ8BX04K5vh65m+9VfJZYAA0ZB1EkVNVY5inw+x6nQ6l rl1oYFUyyrlXAEMK2rzFHicqr27IbQatKG7QVjsHu3tbOMMLNYUOjM7U9cWYaSAU w4MQBzb3Ij0BTlVe45Cf3c9H3PPHPDdL9qglfJVLQ+myGJ3CzMPCgPpgtkYtbQw3 DnulpvmFPtjpbA3H2kQkvQlk5WwzwFs/nvoD+IoFPi6NQgCMWpyEARbsVayf18jN z160xR/9AmkAU7zKEzav5W7lvF3ejqfVp03I6jRUeWzfIR0nyra+o8VB2DyaBSt5 B1TNbsDpt7Cq5XycgGbY+cl0uTiMjrDImEirkFx/vw7+rIwP6vLO7k5PBPbXBEuD 6aB2nAGBaRIfxWQ= =c6GZ -END PGP SIGNATURE-
Accepted ntpsec 1.0.0+dfsg1-3 (source amd64 all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 21 Feb 2018 00:29:24 -0600 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source amd64 all Version: 1.0.0+dfsg1-3 Distribution: unstable Urgency: medium Maintainer: Richard Laager <rlaa...@wiktel.com> Changed-By: Richard Laager <rlaa...@wiktel.com> Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 890758 890761 890762 890770 Changes: ntpsec (1.0.0+dfsg1-3) unstable; urgency=medium . * Add Vcs-* headers * Update Standards-Version to 4.1.3 * Improve debian/copyright (Closes: 890758) * Bump the autorevision version requirement (Closes: 890761) * Fix FTBFS when building arch-indep only. Thanks to Daniel Baumann <daniel.baum...@progress-linux.org> (Closes: 890762) * Make ntpsec-ntpdate depend on python3-ntp (Closes: 890770) * Inline the SHM message in README.Debian * Add note about AppArmor tunable in README.Debian. Thanks to Bernhard Schmidt <be...@debian.org> * Drop historic Breaks/Pre-Depends. Thanks to Bernhard Schmidt <be...@debian.org> * ntpsec: Stop creating /var/log/ntpstats * ntpsec-ntpviz: Add Suggests: python * Create /var/lib/ntp in the postinst * Do not recursively chown /var/log/ntpstats * Suppress a lintian warning * Drop historic apparmor Suggests/Breaks/Replaces * Changes as of ntp_4.2.8p10+dfsg-6 have been merged as appropriate. . ntpsec (1.0.0+dfsg1-2) unstable; urgency=medium . * debian/apparmor-profile: add attach_disconnected. Thanks to Christian Ehrhardt <christian.ehrha...@canonical.com> * Fix reading the drift file on startup * Drop the ntpwait "quick mode" patch Checksums-Sha1: c3b2ac0b3e7a2a28a878f60683cb52f8142ed99a 2440 ntpsec_1.0.0+dfsg1-3.dsc 45158062017c5cfc12fd7342fd3cd740f679bbdf 45064 ntpsec_1.0.0+dfsg1-3.debian.tar.xz a4c7f674277a34d17a8169154f41294f9a5eb22d 616600 ntpsec-dbgsym_1.0.0+dfsg1-3_amd64.deb 0b4e8ee9b83acb75fa12e4e19ced65813db94545 1208004 ntpsec-doc_1.0.0+dfsg1-3_all.deb b2b9be3178ef10518772968aae89eaa7ea05ac58 29684 ntpsec-ntpdate_1.0.0+dfsg1-3_amd64.deb 21a19bf4f4b9838aee68bd1a7dda50e89b97c46b 46576 ntpsec-ntpviz_1.0.0+dfsg1-3_amd64.deb b8087ab155406835987c0d8153c10987281b9699 9143 ntpsec_1.0.0+dfsg1-3_amd64.buildinfo 6790d34b04e2749778c46bffd37db419c4b3 282224 ntpsec_1.0.0+dfsg1-3_amd64.deb 14e7b4a9f95374c3b1fc4022a42289617d32cf5e 67064 python3-ntp-dbgsym_1.0.0+dfsg1-3_amd64.deb 1688a26fce9b995fe67e28e9b64a882523a3c151 71544 python3-ntp_1.0.0+dfsg1-3_amd64.deb Checksums-Sha256: a99a619dcffbab42df7309faddcc9471bfff0e6672eb56048e7cc727e388f56d 2440 ntpsec_1.0.0+dfsg1-3.dsc 641c41b752bd0b6114fb0b91f1aaffc485ceef3ded766722defd1f9dc04d2dc6 45064 ntpsec_1.0.0+dfsg1-3.debian.tar.xz acc6438b0eec686b6b95e29300321b7dfccc10cec38fd7942995cce1b5776cba 616600 ntpsec-dbgsym_1.0.0+dfsg1-3_amd64.deb 0525c9cf3dcd45bc35245f80d8b8746f28da2db442f17dfa6be9696ce47a2a60 1208004 ntpsec-doc_1.0.0+dfsg1-3_all.deb 7885c7985c4b311d8f2dc93d158f65c8cd35f4a1929dae65a92dd0c4b2178842 29684 ntpsec-ntpdate_1.0.0+dfsg1-3_amd64.deb 41f25c5f62d1147350d60afad6911d3963559cb85e28bf85fe37bbfc37112308 46576 ntpsec-ntpviz_1.0.0+dfsg1-3_amd64.deb 9cc9afb85d6a5f0186cb2249d7328c8f834acfc8064294e0e08f6fa9b5eb2f78 9143 ntpsec_1.0.0+dfsg1-3_amd64.buildinfo 4669594a437cea913ee25572beb471b7565dc861e4bce351d476231437b4a63d 282224 ntpsec_1.0.0+dfsg1-3_amd64.deb 6a0481424bdf0b3f50a99bf32d7dad869d8a113188be9d1e69936017812d7f85 67064 python3-ntp-dbgsym_1.0.0+dfsg1-3_amd64.deb 73560330c440b2aeab957141189609d02494954bdcb269f982805eca1ed5ea29 71544 python3-ntp_1.0.0+dfsg1-3_amd64.deb Files: 619664deb323a5687ce04b252eb5361e 2440 net optional ntpsec_1.0.0+dfsg1-3.dsc f76a15ec7058cb72b50dd5879ec0dac3 45064 net optional ntpsec_1.0.0+dfsg1-3.debian.tar.xz 9cd9474a78177f0cc65becc05c0cc309 616600 debug optional ntpsec-dbgsym_1.0.0+dfsg1-3_amd64.deb a9516ffe3938c6e4a028b545dbef9b6f 1208004 doc optional ntpsec-doc_1.0.0+dfsg1-3_all.deb 769ae1087f0e9af8d714988375c06e12 29684 net optional ntpsec-ntpdate_1.0.0+dfsg1-3_amd64.deb e15d97f2db39308b3a0f042bec71032c 46576 net optional ntpsec-ntpviz_1.0.0+dfsg1-3_amd64.deb 4141af1ac63d0c7ff326537481d0f431 9143 net optional ntpsec_1.0.0+dfsg1-3_amd64.buildinfo 5f18d2dc288080ccb1794da40ae50e56 282224 net optional ntpsec_1.0.0+dfsg1-3_amd64.deb db42d3eb49d99128014be2a0aabd5f28 67064 debug optional python3-ntp-dbgsym_1.0.0+dfsg1-3_amd64.deb 0ff571e69174751d581a818696bb0f6c 71544 python optional python3-ntp_1.0.0+dfsg1-3_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlqOURoUHHRtYW5jaWxs QGRlYmlhbi5vcmcACg
Accepted ntpsec 1.0.0+dfsg1-1 (source amd64 all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 30 Nov 2017 21:29:52 -0600 Source: ntpsec Binary: ntpsec ntpsec-ntpdate ntpsec-ntpviz ntpsec-doc python3-ntp Architecture: source amd64 all Version: 1.0.0+dfsg1-1 Distribution: unstable Urgency: medium Maintainer: Richard Laager <rlaa...@wiktel.com> Changed-By: Richard Laager <rlaa...@wiktel.com> Description: ntpsec - Network Time Protocol daemon and utility programs ntpsec-doc - Network Time Protocol documentation ntpsec-ntpdate - client for setting system time from NTP servers ntpsec-ntpviz - NTP statistics graphing utility python3-ntp - Python 3 NTP Helper Classes Closes: 819806 Changes: ntpsec (1.0.0+dfsg1-1) unstable; urgency=medium . * Initial release. (Closes: #819806) The packaging was originally forked from ntp_4.2.8p8+dfsg. Changes as of ntp_4.2.8p10+dfsg-5 have been merged. Checksums-Sha1: cadca012caffed095533fbd75a609fbd616b9f20 2338 ntpsec_1.0.0+dfsg1-1.dsc 39e4541fb82cae0ee62d40ac5d3af392a041c98d 2432946 ntpsec_1.0.0+dfsg1.orig.tar.gz 6d11a39098f6972c09beafe7e287face303d1612 45460 ntpsec_1.0.0+dfsg1-1.debian.tar.xz fa03cbdbc49545cf1ee1085eb5ac55bf14475c96 616408 ntpsec-dbgsym_1.0.0+dfsg1-1_amd64.deb be987eca0e773d548bd63108779d05dad609e512 1207212 ntpsec-doc_1.0.0+dfsg1-1_all.deb bcb00cf5f652e1b8e3b2d121c86b0bd617be063a 28288 ntpsec-ntpdate_1.0.0+dfsg1-1_amd64.deb c3bbd3a5df30c6004209f98013c9835856f6eb35 45240 ntpsec-ntpviz_1.0.0+dfsg1-1_amd64.deb 20030e1d2e71f6daee4198c71f66873b667cc19c 8982 ntpsec_1.0.0+dfsg1-1_amd64.buildinfo bb6d3b35fa51191e40d1e157e9fd4935ab7eca2b 280820 ntpsec_1.0.0+dfsg1-1_amd64.deb 74b9ccddd9d22c730bfdcea0aff5129321237d0b 66640 python3-ntp-dbgsym_1.0.0+dfsg1-1_amd64.deb ca2e82896ac2a6515d238b4a9c2eb9a53c5fd7f6 70136 python3-ntp_1.0.0+dfsg1-1_amd64.deb Checksums-Sha256: 1e03c9f090ee72c132e7e9450138b3c54c652ab3922d3c1cc5b1d240764823a7 2338 ntpsec_1.0.0+dfsg1-1.dsc 2c1a255170f701b56b4f823c9d31ef4a0df0c5f7cfafa4e87ffbee9d7fb7d3a0 2432946 ntpsec_1.0.0+dfsg1.orig.tar.gz ff5bf1274101b1862fe9037537ce9bdc3811c521b3c8898bdfb5e8f35f319ba2 45460 ntpsec_1.0.0+dfsg1-1.debian.tar.xz d0234969b2e185c5d18db919cae3278b5c56fe75f142339d6c1453c0cd9a786b 616408 ntpsec-dbgsym_1.0.0+dfsg1-1_amd64.deb d8d482925fc69590ce12ea2bb034af1e3549a99092098d307bcaca4a005c5bf5 1207212 ntpsec-doc_1.0.0+dfsg1-1_all.deb e7bb72369812f6f4d859b764dab984de899a936831b729eb58a562462f912d0f 28288 ntpsec-ntpdate_1.0.0+dfsg1-1_amd64.deb 727ac2f7e82c144b2d3ece256512762dc45489d8c7be8bba929349bd3f2056a8 45240 ntpsec-ntpviz_1.0.0+dfsg1-1_amd64.deb b05fa8c5512390a7962c8ac59bbb2dcade2db72bd0df4f680b0bce881a46e987 8982 ntpsec_1.0.0+dfsg1-1_amd64.buildinfo 8aa48833c41dd0db18d969fe9d8d92c9d80156aedaa8b35934538deb8309f583 280820 ntpsec_1.0.0+dfsg1-1_amd64.deb 097cb1934eb374613a25e4b04b1216abf5427a54d6c89333d1c7f1a3ec303b98 66640 python3-ntp-dbgsym_1.0.0+dfsg1-1_amd64.deb b003503119ec2ed446ae166a90fed09d897daeb131aec08c4ee8544f739a716c 70136 python3-ntp_1.0.0+dfsg1-1_amd64.deb Files: 855ef0e68dfa96764241639c1e478b46 2338 net optional ntpsec_1.0.0+dfsg1-1.dsc c6aa831c5732898293963a7e22d74859 2432946 net optional ntpsec_1.0.0+dfsg1.orig.tar.gz a87821afd1679f19460db888c981a86e 45460 net optional ntpsec_1.0.0+dfsg1-1.debian.tar.xz c098813030c8d1d55e56b001e056f7a0 616408 debug optional ntpsec-dbgsym_1.0.0+dfsg1-1_amd64.deb 9740e5db2d527ae21baf12b3fb80a30f 1207212 doc optional ntpsec-doc_1.0.0+dfsg1-1_all.deb 6bbf769d0ebf63ff8cb81aa0eb6f1036 28288 net optional ntpsec-ntpdate_1.0.0+dfsg1-1_amd64.deb 7ab0a8ea7f6c0db03d14dc95973bacf4 45240 net optional ntpsec-ntpviz_1.0.0+dfsg1-1_amd64.deb cd000489fa453556d6ba697c34e2c60a 8982 net optional ntpsec_1.0.0+dfsg1-1_amd64.buildinfo 93abc9848382950e3bd00365c0835fe9 280820 net optional ntpsec_1.0.0+dfsg1-1_amd64.deb 516389225e7bb35e0c4a927b3e734551 66640 debug optional python3-ntp-dbgsym_1.0.0+dfsg1-1_amd64.deb 624ece3b3f83fd38cf2aff60b0f00444 70136 python optional python3-ntp_1.0.0+dfsg1-1_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAlohZ+AUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpYrjw//flFuFXWk3TVMhveA/Si7SDQpHj/W uF34yJgzVTr4T/VRLRQ8R9cE9vfV61JN4HibNP1CWsKsT/xqNeuUsUqbp33v31JD MiNdACTvCbFhQqbrCWOOio2x0sOAr3fn08CK6jyWpiZviVhg/wzjmHWzKGenUH1n HUnlqZZDit0kFVMdXOM8nsFsAecwKUZFZWs6c7PN5xqx8sdhyDtMdPy+OAYSUyeM p8R2dCXnnungHKGLG97YuexZEXnt8CaZFXrOtUYHn/oTklO/So8UKGHRuM4W8o9M TLkp/tcw1ZeexBLOopRVcwk0vu1h8RrxMojjX/G0q20li1yCJP9Q3KwfnMRAHYT8 Jo9LsDYealDDQYK/QXOgWDzVu5yQ0tLlfIlXd1+9gIiBg9Tp0/LVZwwBVmFBBKTS zCc8zbmruHYMDY93JyiUEDArqwllrtpeGCKECrnFeC2Xia1jm/ClGEV0cwudvUKa XxyM8PcJWGJrZchFlnpTBCXby8OZuiCh4OgRDHXAOvfqnOIQtPH/1bRO8YCj0eDf J/PHW4y/E09jeJBMYz1vQmjMC+VBpLlRYuvVy++klgiBV42hsCXU85pYn4f9py9V zyJUMmI4kGZs1j6A/igW4oqt+335U3opRVFpbRv/1L1H6IY4E39I9KanjZwT4geq dbmdNQ2ZMW7mY/0= =ruuk -END PGP SIGNATURE-
Accepted gbonds 2.0.3-11 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 05 Nov 2017 21:16:21 -0600 Source: gbonds Binary: gbonds gbonds-data Architecture: source all amd64 Version: 2.0.3-11 Distribution: unstable Urgency: medium Maintainer: Richard Laager <rlaa...@wiktel.com> Changed-By: Richard Laager <rlaa...@wiktel.com> Description: gbonds - U.S. Savings Bond inventory program for GNOME gbonds-data - GBonds data files Changes: gbonds (2.0.3-11) unstable; urgency=medium . * Re-add gnome-vfs build-dep * Recommend libgnomevfs2-extra Checksums-Sha1: e682b78cf898a585e9cb54066fb52b5d17880666 2136 gbonds_2.0.3-11.dsc e8db5430f1b7743d694be0d9777cb188c028b399 45512 gbonds_2.0.3-11.debian.tar.xz 88d533745db7406374dce1a3d0d4d9ee4f41c8f3 587188 gbonds-data_2.0.3-11_all.deb f82c6a97c5d807f383d56921f599d90af5cae163 344168 gbonds-dbgsym_2.0.3-11_amd64.deb 6bfcf0cdbec05b8261e907602f6c8ddf76fb5e1c 14714 gbonds_2.0.3-11_amd64.buildinfo 58ac33afaa768c93b80ddb9de1c3094caeee983f 67684 gbonds_2.0.3-11_amd64.deb Checksums-Sha256: b87f9d132962ceb84fcee2bc194e3dd5f0bfdc2eacd4612817d42102a974ae34 2136 gbonds_2.0.3-11.dsc 0bd1ea9250350fdfd64ddcc75bcaa6d093761b602f68b77306284ceaa6fa8ac9 45512 gbonds_2.0.3-11.debian.tar.xz 922d1586934cf109d91295051ba9017ead097432369a206853b145d143940e13 587188 gbonds-data_2.0.3-11_all.deb 24e6e4ea6cde0531edb5d47112a840f5a47111894e46ca6d7912459293c10dcf 344168 gbonds-dbgsym_2.0.3-11_amd64.deb 7414e038e1c6f3449eaf2520bbbfadb652a6c5ba64dd8a10db5723a0cc95 14714 gbonds_2.0.3-11_amd64.buildinfo 4b638ec3c3bca1494dc73cc5a04e49dea6ff65871b18ceb1ee84af56e94c791a 67684 gbonds_2.0.3-11_amd64.deb Files: c9add28f9b1a56323bce6165e69c8ed1 2136 gnome optional gbonds_2.0.3-11.dsc f2c85913662d697c818e8a0e2acf52e0 45512 gnome optional gbonds_2.0.3-11.debian.tar.xz 33e0eae8a031c0c61cba20ac20d40295 587188 gnome optional gbonds-data_2.0.3-11_all.deb e66f9a1b1062f855c1381e8539fcccea 344168 debug optional gbonds-dbgsym_2.0.3-11_amd64.deb 3fb0ca01f43fef63604a6987963c78c7 14714 gnome optional gbonds_2.0.3-11_amd64.buildinfo 5975cdeb2d78874603a2ec5d8a313616 67684 gnome optional gbonds_2.0.3-11_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAloAWlIUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpalLw//cA6y7SL2YGAiviyslGBg1uOgp8sP cGp0KFrzcG3NWIPsEf/z5FUSHjgoWhtVqsjl7ByF523rB4PeOU+zY9mq7HiIHXzb x+RdIgFtvCpG601iP8PAmylHICB15Fag81FIG0UkeWojFbGV1BbkDxAuNB2L4XSr 6Fa5j23lCJc02JXAeeSFBtZdWWxjlPW3i6ql2Cu3sF+VknNn9KDrChREpIe0qquF txhrJMuOAlEYFMqDEsoDGN4CmTaqag4LN5Vf5DZX0IDNMJFuUDhZNa2Y63SRdDN6 fAN1mAEe8dqs+fwYlHATyTWhu7P84U6twCeAECWQrp0J8v5CEVL1BiwOC4E6O6Am FYDcys0Q/3WCT74vLH1BAqBMXthvWbGiYjtZx+krtD5V0He5W1II7ljNrRGiAVGJ o9uxJs2MJneHT+47NaQ8pDa6B6SQBhu1MZEM6F20Vr+Z9YohNSBOPi4y2/DvLdMm zeBYxf5vVoEjs6danxgY5uqXpegNPZvaDfWLE7fbV7WYBo2oM80v2hSbKIgiNCYB tgOFYKIefQwnWOr8kC09e7/s82ELlPXPvag50IGV/Ntq6E9xH/UQ6uUAWjvNLvoI VkamMJJ3Za7q9qZuNetbUo84PCO+HhLuM3qv8206Cm/tKkjk4J1TzRBA/cpT1XeJ T69t5lKwXV6g8UU= =gx9V -END PGP SIGNATURE-
Accepted up-imapproxy 1.2.8~svn20171105-1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 05 Nov 2017 02:20:25 -0600 Source: up-imapproxy Binary: imapproxy Architecture: source amd64 Version: 1.2.8~svn20171105-1 Distribution: unstable Urgency: medium Maintainer: Richard Laager <rlaa...@wiktel.com> Changed-By: Richard Laager <rlaa...@wiktel.com> Description: imapproxy - IMAP protocol proxy Changes: up-imapproxy (1.2.8~svn20171105-1) unstable; urgency=medium . * Imported Upstream version 1.2.8~svn20171105 * Drop upstreamed changes * Bump Standards-Version to 4.1.1 (no changes) * Update to debhelper 10 * Run wrap-and-sort Checksums-Sha1: 9e2783f61c251da54b3f1c176763199d86251ef7 2114 up-imapproxy_1.2.8~svn20171105-1.dsc 85e76717b0d2f790e366b7516cc567fc551c9cc6 118836 up-imapproxy_1.2.8~svn20171105.orig.tar.bz2 8b093374becc10ca23303917e38cef48e51e5d78 28132 up-imapproxy_1.2.8~svn20171105-1.debian.tar.xz baf8de7320554eb4e1e0da7c563f2726ec9de38e 97584 imapproxy-dbgsym_1.2.8~svn20171105-1_amd64.deb 5854a30b4e849ececc03ac1161baa7a560298044 61984 imapproxy_1.2.8~svn20171105-1_amd64.deb ab2e1d9f71bfe987baec696344c840172ea228a5 5873 up-imapproxy_1.2.8~svn20171105-1_amd64.buildinfo Checksums-Sha256: 8fb825935e25f638b7f1234a198c8c854bc8c34c3c6bda948a8227953334619f 2114 up-imapproxy_1.2.8~svn20171105-1.dsc 2fa3d400227c791b94d7f1e04f5ead5c2165eece44c8b018cc94ed55bb9efdde 118836 up-imapproxy_1.2.8~svn20171105.orig.tar.bz2 007c67099be0753224808b9fd974691d3092eda852d59aee43a23bce314e1a20 28132 up-imapproxy_1.2.8~svn20171105-1.debian.tar.xz 7939384c40c06dae1c7b02cfe7c5e18e6d52ef1371b91833c7eaa57cd9472674 97584 imapproxy-dbgsym_1.2.8~svn20171105-1_amd64.deb 46333f95f991c157495935140c820366bb839b4008512735699b9da359ac4422 61984 imapproxy_1.2.8~svn20171105-1_amd64.deb a195d32f0bfeaeace11062362fead2eca8be15ccc6f93a146d6dfa7e5dbae1c1 5873 up-imapproxy_1.2.8~svn20171105-1_amd64.buildinfo Files: 331b72b6e1d5a23ac26218ce75e8000a 2114 mail optional up-imapproxy_1.2.8~svn20171105-1.dsc 587b7745143793576e74b459c1ac8373 118836 mail optional up-imapproxy_1.2.8~svn20171105.orig.tar.bz2 acb420f147d0501cd985d8dceb79ac63 28132 mail optional up-imapproxy_1.2.8~svn20171105-1.debian.tar.xz bcde68e2939a631e51fd9f4a02aff530 97584 debug optional imapproxy-dbgsym_1.2.8~svn20171105-1_amd64.deb 617c96a0f3b3c8f6f12c8d30dd2e1d62 61984 mail optional imapproxy_1.2.8~svn20171105-1_amd64.deb caa107ba3239906b444f14838063e1af 5873 mail optional up-imapproxy_1.2.8~svn20171105-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAln/IDQUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpZb3Q/7BFJ/Y8a4EdG5RIV51TrFSX8qWGiV O8V2ZcUeK9LfaNa7+fmCXFtbriztBLepQjudV6awkF/yIFRWDd+9FIIteHB4HgoE zEcpKKzHe4LQQMF4Q0VcOWlkYVWXo9CbSGVVQCTLCnmD6wtZWNae1amvshRCyFNh mgQgaq+T0MGVt9eOFdd/2nIryR5+/5WZYTpKZfJlSy5hBnfsRrop645I4FDMhKAx 2lXHyxzavVcU73+EnYWjgNzTsZCkhch9vsK+7C5EXa9S0txHq7TE/q28YSKx6MUx 3Q8FXxIgU5iXwPUcLW56TgkuYLpKArlHAQ3yWTIQYVtYVcPF09KMnwwgkU4BDM/Z H/qFOtxhan8nHM3/lJ/bu4a5qAk+bv6zivs+GdaXLUYyxE1tdmJGZMpmshvW04x8 saet6dYeamX2OTepcjuNnSeKbn12bUaANM9xNRqC9P4Eju/cBYID+/1hxWY1aASP HOwiWs1FNm/Q8L3764hh2r0dtpp5rsH4lRVGGu3iDTIfsfW4ND7v6FbCi19mQb/n Ba5Vi1RGtglJEx10TypknzgHpx5fr1f4CWdDROJmxXGX25KvNqPBmUQelQ/Ne417 tYlbSgmxrGo5Z8kRu9RMpvFC5cciTd5I3IFQV4WU5oo00CQhepgkOEvvdIGQKgnd +Z9e3AX7xRVUkew= =jEOf -END PGP SIGNATURE-
Accepted gbonds 2.0.3-10 (source all amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 04 Nov 2017 02:57:31 -0500 Source: gbonds Binary: gbonds gbonds-data Architecture: source all amd64 Version: 2.0.3-10 Distribution: unstable Urgency: medium Maintainer: Richard Laager <rlaa...@wiktel.com> Changed-By: Richard Laager <rlaa...@wiktel.com> Description: gbonds - U.S. Savings Bond inventory program for GNOME gbonds-data - GBonds data files Closes: 868413 Changes: gbonds (2.0.3-10) unstable; urgency=medium . [ Richard Laager ] * Use https for debian/copyright Format URL * Add redemption data through 05/2018 (sb201712.asc) . [ tony mancill ] * Bump Standards-Version to 4.1.1 * Drop build-dep on gnome-vfs and autotools-dev. Add build-dep on gvfs-libs (Closes: 868413) * Bump debhelper and compat to DH 10. . [ Richard Laager ] * Replace g_strcasecmp Checksums-Sha1: 2c39917f0423863edcca3564d6a6b87cf0fefb9c 2118 gbonds_2.0.3-10.dsc 9d4e3878610ab3696fcc9de89716edf074a4d6ac 45528 gbonds_2.0.3-10.debian.tar.xz e6d9323e1a42dea2d54d6ee20b302e288fe197d9 586848 gbonds-data_2.0.3-10_all.deb efd2f41d0c6e64d049b3d2bf28d2f60c359c7875 344132 gbonds-dbgsym_2.0.3-10_amd64.deb 0d92d942375f53017923c21562950620e438647e 14953 gbonds_2.0.3-10_amd64.buildinfo 397aeae574b9d638cfb562c1948f2dc2895b33c3 67628 gbonds_2.0.3-10_amd64.deb Checksums-Sha256: 42cdee0602dde933b342a74dd5da935f087b96b591844f8f212dc3627b2b8cd5 2118 gbonds_2.0.3-10.dsc 7254e688e46c46fbd33bc88a900b57bc99efb1e9727de42ad2e2e3e26c137f3a 45528 gbonds_2.0.3-10.debian.tar.xz 89f23cb68963e34027e7f0bf62c4736fee599972775fb9c3c51036b6ce7e5c6d 586848 gbonds-data_2.0.3-10_all.deb 0071cd6d3bdc9a25d5e6fd37470c0f3fa5813441500326551c4400c9a521b646 344132 gbonds-dbgsym_2.0.3-10_amd64.deb c2558e97a40e224b275fe16cb84809ba073ae1fa5a5fdf8bcc8a38ef970fc6a6 14953 gbonds_2.0.3-10_amd64.buildinfo 2424b87d95fbbf8e2731ffb9f31bee927b9102900d488c152e635518aa78be9a 67628 gbonds_2.0.3-10_amd64.deb Files: f0b971cc2f62301bbe49efa945d7c264 2118 gnome optional gbonds_2.0.3-10.dsc b5444313a8d8c7dbc90f2c62b8e47252 45528 gnome optional gbonds_2.0.3-10.debian.tar.xz 671414974270f1aa0f6d4f7dad9db4f1 586848 gnome optional gbonds-data_2.0.3-10_all.deb 5b87bddefb0918a4fcd38621f48d489b 344132 debug optional gbonds-dbgsym_2.0.3-10_amd64.deb 82b7a25b205cf7feb3c1f634bbadb894 14953 gnome optional gbonds_2.0.3-10_amd64.buildinfo 5df400715def4e3f353d9e8538f23084 67628 gnome optional gbonds_2.0.3-10_amd64.deb -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAln9ypoUHHRtYW5jaWxs QGRlYmlhbi5vcmcACgkQIdIFiZdLPpY10Q/+I2LfTUtGCY6TgJBXu5omcmbkDQZA v0B9J0OAuJ8m02m+CyciI1L/U0YpcSitTxVQKyKYLBpCxfAIFh3DFxXHS/WfC3iN bVkJw7OzbfNKivqg2TexeFEaGkguYTkkq01FKGNYnDAjJboHdO0OHBCfdHQjyCN0 r7oF+NmFH0/mq9YzUnDIjs1xgrXkH5ghlUJECLzW6JV0Pv033G39TMsVaKYWBwbb KVOwPUcZ7S9p9EyD6VGll9Jw+QCdrrsy6bJe2dRTl5rAu+C45veMLsv8CzD8DpEq K5xbagvN/oXuymgGKmOYbHHQCtPErtmXy30ERuT0wmiGbojm2IDCt+gvBaPsudg3 OdHh/MBYJoALwjpnYsT6vg3cD/CjptS6KWD3RbOTXRmBJ2zReTEUPRY6sbSU7pNl P+WvwZoepcQuzqiOPIzIRUSROWsiEc4uD4s7yVCS7woXRi0q3Gei5Oc7weYwP+4n 54wQ251Pn6U0kDhGbktwmeB5OisCPKhAIDZ6XWUQZZHpw/6Na2tR7RCn5Arz5MUf bbHDzmuPo6sVCZleUOqs0+455eDYeeTbluUbeUUiCm7vOM/PNqeSNRwgmctIzigc prB2PJm84ASM1pq6fn3g8eECR1tb2KLZZIsLmudUxLGPsVulkFCzeq4yG+VMu1+p BwhyWO5UkwdulI4= =DSHF -END PGP SIGNATURE-
