Bug#1066313: fixed upstream

[micah anderson]

These issues are fixed upstream in main, but there is not a release.

The fix is in commit 1171bf2fd4e7a0cab02cf5fca59090b65af9cd29.

Clément would you pull that fix into the package to resolve this FTBFS?

Bug#1023700: Confirmed

[micah anderson]

I've tried the same thing, and get the same results. It appears that the
systemd support is there, the cryptsetup support is ithere, but just
cryptsetup-initramfs is not somehow there also.

It would be a shame to release bookworm with just the initramfs feature
missing, when all the other pieces are there. Do you have any idea what
might be blocking this?

For what it is worth, dracut does work.

-- 
micah

Bug#1029012: www.debian.org: https://www.debian.org/releases/bullseye/debian-installer shows "trixie" information

[Micah Anderson]

Package: www.debian.org
Severity: important

I wanted to install Debian stable, so I searched on the internet to find the 
debian-installer, and I arrived on 
https://www.debian.org/devel/debian-installer/ you click "the bullseye page" 
and you get sent to https://www.debian.org/releases/bullseye/debian-installer 
which actually has no content at all, except for, "For installation images and 
documentation about how to install "trixie" (which is currently Testing), see 
the Debian-Installer page."

This is obviously wrong, it should point to bullseye installation information.

When asked on #debian-devel, one person said that it worked for them, but then 
when they clicked on the "English" language, they got the "trixie" page.

english/releases/bullseye/debian-installer/index.wml doesn't seem crazy at 
first glance…
interestingly, grep -i trixie 
/srv/www.debian.org/webwml/english/releases/bullseye/debian-installer/index.en.html
 returns nothing.
(so the build results seem to match the source files, which are fine; not sure 
where the buggy served page comes from…)

Bug#1025808: python3-jinja2: Bug in jinja2 template macros causes ansible problems

[Micah Anderson]

Package: python3-jinja2
Version: 3.0.3-2
Severity: important
Tags: upstream

Hello,

There is a bug in the version of the package that is in Bookworm that causes
Ansible templates to fail in frustrating ways (see
https://github.com/ansible/ansible/issues/77272), it has been fixed upstream
(https://github.com/pallets/jinja/issues/1510 and fixed upstream in the 3.1.0
release (https://github.com/pallets/jinja/pull/1511).

This will affect Ansible users quite a bit if this version is included in the
release.

Thanks!

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-jinja2 depends on:
ii  python3 3.10.6-1
ii  python3-markupsafe  2.1.1-1+b1

Versions of packages python3-jinja2 recommends:
ii  python3-babel  2.10.3-1
ii  python3-pkg-resources  65.5.0-1

Versions of packages python3-jinja2 suggests:
pn  python-jinja2-doc  

-- no debconf information

Bug#1006629: unattended-upgrades: dry-run should not interfere with the system locks

[Micah Anderson]

Package: unattended-upgrades
Version: 2.8
Severity: wishlist

When unattended-upgrades is run with the --dry-run flag, it still acquires a
cache lock (presumably from apt update?), and makes a pid file. These can
interfere with unattended-upgrade runs that are done without the --dry-run, and
can result in Cache acquire lock errors.

Ideally, for --dry-run, unattended-upgrades could use a temporary directory for
the lists location, and the pid, if it even needs one.

thanks!

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-dbus   1.2.16-5
ii  python3-distro-info1.0
ii  ucf3.0043
ii  xz-utils   5.2.5-2

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-30
ii  cron [cron-daemon]  3.0pl1-137
ii  systemd-sysv247.3-6

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx   8.1.2-0.20180807cvs-2
ii  needrestart 3.5-4
ii  postfix [mail-transport-agent]  3.5.6-1+b1
ii  powermgmt-base  1.36
ii  python3-gi  3.38.0-2

-- debconf information excluded

Bug#991284: RM: deltachat-core -- ROM; Replaced by a rust rewrite and no longer maintained

[Micah Anderson]

Package: ftp.debian.org
Severity: normal

Hi,

The upstream authors of deltachat-core have decided to re-implement the library
in Rust, and this package is no longer relevant. Upstream is not continuing to
maintain it, and it would just otherwise collect dust in the archive, so I'm
requesting removal.

I am the package maintainer.

Thanks!

micah

Bug#959446: debuerreotype: Consider additionally providing images on debian infrastructure

[micah anderson]

Tianon Gravi  writes:

> On Sat, 2 May 2020 at 06:24, Micah Anderson  wrote:
>> I'm not sure that this is the right place to file this issue, but I was 
>> unable
>> to find a better place. Feel free to redirect to a more suitable place. I 
>> talked
>> to the debian-cloud people and they didn't think that this was their purview.
>
> I think an issue under [1] would probably be more correct, but this
> will do (I'm not at all fond of the Debian BTS, as I always have to
> look up the documentation for how to do simple things like close bugs
> and even then I typically get something wrong, but such is life).
>
> [1]: https://github.com/debuerreotype/docker-debian-artifacts
>
>> I really value the debian built docker images that are available at Docker
>> Hub. The fact that they are built in a reproducible fashion, and are 
>> available
>> as "official" docker images (which means that they are verifiable through 
>> Docker
>> Content Trust (DCT) signatures) goes a long way for reducing my paranoia.
>
> Additionally (and probably more critically, depending on how much
> stock you put in DCT), the signatures on the Docker official images
> program at large have been nonfunctional[2][3][4] for quite some time
> now, so anyone using them will likely be silently getting outdated
> images (which is an absolutely horrifying failure mode in itself,
> IMO).
>
> [2]: https://github.com/docker-library/official-images/issues/6838
> [3]: https://github.com/docker-library/official-images/issues/5874
> [4]: https://github.com/docker-library/official-images/issues/1516

Thanks for these references, I wasn't aware of them.

>> The reason I'm writing is because I'd like to have the option of obtaining 
>> these
>> images from Debian directly, from a Debian controlled registry that is 
>> properly
>> notarized to provide the same cryptographically verifiable trust chain as is
>> provided through Docker Hub.
>>
>> Being able to verify the images from the same root of trust that the 
>> operating
>> system depends on, would be a nice improvement. Considering that the images 
>> are
>> essentially building Debian, on Debian, it would be nice to not have to rely 
>> on
>> docker.io to trust the resulting images. Sure, they are signed, but the trust
>> root itself is not coming from Debian itself. When I `debootstrap` from a 
>> debian
>> system, by default, it already verifies the packages pulled automatically, 
>> from
>> the same root of trust that the OS depends on.
>
> This would definitely be very nice; unfortunately, the container
> ecosystem at large is very resistant to anything PGP-related, so I
> don't think we'll see PGP signatures on container images being
> supported any time soon.

What about something far more simple... what if you, when you've built
the images, created a detached signature of the image, and published it
somewhere. That way it would be trivial for people to take a docker
image, look at the hash, combine it with the debian keyring and your
signature, and feel reasonably confident in the chain of trust being
unbroken.

Instead of some hopelessly complicated framework, or adding something to
the container image format, just build (automatically), a file
containing signatures, that is then signed and published somewhere.

> However, there is some collaboration in-progress on what's being
> called "Notary v2" [5], which is a re-imagining of what "container
> image signing" means such that many more use cases than were solved in
> v1 are being considered, and I think this is our best bet for being
> able to have something like a trust root distributed as a Debian
> package which can then be used to verify downloaded images.  Anyone
> who is interested in more information on that initiative or especially
> in collaborating with those folks should check out [6].
>
> [5]: https://www.docker.com/blog/community-collaboration-on-notary-v2/
> [6]: https://github.com/notaryproject/requirements

Yesterday and the day before were two sessions on the status of notary
v2 at kubecon:
https://kccnceu20.sched.com/event/Zewy/notary-v2-introduction-and-status-report-justin-cormack-docker-omar-paul-amazon
https://kccnceu20.sched.com/event/Zexw/notary-v2-outstanding-issues-working-session-justin-cormack-docker-steve-lasker-microsoft

I feel like the tongue-in-cheek references to Antoni Gaudí and the
Sagrada Familia in the slide deck, is very telling. Its fairly obvious
that this is something that I can just ignore for another year, and hope
it will be in a somewhat usable state next year, maybe

However, in the meantime, the supply chain is not authenticated, and I'm
afraid the perfect is being the enemy of the good here.

-- 
micah

Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period

[micah anderson]

Hi Balint,

I looked at the patch you link to
(https://github.com/mvo5/unattended-upgrades/pull/280) but the
unattended-upgrade code that is in the diff is fairly different from
what is in the version in Buster, specifically this chunk:

-if not marking_succeeded or \
-   not check_changes_for_sanity(self, desired_pkg=pkg):
+if (not marking_succeeded
+or not check_changes_for_sanity(self, desired_pkg=pkg)) \
+and allow_marking_fallback():
logging.debug("falling back to adjusting %s's dependencies"
  % pkg.name)
self.clear()

this class UnattendedUpgradesCache(apt.Cache) is in there, but it seems
fairly different and there is no 'if not marking_succeeded' in there at
all.

-- 
micah

Bug#963781: mtail: Gets caught in a tight loop and doesn't respond

[Micah Anderson]

Package: mtail
Version: 3.0.0~rc19-2
Severity: important

Hi,

It seems the version of mtail that is in buster works for a short period of
time, but then gets into a strange state where it doesn't respond anymore. If
you attempt to curl the port it is listening on it will simply hang and never
respond.

I've run some straces of the process, but they just look like it is caught in a
tight loop, regardless of the mtail programs loaded (I used a simple counter to
eliminate problems with the programs), it just looks like this over and over:

16164 futex(0xbc7760, FUTEX_WAKE_PRIVATE, 1) = 1
16158 <... restart_syscall resumed> )   = 0
16164 read(10,  
16158 futex(0xbc4360, FUTEX_WAIT_PRIVATE, 0, NULL 
16164 <... read resumed> 0xc0001229e8, 4096) = -1 EAGAIN (Resource temporarily 
unavailable)
16164 futex(0xbc4360, FUTEX_WAKE_PRIVATE, 1) = 1
16158 <... futex resumed> ) = 0
16164 futex(0xbc7760, FUTEX_WAIT_PRIVATE, 0, {tv_sec=4, tv_nsec=999609690} 

16158 epoll_pwait(5, [], 128, 0, NULL, 0) = 0
16158 epoll_pwait(5,  
16161 <... sched_yield resumed> )   = 0
16161 futex(0xbc37b0, FUTEX_WAKE_PRIVATE, 1) = 0
16161 nanosleep({tv_sec=0, tv_nsec=2}, NULL) = 0
16161 futex(0xbc3890, FUTEX_WAIT_PRIVATE, 0, {tv_sec=60, tv_nsec=0} 
16158 <... epoll_pwait resumed> [{EPOLLIN, {u32=437136944, 
u64=139848867262000}}], 128, -1, NULL, 0) = 1
16158 futex(0xbc3890, FUTEX_WAKE_PRIVATE, 1 
16161 <... futex resumed> ) = 0
16158 <... futex resumed> ) = 1
16161 sched_yield( 
16158 futex(0xbc7760, FUTEX_WAKE_PRIVATE, 1 
16164 <... futex resumed> ) = 0
16158 <... futex resumed> ) = 1
16164 futex(0xc41640, FUTEX_WAIT_PRIVATE, 0, NULL 
16158 read(10, 0xc0001229e8, 4096)  = -1 EAGAIN (Resource temporarily 
unavailable)
16158 futex(0xc41640, FUTEX_WAKE_PRIVATE, 1 
16164 <... futex resumed> ) = 0
16158 <... futex resumed> ) = 1
16164 epoll_pwait(5,  
16158 futex(0xbc7760, FUTEX_WAIT_PRIVATE, 0, {tv_sec=4, tv_nsec=999784712} 

16164 <... epoll_pwait resumed> [], 128, 0, NULL, 0) = 0
16164 epoll_pwait(5,  
16161 <... sched_yield resumed> )   = 0
16161 futex(0xbc37b0, FUTEX_WAKE_PRIVATE, 1) = 0
16161 nanosleep({tv_sec=0, tv_nsec=2}, NULL) = 0
16161 futex(0xbc3890, FUTEX_WAIT_PRIVATE, 0, {tv_sec=60, tv_nsec=0} 
16164 <... epoll_pwait resumed> [{EPOLLIN, {u32=437136944, 
u64=139848867262000}}], 128, -1, NULL, 0) = 1
16164 futex(0xbc3890, FUTEX_WAKE_PRIVATE, 1) = 1
16161 <... futex resumed> ) = 0
16164 read(10,  
16161 sched_yield( 
16164 futex(0xbc7760, FUTEX_WAKE_PRIVATE, 1) = 1
16158 <... futex resumed> ) = 0
16164 read(10,  
16158 futex(0xbc4360, FUTEX_WAIT_PRIVATE, 0, NULL 
16164 <... read resumed> 0xc0001229e8, 4096) = -1 EAGAIN (Resource temporarily 
unavailable)
16164 futex(0xbc4360, FUTEX_WAKE_PRIVATE, 1) = 1
16158 <... futex resumed> ) = 0
16164 futex(0xbc7760, FUTEX_WAIT_PRIVATE, 0, {tv_sec=4, tv_nsec=999800747} 

16158 epoll_pwait(5, [], 128, 0, NULL, 0) = 0
16158 epoll_pwait(5,  
16161 <... sched_yield resumed> )   = 0
16161 futex(0xbc37b0, FUTEX_WAKE_PRIVATE, 1) = 0
16161 nanosleep({tv_sec=0, tv_nsec=2}, NULL) = 0
16161 futex(0xbc3890, FUTEX_WAIT_PRIVATE, 0, {tv_sec=60, tv_nsec=0} 
16158 <... epoll_pwait resumed> [{EPOLLIN, {u32=437136944, 
u64=139848867262000}}], 128, -1, NULL, 0) = 1
16158 futex(0xbc3890, FUTEX_WAKE_PRIVATE, 1 
16161 <... futex resumed> ) = 0
16158 <... futex resumed> ) = 1
16161 sched_yield( 

The stretch-backports and bullseye versions of mtail seem to work fine, but this
version in buster isn't something that we can use in production because it falls
over like this fairly quickly and then we cannot seem to get it to work again.

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mtail depends on:
ii  adduser  3.118
pn  daemon   
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  tzdata   2020a-0+deb10u1

mtail recommends no packages.

mtail suggests no packages.

Bug#959446: debuerreotype: Consider additionally providing images on debian infrastructure

[Micah Anderson]

Package: debuerreotype
Version: 0.10-1
Severity: normal

Hello!

I'm not sure that this is the right place to file this issue, but I was unable
to find a better place. Feel free to redirect to a more suitable place. I talked
to the debian-cloud people and they didn't think that this was their purview.

I really value the debian built docker images that are available at Docker
Hub. The fact that they are built in a reproducible fashion, and are available
as "official" docker images (which means that they are verifiable through Docker
Content Trust (DCT) signatures) goes a long way for reducing my paranoia.

I am not writing to suggest any of that change, I think it should definitely
stay that way.

The reason I'm writing is because I'd like to have the option of obtaining these
images from Debian directly, from a Debian controlled registry that is properly
notarized to provide the same cryptographically verifiable trust chain as is
provided through Docker Hub.

Being able to verify the images from the same root of trust that the operating
system depends on, would be a nice improvement. Considering that the images are
essentially building Debian, on Debian, it would be nice to not have to rely on
docker.io to trust the resulting images. Sure, they are signed, but the trust
root itself is not coming from Debian itself. When I `debootstrap` from a debian
system, by default, it already verifies the packages pulled automatically, from
the same root of trust that the OS depends on.

It would be nice to get my debian docker images from a debian registry, and not
have to trust Docker Hub as a secondary verifier.

Understandably, this isn't a trivial effort. It requires a debian provided
registry, and a TUF configured notarization process. Each of these is an effort
in itself.

Maybe a good starting point would be to provide a simple registry service at
https://docker.debian.net, where you can already find the image checksums. It
doesn't have to be a notarized one from the beginning, but just a registry where
the same images that are pushed to Docker Hub are also pushed. Perhaps using the
built-in registry at Salsa would be another option.

Once things are reliably being pushed to a registry on debian.net, or salsa,
then building the notarization pieces for verification would be next.

Once that has been completed, then perhaps this can become a proper Debian
service.

Thanks for considering this, and thanks for working on these images!

micah


-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debuerreotype depends on:
ii  debian-archive-keyring  2019.1

Versions of packages debuerreotype recommends:
pn  debootstrap  

Versions of packages debuerreotype suggests:
pn  diffoscope  

Bug#959132: libquickfix-dev: Please compile with the option --with-openssl

[Micah Anderson]

Package: libquickfix-dev
Version: 1.15.1+dfsg-3
Severity: wishlist

Hello!

It would be nice if you could toggle the configure flag --with-openssl.

It doesn't impact people who want to use it without ssl, but makes it possible
to make TLS connections.

thanks!

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_BAD_PAGE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#955292: netbase: Typo in /etc/services

[Micah Anderson]

Package: netbase
Version: 5.6
Severity: minor
Tags: patch

Hello,

It seems /etc/services has a typo for the 'time' service. Patch attached.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information
--- /etc/services   2019-02-09 21:05:36.0 -0500
+++ /tmp/services   2020-03-29 08:59:57.421951341 -0400
@@ -30,8 +30,8 @@
 ssh22/tcp  # SSH Remote Login Protocol
 telnet 23/tcp
 smtp   25/tcp  mail
-time   37/tcp  timserver
-time   37/udp  timserver
+time   37/tcp  timeserver
+time   37/udp  timeserver
 rlp39/udp  resource# resource location
 nameserver 42/tcp  name# IEN 116
 whois  43/tcp  nicname

Bug#951298: RM: u1db -- ROM; No longer used or maintained

[Micah Anderson]

Package: ftp.debian.org
Severity: normal

Hello, World

As the original packager for u1db, I'd like to request removal, as it is no 
longer maintained upstream, nor is it needed.

Thank you!
Micah

Bug#938737: u1db: Python2 removal in sid/bullseye

[micah anderson]

Moritz Mühlenhoff  writes:

> On Fri, Aug 30, 2019 at 07:57:06AM +, Matthias Klose wrote:
>> Package: src:u1db
>> Version: 13.10-6.4
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
>> 
>> Python2 becomes end-of-live upstream, and Debian aims to remove
>> Python2 from the distribution, as discussed in
>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>> 
>> Your package either build-depends, depends on Python2, or uses Python2
>> in the autopkg tests.  Please stop using Python2, and fix this issue
>> by one of the following actions.
>
> Hi Micah,
> per Wikipedia the Ubuntu One cloud storage has been shut down many years
> ago, should this simply be removed?

We were not using it for Ubuntu One cloud storage, but instead as its
more generic use case as "a cross-platform, cross-device, syncable
database API", which we modified to have client-side encrypted database
replicas and documents.

However, it is not being used any longer, and should simply be removed.

-- 
micah

Bug#922308: dput-ng: Please set the default transport to use ssh-upload

[micah anderson]

Mattia Rizzolo  writes:

> On Thu, Feb 14, 2019 at 07:58:13AM -0500, Daniel Kahn Gillmor wrote:
>> Could the dput or dput-ng maintainers weigh in on what is needed to make
>> this change?
>
> As the de-facto dput-ng maintainer, I won't do that until DMs can use
> it.

I think it is a good goal to get DMs to be able to use it, but what is
the reason to keep DDs from using it until DMs can?

thanks!

-- 
micah

Bug#947105: [Pkg-puppet-devel] Bug#947105: puppet: Default install uses outdated configuration file and directory locations

[micah anderson]

"Todd H. Poole"  writes:

> As for departing from prior behavior, I'll give you that: that's why there
> was so much messaging around the 4.x release and such a strong up-tick in
> the quality of the upstream docs around that time. If you were to change
> this now, I'd absolutely advocate doing so as part of your Puppet 6.x
> release.

For me, /etc/puppetlabs indicates the PuppetLabs provided packages, and
*not* the Debian provided packages. This is where they install things,
and I think it would be confusing to mix those two namespaces.

-- 
micah

Bug#941457: postfix: Please include collate.pl contrib script

[Micah Anderson]

Package: postfix
Version: 3.4.5-1
Severity: wishlist

Hello,

Upstream has collate.pl under auxiliary/collate/collate.pl in the upstream 
source. 
This is a very useful utility script, and would be lovely if the debian package
would include it so it would be installed on the system when the package is 
installed.

This script, by Viktor Dukhovni, untangles a Postfix logfile and
groups the records one "session" at a time based on queue ID and
process ID information.

Thanks!
Micah

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.67-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.12+dfsg-9
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  e2fsprogs  1.44.5-1+deb10u1
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libicu63   63.1-6
ii  libsasl2-2 2.1.27+dfsg-1
ii  libssl1.1  1.1.1c-1
ii  lsb-base   10.2019051400
ii  netbase5.6
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  python3  3.7.3-1

Versions of packages postfix suggests:
ii  emacs-gtk [mail-reader]1:26.1+1-3.2
ii  libsasl2-modules   2.1.27+dfsg-1
ii  mailutils [mail-reader]1:3.5-3
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
ii  postfix-sqlite 3.4.5-1
ii  procmail   3.22-26
pn  resolvconf 
ii  thunderbird [mail-reader]  1:60.8.0-1~deb10u1
pn  ufw

-- debconf information excluded

Bug#930033: [Pkg-puppet-devel] Bug#930033: Puppet-master do not clean reports in /var/lib/puppet/reports

[micah anderson]

Thomas Goirand  writes:

> Using puppet-master from both Stretch and Buster in production, I have found
> out that on each puppet run, a run report is saved under:
>
> /var/lib/puppet/reports//.yaml
>
> unfortunately, with a moderatly sized cluster (about 30 nodes), this fills-up
> very fast. For me, the reports folder was 52 GBytes, leading to a disk full
> (as my puppet-master was running on a small-ish VM). Of course, once the
> disk is full, absolutely nothing works anymore (new nodes get their certs
> saved as zero bytes, etc.).
>
> What should be done, is clean old reports, let's say those that are at least
> one month old, using a cron.daily job.

Some people want these reports to continue to accumulate, some do not,
this is what I do:

 class puppet::master::cleanup_reports {
  # clean up reports older than $puppetmaster_cleanup_reports days
  file { '/etc/cron.daily/puppet_reports_cleanup':
content => "#!/bin/bash\nfind ${puppet::master::reports_dir} -maxdepth 2 
-type f -ctime +${puppet::master::cleanup_reports} -exec rm {} \\;\n",
owner   => root,
group   => 0,
mode=> '0700';
  }

-- 
micah

Bug#919937: status update

[micah anderson]

Antoine Beaupré  writes:

> We've processed a bunch of the dependencies for this, and uploaded some
> to NEW (with related git repos in salsa). Some are not done yet, mostly
> because their license is unclear.

The packages indicated in this table as having unclear licenses have had
that issue resolved, so those packages can be built now.

Bug#919944: License clarification resolved

[micah anderson]

The unclear license on this package was resolved by upstream. I believe
that this can be packaged now.

-- 
micah

Bug#919945: License clarification resolved

[micah anderson]

The unclear license situation has been resolved by upstream. I believe
that removes the remaining blocker for this package to be put into the
archive.

-- 
micah

Bug#924005: Same problem

[micah anderson]

I had the same problem, and I found this bug when searching for a
solution.

I downgraded to the previous jetty version from snapshots.debian.org and
it worked.

I'm unsure what changed in this version that causes it.

-- 
micah

Bug#925164: RM: deltachat-core/0.39.0-1+ds2

[micah anderson]

Control tags -1 - moreinfo

Hi,

Niels Thykier  writes:

> I am adding the Debian maintainer of Delta Chat in Debian as:
>
>  * I do not know anything about Delta Chat nor its situation outside of
>Debian.  In Debian, it has zero bugs.

Indeed, the upstream Delta Chat authors have requested that it not be
put into stable, as too much is changing at the moment.

>  * I am not sure if the Debian maintainer has been informed of the
>situation (I got not easily way of knowing except asking).

Yes, I am aware, and glad that this was done.

Andre is listed as DM for this package, so I thought that it would not
be necessary to check this.

> @micah: Can you please comment on this and remove the moreinfo tag when
> you have done so.

done.

-- 
micah

Bug#736859: dput: Please set the default transport to use ssh-upload

[micah anderson]

Daniel Kahn Gillmor  writes:

> On Mon 2019-02-11 10:25:48 -0500, Daniel Kahn Gillmor wrote:
>> The default dupload target for debian is described this way in
>> /etc/dupload.conf:

If I install dput, I do not have an /etc/dupload.conf, and rather I see
this in /etc/dput.conf:

[DEFAULT]
login   = *
method  = ftp
hash= md5

...

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp

...

That seems like it is using ftp as default to me.

> So perhaps this bug report can be closed, since ssh.upload.debian.org
> does appear to be the default target for dupload today?  i don't know
> when that changed.

That may be true about dupload, but dupload is a different package, and
this was about dput.

-- 
micah

Bug#919943: ITP: golang-github-getlantern-systray -- a cross platfrom Go library to place an icon and menu in the notification area

[Micah Anderson]

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: golang-github-getlantern-systray
  Version : 0.0~git20181206.eaad711-1
  Upstream Author : Lantern
* URL : https://github.com/getlantern/systray
* License : Apache-2.0
  Programming Lang: Go
  Description : a cross platfrom Go library to place an icon and menu in 
the notification area

 Package systray is a cross platfrom Go library to place an icon and menu
 in the notification area.
 .
 This is a dependency for the riseup-vpn ITP (#919937)

Bug#919940: ITP: golang-github-oxtoacart-bpool -- Buffer/Byte pool for Go

[micah anderson]

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: golang-github-oxtoacart-bpool
  Version : 0.0~git20150712.4e1c556-1
  Upstream Author : Percy Wegmann
* URL : https://github.com/oxtoacart/bpool
* License : Apache-2.0
  Programming Lang: Go
  Description : Buffer/Byte pool for Go

 bpool implements leaky pools of byte arrays and Buffers as bounded
 channels.
 .
 A common use case for this package is to use buffers  to execute HTML templates
 against (via ExecuteTemplate) or encode JSON into (via json.NewEncoder). This
 allows you to catch any rendering or marshalling errors prior to writing to
 a http.ResponseWriter, which helps to avoid writing incomplete or malformed
 data to the response.
 .
 This is a dependency for the riseup-vpn ITP (#919937)

Bug#919937: ITP: riseup-vpn -- Minimal, easy to use vpn client

[micah anderson]

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: riseup-vpn
  Version : 0.18.12
  Upstream Author : LEAP Encryption Access Project
* URL : https://0xacab.org/leap/bitmask-vpn
* License : GPLv3
  Programming Lang: Go
  Description : Minimal, easy to use VPN client

A minimalistic implementation, written in golang, of Bitmask VPN. The
only User Interface is a small systray icon. This provides simple setup
for VPN service through Riseup.

-- 
micah

Bug#919935: ITP: golang-github-protonmail-go-autostart -- A Go library to run a command after login

[micah anderson]

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: golang-github-protonmail-go-autostart
  Version : 0.0~git20181114.c527205-1
  Upstream Author : 
* URL : https://github.com/ProtonMail/go-autostart
* License : MIT
  Programming Lang: Go
  Description : A Go library to run a command after login

 A Go library to run a command after login.

 This is a dependency for the package riseupvpn that is also being packaged.

Bug#895381: Severity

[micah anderson]

Hello Sergio,

I'm reviewing bugs that are currently release critical at our local bug
squashing party, and I stumbled on yours.

I'm not disputing this bug exists, I'm just trying to determine why it
is you set the severity to "Serious". As you are probably aware, this
severity indicates that this is a sever violation of Debian policy
(violates a "must" or "required" directive), or in the package
maintainer's opinion, makes the package unsuitable for release.

Can you specify what part of debian policy this issue makes this bug
severity "Serious"?

Thanks!

-- 
micah

Bug#892340: Status of upload?

[micah anderson]

Hello Marc,

I'm checking up on RC bugs, because we are working on a Bug Squashing
Party here.

Back in November, you were saying you were going to combine this fix
with a bump of upstream's version:

> I was planning to combine this with an update from upstream.

I'm wondering if you are planning on doing this soon? If you aren't,
maybe we could upload the package with the fix?

-- 
micah

Bug#893644: Dependency on gnupg

[micah anderson]

Actually, I was wrong in my previous message. The package
`leap-archive-keyring` Depends on gnupg because its .postinst has a
clean-up process from a previous package (2016.03.03) that removes keys
from the old /etc/apt/trusted.gpg.

In order to do that clean-up, gpg is necessary, thus the Depends.

-- 
micah

Bug#893644: stretch-pu: package leap-archive-keyring/2016.03.08

[micah anderson]

Julien Cristau  writes:

> On Tue, Apr 03, 2018 at 01:00:41PM -0400, micah anderson wrote:
>> I went with 2017.11.24~deb9u1 because indeed, the changes since the
>> current version in stretch are appropriate for a stable update, namely:
>> 
>> 1. Providing keys in a second location, to aid in the transition from
>> jessie->stretch methods for how sources.list [signed-by=] method changed
>> to allow for both paths and fingerprints
>> 
>> 2. fix priority to be in-line with debian policy
>> 
>> 3. add a dependency on gnupg
>> 
>> 4. update the expirations on the keys themselves
>> 
>> I'm only unsure if changing the Priority section is allowed in a stable
>> point update?
>> 
> It's a no-op.  Priority and Section in the package are meaningless.
>
> I'm curious about 3 though, no explanation seems to be provided.

Indeed, I believe this could be a Recommends (like
debian-keyring). Would you like me to change that?

-- 
micah

Bug#912430: ITP: deltachat-core -- Delta.chat development library and header files

[micah anderson]

Package: wnpp
Severity: wishlist
Owner: mi...@debian.org

* Package name: deltachat-core
  Version : 0.24.0
  Upstream Author : Delta.chat 
* URL : https://github.com/deltachat/deltachat-corecode
* License : GPL
  Programming Lang: C
  Description : Delta.chat development library and header files

 Delta Chat is a modern messenger. It is like email in a new dress.
 Just better, safer and user-optimised. This package provides the
 Delta Chat development files.

 This package has been placed in collab-maint group on salsa, and
 is otherwise being team maintained by myself and another.
micah


signature.asc
Description: PGP signature

Bug#897427: multiple tun/tap devices

[micah anderson]

I believe the issue has to do with multiple tun/tap devices. The first
one works, but any further ones after fail. You can experience this with
multiple KVM guests, or trying to run openvpn listening on UDP and
TCP. Only one will work, the rest will fail.

It seems like Ben has already found the source of the problem, based on
what he said on #debian-kernel.

-- 
micah

Bug#893644: stretch-pu: package leap-archive-keyring/2016.03.08

[micah anderson]

"Adam D. Barratt"  writes:

> Control: tags -1 + moreinfo
>
> On Wed, 2018-03-21 at 14:07 +0100, micah wrote:
>> "Adam D. Barratt"  writes:
>> 
>> > Control: tags -1 + moreinfo
>> > 
>> > On Tue, 2018-03-20 at 16:32 -0400, micah wrote:
>> > > The leap-archive-keyring is a simple archive keyring package that
>> > > contains the
>> > > signing key for trusting the archive of the LEAP encryption
>> > > access
>> > > project. Unfortunately, the expiration date chosen for the key
>> > > that
>> > > is included
>> > > in the package in Stretch was too low, and it has expired.
>> > > 
>> > > The newer package that is available in testing, unstable, and
>> > > backports provides
>> > > a key with a sufficient length to cover the stable release cycle.
>> > > 
>> > > I would like to propose that this package be included in the next
>> > > stable release point update.
>> > 
>> > We'd need to see a debdiff of the proposed upload, built on and
>> > tested
>> > against stretch, please.
>> 
>> Sorry, I thought I had attached the debdiff, here it is:
>
> Ah, sorry, I meant of the source packages, not the binaries.

Of course, I should have assumed that. I've attached the source debdiff
to this email.

> (Also, as per above - "of the proposed upload, built on and tested
> against stretch". The provided debdiff is against the version that was
> uploaded to unstable.

Fixed.

> An upload to stretch at least needs a new changelog stanza with a
> different version number - most likely 2016.03.08+deb9u1, but possibly
> 2017.11.24~deb9u1 if you wish to argue that all of the changes since
> the current version in stretch are appropriate for a stable update.)

I went with 2017.11.24~deb9u1 because indeed, the changes since the
current version in stretch are appropriate for a stable update, namely:

1. Providing keys in a second location, to aid in the transition from
jessie->stretch methods for how sources.list [signed-by=] method changed
to allow for both paths and fingerprints

2. fix priority to be in-line with debian policy

3. add a dependency on gnupg

4. update the expirations on the keys themselves

I'm only unsure if changing the Priority section is allowed in a stable
point update?

Thanks!
Micah




leap-archive-keyring-src.debdiff
Description: Binary data


signature.asc
Description: PGP signature

Bug#865410: Should be fixed in stable

[micah anderson]

This memory leak is real. I've hit it many times, it ate up all my
memory, and filled up all my disks with logs like:

LOG4[218498]: Possible memory leak at ../crypto/asn1/asn1_lib.c:277:
33195 allocations

I ended up getting 4 log files of 14gig each, because of the severity of
the logging.

I've backported the newer version, and the problem stopped.

I really think this needs to be fixed in stable, in a point update.

micah


signature.asc
Description: PGP signature

Bug#880220: Fixed in upload

[micah anderson]

Version: 2007.11.08
thanks

This issue was resolved in the most recent upload,
micah

Bug#859927: Works, uploaded to DELAYED-3

[micah anderson]

That fix works, I've done a NMU fixed package and uploaded it to
DELAYED-3.

Micah

Bug#859927: Confirmed

[micah anderson]

I've confirmed this bug, as reported:

I installed lighttpd:

The following NEW packages will be installed:
  lighttpd spawn-fcgi
0 upgraded, 2 newly installed, 0 to remove and 326 not upgraded.
Need to get 299 kB of archives.
After this operation, 1,019 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://httpredir.debian.org/debian sid/main amd64 lighttpd amd64 1.4.45-1 
[284 kB]
Get:2 http://httpredir.debian.org/debian sid/main amd64 spawn-fcgi amd64 
1.6.4-1+b1 [14.9 kB]
Fetched 299 kB in 1s (194 kB/s)  
Selecting previously unselected package lighttpd.
(Reading database ... 206019 files and directories currently installed.)
Preparing to unpack .../lighttpd_1.4.45-1_amd64.deb ...
Unpacking lighttpd (1.4.45-1) ...
Selecting previously unselected package spawn-fcgi.
Preparing to unpack .../spawn-fcgi_1.6.4-1+b1_amd64.deb ...
Unpacking spawn-fcgi (1.6.4-1+b1) ...
Setting up spawn-fcgi (1.6.4-1+b1) ...
Setting up lighttpd (1.4.45-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/lighttpd.service → 
/lib/systemd/system/lighttpd.service.
Processing triggers for systemd (232-20) ...
Processing triggers for man-db (2.7.6.1-2) ...

and confirmed it is running:

root@reeds:/home/micah/debian/lighttpd-1.4.45# ps auxw |grep lighttpd
www-data  2129  0.0  0.0  58924  5452 ?Ss   15:03   0:00 
/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
root  4119  0.0  0.0  12788   956 pts/3S+   15:03   0:00 grep lighttpd

I enabled the module as described in the bug:

root@reeds:/home/micah/debian/lighttpd-1.4.45# lighttpd-enable-mod fastcgi-php
Met dependency: fastcgi
Enabling fastcgi-php: ok
Enabling fastcgi: ok
Run "service lighttpd force-reload" to enable changes
root@reeds:/home/micah/debian/lighttpd-1.4.45# service lighttpd force-reload

and now lighttpd is not running:

root@reeds:/home/micah/debian/lighttpd-1.4.45# ps auxw |grep lighttpd
root  4223  0.0  0.0  12788   980 pts/3S+   15:04   0:00 grep lighttpd

I will attempt to apply the patch and see if it works.

micah

Bug#859050: tried changing order

[micah anderson]

I changed the order in the Build-dep so that it was:

libssl1.0-dev|libssl-dev

instead of:

libssl-dev|libssl1.0-dev

It built fine, and used libssl1.0-dev instead. I think that this would
solve lighttpd being in error state for this transition:

https://release.debian.org/transitions/html/ssl1.0.html

I'm happy to upload this, if you want.

micah


signature.asc
Description: PGP signature

Bug#857070: stunnel4: Missing defaults in man page

[micah anderson]

Package: stunnel4
Version: 3:5.39-2
Severity: wishlist

Hello,

The following options in the man page do not indicate their defaults. I had to
dig into the source to find them:

sessionCacheSize: 1000
sessionCacheTimeout: 300
TIMEOUTbusy: 300
TIMEOUTclose: 60
TIMEOUTidle: 43200
TIMEOUTconnect: 10

There are perhaps others, but these were the ones I was trying to find.


Micah

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages stunnel4 depends on:
ii  adduser  3.115
ii  libc62.24-9
ii  libssl1.11.1.0e-1
ii  libsystemd0  232-19
ii  libwrap0 7.6.q-26
ii  lsb-base 9.20161125
ii  netbase  5.4
ii  openssl  1.1.0e-1
pn  perl:any 

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  

-- no debconf information

Bug#856408: apt: Signed-By does nothing

[micah anderson]

Julian Andres Klode  writes:

>> deb http://deb.leap.se/debian sid main Signed-By: 
>> 2f483BbCE87BEE2F7DFE99661E34A1828E203901
>
> That's invalid syntax. It should look like these:
>
> deb [signed-by=BBEBDCB318AD50EC6865090613B00F1FD2C19886] 
> http://repository.spotify.com stable non-free

Thanks, I totally missed the format details in the man page before!

> deb [signed-by=/usr/share/keyrings/debian-archive-keyring.gpg 
> target-=Contents-deb] http://deb.debian.org/debian/ experimental main contrib 
> non-free

I'm very curious about this "target-=Contents-deb" option. I see the
section in sources.list(5) saying that this is an option to indicate
what download targets apt will try to acquire from this source. My
understanding is that the -= means that this modifies the default value
to remove the given value so it wont be acquired.

However, I don't quite get what this configuration is intended to do,
why would you indicate that you do not want to download the Contents-deb
files. Would you do that just to speed up apt updates?

thanks!
micah

Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB

[micah anderson]

Apollon Oikonomopoulos  writes:

> On 09:29 Thu 02 Feb , micah wrote:
>> Apollon Oikonomopoulos  writes:
>> 
>> ...
>> >  - As soon as 4.8.2-1 enters testing, I intend to upload 4.8.2-2, with 
>> >the following changes:
>> ...
>> >It will go through NEW for puppet-terminus-puppetdb, vim-puppet and 
>> >puppet-el, but there should be no problems here.
>> 
>> According to the release page[0]:
>> 
>> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day migrations)
>> 
>> Doesn't that mean that this package wont be able to make it through NEW?
>
> It will go through NEW (unstable is not affected by the freeze). Also 
> the "no new packages" stuff actually means "no new source packages in 
> testing".

Ah, I didn't realize this subtle difference.

> I know it's a bit late (but not too late), but I think we should have a 
> shot with the release team. The change is not that big and it will not 
> break existing systems anyway.

I think so too - especially considering DSA uses puppet with
storedconfigs.

micah

Bug#800588: [debian-mysql] Bug#800588: Upgrade from jessie

[micah anderson]

Otto Kekäläinen  writes:

> 2017-01-31 0:27 GMT+02:00 micah :
>> I upgraded a machine from jessie to stretch today and then when I went
>> to reboot, I had to wait 10 minutes for mysql to fail to shutdown.
>
> Looking at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800588 I
> don't see Micah if you already reported what you had installed in
> Jessie, and what you upgraded to in Stretch. Please report exact
> software versions (mysql-5.5 -> mariadb-10.1 10.1.21-5?) so that there
> is a chance for somebody to try to reproduce the error.

This was a machine that I installed as jessie, and then upgraded to
stretch. I did very little on the machine before upgrading, this is the
dpkg.log info for mysql-server:

2017-01-04 20:50:02 install mysql-server-core-5.5:amd64  5.5.50-0+deb8u1
2017-01-04 20:50:03 install mysql-server-5.5:amd64  5.5.50-0+deb8u1
2017-01-04 20:50:05 install mysql-server:all  5.5.50-0+deb8u1
2017-01-04 20:50:07 status installed mysql-server-core-5.5:amd64 5.5.50-0+deb8u1
2017-01-04 20:50:23 status installed mysql-server-5.5:amd64 5.5.50-0+deb8u1
2017-01-04 20:50:23 status installed mysql-server:all 5.5.50-0+deb8u1
2017-01-12 19:52:44 status installed mysql-server-core-5.5:amd64 5.5.53-0+deb8u1
2017-01-12 19:52:59 status installed mysql-server-5.5:amd64 5.5.53-0+deb8u1
2017-01-12 19:52:59 status installed mysql-server:all 5.5.53-0+deb8u1
2017-01-20 19:29:06 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-20 19:29:18 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-20 19:29:18 status installed mysql-server:all 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status installed mysql-server-core-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:49:42 status not-installed mysql-server-core-5.5:amd64 
2017-01-27 19:49:42 install mysql-server-core-5.6:amd64  5.6.30-1
2017-01-27 19:49:42 status not-installed mysql-server-core-5.6:amd64 
2017-01-27 19:52:19 install mysql-server-core-5.6:amd64  5.6.30-1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:21 status installed mysql-server-5.5:amd64 5.5.54-0+deb8u1
2017-01-27 19:52:26 install mysql-server-5.6:amd64  5.6.30-1
2017-01-27 19:52:44 status installed mysql-server-core-5.6:amd64 5.6.30-1
2017-01-27 19:53:00 status installed mysql-server-5.6:amd64 5.6.30-1
2017-01-27 19:53:00 status installed mysql-server:all 5.6.30-1

These are the mariadb events:

2017-01-27 19:52:30 install mariadb-common:all  10.1.20-3
2017-01-27 19:52:31 install libmariadbclient18:amd64  10.1.20-3
2017-01-27 19:52:47 status installed mariadb-common:all 10.1.20-3
2017-01-27 19:52:48 status installed libmariadbclient18:amd64 10.1.20-3
2017-01-30 10:17:55 status installed mariadb-common:all 10.1.21-5
2017-01-30 10:18:02 status installed libmariadbclient18:amd64 10.1.21-5

Bug#817521: libapache-mod-removeip: Removal of debhelper compat 4

[micah anderson]

Hello,

intrigeri  writes:

> Hi Micah,
>
> Adrian Bunk:
>> Can you anyway NMU this package?
>
>> The alternative is that it will get removed from stretch soon.
>
> Well, it's not a goal of mine to include as many packages in Stretch
> as possible. So I really don't want to be the one who decides that
> a given package will be part of a Debian stable release, if its
> maintainers are not ready to support it there; in this case, I see
> little indication that they are. (And backports are always an option
> anyway :)
>
> Micah, what do you think? If you're ready to support the package in
> Stretch, I'm happy to give some one-shot help by NMU'ing it over the
> week-end.

It would be great if the package could continue to be in
Stretch.

Unfortunately, I have not been able to address this issue, and would be
very happy if you could NMU the work you did to fix this issue!

micah


signature.asc
Description: PGP signature

Bug#848766: reel: FTBFS: ERROR: Test "ruby2.3" failed: Failure/Error: response = http.request(request)

[micah anderson]

Antonio Terceiro  writes:

>> Relevant part (hopefully):
>> >  Failure/Error: response = http.request(request)
>> > 
>> >  OpenSSL::SSL::SSLError:
>> >SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert 
>> > unsupported certificate

Hmm, I built the reverse depends on ruby-certificate-authority and found
this failure in reel, and patched it in 0.6.1-3 to fix this error. I'm
surprised its back, that means something didn't go right with my patch.
I'll have a look at it.

> Micah, was there a specific reason to package an unreleased snapshot of
> ruby-certificate-authority? The changelog doesn't really say anything.

The last official upstream tagged release and gem publish was august
2012. The upstream author bumped the version to 2.0 in Sept. 2012, and
there have been a number of important fixes (including security) since
then. There is also a request in the github issue tracker for a new
release in May 2014, no response.

I spoke with the original packager (Sebastien Badia) about updating this
to the current master which fixes those issues, and he gave the go ahead
if we resolved all the reverse-deps.

micah

Bug#696335: This happens with 'apt' as well

[micah anderson]

Hi,

This bug is pretty annoying, because it makes it impossible to recover
from problems in a scriptable way. I thought maybe things would be
better in 'apt', but it turns out its still the case that you will get a
'0' result code:

root@muck:/home/micah# apt update
Hit:1 http://deb.leap.se/debian sid InRelease
Err:2 http://cdn.debian.net/debian lenny InRelease 
  Cannot initiate the connection to cdn.debian.net:80 
(2001:41c8:1000:21::21:35). - connect (101: Network is unreachable) [IP: 
2001:41c8:1000:21::21:35 80]
Reading package lists... Done  
Building dependency tree   
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://cdn.debian.net/debian/dists/lenny/InRelease  Cannot 
initiate the connection to cdn.debian.net:80 (2001:41c8:1000:21::21:35). - 
connect (101: Network is unreachable) [IP: 2001:41c8:1000:21::21:35 80]
W: Some index files failed to download. They have been ignored, or old ones 
used instead.
root@muck:/home/micah# echo $?
0
root@muck:/home/micah# 

The man page for apt(8) says this:

DIAGNOSTICS
   apt returns zero on normal operation, decimal 100 on error.

but that is not true because of this.

thanks!
micah

Bug#824612: python3-pyqt5: Python 3 Qt5 5.6 having problems with decoration signatures

[Micah Anderson]

Package: python3-pyqt5
Version: 5.6+dfsg-1
Severity: normal

Hello,

The current Sid version of Qt5 5.6 for python3 has problems with decoration
signatures as in: `TypeError: decorated slot has no signature compatible with
mapped(QString)`. Other platforms with python3 and Qt5 5.6 do not have this
problem.

Trying to get a new version of Nagstamon to work with this version of Qt5
results in this:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Nagstamon/Config.py", line 594, in 
KeyringAvailable
import secretstorage
ImportError: No module named 'secretstorage'
Traceback (most recent call last):
  File "/usr/bin/nagstamon", line 54, in 
from Nagstamon.QUI import (APP,
  File "/usr/lib/python3/dist-packages/Nagstamon/QUI/__init__.py", line 5992, 
in 
dialogs = Dialogs()
  File "/usr/lib/python3/dist-packages/Nagstamon/QUI/__init__.py", line 3772, 
in __init__
self.settings = Dialog_Settings(Ui_settings_main)
  File "/usr/lib/python3/dist-packages/Nagstamon/QUI/__init__.py", line 4112, 
in __init__
self.toggle_toggles()
  File "/usr/lib/python3/dist-packages/Nagstamon/QUI/__init__.py", line 3921, 
in toggle_toggles
self.signalmapper_toggles.mapped[str].connect(self.toggle)
TypeError: decorated slot has no signature compatible with mapped(QString)

If the error causing line is removed then it appears on other occurences of the
decorator, regardless of QString or whatever is being used.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pyqt5 depends on:
ii  libc62.22-9
ii  libgcc1  1:6.1.1-3
ii  libpython3.5 3.5.1-12
ii  libqt5core5a [qtbase-abi-5-5-1]  5.5.1+dfsg-16+b1
ii  libqt5dbus5  5.5.1+dfsg-16+b1
ii  libqt5designer5  5.5.1-3
ii  libqt5gui5   5.5.1+dfsg-16+b1
ii  libqt5help5  5.5.1-3
ii  libqt5network5   5.5.1+dfsg-16+b1
ii  libqt5printsupport5  5.5.1+dfsg-16+b1
ii  libqt5test5  5.5.1+dfsg-16+b1
ii  libqt5widgets5   5.5.1+dfsg-16+b1
ii  libqt5xml5   5.5.1+dfsg-16+b1
ii  libstdc++6   6.1.1-3
ii  python3  3.5.1-3
ii  python3-sip [sip-py3api-11.3]4.18+dfsg-1

python3-pyqt5 recommends no packages.

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

-- no debconf information

Bug#821111: nginx: Failure to remove socket due to Debian's method of stopping

[micah anderson]

Package: nginx
Version: 1.9.10-1
Severity: normal
Tags: patch

Hello,

It turns out that the way that Debian implements stopping nginx is by
sending it, through the start-stop-daemon's --retry option a SIGQUIT to
nginx, which is interpreted by nginx as a "gradeful shutdown", but it
turns out is not very clean way to shutdown, and nginx developers think
that nobody should be doing this[0]. The other stop method is the
SIGTERM, which is what they are expecting people to send to shutdown
nginx and it properly cleans up the sockets.


If you configure nginx to use a unix socket for a listener, then when
you restart, or stop and then start, nginx, it will fail to start
because it will not clean up the listening socket because it was stopped
with the 'SIGQUIT' method[1][2].

Additionally, in version 1.6.2-3 of the package upload this changelog
entry appears:

 * debian/nginx-common.nginx.init:  
  
+ Gracefully stop nginx by default, we are switcing to a configurable   
   
  STOP/5/TERM/5/KILL/5 schedule. We are now in sync with the systemd
   
  service file. (Closes: #762708)

However, the initscript and the systemd service file are *not* in
sync. The systemd service file has just '--retry QUIT/5' and the
initscript has 'QUIT/5/TERM/5/KILL/5', so these are most definitely not
in sync.

I've attached patches that syncs these up, and has them do a SIGTERM
instead of a SIGQUIT because it appears to be more "graceful" and will
properly clean up sockets.

micah

0. https://trac.nginx.org/nginx/ticket/753#comment:5
1. https://trac.nginx.org/nginx/ticket/753 and
2. https://trac.nginx.org/nginx/ticket/952).

--- /tmp/nginx	2016-04-15 12:07:29.634756281 -0400
+++ /etc/init.d/nginx	2016-01-26 13:12:14.0 -0500
@@ -20,7 +20,7 @@
 	. /etc/default/nginx
 fi
 
-STOP_SCHEDULE="${STOP_SCHEDULE:-TERM/5/QUIT/5/KILL/5}"
+STOP_SCHEDULE="${STOP_SCHEDULE:-QUIT/5/TERM/5/KILL/5}"
 
 test -x $DAEMON || exit 0
 
--- /tmp/nginx.service	2016-04-15 12:07:12.135245311 -0400
+++ /lib/systemd/system/nginx.service	2016-01-26 13:12:14.0 -0500
@@ -20,7 +20,7 @@
 ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
 ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
 ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
-ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry TERM/5/QUIT/5/KILL/5 --pidfile /run/nginx.pid
+ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
 TimeoutStopSec=5
 KillMode=mixed
 

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#717991: python-parsedatetime: New upstream version available

[Micah Anderson]

Hi,

> (If you don't have time to maintain this package anymore, I'm willing
> to help out. I'm already a member of the DPMT and can prepare an
> updated package if you want).

The maintainer for this package is the Python Modules Team
, it seems you are already
a member of that team, the
https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin page says this
about packages:

There is a unwritten policy about the usage of Maintainer and Uploaders
field, you might be interested to know about:

If the team is in the Maintainer field (and you are in Uploaders
field) then every member of the team can apply changes to the
package and upload it freely;

if you are in the Maintainer field (and the team is in Uploaders
field) then every member of the team can apply changes to the
package but any upload should be acknowledged by you (there are some
exceptions, like uploads to fix RC bugs, but are infrequent).

As a general rule of thumb, just set Maintainer to the team; there might
be some exceptions, like in situations where the package is so complex
that a check from a knowledgeable person is welcome before an upload but
they are very rare.

If the team is in Maintainer field, remember to subscribe appropriate
mailing list or at least bts and contact keywords on this page.

So, it seems like you are free to update the package!

micah

Bug#797788: gcc5 transition

[micah anderson]

Chris Knadle  writes:

> micah:
>> Chris Knadle  writes:
>
>>> I'm currently updating my 1.2.10-1 prepared upload for Debian with a patch
>>> for #787384, which I just did for the package in my repo only for Sid,
>>> because the new zeroc-ice hasn't transitioned to Stretch yet AFAIK.
>> 
>> The reason I'm really interested in this is because of the PFS cipher
>> support. Unfortunately, it seems like this isn't particularly useful
>> unless things are built from the git head at the moment, and maybe that
>> support isn't even finished. It would be great if this could be brought
>> into the debian packages (even if it might need to be done before 1.3 is
>> released), see https://github.com/mumble-voip/mumble/issues/1811
>
> I'm really interested in mumble in terms of encryption/privacy/integrity
> too, so I'd love to get PFS support but in reading the bug it looks like
> that's not possible for now.  Upstream has specifically requested I only
> release the stable 1.2 builds (the non-snapshot+cherry-pick-patches release
> for wheezy that Ron Lee made has been particularly painful for upstream) and
> avoid uploading any of the 1.3 "snapshot" builds until they release a stable
> version, and #1811 above states that the mumble 1.2 releases are bound to Qt
> 4... and sounds like Qt 4 can't do PFS

Yeah, I think you are right.

As an aside, the Qt 4 problem shouldn't be an issue because QT 5 is in
Debian now.

> Mumble upstream also have some Qt 4 patches to add TLS 1.1 and 1.2 support,
> but the way they work is to redefine QSsl::TlsV1 to mean "TLS 1.0 or later"
> and they don't recommend upstream distributions try to use these patches.
> This is explained in:
>
>http://blog.mumble.info/mumble-1-2-9/
>
> The only good news is that with the 1.2.10-1 release I'm about to upload,
> the sslCiphers can be specified in the mumble-server.ini file. [That's
> probably important enough that I should add a note about this to the NEWS 
> file.]

Yeah, I've been testing this version against the same server version,
and trying to set the sslciphers option in the murmurd config file, it
seems to set it, but I can't seem to get the client to pick up those
preferred ciphers, and I'm not sure why.

> BTW: in the "Advanced" settings under "Network" in the mumble client you can
> use "Force TCP mode" so that mumble could be used over Tor and then starting
> mumble in a terminal with 'torify mumble'.  [That works! :-)]

You can also not set "Force TCP mode" and just use 'torsocks mumble' -
that works fine too (even with .onion addresses!) Mumble seems to
automatically switch to one mode over the other, if it can do it, so
maybe the Force mode would just make it faster in figuring this out? I
just know it was pretty fast in figuring it out for me.

> Re: integrity: a while ago I changed the the debian/watch file to have uscan
> check OpenPGP signatures of the upstream releases.  And with 1.2.10-1 I'm
> switching debian/rules to 'dh' in an effort to get reproducible builds.

that is great to hear, thanks for doing those changes!

micah

Bug#797788: new version of mumble

[micah anderson]

Hi,

If you aren't ready to upload the new mumble packages yet, would you
make the ones you've prepared available? I'd like to test them as soon
as possible.

thanks!
micah

Bug#797788: gcc5 transition

[micah anderson]

Hi Chris,

It looks like the gcc5 transition is no longer affecting mumble. Maybe
you can upload the new version now?

I'd really like this available as a jessie backport, so I'd love to see
it transition soon!

micah

Bug#786987: evidence

[Micah Anderson]

Hi,

I hear the argument that Colin is making, and understand and respect the
use-case he describes for the setting, and wouldn't argue that this
option should be removed. However, I feel like the comparison that is
being setup doesn't make sense for justifying that the setting is the
default.

The argument is basically that we should use the current setting as the
default for everyone, because there is one specific use-case that
justifies it. While the argument against reverting this default is that
there isn't any specific evidence of people using the version string to
select servers for attack.

I think that is much easier to come up with an actual use-case for the
first, but much harder to provide concrete evidence of the latter. That
isn't necessarily because this never happens, but very possibly its
because it is quite hard to provide specific evidence of this being
used, regardless if it is actually being done.

We do know, in general, where this version string is used in ways that
are undesirable:

 . it is a module in metasploit for helping identify vulnerable
 versions[0]

. it is used as a selector in NSA's XKEYSCORE queries in conjunction
 with the metadata database of potentially exploitable services
 (BLEAKINQUIRY) by the NSA group S31176 for targeted exploit and
 compromise[1][2]

. it is used by annoying security scanners, such as Nessus to
 incorrectly identify vulnerable versions -- I would normally argue
 that version strings are a terrible way of finding an actual
 vulnerability, in fact I *regularly* have to argue with people who run
 these security scanners against our network and then bring us a
 report to show me how many vulnerable services we have because the
 version numbers in their outdated database don't take into account
 Debian Security fixes... but this is precisely why I am bringing this
 up, because I have to regularly argue with people about these version
 strings. They are wrong, of course, but I don't want to have to deal
 with that pointless argument. If there was no version string, I
 wouldn't have to do that anymore.

. its used in CTF (capture the flag) events, in order to know what OS is
running on a system that only has ssh running, and what version of ssh
is running so that you can look at exploits that could be used to
compromise the system for a flag.

apart from these, things like malware dropper (for instance) that use
0-days don't bother with version strings, they just hammer the internet
and try it anyways... but that depends a lot on the malware.

I'd actually turn that argument around and say that justifying Debian
carrying this patch and setting this non-standard default from upstream
for everyone, just because of one example, is not sufficient.

micah

0. http://www.offensive-security.com/metasploit-unleashed/Service_Identification
1. 
http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html
2. http://www.spiegel.de/media/media-35515.pdf


signature.asc
Description: PGP signature

Bug#783145: jessie-pu: package sqlcipher/3.2.0-1

[Micah Anderson]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hello!

It seems we missed the RC bug fix date, and now we are in the quiet
period. However, I have uploaded a NMU to unstable to fix #776987 so I
wanted to file a bug here, as was detailed in debian-devel-announce.

Please find attached the debdiff against the two source packages.

Micah


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru sqlcipher-3.2.0/debian/changelog sqlcipher-3.2.0/debian/changelog
--- sqlcipher-3.2.0/debian/changelog	2014-10-17 20:16:29.0 -0300
+++ sqlcipher-3.2.0/debian/changelog	2015-04-22 17:03:50.0 -0300
@@ -1,3 +1,11 @@
+sqlcipher (3.2.0-1.1) unstable; urgency=high
+
+  [ Ben Carrillo ]
+  * Non-maintainer upload.
+  * use a separate variable to track SQLCIPHER version (Closes: #776987)
+
+ -- Micah Anderson mi...@debian.org  Wed, 22 Apr 2015 10:38:05 -0400
+
 sqlcipher (3.2.0-1) unstable; urgency=low
 
   * updated to latest upstream: v3.2.0
diff -Nru sqlcipher-3.2.0/debian/patches/20-change-name-to-sqlcipher.patch sqlcipher-3.2.0/debian/patches/20-change-name-to-sqlcipher.patch
--- sqlcipher-3.2.0/debian/patches/20-change-name-to-sqlcipher.patch	2014-10-17 00:24:01.0 -0300
+++ sqlcipher-3.2.0/debian/patches/20-change-name-to-sqlcipher.patch	2015-04-22 17:03:50.0 -0300
@@ -1,7 +1,38 @@
 a/VERSION
-+++ b/VERSION
-@@ -1 +1 @@
--3.8.6
-\ No newline at end of file
+--- a/Makefile.in
 b/Makefile.in
+@@ -89,6 +89,7 @@ TCC += $(OPTS)
+ VERSION = @VERSION@
+ VERSION_NUMBER = @VERSION_NUMBER@
+ RELEASE = @RELEASE@
++SQLCIPHER_VERSION = @SQLCIPHER_VERSION@
+ 
+ # Filename extensions
+ #
+--- /dev/null
 b/VERSION_SQLCIPHER
+@@ -0,0 +1 @@
 +3.2.0
-\ No newline at end of file
+--- a/configure.ac
 b/configure.ac
+@@ -179,6 +179,10 @@ VERSION_NUMBER=[`cat $srcdir/VERSION \
+ AC_MSG_NOTICE(Version number set to $VERSION_NUMBER)
+ AC_SUBST(VERSION_NUMBER)
+ 
++SQLCIPHER_VERSION=[`cat $srcdir/VERSION_SQLCIPHER | sed 's/^\([0-9]*\.*[0-9]*\).*/\1/'`]
++AC_MSG_NOTICE(SQLCipher Version set to $SQLCIPHER_VERSION)
++AC_SUBST(SQLCIPHER_VERSION)
++
+ #
+ # Check to see if the --with-hints=FILE option is used.  If there is none,
+ # then check for a files named $host.hints and ../$hosts.hints where
+--- a/sqlcipher.pc.in
 b/sqlcipher.pc.in
+@@ -7,7 +7,7 @@ includedir=@includedir@
+ 
+ Name: SQLCipher
+ Description: SQL database engine
+-Version: @PACKAGE_VERSION@
++Version: @SQLCIPHER_VERSION@
+ Libs: -L${libdir} -lsqlcipher
+ Libs.private: @LIBS@
+ Cflags: -I${includedir}
diff -Nru sqlcipher-3.2.0/debian/patches/32-fix-pkgconfig-libname.patch sqlcipher-3.2.0/debian/patches/32-fix-pkgconfig-libname.patch
--- sqlcipher-3.2.0/debian/patches/32-fix-pkgconfig-libname.patch	2014-10-17 00:25:32.0 -0300
+++ sqlcipher-3.2.0/debian/patches/32-fix-pkgconfig-libname.patch	2015-04-22 17:03:50.0 -0300
@@ -1,7 +1,7 @@
 --- a/sqlcipher.pc.in
 +++ b/sqlcipher.pc.in
 @@ -10,4 +10,4 @@ Description: SQL database engine
- Version: @PACKAGE_VERSION@
+ Version: @SQLCIPHER_VERSION@
  Libs: -L${libdir} -lsqlcipher
  Libs.private: @LIBS@
 -Cflags: -I${includedir}

Bug#764982: Backports removed from sources.list ;-(

[micah anderson]

 In my opinion it's very good when backports is default in sources.list.

My opinion is that I don't want to push ticking time bombs into the
hands of our users. And that's exactly what defaulting to enabling
backports was.

You pointed out that apt will happily install a package from backports
if it is not available in the base suite, which might mean that you
don't realize that you are going to install something from backports
because you didn't explicitly ask for it...

However, I don't see how this is a 'ticking time bomb', that seems a tad
hyperbolic. If someone wanted to install 'zmap' on wheezy, they do
apt-get install zmap, find out there is no zmap package available, what
happens next from my observations is they either give up thinking that
the package just isn't available in debian, or they enable backports and
then install zmap. The first one seems worth fixing, the second seems
worth making easier.

If you install zmap from backports and see that it is pulling from
backports during the install and you really didn't want things from
backports for some reason (and I can't think of a reason), you can
always interrupt the process, or just remove the package after its
finished installing.

Backports isn't some rouge repository filled with broken packages that
are uploaded by untrustworthy people. One of the first things I do on
every debian stable system I install is add backports entries to
sources.lists. One of the most frequent confusions of people I support,
who are using Debian, is unavailability of packages. I tell them to
install X package, and they say its not in Debian and then I have to
discuss with them about how to discover that there is a package
available in backports and how to enable it and get it. Simplifying this
user experience seems worth it.


signature.asc
Description: PGP signature

Bug#781685: cryptsetup: prompt for password if device exists, otherwise don't block for it to appear

[Micah Anderson]

Package: initramfs-tools
Version: 0.119
Severity: wishlist

I have an encrypted USB drive that is not always attached to my
system. With the default cryptsetup configuration, when the system
boots, it asks me for the passphrase and everything is fine. If the
device is not connected, then booting takes a long time because a
1min30second timeout is triggered waiting for the disk to show up.

If I set 'noauto' in crypttab, then I wont be asked for the disk
passphrase on boot, even if the device is there, but then the system
wont block waiting for the device if it is not there.

I would like it if I were prompted for passphrase for this disk, if it
is there, otherwise don't spend 1min30seconds blocking boot for it. I
understand some people might want the long timeout, but it is pretty
frustrating when you do not want it. Perhaps this could be an option
in crypttab?

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#781674: cryptsetup: Homepage moved

[Micah Anderson]

Package: cryptsetup
Version: 2:1.6.6-5
Severity: wishlist

Homepage: http://code.google.com/p/cryptsetup/ -- is no longer valid,
the project is now at: https://gitlab.com/cryptsetup/cryptsetup

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768094: bug still occurs

[micah anderson]

I just tried to do a database update with 0.19.1-1.1 and it churned for
a while and then spit out this in the log:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid

and it killed the mpd daemon :(

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776858: duplicity: Man page includes --ssh-backend option which is no longer included

[Micah Anderson]

Package: duplicity
Version: 0.7.01-1
Severity: minor

Hi,

The new version of duplicity does not support --ssh-backend, but the manpage
details that option. It seems that this should be removed from the docs.

micah

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages duplicity depends on:
ii  libc62.19-13
ii  librsync10.9.7-10
ii  python   2.7.8-2
ii  python-lockfile  1:0.8-2

Versions of packages duplicity recommends:
ii  python-oauthlib  0.6.3-1
ii  python-paramiko  1.15.1-1
ii  python-urllib3   1.9.1-3
ii  rsync3.1.1-2+b1

Versions of packages duplicity suggests:
pn  lftpnone
pn  ncftp   none
pn  python-boto none
pn  python-cloudfiles   none
pn  python-gdatanone
pn  python-swiftclient  none
pn  tahoe-lafs  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736548: Can't sign any uids if any subkey is expired

[micah anderson]

I ran into this as well, I can't sign a key because one of the subkeys
is expired. The key holder has deliberately let that key expire, but it
makes it so I can't use monkeysign to sign any uids for this user.

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768094: me too

[micah anderson]

severity 768094 important
tags 768094 patch
thanks

This is also happening to me. I can't update the database without it
crashing. I thought I had a few malformed mp3s, so I moved several out
of the way, which would cause it to work a little further and then crash
again, but it quickly became clear that there was something else going
on.

In the meantime, I stopped using mpd, because having only 10 songs in my
database was driving me nuts.

What do you think about uploading a new version with this patch to see
if it solves the issue? I don't mind doing a NMU.

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771625: openssh-server: Please add ProtectSystem=yes to service file

[Micah Anderson]

Package: openssh-server
Version: 1:6.7p1-3
Severity: wishlist

Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssh-server depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.54
ii  dpkg   1.17.22
ii  init-system-helpers1.22
ii  libc6  2.19-13
ii  libcomerr2 1.42.12-1
ii  libgssapi-krb5-2   1.12.1+dfsg-15
ii  libkrb5-3  1.12.1+dfsg-15
ii  libpam-modules 1.1.8-3.1
ii  libpam-runtime 1.1.8-3.1
ii  libpam0g   1.1.8-3.1
ii  libselinux12.3-2
ii  libssl1.0.01.0.1j-1
ii  libwrap0   7.6.q-25
ii  lsb-base   4.1+Debian13+nmu1
ii  openssh-client 1:6.7p1-3
ii  openssh-sftp-server1:6.7p1-3
ii  procps 2:3.3.9-8
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages openssh-server recommends:
ii  ncurses-term  5.9+20140913-1
ii  xauth 1:1.0.9-1

Versions of packages openssh-server suggests:
pn  molly-guard  none
ii  monkeysphere 0.37-2
pn  rssh none
ii  ssh-askpass  1:1.2.4.1-9
ii  ssh-askpass-gnome [ssh-askpass]  1:6.7p1-3
pn  ufw  none

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771628: alsa-base: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: alsa-base
Version: 1.0.27+1
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages alsa-base depends on:
ii  dpkg  1.17.22
ii  kmod  18-3

alsa-base recommends no packages.

alsa-base suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771627: bluez: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: bluez
Version: 5.23-1
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bluez depends on:
ii  dbus 1.8.12-1
ii  init-system-helpers  1.22
ii  kmod 18-3
ii  libc62.19-13
ii  libdbus-1-3  1.8.12-1
ii  libglib2.0-0 2.42.1-1
ii  libreadline6 6.3-8+b1
ii  libudev1 215-7
ii  lsb-base 4.1+Debian13+nmu1
ii  udev 215-7

bluez recommends no packages.

bluez suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771626: openvpn: Please add ProtectSystem=yes to service file

[Micah Anderson]

Package: openvpn
Version: 2.3.4-4
Severity: wishlist

Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.54
ii  init-system-helpers1.22
ii  initscripts2.88dsf-58
ii  iproute2   3.16.0-2
ii  libc6  2.19-13
ii  liblzo2-2  2.08-1
ii  libpam0g   1.1.8-3.1
ii  libpkcs11-helper1  1.11-2
ii  libssl1.0.01.0.1j-1

Versions of packages openvpn recommends:
ii  easy-rsa  2.2.2-1

Versions of packages openvpn suggests:
ii  openssl 1.0.1j-1
ii  resolvconf  1.76

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771629: cron: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: cron
Version: 3.0pl1-127
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- Package-specific info:
--- EDITOR:
not set

--- /usr/bin/editor:
/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 36008 Oct 25 18:04 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 5 root root 4096 Sep 21 21:30 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Oct  5 22:20 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Nov 25 10:52 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Nov 29 15:56 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Oct 26 23:40 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Oct 26 23:40 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Nov 25 10:52 /etc/cron.weekly


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cron depends on:
ii  adduser  3.113+nmu3
ii  debianutils  4.4+b1
ii  dpkg 1.17.22
ii  init-system-helpers  1.22
ii  libc62.19-13
ii  libpam-runtime   1.1.8-3.1
ii  libpam0g 1.1.8-3.1
ii  libselinux1  2.3-2
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages cron recommends:
ii  postfix [mail-transport-agent]  2.11.3-1

Versions of packages cron suggests:
ii  anacron2.3-22
pn  checksecurity  none
ii  logrotate  3.8.7-1+b1

Versions of packages cron is related to:
pn  libnss-ldap   none
pn  libnss-ldapd  none
pn  libpam-ldap   none
pn  libpam-mount  none
pn  nis   none
pn  nscd  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771631: dnsmasq: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: dnsmasq
Version: 2.72-2
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.72-2
ii  init-system-helpers  1.22
ii  netbase  5.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
ii  resolvconf  1.76

-- Configuration Files:
/etc/dnsmasq.conf changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771632: gdm3: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: gdm3
Version: 3.14.1-3
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.37-3+b1
ii  adduser   3.113+nmu3
ii  awesome [x-window-manager]3.4.15-1+b1
ii  dconf-cli 0.22.0-1
ii  dconf-gsettings-backend   0.22.0-1
ii  debconf [debconf-2.0] 1.5.54
ii  gir1.2-gdm3   3.14.1-3
ii  gnome-session [x-session-manager] 3.14.0-2
ii  gnome-session-bin 3.14.0-2
ii  gnome-settings-daemon 3.14.1-1
ii  gnome-shell   3.14.1-2
ii  gnome-terminal [x-terminal-emulator]  3.14.1-1
ii  gsettings-desktop-schemas 3.14.1-1
ii  libaccountsservice0   0.6.37-3+b1
ii  libaudit1 1:2.4-1
ii  libc6 2.19-13
ii  libcanberra-gtk3-00.30-2.1
ii  libcanberra0  0.30-2.1
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libgdm1   3.14.1-3
ii  libglib2.0-0  2.42.1-1
ii  libglib2.0-bin2.42.1-1
ii  libgtk-3-03.14.5-1
ii  libpam-modules1.1.8-3.1
ii  libpam-runtime1.1.8-3.1
ii  libpam-systemd215-7
ii  libpam0g  1.1.8-3.1
ii  librsvg2-common   2.40.5-1
ii  libselinux1   2.3-2
ii  libsystemd0   215-7
ii  libwrap0  7.6.q-25
ii  libx11-6  2:1.6.2-3
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.1-1
ii  libxrandr22:1.4.2-1+b1
ii  lsb-base  4.1+Debian13+nmu1
ii  metacity [x-window-manager]   1:3.14.3-1
ii  policykit-1   0.105-8
ii  rxvt-unicode [x-terminal-emulator]9.20-1+b1
ii  ucf   3.0030
ii  x11-common1:7.7+7
ii  x11-xserver-utils 7.7+3+b1
ii  xterm [x-terminal-emulator]   312-1

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.14.0-1
ii  desktop-base   7.0.3
ii  gnome-icon-theme   3.12.0-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  x11-xkb-utils  7.7+1
ii  xserver-xephyr 2:1.16.1.901-1
ii  xserver-xorg   1:7.7+7
ii  zenity 3.14.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.14.0-2
ii  libpam-gnome-keyring  3.14.0-1+b1

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771633: haveged: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: haveged
Version: 1.9.1-1
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages haveged depends on:
ii  init-system-helpers  1.22
ii  libc62.19-13
ii  libhavege1   1.9.1-1
ii  lsb-base 4.1+Debian13+nmu1

haveged recommends no packages.

haveged suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771635: network-manager: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: network-manager
Version: 0.9.10.0-3
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.8.12-1
ii  init-system-helpers1.22
ii  isc-dhcp-client4.3.1-5
ii  libc6  2.19-13
ii  libdbus-1-31.8.12-1
ii  libdbus-glib-1-2   0.102-1
ii  libgcrypt201.6.2-4
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-5
ii  libgudev-1.0-0 215-7
ii  libmm-glib01.4.0-1
ii  libndp01.4-2
ii  libnewt0.520.52.17-1+b1
ii  libnl-3-2003.2.24-2
ii  libnl-genl-3-200   3.2.24-2
ii  libnl-route-3-200  3.2.24-2
ii  libnm-glib40.9.10.0-3
ii  libnm-util20.9.10.0-3
ii  libpam-systemd 215-7
ii  libpolkit-gobject-1-0  0.105-8
ii  libreadline6   6.3-8+b1
ii  libsoup2.4-1   2.48.0-1
ii  libsystemd0215-7
ii  libteamdctl0   1.12-1
ii  libuuid1   2.25.2-3
ii  lsb-base   4.1+Debian13+nmu1
ii  policykit-10.105-8
ii  udev   215-7
ii  wpasupplicant  2.3-1

Versions of packages network-manager recommends:
ii  crda  3.13-1
ii  dnsmasq-base  2.72-2
ii  iptables  1.4.21-2+b1
ii  modemmanager  1.4.0-1
ii  ppp   2.4.6-3

Versions of packages network-manager suggests:
pn  avahi-autoipd  none
pn  libteam-utils  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771634: mpd: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: mpd
Version: 0.19.1-1
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mpd depends on:
ii  adduser   3.113+nmu3
ii  init-system-helpers   1.22
ii  libadplug-2.2.1-0 2.2.1+dfsg3-0.1
ii  libao41.1.0-3
ii  libasound21.0.28-1
ii  libaudiofile1 0.3.6-2+b1
ii  libavahi-client3  0.6.31-4+b1
ii  libavahi-common3  0.6.31-4+b1
ii  libavcodec56  6:11-2
ii  libavformat56 6:11-2
ii  libavutil54   6:11-2
ii  libbz2-1.01.0.6-7+b1
ii  libc6 2.19-13
ii  libcdio-cdda1 0.83-4.2
ii  libcdio-paranoia1 0.83-4.2
ii  libcdio13 0.83-4.2
ii  libcurl3-gnutls   7.38.0-3
ii  libdbus-1-3   1.8.12-1
ii  libexpat1 2.1.0-6+b3
ii  libfaad2  2.7-8
ii  libflac8  1.3.0-3
ii  libfluidsynth11.1.6-2
ii  libglib2.0-0  2.42.1-1
ii  libgme0   0.5.5-2
ii  libicu52  52.1-6
ii  libid3tag00.15.1b-11
ii  libiso9660-8  0.83-4.2
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20140719git3eb0ae6a~dfsg-2
ii  libmad0   0.15.1b-8
ii  libmikmod33.3.7-1
ii  libmms0   0.6.2-4
ii  libmodplug1   1:0.8.8.4-4.1+b1
ii  libmp3lame0   3.99.5+repack1-5
ii  libmp4v2-22.0.0~dfsg0-3
ii  libmpcdec62:0.1~r459-4.1
ii  libmpdclient2 2.9-1
ii  libmpg123-0   1.20.1-2
ii  libnfs4   1.9.5-2
ii  libogg0   1.3.2-1
ii  libopenal11:1.15.1-5
ii  libopus0  1.1-2
ii  libpulse0 5.0-13
ii  libresid-builder0c2a  2.1.1-14
ii  libroar2  1.0~beta11-1
ii  libsamplerate00.1.8-8
ii  libshout3 2.3.1-3
ii  libsidplay2   2.1.1-14
ii  libsidutils0  2.1.1-14
ii  libsmbclient  2:4.1.13+dfsg-2
ii  libsndfile1   1.0.25-9+b1
ii  libsoxr0  0.1.1-1
ii  libsqlite3-0  3.8.7.1-1
ii  libstdc++64.9.2-4
ii  libsystemd0   215-7
ii  libupnp6  1:1.6.19+git20141001-1
ii  libvorbis0a   1.3.4-2
ii  libvorbisenc2 1.3.4-2
ii  libvorbisfile31.3.4-2
ii  libwavpack1   4.70.0-1
ii  libwildmidi1  0.3.7-1
ii  libwrap0  7.6.q-25
ii  libyajl2  2.1.0-2
ii  libzzip-0-13  0.13.62-3
ii  lsb-base  4.1+Debian13+nmu1
ii  zlib1g1:1.2.8.dfsg-2+b1

mpd recommends no packages.

Versions of packages mpd suggests:
ii  avahi-daemon   0.6.31-4+b1
ii  gmpc [mpd-client]  11.8.16-9
pn  icecast2   none
ii  mpc [mpd-client]   0.26-1
ii  pulseaudio 5.0-13

-- Configuration Files:
/etc/mpd.conf changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771630: anacron: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: anacron
Version: 2.3-22
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages anacron depends on:
ii  debianutils  4.4+b1
ii  init-system-helpers  1.22
ii  libc62.19-13
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages anacron recommends:
ii  cron [cron-daemon]   3.0pl1-127
ii  rsyslog [system-log-daemon]  8.4.2-1

Versions of packages anacron suggests:
ii  postfix [mail-transport-agent]  2.11.3-1
ii  powermgmt-base  1.31+nmu1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771636: rsyslog: Please add ProtectSystem=yes to systemd service file

[Micah Anderson]

Package: rsyslog
Version: 8.4.2-1
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Hello,

If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.

There is no reason why it needs to write there, so enabling this
option should not cause any problems.

This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.

micah

[0] 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.22
ii  initscripts  2.88dsf-58
ii  libc62.19-13
ii  libestr0 0.1.9-1.1
ii  libjson-c2   0.11-4
ii  liblogging-stdlog0   1.0.4-1
ii  liblognorm1  1.0.1-3
ii  libuuid1 2.25.2-3
ii  lsb-base 4.1+Debian13+nmu1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages rsyslog recommends:
ii  logrotate  3.8.7-1+b1

Versions of packages rsyslog suggests:
pn  rsyslog-docnone
pn  rsyslog-gnutls none
pn  rsyslog-gssapi none
pn  rsyslog-mongodbnone
pn  rsyslog-mysql | rsyslog-pgsql  none
pn  rsyslog-relp   none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752420: couchdb: Please upgrade to 1.6.0

[micah anderson]

Hi,

I'm sorry I didn't reply to your earlier mail, I was not CC'd on it and not
subscribed to the bug. I've just subscribed to the bug so I will get further
replies without the need for the CC.

On Tue, Jul 08, 2014 at 06:33:34PM +0200, André Gaul wrote:
 Am 08.07.2014 08:39, schrieb László Böszörményi (GCS):
   I think there's a small misunderstanding. Packaging CouchDB itself is
  not a daunting task, 
 
 Maybe there was a misunderstanding. In Micah's summary it appeared to me
 that it suffices to note the embedded projects. If you (as the
 maintainer) think that all included dependencies should be debianized
 before, then that's OK and I'll help where I can.

Indeed, you are correct. I think that László should have a read of my earlier
messages on this bug and if there is a disagreement about any of the conclusions
I made, it would be good to hear the reasons!

That said, I think that working on adding the dependencies is still worth it. As
I identified in my message, there are some places where I was going to note the
embedded code copy, until a proper package has been made, so making those proper
packages would be the right way forwards.

 One comment on the source of the 1.6 package: although it may be easy to
 create, I don't like to repeat work that already has been done. ;)

Because of the ongoing effort upstream to merge bigcouch, and my requirements
for the bigcouch functionality, I decided to wait on this package until that
merge has completed and then move on packaging that newer version. It seems like
that merge is about to complete, and I am going to look at packaging a newer
version, perhaps from git, so I will look back on this issue to try and make
some progress with it in the near future. 

I have the 1.6.0 package work I've done locally, I wasn't sure where to push it
to, as I didn't see a repostiory that is being used for couchdb in debian. I can
make a collab-maint repository if László agrees and maybe we can collaborate
with others who are interested in working on the package?

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760347: Merged bugs...

[micah anderson]

I merged these bugs, but it seems that automatically tagged 760347 as
wontfix, because the other bug was marked that. I didn't intentionally
do that. I guess if the old status is no longer relevant, then perhaps
re-opening the bug would be in order.

I'll step out of the way of this as I think I've created enough
confusion already.

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762128: openssh-server: Spit out ssh host keys after generating in postinst (easy, and really useful!)

[Micah Anderson]

Package: openssh-server
Version: 1:6.6p1-7
Severity: wishlist

It suddenly dawned on me today, after doing this for the millionth time, that
when you install the openssh-server package, and it generates the ssh-host keys,
it would be super helpful if it simply ran ssh-keygen -lf against those
generated host keys so that the fingerprints would be spit out on the screen. 

What I do is install the package, then I type that manually, every single
time. It strikes me as an incredibly simple change that would be really useful!

micah


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssh-server depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.53
ii  dpkg   1.17.13
ii  init-system-helpers1.21
ii  libc6  2.19-11
ii  libcomerr2 1.42.12-1
ii  libgssapi-krb5-2   1.12.1+dfsg-9
ii  libkrb5-3  1.12.1+dfsg-9
ii  libpam-modules 1.1.8-3.1
ii  libpam-runtime 1.1.8-3.1
ii  libpam0g   1.1.8-3.1
ii  libselinux12.3-2
ii  libssl1.0.01.0.1i-2
ii  libwrap0   7.6.q-25
ii  lsb-base   4.1+Debian13
ii  openssh-client 1:6.6p1-7
ii  openssh-sftp-server1:6.6p1-7
ii  procps 1:3.3.9-7
ii  zlib1g 1:1.2.8.dfsg-2

Versions of packages openssh-server recommends:
ii  ncurses-term  5.9+20140712-2
ii  xauth 1:1.0.9-1

Versions of packages openssh-server suggests:
pn  molly-guard  none
ii  monkeysphere 0.37-1
pn  rssh none
ii  ssh-askpass-gnome [ssh-askpass]  1:6.6p1-7
ii  ufw  0.33-2

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755015: [Pkg-utopia-maintainers] Bug#755015: network-manager: diff for NMU version 0.9.10.0-1.1

[micah anderson]

micah mi...@debian.org writes:

 I do know that this patch did resolve the issue I was experiencing,
 however your email has caused me to question if the issue that was
 originally reported in 755015 was the same issue as the one I was
 experiencing. I should have that figured out relatively soon and get
 back to you.

 and now that -2 has been uploaded, without the patch, the issue is
back.

micah


pgpa8UN_adANF.pgp
Description: PGP signature

Bug#755015: [Pkg-utopia-maintainers] Bug#755015: network-manager: diff for NMU version 0.9.10.0-1.1

[micah anderson]

Michael Biebl bi...@debian.org writes:

 Am 11.08.2014 19:06, schrieb micah anderson:
 Control: tags 755015 + patch
 Control: tags 755015 + pending
 
 Hello!
 
 I've prepared an NMU for network-manager (versioned as 0.9.10.0-1.1) and
 uploaded it to DELAYED/5-day. Please feel free to tell me if I
 should delay it longer.

 Are you sure the patch you applied actually fixes #755015?

I've reviewed the original description of #755015 and now I believe that
the patch that I applied in the NMU is for a different issue. I'll
report a different bug for that.

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761114: network-manager: erroneously removes externally provided routes

[Micah Anderson]

Package: network-manager
Version: 0.9.10.0-2
Severity: serious
Tags: patch
Justification: breaks unrelated software

Hello,

When using unrelated software, such as openvpn, that pushes default routes,
network-manager immediately (and incorrectly) removes that route. This is new
behavior in 0.9.10, it does not do this in previous versions.

I spent quite a bit of time debugging this issue with upstream NM people
on their IRC channel, in the end they came up with a patch that was
committed upstream in git with the following hash:
06703c1670d0f96834b268920b09792e22fdb4c4)

I tested this change, and it worked well for me, previously I uploaded a NMU,
with this patch, thinking that this was #755015, and it successfully fixed the
problem for me and others I know who are experiencing this issue. However, the
NMU was not acknowledged in -2, due to it being targeted for the incorrect bug
number.

Considering that this effectively breaks all OpenVPN setups (and other software
that modifies default routes) that are not using network-manager's built-in VPN
mechanisms, this seems to me a serious regression over previous versions. Seeing
as upstream has acknowledged this issue and provided a fix for it and that fix
has been tested and even migrated to testing, it seems to me appropriate to
cherry-pick the change in the package without waiting for the next major release
of NM. 

I'm happy to re-NMU this fix, this time with the right bug number. Attached is
the NMU diff (I'd only add the bug number to the changelog).

micah


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.8.6-2
ii  init-system-helpers1.21
ii  isc-dhcp-client4.3.1-1
ii  libc6  2.19-10
ii  libdbus-1-31.8.6-2
ii  libdbus-glib-1-2   0.102-1
ii  libgcrypt111.5.4-3
ii  libglib2.0-0   2.40.0-5
ii  libgnutls-deb0-28  3.3.7-2
ii  libgudev-1.0-0 208-8
ii  libmm-glib01.2.0-1
ii  libndp01.4-1
ii  libnewt0.520.52.17-1
ii  libnl-3-2003.2.24-2
ii  libnl-genl-3-200   3.2.24-2
ii  libnl-route-3-200  3.2.24-2
ii  libnm-glib40.9.10.0-2
ii  libnm-util20.9.10.0-2
ii  libpam-systemd 208-8
ii  libpolkit-gobject-1-0  0.105-6.1
ii  libreadline6   6.3-8
ii  libsoup2.4-1   2.46.0-2
ii  libsystemd-daemon0 208-8
ii  libsystemd-login0  208-8
ii  libteamdctl0   1.12-1
ii  libuuid1   2.20.1-5.8
ii  lsb-base   4.1+Debian13
ii  policykit-10.105-6.1
ii  udev   208-8
ii  wpasupplicant  1.1-1

Versions of packages network-manager recommends:
ii  crda  3.13-1
ii  dnsmasq-base  2.71-1
ii  iptables  1.4.21-2
ii  modemmanager  1.2.0-1
ii  ppp   2.4.6-2

Versions of packages network-manager suggests:
ii  avahi-autoipd  0.6.31-4
pn  libteam-utils  none

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[logging]


-- no debconf information
diff -Nru network-manager-0.9.10.0/debian/changelog network-manager-0.9.10.0/debian/changelog
--- network-manager-0.9.10.0/debian/changelog	2014-07-10 00:49:54.0 -0400
+++ network-manager-0.9.10.0/debian/changelog	2014-08-11 12:37:33.0 -0400
@@ -1,3 +1,11 @@
+network-manager (0.9.10.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Pull patch from upstream to fix checks for default
+routes
+
+ -- Micah Anderson mi...@debian.org  Mon, 11 Aug 2014 12:08:31 -0400
+
 network-manager (0.9.10.0-2) unstable; urgency=medium
 
   * New upstream release.
diff -Nru network-manager-0.9.10.0/debian/patches/0006-Fix-checks-for-default-routes network-manager-0.9.10.0/debian/patches/0006-Fix-checks-for-default-routes
--- network-manager-0.9.10.0/debian/patches/0006-Fix-checks-for-default-routes	1969-12-31 19:00:00.0 -0500
+++ network-manager-0.9.10.0/debian/patches/0006-Fix-checks-for-default-routes	2014-08-11 12:37:08.0 -0400
@@ -0,0 +1,83 @@
+Index: network-manager-0.9.10.0/src/nm-ip4-config.c
+===
+--- network-manager-0.9.10.0.orig/src/nm-ip4-config.c	2014-07-03 20:44:19.0 -0400
 network-manager-0.9.10.0/src/nm-ip4-config.c	2014-07-29 19:42:06.965378158 -0400
+@@ -198,7 +198,7 @@
+ 	for (i = 0; i  priv-routes-len; i++) {
+ 		const NMPlatformIP4Route *route = g_array_index (priv-routes, NMPlatformIP4Route, i);
+ 
+-		if (route-network == 0) {
++		if (NM_PLATFORM_IP_ROUTE_IS_DEFAULT (route)) {
+ 			if (route-metric

Bug#759402: RM: pyopenssl -- ANAIS; Arch: any to Arch:all transition failure

[Micah Anderson]

Package: ftp.debian.org
Severity: normal

The pyopenssl package was switched from Arch:any to Arch:all, and the 
auto-decrufting process did not work, as a result it is not installable and has 
not been for over a week:

muck# apt-get install python-openssl
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package python-openssl is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'python-openssl' has no installation candidate
muck# 

Nothing should depend on the arch qualified package.

I spoke with paultag at debconf and he said that filing this bug was the thing 
to do to resolve this.

thanks!
micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754120: ITP: python-gnupg-ng -- A Python wrapper for GnuPG

[micah anderson]

intrigeri intrig...@debian.org writes:

 Hi,

 micah anderson wrote (14 Aug 2014 21:12:03 GMT) :
 Also - we have a package ready to upload for it.

 Where can I find this package?

It is available at:

deb http://deb.leap.se/debian sid main

as well as the git repository:

git clone https://leap.se/git/python_gnupg-ng.git


pgp_Xg6PwSjwS.pgp
Description: PGP signature

Bug#758319: bird: Please ship birdcl in package

[Micah Anderson]

Package: bird
Version: 1.4.4-1
Severity: wishlist
Tags: patch

Hello,

It seems that you are not shipping the birdcl binary in the package. The
attached patch would add that to the package.

I'm happy to upload this as a NMU to help you.

micah

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bird depends on:
ii  adduser   3.113+nmu3
ii  libc6 2.19-7
ii  libreadline6  6.3-8
ii  libtinfo5 5.9+20140712-2

bird recommends no packages.

Versions of packages bird suggests:
ii  bird-doc  1.4.4-1
diff --git a/debian/bird.install b/debian/bird.install
index 2088dfc..c5ed65d 100644
--- a/debian/bird.install
+++ b/debian/bird.install
@@ -1,6 +1,7 @@
 etc/bird/bird.conf
 usr/sbin/bird
 usr/sbin/birdc
+usr/sbin/birdcl
 etc/bird/bird6.conf
 usr/sbin/bird6
 usr/sbin/birdc6
diff --git a/debian/changelog b/debian/changelog
index f8b69d0..42e8750 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+bird (1.4.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install birdcl
+
+ -- Micah Anderson mi...@debian.org  Sat, 16 Aug 2014 15:45:29 -0400
+
 bird (1.4.4-1) unstable; urgency=medium
 
   * New upstream version 1.4.4

Bug#758318: FTBFS: missing build-depends: sp

[Micah Anderson]

Package: bird
Version: 1.4.4-1
Severity: serious
Tags: patch
Justification: Fails to build from source

Hello,

The bird package currently fails to build from source because during the pdf
generation phase it cannot find /usr/bin/nsgmls. Simply adding the 'sp' package
to the build-depends makes it work again. The attached patch shows this. I'm
happy to upload this as a NMU if it would help you.

make[2]: Entering directory '/home/micah/debian/bird-1.4.4/doc'
/home/micah/debian/bird-1.4.4/tools/progdoc /home/micah/debian/bird-1.4.4
/Doc
/doc/Doc
prog-intro.sgml
/nest/Doc
rt-fib.c
rt-table.c
Warning(551): Function parameter 'before_old' not described in 'rte_announce'
Warning(1446): Function parameter 'tab' not described in 'rt_prune_table'
rt-attr.c
proto.sgml
proto.c
Warning(731): Function parameter 'UNUSED' not described in 
'graceful_restart_done'
proto-hooks.c
Warning(161): Function parameter 'buflen' not described in 'get_attr'
iface.c
neighbor.c
Warning(352): Function parameter 'a' not described in 'neigh_ifa_update'
cli.c
locks.c
/conf/Doc
conf.c
cf-lex.l
Warning(561): Function parameter 'c' not described in 'cf_lex_init'
/filter/Doc
filter.c
tree.c
trie.c
Warning(84): Function parameter 'lp' not described in 'f_new_trie'
/proto/Doc
/proto/bfd/Doc
bfd.c
/proto/bgp/Doc
bgp.c
Warning(729): Function parameter 'UNUSED' not described in 
'bgp_incoming_connection'
packets.c
attrs.c
/proto/ospf/Doc
ospf.c
topology.c
Warning(1610): Function parameter 'pool' not described in 'ospf_top_new'
neighbor.c
iface.c
packet.c
lsalib.c
dbdes.c
rt.c
/proto/pipe/Doc
pipe.c
/proto/rip/Doc
rip.c
auth.c
/proto/radv/Doc
radv.c
packets.c
/proto/static/Doc
static.c
../nest/rt-dev.c
/sysdep/Doc
sysdep.sgml
/sysdep/unix/Doc
log.c
Warning(106): Function parameter 'buf' not described in 'log_commit'
krt.c
/lib/Doc
ip.c ipv4.c ipv6.c
lists.c
checksum.c bitops.c patmatch.c printf.c xmalloc.c
resource.sgml
resource.c
mempool.c
slab.c
event.c
../sysdep/unix/io.c
Warning(454): Function parameter 'fmt_spec' not described in 
'tm_format_datetime'
./sgml2html prog.sgml
Processing file prog.sgml
sh: 1: /usr/bin/nsgmls: not found
./sgml2latex --output=tex prog.sgml
Processing file prog.sgml
sh: 1: /usr/bin/nsgmls: not found
pdflatex prog.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
! I can't find file `prog.tex'.
* prog.tex

(Press Enter to retry, or Control-D to exit)
Please type another input file name: 

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bird depends on:
ii  adduser   3.113+nmu3
ii  libc6 2.19-7
ii  libreadline6  6.3-8
ii  libtinfo5 5.9+20140712-2

bird recommends no packages.

Versions of packages bird suggests:
ii  bird-doc  1.4.4-1
diff --git a/debian/changelog b/debian/changelog
index f8b69d0..0f662e4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+bird (1.4.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add sp package to Build-depends to provide missing /usr/bin/nsgmls
+fixing FTBFS 
+
+ -- Micah Anderson mi...@debian.org  Sat, 16 Aug 2014 15:45:29 -0400
+
 bird (1.4.4-1) unstable; urgency=medium
 
   * New upstream version 1.4.4
diff --git a/debian/control b/debian/control
index 5d10ec6..27c3bd8 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends: quilt,
 	   autotools-dev,
 	   xsltproc,
 	   docbook-xsl,
-	   linuxdoc-tools-latex
+	   linuxdoc-tools-latex, sp
 Maintainer: Ondřej Surý ond...@debian.org
 Standards-Version: 3.9.5
 Vcs-Browser: http://git.debian.org/?p=users/ondrej/bird.git

Bug#754120: ITP: python-gnupg-ng -- A Python wrapper for GnuPG

[micah anderson]

 Why exactly should shell=True be necessary?

It turns out that shell=True (basically what started the fork) is not
needed now. Vinay changed it in the latest release of the original
python gnupg, which came after a bunch of CVEs and some comments in this
thread as a result of python-gnupg-ng:
http://seclists.org/oss-sec/2014/q1/303

The original reason for doing shell=True is/was commented on
python-gnupg (original) code: without that, it didn't work in windows.

So while it is true that Shell=True is not needed, python-gnupg-ng has
other advantages: its more community based (it has a bugtracker and
public repo, to begin with), the code has diverged from the original a
bit in adding various gnupg functionality to the module, re-reading of
the original having security and documentation in minde and improving
the overall code quality. 

I'd argue that including this in Debian is a win because this one has:

 * Better gnupg options parsing
 * Better code structure.
 * Better documentation.
 * Open repo and bugtracker.

Also - we have a package ready to upload for it.


pgp61lMNubroM.pgp
Description: PGP signature

Bug#701962: Upload of libsodium

[micah anderson]

Hello,

I am eager to have libsodium available in Debian.

From what I can tell, the last state is László asking Raúl:

 I've updated the packaging[2]. Will upload it with those changes if
you don't mind.

 https://github.com/gcsideal/libsodium/commits/master

Raúl, it seems like there is just needed an acknowledgment from you that
these changes are ok, and then the package would be uploaded to
Debian. I'd really like this to be available, so I wanted to check with
you about this.

thanks!
micah


pgpByJmwW4NHR.pgp
Description: PGP signature

Bug#755015: network-manager: diff for NMU version 0.9.10.0-1.1

[micah anderson]

Control: tags 755015 + patch
Control: tags 755015 + pending

Hello!

I've prepared an NMU for network-manager (versioned as 0.9.10.0-1.1) and
uploaded it to DELAYED/5-day. Please feel free to tell me if I
should delay it longer.

Thanks,
micah
diff -Nru network-manager-0.9.10.0/debian/changelog network-manager-0.9.10.0/debian/changelog
--- network-manager-0.9.10.0/debian/changelog	2014-07-10 00:49:54.0 -0400
+++ network-manager-0.9.10.0/debian/changelog	2014-08-11 12:37:33.0 -0400
@@ -1,3 +1,11 @@
+network-manager (0.9.10.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Pull patch from upstream to fix checks for default
+routes (Closes: #755015)
+
+ -- Micah Anderson mi...@debian.org  Mon, 11 Aug 2014 12:08:31 -0400
+
 network-manager (0.9.10.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru network-manager-0.9.10.0/debian/patches/0006-Fix-checks-for-default-routes network-manager-0.9.10.0/debian/patches/0006-Fix-checks-for-default-routes
--- network-manager-0.9.10.0/debian/patches/0006-Fix-checks-for-default-routes	1969-12-31 19:00:00.0 -0500
+++ network-manager-0.9.10.0/debian/patches/0006-Fix-checks-for-default-routes	2014-08-11 12:37:08.0 -0400
@@ -0,0 +1,83 @@
+Index: network-manager-0.9.10.0/src/nm-ip4-config.c
+===
+--- network-manager-0.9.10.0.orig/src/nm-ip4-config.c	2014-07-03 20:44:19.0 -0400
 network-manager-0.9.10.0/src/nm-ip4-config.c	2014-07-29 19:42:06.965378158 -0400
+@@ -198,7 +198,7 @@
+ 	for (i = 0; i  priv-routes-len; i++) {
+ 		const NMPlatformIP4Route *route = g_array_index (priv-routes, NMPlatformIP4Route, i);
+ 
+-		if (route-network == 0) {
++		if (NM_PLATFORM_IP_ROUTE_IS_DEFAULT (route)) {
+ 			if (route-metric  lowest_metric) {
+ priv-gateway = route-gateway;
+ lowest_metric = route-metric;
+@@ -276,7 +276,8 @@
+ 			/* Don't add the default route if the connection
+ 			 * is never supposed to be the default connection.
+ 			 */
+-			if (nm_ip4_config_get_never_default (config)  route.network == 0)
++			if (   nm_ip4_config_get_never_default (config)
++			 NM_PLATFORM_IP_ROUTE_IS_DEFAULT (route))
+ continue;
+ 
+ 			g_array_append_val (routes, route);
+Index: network-manager-0.9.10.0/src/nm-ip6-config.c
+===
+--- network-manager-0.9.10.0.orig/src/nm-ip6-config.c	2014-07-03 20:44:19.0 -0400
 network-manager-0.9.10.0/src/nm-ip6-config.c	2014-07-29 19:42:06.965378158 -0400
+@@ -308,7 +308,7 @@
+ 	for (i = 0; i  priv-routes-len; i++) {
+ 		const NMPlatformIP6Route *route = g_array_index (priv-routes, NMPlatformIP6Route, i);
+ 
+-		if (IN6_IS_ADDR_UNSPECIFIED (route-network)) {
++		if (NM_PLATFORM_IP_ROUTE_IS_DEFAULT (route)) {
+ 			if (route-metric  lowest_metric) {
+ priv-gateway = route-gateway;
+ lowest_metric = route-metric;
+@@ -387,7 +387,8 @@
+ 			/* Don't add the default route if the connection
+ 			 * is never supposed to be the default connection.
+ 			 */
+-			if (nm_ip6_config_get_never_default (config)  IN6_IS_ADDR_UNSPECIFIED (route.network))
++			if (   nm_ip6_config_get_never_default (config)
++			 NM_PLATFORM_IP_ROUTE_IS_DEFAULT (route))
+ continue;
+ 
+ 			g_array_append_val (routes, route);
+Index: network-manager-0.9.10.0/src/platform/nm-linux-platform.c
+===
+--- network-manager-0.9.10.0.orig/src/platform/nm-linux-platform.c	2014-07-03 20:44:19.0 -0400
 network-manager-0.9.10.0/src/platform/nm-linux-platform.c	2014-07-29 19:42:06.969378050 -0400
+@@ -3520,7 +3520,7 @@
+ 	for (object = nl_cache_get_first (priv-route_cache); object; object = nl_cache_get_next (object)) {
+ 		if (_route_match ((struct rtnl_route *) object, AF_INET, ifindex)) {
+ 			if (init_ip4_route (route, (struct rtnl_route *) object)) {
+-if (route.plen != 0 || include_default)
++if (!NM_PLATFORM_IP_ROUTE_IS_DEFAULT (route) || include_default)
+ 	g_array_append_val (routes, route);
+ 			}
+ 		}
+@@ -3542,7 +3542,7 @@
+ 	for (object = nl_cache_get_first (priv-route_cache); object; object = nl_cache_get_next (object)) {
+ 		if (_route_match ((struct rtnl_route *) object, AF_INET6, ifindex)) {
+ 			if (init_ip6_route (route, (struct rtnl_route *) object)) {
+-if (route.plen != 0 || include_default)
++if (!NM_PLATFORM_IP_ROUTE_IS_DEFAULT (route) || include_default)
+ 	g_array_append_val (routes, route);
+ 			}
+ 		}
+Index: network-manager-0.9.10.0/src/platform/nm-platform.h
+===
+--- network-manager-0.9.10.0.orig/src/platform/nm-platform.h	2014-07-03 20:44:13.0 -0400
 network-manager-0.9.10.0/src/platform/nm-platform.h	2014-07-29 19:41:45.549955242 -0400
+@@ -248,6 +248,10 @@
+ 	};
+ } NMPlatformIPRoute;
+ 
++#define NM_PLATFORM_IP_ROUTE_IS_DEFAULT(route

Bug#701962: Upload of libsodium

[micah anderson]

micah anderson mi...@debian.org writes:

I just tried to build this and I had to remove two symbols from the
libsodium10.symbols file to get it to build, on 386.

   - _crypto_stream_salsa20@Base 0.6.0
   - _crypto_stream_salsa20_xor_ic@Base 0.6.0
   +#MISSING: 0.6.1-1# _crypto_stream_salsa20@Base 0.6.0
   +#MISSING: 0.6.1-1# _crypto_stream_salsa20_xor_ic@Base 0.6.0


18:31:17 dpkg-gensymbols: warning: some symbols or patterns disappeared in the 
symbols file: see diff output below
18:31:17 dpkg-gensymbols: warning: debian/libsodium10/DEBIAN/symbols doesn't 
match completely debian/libsodium10.symbols
18:31:17 --- debian/libsodium10.symbols 
(libsodium10_0.6.1-1+0~20140811181730.5+jessie~1.gbpb11145_i386)
18:31:17 +++ dpkg-gensymbols4cPxAS  2014-08-11 18:31:17.0 +
18:31:17 @@ -1,6 +1,6 @@
18:31:17  libsodium.so.10 libsodium10 #MINVER#
18:31:17 - _crypto_stream_salsa20@Base 0.6.0
18:31:17 - _crypto_stream_salsa20_xor_ic@Base 0.6.0
18:31:17 +#MISSING: 0.6.1-1+0~20140811181730.5+jessie~1.gbpb11145# 
_crypto_stream_salsa20@Base 0.6.0
18:31:17 +#MISSING: 0.6.1-1+0~20140811181730.5+jessie~1.gbpb11145# 
_crypto_stream_salsa20_xor_ic@Base 0.6.0
18:31:17   crypto_aead_chacha20poly1305_abytes@Base 0.6.0
18:31:17   crypto_aead_chacha20poly1305_decrypt@Base 0.6.0
18:31:17   crypto_aead_chacha20poly1305_encrypt@Base 0.6.0
18:31:17 dh_makeshlibs: failing due to earlier errors
18:31:17 debian/rules:8: recipe for target 'binary-arch' failed
18:31:17 make: *** [binary-arch] Error 2
18:31:17 dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error 
exit status 2
18:31:17 E: Failed autobuilding of package


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755015: Fix for this issue

[micah anderson]

Hi,

I'm having a similar issue. If I use openvpn externally, it will push a
default route, but network-manager immediately removes that route. This
is new behavior in 0.9.10, in fact I confirmed that by trying the
previous version by pulling packages from snapshots, previous versions
did not have this problem.

I spent quite a bit of time debugging this issue with upstream NM people
on their IRC channel, in the end they came up with a patch that was
committed upstream (in git it is: the following hash: 
06703c1670d0f96834b268920b09792e22fdb4c4)

I tested this change, and it worked well for me. 

Considering that this effectively breaks all OpenVPN setups that are not
using network-manager's built-in VPN mechanisms, I would really like to
get this change into Debian without having to wait for the next major
release of NM. If you are planning on doing an upload in the near
future, could you cherry-pick this change? If you aren't planning on
doing one any time soon, would you mind if I NMU with this change?

thanks for maintaining network manager!
micah



pgpqEfCTvX8Ce.pgp
Description: PGP signature

Bug#756004: Not sure if this will fix it

[micah anderson]

Hello,

I ran into this issue when I upgraded to the backport version. I found
http://www.redmine.org/issues/16710 which detailed the issue and the
fixes. 

I tried to pull in the changes that were mentioned in that issue to
the ruby-mime-types that I have installed on wheezy, but found the code
was too old. I was looking at backporting it, when I noticed that the
issue links to a redmine change:

http://www.redmine.org/projects/redmine/repository/revisions/13107

this changes is to the redmine provided lib/redmine/mime_type.rb file (a
simple change). When I made that change, things worked again. I'm not
sure if the new ruby-mime-types is going to fix this issue if redmine is
using its own version there.

Might be worthwhile to cherry-pick this change?

micah


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752420: couchdb: Please upgrade to 1.6.0

[Micah Anderson]

Package: couchdb
Version: 1.4.0-3
Severity: wishlist

Hello,

It would be nice if we could have the most recent version of couchdb
available. I've imported the 1.6.0 upstream code and built a package from it, it
was quite easy to do!

If you like, I can upload this package for you.

micah


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749611: apt-transport-tor: Leaks locale information

[Micah Anderson]

Micah Anderson mi...@debian.org writes:

 The way to do this is to have the package install a
 /etc/apt/apt.conf.d/90languages with the following:

 Acquire::Languages { ca; cs; da; de; el; en; eo; es; eu; 
 fi; fr; hr; hu; id; it; ja; km; ko; ml; nb; nl; pl; 
 pt; ro; ru; sk; sr; sv; tr; uk; vi; zh; };

Actually, if you do this then what happens is:

1. you request all these languages in this order
2. depending on what translations are available, apt is going to show
you these languages in this preference order. For example, in apt-cache
search, or apt-cache show... so if some package has been danish
localized, and you speak english, you will get the danish ones first.

You can of course set your preferred language to be first in this list,
but then you will be requesting that first, which still betrays your
language preference.

I'm guessing a better fix would be that this transport fetches all
possible languages in a random order, dumps them all to /dev/null except
your locale


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749789: reprepro: signhook documentation truncated

[Micah Anderson]

Package: reprepro
Version: 4.14.0-1
Severity: minor

Hello,

I found the signhook implementation (from #469656) and am interested in using
that for offline signing. However, the manual.html seems to be truncated in the
description, it simply reads:

The script gets three arguments: The filename to sign, the filename of the
InRelease file to create and the filename of the Release.gpg to create (a
Release.gpg does not need to be created. reprepro will assume you do not care
about that legacy file if it

and it ends right there at that 'if it'...

I'm not exactly sure I understand how I would use a script to do offline
signing, but I am eager to know how!

thanks!
micah


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749611: apt-transport-tor: Leaks locale information

[Micah Anderson]

Package: apt-transport-tor
Version: 0.1.1-1
Severity: important

Hello,

Thanks for making apt-transport-tor, I was doing this via torsocks, but it was
sub-optimal. This is much better!

The only problem is that when you do an apt-get update, you are leaking some
important identifying bits, namely your locale preferences through the requested
Translations-* files. This is pretty interesting, and revealing information! For
example, if someone is requesting the Translation-zh files, you can pretty
reasonably guess that they are Chinese speaking. Fortunately, the specific
locality is not leaked (eg. en_US).

Because people do want their localized languages available to them, but
requesting them over tor betrays information, I think that the only way to get
around this problem is to request all the locales. Its somewhat annoying because
it slows down the apt-get update process a little bit, and you download more
data than you need, but then you do have your proper language locale, without
leaking which one you are using.

The way to do this is to have the package install a
/etc/apt/apt.conf.d/90languages with the following:

Acquire::Languages { ca; cs; da; de; el; en; eo; es; eu; 
fi; fr; hr; hu; id; it; ja; km; ko; ml; nb; nl; pl; 
pt; ro; ru; sk; sr; sv; tr; uk; vi; zh; };

Micah

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt-transport-tor depends on:
ii  libapt-pkg4.12   1.0.3
ii  libc62.18-7
ii  libcurl3-gnutls  7.37.0-1
ii  libgcc1  1:4.9.0-4
ii  libstdc++6   4.9.0-4
ii  tor  0.2.4.22-1

apt-transport-tor recommends no packages.

apt-transport-tor suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745735: apt: Provide meaningful exit codes for gpg failures

[Micah Anderson]

Package: apt
Version: 1.0.1
Severity: normal

Hello,

It seems like from reading the code that the gpg signature verification process 
doesn't
provide meaningful exit codes when bad things happen. This results in apt-get 
update
providing an exit code of zero, even if there was a BADSIG. It would be very 
useful
if we could get an exit code when these bad situations happen:

BADSIG
NO_PUBKEY
KEYEXPIRED
REVKEYSIG
NODATA

Thank you,
micah

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt depends on:
ii  debian-archive-keyring  2012.4
ii  gnupg   1.4.16-1.1
ii  libapt-pkg4.12  1.0.1
ii  libc6   2.18-4
ii  libgcc1 1:4.9-20140411-2
ii  libstdc++6  4.9-20140411-2

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc none
ii  aptitude0.6.10-1
ii  dpkg-dev1.17.7
ii  python-apt  0.9.3.5

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741690: redmine: ActionView::Template::Error (no suitable markdown gem found):

[Micah Anderson]

Source: redmine
Version: 2.4.2-1
Severity: normal

Hello,

It seems that in certain circumstances that I have not been able to adequitely
determine, Redmine gives a 500 Internal Server error, and the following in the
logs when viewing the repository:

ActionView::Template::Error (no suitable markdown gem found):
1: %= call_hook(:view_repositories_show_contextual, { :repository = 
@repository, :project = @project }) %
2: 
3: div class=contextual
4:   %= render :partial = 'navigation' %
  lib/redmine/hook.rb:61:in `block (2 levels) in call_hook'
  lib/redmine/hook.rb:61:in `each'
  lib/redmine/hook.rb:61:in `block in call_hook'
  lib/redmine/hook.rb:58:in `tap'
  lib/redmine/hook.rb:58:in `call_hook'
  lib/redmine/hook.rb:158:in `call_hook'
  app/controllers/repositories_controller.rb:125:in `show'

it seems that this is solved by installing the ruby-redcarpet package, so I
guess that should be a Depends for this package.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739981: [PATCH 2/4] add LXC devices to debian/securetty.linux

[Micah Anderson]

---
 debian/securetty.linux | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/securetty.linux b/debian/securetty.linux
index 9be98b0..623ebf0 100644
--- a/debian/securetty.linux
+++ b/debian/securetty.linux
@@ -385,6 +385,13 @@ ttymxc3
 ttymxc4
 ttymxc5
 
+# LXC (Linux Containers)
+lxc/console
+lxc/tty1
+lxc/tty2
+lxc/tty3
+lxc/tty4
+
 # Serial Console for MIPS Swarm
 duart0
 duart1
-- 
1.9.0


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739981: [PATCH 4/4] login.postinst: install a default /etc/subuid and /etc/subgid

[Micah Anderson]

---
 debian/changelog  |  1 +
 debian/login.postinst | 13 +
 2 files changed, 14 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index ebf1e9c..cb9f338 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -39,6 +39,7 @@ shadow (1:4.2-1) UNRELEASED; urgency=low
   * Allow LXC devices (lxc/console, lxc/tty[1234]) in securetty.linux
   * Update documentation of UMASK: Explain that USERGROUPS_ENAB will modify
 this default for UPGs. (Closes: #583971)
+  * login.postinst: install a default /etc/subuid and /etc/subgid
 
  -- Christian Perrier bubu...@debian.org  Sat, 27 Jul 2013 20:07:18 +0200
 
diff --git a/debian/login.postinst b/debian/login.postinst
index 59d6b7f..39aa57c 100644
--- a/debian/login.postinst
+++ b/debian/login.postinst
@@ -24,6 +24,19 @@ then
fi
 fi
 
+# Create subuid/subgid if missing
+if [ ! -e /etc/subuid ]; then
+touch /etc/subuid
+chown root:root /etc/subuid
+chmod 644 /etc/subuid
+fi
+
+if [ ! -e /etc/subgid ]; then
+touch /etc/subgid
+chown root:root /etc/subgid
+chmod 644 /etc/subgid
+fi
+
 #DEBHELPER#
 
 exit 0
-- 
1.9.0


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739981: [PATCH 3/4] Update documentation of UMASK: Explain that USERGROUPS_ENAB will modify this default for UPGs. (Closes: #583971)

[Micah Anderson]

---
 debian/changelog  | 3 +++
 debian/login.defs | 5 +
 2 files changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 79cdfc3..ebf1e9c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -36,6 +36,9 @@ shadow (1:4.2-1) UNRELEASED; urgency=low
   * added debian/patches/userns to enable use of subuids, plus some bugfix 
 patches on top of them, patches from Eric Biederman, pulled from
 Ubuntu. Closes: #739981
+  * Allow LXC devices (lxc/console, lxc/tty[1234]) in securetty.linux
+  * Update documentation of UMASK: Explain that USERGROUPS_ENAB will modify
+this default for UPGs. (Closes: #583971)
 
  -- Christian Perrier bubu...@debian.org  Sat, 27 Jul 2013 20:07:18 +0200
 
diff --git a/debian/login.defs b/debian/login.defs
index 968c657..aeb8585 100644
--- a/debian/login.defs
+++ b/debian/login.defs
@@ -139,6 +139,11 @@ TTYPERM0600
 # There is no One True Answer here : each sysadmin must make up his/her
 # mind.
 #
+# If USERGROUPS_ENAB is set to yes, that will modify this UMASK default value
+# for private user groups, i. e. the uid is the same as gid, and username is
+# the same as the primary group name: for these, the user permissions will be
+# used as group permissions, e. g. 022 will become 002.
+#
 # Prefix these values with 0 to get octal, 0x to get hexadecimal.
 #
 ERASECHAR  0177
-- 
1.9.0


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739981: passwd: Please upload version with subuid/subgid support

[Micah Anderson]

Package: passwd
Version: 1:4.1.5.1-1
Severity: wishlist

Hello!

In order to have unprivileged lxc containers in debian, we need to
have a version of shadow uploaded that has subuid/subgid support. I
spoke with stgraber on irc about this and he indicated that the patches are 
already in on alioth, but it hasn't been uploaded yet. I'm curious what is 
needed to get that to happen?

If there are concerns about uploading to sid - perhaps an experimental package 
for a little bit?

thanks, you are awesome!
micah


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages passwd depends on:
ii  debianutils 4.4
ii  libc6   2.18-1
ii  libpam-modules  1.1.8-2
ii  libpam0g1.1.8-2
ii  libselinux1 2.2.2-1
ii  libsemanage12.2-1

passwd recommends no packages.

passwd suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org