Bug#1002487: python3-buildstream should depend on gir1.2-ostree-1.0

[Carlos Alberto Lopez Perez]

Package: python3-buildstream
Version: 1.4.3-0.1


Installing python3-buildstream on Debian 11 (bullseye) on a new container
leads to the software not beeing usable due to a missing package dependency

Steps to reproduce:

1. Install on an empty debian system the packages python3-buildstream 
python3-gi python3 buildstream ostree

2. Try to run

  $ python3 -c 'from gi.repository import OSTree'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/gi/importer.py", line 131, in 
load_module
raise ImportError('cannot import name %s, '
ImportError: cannot import name OSTree, introspection typelib not found


I fixed the issue by manually installing the package gir1.2-ostree-1.0,
but I think this should be automatically installed via the apt deps.

Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation

[Carlos Alberto Lopez Perez]

On 11/06/2020 18:34, Michael Borg wrote:
> Yep I know but I cannot tell all my customers to run this workaround, some
> of our users are not experienced at all The only thing I see here is
> that I need to provide a hotfix ourselves. We cannot wait for days... You
> are saying we cannot make an exception and push this fix ASAP?

Pushing packages to Debian takes time. If you need something for today you need 
to fix it yourself.

You can downgrade to the old version of the package ca-certificates or install 
the missed certificate manually

This recipe allows to do that:

wget --no-check-certificate -c 
https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem
   \
&& mkdir /usr/local/share/ca-certificates/extra 
  \
&& mv GeoTrust_Global_CA.pem 
/usr/local/share/ca-certificates/extra/GeoTrust_Global_CA.crt   
 \
&& update-ca-certificates

And when you upgrade to the fixed version of ca-certificates you can remove the 
directory /usr/local/share/ca-certificates/extra 
and run the command update-ca-certificates again.



signature.asc
Description: OpenPGP digital signature

Bug#962596: ca-certificates: Removal of GeoTrust Global CA requires investigation

[Carlos Alberto Lopez Perez]

On 10/06/2020 16:51, Philippe Normand wrote:
> Package: ca-certificates
> Version: 20200601
> Severity: normal
> 
> Dear Maintainer,
> 
> Since the update of ca-certificates to version 20200601 I can no longer access
> webkit.org websites.
> 


The removed CA (GeoTrust Global CA) is used to sign the Apple
intermediate certificate "Apple IST CA 2 - G1".

Firefox and Chrome have some sort of hack (likely a whitelist)
specifically to trust this Apple's intermediate CAs:
https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

So the website still works in Firefox and Chrome on Debian, even with
GeoTrust removed. But it doesn't work with GnuTLS (or the Epiphany web
browser).



signature.asc
Description: OpenPGP digital signature

Bug#927731: epiphany-browser/i386: private libdazzle not loaded

[Carlos Alberto Lopez Perez]

On 28/08/2019 11:44, Simon McVittie wrote:
> On Wed, 28 Aug 2019 at 08:29:20 +0100, Simon McVittie wrote:
>> I'm not sure why the RPATH/RUNPATH isn't being set, because ephymain
>> and ephywebprocessextension both have "install_rpath: pkglibdir" in
>> their respective meson.build files, but for some reason only the one
>> for ephymain seems to "stick"?
> 
> ephywebprocessextension does seem to get a correct RUNPATH, so it
> isn't that.
> 
> The only binary that links to libdazzle but doesn't have a RUNPATH seems
> to be libephymisc.so (libephysync.so also doesn't have a RUNPATH, but
> it doesn't link directly to libdazzle either). I wonder whether one of
> those could be the problem? If you can reproduce this but you can't tell
> me how I can, please try an epiphany-browser built with this patch:
> 

To reproduce it, first remove the Debian package libdazzle-1.0-0 if
you have it installed

And then you can use any of this two options
1) Checking that the ugly warning about missing libdazzle doesn't appear when
starting epiphany from a shell 
2) Try to use Epiphany password manager to log into a previous site with saved
credentials (like bugzilla). If epiphany is able to automatically fill the saved
password then its working.


I tested the first patch (the one quoted below) and it fixed the issue for me.

> =
> diff --git a/lib/meson.build b/lib/meson.build
> index be5af33ef..0eb47570e 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -87,7 +87,8 @@ libephymisc = shared_library('ephymisc',
>dependencies: libephymisc_deps,
>include_directories: libephymisc_includes,
>install: true,
> -  install_dir: pkglibdir
> +  install_dir: pkglibdir,
> +  install_rpath: pkglibdir
>  )
>  
>  ephymisc_dep = declare_dependency(
> =
> 


After the above patch it seems to be working as expected (without having to 
install
Debian package libdazzle-1.0-0) and I can see how now it links with the right
library.

$ ldd 
/usr/lib/x86_64-linux-gnu/epiphany-browser/web-extensions/libephywebextension.so|grep
 -i dazz
libdazzle-1.0.so.0 => 
/usr/lib/x86_64-linux-gnu/epiphany-browser/libdazzle-1.0.so.0 
(0x7fd0f99d4000)



Thanks!



signature.asc
Description: OpenPGP digital signature

Bug#927731: epiphany-browser/i386: private libdazzle not loaded

[Carlos Alberto Lopez Perez]

On 28/08/2019 03:07, Carlos Alberto Lopez Perez wrote:
> I can confirm this bug in last Debian sid (also in stable) and on AMD64.
> 
> if you simply do "apt install epiphany-browser" libdazzle-1.0-0 is not
> installed.
> 
> The problem is not only the ugly warning on stderr, but that you miss
> the new nice search bar at all. You can read about this here:
> 
> https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/
> 
> Installing libdazzle-1.0-0 fixes the problem and makes the new nice
> address bar work.
> 
> You can check this yourself by installing/removing libdazzle-1.0-0 and
> reopening epiphany and seeing the different address bar.
> 
> Please, declare a dependency on libdazzle for the epiphany-browser.

Sorry, seem i tested too fast here.

What is broke is not the new search bar, but the libephywebextension.so
which is unrelated with the search bar.

This extension is injected into the WebProcess and is used for things
like remembering passwords on sites (the typical login form)


Also you can check how libephywebextension.so only loads into the
WebKitWebProcess pid map if it can resolve the linker reference to
libdazzle.

It seems that in the linking process this .so library got linked with
the system libdazzle by mistake.


So the fix is either to declare a dependecy on the system libdazzle or
rebuild this library declaring a build-conflicts with the system
libdazzle to avoid this .so linking with it (instead the package embeded
copy of libdazzle)

$ ldd 
/usr/lib/x86_64-linux-gnu/epiphany-browser/web-extensions/libephywebextension.so|grep
 -i dazz
libdazzle-1.0.so.0 => not found


$ apt-cache policy epiphany-browser
epiphany-browser:
  Installed: 3.32.1.2-2
  Candidate: 3.32.1.2-2
  Version table:
 *** 3.32.1.2-2 990
990 http://httpredir.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status




signature.asc
Description: OpenPGP digital signature

Bug#927731: epiphany-browser/i386: private libdazzle not loaded

[Carlos Alberto Lopez Perez]

On 28/04/2019 01:01, Simon McVittie wrote:
> Control: tags -1 + moreinfo
> 
> On Tue, 23 Apr 2019 at 02:46:53 +0800, 積丹尼 Dan Jacobson wrote:
>> SM> Does this perhaps depend on settings or something? If you create a new
>> SM> temporary user account, log in as the new user and run epiphany-browser,
>> SM> do you get the same warnings?
>>
>> Same on AMD64:
>>
>> $ su - some_vanilla_acct
>> $ DISPLAY=:0 epiphany
> ...
>> Error loading module 
>> '/usr/lib/x86_64-linux-gnu/epiphany-browser/web-extensions/libephywebextension.so':
>>  libdazzle-1.0.so.0: cannot open shared object file: No such file or 
>> directory
> 
> I haven't been able to reproduce this, but libephywebextension.so also
> doesn't appear in epiphany's /proc/$pid/maps for me.
> 


It doesn't appear inside the epiphany's pid map because
libephywebextension.so is a WebKitGTK WebProcess extension and not an
epiphany/UIProcess plugin.

It get's loaded in the WebKitWebProcess pid that epiphany executes.

And it only gets loaded if the linker is able to resolve all the symbols
(including libdazzle-1.0.so.0), otherwise the WebProcess skips loading it.

> Was some_vanilla_acct an entirely new user account with no prior
> configuration?
> 
> Do you have some sort of configuration, perhaps system-wide, that might
> cause epiphany-browser to load web extensions, where it doesn't for me?
> 
> Is there any feature that is observably not working as a result of
> libephywebextension.so not loading, or is the warning message the only
> symptom that you see?
> 

I can confirm this bug in last Debian sid (also in stable) and on AMD64.

if you simply do "apt install epiphany-browser" libdazzle-1.0-0 is not
installed.

The problem is not only the ugly warning on stderr, but that you miss
the new nice search bar at all. You can read about this here:

https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/

Installing libdazzle-1.0-0 fixes the problem and makes the new nice
address bar work.

You can check this yourself by installing/removing libdazzle-1.0-0 and
reopening epiphany and seeing the different address bar.

Please, declare a dependency on libdazzle for the epiphany-browser.

Thanks



signature.asc
Description: OpenPGP digital signature

Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another

[Carlos Alberto Lopez Perez]

On 15/07/2019 06:16, Nicholas D Steeves wrote:
> Package: wnpp
> Severity: wishlist
> 
> Package name: fuidshift
> Version : 3.0
> Upstream Author : Name 
> URL : https://github.com/lxc/lxd/tree/master/fuidshift
> License : Apache 2.0
> Programming Lang: Go
> Description : remap a filesystem tree to shift one set of UID/GID ranges 
> to another
> 
> Fuidshift is useful for converting privileged containers to
> unprivileged ones, and also to adapt a container master to multiple
> users' authorised subuid and subguid ranges.  It also sounds like it
> might be useful for fixing up cases where --numeric-owner should have
> been used, but where it would be too labour-intensive to manually chown.
> 
> I learned about this tool via the following document:
>   https://github.com/BenSartor/unprivileged-lxc-containers
> 
> Here is the upstream description:
> 
>   This tool lets you remap a filesystem tree, switching it from one
>   set of UID/GID ranges to another.
>   This is mostly useful when retrieving a wrongly shifted filesystem tree
>   from a backup or broken system and having to remap everything either to
>   the host UID/GID range (uid/gid 0 is root) or to an existing container's
>   range.
>   A range is represented as 
> :::.
>   Where "u" means shift uid, "g" means shift gid and "b" means shift uid and 
> gid.
> 
> https://github.com/lxc/lxd/blob/81b81b9ace3064c8065319f4e984378244587d80/fuidshift/main_shift.go#L26-L36
> 
> It's part of the LXD project, but I'm not sure if it's as difficult to
> package as LXD itself, which is one reason why I've CCed the Go team.
> I also wonder if the best way to get this into Debian would be a
> src:lxd that produces bin:fuidshift.
> 
> 

An alternative to this, written on C, is uidmapshift that can be found
at https://code.launchpad.net/~serge-hallyn/+junk/nsexec

Its packaged for Arch, see:

https://wiki.archlinux.org/index.php/Linux_Containers#Converting_a_privileged_container_to_an_unprivileged_container





signature.asc
Description: OpenPGP digital signature

Bug#908852: Debian Stretch can't be installed or booted on Apollo Lake systems.

[Carlos Alberto Lopez Perez]

Package: grub-efi-amd64
Version: 2.02~beta3-5
Severity: important
Tags: d-i patch


There is a bug in the version of Grub2 shipped in Debian stable that renders
grub unable to boot in Apollo Lake systems (this are usually recent netbooks
or ultrabooks with Celeron/Atom CPUs).

The issue is that the EFI binary generated by Grub2 from Stretch hangs this
systems completely.

See: https://medium.com/@pawitp/grub-2-issue-on-intel-n4200-97c12d4db8af

The fix is simply to backport this patch 
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=446794de8da4329ea532cbee4ca877bcafd0e534
(which applies cleanly over the grub version in Stretch).


I think it will be a good idea to release a new version of Grub2 for stable
with this patch and generate a new image of the debian installer.

Otherwise it is impossible (well, not impossible, but very difficult) to
install Debian Stretch on this systems.


Note that Debian testing is not affected, as this patch is already included
there. The fix is only necessary for Stretch.


I attach a debdiff of a backport I did myself. I have verified that Debian
Stretch boots fine on my Yepo 737A laptop (Apollo Lake) with this new version
of Grub2.
diff -Nru grub2-2.02~beta3/debian/changelog grub2-2.02~beta3/debian/changelog
--- grub2-2.02~beta3/debian/changelog	2017-02-11 16:09:19.0 +0100
+++ grub2-2.02~beta3/debian/changelog	2018-09-15 01:51:02.0 +0200
@@ -1,3 +1,10 @@
+grub2 (2.02~beta3-6) stable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix boot on Apollo Lake EFI systems.
+
+ -- Carlos Alberto Lopez Perez   Sat, 15 Sep 2018 01:51:02 +0200
+
 grub2 (2.02~beta3-5) unstable; urgency=medium
 
   [ Steve McIntyre ]
diff -Nru grub2-2.02~beta3/debian/patches/fix_boot_apollo_lake.patch grub2-2.02~beta3/debian/patches/fix_boot_apollo_lake.patch
--- grub2-2.02~beta3/debian/patches/fix_boot_apollo_lake.patch	1970-01-01 01:00:00.0 +0100
+++ grub2-2.02~beta3/debian/patches/fix_boot_apollo_lake.patch	2018-09-15 01:49:57.0 +0200
@@ -0,0 +1,31 @@
+From 446794de8da4329ea532cbee4ca877bcafd0e534 Mon Sep 17 00:00:00 2001
+From: "David E. Box" 
+Date: Fri, 15 Sep 2017 15:37:05 -0700
+Subject: tsc: Change default tsc calibration method to pmtimer on EFI systems
+
+On efi systems, make pmtimer based tsc calibration the default over the
+pit. This prevents Grub from hanging on Intel SoC systems that power gate
+the pit.
+
+Signed-off-by: David E. Box 
+Reviewed-by: Daniel Kiper 
+---
+ grub-core/kern/i386/tsc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grub-core/kern/i386/tsc.c b/grub-core/kern/i386/tsc.c
+index 2e85289..f266eb1 100644
+--- a/grub-core/kern/i386/tsc.c
 b/grub-core/kern/i386/tsc.c
+@@ -68,7 +68,7 @@ grub_tsc_init (void)
+ #ifdef GRUB_MACHINE_XEN
+   (void) (grub_tsc_calibrate_from_xen () || calibrate_tsc_hardcode());
+ #elif defined (GRUB_MACHINE_EFI)
+-  (void) (grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
++  (void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || grub_tsc_calibrate_from_efi() || calibrate_tsc_hardcode());
+ #elif defined (GRUB_MACHINE_COREBOOT)
+   (void) (grub_tsc_calibrate_from_pmtimer () || grub_tsc_calibrate_from_pit () || calibrate_tsc_hardcode());
+ #else
+-- 
+cgit v1.0-41-gc330
+
diff -Nru grub2-2.02~beta3/debian/patches/series grub2-2.02~beta3/debian/patches/series
--- grub2-2.02~beta3/debian/patches/series	2017-02-11 16:03:45.0 +0100
+++ grub2-2.02~beta3/debian/patches/series	2018-09-15 01:50:47.0 +0200
@@ -57,3 +57,4 @@
 efinet_set_network_from_uefi_devpath.patch
 efinet_set_dns_from_uefi_proto.patch
 grub-install-efibootmgr-check.patch
+fix_boot_apollo_lake.patch


signature.asc
Description: OpenPGP digital signature

Bug#863915: unblock: webkit2gtk/2.16.3-2

[Carlos Alberto Lopez Perez]

On 02/06/17 14:47, Carlos Alberto Lopez Perez wrote:
>> Also it'd be nice to know what kind of automated testing is happening. I know
>> WebKit has an extensive test suite (including layout tests) that upstream
>> continuously runs for development series. I don't know if that's the same for
>> stable series though. Also can we enable the test suite in Debian?
>>
> On trunk (master) we have a extensive test coverage per each commit.
> We even have a bot testing that WebKitGTK+ always remains build-able
> both on Debian stable and Ubuntu LTS. Check our bots here:
> http://build.webkit.org/waterfall?category=GTK
> 
> All those bots are running Debian 9, except for the 32-bit and ARM bot
> that are running Debian 8 but they will be eventually upgraded to Debian
> 9 also.
> 
> (Also except the Debian and Ubuntu bots that are of course running
> Debian 8 and Ubuntu 16.04)
> 
> For the stable branch (that is what you are interested about I guess) we
> have a bot running all those tests here:
> 
> https://build-webkit.igalia.com/waterfall?category=GTK
> 
> This bot running the tests on the stable branch is currently running
> Debian 8 as base distro.
> We are happy to upgrade it to Debian 9 if you wish (is something we will
> eventually do in any case).
> 
> Note that those 9 failures are not really meaningful.
> Current layout test suite of WebKit has 47556 tests
> 
> If there is some more testing we can do to accommodate your needs, we
> will be happy to help.
> 
> Regards.
> 
> 

One note more:

The results of the layout tests are highly dependent on very specific
versions of the libraries we depend on. For example, different versions
of GTK+ or Cairo produce different results (this are usually small pixel
differences on the render of the webview).

So what we do, is to have the expected results of those tests specially
created for very specific versions of those libraries that we build with
JHBuild and we use it for testing.

If you try to run the layout test suite without using our internal
JHBuild you are going to get thousands of tests failures due to this
(they are not real failures, but the tooling is unable to detect that as
it can't know if a 1-pixel difference is because of a real failure or
because your version of GTK+ draws arrows/boxes/etc in a sightly
different way than the one was used to produce the expected result)

So, I don't think is flexible for Debian to run our layout test suite
unless you are willing to maintain your own list of expected results.

There are however other tests that you can run that don't depend on the
version of the libraries used like the jscore-tests or the API tests.
However, the tarballs we release are trimmed to remove all those testing
stuff from them. You would have to use the SVN repository for that,
which complicates things.


However, we are happy to keep our bot that runs all those tests for the
stable branch on Debian.




signature.asc
Description: OpenPGP digital signature

Bug#863915: unblock: webkit2gtk/2.16.3-2

[Carlos Alberto Lopez Perez]

On 02/06/17 10:27, Emilio Pozuelo Monfort wrote:
> Hi Jeremy,
> 
> On 01/06/17 23:15, Jeremy Bicha wrote:
>> Please unblock package webkit2gtk for inclusion in Debian 9.0.
>>
>> unblock webkit2gtk/2.16.3-2
>>
>> Justification
>> --
>> Three known publicized security vulnerabilities have been fixed in
>> 2.16.3: CVE-2017-2496, CVE-2017-2539 and CVE-2017-2510. For more
>> details about these and other recent security fixes, see [1].
>>
>> webkit2gtk follows GNOME's Release Schedule (new major updates in
>> March and September with bugfix updates in between). The 2.14 series
>> is no longer supported and will not be updated to fix those or future
>> security vulnerabilities.
>>
>> Background Info
>> 
>> Sadly, Debian's security packaging infrastructure is not set up to
>> test this kind of update very well. To provide a reasonable balance
>> between security for Debian 9 users and API stability for apps, the
>> current proposal [2] is to use Debian's s-p-u procedures and get these
>> updates into Debian point releases. This is a huge improvement over
>> Debian 8 where webkitgtk got only one early update and webkit2gtk was
>> only updated through backports. [3] [4] [5]
>>
>> To summarize a bit of the discussion on debian-devel, Ubuntu 16.04 LTS
>> has been receiving new webkit2gtk versions within about a week of
>> their release. Although regressions are possible, these have been
>> averted so far because Ubuntu tests the new major beta releases in the
>> development release of Ubuntu and because regressions are quickly
>> pointed out by users of more bleeding-edge distros (and these
>> regressions are quickly fixed!)
> 
> Could you list all the known regressions that resulted from these updates in
> Ubuntu? I think that would be an interesting data point for this discussion, 
> so
> that we can assess not just the number of regressions, but the severity of 
> them
> and how/if they were fixed (e.g. if upstream cared about these in the cases 
> that
> were reported to them, etc). If you can provide bug#, severity, and a timeline
> (e.g. webkit update to -proposed, webkit update to $distro, date of regression
> reported, regression fixed) that'd be helpful.
> 
> Also it'd be nice to know what kind of automated testing is happening. I know
> WebKit has an extensive test suite (including layout tests) that upstream
> continuously runs for development series. I don't know if that's the same for
> stable series though. Also can we enable the test suite in Debian?
> 

On trunk (master) we have a extensive test coverage per each commit.
We even have a bot testing that WebKitGTK+ always remains build-able
both on Debian stable and Ubuntu LTS. Check our bots here:
http://build.webkit.org/waterfall?category=GTK

All those bots are running Debian 9, except for the 32-bit and ARM bot
that are running Debian 8 but they will be eventually upgraded to Debian
9 also.

(Also except the Debian and Ubuntu bots that are of course running
Debian 8 and Ubuntu 16.04)

For the stable branch (that is what you are interested about I guess) we
have a bot running all those tests here:

https://build-webkit.igalia.com/waterfall?category=GTK

This bot running the tests on the stable branch is currently running
Debian 8 as base distro.
We are happy to upgrade it to Debian 9 if you wish (is something we will
eventually do in any case).

Note that those 9 failures are not really meaningful.
Current layout test suite of WebKit has 47556 tests

If there is some more testing we can do to accommodate your needs, we
will be happy to help.

Regards.




signature.asc
Description: OpenPGP digital signature

Bug#863201: libpam-ldap not longer installs the file /usr/share/pam-configs/ldap needed for pam-auth-update

[Carlos Alberto Lopez Perez]

Package: libpam-ldap
Version: 186-3
Severity: grave


libpam-ldap 184-8.7 (Jessie) installed a config file on 
/usr/share/pam-configs/ldap
telling pam-auth-update how it should re-configure the files on /etc/pam.d when 
the
command pam-auth-update is executed (that the package libpam-ldap executes on 
the
postinstall)

libpam-ldap 186-3 (Stretch) not longer installs this file

jessie $ dpkg --contents libpam-ldap_184-8.7+b1_amd64.deb | grep 
pam-configs/ldap
-rw-r--r-- root/root   518 2014-11-08 18:35 ./usr/share/pam-configs/ldap

stretch $ dpkg --contents libpam-ldap_186-3_amd64.deb | grep pam-configs
# nothing

Therefore the package on Stretch is pretty much useless for new installs.

The workaround is to copy this file manually from libpam-ldap=184-8.7 
and manually execute pam-auth-update.


Please, bring /usr/share/pam-configs/ldap back into libpam-ldap



signature.asc
Description: OpenPGP digital signature

Bug#848606: util-vserver: diff for NMU version 0.30.216-pre3120-1.3

[Carlos Alberto Lopez Perez]

On 19/12/16 19:37, Carlos Alberto Lopez Perez wrote:
> On 18/12/16 23:05, Hilko Bengen wrote:
>> Package: util-vserver
>> Version: 0.30.216-pre3120-1.1
>> Severity: normal
>> Tags: patch pending
>>
>> [Replace 5 with correct value]
>> Dear maintainer,
>>
>> I've prepared an NMU for util-vserver (versioned as 0.30.216-pre3120-1.3) and
>> uploaded it to DELAYED/5. Please feel free to tell me if I
>> should delay it longer.
>>
>> Regards,
>> -Hilko
>>
> 
> The changes look OK to me.
> 
> Thanks for the contribution :)
> 

Did you uploaded this in the end?

I don't see it on the archives after more than 5 days.

Shall I re-upload it? Or do you prefer to re-upload it yourself?

Thanks



signature.asc
Description: OpenPGP digital signature

Bug#848606: util-vserver: diff for NMU version 0.30.216-pre3120-1.3

[Carlos Alberto Lopez Perez]

On 18/12/16 23:05, Hilko Bengen wrote:
> Package: util-vserver
> Version: 0.30.216-pre3120-1.1
> Severity: normal
> Tags: patch pending
> 
> [Replace 5 with correct value]
> Dear maintainer,
> 
> I've prepared an NMU for util-vserver (versioned as 0.30.216-pre3120-1.3) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Regards,
> -Hilko
> 

The changes look OK to me.

Thanks for the contribution :)



signature.asc
Description: OpenPGP digital signature

Bug#843600: checkbashishm should warn about trap with SIG-something names

[Carlos Alberto Lopez Perez]

Package: devscripts
Version: 2.16.8

Hi,

It seems that referring to the signals with a SIG prefix is not
something that has to be supported by the POSIX standard:


​http://pubs.opengroup.org/onlinepubs/95399/utilities/trap.html:

RATIONALE

Implementations may permit lowercase signal names as an extension.
Implementations may also accept the names with the SIG prefix; no known
historical shell does so. The trap and kill utilities in this volume of
IEEE Std 1003.1-2001 are now consistent in their omission of the SIG
prefix for signal names. Some kill implementations do not allow the
prefix, and kill -l lists the signals without prefixes.

Trapping SIGKILL or SIGSTOP is syntactically accepted by some
historical implementations, but it has no effect. Portable POSIX
applications cannot attempt to trap these signals.


And this is major problem, because our default /bin/sh (dash) fails to
run scripts using SIGSOMETHING.


Check this example:


$ cat test.sh
#/bin/sh
trap "echo hi from int" SIGINT
kill -INT $$

$ bash test.sh
hi from int

$ dash test.sh
trap: SIGINT: bad trap

$ sh test.sh
trap: SIGINT: bad trap

$ ./test.sh
trap: SIGINT: bad trap


To fix the script, SIGINT should be replaced with INT

So I think checkbashishm should warn always that it finds SIGSOMETHING
on a trap line.



signature.asc
Description: OpenPGP digital signature

Bug#839680: Please update to upstream version 1.1rc2

[Carlos Alberto Lopez Perez]

Package: icecc
Version: 1.0.1-2
Severity: wishlist


Hi,


icecc has recently (Apr 2016) released a new version (1.1rc2 [1]) which
includes support for debug fission  (-gsplit-dwarf [2]).


It will be amazing if this version can be released in Debian.
I would love to have it on Debian Strech.


If you are short of time, I offer to help. Just let me know it.


Regards
---

[1] https://github.com/icecc/icecream/releases
[2] https://gcc.gnu.org/wiki/DebugFission



signature.asc
Description: OpenPGP digital signature

Bug#835992: [Pkg-zfsonlinux-devel] Bug#835992: 835992

[Carlos Alberto Lopez Perez]

And it seems that for kernel 4.8 another patch is needed:

https://github.com/zfsonlinux/spl/commit/b7c7008ba28ca926fbda929aec52f3761d72cffe



signature.asc
Description: OpenPGP digital signature

Bug#830824: [Pkg-zfsonlinux-devel] Bug#830824: Bug#830824: Silently corrupted file in snapshots after send/receive

[Carlos Alberto Lopez Perez]

Control: tag -1 +pending
On 11/08/16 17:51, Carlos Alberto Lopez Perez wrote:
> 1) Wait for the patch on PR #4833 to be merged, then import it
> defaulting to ignore hole_birth until the issue is fixed.

This patch was finally merged on ZoL/master but with the option set to
false by default.

I have cherry-picked it and then added another patch defaulting it to true.

On the PR #4833 [1], Brian Behlendorf comments he is also thinking in
defaulting this to true for the upcoming 0.8.5

Regards.

[1] https://github.com/zfsonlinux/zfs/pull/4833





signature.asc
Description: OpenPGP digital signature

Bug#834176: libgeoclue-2-dev should depend on package geoclue-2.0

[Carlos Alberto Lopez Perez]

Package: libgeoclue-2-dev
Version: 2.4.3-1

Hi,

I think libgeoclue-2-dev should depend on package geoclue-2.0 because
this package contains files needed for development of geoclue like
geoclue-2.0.pc

I have been dealing with geoclue/package-config related failures trying
to build webkit on debian sid until I realized the packageconfig file
geoclue-2.0.pc was not shipped on the dev package rather than in the
package geoclue-2.0


Thanks



signature.asc
Description: OpenPGP digital signature

Bug#834169: Apache2 can't be installed on testing/sid

[Carlos Alberto Lopez Perez]

Package: apache2
Version: 2.4.23-3
Severity: grave


On a new fresh created Debian Sid ADM64 chroot, installing apache2 is not 
possible:


$ sudo apt-get install  -y apache2
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  autoconf-archive fonts-lato libmpfr4 libpython-stdlib libpython2.7-minimal 
libpython2.7-stdlib libwrap0 python python-minimal python2.7 python2.7-minimal
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  ssl-cert
Suggested packages:
  apache2-doc apache2-suexec-pristine | apache2-suexec-custom openssl-blacklist
The following NEW packages will be installed:
  apache2 ssl-cert
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
31 not fully installed or removed.
Need to get 0 B/248 kB of archives.
After this operation, 641 kB of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 45161 files and directories currently installed.)
Preparing to unpack .../0-apache2_2.4.23-3_amd64.deb ...
preinst called with unknown argument `install'
dpkg: error processing archive 
/tmp/apt-dpkg-install-qHR4wD/0-apache2_2.4.23-3_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Selecting previously unselected package ssl-cert.
Preparing to unpack .../1-ssl-cert_1.0.38_all.deb ...
Unpacking ssl-cert (1.0.38) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-qHR4wD/0-apache2_2.4.23-3_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



It seems the preinst script aborts when called with $1=install


$ apt-get download apache2
Get:1 http://debian.univ-tlse2.fr/debian sid/main amd64 apache2 amd64 2.4.23-3 
[227 kB]
Fetched 227 kB in 0s (250 kB/s)


$ dpkg -I apache2_2.4.23-3_amd64.deb preinst |grep ^case -A99|grep ^esac -B99
case "$1" in
upgrade)

if dpkg --compare-versions "$2" lt-nl "2.4.23-3~" ; then
list_fixup_conffiles | replace_broken_conffiles
fi

;;

abort-upgrade)
list_fixup_conffiles | revert_broken_conffiles
;;

*)
echo "preinst called with unknown argument \`$1'" >&2
exit 1
;;
esac


I workaround this by manually installing apache2 from Jessie, which has a 

case "$1" in
install|upgrade)
[ ... ]
esac

on the preinst script, and later upgrading to the one from testing/sid.



signature.asc
Description: OpenPGP digital signature

Bug#830824: [Pkg-zfsonlinux-devel] Bug#830824: Silently corrupted file in snapshots after send/receive

[Carlos Alberto Lopez Perez]

On 09/08/16 16:35, Petter Reinholdtsen wrote:
> [ Antonio Russo 2016-07-11 ]
>> Sorry, there is no 0.6.5.8 release. The fix does exist in the master branch,
>> however.  (bc77ba7: OpenZFS 6513 - partially filled holes lose birth time)
> 
> As far as I can see from https://github.com/zfsonlinux/zfs/issues/4809 
> >,
> the issue is still unsolved upstream.
> 
> Are you sure that commit is enough to solve the problem?  There are others
> mentioned in issue #4809.
> 
> See also https://www.illumos.org/issues/6370 >,
> https://www.illumos.org/issues/6513 > and
> https://www.illumos.org/issues/6844 >.
> 

It seems there are several issues affecting zfs send/receive when the
hole_birth feature is enabled.

Commit bc77ba7 fixes one of this issues, but not the others.

The best fix right now seems to completely ignore hole_birth. A patch
was proposed here that ignores it, and adds a module parameter to enable
it back [1].

Options I see going forward:

1) Wait for the patch on PR #4833 to be merged, then import it
defaulting to ignore hole_birth until the issue is fixed.

2) If we don't want to wait for the patch to be merged, we can import it
anyway but removing the part that adds a kernel module parameter tunable
to avoid adding any option that is still not upstreamed. So just disable
hole_birth always.

3) Do nothing and wait for upstream to fix this issues with hole_birth
and zfs send/receive.


Right now, I'm inclined to proceed with option #2 and disable hole_birth
until the issues with it are 100% fixed upstream and a new major release
is made.

Opinions?


PS: There is still an user reporting some problems observed even with
ignore_hole_birth=1, but is still not 100% clear if in this case the
problem is the same. Let's wait some days to see how this evolves [2].


BTW: I'm a bit surprised that this has been raised to RC bug on Debian
unstable, but on Ubuntu LTS nobody cares about it. [3]
Or I'm missing something?


[1] https://github.com/zfsonlinux/zfs/pull/4833
[2] https://github.com/zfsonlinux/zfs/issues/4809#issuecomment-238503468
[3] https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1600060



signature.asc
Description: OpenPGP digital signature

Bug#822221: ITP: flipcoin -- flip an adjustable coin for random exit status

[Carlos Alberto Lopez Perez]

On 22/04/16 14:48, Adam Borowski wrote:
> On Thu, Apr 21, 2016 at 11:11:39PM -0700, Rudi Cilibrasi wrote:
>> * Package name: flipcoin
>> * URL : https://github.com/rudi-cilibrasi/flipcoin
>>   Description : flip an adjustable coin for random exit status
>>
>> This command-line utility can be used to simulate a coin flip to get
>> a random exit status.  The probability of success is adjustable using
>> an optional command line parameter.
> [...]
>> This package is a useful core utility for shell scripts that need to
>> do things in a way that is decorrelated in time and infrequent. Usage is
>> simple at the shell prompt:
>>
>> if flipcoin ; then echo heads ; else echo tails ; fi
> 
> Sorry, but I don't believe that someone writing shell scripts is likely to
> not know one of many ways to do this, be it $RANDOM, perl, awk, or, if you
> really want to require something non-essential, rolldice.
> 
> Thus, please reconsider the point of packaging this.
> 
> 
> Meow!
>
Indeed. With bash:

flipcoin() { return $(($RANDOM % 2)); }

if flipcoin ; then echo heads ; else echo tails ; fi

:)



signature.asc
Description: OpenPGP digital signature

Bug#816513: Call to configure_network in initramfs script broken due to set -e

[Carlos Alberto Lopez Perez]

Package: mandos-client
Version: 1.6.9-1


Hi,


The mandos initramfs script <${INITRAMFS}/scripts/init-premount/mandos>
is configured with set -e. (#!/bin/sh -e in the shebang).

This causes that it aborts when any command executed returns non-zero and
the return value is not checked.

The problem is that this script sources /scripts/functions from the initramfs
and /scripts/functions was not designed to work with set -e. So when the mandos
script calls any function sourced from /scripts/functions problems may happen.

For example, I have found that when executing the function configure_networking
it will cause the mandos script to abort if the DHCP server don't replies in
less than 2 seconds.

This function is called from the mandos initramfs script
<${INITRAMFS}/scripts/init-premount/mandos> to configure the network
when mandos=connect is specified on the kernel command line.


Let's take a look to the function configure_networking:



configure_networking()
{

# [... skipped code for clarity ]

for ROUNDTTT in 2 3 4 6 9 16 25 36 64 100; do

# The NIC is to be configured if this file does not exist.
# Ip-Config tries to create this file and when it succeds
# creating the file, ipconfig is not run again.
for x in /run/net-"${DEVICE}".conf /run/net-*.conf ; do
[ -e "$x" ] && break 2
done

case ${IP} in
none|off)
# Do nothing
;;
""|on|any)
# Bring up device
ipconfig -t ${ROUNDTTT} "${DEVICE}"
;;
dhcp|bootp|rarp|both)
ipconfig -t ${ROUNDTTT} -c ${IP} -d "${DEVICE}"
;;
*)
ipconfig -t ${ROUNDTTT} -d $IP

# grab device entry from ip option
NEW_DEVICE=${IP#*:*:*:*:*:*}
if [ "${NEW_DEVICE}" != "${IP}" ]; then
NEW_DEVICE=${NEW_DEVICE%%:*}
else
# wrong parse, possibly only a partial string
NEW_DEVICE=
fi
if [ -n "${NEW_DEVICE}" ]; then
DEVICE="${NEW_DEVICE}"
fi
;;
esac
done

# [... skipped code for clarity ]
}


This function will call ipconfig (from klibc-utils) with a different
ROUNDTTT value each time. The problem is that ipconfig will return a
non-zero value if it fails to get the DHCP value before the timeout.

This is fine if configure_networking has not been called with set -e.
Otherwise it will break things because it makes abort the whole script
on the first failure from ipconfig.


This is part of trace from the initramfs obtained by booting the machine
with the debug parameter in the kernel cmdline.

Begin: Running /scripts/init-premount ... + run_scripts /scripts/init-premount
+ initdir=/scripts/init-premount
+ [ ! -d /scripts/init-premount ]
+ shift
+ . /scripts/init-premount/ORDER
+ /scripts/init-premount/plymouth
+ [ -e /conf/param.conf ]
+ /scripts/init-premount/mandos
calling: settle
IP-Config: eth1 hardware address 0c:14:3a:1b:af:81 mtu 1500 DHCP RARP
IP-Config: eth0 hardware address 0c:14:2a:1b:af:80 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
+ [ -e /conf/param.conf ]
+ [ n != y ]
+ log_end_msg
+ _log_msg done.\n
+ [ n = y ]
+ printf done.\n
done.
+ maybe_break mount
+ [  = mount ]
+ log_begin_msg Mounting root file system
+ _log_msg Begin: Mounting root file system ... 
+ [ n = y ]
+ printf Begin: Mounting root file system ... 
Begin: Mounting root file system ... + . /scripts/local
+ . /scripts/nfs
+ . /scripts/local



As you can see, the script /scripts/init-premount/mandos exits as soon as
IP-Config fails on the first try to get IP with a 2 second timeout. 

A possible fix is the following patch:

--- a/usr/share/initramfs-tools/scripts/init-premount/mandos2016-03-02 
10:41:43.437960673 +0100
+++ b/usr/share/initramfs-tools/scripts/init-premount/mandos2016-03-02 
13:00:27.392153826 +0100
@@ -94,7 +94,7 @@
 # If we are connecting directly, run "configure_networking" (from
 # /scripts/functions); it needs IPOPTS and DEVICE
 if [ "${connect+set}" = set ]; then
-configure_networking
+configure_networking || true
 if [ -n "$connect" ]; then
cat <<-EOF >>/conf/conf.d/mandos/plugin-runner.conf



But there are also other possibilities like disabling set -e on the script.
Maybe there are other functions that can cause trouble.
I have checked all the scripts on my initramfs and only the mandos and the
udev ones are running with set -e.





signature.asc
Description: OpenPGP digital signature

Bug#733988: klibc-utils: ipconfig fails to get dhcp on machine with two interfaces

[Carlos Alberto Lopez Perez]

Control: found -1 2.0.4-2
Control: Severity -1 important

On 02/01/14 22:26, Alexander Inyukhin wrote:
> Package: klibc-utils
> Version: 2.0.2-1
> Severity: normal
> 
> Hi!
> 
> I'm trying to boot a machine with two e1000e interfaces and nfsroot.
> It works fine with kernel 3.2.0-4-amd64, but fails to get DHCP address
> with 3.11.10-1~bpo70+1-amd64.
> 
> Network is attached only to eth1, eth0 is left unconnected.
> There is also an IPMI console session over connected interface.
> 
> Manual network configuration from initramfs shell (root is set to
> non-existent device to achieve this shell) gives this:
> 
> (initramfs) ipconfig -t 2 -c dhcp -d ""
> IP-Config: eth1 hardware address f4:6d:04:03:28:40 mtu 1500 DHCP
> IP-Config: eth0 hardware address f4:6d:04:03:27:99 mtu 1500 DHCP
> IP-Config: no response after 2 secs - giving up
> (initramfs) ipconfig -t 2 -c dhcp -d eth1
> IP-Config: eth1 hardware address f4:6d:04:03:28:40 mtu 1500 DHCP
> IP-Config: eth1 complete (dhcp from 192.168.0.254):
>  address: 192.168.0.18 broadcast: 192.168.0.255netmask: 255.255.255.0 
>   
>  gateway: 192.168.0.254dns0 : 192.168.0.254dns1   : 0.0.0.0   
>   
>  host   : node-18 
>  rootserver: 192.168.0.254 rootpath: 
>  filename  : 
> 
> In the first case and "in the wild" ipconfig sends DISCOVER request, but 
> ignores OFFER.
> 
> To workaround this issue I have to set "IPAPPEND 2" in pxelinux config file.
> 
> 
> 

I have been bitten also by this bug on a fresh Debian Jessie
installation while trying to configure the machine to get DHCP in the
initramfs.

The machine also had two Ethernet interfaces. eth0 connected to the LAN
and eth1 with the cable unplugged.

After many tries and debugging I ended configuring the IP manually via
the boot parameter ip= which was an option for my use case.

I'm raising the severity of this because this breaks automatic IP
configuration for any machine with more than one internet interface,
which is not uncommon nowadays.



signature.asc
Description: OpenPGP digital signature

Bug#786987: Re: Bug#786987: openssh-server: please have DebianBanner default to no

[Carlos Alberto Lopez Perez]

On 22/02/16 18:27, Russ Allbery wrote:
> Carlos Alberto Lopez Perez <clo...@igalia.com> writes:
> 
>> Attackers usually don't start trying to probe exploit after exploit.
> 
> Of course they do.  That is, *by far*, the most common attacker strategy
> on the Internet.  Just look at the logs of any Internet-facing service.
> 

Yes, there are some attackers that do silly things like that. And since
they make lot of noise they appear also a lot on the logs.

But it happens that there are also intelligent attackers out there. They
will first try to find hosts running the affected version that their
exploit targets. This last ones are usually more successful and you
won't see them in the logs of any Internet-facing service because they
don't make noise trying exploit after exploit.



signature.asc
Description: OpenPGP digital signature

Bug#786987: Re: Bug#786987: openssh-server: please have DebianBanner default to no

[Carlos Alberto Lopez Perez]

On 22/02/16 16:30, Colin Watson wrote:
> On Mon, Feb 22, 2016 at 04:19:24PM +0100, Carlos Alberto Lopez Perez wrote:
>> So, putting it into other words...  The use case was actually to make
>> easier to detect vulnerable systems to anyone without access to the
>> system by inspecting the DebianBanner version of the SSH servers, right?
> 
> People can do that anyway just by seeing whether their attacks work;
> plenty of actual attackers just scattergun their attacks.  Hiding the
> version doesn't particularly help, 

I disagree.

If some attacker knows that (for example) that
openssh-server=1:6.7p1-5+deb8u is vulnerable to any vulnerability, they
can find instantly thousands of hosts to attack directly by doing
something as easy as this:

https://www.shodan.io/search?query=SSH-2.0-OpenSSH_6.7p1+Debian-5%2Bdeb8u1

And if they want to find hosts running on Debian lenny (that probably
contains many unpatched vulnerabilities), they can do this:

https://www.shodan.io/search?query=SSH-2.0-OpenSSH_5.1p1+Debian-5

So, this leak on information helps a *lot* to any attacker targeting
specific versions of unpatched software.


Attackers usually don't start trying to probe exploit after exploit.
That is silly. They are probably going to be detected by some IDS or
something like that. The first thing an attacker is going to do is to
gather information about what you are running and which versions. And
this default is helping them a lot.

> but giving network administrators the
> ability to efficiently shut off access to vulnerable systems can do.
>

I think that any network administrator having to do this to secure their
own network probably has a bigger problem that insecure hosts on their
network.

In any case I'm not going to argue about this. We are talking about a
default.

How much network administrators have this need?

And how many Debian users are leaking information about their insecure
machines making them much more exposed to attackers targeting old
versions of the software they run?

So, I think the default should be to have this option to be No.

And the burden should be on the network administrator of your use case
to tell users to enable this option or he will disconnect them.




signature.asc
Description: OpenPGP digital signature

Bug#786987: Re: Bug#786987: openssh-server: please have DebianBanner default to no

[Carlos Alberto Lopez Perez]

On 27/05/15 16:38, Colin Watson wrote:
>> An administrator capable of upgrading packages when needed (e.g. for
>> security updates) should have more reliable ways to learn the version of
>> openssh-server running on their system than a cleartext banner sent
>> across the network on port 22.
> 
> The specific case that prompted the banner in the first place was that
> of a university trying to ensure that systems on its network was secure,
> where the central administration doesn't have direct access to upgrade
> packages nor any other such reliable way to determine package versions,
> but does have the ability to disconnect vulnerable systems if need be.
> 
> Cheers,
> 

So, putting it into other words...  The use case was actually to make
easier to detect vulnerable systems to anyone without access to the
system by inspecting the DebianBanner version of the SSH servers, right?

Is this use case (announcing vulnerable machines via the SSH server
DebianBanner info to anyone without access rights to the machine)
something that Debian wants to keep supporting by default I'm astonished



signature.asc
Description: OpenPGP digital signature

Bug#815558: Debian banner of SSH server on Jessie still advertised to be running on Lenny

[Carlos Alberto Lopez Perez]

Package: openssh-server
Version: 1:6.7p1-5+deb8u1


Hi,

I have noticed this:

$ nc old-debian-lenny-machine 22
SSH-2.0-OpenSSH_5.1p1 Debian-5

$ nc just-fresh-installed-debian-jessie-machine 22
SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u1


Why the Debian banner is still advertising Debian 5 on a Debian 8 machine?


Maybe the best solution is to just disable this banner by default ?
https://bugs.debian.org/786987


Thanks.



signature.asc
Description: OpenPGP digital signature

Bug#794410: Debian Jessie installer freezes during "Processing triggers for libc-bin"

[Carlos Alberto Lopez Perez]

On 17/02/16 21:04, Carlos Alberto Lopez Perez wrote:
[...]
> 
> Trying to read this very same information when /dev/bus/usb/003/002 appears 
> causes a freeze. 
> 
> 
> So, not sure what is going here, but this looks like either a kernel bug or a 
> firmware bug.
> 
> 

This seems very related to this bug reports:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1485057
http://thread.gmane.org/gmane.linux.usb.general/129790

Perhaps the same issue.





signature.asc
Description: OpenPGP digital signature

Bug#794410: Debian Jessie installer freezes during "Processing triggers for libc-bin"

[Carlos Alberto Lopez Perez]

On 17/02/16 20:15, Carlos Alberto Lopez Perez wrote:
> 
> I wonder what can be causing this issue :\
> 
> I already had this issue when installing a fresh Debian 8 in another
> machine, but in that one only happened once. After a hard-reboot and a
> retry it worked. With this Intel NUC machine happened everytime of the 4
> times I tried to install it.

Seems the freeze is reproducible on the installed system (with Debian Jessie 
and the default 3.16.0-4-amd64 kernel) by running:

$ discover-modprobe

If i run it with -x i see that it freezes here:

 readlink -f /sbin/discover-modprobe
+++ '[' 0 = 1 ']'
++ FANCYTTY=
++ '[' -e /etc/lsb-base-logging.sh ']'
++ true
+ . /etc/default/rcS
+ '[' -d /var/discover ']'
+ nop=
+ verbose=false
+ getopts nv ch
+ shift 0
++ grep -E -v '^ *$'
+++ uname -r
++ /sbin/discover --data-path=linux/module/name 
--data-path=linux/module/options '--format=%s %s' --data-version=3.16.0-4-amd64 
all


And If i run the above comand with strace -f, then it freezes here:


read(3, "C Camera/Webcam controller'/>\n  "..., 4096) = 4096
brk(0x145e000)  = 0x145e000
read(3, "een'/>\n  \n  <device"..., 4096) = 4096
read(3, "ideo Player'/>\n  \n  \n"..., 4096) = 1459
read(3, "", 4096)   = 0
read(3, "", 4096)   = 0
close(3)= 0
munmap(0x7f598aea2000, 4096)= 0
open("/proc/bus/usb/devices", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 5 entries */, 32768) = 120
close(3)= 0
openat(AT_FDCWD, "/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 5 entries */, 32768) = 120
getdents(3, /* 0 entries */, 32768) = 0
close(3)= 0
openat(AT_FDCWD, "/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) 
= 3
getdents(3, /* 4 entries */, 32768) = 96
open("/dev/bus/usb/003/002", O_RDWR


It don't freezes always, only sometimes.

Comparing the straces from when it freezes which the straces when it doesn't I 
see the following difference:

* This is when it works ok (don't freezes):


openat(AT_FDCWD, "/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) 
= 3
getdents(3, /* 3 entries */, 32768) = 72
open("/dev/bus/usb/003/001", O_RDWR)= 4


* This is when it freezes:

openat(AT_FDCWD, "/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) 
= 3
getdents(3, /* 4 entries */, 32768) = 96
open("/dev/bus/usb/003/002", O_RDWR


Seems that when it freezes it finds 4 entries in the directory /dev/bus/usb/003 
instead of 3,
and when it tries to open the "ghost" entry it freezes completely.

ls -al /dev/bus/usb/003 gives 3 entries : (".", "..", "001")

I have been rebooting it a couple of times and doing an ls to see if I see 4 
entries.
And when i get 4 entries, trying to access it causes a freeze.

ls -al /dev/bus/usb/003
total 0
drwxr-xr-x 2 root root   80 Feb 17 20:51 .
drwxr-xr-x 5 root root  100 Feb 17 20:51 ..
crw-rw-r-- 1 root root 189, 256 Feb 17 20:51 001
crw-rw-r-- 1 root root 189, 257 Feb 17 20:51 002


$ lsusb
# <... freeze>

The information about /dev/bus/usb/003 is:

# lsusb -D /dev/bus/usb/003/001 
Device: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 3 
  bMaxPacketSize0 9
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0003 3.0 root hub
  bcdDevice3.16
  iManufacturer   3 Linux 3.16.0-4-amd64 xhci_hcd
  iProduct2 xHCI Host Controller
  iSerial 1 :00:14.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   31
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch 

Bug#794410: Debian Jessie installer freezes during "Processing triggers for libc-bin"

[Carlos Alberto Lopez Perez]

I'm having this issue on a Intel NUC (Intel Atom E3815).

Is literally impossible to install Debian 8.

Tried with the following:

 - debian-8.3.0-amd64-netinst.iso (with internet on the NUC)
 - debian-8.3.0-amd64-CD-1.iso (without network connection).

Booting from a usb device that was created via the usual:

$ dd if=image.iso of=/dev/sdX bs=4k

It always freezes on the step

in-target: Setting up discover (2.1.2-7) ...
in-target: Processing triggers for libc-bin (2.19-18+deb8u1) ...

step as seen on the debug console (alt+f4).

Even the cursor stops blinking and it will ignore any key press
combination. Freezes completely 100% of the times.

Here is a picture of the freeze just after it happens:
http://people.igalia.com/clopez/di8_freezes_discover_libctriggers.jpg

Tried installing in DOS mode and in UEFI mode. Didn't make any difference.

This machine don't has any wlan device as the previous reported

I ended workaround this by installing Debian wheezy
 and dist-upgrading after the install.

The triggers for libc-bin in Jessie only seems to contain this:

$ dpkg -I libc-bin_2.19-18+deb8u2_amd64.deb triggers
interest ldconfig


I wonder what can be causing this issue :\

I already had this issue when installing a fresh Debian 8 in another
machine, but in that one only happened once. After a hard-reboot and a
retry it worked. With this Intel NUC machine happened everytime of the 4
times I tried to install it.



signature.asc
Description: OpenPGP digital signature

Bug#746712: please update the loginuid patch to match upstream's current version

[Carlos Alberto Lopez Perez]

Control: severity -1 important
Control: found -1 1.1.8-3.1+deb8u1


Hi,

I'm raising the severity of this bug because is causing that all Debian
containers to be broken when run inside an user namespace.

SSH does not work, neither does login, neither cron. Is a complete mess.

The workaround is to manually disable pam_loginuid in the container with
something like:

sed -i '/^session.*pam_loginuid.so/s/^session/# session/' /etc/pam.d/*

But, I guess users shouldn't have to do this after creating a new Debian
container.

Please maintainer, consider updating the pam-loginuid-in-containers
patch with the version attached in this bug.


Thanks!



signature.asc
Description: OpenPGP digital signature

Bug#793372: systemd breaks LXC cgroup memory limitations

[Carlos Alberto Lopez Perez]

On 23/07/15 13:57, Pablo Abelenda wrote:
> After this income information, I have switched back both the host and
> the container, to sysvinit. With the systems booted on sysvinit, the
> memory limitation is working as it is expected.
> 

I have been investigating this further and I'm not sure at this point if
the bug is on systemd or LXC.

I have posted my findings to the lxc-users mailing list:

http://thread.gmane.org/gmane.linux.kernel.containers.lxc.general/10825



signature.asc
Description: OpenPGP digital signature

Bug#800574: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)

[Carlos Alberto Lopez Perez]

On 23/10/15 22:10, Henrique de Moraes Holschuh wrote:
> On Fri, Oct 23, 2015, at 11:13, Carlos Alberto Lopez Perez wrote:
>> I was having trouble (crashes with the NVIDIA proprietary driver) on a
>> Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable)
> 
> This is very very likely to be braindamage on the NVIDIA driver, though.
> 
> Are you sure that driver is not doing something as idiotic as unlocking
> an already unlocked mutex ?
> 
> The proper fix in that case is _always_ to fix whatever is broken,
> because eventually it will run on something that has working hardware
> lock elision... and crash.
> 

I can't know, since I don't have access to the source code of the
driver, neither the debug symbols are available, so any attempt to get a
meaningful backtrace was hopeless.

At first I also thought it was the driver doing something wrong, but
then I found several reports of people with the same cryptic backtrace
than me saying that this was because of the TSX-NI bug of recent Intel
CPUs [1].

And effectively, after upgrading glibc to this one that disables TSX-NI
for broadwell it suddenly works as expected...

So this seems to suggest that effectively TSX-NI is buggy on this CPU.

In any case... Do you know of any program or test that I can run to
check if TSX-NI (both HLE and RTM) is working as it should or is still
buggy on this CPU? That way we can verify better if the problem is in
the CPU or in the driver.

>> I tried first to update the Intel microcode with the "unreleased" 0x13
>> microcode version but it didn't disabled the TSX-NI instructions [1]
>> neither the crashes.
> 
> Mobile Broadwell-H seems to disable TSX, while Desktop Broadwell-H
> doesn't.  That's why we blacklisted the whole thing: inconsistent
> behavior on the same microcode, and that behavior is itself inconsistent
> with the errata sheet that says such processors shouldn't even be able
> to advertise Intel TSX RTM in CPUID.
> 
> At the moment, we don't even know what is wrong with RTM in
> Broadwell/Broadwel-H/Broadwell-DE.  We do know some of what is wrong
> with HLE in Broadwell/-H/-DE (and it is really nasty), but HLE is not
> used by glibc in the first place, and the HLE erratum is supposedly
> worked around somehow (because it is documented to be so on the Xeon
> D-1500/Broadwell-DE) by the batch of microcode updates available in the
> kernel bugzilla bug report mentioned in this bug report.
> 
> Broadwell-H Microcode 0x13 is useful anyway because it fixes other
> critical errata that hangs/oopses the kernel: you box should be a _lot_
> more stable with it.  And at least one person reported that not all
> hangs were fixed by microcode 0x12, thus you probably should use keep
> using microcode 0x13 (or newer, should one become available).
> 

Good to know, thanks for the advice. I will keep using this 0x13
"unofficial" microcode until a new one is out.
I can't keep wondering why Intel is not releasing this :\


Regards!


[1]
https://lists.archlinux.org/pipermail/arch-general/2015-April/038953.html



signature.asc
Description: OpenPGP digital signature

Bug#800574: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)

[Carlos Alberto Lopez Perez]

On 26/10/15 20:13, Carlos Alberto Lopez Perez wrote:
> On 23/10/15 22:10, Henrique de Moraes Holschuh wrote:
>> On Fri, Oct 23, 2015, at 11:13, Carlos Alberto Lopez Perez wrote:
>>> I was having trouble (crashes with the NVIDIA proprietary driver) on a
>>> Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable)
>>
>> This is very very likely to be braindamage on the NVIDIA driver, though.
>>
>> Are you sure that driver is not doing something as idiotic as unlocking
>> an already unlocked mutex ?
>>
>> The proper fix in that case is _always_ to fix whatever is broken,
>> because eventually it will run on something that has working hardware
>> lock elision... and crash.
>>
> 
> I can't know, since I don't have access to the source code of the
> driver, neither the debug symbols are available, so any attempt to get a
> meaningful backtrace was hopeless.
> 
> At first I also thought it was the driver doing something wrong, but
> then I found several reports of people with the same cryptic backtrace
> than me saying that this was because of the TSX-NI bug of recent Intel
> CPUs [1].
> 
> And effectively, after upgrading glibc to this one that disables TSX-NI
> for broadwell it suddenly works as expected...
> 
> So this seems to suggest that effectively TSX-NI is buggy on this CPU.
> 
> In any case... Do you know of any program or test that I can run to
> check if TSX-NI (both HLE and RTM) is working as it should or is still
> buggy on this CPU? That way we can verify better if the problem is in
> the CPU or in the driver.
> 

I'm re-reading your explanation [2] about programs crashing with SIGSEV
in __lll_unlock_elision when TSX is enabled to be caused by the program
itself trying to unlock an already unlocked lock. That would explain
everything, and will point indeed to a bug in the NVIDIA driver rather
than in the CPU.

Also, this specific model of CPU (i7-5775C) for what I have been reading
seems to have fixed TSX-NI support. At least the ark page of Intel still
advertises it [3]. In any case I'm still interested in testing this to
be 100% sure. If you know about any test program that I can run, please
let me know about it.

Cheers
--

[2] https://bugzilla.kernel.org/show_bug.cgi?id=103351#c86
[3]
http://ark.intel.com/products/88040/Intel-Core-i7-5775C-Processor-6M-Cache-up-to-3_70-GHz



signature.asc
Description: OpenPGP digital signature

Bug#800574: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)

[Carlos Alberto Lopez Perez]

Hi,

Thanks for this patch.

I was having trouble (crashes with the NVIDIA proprietary driver) on a
Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable)

I tried first to update the Intel microcode with the "unreleased" 0x13
microcode version but it didn't disabled the TSX-NI instructions [1]
neither the crashes.

Finally I upgraded to glibc=2.21-0experimental2 and it fixed the crashes.

I wonder:

Should this patch be backported both to stable and unstable?


Thanks for your awesome work !


Regards
---

[1] https://bugzilla.kernel.org/show_bug.cgi?id=103351#c93



signature.asc
Description: OpenPGP digital signature

Bug#797064: unusuable with current kernels, remove vserver packages from sid?

[Carlos Alberto Lopez Perez]

Hi,

From my point of view, the situation regarding vserver is the following:


1) Regarding the vserver patch for the Linux kernel:

 - The latest LTS Kernel (3.18) is already supported [1].
   This is usually what you want to use in production (LTS).

 - There is already a beta patch for Linux 4.1 [2]. And there will be
patches for 4.2 and newer kernels ASAP.

 - So my conclusion is that development of the patchset keeps going. A
bit slow, but steady.

2) Regarding the util-vserver package, I'm going to update it to the
last version from upstream in the next days. And I'm plan to keep
maintaining it for the foreseeable future.


3) Regarding the vserver-debiantools package: I don't use it, but maybe
there are still some users of it? So... my suggestion is to keep it
within Debian (of course if there aren't any serious bug with it).
I think the users of this utility will appreciate that you keep the
package on Debian meanwhile it works.


So, I don't see any compelling reason to request the removal of
util-vserver.


Regards
---

[1] http://vserver.13thfloor.at/Experimental/patch-3.18.7-vs2.3.7.4.diff
[2]
http://vserver.13thfloor.at/Experimental/patch-4.1.3-vs2.3.8.2_donotuse.diff


On 27/08/15 22:28, Ola Lundqvist wrote:
> Hi Holger
> 
> I tend to agree. I thought I had already asked for the removal of 
> vserver-debiantools, but obviously not.
> 
> Carlos, what do you say?
> 
> Cheers,
> 
> // Ola
> 
> On Thu, Aug 27, 2015 at 4:15 PM, Holger Levsen
>  wrote:
> 
>> package: util-vserver, vserver-debiantools severity: important 
>> x-debbugs-cc: debian...@lists.debian.org
>> 
>> Hi,
>> 
>> both util-vserver as well as vserver-debiantools are unusuable with
>> current kernels as upstream only supports up to linux 3.18.7, so I
>> wonder if actually util-vserver and vserver-debiantools should be
>> removed from sid?
>> 
>> Only filing this as "important" as one can easily use these old
>> kernels...
>> 
>> 
>> cheers, Holger
>> 
> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#793372: systemd breaks LXC cgroup memory limitations

[Carlos Alberto Lopez Perez]

Just CC'ing the Debian LXC maintainer and the upstream LXC mailing lists.

I guess they may find relevant this bug.

https://bugs.debian.org/793372

Regards.

On 23/07/15 13:57, Pablo Abelenda wrote:
 Package: systemd
 Version: 215-17+deb8u1
 Severity: important
 
 Dear Maintainer,
 
 I have been checking on LXC for a while. I wanted to acquaint with the
 containers management, specifically with the resources limitation
 capabilities.
 
 I have created, configured and destroyed several containers. The issue
 comes when I try to limit the memory usage. I have added this option to
 the grub defaults:
 
 cgroup_enable=memory
 
 This allowed me to start a container with options configured such as
 this:
 
 lxc.cgroup.memory.limit_in_bytes = 1024M
 lxc.cgroup.memory.memsw.limit_in_bytes = 1200M
 
 The thing is that when I try to use more than 1200 MB of memory, inside
 the container, I actually can. I have used a very simply script I found
 on someone page to test the memory allocation capabilities.
 
 
 memory_allocation.py
 
 #!/usr/bin/env python
 import sys
 import time
 
 if len(sys.argv) != 2:
 print usage: fillmem number-of-megabytes
 sys.exit()
 
 count = int(sys.argv[1])
 
 megabyte = (0,) * (1024 * 1024 / 8)
 
 data = megabyte * count
 
 while True:
 time.sleep(1)
 
 
 I have tried to isolate the problem, focusing on some missing LXC or
 cgroups configuration. Let me add the trace:
 
 First, I have created a new control group, outside the LXC stuff:
 
 cgcreate -g memory:/bmalloc1gb
 echo $(( 1024 * 1024 * 1024 ))|tee 
 /sys/fs/cgroup/memory/bmalloc1gb/memory.limit_in_bytes
 echo $(( 1200 * 1024 * 1024 ))|tee 
 /sys/fs/cgroup/memory/bmalloc1gb/memory.memsw.limit_in_bytes
 cgexec -g memory:/bmalloc1gb bash
 python memory_allocation.py 2000 [killed]
 
 When I run the script on this environment, the memory allocation did not
 went far from this 1200 MB, which is what I need.
 
 Second, I have joined the LXC cgroup, to try the very same as above:
 
 cgexec -g memory:lxc/test bash
 python memory_allocation.py 2000 [killed]
 
 This two tests made me point to LXC, but after some internet digging I
 found this:
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777601
 
 In this bug report, which is not exactly the same as this one, the
 reporter states this:
 
 I also tested something which may be another problem (so another ticket)
 but the memory and swap limitation doesn't work at all :-(...with or
 without this bug. I can't tell if it's linked or not.
 I tested cpu pinning and it works like a charm. The issue seems related
 to memory and swap only.
 
 After this income information, I have switched back both the host and
 the container, to sysvinit. With the systems booted on sysvinit, the
 memory limitation is working as it is expected.
 
 Let me add the whole container configuration for your reference:
 
 lxc.cgroup.cpuset.cpus = 0,1
 lxc.cgroup.cpu.shares = 256
 lxc.cgroup.blkio.weight = 500
 lxc.cgroup.memory.limit_in_bytes = 1024M
 lxc.cgroup.memory.memsw.limit_in_bytes = 1200M
 lxc.network.type = veth
 lxc.network.flags = up
 lxc.network.link = br0
 lxc.network.name = eth0
 lxc.rootfs = /dev/vg/test
 lxc.start.auto = 1
 lxc.include = /usr/share/lxc/config/debian.common.conf
 lxc.mount = /var/lib/lxc/test/fstab
 lxc.utsname = test
 lxc.arch = amd64
 lxc.autodev = 1
 
 Thanks for your consideration.
 
 Best regards.
 
 
 -- Package-specific info:
 
 -- System Information:
 Debian Release: 8.1
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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 systemd depends on:
 ii  acl 2.2.52-2
 ii  adduser 3.113+nmu3
 ii  initscripts 2.88dsf-59
 ii  libacl1 2.2.52-2
 ii  libaudit1   1:2.4-1+b1
 ii  libblkid1   2.25.2-6
 ii  libc6   2.19-18
 ii  libcap2 1:2.24-8
 ii  libcap2-bin 1:2.24-8
 ii  libcryptsetup4  2:1.6.6-5
 ii  libgcrypt20 1.6.3-2
 ii  libkmod218-3
 ii  liblzma55.1.1alpha+20120614-2+b3
 ii  libpam0g1.1.8-3.1
 ii  libselinux1 2.3-2
 ii  libsystemd0 215-17+deb8u1
 ii  mount   2.25.2-6
 ii  sysv-rc 2.88dsf-59
 ii  udev215-17+deb8u1
 ii  util-linux  2.25.2-6
 
 Versions of packages systemd recommends:
 ii  dbus1.8.18-0+deb8u1
 ii  libpam-systemd  215-17+deb8u1
 
 Versions of packages systemd suggests:
 pn  systemd-ui  none
 
 -- no debconf information
 
 
 





signature.asc
Description: OpenPGP digital signature

Bug#788370: Please include all the *info, *gears* and *egltri* binaries

[Carlos Alberto Lopez Perez]

Package: mesa-utils
Version: 8.2.0-1
Severity: wishlist


After running ./configure  make on the source package of mesa-demos, I
see that a lot of binaries are built but only a few are shipped.

I think that all versions of *info, *gears* and *egltri* are interesting
and should be included.


This is what gets built:

$ find src -type f -executable|grep info
src/egl/opengl/eglinfo
src/egl/opengles2/es2_info
src/xdemos/glxinfo
src/xdemos/pbinfo
src/demos/glinfo

$ find src -type f -executable|grep gears
src/egl/opengl/xeglgears
src/egl/opengl/peglgears
src/egl/opengl/eglgears_x11
src/egl/opengl/eglgears_screen
src/egl/opengles2/es2gears_x11
src/egl/opengles2/es2gears_screen
src/xdemos/glxgears_pixmap
src/xdemos/glxgears
src/xdemos/glxgears_fbconfig
src/demos/gears

$ find src -type f -executable|grep egltri
src/egl/opengl/egltri_x11
src/egl/opengl/egltri_screen


This is what is shipped:

$ dpkg -L mesa-utils|grep bin/
/usr/bin/glxdemo
/usr/bin/glxgears
/usr/bin/glxinfo
/usr/bin/glxheads

$ dpkg -L mesa-utils-extra|grep bin/
/usr/bin/es2tri
/usr/bin/es2gears_screen
/usr/bin/es2_info
/usr/bin/es2gears_x11
/usr/bin/es2gears


Thanks!



signature.asc
Description: OpenPGP digital signature

Bug#776536: /usr/bin/eog: Crash raising a gdk error when opening png test images

[Carlos Alberto Lopez Perez]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=672990#c2

Seems that this is a know limitation of cairo.

It can't handle images with an horizontal or vertical size greater than 32K 
pixels. :(




signature.asc
Description: OpenPGP digital signature

Bug#785672: Critical ext4 data corruption bug (maybe is dm-crypt related ?)

[Carlos Alberto Lopez Perez]

Are you using dm-crypt?

Then this may be related to another bug that appeared on 4.0. See:

http://thread.gmane.org/gmane.linux.kernel/1942014


The following issue on RH's tracker is also related:
https://bugzilla.redhat.com/show_bug.cgi?id=1223332


I can confirm that last bug (dm-crypt). I have experimented this issue
after upgrading to 4.0.2 (lot of libata errors). Luckily I quickly
noticed it and downgraded to 3.16, and I didn't suffered of any data
corruption/loss (or at least didn't noticed so far).


Regards.



signature.asc
Description: OpenPGP digital signature

Bug#780142: kpartx fails with error device-mapper: resume ioctl on loop0p1 failed: Invalid argument

[Carlos Alberto Lopez Perez]

Package: kpartx
Version: 0.5.0-6
Severity: important


Hi,

kpartx fails to map the following image file:

# Note: download is ~1GB zip that gives an uncompressed ~8GB image.
$ wget 
http://download.udoo.org/files/UDOO_Quad/Yocto_img/udoo_quad_revC_yocto_090713.zip
[...]

$ sha1sum udoo_quad_revC_yocto_090713.zip
c79c6961a37eed320fdf9843f69500558c86fc58  udoo_quad_revC_yocto_090713.zip

$ unzip udoo_quad_revC_yocto_090713.zip 
Archive:  udoo_quad_revC_yocto_090713.zip
  inflating: udoo_quad_revC_yocto_09072013.img  

$ ls -sh udoo_quad_revC_yocto_09072013.img 
7.4G udoo_quad_revC_yocto_09072013.img

$ sha1sum udoo_quad_revC_yocto_09072013.img 
dd5ddd6d1676d49e69ad9d5613dd2dfa84e96868  udoo_quad_revC_yocto_09072013.img

$ file udoo_quad_revC_yocto_09072013.img 
udoo_quad_revC_yocto_09072013.img: ; partition 1 : ID=0x83, start-CHS 
(0x1,70,6), end-CHS (0x3c6,177,43), startsector 20480, 15509504 sectors


$ sudo kpartx -av udoo_quad_revC_yocto_09072013.img 
device-mapper: resume ioctl on loop0p1 failed: Invalid argument
create/reload failed on loop0p1
add map loop0p1 (0:0): 0 15509504 linear /dev/loop0 20480

And on /var/log/kern.log it appears:
kernel: [728695.658845] device-mapper: table: 253:7: loop0 too small for 
target: start=20480, len=15509504, dev_size=15407104


$ sudo fdisk -l /dev/loop0

Disk /dev/loop0: 7.4 GiB, 7888437248 bytes, 15407104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x32bb

Device   Boot Start  End  Sectors  Size Id Type
/dev/loop0p1  20480 15529983 15509504  7.4G 83 Linux


And there is no /dev/loop0p1 or /dev/mapper/loop0p1 anywhere.

kpartx works for me fine with another images, so maybe there
is something in this image that makes it fail?

BTW: I don't have multipath-tools installed.

-- System Information:
Debian Release: 8.0
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages kpartx depends on:
ii  dmsetup 2:1.02.90-2
ii  libc6   2.19-13
ii  libdevmapper1.02.1  2:1.02.90-2
ii  udev215-8

kpartx recommends no packages.

kpartx suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#704989: dkms: Add POST_BUILD to the dkms_conf_variables list

[Carlos Alberto Lopez Perez]

Control: tags -1 + fixed-upstream

This was applied ustream on 22/Sep/2014:

git://linux.dell.com/dkms.git 8653e9f44145bbf77d7145bc0c4f9f0c336a7fb9



signature.asc
Description: OpenPGP digital signature

Bug#751892: Re: Bug#751892: udev: external media belong to disk group

[Carlos Alberto Lopez Perez]

On 26/02/15 15:13, Marco d'Itri wrote:
 On Feb 26, Carlos Alberto Lopez Perez clo...@igalia.com wrote:
 
 To any random user reading this bug (me for example) it looks like you
 did this change that broke a feature that was working previously without
 any valid reason and that you don't even care to explain it.
 I am quite confident that I will be able to live with this stigma.
 

Please notice than no one in this bug is trying to blame or put an
stigma on you.

We think that the change you have done on the udev package is wrong and
should be reverted.

You disagree, that's ok.

So, we kindly ask for an explanation about your disagreement. You refuse
to give any explanation.  That's not ok.

Do you think this is an appropriate behavior for a maintainer? I was
expecting a higher standard from a DD that maintains one of the core
packages.



signature.asc
Description: OpenPGP digital signature

Bug#751892: Re: Bug#751892: udev: external media belong to disk group

[Carlos Alberto Lopez Perez]

On 19/11/14 04:24, m...@linux.it (Marco d'Itri) wrote:
 On Nov 19, Dmitry Alexandrov 321...@gmail.com wrote:
 
 May I ask, what exactly did work wrong with removable medias belonging to
 ‘floppy’ group? To me it is one of conventions that always existed. Was
 there any bug caused by it?
 Yes, and I have no interest in digging them up from the BTS archives.
 

At least you could explain a bit what was wrong with the previous
behavior of using the floppy group for removable devices.

To any random user reading this bug (me for example) it looks like you
did this change that broke a feature that was working previously without
any valid reason and that you don't even care to explain it.



signature.asc
Description: OpenPGP digital signature

Bug#775932: Certificate from msm.mitre.org (Entrust) not recognized by some programs.

[Carlos Alberto Lopez Perez]

On 22/01/15 15:39, Michael Shuler wrote:
 Control: tags -1 + wontfix
 
 On 01/21/2015 11:18 AM, Carlos Alberto Lopez Perez wrote:
 - Certificate[3] info:
   - subject `C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref.
 (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure
 Server Certification Authority', issuer
 `C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref. (limits
 liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure Server
 Certification Authority', RSA key 1024 bits, signed using RSA-SHA1,
 activated `1999-05-25 16:09:40 UTC', expires `2019-05-25 16:39:40
 UTC', SHA-1 fingerprint `99a69be61afe886b4d2b82007cb854fc317e1539'
 - Status: The certificate is NOT trusted. The certificate issuer is
 unknown.
 
 CN=Entrust.net Secure Server Certification Authority'
 SHA-1 fingerprint `99a69be61afe886b4d2b82007cb854fc317e1539'
 
 This CA (as well as all other 1024-bit CAs) was removed from the Mozilla
 certificate bundle. You will find this CA removal listed in the
 ca-certificates 20140927 release changelog.
 
 https://bugzilla.mozilla.org/show_bug.cgi?id=936304
 http://anonscm.debian.org/cgit/collab-maint/ca-certificates.git/tree/debian/changelog?id=debian/20140927
 
 

So Why iceweasel, chromium or wget accept this certificate as valid?
Do you have any idea?



signature.asc
Description: OpenPGP digital signature

Bug#775932: Certificate from msm.mitre.org (Entrust) not recognized by some programs.

[Carlos Alberto Lopez Perez]

Package: ca-certificates
Version: 20141019


Hi,


On a Debian/testing system the certificate from https://msm.mitre.org
(signed by Entrust) is not recognized by some system programs,
meanwhile it is recognized by others.

I will list some examples where it is not recognized first, and then
some examples where it is recognized.


Not recognized:


$ openssl s_client -CApath /etc/ssl/certs -connect msm.mitre.org:443
CONNECTED(0004)
depth=3 C = US, O = Entrust.net, OU = www.entrust.net/CPS incorp. by ref. 
(limits liab.), OU = (c) 1999 Entrust.net Limited, CN = Entrust.net Secure 
Server Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=US/ST=Virginia/L=McLean/O=The Mitre Coproration/CN=msm.mitre.org
   i:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by 
reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
 1 s:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by 
reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
   i:/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits 
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority 
(2048)
 2 s:/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits 
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority 
(2048)
   i:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits 
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server 
Certification Authority
 3 s:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits 
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server 
Certification Authority
   i:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits 
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server 
Certification Authority
---
Server certificate
-BEGIN CERTIFICATE-
MIIGXTCCBUWgAwIBAgIETCKi8jANBgkqhkiG9w0BAQUFADCBsTELMAkGA1UEBhMC
VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
Lm5ldC9ycGEgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMW
KGMpIDIwMDkgRW50cnVzdCwgSW5jLjEuMCwGA1UEAxMlRW50cnVzdCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSAtIEwxQzAeFw0xNDA0MDkxMzEyNDZaFw0xNjExMDEy
MDAzNTJaMGkxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEPMA0GA1UE
BxMGTWNMZWFuMR4wHAYDVQQKExVUaGUgTWl0cmUgQ29wcm9yYXRpb24xFjAUBgNV
BAMTDW1zbS5taXRyZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDC5h1/pbx6i+/vwCFPEOARzyMZEMC0I69XV00XeR6HDw6RehcXbDjg8fKA351U
t5N6+SZoRg/yCrodNv4EJ5vjqR9eFS1W/wEMjP1DseU3clJPKiH7s0AA/46rUQty
EnH9FckjvvqrrdUJu7ipGXHRGOUv7tsPrC2BJDMwX4Qo+48ggivp2XUdreMW8toT
uu6W6mslpCdyoKoeTH52PsOyGr/fa/PZMP7NhUhklRRP3hl7wODWawSnCZWr7QtV
rPRL5tGJNQIYBezzTMY+gA8TdJXKJBSiVlW9mqqRxSKaF4Z9uxhn6zbK+3ZnlaS2
p2yW77PWXOMedM9veDluL1dNAgMBAAGjggLCMIICvjALBgNVHQ8EBAMCBaAwHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMDMGA1UdHwQsMCowKKAmoCSGImh0
dHA6Ly9jcmwuZW50cnVzdC5uZXQvbGV2ZWwxYy5jcmwwZAYIKwYBBQUHAQEEWDBW
MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5lbnRydXN0Lm5ldDAvBggrBgEFBQcw
AoYjaHR0cDovL2FpYS5lbnRydXN0Lm5ldC8yMDQ4LWwxYy5jZXIwSgYDVR0gBEMw
QTA1BgkqhkiG9n0HSwIwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5lbnRydXN0
Lm5ldC9ycGEwCAYGZ4EMAQICMIIBXAYDVR0RBIIBUzCCAU+CDW1zbS5taXRyZS5v
cmeCDm92YWwubWl0cmUub3Jngg9jYXBlYy5taXRyZS5vcmeCDWNwZS5taXRyZS5v
cmeCH3JlY29tbWVuZGF0aW9udHJhY2tlci5taXRyZS5vcmeCDGJlLm1pdHJlLm9y
Z4IOb2NybC5taXRyZS5vcmeCDWNtZS5taXRyZS5vcmeCDnN0aXgubWl0cmUub3Jn
gh5iZW5jaG1hcmtkZXZlbG9wbWVudC5taXRyZS5vcmeCDWNlZS5taXRyZS5vcmeC
DWN3ZS5taXRyZS5vcmeCDWNjZS5taXRyZS5vcmeCE2JlbmNobWFyay5taXRyZS5v
cmeCD3RheGlpLm1pdHJlLm9yZ4IObWFlYy5taXRyZS5vcmeCDWNyZi5taXRyZS5v
cmeCD2N5Ym94Lm1pdHJlLm9yZ4INY3ZlLm1pdHJlLm9yZzAfBgNVHSMEGDAWgBQe
8auJBvhJDwEzd+4Ueu4ZfJMoTTAdBgNVHQ4EFgQUJ82NEIJBFe+UxCeL9o+VxIq3
Za8wCQYDVR0TBAIwADANBgkqhkiG9w0BAQUFAAOCAQEAKZ0wed0DChKXWIBCORJe
nEWomevUXQoAxJ5VLg4rldtw+lWTU46Vpr9v2ojrxYP6+kcoJda7wIshQ6n+0LVK
+LHCt1L1pQVNHQ9uGmS5dZZseQruCrK9e2FXCQxhTMQc/IQkBW2oVu/7R9jk5B+9
ZiCAUetz0MxJdgNNA9ND81zodTRNnrB8eIUalgEn31Gc0Ut7dbBDvuNpu+DwalWs
+St5aqFMa9XIKoxZ3C5BNo/lkU0lGP4fx/IQSFqQxsZpSAvH367aG57zhYJEdhwg
EWWBU/vvza2r5zMmW0TIbOOahY5uQvBNw6/19XLnfdNONqw9GeoR1yNw8AO+gRdv
9g==
-END CERTIFICATE-
subject=/C=US/ST=Virginia/L=McLean/O=The Mitre Coproration/CN=msm.mitre.org
issuer=/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by 
reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
---
No client certificate CA names sent
---
SSL handshake has read 5688 bytes and written 623 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher: AES256-GCM-SHA384
Session-ID: 1CE5751D9B59229F85736A94BF1A7B74B1782F5FB5A8697332616A52F816CE9C
Session-ID-ctx: 
Master-Key: 

Bug#775420: aircrack-ng: Airodump-ng won't start

[Carlos Alberto Lopez Perez]

On 16/01/15 13:07, Viktor Petrášek wrote:
 Hey,
 
 I tried the rmmod wl  modprobe wl. It just removes my PCI wifi, but the
 USB adapter remains visible
 After that I still get the same error when running airmon-ng
 
 I didn't find a way to kill the network-manager. When I run sudo services
 network-manager stop, it just restarts
 
 Viktor
 

Try with this:

sudo systemctl stop NetworkManager.service



signature.asc
Description: OpenPGP digital signature

Bug#775420: aircrack-ng: Airodump-ng won't start

[Carlos Alberto Lopez Perez]

On 15/01/15 19:13, Viktor Petrášek wrote:
 *1) service network-manager stop* makes network manager stop, but it
 starts back again as if it was restart
  so I wasn't able to test it without nm running
 
 *2) airmon-zc*
 
  viktor@jessie:~$ sudo airmon-zc start wlan1

NetworkManager can cause lot of interference with aircrack-ng.
I recommend you to find a way to kill it. And then retry the tests.
If you are using systemd as init (the Default in Jessie), look at how to
stop services with it.

Also, try with airmon-zc (instead of airmon-ng) after a fresh reboot and
after killing network manager.



 *4) proprietary driver*
 Yes it is a proprietary driver. It is from packge firmware-realtek.
 Unfortunately, I am a kind of a noob, so I don't know how to remove
 it from the kernel.

Try removing it with this:

sudo rmmod wl

To add it back:

sudo modprobe wl


(No need to reboot, this adds or removes the driver only temporally)



signature.asc
Description: OpenPGP digital signature

Bug#775420: aircrack-ng: Airodump-ng won't start

[Carlos Alberto Lopez Perez]

Control: retitle -1 airmon-ng/airodump-ng: ioctl(SIOCSIFFLAGS) failed: Name not 
unique on network
Thanks.


Hi,


I'm not sure if this is a bug on aircrack-ng, on your kernel or driver of your 
wireless card,
or on your specific network or system configurations.

After grepping the kernel, it seems to me that the error ENOTUNIQ (Name not 
unique on network)
happens when you try to create some interface with a duplicate MAC address and
one of this interfaces is not in monitor mode.

The interface mon0 is going to have the same MAC than the parent (wlan1), so
either one of mon0 or wlan1 has to be in monitor mode.

The interface that airmon-ng enables on mon0 should be a interface of type
NL80211_IFTYPE_MONITOR, so it shouldn't give ENOTUNIQ error.

You say that it works if you manually first put wlan1 in monitor mode.
So that matchs my understanding of the situation.
Seems that for some reason (read:bug) the interface mon0 is not beeing
created in monitor mode mode by default.


Can you try the following:


1) First stop NetworkManager

$ service network-manager stop

And retry creating mon0 with airmon-ng.

If it still fails with the same error.

2) Try using airmon-zc instead of airmon-ng to bring the interface up:

$ sudo airmon-zc start wlan0

3) If it still fails, try creating the mon0 interface manually:

sudo iw dev wlan1 interface add mon0 type monitor

4) You are running a propietary driver (wl) for the interface wlan0.
This may cause problems. Can you try to temporally remove this driver
from your kenel and booting without it, to check if that makes a difference ?

5)

If all the above fails, can you please paste here the output
of the following commands (after the error has happened):

/sbin/iw list
/sbin/iw dev
/sbin/ip addr
/sbin/ifconfig -a


Regards!



signature.asc
Description: OpenPGP digital signature

Bug#774163: root-system: diff for NMU version 5.34.19+dfsg-1.2

[Carlos Alberto Lopez Perez]

On 16/01/15 01:12, Sebastian Ramacher wrote:
 Control: tags 774163 + patch
 Control: tags 774163 + pending
 
 Dear maintainer,
 
 I've prepared an NMU for root-system (versioned as 5.34.19+dfsg-1.2) and
 uploaded it to DELAYED/2. Please feel free to tell me if I
 should delay it longer.
 
 Cheers
 


 diff -Nru root-system-5.34.19+dfsg/debian/changelog 
 root-system-5.34.19+dfsg/debian/changelog
 --- root-system-5.34.19+dfsg/debian/changelog 2014-10-24 13:44:02.0 
 +0200
 +++ root-system-5.34.19+dfsg/debian/changelog 2015-01-16 00:43:59.0 
 +0100
 @@ -1,3 +1,12 @@
 +root-system (5.34.19+dfsg-1.2) unstable; urgency=medium
 +
 +  * Non-maintainer upload.
 +  * debian/control: Make ttf-root-installer depend on ca-certificates.
 +Certificates need to be available for postint configure to work.
 +(Closes: #774163)
 +
 + -- Sebastian Ramacher sramac...@debian.org  Fri, 16 Jan 2015 00:43:11 
 +0100
 +


Interesting...

When I reported the bug the CA signing the certificate for https://root.cern.ch
was a custom one (kind of self-signed: (CERN Grid Certification Authority)).

Now is signed by COMODO. I guess somebody told them to use a proper CA.

Indeed... https://root.cern.ch/phpBB3/viewtopic.php?f=7t=18818

Regards!



signature.asc
Description: OpenPGP digital signature

Bug#760552: PyAssertionError bitmap.GetWidth prevents startup

[Carlos Alberto Lopez Perez]

Hi,


Just installed tribler on debian testing, and I'm running it without
problems.

So far I didn't hit the bug that is reported here.



signature.asc
Description: OpenPGP digital signature

Bug#656096: dante-client: socksify preloads libdl.so.2 from an incorrect path

[Carlos Alberto Lopez Perez]

Control: severity -1 grave
Justification: Makes the package unusable, therefore not suitable for release.
Thanks


Hi,


I was trying this software for the first time, as recommended on the tor 
documentation [1] as a best alternative to tsocks.

Unfortunately this bugs makes this package completely unusable.



$ socksify curl http://www.debian.org
ERROR: ld.so: object '/lib/libdl.so.2' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
$ echo $?
1

Upon enabling debug at /etc/dante.conf

$ socksify curl http://www.debian.org
ERROR: ld.so: object '/lib/libdl.so.2' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
Dec 30 15:58:31 (1419951511) curl[28155]: symbolfunction(): compiletime 
configuration error?  Failed to open libc.so: 
/usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header
$ echo $?
1


A quick search reveals that this bug may have been fixed (at least parcially) 
on Ubuntu (you may want to pick their patches)
https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153

Also Debian bug https://bugs.debian.org/731178 may be related.


Regards!

[1] 
https://trac.torproject.org/projects/tor/wiki/doc/SupportPrograms#AboutDNSandtsocks



signature.asc
Description: OpenPGP digital signature

Bug#774163: Unable to upgrade or install ttf-root-installer (dpkg: error processing package) because of invalid certificate on root.cern.ch

[Carlos Alberto Lopez Perez]

Package: ttf-root-installer
Version: 5.34.19+dfsg-1.1
Severity: grave


Hi, when upgrading my system ttf-root-installer
broke the upgrade because its configure script failed.

I tried to purge it completely and install it again,
unfortunately it broke again:

$ sudo apt-get install ttf-root-installer
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following NEW packages will be installed:
  ttf-root-installer
0 upgraded, 1 newly installed, 0 to remove and 633 not upgraded.
Need to get 28.1 kB of archives.
After this operation, 91.1 kB of additional disk space will be used.
Get:1 http://mirror.ovh.net/debian/ sid/contrib ttf-root-installer all 
5.34.19+dfsg-1.1 [28.1 kB]
Fetched 28.1 kB in 0s (135 kB/s)  
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Preconfiguring packages ...
Selecting previously unselected package ttf-root-installer.
(Reading database ... 572464 files and directories currently installed.)
Preparing to unpack .../ttf-root-installer_5.34.19+dfsg-1.1_all.deb ...
Unpacking ttf-root-installer (5.34.19+dfsg-1.1) ...
Setting up ttf-root-installer (5.34.19+dfsg-1.1) ...
dpkg: error processing package ttf-root-installer (--configure):
 subprocess installed post-installation script returned error exit status 5
Errors were encountered while processing:
 ttf-root-installer
E: Sub-process /usr/bin/dpkg returned an error code (1)



Upon furter investigation :


$ sudo DEBCONF_DEBUG=developer dpkg -D777 --configure ttf-root-installer
D01: ensure_diversions: new, (re)loading
D01: process queue pkg ttf-root-installer:all queue.len 0 progress 1, try 1
D40: checking dependencies of ttf-root-installer:all (- none)
D000400:   checking group ...
D000400: checking possibility  - debconf
D000400:   checking non-provided pkg debconf:all
D000400:   is installed, ok and found
D000400: found 3
D000400:   found 3 matched 0 possfixbytrig -
D000400:   checking group ...
D000400: checking possibility  - wget
D000400:   checking non-provided pkg wget:amd64
D000400:   is installed, ok and found
D000400: found 3
D000400:   found 3 matched 0 possfixbytrig -
D000400:   checking group ...
D000400: checking possibility  - xfonts-utils
D000400:   checking non-provided pkg xfonts-utils:amd64
D000400:   is installed, ok and found
D000400: found 3
D000400:   found 3 matched 0 possfixbytrig -
D40: ok 2 msgs 
D40: checking Breaks
D000400:  checking virtbroken root-ttf
Setting up ttf-root-installer (5.34.19+dfsg-1.1) ...
D02: fork/exec /var/lib/dpkg/info/ttf-root-installer.postinst ( configure  )
debconf (developer): frontend started
debconf (developer): frontend running, package name is ttf-root-installer
debconf (developer): starting /var/lib/dpkg/info/ttf-root-installer.config 
configure 
debconf (developer): -- TITLE ROOT TTF Installer
debconf (developer): -- 0
debconf (developer): -- INPUT high ttf-root-installer/blurb
debconf (developer): -- 30 question skipped
debconf (developer): -- INPUT high ttf-root-installer/dldir
debconf (developer): -- 30 question skipped
debconf (developer): -- GO 
debconf (developer): -- 0 ok
debconf (developer): -- GET ttf-root-installer/dldir
debconf (developer): -- 0 
debconf (developer): -- INPUT high ttf-root-installer/savedir
debconf (developer): -- 30 question skipped
debconf (developer): -- GO 
debconf (developer): -- 0 ok
debconf (developer): -- GET ttf-root-installer/savedir
debconf (developer): -- 0 
debconf (developer): starting /var/lib/dpkg/info/ttf-root-installer.postinst 
configure 
+ archive=ttf_fonts.tar.gz
+ db_get ttf-root-installer/dldir
+ _db_cmd GET ttf-root-installer/dldir
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n GET ttf-root-installer/dldir
+ IFS=  

+ IFS=
 read -r _db_internal_line
debconf (developer): -- GET ttf-root-installer/dldir
debconf (developer): -- 0 
+ RET=
+ return 0
+ LOCALCOPY=
+ db_get ttf-root-installer/savedir
+ _db_cmd GET ttf-root-installer/savedir
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n GET ttf-root-installer/savedir
+ debconf (developer): -- GET ttf-root-installer/savedir
IFS=

+ IFS=
 read -r _db_internal_line
debconf (developer): -- 0 
+ RET=
+ return 0
+ SAVEDIR=
+ test ! -f /var/cache/ttf-root-installer
+ echo
+ tr [:upper:] [:lower:]
+ test x != xnone
+ pwd
+ savdir=/
+ mktemp -d
+ tmpdir=/tmp/tmp.LG7ux68bWG
+ cd /tmp/tmp.LG7ux68bWG
+ test -z
+ wget --continue --tries=1 --dns-timeout=20 --connect-timeout=20 
--read-timeout=300 -q --directory-prefix . -c 
http://root.cern.ch/download/ttf/ttf_fonts.tar.gz
dpkg: error processing package ttf-root-installer (--configure):
 subprocess installed post-installation script returned error exit status 5
D01: ensure_diversions: same, skipping
Errors were encountered while processing:
 ttf-root-installer


Trying to reproduce it manually:

$ wget --continue --tries=1 --dns-timeout=20 --connect-timeout=20 

Bug#774163: Unable to upgrade or install ttf-root-installer (dpkg: error processing package) because of invalid certificate on root.cern.ch

[Carlos Alberto Lopez Perez]

Seems on the past there were also problems with this file served via
ftp. https://bugs.launchpad.net/ubuntu/+source/root-system/+bug/349860



signature.asc
Description: OpenPGP digital signature

Bug#686447: [Pkg-zfsonlinux-devel] Summary of ZFS on Linux for Debian

[Carlos Alberto Lopez Perez]

Hi Lucas,

It has been already 3 months since you requested ftp-masters to ACK the
mail quoted below.

I have already requested several times on the IRC (#debian-ftp) to the
ftp-team to ACK your mail, and they ignored my requests.

I think that 3 months of waiting for an ACK is more than enough.

At this point, I kindly ask you to pass our mail regarding the license
issues about ZoL to the SFLC lawyer in the next couple of days if you
don't get an ACK or a reply from ftp-masters about this issue.

Thanks.

On 31/08/14 01:28, Lucas Nussbaum wrote:
 Hi,
 
 On 29/08/14 at 09:42 +0800, Aron Xu wrote:
 Dear DPL and FTP Masters,

 As agreed at DebConf 14, Debian ZFS on Linux Maintainers have concluded
 into the following summary for the situation, please see as follows.
 
 Thanks a lot for this work.
 
 I think that adding an actual question to our legal counsel would help
 focus their work. If I understand correctly, that question should be:
 Does this summary accurately represents your understanding of the
 question?
 Can Debian distribute a ZoL package using (1) Source code and (2)
 Binary Linux LKM?
 
 In any case, I'll wait for comments or ACK from ftpmasters before
 forwarding your mail to SFLC.
 
 Lucas
 
 
 
 ___
 Pkg-zfsonlinux-devel mailing list
 pkg-zfsonlinux-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
 






signature.asc
Description: OpenPGP digital signature

Bug#771257: pre-approval unblock: aircrack-ng/1:1.2-0~beta3-4

[Carlos Alberto Lopez Perez]

Control: tags -1 - moreinfo
On 28/11/14 08:55, Adam D. Barratt wrote:
 Control: tags -1 + confirmed moreinfo
 
 On 2014-11-28 0:21, Carlos Alberto Lopez Perez wrote:
 Please grant a pre-approval unblock for the debdiff attached here for
 the package aircrack-ng.

 This fixes bug #771221 which makes airodump-ng unable to access the IEEE
 OUI database to show the information about the manufacturers.
 
 Please go ahead, and remove the moreinfo tag once the package is in
 unstable.
 
 Regards,
 
 Adam
 

I have uploaded it, and the package has been accepted in unstable
(but not yet installed into the pool, is still at incoming.debian.org)


Please unblock aircrack-ng/1:1.2-0~beta3-4


Thanks!



signature.asc
Description: OpenPGP digital signature

Bug#771221: airodump-ng can't find the OUI file. it lists all MACs as unknown.

[Carlos Alberto Lopez Perez]

Package: aircrack-ng
Version: 1:1.2-0~beta3-3
Severity: important


airodump-ng needs to access to the IEEE OUI database to get the
information that correlates a given MAC with a manufacturer.

$ airodump-ng --manufacturer ...

On Debian systems, this database is provided by the package ieee-data.

The package ieee-data changed the path of the database on version =
20140927.1 (because of #763018).

This have rendered airodump-ng unable to find the file, therefore it
shows all MACs as unknown.


This has been fixed on http://trac.aircrack-ng.org/changeset/2455



signature.asc
Description: OpenPGP digital signature

Bug#771257: pre-approval unblock: aircrack-ng/1:1.2-0~beta3-4

[Carlos Alberto Lopez Perez]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Hi,

Please grant a pre-approval unblock for the debdiff attached here for
the package aircrack-ng.

This fixes bug #771221 which makes airodump-ng unable to access the IEEE
OUI database to show the information about the manufacturers.

Although the upstream fix re-factorizes the code to look for the OUI
file, I have done here only the minimum changes to fix this issue.

The changes only involve updating 2 defines on airodump-ng.h to match
the paths that the package ieee-data uses now.

Thanks.

Please pre-approval unblock aircrack-ng/1:1.2-0~beta3-4
diff -Nru aircrack-ng-1.2-0~beta3/debian/changelog 
aircrack-ng-1.2-0~beta3/debian/changelog
--- aircrack-ng-1.2-0~beta3/debian/changelog2014-11-12 18:25:47.0 
+0100
+++ aircrack-ng-1.2-0~beta3/debian/changelog2014-11-28 00:56:39.0 
+0100
@@ -1,3 +1,11 @@
+aircrack-ng (1:1.2-0~beta3-4) unstable; urgency=medium
+
+  * Update the paths for the IEEE OUI file on airodump-ng
+to match the ones used now by the package ieee-data.
+(Closes: #771221)
+
+ -- Carlos Alberto Lopez Perez clo...@igalia.com  Fri, 28 Nov 2014 00:48:06 
+0100
+
 aircrack-ng (1:1.2-0~beta3-3) unstable; urgency=high
 
   * Remove useless dh-python from Build-Depends. Check #769285.
diff -Nru 
aircrack-ng-1.2-0~beta3/debian/patches/008-Airodump_fix-ieee-oui-path.diff 
aircrack-ng-1.2-0~beta3/debian/patches/008-Airodump_fix-ieee-oui-path.diff
--- aircrack-ng-1.2-0~beta3/debian/patches/008-Airodump_fix-ieee-oui-path.diff  
1970-01-01 01:00:00.0 +0100
+++ aircrack-ng-1.2-0~beta3/debian/patches/008-Airodump_fix-ieee-oui-path.diff  
2014-11-27 19:51:54.0 +0100
@@ -0,0 +1,22 @@
+Description: airodump-ng can't find the IEE OUI file.
+ We are doing here the minium changes to keep release team
+ happy and have this allowed into Jessie.
+ .
+ Next upstream release of aircrack-ng will already contain
+ r2455, so this patch can be dropped.
+Author: Carlos Alberto Lopez Perez clo...@igalia.com
+Bug-Debian: http://bugs.debian.org/771221
+Applied-Upstream: http://trac.aircrack-ng.org/changeset/2455
+--- a/src/airodump-ng.h
 b/src/airodump-ng.h
+@@ -146,8 +146,8 @@
+ 
+ #define OUI_PATH0 /etc/aircrack-ng/airodump-ng-oui.txt
+ #define OUI_PATH1 /usr/local/etc/aircrack-ng/airodump-ng-oui.txt
+-#define OUI_PATH2 /usr/share/aircrack-ng/airodump-ng-oui.txt
+-#define OUI_PATH3 /usr/share/misc/oui.txt
++#define OUI_PATH2 /var/lib/ieee-data/oui.txt
++#define OUI_PATH3 /usr/share/ieee-data/oui.txt
+ #define MIN_RAM_SIZE_LOAD_OUI_RAM 32768
+ 
+ int read_pkts=0;
diff -Nru aircrack-ng-1.2-0~beta3/debian/patches/series 
aircrack-ng-1.2-0~beta3/debian/patches/series
--- aircrack-ng-1.2-0~beta3/debian/patches/series   2014-11-11 
23:59:00.0 +0100
+++ aircrack-ng-1.2-0~beta3/debian/patches/series   2014-11-28 
01:12:23.0 +0100
@@ -6,3 +6,4 @@
 005-CVE-2014-8322.diff
 006-CVE-2014-8323.diff
 007-CVE-2014-8324.diff
+008-Airodump_fix-ieee-oui-path.diff


signature.asc
Description: OpenPGP digital signature

Bug#769285: unblock aircrack-ng/1:1.2-0~beta3-2

[Carlos Alberto Lopez Perez]

Subject: unblock: aircrack-ng/1:1.2-0~beta3-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: important
X-Debbugs-CC: car...@debian.org


Please unblock package aircrack-ng

It fixes 4 security vulnerabilities. (#767979)

https://security-tracker.debian.org/tracker/CVE-2014-8321
https://security-tracker.debian.org/tracker/CVE-2014-8322
https://security-tracker.debian.org/tracker/CVE-2014-8323
https://security-tracker.debian.org/tracker/CVE-2014-8324

Attached is the debdiff against the package in testing.


unblock aircrack-ng/1:1.2-0~beta3-2
diff -Nru aircrack-ng-1.2-0~beta3/debian/changelog 
aircrack-ng-1.2-0~beta3/debian/changelog
--- aircrack-ng-1.2-0~beta3/debian/changelog2014-05-30 19:40:13.0 
+0200
+++ aircrack-ng-1.2-0~beta3/debian/changelog2014-11-12 00:16:47.0 
+0100
@@ -1,3 +1,14 @@
+aircrack-ng (1:1.2-0~beta3-2) unstable; urgency=high
+
+  * Fix the following security vulnerabilities: (Closes: #767979)
+* CVE-2014-8321 - GPS stack overflow.
+* CVE-2014-8322 - tcp_test stack overflow.
+* CVE-2014-8323 - buddy-ng missing checkin data format.
+* CVE-2014-8324 - net_get missing check for invalid values.
+  * Add missing dh-python package to Build-Depends.
+
+ -- Carlos Alberto Lopez Perez clo...@igalia.com  Tue, 11 Nov 2014 23:41:52 
+0100
+
 aircrack-ng (1:1.2-0~beta3-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru aircrack-ng-1.2-0~beta3/debian/control 
aircrack-ng-1.2-0~beta3/debian/control
--- aircrack-ng-1.2-0~beta3/debian/control  2014-05-30 18:39:20.0 
+0200
+++ aircrack-ng-1.2-0~beta3/debian/control  2014-11-12 00:15:54.0 
+0100
@@ -5,6 +5,7 @@
 Homepage: http://www.aircrack-ng.org/
 Build-Depends:
  debhelper (= 9),
+ dh-python,
  libgcrypt20-dev | libgcrypt11-dev,
  libnl-genl-3-dev [linux-any],
  libpcap0.8-dev,
diff -Nru aircrack-ng-1.2-0~beta3/debian/patches/004-CVE-2014-8321.diff 
aircrack-ng-1.2-0~beta3/debian/patches/004-CVE-2014-8321.diff
--- aircrack-ng-1.2-0~beta3/debian/patches/004-CVE-2014-8321.diff   
1970-01-01 01:00:00.0 +0100
+++ aircrack-ng-1.2-0~beta3/debian/patches/004-CVE-2014-8321.diff   
2014-11-11 23:52:09.0 +0100
@@ -0,0 +1,26 @@
+From ff70494dd389ba570dbdbf36f217c28d4381c6b5 Mon Sep 17 00:00:00 2001
+From: Thomas d'Otreppe tdotre...@aircrack-ng.org
+Date: Fri, 3 Oct 2014 01:51:21 +
+Subject: [PATCH] Airodump-ng: Fixed GPS stack overflow (Closes #13 on GitHub).
+
+git-svn-id: http://svn.aircrack-ng.org/trunk@2416 
28c6078b-6c39-48e3-add9-af49d547ecab
+---
+ src/airodump-ng.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/airodump-ng.c b/src/airodump-ng.c
+index 6cec912..222492c 100644
+--- a/src/airodump-ng.c
 b/src/airodump-ng.c
+@@ -4497,7 +4497,7 @@ void gps_tracker( void )
+   }
+ 
+   // New version, JSON
+-  if( recv( gpsd_sock, line + pos, sizeof( line ) - 1, 0 ) = 0 )
++  if( recv( gpsd_sock, line + pos, sizeof( line ) - pos - 1, 0 ) 
= 0 )
+   return;
+ 
+   // search for TPV class: {class:TPV
+-- 
+2.0.0.rc2
+
diff -Nru aircrack-ng-1.2-0~beta3/debian/patches/005-CVE-2014-8322.diff 
aircrack-ng-1.2-0~beta3/debian/patches/005-CVE-2014-8322.diff
--- aircrack-ng-1.2-0~beta3/debian/patches/005-CVE-2014-8322.diff   
1970-01-01 01:00:00.0 +0100
+++ aircrack-ng-1.2-0~beta3/debian/patches/005-CVE-2014-8322.diff   
2014-11-11 23:52:57.0 +0100
@@ -0,0 +1,27 @@
+From 091b153f294b9b695b0b2831e65936438b550d7b Mon Sep 17 00:00:00 2001
+From: Thomas d'Otreppe tdotre...@aircrack-ng.org
+Date: Fri, 3 Oct 2014 01:53:50 +
+Subject: [PATCH] Aireplay-ng: Fixed tcp_test stack overflow (Closes #14 on
+ GitHub).
+
+git-svn-id: http://svn.aircrack-ng.org/trunk@2417 
28c6078b-6c39-48e3-add9-af49d547ecab
+---
+ src/aireplay-ng.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/aireplay-ng.c b/src/aireplay-ng.c
+index 7335442..b397015 100644
+--- a/src/aireplay-ng.c
 b/src/aireplay-ng.c
+@@ -5398,6 +5398,8 @@ int tcp_test(const char* ip_str, const short port)
+ if( (unsigned)caplen == sizeof(nh))
+ {
+ len = ntohl(nh.nh_len);
++if (len  1024 || len  0)
++continue;
+ if( nh.nh_type == 1  i==0 )
+ {
+ i=1;
+-- 
+2.0.0.rc2
+
diff -Nru aircrack-ng-1.2-0~beta3/debian/patches/006-CVE-2014-8323.diff 
aircrack-ng-1.2-0~beta3/debian/patches/006-CVE-2014-8323.diff
--- aircrack-ng-1.2-0~beta3/debian/patches/006-CVE-2014-8323.diff   
1970-01-01 01:00:00.0 +0100
+++ aircrack-ng-1.2-0~beta3/debian/patches/006-CVE-2014-8323.diff   
2014-11-11 23:53:42.0 +0100
@@ -0,0 +1,26 @@
+From da087238963c1239fdabd47dc1b65279605aca70 Mon Sep 17 00:00:00 2001
+From: Thomas d'Otreppe tdotre...@aircrack-ng.org
+Date: Fri, 3 Oct 2014 01:58:02 +
+Subject: [PATCH] Buddy-ng: Fixed

Bug#769285: unblock aircrack-ng/1:1.2-0~beta3-2

[Carlos Alberto Lopez Perez]

On 12/11/14 14:09, Cyril Brulebois wrote:
 Control: tag -1 moreinfo
 
 Hi,
 
 Carlos Alberto Lopez Perez clo...@igalia.com (2014-11-12):
 +aircrack-ng (1:1.2-0~beta3-2) unstable; urgency=high
 +
 +  * Fix the following security vulnerabilities: (Closes: #767979)
 +* CVE-2014-8321 - GPS stack overflow.
 +* CVE-2014-8322 - tcp_test stack overflow.
 +* CVE-2014-8323 - buddy-ng missing checkin data format.
 +* CVE-2014-8324 - net_get missing check for invalid values.
 +  * Add missing dh-python package to Build-Depends.
 
 The freeze policy[1] warmly recommends documenting changes verbosely.
 What were the consequences of the missing dh-python build-dep? Previous
 uploads don't seem to have FTBFS'd; missing functionalities in the
 resulting binary packages, missing dependencies, some other things?
 
  1. https://release.debian.org/jessie/freeze_policy.html
 

I noticed this because when building the new version of the package on a
fresh jessie chroot (with pdebuild) this showed on the log:

make[1]: Leaving directory '/tmp/buildd/aircrack-ng-1.2-0~beta3'
   dh_installdocs
   dh_installchangelogs
   dh_installexamples
   dh_installman
   dh_python2
W: dh_python2:479: Please add dh-python package to Build-Depends
   dh_perl
   dh_link
   dh_compress
   dh_fixperms
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   dh_gencontrol
[...]

So I added it.

Investigating a bit more, this was introduced by:
https://alioth.debian.org/scm/loggerhead/pkg-python/python-defaults-debian/revision/401

There is no difference at all on the binary packages produced.
I compared the debs produced with this build-dep and without it, they
are identical.



signature.asc
Description: OpenPGP digital signature

Bug#769285: unblock aircrack-ng/1:1.2-0~beta3-2

[Carlos Alberto Lopez Perez]

retitle 769285 unblock aircrack-ng/1:1.2-0~beta3-3
thanks

On 12/11/14 17:38, Julien Cristau wrote:
 On Wed, Nov 12, 2014 at 14:30:22 +0100, Carlos Alberto Lopez Perez wrote:
 
 Investigating a bit more, this was introduced by:
 https://alioth.debian.org/scm/loggerhead/pkg-python/python-defaults-debian/revision/401

 There is no difference at all on the binary packages produced.
 I compared the debs produced with this build-dep and without it, they
 are identical.

 Sounds like a bug to me.  The only python file you seem to ship is in
 /usr/share/doc as an example.  Please revert the useless build-dep.
 
 Cheers,
 Julien
 

I have just uploaded 1:1.2-0~beta3-3 reverting that build-dep as requested.

I'm attaching the debdiff against the package in testing.


Please unblock aircrack-ng/1:1.2-0~beta3-3
diff -Nru aircrack-ng-1.2-0~beta3/debian/changelog 
aircrack-ng-1.2-0~beta3/debian/changelog
--- aircrack-ng-1.2-0~beta3/debian/changelog2014-05-30 19:40:13.0 
+0200
+++ aircrack-ng-1.2-0~beta3/debian/changelog2014-11-12 18:25:47.0 
+0100
@@ -1,3 +1,20 @@
+aircrack-ng (1:1.2-0~beta3-3) unstable; urgency=high
+
+  * Remove useless dh-python from Build-Depends. Check #769285.
+
+ -- Carlos Alberto Lopez Perez clo...@igalia.com  Wed, 12 Nov 2014 17:42:10 
+0100
+
+aircrack-ng (1:1.2-0~beta3-2) unstable; urgency=high
+
+  * Fix the following security vulnerabilities: (Closes: #767979)
+* CVE-2014-8321 - GPS stack overflow.
+* CVE-2014-8322 - tcp_test stack overflow.
+* CVE-2014-8323 - buddy-ng missing checkin data format.
+* CVE-2014-8324 - net_get missing check for invalid values.
+  * Add missing dh-python package to Build-Depends.
+
+ -- Carlos Alberto Lopez Perez clo...@igalia.com  Tue, 11 Nov 2014 23:41:52 
+0100
+
 aircrack-ng (1:1.2-0~beta3-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru aircrack-ng-1.2-0~beta3/debian/patches/004-CVE-2014-8321.diff 
aircrack-ng-1.2-0~beta3/debian/patches/004-CVE-2014-8321.diff
--- aircrack-ng-1.2-0~beta3/debian/patches/004-CVE-2014-8321.diff   
1970-01-01 01:00:00.0 +0100
+++ aircrack-ng-1.2-0~beta3/debian/patches/004-CVE-2014-8321.diff   
2014-11-11 23:52:09.0 +0100
@@ -0,0 +1,26 @@
+From ff70494dd389ba570dbdbf36f217c28d4381c6b5 Mon Sep 17 00:00:00 2001
+From: Thomas d'Otreppe tdotre...@aircrack-ng.org
+Date: Fri, 3 Oct 2014 01:51:21 +
+Subject: [PATCH] Airodump-ng: Fixed GPS stack overflow (Closes #13 on GitHub).
+
+git-svn-id: http://svn.aircrack-ng.org/trunk@2416 
28c6078b-6c39-48e3-add9-af49d547ecab
+---
+ src/airodump-ng.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/airodump-ng.c b/src/airodump-ng.c
+index 6cec912..222492c 100644
+--- a/src/airodump-ng.c
 b/src/airodump-ng.c
+@@ -4497,7 +4497,7 @@ void gps_tracker( void )
+   }
+ 
+   // New version, JSON
+-  if( recv( gpsd_sock, line + pos, sizeof( line ) - 1, 0 ) = 0 )
++  if( recv( gpsd_sock, line + pos, sizeof( line ) - pos - 1, 0 ) 
= 0 )
+   return;
+ 
+   // search for TPV class: {class:TPV
+-- 
+2.0.0.rc2
+
diff -Nru aircrack-ng-1.2-0~beta3/debian/patches/005-CVE-2014-8322.diff 
aircrack-ng-1.2-0~beta3/debian/patches/005-CVE-2014-8322.diff
--- aircrack-ng-1.2-0~beta3/debian/patches/005-CVE-2014-8322.diff   
1970-01-01 01:00:00.0 +0100
+++ aircrack-ng-1.2-0~beta3/debian/patches/005-CVE-2014-8322.diff   
2014-11-11 23:52:57.0 +0100
@@ -0,0 +1,27 @@
+From 091b153f294b9b695b0b2831e65936438b550d7b Mon Sep 17 00:00:00 2001
+From: Thomas d'Otreppe tdotre...@aircrack-ng.org
+Date: Fri, 3 Oct 2014 01:53:50 +
+Subject: [PATCH] Aireplay-ng: Fixed tcp_test stack overflow (Closes #14 on
+ GitHub).
+
+git-svn-id: http://svn.aircrack-ng.org/trunk@2417 
28c6078b-6c39-48e3-add9-af49d547ecab
+---
+ src/aireplay-ng.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/aireplay-ng.c b/src/aireplay-ng.c
+index 7335442..b397015 100644
+--- a/src/aireplay-ng.c
 b/src/aireplay-ng.c
+@@ -5398,6 +5398,8 @@ int tcp_test(const char* ip_str, const short port)
+ if( (unsigned)caplen == sizeof(nh))
+ {
+ len = ntohl(nh.nh_len);
++if (len  1024 || len  0)
++continue;
+ if( nh.nh_type == 1  i==0 )
+ {
+ i=1;
+-- 
+2.0.0.rc2
+
diff -Nru aircrack-ng-1.2-0~beta3/debian/patches/006-CVE-2014-8323.diff 
aircrack-ng-1.2-0~beta3/debian/patches/006-CVE-2014-8323.diff
--- aircrack-ng-1.2-0~beta3/debian/patches/006-CVE-2014-8323.diff   
1970-01-01 01:00:00.0 +0100
+++ aircrack-ng-1.2-0~beta3/debian/patches/006-CVE-2014-8323.diff   
2014-11-11 23:53:42.0 +0100
@@ -0,0 +1,26 @@
+From da087238963c1239fdabd47dc1b65279605aca70 Mon Sep 17 00:00:00 2001
+From: Thomas d'Otreppe tdotre...@aircrack-ng.org
+Date: Fri, 3 Oct 2014 01:58:02 +
+Subject: [PATCH] Buddy-ng: Fixed segmentation fault (Closes #15

Bug#744114: with-session-tracking=systemd vs with-session-tracking=consolekit

[Carlos Alberto Lopez Perez]

Probably those of you that don't want to install systemd but want a
working network manager would find this information useful:

* I rebuilt network-manager with the following patch:
http://paste.debian.net/plain/128994

* Also followed the following howto:
http://jeffhoogland.blogspot.com.es/2012/05/howto-give-network-manager-sufficient.html

After that I was able to successfully run network-manager without
systemd, libpam-systemd, logind or anythingd


I think the following upstream bug is relevant:
https://bugzilla.gnome.org/show_bug.cgi?id=686997



signature.asc
Description: OpenPGP digital signature

Bug#766073: [oss-security] Multiple disputed issues in util-vserver

[Carlos Alberto Lopez Perez]

On 14/10/14 16:31, Fiedler Roman wrote:
 Hi,
 
 While fixing a bug, I noticed some strange behavior in linux vserver
 virtualization, that I would call a security problems, but project
 developers see it differently. Since the util-vserver packages and patched
 kernel were or are included in some Linux distros, I would be interested in
 the communities' opinion on that.
 
 Issue 1: When calling util-vserver tool on the host to execute a job within
 the guest, e.g. to install updates, the host process (in host PID ns) might
 end up being the child of a guest process (with PID only in guest ns), thus
 the parent PID of the host process pointing to a guest ns PID. If the host
 process wants to signal the parent process or some other tool operates using
 the ppid, a host process might interact with another arbitrary host process
 on error (see [1]). Compared to issue 2-3, I'm not sure for myself if it is
 really a bug and what the correct behavior of kernel with pid namespaces
 would be. At least it breaks bash process handling (gets stuck) when calling
 vserver exec in a certain way, start-stop-daemon or upstart might not like
 it also.
 

Is there any (practical) scenario in which an attacker that has
compromised an vserver guest could use this behavior to compromise or
execute code on the host (master)?

 Issue 2: When entering the container from the host or executing commands
 within the container, e.g. to perform common administrative tasks, a
 malicious login shell inside the container might overwrite the
 /usr/sbin/vcontext on the host, thus allowing on to execute arbitrary code
 on the host with root privileges next time vcontext is invoked. See [3].
 Feedback from developer:  Yes, vlogin is known to have several security
 issues. It's a maintenance backdoor, much like the iLO or iDRAC on hardware.
 If you can find ways to improve it, patches would be accepted, but I doubt
 it will ever be possible to do what it does securely. Project documentation
 does not strike out those restrictions (or at least I did not find that or
 the list of several known security issues online), other sources, e.g.
 container vs system virtualization comparison strike out the importance of
 the feature to enter a guest from the host easily for maintenance, so I
 guess that those tools were not useful just for me alone. This issue I would
 rate a killer for production use, e.g. for mass hosting.
 

Can you please send me the PoC for this issue ?

 Issue 3: It seems that handling of open tty FDs on enter, that allows to
 inject arbitrary keyboard input to be read by the parent process, also
 affects the tool to start the guest container. This seems to be the same
 issue with vserver start as reported in [2] for vserver enter, which was
 classified as less relevant back than. My rating would be little lower than
 2 but still quite high for mass hosting: manual restart, e.g. during
 maintenance, seems quite common to me.
 

If I understand correctly, this (and the previous one) are
CVE-2005-4890, isn't it?.

http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation


 From my point of view, those issues might be expected behavior as claimed by
 the developers, but if so it should be at least stated more clearly in
 documentation:
 
 a) never use any tools except vserver stop (to terminate the container) to
 interact with a running and possibly compromised container from the host
 b) only use network/socket-based tools to connect to processes inside a
 possibly compromised guest, e.g. SSH. 
 c) never start a possibly compromised container from interactive shell to
 avoid injection of shell commands
 
 Regarding documentation I would even vote for a solution d), that all those
 tools get a mandatory argument like
 '--i-know-entering-insecure-container-may-kill-my-host' so that it is not
 very likely, that someone will use those tools for something else then
 testing or nice-world administration.
 
 Opinions to issues 1-3?
 
 What about solutions?
 

Halfdog (CC'ed) already suggested some possible solutions:
http://www.paul.sladen.org/vserver/archives/201211/0011.html

 Kind regards,
 Roman
 
 [1]
 http://list.linux-vserver.org/archive?mss:6788:201410:moeiomapkoefmmdnmcji
 [2] http://www.openwall.com/lists/oss-security/2012/11/05/8
 [3] Guest - Host escape POC: C-code to be put as /bin/bash replacement in
 guest, will overwrite /usr/sbin/vcontext on host. Available on request
 
 
 DI Roman Fiedler
 Scientist
 Safety  Security Department
 Assistive Healthcare Information Technology
 
 AIT Austrian Institute of Technology GmbH
 Reininghausstraße 13/1  |  8020 Graz  |  Austria
 T +43(0) 50550 2957  |  M +43(0) 664 8561599  |  F +43(0) 50550 2950
 roman.fied...@ait.ac.at | http://www.ait.ac.at/
 
 FN: 115980 i HG Wien  |  UID: ATU14703506
 http://www.ait.ac.at/Email-Disclaimer
 



signature.asc
Description: OpenPGP digital signature

Bug#748867: [Pkg-chromium-maint] Bug#748867: patch: Let's fix this by adding APIKEY

[Carlos Alberto Lopez Perez]

On 19/10/14 12:11, Martin Steigerwald wrote:
 Am Samstag, 18. Oktober 2014, 19:06:33 schrieb Michael Gilbert:
 control: severity -1 important

 On Sat, Oct 18, 2014 at 5:12 AM, Osamu Aoki wrote:
 At least adding this key fixed my system.  (I have removed old
 ~/.chromium directory before adding the API key.  If removal of this is
 required for upgrade, please consider adding entry to  debian/NEWS)

 That patch, of course as simple as it is, looks ok, almost.  Like I
 said my plan is to put it in a separate chromium-apikeys package.

 I'll have time to work on that tomorrow.  Those interested can then
 press ftp masters for a quick review.
 
 Honestly I am starting to wonder… when does Chromium use Google APIs and 
 exactly *why* do Chromium developers *insist* with a nagging warning to have 
 API key installed? What user behaviour tracking abilities does it give to 
 Google? And did I really disable all privacy harming features in it already?
 

The following article contains some useful information about this:

Chromium API keys on Debian -- http://lwn.net/Articles/570485/



signature.asc
Description: OpenPGP digital signature

Bug#732054: good idea

[Carlos Alberto Lopez Perez]

On 08/10/14 23:24, Chad Seys wrote:
 Hi Martin,
   You might also be interested to know about 'lsblk' which looks like it can 
 detect whether discard is supported on device-mapper devices:

Indeed.

I use the following script that automatically detects and trims devices that 
support it.

Drop it under /etc/cron.daily or weekly:


#!/bin/bash
#
# To find which FS support trim, we check that DISC-MAX (discard max bytes)
# is great than zero. Check discard_max_bytes documentation at
# https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt
#
for fs in $(lsblk -o MOUNTPOINT,DISC-MAX,FSTYPE|grep -E '^/.* [1-9]+.* '|awk 
'{print $1}'); do
fstrim $fs
done




signature.asc
Description: OpenPGP digital signature

Bug#748867: Fix/workaround for Google API key problem.

[Carlos Alberto Lopez Perez]

Another option is setting the Google API Keys in the environment [1].

So, it should be enough to create a file at /etc/chromium.d that
exports the keys. (/usr/bin/chromium sources all files on that dir)

This works for me:

$ cat /etc/chromium.d/googleapikeys 
export GOOGLE_API_KEY=AIzaSyCkfPOPZXDKNn8hhgu3JrA62wIgC93d44k
export GOOGLE_DEFAULT_CLIENT_ID=811574891467.apps.googleusercontent.com
export GOOGLE_DEFAULT_CLIENT_SECRET=kdloedMFGdGla2P1zacGjAQh


(BTW: This keys are the Debian Google API keys that used to be included 
in older Chromium packaging debian/rules)

[1] http://www.chromium.org/developers/how-tos/api-keys



signature.asc
Description: OpenPGP digital signature

Bug#747535: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 11/09/14 14:36, Ben Hutchings wrote:
 On Wed, 2014-09-10 at 21:36 +, Nick Phillips wrote:
 [...]
 Debian has a good and hard-earned reputation for not messing up
 sysadmins' changes; upgrading to systemd - however wonderful it is (and
 I confess to having no opinion on that) - without at least a debconf
 prompt of a reasonable priority telling them what is about to happen and
 offering a bailout, is guaranteed to lose us reputation and users.
 [...]
 
 I do agree that at least some kind of high-priority notice is needed.
 
 Ben.
 

Unfortunately systemd maintainers don't agree on this. (#747535)



signature.asc
Description: OpenPGP digital signature

Bug#757298: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 15:14, Mathieu Parent wrote:
 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez clo...@igalia.com:
 [...]
 So, when upgrading from Wheezy to Jessie, we have three options:

 1) Keep the user init system (sysvinit most probably)
 2) Upgrade to systemd after asking the user.
 3) Upgrade to systemd silently without asking the user.
 
 4) Upgrade to systemd silently without asking the user AND add a grub
 entry to use old init
 
 This will provide the intended default with an extra compatibility
 layer (like the former grub1 to grub2 chain).
 

This may be a good option when you have pre-boot access to the machine
(either physical access or with a KVM), so you can select an option on
the GRUB menu if things go wrong.

But if you don't (Is not uncommon to have servers on remote locations
that are only accessible via ssh) and the machine don't boots properly
you can find yourself in trouble.

When the transition to GRUB2 was made, it didn't replaced the previous
system (GRUB1) without asking the user. What it did was to add a new
(non default) entry on GRUB1 to chainload to GRUB2. The idea was that
the user could test the new system when he felt it was a good moment.
So, after checking that all worked as expected, he could make the new
system the default by executing a command: upgrade-from-grub-legacy. [1]


I wish something similar would be made for the switch to systemd:

1. Add a new entry on GRUB to boot with systemd (but leave the previous
init system as default).
2. Add a command upgrade-from-init-legacy or upgrade-to-systemd that
sets the option to boot with systemd as default.

That way the user can test to boot with systemd when he feels like is a
good moment, and if things work as expected he can make the switch
definitively by executing that command.





[1] https://wiki.debian.org/Grub#Upgrading_from_v1_to_v2



signature.asc
Description: OpenPGP digital signature

Bug#760827: debian-maintainers: Please add Carlos Alberto Lopez Perez as a Debian Maintainer

[Carlos Alberto Lopez Perez]

Package: debian-maintainers
Severity: normal
Tags: patch


Hello,

Please add Carlos Alberto Lopez Perez clo...@igalia.com as a Debian 
Maintainer.

I'm attaching here the jetring changeset.

Thanks!
Comment: Add Carlos Alberto Lopez Perez clo...@igalia.com as a Debian 
Maintainer
Date: Mon, 08 Sep 2014 11:08:39 +0200
Action: import
Recommended-By: 
  Aron Xu a...@debian.org, Paul Wise p...@debian.org
Agreement: 
  https://lists.debian.org/debian-newmaint/2014/08/msg00010.html
Advocates: 
  https://lists.debian.org/debian-newmaint/2014/08/msg00032.html
  https://lists.debian.org/debian-newmaint/2014/09/msg00021.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1
  
  mQINBE7H3fkBEADG64zFhuz6Esa+YnKvbeW474RlXVO9vfFSrrzFNAcCUcu2kF5i
  tAXoEKJVmWs2xqE/TRrXbWGETu2S0802MTi2Suy/7vOFCOrlEQmt2JskAHjowAix
  okHop52/Ed/1Jf+iD9DtLEx47GanUJHRavsnhl/++kMGYhpFUZXU8TyDaFxI64/y
  5lEjjE71jNwK29fZSCL0uWi43mkgxGCIUsqGC+IQ8ZjeGTT3OvS8IpL6GnKFFZ6Q
  LRiWlpqB/fuaJw00aQ0k5tiU1GNEHFIS5uonRcYVpUYKNITq2l5PhU1mwBw3/mMa
  VoDCWTFdxulleWULdoTO/oeumvDalhYlb4f5WnJb1RubNHlAXkX2cONSqNT0zajl
  CCuX29B44vCyGr+nUAkNgbLMGJz4fOHPL3N6eUTZbBV/rJ8kOQq5kld9DPbRn9b0
  pY3ThuU3BQzQSmZXTQQ7R/aV5aJI1V8mO7EsRXoqhyLKHpwlUACRXpjarsf8lqOq
  viu2OnK1LFlnZ1QKJ9bPIuIotO1NID+Rs0IihaKyNTiL+/XGtf+kT+wwajpI/5mI
  QVi5OtEfcIhBL4LgP1Fga+vTLmQEA+9eC6PccWg5RAR4sE1pdiu8rsK05r7u7gE/
  5KtefY1ivltj3dbrn0SJuw7bqb/q0Q2W3VzLoIqtdHb+seqSmH/qF4xcRwARAQAB
  tC5DYXJsb3MgQWxiZXJ0byBMb3BleiBQZXJleiA8Y2xvcGV6QGlnYWxpYS5jb20+
  iQJABBMBCgAqAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAhkBBQJTq//NBQkK
  h7xEAAoJEJZQic5rlfiCRLEP+wcSjt2qg1kUH8PwzCYrESQi5PMj+zgj4pioa7EX
  iEeot6x79SCyqxuU17PFpK6d7pgLaJXDJEIEmVWcOHcuyGRZz5TPA2BL4rpz7E5A
  4Zn4T7Dkh9SxLbX1N+mn6RHyFKBjaL18M2wpm/UGrYpdnQGmCFBgI1qsPisr/4fq
  W98yIjQWyGkPqMoQtqtKsimeb/dWUFPWrVmy3AUlt9GJVmJGO+dmnsjOFZyiVbBV
  vUL86skVZnQqEJW5nvauVS066mx4WUkiM8Zg1l5YNlzUCLA0yydi68R0ZF5PcwXa
  LT3mNEhDI4gF2lXQnBybAgGFpl2rkBHW5WtupgG7UsM4TT68xP1C63QLHMOHfiS7
  BVuEZE/dzo2dcHa/C+tAnTdz0wI7VtPP8KAA/y43HrXFC9nszRiciLJ8ZLVaUaEi
  5PqAO/SFNv/soITx3fWP0wYWqGOtYSnIYAG5xLwqshRuwy5bx5x40Z7HDn/TGDhA
  Sy66eJcBxEJvK7rjy6ktIj34xnUjv5BiyDAGd1HCH6bki3Urb7cGqChSLia1Ki1B
  lF7drco8ERFTwan1BuqmQcVI2SoQbX39MbhEZEfF5LNVg7lKOqGqdP0kW/4REIOA
  FUTiOhGqyaLWRlTimelk8lqMAXljTl+E4QRJHHHyqO9csZbDxuj6dcQhiTD3psiO
  wp8PiEYEEBEKAAYFAk7H47wACgkQPH2MlObsr3gd5ACeNjZn6QPnr2QocUGpdwX9
  vWZ1YloAn2qUqj3sZotz1JZTQUb5shs81PJDiEYEEBECAAYFAk7IRLkACgkQYdSY
  B4kLFbKO4wCfYn8XxZvqkdvBjh+v2aOzXivpH/4AnREehfh1e9Qkha/NGwDbuOQ2
  ncm0iEYEEBECAAYFAk7KIOkACgkQUOuBUQZqwFIE5QCfQGUNCzUNBr8696jQu1Su
  GeO/WR8AnicpQON8vuG34vTTaaxpPUtrrr7xiEYEEBECAAYFAk8urXoACgkQN3jX
  LIAJYNfv9gCcDHOQjpLbwm/aXm18+rBzsXlkuK4AnimrP0R4BrXx3Z4NLiFEMdgK
  47hziEYEEBECAAYFAk8v/z0ACgkQvCkUtBccqkrOnwCggo6vySctQxXbz9ps2Xc7
  jvncoLUAoJICKlbmM4TuFzYCvFVkE6npESbRiEYEEBECAAYFAk9BF5AACgkQVuf/
  iihAxwgo1gCfZkwlMQSn+kQ3I4e//49fsOen2z8AoKUXZM8p6hq6kMQHqVt0EW2E
  /IpmiEYEEBECAAYFAk9BF5AACgkQY0Ly7Lxa9rko1gCgv2LblJiyNkLTH2d3nrCs
  5ndQUuYAn3voZgVSjqtXg1ZGSin7tt7J9wVviF4EEBEIAAYFAk8yRQYACgkQdY+i
  KmE/OuTRRgD9EIhFJvqSx/5/hPLC4Be0yncvbmBo/OAjZYB95b87eY8A/1DNC7yn
  aRBjCVnoT6GLgjlRC5WJXnsxz+vDQT/+SkYyiF4EEBEIAAYFAk8zAmQACgkQRSY5
  iJtTVVYsagEAlUoaxfO4SeR53RcbFziZGZGjUmp5AopZ+jXKb8TvOr8A/AqA2h5J
  J9XBOLmjHbv7gm1cNWPDWTeSHYuM+ThGYeYbiF4EEBEIAAYFAk80/HAACgkQF+5w
  mzg0aL/x2gEAhP1XAtWejPnYOfY4XARzxKZ+P68xebTdMNYbmwhpYToBAKUOYaP7
  Ll7jjH6ULsTgN2KlrJdgH0urQS7j4gBtfuLQiF4EEBEIAAYFAk80/IoACgkQNJjw
  Wu8zPH4DxQD/dr6vonXOpKrQG+eKqSHgVBerAi9YY/KGnU1D5E91sRQA/13Mo1AG
  X69Us+Clt6IsONUB+wXrGYsAkcdDfgjKAeXBiQEcBBABAgAGBQJPQReQAAoJEGfn
  cvCDUeCv7joH+gPWeQwq91FAduY6qB6eLX6SXDemixZaKuw6iIMIsw4JEf+L5Jx0
  UTBLtFoJu+sTIiJxFD4TFO79bAdcis7voKnbQ1bnEgEnLu6m6Vvf1fkm9pveC93x
  2UnHC2CTNfqt6voRkYC4jB1SZQyMXN7kVyh/IY+3JQ6BfZd4/pY7NwGN//jU7o4W
  bVriAdMY41+iujkrK51LZ4ePGimzudZzwFM5pDog8mDZPyaYvb30vFzbdfw1sONe
  JbcKyYgM40wGYZ2/ZcE1/uodfaiQb0SD18JGkGF3PppfOpSGgrs7oWoQnSAt3i7h
  fgzpP2H0sLXJ0Jny/A6NxOb9RZiybNyqRgKJARwEEAECAAYFAk9BF5AACgkQqM4o
  pgENbzruOgf+KMt01OhogLHV5K+Pd+VbXAXH2/fdPoJbpwzSXNFGgkq57zRcUrOM
  8Jmq+xJtTcQjT7CnqQFUkRiB+5cyQhhUh3ewKv8ZIk5TeleWgR8Spj6ULuEBNGlI
  rqj8+5835OH8+EuNkc2xwzgiItGes1WSq1TBA5NLoHJZreiGTBahne+5p7OELw51
  EWIwkT0KCZuB36XvMCPiWyVlM7huNRCE9yp5JOr1QEdl2e5jvHl5fJvsnrBYavhk
  x2ooTr0ClaZEy/Jeu2hF87XpI36O8bt6kO9pS7MYFNPLfkzIRVketOIS9dtNoVTR
  +SJhOmtnsV3iwZVRDM6fenAxyxUrj1pTGIkCHAQQAQIABgUCTy7WzQAKCRBbnqFh
  ZpDPlOaaD/9YjquYlKgQ2PgLrwOHjlZItb4Ib8OmuxwWCjFXkqJaR8LJw9nnZSuL
  88+78fZlwsKleq4LAzU/IDx6/U8rld7+QKQk22D8qALnwMZqvYJ7dgesegM2c2XV
  HITIv9pxC8kj7m2JGch2brbtgXI8ALLInswk7G773fsNmv/bbvuIWf8W6ANNMfEE
  PVctk+nletUp+c+0eOTzEMVMQ3672ZMUR7ZZDiNaOwAn4GoODl3bOhnkAE4HZU5x
  8n/EBChGyk35VYHHcOzrRXY48qv9jFCSuktprXIekXmfVc9ysOEYRtNTefd7KTV6
  jsnVt2UC1EPVT087U4D1LQUZQlMygak+4ipuF69RM1YjXXTRnUuu0zJPSEPEXS8P
  c42VTSed4HaRO3zWnXt7yPHtaVdHL8ylhx4S383OZMmyAyEQAWCr9+giW4gK2LLu
  IrnEpU5jxJxF/USiX4h92s+2dX6unxt4NYEn7jzEFtAC80Houiqq0tDAfkdS7H6h
  jUXFlCy93hF2X+Z9mUjYv3+wYOLZCTjAW3H9ctrmYZ0Aw0wm9hQotCMbfTtanDq

Bug#686447: [zfs-discuss] Re: Licence issues and non-issues with ZoL: CDDL and GPL

[Carlos Alberto Lopez Perez]

On 30/08/14 01:03, Andreas Dilger wrote:
 On Aug 29, 2014, at 4:48 PM, Prakash Surya m...@prakashsurya.com wrote:
 On Fri, Aug 29, 2014 at 03:33:15PM -0600, Andreas Dilger wrote:
 On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez
 clo...@igalia.com wrote:
 On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote:
 Maybe we could share a RFC of the summary here when we think is ready, in 
 order to double-check our understanding of the license stuff and get more 
 feedback about it.

 On 27/08/14 16:38, Andreas Dilger wrote:
 Hi Carlos,
 I've been dealing with ZoL and the GPL/CDDL issues for a number
 of years for the Lustre filesystem. IANAL, but know quite a bit about
 these issues so I'd be happy to help out if I can. 

 Thanks for the offer to help.

 Aron has posted our summary about the situation [1]. If you want to 
 comment on it that would be great.

 In general I think this is a very well written summary of the issues.

 I think it is a disservice to your argument that you equate CDDL with 
 proprietary binary licenses such as those used for NVidia or Broadcom.

 I would definitely seek clarification of what part of the spirit of the 
 GPL is being violated.

 I think the most important point is that CDDL is an OSI-approved 
 _open_source_ license, which eliminates IMHO the biggest objection to 
 proprietary binary modules, since the source for ZFS is available for 
 debugging, modification, and redistribution.

 The CDDL is actually a permissive license and even grants patent  
 indemnification for any patents embodied in the original ZFS code (similar 
 to GPLv3).  It is the GPL that restricts distributing with CDDL code and 
 not the reverse (CDDL 3.6 explicitly allows this).

 I probably could read the GPL and figure this out, but, in what way does
 the GPL restrict distribution of GPL and CDDL code together? And maybe
 how it specifically relates to this instance, as the ZFS code is
 obviously not a derived work of any GPL project.
 
 You are right, and I forgot to make this important point as I was writing
 my first email.  It is clear that ZFS is _not_ a derived work of Linux
 (originally written for Solaris), and Linus has himself said this in
 the past about AFS [1], and the GPL only covers code which is derived:
 
 If identifiable sections of that work are not derived from the
  Program, and can be reasonably considered independent and separate
  works in themselves, then this License, and its terms, do not
  apply to those sections when you distribute them as separate works.
 
 and just distributing them together does not change this:
 
 In addition, mere aggregation of another work not based on the
  Program with the Program (or with a work based on the Program)
  on a volume of a storage or distribution medium does not bring
  the other work under the scope of this License.
 
 so if the ZoL module is not distributed as part of the kernel (i.e. in
 a separate package) it is no more incompatible with the GPL than any
 other piece of software that is available via download or on the same
 DVD as others.
 
 [1] http://yarchive.net/comp/linux/gpl_modules.html
 


My understanding is that the part of the GPL that causes concerns is the
one related to derived works.

By comparing the CDDL with the proprietary licenses of the NVIDIA or Broadcom
drivers, I tried to stress the point that this same concern related to derived
works, would apply to any of this proprietary drivers.

And Debian is already distributing this proprietary drivers in their archives.
So it would be a non-sense that ZoL was deemed unsuitable for distribution by
Debian, while at the same time Debian continues to distribute this proprietary
drivers.

You are right that maybe that comparison was not very fortunate. However,
it should be kept in mind that the concerns of FTP Masters are not related
with the CDDL license itself, but with the combination of GPL and CDDL in
the same work.

We hold the view that ZFS is not a derived work of the Linux Kernel, so the
requirements of the GPL License for derived works would not apply to it,
therefore both licenses could be satisfied at the same time when Debian
distributes both the Linux Kernel and the ZFS driver (either in source
code form, or as a binary loadable kernel module).

Regards



signature.asc
Description: OpenPGP digital signature

Bug#686447: Licence issues and non-issues with ZoL: CDDL and GPL

[Carlos Alberto Lopez Perez]

On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote:
 Maybe we could share a RFC of the summary here when we think is ready, in 
 order
 to double-check our understanding of the license stuff and get more feedback 
 about it.

[...]

On 27/08/14 16:38, Andreas Dilger wrote:
 Hi Carlos,
 I've been dealing with ZoL and the GPL/CDDL issues for a number
 of years for the Lustre filesystem. IANAL, but know quite a bit about
 these issues so I'd be happy to help out if I can. 

Thanks for the offer to help.

Aron has posted our summary about the situation [1]. If you want to comment on 
it that would be great.


Regards.


[1] http://mid.gmane.org/20140829014229.GA9572@aron-laptop



signature.asc
Description: OpenPGP digital signature

Bug#759545: Ceni - Curses user interface for configuring network interfaces with ifupdown

[Carlos Alberto Lopez Perez]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: k...@otaku42.de, bernard.g...@gmail.com, x-u...@berlios.de, 
s@gmx.de, andre...@debian.org

* Package name: ceni
  Version : 2.28
  Upstream Author : Kel Modderman k...@otaku42.de
* URL : https://github.com/fullstory/ceni
* License : GPL-2+
  Programming Lang: Perl
  Description : Ceni - Curses interface to /etc/network/interfaces

 A Curses user interface for configuring network interfaces with ifupdown.
 Ceni can manage basic network interface ifupdown configuration stanzas for
 ethernet and wireless devices.




signature.asc
Description: OpenPGP digital signature

Bug#722451: Adoption

[Carlos Alberto Lopez Perez]

On 27/08/14 06:31, Prof. Dipl.-Ing. Klaus Knopper wrote:
 Hello,
 
 On Tue, Aug 26, 2014 at 11:56:48PM +0200, Carlos Alberto Lopez Perez wrote:
 On 11/08/14 23:50, MENGUAL Jean-Philippe wrote:

 Hi,

 Do you plan still to package Compiz? Do you have a problem which
 prevents this? Do you need help? Otherwise, can I adopt it so that
 someone and I can package it before freeze? Our work to prepare has now
 good improvement.

 Thanks,

 Regards,


 Hi,

 This bug is marked as RFP = Request For Package. This means that the
 reporter is asking for someone to package this software, but no one has
 still offered to package and maintain it.

 If you want to package/maintain it yourself, please retitle the bug to
 ITP = Intend To Package, assign the bug to yourself, and start working
 on it.

 Find here help about packaging for Debian:
 https://wiki.debian.org/DebianMentorsFaq#Packaging

 And here help about using the BTS (Bug Tracking System):

 https://wiki.debian.org/HowtoUseBTS
 https://www.debian.org/Bugs/server-control

 Thanks!
 
 Actually, I do package the compiz git from launchpad regularly for using
 it in Debian/Knoppix as the main window manager. Please find the source
  binary packaging here:
 
 http://debian-knoppix.alioth.debian.org/packages/compiz/
 
 However, I'm not am official Debian Package Maintainer and thus the
 packages won't show up anywhere else than in Knoppix currently.
 

You don't need to be a Debian Maintainer (DM) to maintain packages in
Debian. Anyone can maintain packages in Debian.

The only difference is that DM are allowed to upload directly to the
archive, while not-DM people need that some DD (Debian Developer) review
and sponsor the package.

Once you are maintaining one or more packages in Debian you can apply to
become a DM if you want, so you can upload further updates of your
packages directly to the archive.

We have a clear process defined for this. Once you have your package
ready, you can upload it to mentors.debian.net (or to other site if you
prefer) and you ask on the mailing list debian-ment...@lists.debian.org
(subscribe yourself to the list) for someone to review and upload your
package.

Probably you will have to trim the Changelog for the initial upload to
Debian, and include a line on it closing this bug #722451. But first you
should retitle this bug to ITP and assign it to yourself, to show your
intention of packaging Compiz for Debian. So anyone else that could be
interested in doing the work is aware that you are already working on
this. So we avoid duplicating work.



signature.asc
Description: OpenPGP digital signature

Bug#686447: Licence issues and non-issues with ZoL: CDDL and GPL (was: Re: [zfs-discuss] [Pkg-zfsonlinux-devel] zfs-linux_0.6.2-1_amd64.changes REJECTED)

[Carlos Alberto Lopez Perez]

On 26/08/14 23:00, Paul Richards Tagliamonte wrote:
 Hello, ZFS on Linux maintainers,
 
 At a recent ftpteam meeting we discussed this package, and what to do about 
 it.
 
 Our consensus was that this package appears to violate the spirit of the GPL 
 at
 minimum, and may cause legal problems. Judges often interpret documents as 
 they're
 intended to read, hacks to comply with the letter but not the intent are not
 looked upon fondly. This may be a hard thing for technical folks to accept, 
 but
 in legal cases one usually isn't dealing with technical people.
 
 As such, this package has been rejected with the following notes:
 
  * Please take care to fix your naming issues. Please talk with the kFreeBSD 
 folks
on how to best handle the namespace. The kFreeBSD folks had these names
first, it's up to them how they're used.
 
  * We recommend that the DPL put a question to our lawyers, providing a full 
 and
complete background on the situation. (We are happy to help reviewing it 
 before
it gets sent off). We will defer judgement on the legality of distributing 
 ZoL
in Debian to them.
 
 Thanks,
   Paul, on behalf of the ftpteam
 


We (the Debian ZoL package maintainers) have been talking about this.

The Debian FTP Team wants us to write a summary of the situation regarding the 
license 
stuff describing how ZoL avoided violating the combination of GPL and CDDL. 
Then they 
may forward that to DPL (Lucas) and then to SPI's lawyer. They would be OK to 
accept 
the package if the lawyer says yes.

We are already writing this summary. If someone wants to help please send me or 
Aron an
e-mail. Maybe we could share a RFC of the summary here when we think is ready, 
in order
to double-check our understanding of the license stuff and get more feedback 
about it.



signature.asc
Description: OpenPGP digital signature

Bug#722451: Adoption

[Carlos Alberto Lopez Perez]

On 11/08/14 23:50, MENGUAL Jean-Philippe wrote:
 
 Hi,
 
 Do you plan still to package Compiz? Do you have a problem which
 prevents this? Do you need help? Otherwise, can I adopt it so that
 someone and I can package it before freeze? Our work to prepare has now
 good improvement.
 
 Thanks,
 
 Regards,
 

Hi,

This bug is marked as RFP = Request For Package. This means that the
reporter is asking for someone to package this software, but no one has
still offered to package and maintain it.

If you want to package/maintain it yourself, please retitle the bug to
ITP = Intend To Package, assign the bug to yourself, and start working
on it.

Find here help about packaging for Debian:
https://wiki.debian.org/DebianMentorsFaq#Packaging

And here help about using the BTS (Bug Tracking System):

https://wiki.debian.org/HowtoUseBTS
https://www.debian.org/Bugs/server-control


Thanks!



signature.asc
Description: OpenPGP digital signature

Bug#757146: EFL uses deprecate property from upower 0.99 and causes errors on unrelated software.

[Carlos Alberto Lopez Perez]

Source: efl
Version: 1.8.6-2


I have been getting errors while trying to build and run webkitefl on 
Debian/jessie.
The errors were related to upower and dbus.


Tools/Scripts/run-perf-tests --platform efl --release -2
Running 139 tests
Running Animation/balls.html (1 of 139)
error: Animation/balls.html
ERR11506:ecore_system_upower 
modules/ecore/system/upower/ecore_system_upower.c:74 _on_low_battery_get_cb() 
Message error org.freedesktop.DBus.Error.InvalidArgs - No such property 
OnLowBattery
ERR11518:ecore_system_upower 
modules/ecore/system/upower/ecore_system_upower.c:74 _on_low_battery_get_cb() 
Message error org.freedesktop.DBus.Error.InvalidArgs - No such property 
OnLowBattery

FAILED
Finished: 15.780578 s


The issue is caused because upower 0.99 (the one available on Debian jessie) 
has deprecated that property.

$ apt-get source upower=0.99.0-3
$ grep -r OnLowBattery upower-0.99.0/
upower-0.99.0/NEWS: - Remove OnLowBattery property (use WarningLevel instead) 
(Bastien Nocera)


I tried to report this upstream but I was unable to do it (the EFL trac gives 
errors :\ )



signature.asc
Description: OpenPGP digital signature

Bug#708070: enable x32 support for the amd64 kernels

[Carlos Alberto Lopez Perez]

I was just hit by bug https://bugs.debian.org/736659 after installing
gcc-multilib and later rebuilding my initramfs.

I don't think this situation of having several x32 packages on the
archive (which other packages depend on) while the official debian
kernel don't supports x32 at all is sustainable in the long run.

Please consider enabling CONFIG_X86_X32 on 3.14 and superior.

Thanks



signature.asc
Description: OpenPGP digital signature

Bug#749929: RFS: aircrack-ng/1:1.2-0~beta3-1

[Carlos Alberto Lopez Perez]

On 01/06/14 03:47, Paul Wise wrote:
 On Sat, May 31, 2014 at 1:37 AM, Carlos Alberto Lopez Perez wrote:
 
   dget -x 
 http://mentors.debian.net/debian/pool/main/a/aircrack-ng/aircrack-ng_1.2-0~beta3-1.dsc
 
 Some comments below. Other comments via private mail.
 
 Upstream website SSL is broken because it doesn't send CA certs along
 with it, they need to use SSLCertificateChainFile. Also cacert.org
 isn't trusted by many browsers or CA cert stores so it probably isn't
 the best choice.
 
 https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcertificatechainfile
 

I will forward your comments regarding the SSL certificate of
aircrack-ng.org to Thomas.

 I would suggest using experimental instead of unstable for betas.
 

In general I agree with you, but this release is IMHO an improvement
over the previous 1.1 series and is as stable as the older one.

I think that Thomas should have called it release candidate instead of beta.

Most probably, the final 1.2 version would be very similar to this one.

Also I wouldn't want it to miss the next stable release of Debian.
Previous 1.1 version don't has proper support for libnl, which causes
some problems on modern kernels.

 Why remove airdriver-ng?
 

Because is completely broken and only manages to confuse users.

Please check: http://trac.aircrack-ng.org/ticket/1317

 Please use dh --parallel to enable parallel building.


Ok. Will add it.

 Override_dh_auto_install doesn't need to override the normal make
 install, just use dh_auto_install
 

Ok.

 I think you want uversionmangle instead of dversionmangle:
 
 https://wiki.debian.org/debian/watch#Common_mistakes
 

Would check it.

 Upstream might want to replace evalrev with running autorevision:
 
 http://packages.debian.org/autorevision
 

Is there any technical advantage of doing that?

Please, feel free to open a ticket on http://trac.aircrack-ng.org

 What about enabling ext_scripts?
 

I tried to do it, but it was such a mess that I decided to go back.

* airdrop-ng: depends on pylorcon which is not available on Debian.
* versuck-ng: is just a password generator from 2009 for Verizon
wireless routers with 64bit WEP Keys. I doubt any user out there is
still using this.
* airgraph-ng and airoscript-ng: both failed on the install phase. I
wasn't able to get them working after a make install.

I will gladly accept patches if you are interested in any of this tools.

 Are any of the C# things buildable with Mono or useful on Debian?
 

I have no idea, never tried to build that.

The changelog says that it is a C# library to parse Airodump-ng output
files.

If you know where this can be useful for Debian let me know it.
Otherwise I prefer to skip adding a dependency on Mono.

 Is upstream working on getting the many patches merged into Linux
 mainline? Either way it would be great if they had DEP-3 style patch
 headers or similar.
 
This patches are the ones that airdriver-ng used. 99% of this patches
not longer apply or make any sense. See the ticket
http://trac.aircrack-ng.org/ticket/1317

I think this patches should be removed from the upstream repository.

 airoscript overrides TMPDIR but it should use the user-provided one
 and doesn't clean up properly if TMPDIR is not /tmp/.
 
 It would be good if the airoscript logo files were generated at build
 time so they can never get out of sync with the source .xcf/.svg
 files.
 

The package don't installs airoscript (see my previous comments about
ext_scripts) I tried to do it, but the install phase is broken (at least
for me).

Right now I don't have time to fix this, I tried to do it, but it was
not a quick fix so I decided to let that for another moment.

If you are interested in airoscript-ng I will accept patches to enable
it on the Debian package.

 Please ask upstream to remove the two prebuilt gettext .mo files from
 SVN/tarballs, they should be created at build time
 

http://trac.aircrack-ng.org/ticket/1436




signature.asc
Description: OpenPGP digital signature

Bug#749929: RFS: aircrack-ng/1:1.2-0~beta3-1

[Carlos Alberto Lopez Perez]

On 01/06/14 04:24, Paul Wise wrote:
 On Sun, Jun 1, 2014 at 9:47 AM, Paul Wise wrote:
 
 Some comments below.
 
 More:
 
 Some bits of airoscript-ng use /usr/local unconditionally.
 
As commented on my previous reply, the package don't installs airoscript-ng.

 GCC warnings:
 
 tkiptun-ng.c: In function 'main':
 tkiptun-ng.c:4195:11: warning: ignoring return value of 'setuid',
 declared with attribute warn_unused_result [-Wunused-result]
  setuid( getuid() );
^
 airbase-ng.c:73:19: warning: 'gcry_thread_cbs' is deprecated (declared
 at /usr/include/gcrypt.h:213) [-Wdeprecated-declarations]
  GCRY_THREAD_OPTION_PTHREAD_IMPL;
^
 airbase-ng.c: In function 'main':
 airbase-ng.c:4566:11: warning: ignoring return value of 'setuid',
 declared with attribute warn_unused_result [-Wunused-result]
  setuid( getuid() );
^
 airodump-ng.c:77:16: warning: 'gcry_thread_cbs' is deprecated
 (declared at /usr/include/gcrypt.h:213) [-Wdeprecated-declarations]
   GCRY_THREAD_OPTION_PTHREAD_IMPL;
 ^
 aircrack-ng.c:84:16: warning: 'gcry_thread_cbs' is deprecated
 (declared at /usr/include/gcrypt.h:213) [-Wdeprecated-declarations]
   GCRY_THREAD_OPTION_PTHREAD_IMPL;
 ^
 

The gcry* warnings appeared after that I enabled building with
libgcrypt20 by default. Building with libgcrypt11 don't causes this
warnings. I guess I will have to fix that at some moment.

I will look at the setuid warnings.

 lintian:
 
 I: aircrack-ng source:
 debian-watch-file-should-uversionmangle-not-dversionmangle line 3
 P: aircrack-ng source: debian-watch-may-check-gpg-signature
 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/ivstools.1.gz:7
 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/ivstools.1.gz:9
 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/ivstools.1.gz:15
 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/ivstools.1.gz:17
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:40
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:46
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:47
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:50
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:53
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:55
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:60
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:78
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:81
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airbase-ng.8.gz:85
 I: aircrack-ng: hyphen-used-as-minus-sign
 usr/share/man/man8/airbase-ng.8.gz 7 more occurrences not shown
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airodump-ng.8.gz:45
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airodump-ng.8.gz:64
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/airodump-ng.8.gz:69
 I: aircrack-ng: hyphen-used-as-minus-sign
 usr/share/man/man8/airodump-ng.8.gz:166
 I: aircrack-ng: hyphen-used-as-minus-sign 
 usr/share/man/man8/besside-ng.8.gz:39
 
 

I already know about this, but I consider the hyphen-used-as-minus-sign
warnings pretty low priority.



signature.asc
Description: OpenPGP digital signature

Bug#749929: RFS: aircrack-ng/1:1.2-0~beta3-1

[Carlos Alberto Lopez Perez]

On 01/06/14 04:39, Paul Wise wrote:
 On Sun, Jun 1, 2014 at 10:24 AM, Paul Wise wrote:
 On Sun, Jun 1, 2014 at 9:47 AM, Paul Wise wrote:

 Some comments below.

 More:
 
 One more - the ieee-data package places the oui files in a different
 location to where aircrack-ng looks for them.
 

Yes, I know.

airodump-ng looks for the oui file at this 4 places:

/etc/aircrack-ng/airodump-ng-oui.txt
/usr/local/etc/aircrack-ng/airodump-ng-oui.txt
/usr/share/aircrack-ng/airodump-ng-oui.txt
/usr/share/misc/oui.txt


ieee-data installs the file in the 4th place



signature.asc
Description: OpenPGP digital signature

Bug#749929: RFS: aircrack-ng/1:1.2-0~beta3-1

[Carlos Alberto Lopez Perez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package aircrack-ng

  * Package name: aircrack-ng
Version : 1:1.2-0~beta3-1
Upstream Author : Thomas d'Otreppe tdotre...@aircrack-ng.org
  * URL : http://www.aircrack-ng.org
  * License : GPL-2
Section : net

It builds those binary packages:

  aircrack-ng - wireless WEP/WPA cracking utilities

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/aircrack-ng


Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/a/aircrack-ng/aircrack-ng_1.2-0~beta3-1.dsc


Changes since the last upload:

   * New upstream release.
 * Remove all Debian patchess that are now merged upstream.
   * Apply: wrap-and-sort -sa
   * Build with PCRE: Add support for regular expression matching for ESSID
 in airodump-ng.
   * Build with libgcrypt20 by default, but allow to use libgcrypt11 otherwise.
   * Fix libnl detection (Debian patches 002-fix-libnl-detection.diff and
 003-dont-abort-libnl-nolinux.diff).
   * Add build dependency on libnl-genl-3-dev.
   * Remove airdriver-ng (LP: #499513) (Closes: #449299).
   * Not longer recommend wget, because we don't ship airdriver-ng neither
 airoump-ng-oui-update.
   * Recommend the Debian package ieee-data that contains the OUI data.
 Add Debian patch 001-Airodump_whitespace_oui.diff to correctly parse it.
 Not longer ship airodump-ng-oui-update (Use update-oui instead).
 (Closes: #739199)
   * Switch to debhelper 9 and enable all hardening flags (PIE works now).
   * Update debian/watch and debian/copyright.
   * Upgrade to new standars version.


Regards!



signature.asc
Description: OpenPGP digital signature

Bug#749929: RFS: aircrack-ng/1:1.2-0~beta3-1

[Carlos Alberto Lopez Perez]

On 30/05/14 19:37, Carlos Alberto Lopez Perez wrote:
 [...]
  * Remove all Debian patchess that are now merged upstream.
^ patches
 [...]
* Upgrade to new standars version.
  ^ standards


I just fixed now this two typos on the changelog and uploaded to mentors
again.



signature.asc
Description: OpenPGP digital signature

Bug#534508: daemontools: setuidgid should initialize the supplementary groups

[Carlos Alberto Lopez Perez]

Hi,

This bite me recently.

I'm attaching a debdiff with the patch from Huaqing, which I tested and
verified to work as expected. I also updated the manpage.


Could you upload this please? If you don't have time I can do an NMU (if
you think the attached debdiff is OK)


Thanks!
diff -u daemontools-0.76/debian/changelog daemontools-0.76/debian/changelog
--- daemontools-0.76/debian/changelog
+++ daemontools-0.76/debian/changelog
@@ -1,3 +1,11 @@
+daemontools (1:0.76-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch for setuidgid to initialize the supplementary groups and
+update manpage (Closes: #534508)
+
+ -- Carlos Alberto Lopez Perez clo...@igalia.com  Thu, 29 May 2014 11:59:03 
+0200
+
 daemontools (1:0.76-3) unstable; urgency=low
 
   * debian/daemontools-run.postinst: don't exec into the kill program, so
diff -u daemontools-0.76/debian/daemontools-man/setuidgid.8 
daemontools-0.76/debian/daemontools-man/setuidgid.8
--- daemontools-0.76/debian/daemontools-man/setuidgid.8
+++ daemontools-0.76/debian/daemontools-man/setuidgid.8
@@ -14,7 +14,7 @@
 .B setuidgid
 sets its uid and gid to
 .IR account 's
-uid and gid, removing all supplementary groups. It then runs
+uid and gid (including all supplementary groups of the user). It then runs
 .IR child .
 
 .B setuidgid
@@ -23,7 +23,7 @@
 .B setuidgid
 exits 111 if it cannot find a UNIX account named
 .IB account ,
-if it cannot setgid, if it cannot setuid, or if it cannot run
+if it cannot setgid, if it cannot setuid, if it cannot initialize the 
supplementary groups of the user, or if it cannot run
 .IR child .
 Otherwise its exit code is the same as that of
 .IR child .
only in patch2:
unchanged:
--- 
daemontools-0.76.orig/debian/diff/0003-setuidgid-should-initialize-the-supplementary-groups.diff
+++ 
daemontools-0.76/debian/diff/0003-setuidgid-should-initialize-the-supplementary-groups.diff
@@ -0,0 +1,27 @@
+From: Huaqing Zheng morph...@stanford.edu
+Date: Wed, 24 Jun 2009 16:19:16 -0700
+Subject: [PATCH] setuidgid should initialize the supplementary groups
+
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534508
+---
+ daemontools-0.76/src/setuidgid.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/daemontools-0.76/src/setuidgid.c 
b/daemontools-0.76/src/setuidgid.c
+index 8c683de..b75d799 100644
+--- a/daemontools-0.76/src/setuidgid.c
 b/daemontools-0.76/src/setuidgid.c
+@@ -21,6 +21,10 @@ int main(int argc,const char *const *argv,const char *const 
*envp)
+ 
+   if (prot_gid(pw-pw_gid) == -1)
+ strerr_die2sys(111,FATAL,unable to setgid: );
++
++  if (initgroups(pw-pw_name, pw-pw_gid))
++strerr_die2sys(111,FATAL,unable to initgroup: );
++
+   if (prot_uid(pw-pw_uid) == -1)
+ strerr_die2sys(111,FATAL,unable to setuid: );
+ 
+-- 
+2.0.0.rc2
+


signature.asc
Description: OpenPGP digital signature

Bug#728180: gdm3: service gdm3 stop leaves lots of processes running, preventing restart or start of other dm

[Carlos Alberto Lopez Perez]

Same behaviour here.

I have installed gdm3=3.8.4-9 and I'm running sysvinit.



signature.asc
Description: OpenPGP digital signature

Bug#719153: please consider implementing FIPS 181

[Carlos Alberto Lopez Perez]

On 08/08/13 21:42, Marc Haber wrote:
 
 Unfortunately, apg is 3 clause BSD while pwgen is GPL, so it is not
 simply done by pulling in the relevant code from apg.
 

Why not?

AFAIK BSD 3-clausule is compatible with GPL.

You can pull BSD 3-clausule code into a GPL project meanwhile you
respect the license and copyright notices of the files you are importing.



signature.asc
Description: OpenPGP digital signature

Bug#748073: Pepper flash plugin don't works with Chromium 35.0.1916.86-1

[Carlos Alberto Lopez Perez]

Package: chromium
Version: 35.0.1916.86-1


After upgrading chromium to 35.0.1916.86-1 the pepper based flash plugin
(installed with the package pepperflashplugin-nonfree) stopped working.


I tried to reinstall it, but that didn't solved the issue. Finally I
downgraded to chromium 34.0.1847.132-1 and that fixed the issue.


Thanks!



signature.asc
Description: OpenPGP digital signature

Bug#747535: Please don't make upgrades noisier than necessary

[Carlos Alberto Lopez Perez]

On 10/05/14 05:26, Josh Triplett wrote:
 If the maintainers of the packages involved have done their jobs well
 (and they have), upgrading should be an entirely smooth process.  Much
 like upgrading to a new version of the Linux kernel or a new bootloader,
 you won't actually get the new version until you reboot, so there may be
 value in a you need to reboot reminder after finishing the upgrade,
 but that's true for just about every Debian major release upgrade.
 However, adding a new prompt *before* the upgrade just makes the upgrade
 process that much less pleasant for everyone who *doesn't* actually hold
 religious opinions about init systems, which in practice is a far
 greater chunk of Debian users than those who do.  In practice, upgrading
 from GNOME 2 to GNOME 3 will have a more noticeable impact on the user,
 and we don't nag the user with a debconf prompt about that either, nor
 should we.
 
 Upgrading from one Debian major release to another makes a large number
 of substantial changes to the system; for example, it may replace
 module-init-tools with the completely reimplemented kmod-based tools.
 Those changes don't merit debconf noise either.
 

This makes sense when what is replaced not longer exists on Debian (that
are precisely you examples: GNOME2 or module-init-tools).

*But*, when you are replace something that will continue to be on Debian
and to be supported, then is a serious bug.

This bug is like if tomorrow Debian decides that default MTA should be
Postfix, and on upgrade you replace my MTA (Exim) with Postfix. I would
scream to you very loud.

The default has changed (systemd), but the previous default (sysvinit)
is *not* gone. So you can't replace it on upgrades without asking the
administrator first. Full period.



signature.asc
Description: OpenPGP digital signature

Bug#745253: Please include cronjob to update the data

[Carlos Alberto Lopez Perez]

Package: ieee-data
Version: 20131224.1
Severity: wishlist


Hi,


I'm considering making aircrack-ng recommend this package and use the
data it provides instead of shipping another copy of the same data.

My personal experience is that this data changes much more often than
one might expect. For example, since you shipped the package to now:


$ diff -u /usr/share/misc/oui.txt (curl -s 
http://standards.ieee.org/develop/regauth/oui/oui.txt)|diffstat
 63 | 2766 -
 1 file changed, 2571 insertions(+), 195 deletions(-)


In order to keep this data updated, I think that shipping a cronjob
that regularly updates it, is a good idea.

Maybe shipping it on /etc/cron.weekly (or even /etc/cron.monthly),
and it can be something as simple as:


#!/bin/sh
if ! ping -c1 standards.ieee.org /dev/null 21 ; then
# no internet
exit 0
fi
update-oui /dev/null



Regards!



signature.asc
Description: OpenPGP digital signature

Bug#524377: util-vserver: vservers getting built with missing initscripts

[Carlos Alberto Lopez Perez]

This bug report is quite old. Also I'm not able to reproduce this problem.

Can we close this bug or are you still able to reproduce it with
util-vserver=0.30.216-pre3054-1 (sid) ?



signature.asc
Description: OpenPGP digital signature

Bug#636679: ITP apitrace any progress?

[Carlos Alberto Lopez Perez]

On 12/03/14 10:39, Christopher James Halse Rogers wrote:
 Hi!
 
 It's been in an uploadable condition a couple of times over the last
 couple of years, but the DDs on the Debian X team have always been too
 busy to sponsor at those times (and I've never quite got around to apply
 for DD).
 
 I'll give it another update in git; a couple of the other Debian X guys
 are close to DD status, so the bandwidth for uploading should be better
 soon :)
 
 

Hi,


I think is easier to find a sponsor for your packages if you follow the
documented procedure for RFS http://mentors.debian.net/sponsor/rfs-howto
or you ask for it directly on the debian-mentors mailing list.

Is also a good idea to include this bug in the CC, so people looking at
this ITP like me can know that you are already actively looking for an
sponsor.


Thanks for the update.



signature.asc
Description: OpenPGP digital signature

Bug#636679: ITP apitrace any progress?

[Carlos Alberto Lopez Perez]

Hi,


I'd wish to see this utility on Debian.

This ITP has been open for more than 2 years already and the last update
from the bug owner was more than one year ago.


Christopher, is there any progress on this?


If you are not longer interested or you don't have time for packaging
apitrace on Debian, please retitle this bug to RFP so this package work
can be taken by anyone interested and/or with time available.


Thanks!



signature.asc
Description: OpenPGP digital signature

Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?

[Carlos Alberto Lopez Perez]

On 02/03/14 06:56, Turbo Fredriksson wrote:
 On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:
 
  Hostile binary takeover is not allowed - that is two separate source
  packages should not build the same binary package names, even if on
  different architectures.
 Ok, sounds reasonable when you say it like that. I'd still appreciate a link 
 to the policy for that.


One possible example of theoretical breakage is to run the command
apt-get source libzfs1, right now it downloads the kfreebsd/zfsutils
sources, but I don't know what will happen when zfs-linux is allowed
into the archives.

Is apt intelligent enough to pick the source corresponding to the binary
package of the host arch?



signature.asc
Description: OpenPGP digital signature

Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?

[Carlos Alberto Lopez Perez]

On 28/02/14 10:30, Turbo Fredriksson wrote:
 I'm basically Ccing half the world in this (only half sorry about that :) and 
 I don't know who half
 of you are :), but there have been very little information on what's 
 happening with ZoL in Debian
 GNU/Linux.
 
 Aron (and in some part Carlos) seems to have gone a-wall and the list have 
 been VERY quiet. It seems
 like it's only Aron and me that is actually Debian GNU/Linux Developers 
 (unless other things have
 happened outside the list that I'm not aware of - Carlos was/is a maintainer 
 if I don't
 misremembering and Darik is in the wait queue?). And no actually status 
 information/reason from the
 FTP maintainers about why it have been stuck in incoming for so long 
 (accepted into incoming Sun, 07
 Jul 2013 16:00:06 - that's more than six months ago!). Have it been rejected? 
 Is it held up for some
 reason? What can I/we do to help move it along?
 
 
 I'm now the current Debian GNU/Linux Wheezy package maintainer (and have been 
 for quite some time)
 for/in ZoL (upstream from Debian GNU/Linux I suppose) and I have 
 contributed to both the packaging
 (that is already in the Alioth repos) as well as bits and pieces to ZoL code 
 (such as SMB and iSCSI
 support - which will be accepted into post-0.6.3 which is due out very soon 
 now we hope) and also
 wrote support for ZoL to be used as installation target (debian installer, 
 part-man) etc.
 
 With that - I have a large vested interest in maintaining this and I work on 
 it almost daily, so if
 no one else have the time (Aron, Carlos)
 
 I know that Darik is also very busy working on this, and he already maintain 
 (and have for a very
 long time) the Ubuntu packages in ZoL, and much (most, all?) of the current 
 packaging is from his
 busy hands.
 
 So I'd prefer to work with him on this (if aron/carlos don't have the 
 time/interest that is - I'm not
 proposing to steal the packaging!).
 
 
 Since there have been next to no progress in the Debian GNU/Linux ZoL 
 projects, I have done all my
 packaging stuff in the ZoL repos, so if/when this project is revitalized, 
 I'll push all my work to
 the Debian GNU/Linux repos as individual commits.
 


Hi,

We are still waiting for ftp-masters. I already poked them yesterday and this 
was their answer:

Thu Feb 26 #debian-ftp on OFTC
[13:20] clopez anyone from the ftp team can quickly and gently tell me about 
the status of the package zfs-linux on NEW? It has been sitting there for 6 
months already
[14:28] paultag clopez: no one has had time to properly ensure the CDDL / GPL 
linking mess is above the table
[14:29] paultag k
[14:29] paultag whoops
[14:29] clopez paultag: there is no CCDL / GPL linking: the package only 
ships the kernel module in source format, the kernel module binaries are built 
at install time with dkms
[14:29] paultag I understand that's the line
[14:30] paultag but the fact is it's transitively linking is something we 
have to look at
[14:30] paultag I know when the website copy says about it
[14:30] clopez sorry, what means transitively linking?
[14:31] paultag I need to leave for work, just because you link to a shim 
which links to something doesn't mean it's not all linked together.
[14:32] clopez paultag: I understand, but the package don't ships kernel 
binaries, only source code. So as long as binaries are not distributed (and the 
package don't distributes them) I think there is no problem
[14:32] paultag I understand what the website says
[14:33] paultag but you'll not be suprised when we take our time figuring out 
what the hell is going on with this one.
[14:34] clopez yes, I understand you need your time, only wanted to have an 
update regarding this because I felt it was somehow forgotten
[14:34] clopez thanks for the update
[14:34] paultag it's not forgotten, we just haven't had a slice of time to 
commune about it
[14:34] paultag feel free to email ftpmaster@ and poke
[14:37] clopez Liang Guo did that some weeks ago but he got not reply (AFAIK)



So, I don't know how more we can do other than wait.

Regards!



signature.asc
Description: OpenPGP digital signature

Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?

[Carlos Alberto Lopez Perez]

On 28/02/14 17:23, John Paul Adrian Glaubitz wrote:
 On 02/28/2014 04:13 PM, Turbo Fredriksson wrote:
 Is it ok/allowed to upload a new package, even though the initial one is 
 still stuck in incoming?
 
 I suggest asking the FTP masters to mark the package as REJECT if you
 want to change something again. As long the package is still stuck
 in NEW (not incoming, this is where the package goes once it's
 been ACCEPTED), you can always have it rejected.
 
 It's the cleaner solution in my opinion instead of uselessly bumping
 the package revision to fix minor issues before the package isn't
 even ACCEPTED.
 
 Adrian
 

I advise against this. The upload is to experimental, is OK if the
package has RC bugs.

Let the ftp-master team accept the package first, and once that is done
we can upload a better version to unstable.

In the meanwhile you can continue working on the package repository as
usual.

However, I will wait for a resolution from ftp-master before resuming my
work on the package, because there is the possibility of ftp-master not
allowing the upload and I don't like to waste my time.


Regards!



signature.asc
Description: OpenPGP digital signature

Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?

[Carlos Alberto Lopez Perez]

On 28/02/14 17:58, John Paul Adrian Glaubitz wrote:
  However, I will wait for a resolution from ftp-master before
  resuming my work on the package, because there is the possibility
  of ftp-master not allowing the upload and I don't like to waste my
  time.
 Just because your package is rejected doesn't mean you can't get it
 into unstable at all. Packages are rejected all the time. It just
 means the package is not *yet* fit for ACCEPT.

What I'm afraid of is ftp-masters rejecting the package for license
issues (CDDL-GPL).

If the ftp-masters reject the package on a license issue basis this
would mean that zfs-linux won't get into Debian. So I rather will wait
for this before resuming my work on the current package.

I think the license isn't a problem at all because zfs-dkms only ships
source code (no binary distributed). And the binary utilities
distributed on zfsutils don't depend on any CDDL-incompatible
library/package.



signature.asc
Description: OpenPGP digital signature

Bug#700411: git-buildpackage: git-import-orig should filter the upstream debian directory

[Carlos Alberto Lopez Perez]

tag 700411 +patch
thanks

On 06/05/13 18:20, Guido Günther wrote:
 
 It's a great start but before applying it we should also make sure
 git-import-dsc behaves consistently and also not do it for 1.0 packages
 since these are expected to have a patch that applies against the
 upstream tarball.
 Cheers,
  -- Guido
 

I'm attaching a rebased patch that checks for the source format of the
package and only wipes the debian/ directory from upstream tarball if
the source format is 3.0 (quilt).


I'm not sure if for the other 3.0 type of packages (git,bzr,custom)
deleting the debian/ directory is expected. If this was the case, then
is a simple matter of changing on the patch:

-if source_format.version == 3.0 and source_format.type 
== quilt:
+if source_format.version == 3.0 and source_format.type 
!= native:



Regards!
From 440f2066001fafa2668848980602baaaf0cb1ea4 Mon Sep 17 00:00:00 2001
From: Carlos Alberto Lopez Perez clo...@igalia.com
Date: Sat, 15 Feb 2014 18:57:52 +0100
Subject: [PATCH] Filter upstream debian directory on packages 3.0 (quilt)
 (#700411)

---
 gbp/scripts/import_orig.py | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gbp/scripts/import_orig.py b/gbp/scripts/import_orig.py
index aae93fa..8036bd3 100644
--- a/gbp/scripts/import_orig.py
+++ b/gbp/scripts/import_orig.py
@@ -21,11 +21,13 @@ import ConfigParser
 import os
 import sys
 import tempfile
+import shutil
 import gbp.command_wrappers as gbpc
 from gbp.deb import (DebianPkgPolicy, parse_changelog_repo)
 from gbp.deb.uscan import (Uscan, UscanError)
 from gbp.deb.changelog import ChangeLog, NoChangeLogError
 from gbp.deb.git import (GitRepositoryError, DebianGitRepository)
+from gbp.deb.format import DebianSourceFormat
 from gbp.config import GbpOptionParserDebian, GbpOptionGroup, no_upstream_branch_msg
 from gbp.errors import GbpError
 import gbp.log
@@ -292,6 +294,15 @@ def main(argv):
 tmpdir = tempfile.mkdtemp(dir='../')
 source.unpack(tmpdir, options.filters)
 gbp.log.debug(Unpacked '%s' to '%s' % (source.path, source.unpacked))
+# wipe upstream debian/ if package is 3.0 (quilt)
+if os.path.isfile(DebianSourceFormat.format_file) and os.path.isdir(%s %(os.path.join(source.unpacked,debian))):
+try:
+source_format = DebianSourceFormat.parse_file(DebianSourceFormat.format_file)
+if source_format.version == 3.0 and source_format.type == quilt:
+shutil.rmtree(%s %(os.path.join(source.unpacked,debian)))
+gbp.log.info(Deleted 'debian/' directory from unpacked upstream tarball before import)
+except Exception as e:
+raise GbpError(Can't determine package type: %s % e)
 
 if source.needs_repack(options):
 gbp.log.debug(Filter pristine-tar: repacking '%s' from '%s' % (source.path, source.unpacked))
-- 
1.8.5.3



signature.asc
Description: OpenPGP digital signature

Bug#700411: git-buildpackage: git-import-orig should filter the upstream debian directory

[Carlos Alberto Lopez Perez]

On 15/02/14 20:20, Raphael Hertzog wrote:
 Maybe you should put the result of os.path.join(source.unpacked,debian)
 in a variable since you redo the same operation a few lines later.
 
 And you might want to wrap this on 2 lines since it's very long.
 
 +try:
 +source_format = 
 DebianSourceFormat.parse_file(DebianSourceFormat.format_file)
 +if source_format.version == 3.0 and 
 source_format.type == quilt:
 +shutil.rmtree(%s 
 %(os.path.join(source.unpacked,debian)))
 +gbp.log.info(Deleted 'debian/' directory from 
 unpacked upstream tarball before import)
 +except Exception as e:
 +raise GbpError(Can't determine package type: %s % e)
 
 What exception are you trying to catch here? You already checked that we
 have a debian/source/format file.

Yes, you are right, that try-except don't makes much sense.

Thanks for your comments.


I'm attaching a new version of the patch.
From e1f709dd117ee5e97feda9dd02d88aaabfe9b00c Mon Sep 17 00:00:00 2001
From: Carlos Alberto Lopez Perez clo...@igalia.com
Date: Sat, 15 Feb 2014 18:57:52 +0100
Subject: [PATCH] Filter upstream debian directory on packages 3.0 (quilt)
 (#700411)

---
 gbp/scripts/import_orig.py | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gbp/scripts/import_orig.py b/gbp/scripts/import_orig.py
index aae93fa..d5e1d4c 100644
--- a/gbp/scripts/import_orig.py
+++ b/gbp/scripts/import_orig.py
@@ -21,11 +21,13 @@ import ConfigParser
 import os
 import sys
 import tempfile
+import shutil
 import gbp.command_wrappers as gbpc
 from gbp.deb import (DebianPkgPolicy, parse_changelog_repo)
 from gbp.deb.uscan import (Uscan, UscanError)
 from gbp.deb.changelog import ChangeLog, NoChangeLogError
 from gbp.deb.git import (GitRepositoryError, DebianGitRepository)
+from gbp.deb.format import DebianSourceFormat
 from gbp.config import GbpOptionParserDebian, GbpOptionGroup, no_upstream_branch_msg
 from gbp.errors import GbpError
 import gbp.log
@@ -292,6 +294,13 @@ def main(argv):
 tmpdir = tempfile.mkdtemp(dir='../')
 source.unpack(tmpdir, options.filters)
 gbp.log.debug(Unpacked '%s' to '%s' % (source.path, source.unpacked))
+# wipe upstream debian/ if package is 3.0 (quilt)
+upstream_debiandir = os.path.join(source.unpacked, debian)
+if os.path.isdir(upstream_debiandir) and os.path.isfile(DebianSourceFormat.format_file):
+source_format = DebianSourceFormat.parse_file(DebianSourceFormat.format_file)
+if source_format.version == 3.0 and source_format.type == quilt:
+shutil.rmtree(upstream_debiandir)
+gbp.log.info(Deleted 'debian' directory from unpacked upstream tarball before import)
 
 if source.needs_repack(options):
 gbp.log.debug(Filter pristine-tar: repacking '%s' from '%s' % (source.path, source.unpacked))
-- 
1.8.5.3



signature.asc
Description: OpenPGP digital signature

Bug#726661: Does not permit login as root from version 1:6.2p2-6

[Carlos Alberto Lopez Perez]

found 726661 1:6.4p1-2
thanks

Hi,

Current version on testing is also affected.

I hit this bug after upgrading a machine. After rebooting it I was unable to 
login again.

On /var/log/auth.log was the following error:
sshd[10480]: error: PAM: pam_open_session(): Cannot make/remove an entry for 
the specified session

The machine is configured with PAM/LDAP.

Downgrading openssh-server to the version on stable (1:6.0p1-4) fixed the 
problem.



signature.asc
Description: OpenPGP digital signature

Bug#726661: Does not permit login as root from version 1:6.2p2-6

[Carlos Alberto Lopez Perez]

On 13/02/14 22:19, Colin Watson wrote:
 On Thu, Feb 13, 2014 at 08:14:15PM +0100, Carlos Alberto Lopez Perez wrote:
 I hit this bug after upgrading a machine. After rebooting it I was
 unable to login again.
 
 Unfortunately I haven't successfully reproduced this yet ...
 
 On /var/log/auth.log was the following error:
 sshd[10480]: error: PAM: pam_open_session(): Cannot make/remove an entry for 
 the specified session
 
 Could you clarify whether pam_loginuid(sshd:session): set_loginuid
 failed is also in the log, as per the first message in this bug report?
 

Yes. The complete auth.log for a failed attempt to login as root is:


Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: Accepted publickey for root from 
192.168.0.121 port 37267 ssh2: DSA 
1a:f2:16:e1:71:43:62:b6:13:af:91:67:e6:f0:59:8a
Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: pam_loginuid(sshd:session): 
set_loginuid failed
Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: pam_unix(sshd:session): session 
opened for user root by (uid=0)
Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: error: PAM: pam_open_session(): 
Cannot make/remove an entry for the specified session
Feb 13 10:57:41 bb-webkit2-rel-64 sshd[10480]: Received disconnect from 
192.168.0.121: 11: disconnected by user


Is also worth telling that not only login as root was failing,
but also login as any other normal user via PAM/LDAP: 

Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_unix(sshd:auth): 
authentication failure; logname= uid=0 euid=0 tty=ssh ruser= 
rhost=ip121.dynamic.igalia.com  user=clopez
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: Accepted password for clopez 
from 192.168.0.121 port 37262 ssh2
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_loginuid(sshd:session): 
set_loginuid failed
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: pam_unix(sshd:session): session 
opened for user clopez by (uid=0)
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10409]: error: PAM: pam_open_session(): 
Cannot make/remove an entry for the specified session
Feb 13 10:57:09 bb-webkit2-rel-64 sshd[10413]: Received disconnect from 
192.168.0.121: 11: disconnected by user


I didn't tried with a local normal (not-root) user,
but I can give it a try if you think is worth.



signature.asc
Description: OpenPGP digital signature

Bug#731155: arpwatch consumes excessive CPU with libpcap0.8 1.5.1-1

[Carlos Alberto Lopez Perez]

On 12/02/14 22:58, Arthur Marsh wrote:
 
 
 Florian Schlichting wrote, on 13/02/14 07:48:
 Hi Arthur, Carlos,

 the issue you reportied looks a lot like
 https://github.com/the-tcpdump-group/libpcap/issues/333 or
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733747, which was
 fixed in libpcap 1.5.3 (uploaded 2014-01-16, in jessie since
 2014-01-27).

 As I'm unable to reproduce the issue today, would you care to check if a
 current libpcap0.8 = 1.5.3 makes the infinite loop go away?

 Florian


 
 Hi, I don't appear to be having this problem with
 
 libpcap0.8:i386 1.5.3-2
 
 Regards,
 
 Arthur.
 

Same here. The problem seems fixed.

Thanks!



signature.asc
Description: OpenPGP digital signature