Bug#1051577: iproute2: obsolete conffiles

[Ian Campbell]

On Tue, 2023-09-12 at 23:13 +0200, Luca Boccassi wrote:
> On Mon, 11 Sept 2023 at 15:57, Daniel Gröber 
> wrote:
> > 
> > Hi Luca,
> > 
> > On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> > > > I want to question whether removing these conffiles is a good idea at
> > > > all. I'm probably one of the few people that actually muck around in 
> > > > there
> > > > but it seems like this is going to break things for any users that do.
> > > 
> > > As far as I understand dpkg's conffile machinery should recognize if
> > > you changed anything, and leave it in place. Upstream moved the
> > > default ones to /usr, so we just follow what they do.
> > 
> > Right. Think of an admin having to adjust these config files though:
> > previously they could just `editor /etc/iproute2/rt_tables` and get on with
> > things. Now anyone needing to do that will have to do a doubletake, figure
> > out why /etc/iproute2 is missing, realize that it's at /usr/lib/iproute2
> > now, copy that over and finally edit.
> > 
> > Is that friction really warrented to cater to a specialized niche use-case?
> > 
> > Please consider overriding upstream's decision here.
> 
> Yes, it is warranted, both because it's exactly the correct behaviour
> for a package, and also because we are certainly not spending time and
> resources to go against upstream choices, especially when they are the
> right choices.

What is the plan for handling updates? AIUI we've lost the dpkg
conffile handling but it doesn't look like it's been replaced by
anything (e.g. like using ucf to prompt when an update happened
perhaps?).

Ian.

Bug#1029513: xss-lock: crashes with core dump on activation

[Ian Campbell]

Control: severity -1 important
Control: tags -1 +help

On Mon, 2023-01-23 at 11:04 -0500, Stuart Freeman wrote:
> Calling `xdg-screensaver activate` causes xss-lock to dump core.

Thank you for your report.

>From the logs it looks like xss-lock is actually hitting an assertion
which manifests in a core dump:

>     Jan 23 09:52:48 gamera xss-lock[8434]: Error getting session: 
> GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not belong to 
> any known session.
>     Jan 23 09:53:05 gamera xss-lock[8434]: xss-lock: ./src/xss-lock.c:469: 
> logind_session_set_locked_hint: Assertion `logind_session' failed.

I've tried to repro but unfortunately I can't.

It seems like xss-lock is failing to talk to logind on your system. I'm
not sure why this would be, is it possible that logind on your system
is not running or is otherwise misconfigured? 

I launch xss-lock from .i3/config rather than the system unit which you
seem to be using, it's possible that's related? Perhaps the unit needs
to depend (requires?) on some other services for ordering (e.g. logind
or maybe dbus session which is used to talk to logind)? Some sort of
`Requires=dbus.service` type thing maybe?

Since I don't use this configuration and I'm not especially familiar
with system user units I have no good advice on how to do this, or how
to go about debugging, sorry.

Since it does not appear to be generally broken for everyone I have
downgraded the severity to important.

Thanks again,
Ian.

Bug#1016963: Please test u-boot for dreamplug

[Ian Campbell]

On Sat, 2023-01-21 at 12:09 -0800, Vagrant Cascadian wrote:
> On 2022-12-29, Ian Campbell wrote:
> > On Wed, 2022-12-28 at 16:30 -0800, Vagrant Cascadian wrote:
> > > dreamplug
> > 
> > booting u-boot and Debian both from external mmc
> > 
> >   testing: 2022.04+dfsg-2+b1  "FDT and ATAGS support not compiled
> > in" then resets and loops doing that
> > unstable: 2022.10+dfsg-2 ok
> >   exp: 2023.01~rc4+dfsg-1 ok
> 
> Any chance you could test 2023.01+dfsg-1 and/or 2023.01+dfsg-2 on the
> dreamplug? Someone had problems with sheevaplug, which I think is a
> fairly similar platform.

Done, both versions worked fine on dreamplug.

I also think dreamplug is a fairly similar platform to sheevaplug, but
I have no personal experience of the latter.

Ian.

Bug#1016963: Please test u-boot for dreamplug jetson-tk1 Bananapi Cubieboard2 Cubietruck

[Ian Campbell]

On Wed, 2022-12-28 at 16:30 -0800, Vagrant Cascadian wrote:
> jetson-tk1

 testing: 2022.04+dfsg-2+b1  ok
unstable: 2022.10+dfsg-2 ok
 exp: 2023.01~rc4+dfsg-1 ok

> Bananapi

I don't seem to have a working setup for this any more, sorry.

> Cubieboard2 

 testing: 2022.04+dfsg-2+b1  ok
unstable: 2022.10+dfsg-2 ok
 exp: 2023.01~rc4+dfsg-1 ok

I mentioned those successes on the wiki.

Bug#1016963: Please test u-boot for dreamplug jetson-tk1 Bananapi Cubieboard2 Cubietruck

[Ian Campbell]

On Wed, 2022-12-28 at 16:30 -0800, Vagrant Cascadian wrote:
> On 2022-12-28, Vagrant Cascadian wrote:
> > On 2022-12-22, Vagrant Cascadian wrote:
> > > On 2022-08-20, Vagrant Cascadian wrote:
> > > > On 2022-08-10, Vagrant Cascadian wrote:
> > > > > This bug is just to delay migration to testing while more
> > > > > platforms get
> > > > > tested. If you have a relevent board, please consider testing
> > > > > and
> > > > > reporting the status:
> > > > > 
> > > > >    https://wiki.debian.org/U-boot/Status
> > 
> > I have not received many test results for current or even remotely
> > recent u-boot platforms in Debian, and u-boot has been blocked from
> > migration to testing partly because of this.
> > 
> > As the bookworm freeze approaches, this is getting to be...
> > worrysome!
> > 
> > If you have access to any of these boards, please consider testing
> > u-boot versions as packaged in debian for versions from debian
> > stable
> > (2021.01*), testing (2022.04*), unstable (2022.10*) and
> > experimental
> > (2023.01-rc*) and updating the wiki page if successful and/or
> > replying
> > to 1016...@bugs.debian.org with a positive confirmation...
> > 
> > ...and if not successful, filing bugs against the relevent u-boot-*
> > packages and marking them as blocking 1016963.
> 
> dreamplug

booting u-boot and Debian both from external mmc

 testing: 2022.04+dfsg-2+b1  "FDT and ATAGS support not compiled in" then 
resets and loops doing that
unstable: 2022.10+dfsg-2 ok
 exp: 2023.01~rc4+dfsg-1 ok

comparing the config of 2022.04+dfsg-2+b1 vs 2022.10+dfsg-2 I see:

   -# CONFIG_SUPPORT_PASSING_ATAGS is not set
   +# CONFIG_ARCH_GXP is not set
   +CONFIG_SUPPORT_PASSING_ATAGS=y
   +CONFIG_SETUP_MEMORY_TAGS=y
   +CONFIG_CMDLINE_TAG=y
   +CONFIG_INITRD_TAG=y
   
which I suspect explains the failure in 2022.04+dfsg-2+b1.

> jetson-tk1
> Bananapi
> Cubieboard2 

I have these somewhere, I think in a box in the loft, I have to go up
there later anyway so will see if I can find any of them.

> Cubietruck

u-boot on mmc + Debian on sata:

 testing: 2022.04+dfsg-2+b1  ok
unstable: 2022.10+dfsg-2 ok
 exp: 2023.01~rc4+dfsg-1 ok

I've updated the wiki with the 5 successes, I didn't update the
dreamplug testing entry nor file a bug, I assume 2022.10+dfsg-2 will
eventually be allowed to migrate to fix that issue.


Ian.

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Ian Campbell]

On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote:
> The attached patch is an attempt to grow the buffer size
> if the header changes on a new page.
> This is just tested for the given crash, nothing more, therefore
> there might be side effects on replacing this buffer?

It doesn't look unreasonable to me, although the related shuffling of
pointers between rgbRaster, kRaster and m_pPrinterBuffer makes my head
hurt a bit (this code could really do with a dollop of modern c++
memory management idiom).

Do you think there is a need to preserve the current contents (e.g.
something approximating realloc rather than delete+new)? Or maybe it is
fine to simply unconditionally allocate a new buffer each time round
the loop? It could almost be a local variable like *Raster at that
point... But I think if you are looking for a minimal fix your patch
seems pretty sensible to me (speaking as a competent enough C/C++
programmer but not someone familiar with this codebase before today).

Ian.

Bug#974828: Fwd: Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Ian Campbell]

Control: found -1 3.20.11+dfsg0-2
Control: found -1 3.21.2+dfsg1-1

On Thu, 2021-02-25 at 18:32 +, Ian Campbell wrote:
> I'll see if I can upgrade and repeat.

Confirmed I see this with both the current bullseye and sid versions of
printer-driver-hpcups.

Ian.

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Ian Campbell]

Package: printer-driver-hpcups
Version: 3.20.9+dfsg0-4
Severity: serious
Tags: upstream
Justification: #972339

Dear Maintainer,

I have just filed this crash at https://bugs.launchpad.net/hplip/+bug/1904318

dagon:/tmp# /usr/lib/cups/filter/hpcups 1 debian '' 1 '' 
print_step_3.hpcups
STATE: -marker-supply-low-warning
PAGE: 1 1
PAGE: 2 1
free(): invalid next size (normal)
Aborted (core dumped)

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f5af802c537 in __GI_abort () at abort.c:79
#2  0x7f5af80856c8 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f5af8193e31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f5af808c9ba in malloc_printerr (str=str@entry=0x7f5af8196238 
"free(): invalid next size (normal)") at malloc.c:5347
#4  0x7f5af808de8c in _int_free (av=0x7f5af81c5b80 , 
p=0x561e3ecd1fc0, have_lock=) at malloc.c:4322
#5  0x561e3d1255c6 in HPCupsFilter::cleanup (this=0x561e3d1881c0 
) at prnt/hpcups/HPCupsFilter.cpp:227
#6  0x561e3d127df1 in HPCupsFilter::closeFilter (this=0x561e3d1881c0 
) at prnt/hpcups/HPCupsFilter.cpp:221
#7  HPCupsFilter::StartPrintJob (this=0x561e3d1881c0 , 
argc=, argv=0x7fffb82c6f18) at prnt/hpcups/HPCupsFilter.cpp:604
#8  0x7f5af802dcca in __libc_start_main (main=0x561e3d124e10 , argc=6, argv=0x7fffb82c6f18, init=, fini=, rtld_fini=, stack_end=0x7fffb82c6f08) at 
../csu/libc-start.c:308
#9  0x561e3d124efa in _start () at prnt/hpcups/HPCupsFilter.cpp:919

There are some similarities with Debian bug #972339 but not enoguh for me to
feel confident in adding this there (note that I am on amd64 not armhf).

Since it is a crash I think it is worth tracking in our BTS.

Thanks,
Ian.

-- Package-specific info:
Saving output in log file: /home/ijc/hp-check.log

HP Linux Imaging and Printing System (ver. 3.20.9)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling 
the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper 
dependencies are installed to successfully compile HPLIP.   

2. Run-time check mode (-r or --run): Use this mode to determine if a distro 
supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball 
has the proper dependencies installed to successfully run.  
  
3. Both compile- and run-time check mode (-b or --both) (Default): This mode 
will check both of the above cases (both compile- and run-time dependencies).   



Check types:


 
a. EXTERNALDEP - External Dependencies  


 
b. GENERALDEP - General Dependencies (required both at compile and run time)


 
c. COMPILEDEP - Compile time Dependencies   


 
d. [All are run-time checks]


 
PYEXT SCANCONF QUEUES PERMISSION


 

Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

warning: debian-testing version is not supported. Using debian-10.4 versions 
dependencies to verify and 

Bug#963294: cmake-format: FTBFS: ./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'

[Ian Campbell]

On Sat, 2020-06-27 at 12:54 +0200, Gianfranco Costamagna wrote:
> Hello Ian,
> 
> > It seems like pybuild has some heuristics for picking the build
> plugin
> > to use, for me (and buildd) it selects plugin_distutils.py but for
> you
> > it is selecting plugin_cmake.py. I can't see why. If you somehow
> had a
> > `CMakeCache.txt` in the package directory that might explain it,
> but
> > there's no reason for one of those to be there (I assume you'd have
> > said if this was e.g. a repeated build without cleaning the package
> dir
> > in the middle, but even if it was I don't think I'd ).
> > 
> > In the absence of a local repro I'm going to throw in a
> > 'PYBUILD_SYSTEM=distutils' which ought to force things to go the
> > desired way no matter what. Fingers crossed!
> > 
> 
> 
> I agree on your analysis.
> In Ubuntu the build has been failing since the begin, and for some
> reasons it started being successful yesterday, before your upload.
> 
> I can say that I tried to use a patched pybuild
> -log.debug('detected build system: %s (certainty: %s%%)',
> plugin.NAME, certainty)
> +log.info('detected build system: %s (certainty: %s%%)',
> plugin.NAME, certainty)
> 
> and the certainty was 50% fixed 
> I: pybuild pybuild:131: detected build system: distutils (certainty: 50%)
> 
> versus
> I: pybuild pybuild:131: detected build system: cmake (certainty: 50%)

Thanks, I wonder if when both are the same there is some randomness in
the choice, maybe based on e.g. order of the files in the unsorted
directory (which might be fixed for a given base image, so it might not
be random for a given setup but only between setups?).

> I can say, on Ubuntu builders, cmake was always pick up (not since
> yesterday), while on local pbuilder and Debian, distutils was pick up
> 
> if you rebuild locally after the first build, the counter increases
> to 60%.

Which choice becomes 60%?

cmake plugin has (the number is the extra score):

OPTIONAL_FILES = {'cmake_uninstall.cmake': 10, 'CMakeCache.txt': 10}

while distutils has:

OPTIONAL_FILES = {'setup.cfg': 1,
  'requirements.txt': 1,
  'PKG-INFO': 10,
  '*.egg-info': 10}

So I guess one of those 10-point files is left after the first build.


> This is my wild guess, but teaching pybuild to don't care about it
> looks a sane option.

Thanks, I uploaded -3 this morning which forces distutils.

> 
> Just my .02$
> 
> Gianfranco
> 

Bug#963294: cmake-format: FTBFS: ./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create'

[Ian Campbell]

On Sun, 2020-06-21 at 21:52 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks for the report Lucas.

I tried reproducing locally with:

sbuild -n -A -s --force-orig-source --apt-update -d unstable -v 
--no-run-lintian cmake-format_0.6.10-2.dsc

but the build was successful.

> Relevant part (hopefully):
> > /usr/bin/ld: CMakeFiles/cmTC_892ca.dir/src.c.o: in function `main':
> > ./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/src.c:11:
> >  undefined reference to `pthread_create'
> > /usr/bin/ld: 
> > ./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/src.c:12:
> >  undefined reference to `pthread_detach'
> > /usr/bin/ld: 
> > ./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/./.pybuild/cpython3_3.8/build/CMakeFiles/CMakeTmp/src.c:13:
> >  undefined reference to `pthread_join'
> > collect2: error: ld returned 1 exit status

There's also a little earlier:

   -- Looking for pthread.h
   -- Looking for pthread.h - found
   -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
   -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed

Which is not present in the successful builds.

What's weird is that in my local build and on the buildd I see:

  dh_auto_configure -O--buildsystem=pybuild
   pybuild --configure -i python{version} -p 3.8
   I: pybuild base:217: python3.8 setup.py config 
   running config
  dh_auto_build -O--buildsystem=pybuild
   pybuild --build -i python{version} -p 3.8
   I: pybuild base:217: /usr/bin/python3 setup.py build 

(buildd is slightly different since it has an extra `-i`)

Whereas in your log I see:

   dh_auto_configure -O--buildsystem=pybuild
pybuild --configure -i python{version} -p 3.8
I: pybuild base:217: dh_auto_configure --buildsystem=cmake 
--builddirectory="/<>/.pybuild/cpython3_3.8/build" -- <...snip...>
cd .pybuild/cpython3_3.8/build && <...>

It seems like pybuild has some heuristics for picking the build plugin
to use, for me (and buildd) it selects plugin_distutils.py but for you
it is selecting plugin_cmake.py. I can't see why. If you somehow had a
`CMakeCache.txt` in the package directory that might explain it, but
there's no reason for one of those to be there (I assume you'd have
said if this was e.g. a repeated build without cleaning the package dir
in the middle, but even if it was I don't think I'd ).

In the absence of a local repro I'm going to throw in a
'PYBUILD_SYSTEM=distutils' which ought to force things to go the
desired way no matter what. Fingers crossed!

Cheers,
Ian.

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Ian Campbell]

On Tue, 2019-09-24 at 10:05 +0100, Mark Hindley wrote:
> Ian,
> 
> Thanks for this.
> 
> On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> > On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> > Would it be any help at all of the "dbus client-ish" bits and the
> > "direct API-ish" bits of the two libraries were split up into two
> > separate libraries? i.e. would that allow the c/r/p replacement of
> one
> > of the two libraries (AIUI the API one is the more problematic) to
> be
> > pushed further up the dependency stack?
> 
> I think that is what we already have (if I have understood you correctly). The
> dbus components are in systemd/elogind and the sd-*(3) APIs are in
> libsystemd0/libelogind0. Or have I misunderstood?

Probably I have, I thought the dbus client side stuff was in
libsystemd0/libelogind0 too.

> > Has anyone investigated late dynamic binding using a stub library which
> > merely determines which init is running and then dlopens the
> > appropriate libsystemd0 of libelogind0 library and forwards the calls
> > to it?
>  
> > I don't know if the dynamic linker could be coerced into doing the
> > selection automagically, in a way similar to how the hwcap stuff can be
> > used to pickup versions of libraries optimised for different classes of
> > processor. hwcap is provided by the kernel so I think can't be used
> > directly, but maybe there is a parallel mechanism somewhere?
> 
> I think Adam Borowski suggested somthing similar a while ago as an option, 
> but I
> am not aware of anything more than an idea.

Might be worth a PoC?

> I also experimented with LD_PRELOAD a while ago. But it felt very hackish.

Yeah. that's probably not the way to go.

Ian.

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Ian Campbell]

On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> > Hello,
> > 
> > When I looked I elogind a while back I was able to build a package without
> > having a public libelogind0, I basically had that in my debian/rules file:
> > 
> > # We only build the libelogind0 and libelogind-dev if we are building for
> > # Devuan or its derivatives
> > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes)
> > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev
> > endif
> > 
> > libelogind library is only needed for applications that want to interact
> > with the daemon, in the ITP (#905388) bug I also noted that.
> > 
> > If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to
> > communicate with the daemon part, was it checked that the API used is
> > compatible? Is there documentation of the differences, if any?
> 
> Yes, the APIs are the same (deliberately so).
> 
> > Bottom line, is libelogind even needed in the archive to achieve your goal
> > of having an implementation of the login1 D-Bus API not requiring systemd as
> > PID1?
> 
> Thanks.
> 
> I think you are correct that the login1 DBus API doesn't require libsystemd0 
> or
> libelogind0. However some packages, notably policykit use the sd-login(3) API
> which is part of libsystemd0 or libelogind0. Whilst the APIs, and symbol ABIs
> are the same between the two libraries (with the caveats noted in the
> libelogind0 package description) the implementations differ. I have been tolkd
> int he past by elogind upstream that it is not possible for elogind to use
> libsystemd0. For example libsystemd0 requires the concept of slices which
> elogind doesn't have.

Would it be any help at all of the "dbus client-ish" bits and the
"direct API-ish" bits of the two libraries were split up into two
separate libraries? i.e. would that allow the c/r/p replacement of one
of the two libraries (AIUI the API one is the more problematic) to be
pushed further up the dependency stack?

(my impression is no, but I thought I'd ask)

> The only way I have got all of these components to work together on an elogind
> systemd is to ensure everything uses libelogind0.

Has anyone investigated late dynamic binding using a stub library which
merely determines which init is running and then dlopens the
appropriate libsystemd0 of libelogind0 library and forwards the calls
to it?

I don't know if the dynamic linker could be coerced into doing the
selection automagically, in a way similar to how the hwcap stuff can be
used to pickup versions of libraries optimised for different classes of
processor. hwcap is provided by the kernel so I think can't be used
directly, but maybe there is a parallel mechanism somewhere?

Ian.

Bug#918465: sunxi-tools installation fils without udev installed

[Ian Campbell]

On Sun, 2019-01-06 at 13:32 +0200, Adrian Bunk wrote:
> Package: sunxi-tools
> Version: 1.4.2+git20181114.6d598a-2
> Severity: serious
> 
> https://piuparts.debian.org/sid/fail/sunxi-tools_1.4.2+git20181114.6d598a-2.log

Thanks, I was just working on a fix having spotted the report on
tracker.debian.org, upload coming shortly.

Ian.

Bug#907298: CVE-2018-15869

[Ian Campbell]

On Thu, 2018-10-18 at 11:48 +0800, Shengjing Zhu wrote:
> Package: awscli
> Followup-For: Bug #907298
> 
> The corresponding bug on Redhat is closed as
> 
> > Closing this bug as NOTABUG and asked MITRE for rejection, since the issue
> > does not seem to be in AWS CLI but in Packer.
> 
> Can we downgrade this bug and keep awscli in buster?

Not sure why I was cc-d on this, perhaps you got the wrong person?

In any case I've no idea what the correct response is here.

Ian.

Bug#907171: prometheus FTBFS:

[Ian Campbell]

On Thu, 2018-08-30 at 13:23 +0100, Martín Ferrari wrote:

> > Unless the tests are run in their own network namespace (which provides
> > some guarantees over what else might be bound to a port, I can't seem
> > to find logs which would confirm or deny if a netns was in use here
> > though) probably the test needs to use a random port or otherwise be
> > tollerant of 9090 not being available. 

> Right, but this can't be done without root, and buildds do not give root.

I don't think that applies to the "needs to use a random port or otherwise be
tollerant of 9090 not being available" which was the main thrust of my comment.

> > Maybe there is (or should be) an autopkgtest flag to request a clean
> > netns be used?
> 
> This discussion is about a FTBFS bug, not about the CI system. ALso,
> that would not solve the issue, as it is autopkgtest installing (and
> therefore starting) prometheus.

So the issue is a parallel (but unrelated) autopkgtest run on the same
host interfering with builds which are happening at the same time? (I
had thought the autopkgtest was part of the build hence → FTBFS, seems
I was misunderstanding then, sorry for the noise on that front)

Ian.

Bug#907171: prometheus FTBFS:

[Ian Campbell]

On Mon, 2018-08-27 at 19:18 +0100, Martín Ferrari wrote:
> On 27/08/18 17:08, Adrian Bunk wrote:
> 
> > How often did you try?
> > 
> > I would say the probability to hit is somewhere around 50%:
> > https://tests.reproducible-builds.org/debian/history/prometheus.html
> 
> I just tried 20 builds, while using desktop applications that put some
> extra strain on tHE CPU, and none failed..

Port 9090 isn't reserved or privileged at all afaik so it's not out of
the question that some other random outgoing socket connection might be
using it as a source port (or listening on it) at any given point,
whether it is prom running on the host or something else.

Does `nc -l -p 9090` repro the test failure perhaps?

Unless the tests are run in their own network namespace (which provides
some guarantees over what else might be bound to a port, I can't seem
to find logs which would confirm or deny if a netns was in use here
though) probably the test needs to use a random port or otherwise be
tollerant of 9090 not being available. 

Maybe there is (or should be) an autopkgtest flag to request a clean
netns be used?

Ian.

Bug#905574: linux-image-4.17.0-0.bpo.1-amd64: cryptsetup missing in intitramfs for kernel 4.17

[Ian Campbell]

On Mon, 2018-08-06 at 23:47 +0800, Ben Hutchings wrote:
> On Mon, 2018-08-06 at 14:40 +0100, Ian Campbell wrote:
> > On Mon, 2018-08-06 at 21:15 +0800, Ben Hutchings wrote:
> > > > Inspecting the initramfs shows that the cryptsetup related
> > > > parts are
> > > > missing for 4.17, but still in the 4.16 kernel.
> > > > 
> > > > I was able to mitigate the issue by use the cryptsetup packages
> > > > from
> > > > buster.
> > > 
> > > This is strange.  Kernel packages do not determine what goes into
> > > the
> > > initramfs.
> > 
> > Possibly the cryptsetup package changed (and become broken). Then
> > the
> > 4.17 initramfs was (re)built (due to the install/upgrade of that
> > kernel) while the 4.16 initramfs wasn't rebuilt.
> 
> In stable?  (There's no backport of cryptsetup.)

Ah, sorry, I didn't read close enough and somehow thought this was in
unstable.

For stable/bpo s/the cryptsetup package/some package/.

> > I expected that there were be triggers in place which should have
> > caused the 4.16 initramfs (in fact, all initramfses) to be updated
> > if a
> > relevant package (e.g. cryptsetup) was changed, but perhaps that
> > was
> > more in hope than expectation and it's only an initramfs-tools
> > update
> > which would trigger that?
> 
> Installing or upgrading cryptsetup will trigger an update of the newest
> installed kernel version's initramfs.

Thanks, that would potentially explain why 4.16 continues to work (it
has an older working initramfs).

Ian.

Bug#905574: linux-image-4.17.0-0.bpo.1-amd64: cryptsetup missing in intitramfs for kernel 4.17

[Ian Campbell]

On Mon, 2018-08-06 at 21:15 +0800, Ben Hutchings wrote:
> > Inspecting the initramfs shows that the cryptsetup related parts are
> > missing for 4.17, but still in the 4.16 kernel.
> > 
> > I was able to mitigate the issue by use the cryptsetup packages from
> > buster.
> 
> This is strange.  Kernel packages do not determine what goes into the
> initramfs.

Possibly the cryptsetup package changed (and become broken). Then the
4.17 initramfs was (re)built (due to the install/upgrade of that
kernel) while the 4.16 initramfs wasn't rebuilt.

I expected that there were be triggers in place which should have
caused the 4.16 initramfs (in fact, all initramfses) to be updated if a
relevant package (e.g. cryptsetup) was changed, but perhaps that was
more in hope than expectation and it's only an initramfs-tools update
which would trigger that?

Ian.

Bug#885914: [s3cmd] "RuntimeError: dictionary changed size during iteration" in s3cmd put

[Ian Campbell]

Sorry for the unexplained reopen, I expected `bts reopen` to give me
the opportunity to write something.

AFAICT the upstream bug remains open and [0] indicates that the
workaround is only temporary. Neither [1] nor any of the issues it
links to as closed seem related and [2] does show any changes relating
to the stack trace (none at all to `HashCache.py` where the issue
actually occurred and one unrelated change to `FileLists.py` which is
next up in the call chain).

So I think closing this was premature and have reopened.

Thanks,
Ian.

[0] https://github.com/s3tools/s3cmd/issues/945#issuecomment-380941767
[1] https://github.com/s3tools/s3cmd/releases/tag/v2.0.2
[2] https://github.com/s3tools/s3cmd/compare/v2.0.1...v2.0.2

Bug#899766: ivtv-utils: Invalid maintainer address pkg-mythtv-maintain...@lists.alioth.debian.org

[Ian Campbell]

On Thu, 2018-05-24 at 09:27 +0100, Ian Campbell wrote:
> So I think removing ivtv-utils from Debian is probably the best
> answer.
> Unless someone from the X-Debbugs-Cc line suggests oherwise I will do
> so, lets say on or after 1 June 2018 (a bit over a week from today).

Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900631

Ian.

Bug#899766: ivtv-utils: Invalid maintainer address pkg-mythtv-maintain...@lists.alioth.debian.org

[Ian Campbell]

On Thu, 2018-05-24 at 09:44 +0200, Christoph Biedl wrote:
> Package: src:ivtv-utils
> Version: 1.4.1-2
> Severity: serious
> User: ad...@alioth-lists.debian.net
> Usertag: alioth-lists-maintainer
> 
> Dear uploader of ivtv-utils,
> 
> as you've probably heard, Debian's alioth services are shutting down.
> This affects your package ivtv-utils since the list address
> pkg-mythtv-maintain...@lists.alioth.debian.org used in the Maintainer:
> field was not transferred to the alioth-lists service that provides a
> continuation for the lists in the @lists.alioth.debian.org domain.

Thanks for your report.

I think the ivtv-utils have mostly been subsumed into v4l-utils or
otherwise been made obsolete (the driver itself has been in the
upstream kernel for ages).

Personally I no longer have any ivtv based hardware (the UK switched to
a digital broadcasting standard some time ago) to use or test with
(well, TBH, I suspect I have some in a cupboard somewhere, but it is
largely useless to me...).

The upstream domain, ivtvdriver.org, appears to have lapsed and is now
owned by some domain parking service.

So I think removing ivtv-utils from Debian is probably the best answer.
Unless someone from the X-Debbugs-Cc line suggests oherwise I will do
so, lets say on or after 1 June 2018 (a bit over a week from today).

I've CC-d the O: bug for this package too in case anyone else is
subscribed to that.

Ian.

Bug#885914: "RuntimeError: dictionary changed size during iteration" in s3cmd put

[Ian Campbell]

Package: s3cmd
Version: 2.0.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

s3cmd put is failing with:

!
An unexpected error has occurred.
  Please try reproducing the error using
  the latest s3cmd code from the git master
  branch found at:
https://github.com/s3tools/s3cmd
  and have a look at the known issues list:

https://github.com/s3tools/s3cmd/wiki/Common-known-issues-and-their-solutions
  If the error persists, please report the
  following lines (removing any private
  info as necessary) to:
   s3tools-b...@lists.sourceforge.net


!

Invoked as: /usr/bin/s3cmd --ssl --config=/tmp/tmp.akNQcIMsdc --acl-private 
put --cache-file=«path»/.s3cmd.cache --encrypt «files...» s3://«bucket»/
Problem: 
rc = main()
  File "/usr/bin/s3cmd", line 2989, in main
rc = cmd_func(args)
  File "/usr/bin/s3cmd", line 364, in cmd_object_put
local_list, single_file_local, exclude_list, total_size_local = 
fetch_local_list(args, is_src = True)
  File "/usr/lib/python3/dist-packages/S3/FileLists.py", line 353, in 
fetch_local_list
_maintain_cache(cache, local_list)
  File "/usr/lib/python3/dist-packages/S3/FileLists.py", line 311, in 
_maintain_cache
cache.purge()
  File "/usr/lib/python3/dist-packages/S3/HashCache.py", line 49, in purge
for i in self.inodes[d].keys():
RuntimeError: dictionary changed size during iteration

/tmp/tmp.akNQcIMsdc contains:
[default]
access_key = «access key»
acl_public = False
bucket_location = EU
cloudfront_host = cloudfront.amazonaws.com
cloudfront_resource = /2008-06-30/distribution
default_mime_type = binary/octet-stream
delete_removed = False
dry_run = False
encoding = UTF-8
encrypt = False
force = False
get_continue = False
gpg_command = /usr/bin/gpg
gpg_decrypt = %(gpg_command)s --homedir /usr/local/backups/gpghome -d 
--verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o 
%(output_file)s %(input_file)s
gpg_encrypt = %(gpg_command)s --homedir /usr/local/backups/gpghome 
--cipher-algo AES256 -c --verbose --no-use-agent --batch --yes --passphrase-fd 
%(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_passphrase = «passphrase»
guess_mime_type = True
host_base = s3.amazonaws.com
host_bucket = %(bucket)s.s3.amazonaws.com
human_readable_sizes = False
list_md5 = False
preserve_attrs = True
progress_meter = True
proxy_host = 
proxy_port = 0
recursive = False
recv_chunk = 4096
secret_key = «secret key»
send_chunk = 4096
simpledb_host = sdb.amazonaws.com
skip_existing = False
use_https = True
verbosity = WARNING
socket_timeout=60

Downgrading to 1.6.1-1 frm Stretch without changing any other packages works
ok.

Thanks,
Ian.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel, arm64

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

Versions of packages s3cmd depends on:
ii  python3   3.6.4~rc1-2
ii  python3-dateutil  2.6.1-1
ii  python3-magic 1:5.32-1

s3cmd recommends no packages.

s3cmd suggests no packages.

-- no debconf information

Bug#749991: Wrong kernel in debian-installer package

[Ian Campbell]

On Mon, 2017-03-27 at 13:32 +0200, Philip Hands wrote:
> > Alexander Sosedkin  writes:
> 
> > On Mon, 27 Mar 2017 12:43:40 +0200
> > > > Philipp Kern  wrote:
> > 
> > > Even if we'd leave the old kernel udebs in testing for a while, you'd 
> > > still hit a point where we'd need to drop them and old installers
> > > would break.
> > 
> > I can see that it's impossible to support downloading modules for all
> > old ISOs.
> 
> > One can always use http://snapshot.debian.org/ as one's mirror and
> specify a dated URL that matches the ISO's creation date.

I think (based on the last few paragraphs in the "Usage" section of
that URL) that one would also need to preseed some stuff to cause it to
accept the expired signatures on that repo (with all that implies wrt
security), not sure if/how that can be done in practice though.

Ian.

Bug#818731: approx: weekly cronjob breaks with removal of Files field from Sources

[Ian Campbell]

On Tue, 2016-11-15 at 20:48 -0500, Eric Cooper wrote:
> On Sun, Mar 20, 2016 at 08:04:56AM +0000, Ian Campbell wrote:
> > I've just received the following in a cron mail:
> >
> > /etc/cron.weekly/approx:
> > File
> /var/cache/approx/debian/dists/experimental/main/source/Sources.xz,
> line 1: missing "Files" field
> > run-parts: /etc/cron.weekly/approx exited with return code 1
> >
> > Which I pressume relates to the changes announced in
> > https://lists.debian.org/debian-devel-announce/2016/03/msg6.htm
> l
> >
> > Tagging as blocking the corresponding archive bug.
> >
> > There is a newer version in sid but the changelog doesn't indicate
> that it
> > resolves this issue.
> 
> I can't reproduce this problem.  When I include a deb-src line for
> experimental,  I don't see any Sources.xz files in my approx server's
> cache.

It perhaps depends on the version of apt being used and which
compression it prefers? My system with experimental configured is a
mostly-testing/some-unstable infrequently updated one, which doesn't
tell us much since I don't know what I was running when that file was
created.

> Can you please send me the output of
> ls -l /var/cache/approx/debian/dists/experimental/main/source/

Some weeks ago my /var/cache/approx filled up so I manually removed
that file and ran the cleanup, which succeeded. However since then I am
sure I've been getting cron messages about other paths, but stupidly I
seem to have been deleting it rather than archiving it.

I've just run the following by hand and it matches what I recall the
most recent cron mail to look like:

root@celaeno:~# /usr/sbin/approx-gc
File /var/cache/approx/debian-multimedia/dists/sid/main/source/Sources.xz, line 
1: missing "Files" field

This will correspond to my mythtv box (another testing/unstable hybrid,
not updated as often as I should) which has in sources.list:

# mythtv, liblame, mplayer etc
deb http://mirror/debian-multimedia/ sid main
deb-src http://mirror/debian-multimedia/ sid main

To answer your question, I see:

root@celaeno:~# ls -lrt /var/cache/approx/debian/dists/experimental/main/source/
total 264
-rw-r--r-- 1 approx approx 261196 Jul 12 03:31 Sources.xz
-- 1 approx approx  0 Oct 19 09:12 Sources
drwxr-xr-x 3 approx approx   4096 Oct 23 04:38 by-hash

Which I suppose is no longer relevant to this bug but I included it
because the files are so old and Sources is zero sized which seemed odd
to me (and doesn't match the official mirrors). I just ran "apt update"
on a system with experimental configured and those files have not
changed (the system also runs cronapt nightly). I then ran "apt update
--print-uris and from that ran "curl -o /dev/null http://mirror/debian/
dists/experimental/main/source/Sources.xz" and now:

root@celaeno:~# ls -lrt /var/cache/approx/debian/dists/experimental/main/source/
total 208
-- 1 approx approx  0 Oct 19 09:12 Sources
drwxr-xr-x 3 approx approx   4096 Oct 23 04:38 by-hash
-rw-r--r-- 1 approx approx 201732 Nov 16 02:18 Sources.xz

I've no idea what is up with a plain "apt update", but not a approx
issue I guess.

WRT this bug I suppose you would now be more interested in:

root@celaeno:~# ls -rtl 
/var/cache/approx/debian-multimedia/dists/sid/main/source
total 348
drwxr-xr-x 2 approx approx   4096 May 22  2013 Sources.diff
-rw-r--r-- 1 approx approx 134988 Jul 24  2015 Sources.gz
-rw-r--r-- 1 approx approx 140282 Jul 30 15:09 Sources.bz2
-rw-r--r-- 1 approx approx  57992 Nov 12 18:08 Sources.xz

A representative first stanza from the Sources.xz is:

Package: 2mandvd-dmo
Binary: 2mandvd, 2mandvd-data
Version: 1:1.8.5-dmo4
Maintainer: Christian Marillat <maril...@deb-multimedia.org>
Build-Depends: debhelper (>= 9), quilt, ccache, libswscale-dev, 
libavformat-dev, libqt4-dev (>= 4:4.7.2~), libqt4-opengl-dev, libqtwebkit-dev, 
libavcodec-dev
Build-Conflicts: qtbase5-dev
Architecture: any all
Standards-Version: 3.9.7
Format: 1.0
Checksums-Sha256:
 9d5882145478bcecaf43cbecc4f70afead88538f669bcbcc08f76c5114f70316 1920 
2mandvd-dmo_1.8.5-dmo4.dsc
 8d34d7fd748f29ab065cec64817628b573dc4781d48fb4ead049a4b7a362f83b 29534393 
2mandvd-dmo_1.8.5.orig.tar.gz
 7e1c97557334517ed9ac974b0e57abccb09cba8b61eefd6c05265c835f894269 11584 
2mandvd-dmo_1.8.5-dmo4.diff.gz
Homepage: http://2mandvd.tuxfamily.org/
Package-List: 
 2mandvd deb video extra arch=any
 2mandvd-data deb video extra arch=all
Directory: pool/main/2/2mandvd-dmo
Priority: extra
Section: misc

AIUI omitting the Files block with their md5 checksums in favour of
Checksums-Sha256 (or other checksum varieties stronger than md5) is
valid and I think something Debian ftp-masters are moving towards as
well (https://lists.debian.org/debian-devel-annou

Bug#816164: nmudiff for 1.2.1-6.3

[Ian Campbell]

I have uploaded 1.2.1-6.3, nmu diff is attached.

Given the length of time since a maintainer upload and the severity I
went with a direct upload rather than delayed. I hope that is ok.

Ian.diff -u flexbackup-1.2.1/debian/changelog flexbackup-1.2.1/debian/changelog
--- flexbackup-1.2.1/debian/changelog
+++ flexbackup-1.2.1/debian/changelog
@@ -1,3 +1,10 @@
+flexbackup (1.2.1-6.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop using defined on hashes (closes: #816164).
+
+ -- Ian Campbell <i...@debian.org>  Sun, 28 Feb 2016 10:14:56 +
+
 flexbackup (1.2.1-6.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u flexbackup-1.2.1/debian/patches/00list flexbackup-1.2.1/debian/patches/00list
--- flexbackup-1.2.1/debian/patches/00list
+++ flexbackup-1.2.1/debian/patches/00list
@@ -10,0 +11 @@
+70_no_defined_on_hash
only in patch2:
unchanged:
--- flexbackup-1.2.1.orig/debian/patches/70_no_defined_on_hash.dpatch
+++ flexbackup-1.2.1/debian/patches/70_no_defined_on_hash.dpatch
@@ -0,0 +1,48 @@
+#!/bin/sh /usr/share/dpatch/dpatch-run
+## 70_no_defined_on_hash.dpatch by Ian Campbell <i...@debian.org>
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Bug #816164 patch by Ian Campbell <i...@debian.org>
+## DP:
+## DP: defined(%hash) and defined(@array) have been deprecated for a while and
+## DP: are now fatal errors:
+## DP:
+## DP: Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at /usr/bin/flexbackup line 1053.
+## DP: Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at /usr/bin/flexbackup line 2688.
+## DP:
+## DP: See http://perldoc.perl.org/perldelta.html#defined%28%40array%29-and-defined%28%25hash%29-are-now-fatal-errors
+## DP:
+## DP: http://perldoc.perl.org/functions/defined.html recommends just checking
+## DP: for length (i.e. removing the defined()). Do so.
+
+@DPATCH@
+diff -urNad flexbackup-svn~/flexbackup flexbackup-svn/flexbackup
+--- flexbackup-svn~/flexbackup	2016-02-28 08:54:08.338589461 +
 flexbackup-svn/flexbackup	2016-02-28 08:56:08.934584524 +
+@@ -1050,7 +1050,7 @@
+ } else {
+ 	$prunekey = $dir;
+ }
+-if (defined(%{$::prune{$prunekey}})) {
++if ($::prune{$prunekey}) {
+ 	("| NOTE: \$prune is ignored for type=dump");
+ }
+ 
+@@ -2685,7 +2685,7 @@
+ }
+ 
+ # Flag old config file
+-if (defined(@cfg::filesystems) or defined($cfg::mt_var_blksize)) {
++if (@cfg::filesystems or defined($cfg::mt_var_blksize)) {
+ 	# so strict shuts up
+ 	my $junk = @cfg::filesystems;
+ 	$junk = $cfg::mt_var_blksize;
+@@ -4883,7 +4883,7 @@
+ 	$prunekey = $dir;
+ }
+ 
+-if (defined(%{$::prune{$prunekey}})) {
++if ($::prune{$prunekey}) {
+ 	# FreeBSD needs -E (above) and no backslashes around the (|) chars
+ 	if ($::uname =~ /FreeBSD/) {
+ 	$cmd .= '-regex "\./(';


signature.asc
Description: This is a digitally signed message part

Bug#816164: flexbackup: Uses removed defined(%hash) and defined(@array) construct

[Ian Campbell]

Package: flexbackup
Version: 1.2.1-6.2
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Perl has been complaining about the use of this deprecated construct for quite
a while now but now since Perl 5.22 has entered the archive it is a fatal error:

Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at 
/usr/bin/flexbackup line 1053.
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at 
/usr/bin/flexbackup line 2688.

See 
http://perldoc.perl.org/perldelta.html#defined%28%40array%29-and-defined%28%25hash%29-are-now-fatal-errors

It seems that simply removing the defined() (i.e. checking the length) is the
generally recommended fix, so I intend to NMU with the attached dpatch added
once my weekly backups have successfully completed. I'll supply a full diff at
that time.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel, arm64

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages flexbackup depends on:
ii  cpio  2.11+dfsg-5
ii  perl  5.22.1-7

Versions of packages flexbackup recommends:
ii  afio 2.5.1.20130626+gite266635-1
ii  binutils 2.26-4
ii  buffer   1.19-12
ii  lzma 9.22-2
ii  pax  1:20151013-1
ii  rsync3.1.1-3
ii  sharutils1:4.15.2-1
ii  star 1.5final-2
ii  xz-utils [lzma]  5.1.1alpha+20120614-2.1
ii  zip  3.0-11

Versions of packages flexbackup suggests:
pn  lha  
ii  ssh  1:7.1p2-2

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

-- no debconf information
#!/bin/sh /usr/share/dpatch/dpatch-run
## 60_use_afio_default_nocompression.dpatch by Kurt B. Kaiser <k...@shore.net>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Bug #XX patch by Ian Campbell <i...@debian.org>
## DP:
## DP: defined(%hash) and defined(@array) have been deprecated for a while and
## DP: are now fatal errors:
## DP:
## DP: Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at /usr/bin/flexbackup line 1053.
## DP: Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at /usr/bin/flexbackup line 2688.
## DP:
## DP: See http://perldoc.perl.org/perldelta.html#defined%28%40array%29-and-defined%28%25hash%29-are-now-fatal-errors
## DP:
## DP: http://perldoc.perl.org/functions/defined.html recommends just checking
## DP: for length (i.e. removing the defined()). Do so.

@DPATCH@
diff -urNad flexbackup-svn~/flexbackup flexbackup-svn/flexbackup
--- flexbackup-svn~/flexbackup	2016-02-28 08:54:08.338589461 +
+++ flexbackup-svn/flexbackup	2016-02-28 08:56:08.934584524 +
@@ -1050,7 +1050,7 @@
 } else {
 	$prunekey = $dir;
 }
-if (defined(%{$::prune{$prunekey}})) {
+if (%{$::prune{$prunekey}}) {
 	("| NOTE: \$prune is ignored for type=dump");
 }
 
@@ -2685,7 +2685,7 @@
 }
 
 # Flag old config file
-if (defined(@cfg::filesystems) or defined($cfg::mt_var_blksize)) {
+if (@cfg::filesystems or defined($cfg::mt_var_blksize)) {
 	# so strict shuts up
 	my $junk = @cfg::filesystems;
 	$junk = $cfg::mt_var_blksize;
@@ -4883,7 +4883,7 @@
 	$prunekey = $dir;
 }
 
-if (defined(%{$::prune{$prunekey}})) {
+if (%{$::prune{$prunekey}}) {
 	# FreeBSD needs -E (above) and no backslashes around the (|) chars
 	if ($::uname =~ /FreeBSD/) {
 	$cmd .= '-regex "\./(';

Bug#810070: [Pkg-xen-devel] Bug#810070: Bug#810070: XEN Hypervisor crashes/reboots at Startup after "Scrubbing Free Ram"

[Ian Campbell]

Control: close -1 4.6.0-1

On Thu, 2016-02-11 at 16:56 +0100, a...@trash-mail.com wrote:
> > If possible it might be interesting to first try the 4.6 hypervisor in
> > Stretch, I suspect the xen-hypervisor-4.6-amd64 package will just
> install
> > on Jessie with no issues since it has no dependencies and you don't
> need
> > the userspace tools just to check if it boots.
> 
> Hey there,
> 
> I can confirm the issue with new Intel i7-6700 Quad-Core Skylake CPUs and
> I'm also not able to derive further details than already provided. But I
> can also confirm, that the issue seems to be resolved in Debian Stretch. 

Thanks, marking as fixed in 4.6.0-1.

Ian.

Bug#814338: armhf-20150422: Format partitions error for ext4/fat/jfs : Unknown symbol __getblk_gfp

[Ian Campbell]

On Wed, 2016-02-10 at 15:31 +0100, Gaël Jobin wrote:
> Package: installation-reports
> Severity: grave
> Tags: d-i
> Justification: renders package unusable
> 
> I'm trying to run Debian Jessie on ARMv7 using Qemu. I used the initrd.gz
> and
> vmlinuz available at ftp://ftp.debian.org/debian/dists/jessie/main/instal
> ler-
> armhf/20150422/images/netboot/. I also tried with the up-to-date version
> at
> ftp://ftp.debian.org/debian/dists/jessie/main/installer-
> armhf/20150422+deb8u3/images/netboot/ without success.

You need to use 20150422+deb8u3, or more specificall whatever the "current"
symlink currently points to, otherwise you will find a mismatch between the
installer kernel and what is in the network archive, which results in
things like what you are seeing.

It looks like all of your logs are with the 20150422 version, please repeat
using 20150422+deb8u3 and supply those logs instead.

You mention you didn't have success with +deb8u3, but was it the same
issue?

> ~ # uname -a
> Linux debian 3.16.0-4-armmp #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) armv7l

This 3.16.7-ckt9-2 is what lead me to conclude these logs were from
20150422 and not +deb8u3, the latter would be ...-clk20+deb8u.

Ian.

Bug#813995: flash-kernel: writes to nand without being aware of bad blocks

[Ian Campbell]

Control: reassign -1 mtd-utils

So far I see no evidence for the claim that flashcp should not be used
for writing to NAND devices in either its --help or its source (it has
no man page AFAICS).

Having a tool in Debian called "flashcp" which can (according to this
report, I haven't checked this myself) destroy some classes of flash
device with no warning is a clear problem irrespective of flash
-kernel's use of that tool.

At the very least flashcp should either abort when used on NAND devices
or should be renamed norwrite (cf. nandwrite) but ideally it would Just
Work properly when used on a nand device.

mtd-utils maintainer(s), please let me know if this is either wontfix
or if the fix is going to take some time, in either case I will
workaround flashcp in flash-kernel (either permanently or temporarily
respectively).

I suppose it is also possible that this is a bug in the underlying
/dev/mtdN and/or mtdblockN device or in the h/w specific driver at the
bottom of the stack?

codesearch.debian.net doesn't show any other use in packages other than
flash-kernel, but of course that doesn't account for users calling the
tool directly.

Thanks,
Ian.

On Sun, 2016-02-07 at 12:09 +0100, Uwe Kleine-König wrote:
> Package: flash-kernel
> Version: 3.35+deb8u2
> Severity: critical
> Justification: causes serious data loss
> Control: block 806926 with -1
> 
> Hello,
> 
> when flash-kernel writes a kernel/initrd to NAND flash it uses plain
> write(2) to /dev/mtdX (flash-kernel < 3.52) or flashcp
> (flash-kernel >= 3.52). If the device being written to has bad blocks
> these are tried to be erased and written by both approaches.
> 
> This results in a non-booting system at best. In general writing to
> bad
> blocks can also affect other (otherwise good) blocks and so result in
> loss of unrelated data. I never saw this in practise, but the
> manufacturers of NAND flash say so.
> 
> I didn't check which machines are affected, but Netgear ReadyNAS
> 102/104
> (which isn't in flash-kernel's database yet, but see below for the
> obvious entry to add support for them and #806926) is affected and
> flash
> kernel managed to break a ReadyNAS 102 already (non-permanently by
> good
> fortune as far as I can tell up to now).
> I guess there are several other machines affected though.
> 
> The right fix is to use nandwrite to write to NAND flash and only use
> flashcp for NOR.
> 
> Something like
> 
>   test -f /sys/class/mtd/mtdX/oobsize
> 
> could be used to detect if the device is NAND or NOR. But there might
> be
> more reliable ways I'm not aware of.
> 
> I will debug/test a bit more with the broken rn102 (and its owner :-)
> to
> maybe come up with a patch, but if someone beats me that's very
> welcome,
> too.
> 
> Best regards
> Uwe
> 
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'),
> (1, 'experimental')
> Architecture: armhf (armv7l)
> 
> Kernel: Linux 3.16.0-4-armmp (SMP w/1 CPU core)
> 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 flash-kernel depends on:
> ii  debconf [debconf-2.0]  1.5.56
> ii  devio  1.2-1
> ii  initramfs-tools0.120
> ii  linux-base 3.5
> ii  ucf3.0030
> 
> Versions of packages flash-kernel recommends:
> ii  u-boot-tools  2014.10+dfsg1-5
> 
> flash-kernel suggests no packages.
> 
> -- Configuration Files:
> /etc/flash-kernel/db changed:
> Machine: NETGEAR ReadyNAS 104
> DTB-Id: armada-370-netgear-rn104.dtb
> DTB-Append: yes
> Mtd-Kernel: uImage
> Mtd-Initrd: minirootfs
> U-Boot-Kernel-Address: 0x0400
> U-Boot-Initrd-Address: 0x0500
> Required-Packages: u-boot-tools
> 
> 
> -- debconf information:
>   flash-kernel/linux_cmdline: quiet
> 
> 

Bug#812327: [Pkg-xen-devel] Bug#812327: xen: initrd booting with xen don't find any harddisks

[Ian Campbell]

On Fri, 2016-01-22 at 12:40 +0100, Markus Schraeder wrote:
> Package: xen-system-amd64
> Version: 4.6.0-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I installed fresh from ALPHA5, no UEFI, with two disks. Each disk
> got a partition for /boot and one for /, joined each by RAID 1.
> 
> Then I just installed "xen-system-amd64", nothing more. After
> rebooting, selecting on grub to boot XEN, it hangs on
> 
>   mdadm: no devices listed in conf file were found
> 
> . I reproduced this on a different machine, and there is the same case.
> 
> In initrd you can see that it just do not have any /dev/sd* or
> /dev/hd*. So it is clear why it cannot find the arrays.
> 
> Why does the kernel not find any disks booting via XEN? If you select
> in grub the entry without xen, it just finds its discs and boots fine...

Please can you post full boot logs of the successful (without Xen) and
unsuccessful (with Xen) cases using the exact same kernel + initrd binaries
(i.e. the only difference being the presence of Xen under the kernel)

Thanks,
Ian.

Bug#812327: [Pkg-xen-devel] Bug#812327: xen: initrd booting with xen don't find any harddisks

[Ian Campbell]

(adding the bug back, please keep it ccd)
On Fri, 2016-01-22 at 13:05 +0100, Markus Schräder wrote:
> What is for you a full log? A dmesg?

At least the linux dmesg in both cases, yes.

In the Xen case if you can get the Xen dmesg one too (which you may not
from a initrd) that would be useful as well.

In the Xen case you might find http://wiki.xenproject.org/wiki/XenSerialCon
sole useful (if your hardware has a serial port, which is less common these
days). Failing that a digital photo of all the bits with (XEN) at the front
(a big block near the start of boot and possibly odd bits in the middle of
the dom0 logs later) would be better than nothing.

Ian.

Bug#810070: [Pkg-xen-devel] Bug#810070: XEN Hypervisor crashes/reboots at Startup after "Scrubbing Free Ram"

[Ian Campbell]

Control: tag -1 +upstream

On Wed, 2016-01-06 at 08:36 +, Wolf Karsten Dietz wrote:
> Package: xen-hypervisor-4.4-amd64
> Version: 4.4.1-9+deb8u3
> Severity: grave
> 
> Hello,
> I am trying to install the XEN Hypervisor on a Debian Jessie Server.  
> When I am booting without the Hypervisor, everything works fine, but  
> when I am Booting WITH the XEN-Hypervisor, then System crashes /  
> reboots after the "Scrubbing Free RAM" Message without any  
> Error-message, just a blank screen.

Thanks for your report. 

I don't think we are going to be able to resolve this within Debian. Would
you mind reporting this to upstream please:
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen

We could forward it but I expect there will need to be some back and forth
with the maintainers so ti makes sense for you to speak to them directly.
You can CC 810...@bugs.debian.org to keep this bug in the loop.

If possible it might be interesting to first try the 4.6 hypervisor in
Stretch, I suspect the xen-hypervisor-4.6-amd64 package will just install
on Jessie with no issues since it has no dependencies and you don't need
the userspace tools just to check if it boots.

Ian.

> 
> Technical Data of the Server:
> CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (with VT-x)
> MEMORY: 64GB RAM (Memtest reports no Errors)
> HDD: SSD as Software-Raid
> 
> Debian-Version: 8.2 (Jessie) with all Updates
> System/Dom0-Kernel: 3.16.7-ckt20-1 / 3.16+63
> I have also tried the Kernels from Backports: 4.2.6-3-bpo8+2 and  
> 4.3.3-2-bpo8+1 ... makes no difference
> 
> According to other Bug-reports, etc. in the Internet I tried to set  
> Parameters in the Grub-Command-line (/etc/default/grub :  
> GRUB_CMDLINE_XEN_DEFAULT) followed by an update-grub everytime:
> 
> dom0_mem : different Values between 512M,max:512M and 64G,max:64G ( At  
> the beginning in Steps of 256M and at the end in Steps of 2G) ...  
> makes no difference
> mem : diffent Values between 512M and 64G ( like dom0_mem or a little  
> bit higher) ... makes no difference
> dom0_max_vcpus=1 dom0_vcpus_pin : with and without  makes no
> difference
> no-bootscrub : with or without ... the only difference is that the  
> Scubbing Free RAM Message and the dots afterwards are disappearing ...  
> the crash/reboot is happening at the same Position
> noreboot: with or without ... no difference ... with the System hangs  
> with a blank screen and needs a hardware-reset ... without the System  
> is rebooting after the Blank Screen
> acpi=ht|off or without ... makes no difference
> loglvl=all guest_loglvl=all ... no other messages seen
> 
> The Server is in a Data-Center, so I have no physical access to it and  
> i cannot put something like a serial console on it. I have only some  
> Videos from the Remote VGA-Utility of the boot-Sequenz. In all Videos  
> the Screen gets black after the Message of reported VCPUs and the  
> Scrubbing Free RAM.
> 
> dmesg from a normal Startup without XEN-Hypervisor (this time the  
> 4.3-kernel ... if other Kernel needed please ask):
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.3.0-0.bpo.1-amd64  
> (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10)  
> ) #1 SMP Debian 4.3.3-2~bpo8+1 (2015-12-23)
> [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.3.0-0.bpo.1-amd64  
> root=UUID=fc273ce0-6e58-4b9f-9cec-5d625697326c ro nomodeset
> [0.00] x86/fpu: xstate_offset[2]: 0240, xstate_sizes[2]: 0100
> [0.00] x86/fpu: xstate_offset[3]: 03c0, xstate_sizes[3]: 0040
> [0.00] x86/fpu: xstate_offset[4]: 0400, xstate_sizes[4]: 0040
> [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating  
> point registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x08: 'MPX bounds
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x10: 'MPX CSR'
> [0.00] x86/fpu: Enabled xstate features 0x1f, context size is  
> 0x440 bytes, using 'standard' format.
> [0.00] x86/fpu: Using 'eager' FPU context switches.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009c7ff]
> usable
> [0.00] BIOS-e820: [mem 0x0009c800-0x0009]
> reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f]
> reserved
> [0.00] BIOS-e820: [mem 0x0010-0xbf873fff]
> usable
> [0.00] BIOS-e820: [mem 0xbf874000-0xbf874fff]
> ACPI NVS
> [0.00] BIOS-e820: [mem 0xbf875000-0xbf8befff]
> reserved
> [0.00] BIOS-e820: [mem 0xbf8bf000-0xc2f53fff]
> usable
> [0.00] BIOS-e820: [mem 

Bug#787229: [Pkg-xen-devel] Bug#787229: xen-hypervisor-4.4-amd64: xl command hangs on Dell R720

[Ian Campbell]

I'm afraid I don't know what may or may not have happened to your
installation, just that this fake-start-stop-daemon thing is very likely
interfering with the operation of Xen by not actually starting daemons.

I suggest you try asking somewhere like the debian-users list to see if
anyone there knows what this thing is or what to do about it.

Ian.

On Tue, 2015-06-02 at 15:22 +0200, Benoît Tonnerre wrote:
 Hi, 
 
 
 Thanks for your answer.
 
 
 
 During the Debian jessie installation, I had a problem at grub step.
 
 The os-prober part was stuck : grub was at 66 % (os-prober tried to
 browse all the VM on LVM partitions)
 
 After more than 15 minutes, os-prober seems to be stuck, so I rebooted
 the server.
 I had to boot in rescue mode, then, reinstalled grub and modified it
 to add GRUB_DISABLE_OS_PROBER=true.
 
 It seems it solved the problem, I was able to boot the server.
 
 
 Maybe there are some missing things in my Debian installation ?
 
 
 Do you want me to fill an other bug report (concerning the
 installation problem ?)
 
 
 I have not this problem with Debian Wheezy installation.
 
 
 Thanks for your time and for your help.
 
 
 Benoit
 
 
 
 
 
 
 
 
 
 2015-05-30 10:31 GMT+02:00 Ian Campbell i...@debian.org:
 On Sat, 2015-05-30 at 05:23 +0200, Benoît Tonnerre wrote:
  mai 29 23:20:50 jango xen[1150]: Starting Xen daemons: xenfs
 xenstored
  mai 29 22:20:50 jango xen[1150]: Warning: Fake
 start-stop-daemon called, doing
  nothing.
  mai 29 23:20:50 jango xen[1150]: Warning: Fake
 start-stop-daemon called, doing
  nothing.
 
 This suggests that the xen daemons and in particular xenstored
 are not
 actually running, the result of which will be any command
 which tries to
 talk to xenstored (like xl list, most xl commands and the
 xenstore-write
 seen in the status log) will never get an answer and will
 appear to
 hang.
 
 I don't know what Fake start-stop-daemon is, but it sounds
 like the
 root of your problems.
 
 Ian.
 
 
 
 


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

Bug#786936: [Pkg-xen-devel] Bug#786936: xen-hypervisor-4.4-amd64: Upgrade dom0 from wheezy to jessie on Dell R610 results in dom0 unaccessible with xen_netback issue

[Ian Campbell]

Control: reassign -1 linux-image-3.16.0-4-amd64 3.16.7-ckt9-3~deb8u1

On Wed, 2015-05-27 at 08:44 +1000, Andrew Perry wrote:
 Package: xen-hypervisor-4.4-amd64
 Version: 4.4.1-9
 Severity: critical
 Justification: breaks the whole system
 
 Dear Maintainer,
 
 After upgrading the R610 server from Debian 7 to Debian 8, the dom0
 becomes unresponsive via ssh after an hour or so, although the domUs
 still remain accessible.
 
 Initially we thought it may be a disk space issue on / or /boot so
 action was taken to increase those petition sizes but it has no
 effect.
 
 We get the following trace in /var/log/syslog:
 
 May 26 09:18:59 servername kernel: [31526.937788] BUG: unable to handle 
 kernel paging request at c90013a4b158
 May 26 09:18:59 servername kernel: [31526.937798] IP: [a06802a0] 
 xenvif_get_ethtool_stats+0x50/0x80 [xen_netback]

This appears to be a dom0 kernel issue rather than a hypervisor issue,
I've (hopefully) reassigned accordingly.

While we work out a proper fix, since the error appears to be in the
ethtool stats gathering code I suspect that there might be a workaround
which would be to disable whichever code in dom0 (a monitoring daemon
like nagios perhaps?) is calling this path.

 May 26 09:18:59 servername kernel: [31526.937807] PGD b243c067 PUD b243d067 
 PMD 8a56c067 PTE 0
 May 26 09:18:59 servername kernel: [31526.937813] Oops:  [#1] SMP 
 May 26 09:18:59 servername kernel: [31526.937817] Modules linked in: 
 dm_snapshot dm_bufio binfmt_misc xt_tcpudp xt_physdev iptable_filter 
 ip_tables x_tables xen_netback xen_blkback xen_gntdev xen_evtchn xenfs 
 xen_privcmd nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc 
 ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp 
 libiscsi_tcp libiscsi scsi_transport_iscsi bridge stp llc nls_utf8 nls_cp437 
 vfat fat joydev intel_powerclamp coretemp crc32_pclmul ghash_clmulni_intel 
 ttm evdev aesni_intel ipmi_devintf iTCO_wdt iTCO_vendor_support aes_x86_64 
 drm_kms_helper acpi_power_meter dcdbas lrw gf128mul glue_helper tpm_tis tpm 
 drm i2c_algo_bit ablk_helper processor i2c_core lpc_ich ipmi_si 
 ipmi_msghandler i7core_edac thermal_sys cryptd mfd_core button psmouse pcspkr 
 serio_raw shpchp wmi edac_core loop autofs4 ext4 crc16 mbcache jbd2 dm_mod 
 hid_generic usbhid hid sg sr_mod cdrom ses sd_mod enclosure ata_generic 
 crc32c_intel lpfc crc_t10dif crct10dif_generic ehci_pci uhci_hcd 
 crct10dif_pclmul ata_piix ehci_hcd scsi_transport_fc libata megaraid_sas 
 scsi_tgt usbcore scsi_mod usb_common crct10dif_common bnx2
 May 26 09:18:59 servername kernel: [31526.937917] CPU: 0 PID: 1311 Comm: 
 snmpd Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1
 May 26 09:18:59 servername kernel: [31526.937922] Hardware name: Dell Inc. 
 PowerEdge R610/0F0XJ6, BIOS 6.4.0 07/23/2013
 May 26 09:18:59 servername kernel: [31526.937927] task: 88008a86a250 ti: 
 880002b4c000 task.ti: 880002b4c000
 May 26 09:18:59 servername kernel: [31526.937931] RIP: 
 e030:[a06802a0]  [a06802a0] 
 xenvif_get_ethtool_stats+0x50/0x80 [xen_netback]
 May 26 09:18:59 servername kernel: [31526.937939] RSP: e02b:880002b4fd70  
 EFLAGS: 00010283
 May 26 09:18:59 servername kernel: [31526.937942] RAX: c90013a14f38 RBX: 
 0230f940 RCX: 92008ea28c88
 May 26 09:18:59 servername kernel: [31526.937946] RDX: 88008ecadc00 RSI: 
 c90013a4b190 RDI: 88008da7c000
 May 26 09:18:59 servername kernel: [31526.937949] RBP: 880002b4fe10 R08: 
 a06827e0 R09: 0006
 May 26 09:18:59 servername kernel: [31526.937953] R10: 0010ebb8 R11: 
 0246 R12: 0005
 May 26 09:18:59 servername kernel: [31526.937957] R13: 88008da7c000 R14: 
 a0682640 R15: 88008ecadc00
 May 26 09:18:59 servername kernel: [31526.937965] FS:  7f93bcc9e700() 
 GS:8800b2a0() knlGS:
 May 26 09:18:59 servername kernel: [31526.937969] CS:  e033 DS:  ES:  
 CR0: 8005003b
 May 26 09:18:59 servername kernel: [31526.937973] CR2: c90013a4b158 CR3: 
 899ff000 CR4: 2660
 May 26 09:18:59 servername kernel: [31526.937977] Stack:
 May 26 09:18:59 servername kernel: [31526.937979]  814225f1 
 000400114813 7fff3fff32a8 
 May 26 09:18:59 servername kernel: [31526.937985]  880002b4ff18 
 001d3fff32a0 880002b4fde0 814039a6
 May 26 09:18:59 servername kernel: [31526.937990]  0005001d 
 8805 81420455 7fff3fff3280
 May 26 09:18:59 servername kernel: [31526.937995] Call Trace:
 May 26 09:18:59 servername kernel: [31526.938003]  [814225f1] ? 
 dev_ethtool+0x921/0x1ac0
 May 26 09:18:59 servername kernel: [31526.938009]  [814039a6] ? 
 ___sys_recvmsg+0x136/0x2a0
 May 26 09:18:59 servername kernel: [31526.938014]  [81420455] ? 
 netdev_run_todo+0x55/0x2f0
 May 26 09:18:59 servername kernel: 

Bug#787229: [Pkg-xen-devel] Bug#787229: xen-hypervisor-4.4-amd64: xl command hangs on Dell R720

[Ian Campbell]

On Sat, 2015-05-30 at 05:23 +0200, Benoît Tonnerre wrote:
 mai 29 23:20:50 jango xen[1150]: Starting Xen daemons: xenfs xenstored
 mai 29 22:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing
 nothing.
 mai 29 23:20:50 jango xen[1150]: Warning: Fake start-stop-daemon called, doing
 nothing.

This suggests that the xen daemons and in particular xenstored are not
actually running, the result of which will be any command which tries to
talk to xenstored (like xl list, most xl commands and the xenstore-write
seen in the status log) will never get an answer and will appear to
hang.

I don't know what Fake start-stop-daemon is, but it sounds like the
root of your problems.

Ian.


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

Bug#786936: [PATCHv2 1/3] xen-netback: return correct ethtool stats

[Ian Campbell]

Control: fixed -1 4.0-1~exp1

On Wed, 2015-03-04 at 11:14 +, David Vrabel wrote:
 Use correct pointer arithmetic to get the pointer to each stat.

I think this incorrect arithmetic was also responsible for the crash
reported in http://bugs.debian.org/786936 which was using the resulting
stray pointer.

I'll add the fix to our kernel but: David (Miller) could we also have it
queued for stable please?

Thanks.

Reasoning:

IP: [a06802a0] xenvif_get_ethtool_stats+0x50/0x80 [xen_netback]

(gdb) disas xenvif_get_ethtool_stats+0x50
Dump of assembler code for function xenvif_get_ethtool_stats:
   0x5280 +0: callq  0x5285 xenvif_get_ethtool_stats+5
   0x5285 +5: mov0x900(%rdi),%r9d
   0x528c +12:mov$0x0,%r8
   0x5293 +19:lea-0x1(%r9),%r10d
   0x5297 +23:imul   $0x36258,%r10,%r10
   0x529e +30:xchg   %ax,%ax
   0x52a0 +32:test   %r9d,%r9d
   0x52a3 +35:je 0x52f8 xenvif_get_ethtool_stats+120
   0x52a5 +37:movzwl (%r8),%esi
   0x52a9 +41:mov0x8f8(%rdi),%rcx
   0x52b0 +48:lea0x0(,%rsi,8),%rax
   0x52b8 +56:shl$0x6,%rsi
   0x52bc +60:sub%rax,%rsi
   0x52bf +63:lea(%rcx,%rsi,1),%rax
   0x52c3 +67:lea0x36258(%rcx,%r10,1),%rcx
   0x52cb +75:add%rcx,%rsi
   0x52ce +78:xor%ecx,%ecx
   0x52d0 +80:add0x36220(%rax),%rcx
   0x52d7 +87:add$0x36258,%rax
   0x52dd +93:cmp%rsi,%rax
   0x52e0 +96:jne0x52d0 xenvif_get_ethtool_stats+80
   0x52e2 +98:add$0x22,%r8
   0x52e6 +102:   mov%rcx,(%rdx)
   0x52e9 +105:   add$0x8,%rdx
   0x52ed +109:   cmp$0x0,%r8
   0x52f4 +116:   jne0x52a0 xenvif_get_ethtool_stats+32
   0x52f6 +118:   repz retq 
   0x52f8 +120:   xor%ecx,%ecx
   0x52fa +122:   jmp0x52e2 xenvif_get_ethtool_stats+98
End of assembler dump.
(gdb) list *xenvif_get_ethtool_stats+0x50
0x52d0 is in xenvif_get_ethtool_stats 
(/build/linux-RGM_Ed/linux-3.16.7-ckt9/drivers/net/xen-netback/interface.c:349).

... and in the Debian kernel interface.c:349 is the accum += line from
the patch.

Ian.

 
 Signed-off-by: David Vrabel david.vra...@citrix.com
 ---
  drivers/net/xen-netback/interface.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/drivers/net/xen-netback/interface.c 
 b/drivers/net/xen-netback/interface.c
 index f38227a..3aa8648 100644
 --- a/drivers/net/xen-netback/interface.c
 +++ b/drivers/net/xen-netback/interface.c
 @@ -340,12 +340,11 @@ static void xenvif_get_ethtool_stats(struct net_device 
 *dev,
   unsigned int num_queues = vif-num_queues;
   int i;
   unsigned int queue_index;
 - struct xenvif_stats *vif_stats;
  
   for (i = 0; i  ARRAY_SIZE(xenvif_stats); i++) {
   unsigned long accum = 0;
   for (queue_index = 0; queue_index  num_queues; ++queue_index) {
 - vif_stats = vif-queues[queue_index].stats;
 + void *vif_stats = vif-queues[queue_index].stats;
   accum += *(unsigned long *)(vif_stats + 
 xenvif_stats[i].offset);
   }
   data[i] = accum;


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

Bug#786882: debian-installer: FTBFS on arm64: can't find dtbs

[Ian Campbell]

On Tue, 2015-05-26 at 14:16 +0200, Cyril Brulebois wrote:
[...]
 There seems to be some dtb dance here, and I think the src:linux's
 having relocated the dtbs under subdirectories is responsible for the
 FTBFS. Comparing some recent kernels:
 | kibi@wodi:/tmp/linux-kernel$ debdiff 
 binary-kernel-image-3.16.0-4-arm64-di/kernel-image-3.16.0-4-arm64-di_3.16.7-ckt9-2_arm64.udeb
  
 binary-kernel-image-4.0.0-1-arm64-di/kernel-image-4.0.0-1-arm64-di_4.0.2-1_arm64.udeb
 | [The following lists of changes regard files as different if they have
 | different names, permissions or owners.]
 | 
 | Files in second .deb but not in first
 | -
 | -rw-r--r--  root/root   /lib/modules/4.0.0-1-arm64/modules.builtin
 | -rw-r--r--  root/root   /lib/modules/4.0.0-1-arm64/modules.order
 | -rw-r--r--  root/root   
 /usr/lib/linux-image-4.0.0-1-arm64/apm/apm-mustang.dtb
 | -rw-r--r--  root/root   
 /usr/lib/linux-image-4.0.0-1-arm64/arm/foundation-v8.dtb
 | -rw-r--r--  root/root   /usr/lib/linux-image-4.0.0-1-arm64/arm/juno.dtb
 | -rw-r--r--  root/root   
 /usr/lib/linux-image-4.0.0-1-arm64/arm/rtsm_ve-aemv8a.dtb
 | 
 | Files in first .deb but not in second
 | -
 | -rw-r--r--  root/root   /lib/modules/3.16.0-4-arm64/modules.builtin
 | -rw-r--r--  root/root   /lib/modules/3.16.0-4-arm64/modules.order
 | -rw-r--r--  root/root   /usr/lib/linux-image-3.16.0-4-arm64/apm-mustang.dtb
 | -rw-r--r--  root/root   
 /usr/lib/linux-image-3.16.0-4-arm64/foundation-v8.dtb
 | -rw-r--r--  root/root   
 /usr/lib/linux-image-3.16.0-4-arm64/rtsm_ve-aemv8a.dtb
 
 → Besides the ABI bump, one can see apm/ and arm/ being introduced here.
   src:debian-installer likely needs to learn how to handle this.

Upstream decided to structure things a bit more (by vendor). Sorry for
not thinking of d-i when I fixed up the kernel packaging side.

Ian.


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

Bug#783019: kirkwood network console images ask to choose ethernet device

[Ian Campbell]

Package: oldsys-preseed
Version: 3.15
Severity: grave
Tags: patch

Doing a test install of jessie on my TS-419 I get asked (via the serial)
for a serial port and a ssh password. I happen to have a serial port but
these devices mostly do not and are supposed to be headless.

I'm using the images from
http://ftp.uk.debian.org/debian/dists/jessie/main/installer-armel/20150418/images/kirkwood/network-console/qnap/ts-41x/

From the logs there is no sign of oldsys-preseed running. Poking around
in the shell I see:
~ # sh -x /usr/bin/oldsys-preseed 
+ set -e
+ . /usr/lib/oldsys-preseed/functions
+ NONINTERACTIVE=yes
+ FILE=/preseed.cfg
+ archdetect
+ + sed s/Hardware\s*:\s*//
grep ^Hardware /proc/cpuinfo
+ machine=QNAP TS-41x
+ cat /proc/device-tree/model
+ dt_model=
~ # 

IOW due to set -e it exits early on systems
where /proc/device-tree/model does not exist, since the cat fails.

By commenting out that one line things seem to progress in a way which
looks promising (i.e. much more spew than above). I think the most
plausible solution would be:

diff --git a/oldsys-preseed b/oldsys-preseed
index f60196f..4cd7138 100755
--- a/oldsys-preseed
+++ b/oldsys-preseed
@@ -115,7 +115,11 @@ case `archdetect` in
arm*/orion5x | arm*/kirkwood)
machine=$(grep ^Hardware /proc/cpuinfo | sed 
's/Hardware\s*:\s*//')
# /proc/device-tree may not exist on all architectures
-   dt_model=$(cat /proc/device-tree/model 2/dev/null)
+   if [ -e /proc/device-tree/model ] ; then
+   dt_model=$(cat /proc/device-tree/model 2/dev/null)
+   else
+   dt_model=UNKNOWN
+   fi
if echo $machine | grep -q ^Buffalo/Revogear Kurobox Pro; 
then
check_file /proc/mtd
rootfs=$(get_mtdblock rootfs)

I'll build an image and test that shortly.

Severity grave because d-i is mostly useless on qnap hardware (and
headless orion or kirkwood generally) with this issue, at least for
non-DT systems, which I think is still most of them in Jessie.

Ian.


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

Bug#783019: kirkwood network console images ask to choose ethernet device

[Ian Campbell]

On Mon, 2015-04-20 at 19:11 +0100, Ian Campbell wrote:

 By commenting out that one line things seem to progress in a way which
 looks promising (i.e. much more spew than above). I think the most
 plausible solution would be:
 
 diff --git a/oldsys-preseed b/oldsys-preseed
 index f60196f..4cd7138 100755
 --- a/oldsys-preseed
 +++ b/oldsys-preseed
 @@ -115,7 +115,11 @@ case `archdetect` in
 arm*/orion5x | arm*/kirkwood)
 machine=$(grep ^Hardware /proc/cpuinfo | sed 
 's/Hardware\s*:\s*//')
 # /proc/device-tree may not exist on all architectures
 -   dt_model=$(cat /proc/device-tree/model 2/dev/null)
 +   if [ -e /proc/device-tree/model ] ; then
 +   dt_model=$(cat /proc/device-tree/model 2/dev/null)
 +   else
 +   dt_model=UNKNOWN
 +   fi
 if echo $machine | grep -q ^Buffalo/Revogear Kurobox Pro; 
 then
 check_file /proc/mtd
 rootfs=$(get_mtdblock rootfs)
 
 I'll build an image and test that shortly.

Test was successful, proper patch is below.

Ian.

diff --git a/debian/changelog b/debian/changelog
index 422a43d..ad9a6ba 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+oldsys-preseed (3.16) UNRELEASED; urgency=medium
+
+  * Avoid exiting prematurely on arm*/orion5x or arm*/kirkwood which do not use
+device tree. (Closes: #783019)
+
+ -- Ian Campbell i...@debian.org  Mon, 20 Apr 2015 19:06:00 +0100
+
 oldsys-preseed (3.15) unstable; urgency=medium
 
   [ Michael Walle ]
diff --git a/oldsys-preseed b/oldsys-preseed
index f60196f..4cd7138 100755
--- a/oldsys-preseed
+++ b/oldsys-preseed
@@ -115,7 +115,11 @@ case `archdetect` in
arm*/orion5x | arm*/kirkwood)
machine=$(grep ^Hardware /proc/cpuinfo | sed 
's/Hardware\s*:\s*//')
# /proc/device-tree may not exist on all architectures
-   dt_model=$(cat /proc/device-tree/model 2/dev/null)
+   if [ -e /proc/device-tree/model ] ; then
+   dt_model=$(cat /proc/device-tree/model 2/dev/null)
+   else
+   dt_model=UNKNOWN
+   fi
if echo $machine | grep -q ^Buffalo/Revogear Kurobox Pro; 
then
check_file /proc/mtd
rootfs=$(get_mtdblock rootfs)



signature.asc
Description: This is a digitally signed message part

Bug#777191: grub-efi-amd64 on Debian Jessie cannot boot zfs native root filesystem running the latest git code soon to be 0.6.4 tagged - official release

[Ian Campbell]

On Thu, 2015-02-05 at 20:04 -0800, Azeem Esmail wrote:
 Works with 0.6.3 (v0.6.3-766_gfde0d6d)
 Does not work with 0.6.3 latest code (dailies version). 

What are these the versions of?

 At first reboot, the screen freezes with the following message:
 
 mount: mounting /sys on /root/sys failed: No such file or directory
 mount: mounting /proc on /root/proc failed: No such file or directory
 /init: line 335: can't open /root/dev/console: no such file
 ...
 [end Kernel panic - not syncing: attempting to kill init!
 exitcode=0x0200
 
 After a cold boot the following message appears:
 
 sh: argument expected - repeated 4 times
 
 Command: mount -o zfsutil -t zfs - /root
 Message: filesystem '-' cannot be mounted, unable to open the dataset
 mount: mounting - on /root failed: No such file or directory
 Error: 1
 
 Manually mount the root filesystem on /root and then exit.

This would seem to suggest that the issue is with either initramfs-tools
or, more likely, whichever package provided the zfs hooks for
initramfs-tools.

I think it is most likely the latter, but I can't find such a package in
Debian, are you using some tools from outside of Debian for this setup?
i.e. perhaps zfs-initramfs from zfsonlinux.org perhaps? If so then I
think your bug is with that software.

Certainly I think grub's involvement is long over by the time you get to
these sorts of messages.

Ian.


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

Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems

[Ian Campbell]

Control: severity -1 important
Control: tags -1 +unreproducible +moreinfo

On Wed, 2015-02-25 at 12:19 +, Ian Campbell wrote:
 On Sat, 2015-02-21 at 23:27 +0900, Mark Brown wrote:
  On Sat, Feb 21, 2015 at 10:31:19AM +, Ian Campbell wrote:
   On Sat, 2015-02-21 at 11:39 +0900, Mark Brown wrote:
  
Neither of these appears to have disrupted the
boot partition though so I'm not sure what's been doing that :/ .
  
   Does dpkg-reconfigure grub-efi-amd64 or apt-get install --reinstall
   grub-efi-amd64 trigger the bad behaviour?
  
  No.  How frustrating.  I guess it's possible some old version had this
  issue and I didn't notice due to lack of reboots?  Or some other package
  perhaps?
 
 Perhaps reconfigure/reinstall anything in dpkg -l \*grub\* and then
 chalk it up to gremlins unless/until it happens again?

Which I think for now translates into a lower severity and
+unreproducible +moreinfo.

Ian.


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

Bug#779799: linux: Older patches causing FTBFS on armhf

[Ian Campbell]

On Wed, 2015-03-04 at 22:44 +, B.R. Oake wrote:
 On 04/03/15 22:20, maximilian attems wrote:
  they are already removed in the repository for experimental,
  waiting for 3.19.X for the next upload.
 
  in any case thanks for the details.
 
 Hi, maks; thanks, that's good to know.
 
 For the future, is there a way for me to check whether such things have 
 already been fixed before I report them?  Is the repository that you 
 mentioned public?

It's in svn:
http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/


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

Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems

[Ian Campbell]

On Sat, 2015-02-21 at 23:27 +0900, Mark Brown wrote:
 On Sat, Feb 21, 2015 at 10:31:19AM +, Ian Campbell wrote:
  On Sat, 2015-02-21 at 11:39 +0900, Mark Brown wrote:
 
   Neither of these appears to have disrupted the
   boot partition though so I'm not sure what's been doing that :/ .
 
  Does dpkg-reconfigure grub-efi-amd64 or apt-get install --reinstall
  grub-efi-amd64 trigger the bad behaviour?
 
 No.  How frustrating.  I guess it's possible some old version had this
 issue and I didn't notice due to lack of reboots?  Or some other package
 perhaps?

Perhaps reconfigure/reinstall anything in dpkg -l \*grub\* and then
chalk it up to gremlins unless/until it happens again?

Ian.


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

Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems

[Ian Campbell]

On Sat, 2015-02-21 at 11:39 +0900, Mark Brown wrote:
 On Fri, Feb 20, 2015 at 02:32:34PM +, Steve McIntyre wrote:
 
  In fact, for EFI just grub-install -v should tell you a lot more.
 
 ...and here's the Acer.

Thanks.

 Neither of these appears to have disrupted the
 boot partition though so I'm not sure what's been doing that :/ .

Does dpkg-reconfigure grub-efi-amd64 or apt-get install --reinstall
grub-efi-amd64 trigger the bad behaviour?


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

Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems

[Ian Campbell]

(Steve is probably best placed to say something sensible about this, but
he's away at the moment so I'll see if I can avoid sounding too dumb...)

On Fri, 2015-02-20 at 14:21 +0900, Mark Brown wrote:
 Package: grub-efi-amd64-bin
 Version: 2.02~beta2-20
 Severity: critical
 
 On a couple of occasions recently my system has been updated to remove
 boot/bootx86.efi from the EFI boot partition, and on a new install on a
 separate machine this file was not installed at all.  Instead
 debian/grubx86.efi was left installed.  Unfortunately on both systems my
 BIOS ignores this file and will only boot boot/bootx86.efi so these
 updates make the system unbootable.

This sounds, if I'm interpreting the paths correctly, like it relates
somehow to the stuff Steve was doing in #708430, in as much as it sounds
like your system is one which would benefit from enabling that new
workaround (grub2/force_efi_extra_removable in debconf).

Do you have that new option enabled or disabled?

That said, even with the workaround disabled for some reason removing an
existing boot/bootx86.efi doesn't sound right to me. Not that I have any
how or why it would be happening :-/.

Looking at the code the only things I see which touch boot/bootx86.efi
are behind the new force_efi_extra_removable option which attempts to
update the binary -- I wonder if it is possible to fail half way and
actually only remove the old one? (Some sort of weird vfat interaction?)

 Apologies if this is filed against the wrong package, I'm not 100% clear
 what is responsible for installing these files.

It might actually be grub-efi-amd64, but I think you were close
enough ;-).

Ian.


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

Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems

[Ian Campbell]

On Fri, 2015-02-20 at 18:39 +0900, Mark Brown wrote:
 This is a 1st gen Lenovo Yoga, the other machine that's broken with a
 fresh install is an Acer Aspire E11 (with BIOS 1.13 IIRC).  I can supply
 more specific data on both if you tell me what you're looking for (I see
 some talk of a blacklist in the bug though I'm not sure that made it
 into the code).

If you can reproduce the issue then identifying the exact grub-install
command line which the postinst is invoking might be of interest, as
would then rerunning that same command manually under strace.

Ian.


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

Bug#776488: regression: arm map_hardware[] not NULL terminated

[Ian Campbell]

On Wed, 2015-01-28 at 18:38 +0100, Cyril Brulebois wrote:
 dann frazier da...@dannf.org (2015-01-28):
  On Wed, Jan 28, 2015 at 06:10:49PM +0100, Cyril Brulebois wrote:
   I was about to push it but you apparently already did; adjusting tags
   accordingly.
  
  Cool, thanks :) Do you +1 me uploading this? If so, should I request an
  unblock or does that need to come from you?
 
 Feel free to go ahead. I doubt any arm folks (hello Ian) would disagree
 with having that package uploaded ASAP.

Dann already dropped me a line and I said to go ahead.

  Maybe they have some comments as
 to why nobody reported any crashes yet though (maybe the compiler saving
 the day?).

My guess is that next thing in memory just happened to be some zeroes,
i.e. padding for alignment or some thing like that.

Ian.


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

Bug#764162: Regression with kernel 3.16.7-ckt2-1

[Ian Campbell]

On Sat, 2015-01-03 at 09:54 -0200, Rogério Brito wrote:
[...]

Thanks for the info.

  Since I can't reproduce it would be useful if you could take this issue
  to the upstream developers who were involved in the original bug report
  and work with them directly to find a cure.
 
 I may try, but I am not confident that I will have any success. :(

The upstream kirkwood maintainers are very responsive and helpful IME.

(NB: I'm not asking you to fix the issue yourself, but rather to work
directly with those who can instead of having me act as a middleman)

Ian.


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

Bug#764162: Regression with kernel 3.16.7-ckt2-1

[Ian Campbell]

On Wed, 2014-12-31 at 06:08 -0200, Rogério Brito wrote:
 unarchive 764162
 found 764162 3.16.7-ckt2-1
 notfound 764162 3.16.7-2
 thanks
 
 Hi.
 
 I have a Kurobox Pro that I use as a NAS and I was affected by the network
 corruption when the TSO was enabled in versions 3.16 before the version with
 the workaround on the mv643xx_eth (not having seen the code, from a user's
 perspective, this workaround was more like a fix than a dirty hack).

The workaround was just turning off the feature.

Please can you clarify which of these kernels did/didn't work (or for
which you have no data):
  * 3.16.7-1 (has the bug)
  * 3.16.7-2 (with the hack/workaround of disabling TSO by default)
  * 3.16.7-ckt2-1 (with the supposed proper fix, 2c2a9cb from
upstream, backported via the -ckt tree)

FWIW I am running 3.16.7-ckt2-1 on my kirkwood based ts-419 right now
and it seems fine. It's possible that your system has a separate issue
or is somehow more susceptible to the original (Which IIRC was cache
based, so could affect different platforms differently).

Please can you also confirm that flash-kernel has been run and is
picking up the correct kernel image, i.e. it hasn't installed an old
kernel for you or something like that. uname -v includes the actual
running version.

 Can we get a fix for this in time for jessie?

If one can be found of course we will try and apply it.

Since I can't reproduce it would be useful if you could take this issue
to the upstream developers who were involved in the original bug report
and work with them directly to find a cure.

If we can't find one then I suppose we will fall back to just disabling
TSO by default on these systems.

Ian.


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

Bug#767037: Grub EFI fallback - patches for review

[Ian Campbell]

On Sat, 2014-12-20 at 09:45 +0100, David Härdeman wrote:
 one option that doesn't seem to have been considered would be to create
 a separate package (let's call it UEFIx) that installs an UEFI binary to
 EFI/boot/bootx64.efi. That binary could then do what the UEFI BIOS
 should've done (i.e. look at the EFI vars for bootorder, bootnext, etc
 and then go on to load the right bootloader).

Interesting idea, does this stub bootloader already exist, or is it
something someone would need to write? (Either way I think it's likely
too late for Jessie, but perhaps something to think about for Stretch)

I'd also have some worries about packages installing to /boot/EFI since
that is by definition going to be a VFAT filesystem and I'm not
confident that dpkg will work fully/safely without all the POSIX-ish
semantics (hardlinks, atomic updates and the like), might want to handle
that by installing via the postinst instead of shipping in /boot/EFI.

Ian.


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

Bug#773233: linux: Packaging is not correctly enforcing ABI

[Ian Campbell]

Source: linux
Version: 3.16.7-2
Severity: serious
Justification: Not enforcing the ABI will potentially lead to mismatched 
modules, breakage of stable updates in Jessie etc

It appears that we are not currently correctly checking the ABI of kernels
against debian/abi/* at build time. buildcheck.py is reporting:
  Can't read ABI reference.  ABI not checked!  Continuing.

This can be seen in:
https://buildd.debian.org/status/fetch.php?pkg=linuxarch=amd64ver=3.16.7-1stamp=1415134305
https://buildd.debian.org/status/fetch.php?pkg=linuxarch=amd64ver=3.16.7-2stamp=1415320152
https://buildd.debian.org/status/fetch.php?pkg=linuxarch=amd64ver=3.16.7-ckt2-1stamp=1418093077

The ABI should have remained unchanged since 3.16.7-1 (when it was bumped to
4). However running ./debian/bin/abiupdate.py now results in:

 debian/abi/3.16.0-4/amd64_none_amd64 | 33 ++---
 1 file changed, 18 insertions(+), 15 deletions(-)

(similar for most arches and flavours).

The issue appears to be that buildcheck.py is looking for debian/abi/3.16-4,
while abiupdate.py is creating/updating 3.16.0-4.

The addition of .0 to the kernel version string happened in the same upload as
the switch to ABI 4. Looking at r21985 and r22132 it seems the intention was
for the ABI to include the .0. I've poked at buildcheck.py but haven#'t 6

If I add a symlink 3.16-4 - 3.16.0-4 then buildcheck.py finds the symbols and
complains of changes e.g. to iov_iter_get_pages.

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

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


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

Bug#772983: kirkwood kernel image is too big

[Ian Campbell]

On Fri, 2014-12-12 at 18:12 +, Ben Hutchings wrote:
 Package: src:linux
 Version: 3.16.7-2
 Severity: serious
 
 The kirkwood and orion5x kernel images generally have to be installed
 in flash partitions with a fixed size.  Currently we check at build
 time that vmlinuz is small enough to fit.  However, these platforms
 now require Device Tree blobs, and the appropriate DTB must be
 appended to the kernel image in flash since the boot loader won't load
 it separately.
 
 The kirkwood machines with the smallest known kernel partition are
 QNAP TS-119/TS-219, with 2097080 bytes space.  We need to fit:
 
 -rw-r--r-- 1 ben ben 2094680 Nov  7 03:37 vmlinuz-3.16.0-4-kirkwood
 -rw-r--r-- 1 ben ben   10394 Dec  9 04:57 kirkwood-ts219-6281.dtb

We have not switched to dtb appending for the QNAP TS* platforms in
Jessie. The board support still existed in v3.16 and we still use it.

I had originally planned to switch QNAP over for 3.16 but it wasn't
quite ready upstream (I've forgotten why). The board files went away in
3.17 so in experimental (v3.18) appending is necessary. Once I've worked
out some kinks with kirkwood in v3.18 I was planning to upload a
corresponding flash-kernel which does appending for those platforms.

There are other kirkwood platforms with appending enabled in the flash
kernel db in Jessie. They are:

  * Buffalo Linkstation LS-CHLv2 (kirkwood-lschlv2.dtb)
  * Buffalo Linkstation LS-XHL (kirkwood-lsxhl.dtb)
  * D-Link DNS-320 NAS (Rev A1) (kirkwood-dns320.dtb)
  * LaCie Internet Space v2 (kirkwood-is2.dtb)
  * LaCie Network Space Max v2 (kirkwood-ns2max.dtb)
  * Globalscale Technologies Dreamplug (kirkwood-dreamplug.dtb)
  * Marvell GuruPlug Reference Board
(kirkwood-guruplug-server-plus.dtb)
  * (AKA Globalscale Technologies Guruplug Server Plus)
  * Marvell SheevaPlug Reference Board (kirkwood-sheevaplug.dtb)
  * (AKA Globalscale Technologies SheevaPlug)
  * Marvell eSATA SheevaPlug Reference Board
(kirkwood-sheevaplug-esata.dtb)
  * (AKA Globalscale Technologies eSATA SheevaPlug)
  * Plat'Home OpenBlocksA6 (kirkwood-openblocks_a6.dtb)
  * Seagate FreeAgent Dockstar (kirkwood-dockstar.dtb)

Of all those only D-Link DNS-320 NAS (Rev A1) has the Mtd-kernel
field, so all the others must boot from a filesystem not an raw MTD
partition.

Sadly the db doesn't record the mtd sizes for platforms, so I don't know
how much space that model has. kirkwood-dns320.dtb is 13199 bytes
though.

   2094680  2097080
 2094680 + 10394 = 2105074  2097080
 
 The orion5x machine with the smallest known kernel partition is D-Link
 DNS-323, with 1572792 bytes space.  We currently have less than 1 KB
 to spare here.  Thankfully this machine is still supported by board
 code and doesn't need a DTB.  But if any of the other orion5x machines
 we intend to support have a similarly small kernel partition and
 require a DTB they will not work with this version.

I don't know much about orion5x, but the flash-kernel db tells me that
we don't currently append a dtb on any platform there.

1k is rather tight though, even if appending isn't needed. A security
update adding 1k of binary size wouldn't be totally out of the question
and it would be unfortunate to have to start disabling features in a
security update.

 
 Ben.
 
 -- System Information:
 Debian Release: 8.0
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
 'experimental')
 Architecture: i386 (x86_64)
 Foreign Architectures: amd64
 
 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)
 
 


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

Bug#767037: Grub EFI fallback - patches for review

[Ian Campbell]

On Mon, 2014-12-08 at 01:36 +, Steve McIntyre wrote:
 The current package in sid (-17) is unblocked and I think ought to
 transition tomorrow (or perhaps Tuesday depending on TZ). I propose to
 upload -18 with this change shortly after that happens. Will you take
 care of the unblock request or at least provide me some text with the
 rationale etc.
 
 I'll ask for the unblock, and I'll also upload grub-installer the same
 day.

Upload == done.

 -17 included some patches from Colin to make the 32-bit linuxefi command
 work.
 
 Yup, saw that. I'm looking into 32-bit EFI stuff right now. Using a
 Mac atm *shudder*

Urk!

Ian.


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

Bug#767037: Grub EFI fallback - patches for review

[Ian Campbell]

Control: tag -1 +pending

On Wed, 2014-12-03 at 15:27 +, Steve McIntyre wrote:
 On Wed, Dec 03, 2014 at 09:42:20AM +, Ian Campbell wrote:
 On Wed, 2014-12-03 at 01:55 +, Steve McIntyre wrote:
  On Tue, Dec 02, 2014 at 08:36:31AM +, Ian Campbell wrote:
  On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:
  
  Starting with grub-install-fallback.patch:
  
   From e384e597914b6e1b1dcbf96ef6782cf9bcc2313b Mon Sep 17 00:00:00 2001
debian/patches/grub-install-extra-removable.patch | 115 
   ++
  
  Could you send this to grub-de...@gnu.org? Or at least provide a commit
  log for the upstream bit inline in the patch for whoever does end up
  forwarding it.
  
  Sure, no problem. I've added a header for now. As my stuff is
  intermingled with other changes in the Debian tree, I'm not sure how
  well that will work upstream...
 
 Ah yes, if it is dependent on other non-upstream stuff then probably no
 point sending off in isolation.
 
 ACK. It's not *functionally* dependent, but it's intermingled in the
 patches.
 
  Rebased patch V2 against current git master attached...
 
 Looks good to me.
 
 Cool. I don't (think I) have push access to the git repo, so if you
 could do the honours and apply, that would be lovely. :-)

Done, patches are now in pkg-grub/grub.git#master.

The current package in sid (-17) is unblocked and I think ought to
transition tomorrow (or perhaps Tuesday depending on TZ). I propose to
upload -18 with this change shortly after that happens. Will you take
care of the unblock request or at least provide me some text with the
rationale etc.

There are a boatload of updates to debian/po/*. How is that handled? I
committed the automated thing but am I supposed to prod some process
somewhere else too?

Anyway, I suppose there will need to be a second upload at some point
with the results of those translations. Perhaps that will be a good time
to fix #771249 too.

 I'm also wanting to get this into Jessie if we can, along with the
 32-bit EFI work that's next...!

-17 included some patches from Colin to make the 32-bit linuxefi command
work.


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

Bug#767037: Grub EFI fallback - patches for review

[Ian Campbell]

On Wed, 2014-12-03 at 02:10 +, Steve McIntyre wrote:
 On Tue, Dec 02, 2014 at 08:51:24AM +, Ian Campbell wrote:
 On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:
 I didn't review the text since that seems to have been done already.
 
  diff --git a/rescue.d/81grub-efi-force-removable 
  b/rescue.d/81grub-efi-force-removable
 
 I don't know much about rescue mode, is this offering an automatic fixup
 for this issue? Does it appear in a menu to be selected rather than
 asking everyone booting rescue on an EFI system? 
 
 The .tst file is run as a test:
 
 [ -f /target/boot/grub/grub.cfg ]  ( grep -q /boot/efi /target/etc/fstab )
 
 So, the target system must have grub installed and a mention of
 /boot/efi in /etc/fstab. Assuming that it does, an extra rescue option
 of Force GRUB installation to the EFI removable media path will show
 up as an option for the user. If the user selects it, the help text in
 grub-installer/force-efi-extra-removable is shown, then they can
 select to set the option.
 

Neat, thanks for explaining.
 
  +mountvirtfs () {
  +   fstype=$1
  +   path=$2
  +   if grep -q [[:space:]]$fstype\$ /proc/filesystems  \
  +  ! grep -q ^[^ ]\+ \+$path  /proc/mounts; then
  +   mkdir -p $path || \
  +   die grub-installer/mounterr Error creating $path
  +   mount -t $fstype $fstype $path || \
  +   die grub-installer/mounterr Error mounting $path
  +   trap umount $path HUP INT QUIT KILL PIPE TERM EXIT
 
 trap doesn't stack, does it? You call mountvirtfs twice, so only the
 second umount will actually happen on error.
 
 True. This (buggy) code is already in use elsewhere in grub-installer,
 I've just borrowed it. :-/

Hrm, yes.

 Also you umount explicitly on the exit path, but don't cancel this trap,
 so I guess you'll see some noise from umount the second time.
 
 True; I've not seen any such errors, as it seems they're hidden at
 that point.
 
 I know we've established that in-target isn't widely used in this
 particular bit of code -- but it does take care of all this sort of
 thing automatically and (presumably!) correctly, as well as being only a
 single place to fix if it is wrong (e.g. in-target handles BSD
 explicitly too).
 
 Right. I've absolutely *no* idea how well any of the existing EFI
 stuff will work with BSD...!

Me neither.

  +log Mounting filesystems
  +# If we're installing grub-efi, it wants /sys mounted in the
  +# target. Maybe /proc too?
  +mountvirtfs proc /target/proc
  +mountvirtfs sysfs /target/sys
  +chroot /target mount /boot/efi || true
  +
  +db_progress STEP 1
  +db_progress INFO grub-installer/progress/step_install_loader
  +# Do the installation now
  +log Running grub-install
  +if ! chroot /target grub-install --force-extra-removable; then
 
 The main invocation would invoke this with a --target=foo-efi. Not
 sure if this matters or not.
 
 Nope, the code in grub-install already picks up on the right platform
 by default. I could add this too, but I'm not convinved it's necessary.

Lets leave it then.

 In order to avoid having to repeat all the logic twice perhaps you could
 arrange to do the debconf-set-selections thing first and then run
 dpkg-reconfigure or something in the target to force the main postinst
 to rerun and reinstall?
 
 Maybe, yeah. I'll take a look.
 
  +   db_input critical grub-installer/grub-install-failed || true
  +   db_go || true
  +   db_progress STOP
  +   exit 1
 
 You don't umount /target/boot/efi on this path.
 
 Correct, and that's definitely wanted.

The unmount is wanted or the leaving of /boot/efi mounted is? (I could
see an argument either way actually).

Ian.


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

Bug#767037: Grub EFI fallback - patches for review

[Ian Campbell]

On Wed, 2014-12-03 at 01:55 +, Steve McIntyre wrote:
 On Tue, Dec 02, 2014 at 08:36:31AM +, Ian Campbell wrote:
 On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:
 
 Starting with grub-install-fallback.patch:
 
  From e384e597914b6e1b1dcbf96ef6782cf9bcc2313b Mon Sep 17 00:00:00 2001
   debian/patches/grub-install-extra-removable.patch | 115 
  ++
 
 Could you send this to grub-de...@gnu.org? Or at least provide a commit
 log for the upstream bit inline in the patch for whoever does end up
 forwarding it.
 
 Sure, no problem. I've added a header for now. As my stuff is
 intermingled with other changes in the Debian tree, I'm not sure how
 well that will work upstream...

Ah yes, if it is dependent on other non-upstream stuff then probably no
point sending off in isolation.

 Rebased patch V2 against current git master attached...

Looks good to me.


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

Bug#767037: Grub EFI fallback - patches for review

[Ian Campbell]

On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:

Starting with grub-install-fallback.patch:

 From e384e597914b6e1b1dcbf96ef6782cf9bcc2313b Mon Sep 17 00:00:00 2001
  debian/patches/grub-install-extra-removable.patch | 115 
 ++

Could you send this to grub-de...@gnu.org? Or at least provide a commit
log for the upstream bit inline in the patch for whoever does end up
forwarding it.

 +@@ -829,6 +838,27 @@ fill_core_services (const char *core_ser
 +   free (sysv_plist);
 + }
 + 
 ++static void
 ++also_install_removable(const char *src, const char *base_efidir, const char 
 *efi_suffix_upper)
 ++{
 ++  char *efi_file = NULL;
 ++  char *dst = NULL;
 ++  char *dir = NULL;
 ++  
 ++  if (!efi_suffix_upper)
 ++grub_util_error (%s, _(You've found a bug));

There are one or two of these in the upstream code base already, but it
is a bit unfriendly to the bug-reported/triagger.

I see an existing instance of
_(you found a bug ... (%s:%d)\n), file, line)
which is a bit nicer at least. Plain old assert() sees some usage too.

The Debian-specific bits all look sensible to me, FWIW. There will be a
minor conflict with the patches in #770412 but nothing insurmountable.

 [...]
 + also depend on this path. If so, uou will need to ensure that GRUB is

Typo: uou.

Ian.


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

Bug#767037: Grub EFI fallback - patches for review

[Ian Campbell]

On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:

grub-installer-rescue-UEFI-removable.patch:

 diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates
 index e439ad0..a6af2ec 100644
 --- a/debian/grub-installer.templates
 +++ b/debian/grub-installer.templates
 @@ -209,6 +209,21 @@ Type: text
  # :sl1:
  _Description: Updating /etc/kernel-img.conf...
  
 +Template: grub-installer/progress/step_force_efi

Perhaps add _removable at the end of the name?

I didn't review the text since that seems to have been done already.

 diff --git a/rescue.d/81grub-efi-force-removable 
 b/rescue.d/81grub-efi-force-removable

I don't know much about rescue mode, is this offering an automatic fixup
for this issue? Does it appear in a menu to be selected rather than
asking everyone booting rescue on an EFI system? 

 +mountvirtfs () {
 +   fstype=$1
 +   path=$2
 +   if grep -q [[:space:]]$fstype\$ /proc/filesystems  \
 +  ! grep -q ^[^ ]\+ \+$path  /proc/mounts; then
 +   mkdir -p $path || \
 +   die grub-installer/mounterr Error creating $path
 +   mount -t $fstype $fstype $path || \
 +   die grub-installer/mounterr Error mounting $path
 +   trap umount $path HUP INT QUIT KILL PIPE TERM EXIT

trap doesn't stack, does it? You call mountvirtfs twice, so only the
second umount will actually happen on error.

Also you umount explicitly on the exit path, but don't cancel this trap,
so I guess you'll see some noise from umount the second time.

I know we've established that in-target isn't widely used in this
particular bit of code -- but it does take care of all this sort of
thing automatically and (presumably!) correctly, as well as being only a
single place to fix if it is wrong (e.g. in-target handles BSD
explicitly too).
 
 +log Mounting filesystems
 +# If we're installing grub-efi, it wants /sys mounted in the
 +# target. Maybe /proc too?
 +mountvirtfs proc /target/proc
 +mountvirtfs sysfs /target/sys
 +chroot /target mount /boot/efi || true
 +
 +db_progress STEP 1
 +db_progress INFO grub-installer/progress/step_install_loader
 +# Do the installation now
 +log Running grub-install
 +if ! chroot /target grub-install --force-extra-removable; then

The main invocation would invoke this with a --target=foo-efi. Not
sure if this matters or not.

In order to avoid having to repeat all the logic twice perhaps you could
arrange to do the debconf-set-selections thing first and then run
dpkg-reconfigure or something in the target to force the main postinst
to rerun and reinstall?

 +   db_input critical grub-installer/grub-install-failed || true
 +   db_go || true
 +   db_progress STOP
 +   exit 1

You don't umount /target/boot/efi on this path.

Ian.


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

Bug#737613: Debian Bug 737613: Xen not loading dom0 on Jessie - FATAL error on running /etc/init.d/xen

[Ian Campbell]

Control: forcemerge 503287 737613

(making $subjet a bit more helpful this time too)

On Mon, Nov 24, 2014 at 05:28:59PM +, Ian Campbell wrote:
 Before investigating any further can either of you confirm whether
 this still happens with the version of Xen currently in Jessie, which
 is 4.4.1-3 (and the current kernel too). That was a major version
 bump, so it is worth confirming.

Actually nevermind this. Right after hitting send a bit more googling around
the issue took me to http://osdir.com/ml/general/2013-09/msg42718.html which
reminded me about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503287 and
checking the original report again it appears that you are indeed running
32-bit userspace on a 64-kernel on a 64-bit Xen. Unfortunately that combination
is not supported, quoting that first link:

  The Xen i386 userspace tools cannot run on a 64-bit kernel+hypervisor
  combo.
  
  The working combinations are:
  
  64 bit hyp, 64 bit dom0 kernel, 64 bit dom0 userspace.
  64 bit hyp, 32 bit dom0 kernel, 32 bit dom0 userspace.

The failure would be the same sort of invalid ioctl error as was observed.

Sorry for not spotting this sooner. Unfortunately this is unlikely to be fixed
within Debian (it's really an upstream thing).

Now that multiarch exists I think it ought to be possible to install the 64-bit
Xen toolstack on an otherwise 32-bit dom0 userspace, but I've not tried that
myself.

Sorry again for not figuring this out before.

I'm merging this bug with the existing wishlist bug, which is tagged wontfix
I'm afraid. It occurs to me today that /etc/init.d/xen could at least try and
detect this situation and warn about it instead of hanging.

Ian.


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

Bug#770412: grub-xen: fails to install in a chroot

[Ian Campbell]

On Fri, 2014-11-21 at 20:34 +, Ian Campbell wrote:
 Anyway, I'll investigate ischroot or running-in-container which the grub
 postinst seem to use already (not sure what it does, might be suitable).

Neither of those seemed quite right, so here is what I came up with.
Passes a local piuparts run and installation in a Xen guest.

Colin, does this seem sane? It has the affect that grub-* will no longer
fail to install if grub-install fails for some reason -- that could be
seen as either a good or bad thing I suspect...

8--

From a8eb7d27c945df31eaca58ba02948d0f1964b0e9 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@debian.org
Date: Sat, 22 Nov 2014 10:03:48 +
Subject: [PATCH] Log a failure in postinst when grub-install fails instead of
 failing entirely

This allows installation of the package when e.g. dev is not mounted etc.

The change covers all invocations of grub-install which do not already have
special handling of some sort.
---
 debian/changelog   |  7 +++
 debian/postinst.in | 20 ++--
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 40db9e9..90a9412 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+grub2 (2.02~beta2-17) UNRELEASED; urgency=medium
+
+  * Log failure when grub-install fails in postinst, rather than failing the
+entire postinst. (Closes: #770412)
+
+ -- Ian Campbell i...@debian.org  Sat, 22 Nov 2014 07:45:46 +
+
 grub2 (2.02~beta2-16) unstable; urgency=medium
 
   [ Ian Campbell ]
diff --git a/debian/postinst.in b/debian/postinst.in
index 30e6947..056e27d 100644
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -299,6 +299,14 @@ running_in_container()
   type running-in-container /dev/null 21  running-in-container /dev/null
 }
 
+run_grub_install()
+{
+if ! grub-install $@ ; then
+echo Failed: grub-install $@ 2
+echo WARNING: Bootloader is not properly installed, system may not be 
bootable 2
+fi
+}
+
 case $1 in
   configure)
 . /usr/share/debconf/confmodule
@@ -696,7 +704,7 @@ case $1 in
 grub-efi-arm)   target=arm-efi ;;
 grub-efi-arm64) target=arm64-efi ;;
   esac
-  grub-install --target=$target
+  run_grub_install --target=$target
 fi
 
 # /boot/grub/ has more chances of being accessible by GRUB
@@ -714,22 +722,22 @@ case $1 in
 # Output may be empty; if so, just update the core image but
 # don't install it to any PReP partition.
 prep_bootdev=$(/usr/lib/grub/powerpc-ieee1275/prep-bootdev)
-grub-install --target=powerpc-ieee1275 $prep_bootdev
+run_grub_install --target=powerpc-ieee1275 $prep_bootdev
   ;;
 esac
   ;;
 
   grub-yeeloong)
-grub-install --target=mipsel-loongson
+run_grub_install --target=mipsel-loongson
   ;;
 
   grub-xen)
 # Install for x86_64 regardless of arch, since a 32-bit userspace can 
still boot with a 64-bit kernel.
-   mkdir -p /boot/xen
-grub-install --target=x86_64-xen
+mkdir -p /boot/xen
+run_grub_install --target=x86_64-xen
 case $(dpkg --print-architecture) in
   i386)
-grub-install --target=i386-xen
+run_grub_install --target=i386-xen
   ;;
 esac
   ;;
-- 
2.1.3


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

Bug#770412: grub-xen: fails to install in a chroot

[Ian Campbell]

Control: tag -1 +patch

On Sat, 2014-11-22 at 00:39 +, Colin Watson wrote:

I only saw this after I sent my previous mail with patch.

(also forgot to add the patch tag, doing that here instead)

 On Fri, Nov 21, 2014 at 12:42:43PM +, Ian Campbell wrote:
  Looking at https://piuparts.debian.org/jessie/source/g/grub2.html it
  seems the test passed for other grub-* packages, e.g. grub-pc and
  grub-efi, in the previous release. I'm a bit confused by this since at
  least on first glance most of the related code seems to be the same in
  grub-xen as in those others.
 
 I think the difference here is likely that at least some of the other
 platforms only run grub-install after it's been run once already, and as
 you say we probably just don't run piuparts on the more exotic
 architectures.  Not clear that that approach makes sense for Xen though.
 
  Is it expected that the chroot in a piuparts test won't have a /dev
  mounted? What about /sys and /proc?
 
 We can't necessarily guarantee that /dev is comprehensible by
 grub-install in things like loopback setups.  But we do at least need to
 figure out the file system in use for /boot/grub/ in order to produce a
 useful core image, so we probably can't just stub out this check.

Agreed.

 I'm not sure that ischroot or running-in-container is suitable.

No, I later concluded not too.

 It seems to me that you want to be able to prepare an image in a chroot or
 a container which will be bootable by Xen.

Yes, agreed.

   It's not ideal, but perhaps
 just sticking in || true is semi-reasonable in this case to pacify
 piuparts.

I ended up doing essentially that but in a slightly more complex way
involving a warning message. I also applied it to more than just
grub-xen (i.e. grub-efi-*, grub-ieee1275, grub-yeelong too). I'll back
off on one or both of those in favour of || true though if you prefer.

 It would be worth checking whether the current code works in
 image-build-like scenarios such as live-build.

I doubt grub-xen is being installed there at all, but I'd expect the
same class of errors to be affecting grub-efi-* too,
iff /boot/efi/EFI/Debian existed in those scenarios -- which perhaps it
does not.

Ian.


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

Bug#770412: grub-xen: fails to install in a chroot

[Ian Campbell]

On Fri, 2014-11-21 at 04:02 +0100, Andreas Beckmann wrote:
 during a test with piuparts I noticed your package failed to install. As
 per definition of the release team this makes the package too buggy for
 a release, thus the severity.

Thanks.

It seems like https://piuparts.debian.org/sid/source/g/grub2.html
doesn't show this result yet, I suppose this was run manually and/or by
some other service? (or maybe there is some lag in the index?). Does
really matter, I just wanted to check the status of the other grub-*
packages.

Looking at https://piuparts.debian.org/jessie/source/g/grub2.html it
seems the test passed for other grub-* packages, e.g. grub-pc and
grub-efi, in the previous release. I'm a bit confused by this since at
least on first glance most of the related code seems to be the same in
grub-xen as in those others.

Is it expected that the chroot in a piuparts test won't have a /dev
mounted? What about /sys and /proc?

I take it there is no piuparts overrides in place for the other grub-*
packages?

Anyway, I'll investigate, thanks for bringing this to my attention.

Ian.

 From the attached log (scroll to the bottom...):
 
   Selecting previously unselected package grub-xen.
   (Reading database ... 8098 files and directories currently installed.)
   Preparing to unpack .../grub-xen_2.02~beta2-16_amd64.deb ...
   Unpacking grub-xen (2.02~beta2-16) ...
   Setting up grub-xen (2.02~beta2-16) ...
   
   Creating config file /etc/default/grub with new version
   Installing for x86_64-xen platform.
   grub-install: error: cannot find a device for /boot/grub (is /dev mounted?).
   dpkg: error processing package grub-xen (--configure):
subprocess installed post-installation script returned error exit status 1
   Errors were encountered while processing:
grub-xen
 
 
 cheers,
 
 Andreas
 ___
 Pkg-grub-devel mailing list
 pkg-grub-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grub-devel


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

Bug#770412: grub-xen: fails to install in a chroot

[Ian Campbell]

On Fri, 2014-11-21 at 14:31 +0100, Andreas Beckmann wrote:
[...snip, useful info, thanks...]

 There is an ischroot command in debianutils.
 
  I take it there is no piuparts overrides in place for the other grub-*
  packages?
 
 No, they work out-of-the-box now.

It seems their postinsts are typically keying the invocation of
grub-install on the presence of some directory e.g. /boot/efi/ in the
case of grub-efi-* or some complex debconf stuff in the case of grub-pc.
Some of the non-x86 arches look to me like they would fail if piuparts
was run on those arches.

Anyway, I'll investigate ischroot or running-in-container which the grub
postinst seem to use already (not sure what it does, might be suitable).

Ian.


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

Bug#764162: [PATCH 0/1] mv643xx_eth: Disable TSO by default

[Ian Campbell]

On Tue, 2014-11-04 at 15:20 +0100, Karl Beldan wrote:
 On Sat, Nov 01, 2014 at 12:30:19PM -0300, Ezequiel Garcia wrote:
  Several users ([1], [2]) have been reporting data corruption with TSO on
  Kirkwood platforms (i.e. using the mv643xx_eth driver).
  
  Until we manage to find what's causing this, this simple patch will make
  the TSO path disabled by default. This patch should be queued for stable,
  fixing the TSO feature introduced in v3.16.
  
  The corruption itself is very easy to reproduce: checking md5sum on a 
  mounted
  NFS directory gives a different result each time. Same tests using the 
  mvneta
  driver (Armada 370/38x/XP SoC) pass with no issues.
  
  Frankly, I'm a bit puzzled about this, and so any ideas or debugging hints
  are well received.
  
 
 Hi,
 
 Can you try this :

It fixes things for me, thanks!

Tested-by: Ian Campbell i...@hellion.org.uk

 @@ -1067,7 +1082,8 @@ static int txq_reclaim(struct tx_queue *txq, int 
 budget, int force)
   txq-tx_desc_count--;
  
   skb = NULL;
 - if (cmd_sts  TX_LAST_DESC)
 + if ((cmd_sts  (TX_LAST_DESC | TX_ENABLE_INTERRUPT)) ==
 +(TX_LAST_DESC | TX_ENABLE_INTERRUPT))
   skb = __skb_dequeue(txq-tx_skb);
  
   if (cmd_sts  ERROR_SUMMARY) {
 


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

Bug#764162: linux-image-3.16-2-kirkwood: [regression 3.14-3.16] file data corruption, via network

[Ian Campbell]

On Fri, 2014-10-31 at 14:29 +0100, Julien D'Ascenzio wrote:
 Le vendredi 31 octobre 2014 à 09:50 +, Ian Campbell a écrit :
  On Sun, 2014-10-19 at 14:27 +0100, Ian Campbell wrote:
You could inactivate this feature manually with:
ethtool -K eth0 tso off

I'm in contact with the developer of this feature. Tell me if this 
command resolve your problem
   
   Excellent, please let us know how you get on (feel free to CC the bug
   too if you want).
  
  Did you make any progress with the developer?
  
  In the changes to this driver since v3.16 I see
  commit 817dbfa5d1bc276a72c1a577310382008e8aca0a
  Author: Vlad Yasevich vyasev...@gmail.com
  Date:   Mon Aug 25 10:34:54 2014 -0400
  
  mvneta: Fix TSO and checksum for non-acceleration vlan traffic
  
  which might be potentially interesting, except no one on this bug has
  mentioned VLANs at any point.
  
  I don't see anything else of interest.
  
  Ian.
  
 
 I don't have more information. They seems not to understand why there
 are data corrupt with this soc. The only solution at this time is to
 inactivate tso or apply this patch, which makes TSO disabled by default:

I've now managed to update my qnap box too and can trivially see file
corruption over NFS. Unless anyone has any ideas or suggested fixes I'm
going to apply this patch to disable TSO by default to the Debian
kernel.

 
 diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
 b/drivers/net/ethernet/marvell/mv643xx_eth.c
 index 693b5b5..8e6df75 100644
 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
 +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
 @@ -3113,11 +3113,11 @@ static int mv643xx_eth_probe(struct
 platform_device *pdev)
 dev-watchdog_timeo = 2 * HZ;
 dev-base_addr = 0;
  
 -   dev-features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
 +   dev-features = NETIF_F_SG | NETIF_F_IP_CSUM;
 dev-vlan_features = dev-features;
  
 dev-features |= NETIF_F_RXCSUM;
 -   dev-hw_features = dev-features;
 +   dev-hw_features = dev-features  | NETIF_F_TSO;
  
 dev-priv_flags |= IFF_UNICAST_FLT;
 dev-gso_max_segs = MV643XX_MAX_TSO_SEGS;
 
 I CC my contact
 
 Julien D'Ascenzio
 
 


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

Bug#764162: linux-image-3.16-2-kirkwood: [regression 3.14-3.16] file data corruption, via network

[Ian Campbell]

On Tue, 2014-11-04 at 08:51 +, Ian Campbell wrote:
 On Fri, 2014-10-31 at 14:29 +0100, Julien D'Ascenzio wrote:
  Le vendredi 31 octobre 2014 à 09:50 +, Ian Campbell a écrit :
   On Sun, 2014-10-19 at 14:27 +0100, Ian Campbell wrote:
 You could inactivate this feature manually with:
 ethtool -K eth0 tso off
 
 I'm in contact with the developer of this feature. Tell me if this 
 command resolve your problem

Excellent, please let us know how you get on (feel free to CC the bug
too if you want).
   
   Did you make any progress with the developer?
   
   In the changes to this driver since v3.16 I see
   commit 817dbfa5d1bc276a72c1a577310382008e8aca0a
   Author: Vlad Yasevich vyasev...@gmail.com
   Date:   Mon Aug 25 10:34:54 2014 -0400
   
   mvneta: Fix TSO and checksum for non-acceleration vlan traffic
   
   which might be potentially interesting, except no one on this bug has
   mentioned VLANs at any point.
   
   I don't see anything else of interest.
   
   Ian.
   
  
  I don't have more information. They seems not to understand why there
  are data corrupt with this soc. The only solution at this time is to
  inactivate tso or apply this patch, which makes TSO disabled by default:
 
 I've now managed to update my qnap box too and can trivially see file
 corruption over NFS. Unless anyone has any ideas or suggested fixes I'm
 going to apply this patch to disable TSO by default to the Debian
 kernel.

I've just seen https://patchwork.ozlabs.org/patch/405792/ so I'm going
to go ahead for now.

Ian.


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

Bug#764162: linux-image-3.16-2-kirkwood: [regression 3.14-3.16] file data corruption, via network

[Ian Campbell]

On Sun, 2014-10-19 at 14:27 +0100, Ian Campbell wrote:
  You could inactivate this feature manually with:
  ethtool -K eth0 tso off
  
  I'm in contact with the developer of this feature. Tell me if this 
  command resolve your problem
 
 Excellent, please let us know how you get on (feel free to CC the bug
 too if you want).

Did you make any progress with the developer?

In the changes to this driver since v3.16 I see
commit 817dbfa5d1bc276a72c1a577310382008e8aca0a
Author: Vlad Yasevich vyasev...@gmail.com
Date:   Mon Aug 25 10:34:54 2014 -0400

mvneta: Fix TSO and checksum for non-acceleration vlan traffic

which might be potentially interesting, except no one on this bug has
mentioned VLANs at any point.

I don't see anything else of interest.

Ian.


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

Bug#764162: linux-image-3.16-2-kirkwood: [regression 3.14-3.16] file data corruption, via network

[Ian Campbell]

On Sun, 2014-10-19 at 14:44 +0200, Julien D'Ascenzio wrote:
 Since v3.16 kernel a tso feature was introduced in the driver of marvell 
 ethernet. This feature seems to work badly.

3.16-1~exp1 was reported as not exhibiting the issue, but maybe that was
just a quick test which got lucky. So this is nonetheless a good tip and
something worth trying, thanks!

 You could inactivate this feature manually with:
 ethtool -K eth0 tso off
 
 I'm in contact with the developer of this feature. Tell me if this 
 command resolve your problem

Excellent, please let us know how you get on (feel free to CC the bug
too if you want).

Ian.


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

Bug#764162: linux-image-3.16-2-kirkwood: [regression 3.14-3.16] file data corruption, via network

[Ian Campbell]

On Sun, 2014-10-12 at 23:46 +0200, Svenska wrote:
  If you were able to try 3.16-1~exp1[0]
  from snapshot.debian.org that might help rule that out.
 
 I downloaded linux-image-3.16-trunk-kirkwood_3.16-1~exp1_armel.deb from 
 your link and flashed it into the NAS. I have not done a deeper 
 analysis, but it looks like the problem is gone.
 
 For now, I will revert back to the known-working 3.14-2 (3.14.15-2) 
 anyway, but if you want me to test another binary image, I could do that 
 if given a week or two.
 
 Hope this helps.

Thanks, it narrows it down to a change on the Debian side rather than a
generic 3.16 upgrade breakage.

Looking at the changelog the most plausible looking candidate is still
the enabling of CONFIG_HIGHMEM. Your system has far less RAM than I
would expect to need highmem though.

If you are comfortable building a kernel for yourself (see [0] for
details) then it might be interesting to try rebuilding without
CONFIG_HIGHMEM.

Ian.

[0] 
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official


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

Bug#764162: linux-image-3.16-2-kirkwood: [regression 3.14-3.16] file data corruption, via network

[Ian Campbell]

On Mon, 2014-10-06 at 01:21 +0200, Svenska wrote:
 Package: src:linux
 Version: 3.16.3-2
 Severity: serious
 Justification: may cause silent data corruption
 
 Hello,
 
 after upgrading the kernel of my NAS to 3.16-2-kirkwood, I noticed
 corrupt data on my files. The NAS works as a DHCP client on its single
 LAN port, the two hard drives run in a RAID1 configuration. Both
 drives are fine according to mdadm and smartctl. Kernel logs in both
 cases have not been eye-catching. Samba is configured with unix
 charset = ISO-8859-1.
 
 When copying data from the NAS to some other device using CIFS or
 Samba (the other devices run jessie/amd64 or wheezy/i686), the files
 are partly corrupt. The reported md5 checksums of files change every
 time the files are read. (And they differ from the checksums as stored
 on disk as well.) The files are not completely destroyed: ZIP archives
 show CRC errors only for some files in them, and video files remain
 generally playable, with lots of audio/video errors and crashing
 players.
 
 Shell access using SSH generally works. Trying to copy files with scp
 or sftp breaks the connection (invalid MAC packets or similar). File
 listing and mounting with sshfs work. Trying to copy files via sshfs
 results in a Socket not connected error, and the mount point is
 gone.
 
 As far as I can see, the on-disk data seems to be fine, as do files
 copied to the NAS while running the corrupt kernel. I am unable to
 check all new files, though - there might have been silent data
 corruption on new files.

It's sounding like the issue might be corruption on the networking path
rather than the disk path then?

 Data corruption on NAS devices is a serious issue for me.
 Reverting back to 3.14-2-kirkwood fixed the problems.

Which exact version did you revert to? Looking at debian/changelog since
the first 3.14 version I don't see much specific to kirkwood. At some
point there were some changes with the network PHY but they predate 3.14
IIRC.

The only thing which jumps out is [armel/kirkwood] mm: Enable HIGHMEM
(Closes: #760786) in 3.16.2-1. If you were able to try 3.16-1~exp1[0]
from snapshot.debian.org that might help rule that out.

If 3.16-1~exp1 still has the issue then I think we are looking at an
upstream regression. It might be worth bisecting a bit over the old
kernels from experimental which can be found on snapshot.d.o e.g. to
narrow down if the issue appeared in 3.15 or 3.16.

After that please could you to take this up with the upstream
developers[1], who are normally very responsive to kirkwood issues. 

Thanks,
Ian.

[0] Should be at http://snapshot.debian.org/package/linux/3.16-1~exp1/
[1]
ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
M:  Jason Cooper ja...@lakedaemon.net
M:  Andrew Lunn and...@lunn.ch
M:  Sebastian Hesselbarth sebastian.hesselba...@gmail.com
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S:  Maintained


 
 Best Regards
 
 -- Package-specific info:
 ** Kernel log: boot messages should be attached
 
 ** Model information
 Hardware  : QNAP TS-119/TS-219
 Revision  : 
 
 ** PCI devices:
 00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. Device 
 [11ab:6282] (rev 01)
   Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
 Stepping- SERR+ FastB2B- DisINTx+
   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
 MAbort+ SERR- PERR- INTx-
   Latency: 0, Cache Line Size: 32 bytes
   Interrupt: pin A routed to IRQ 9
   Region 0: Memory at ignored (64-bit, prefetchable)
   Capabilities: access denied
 
 00:01.0 SATA controller [0106]: JMicron Technology Corp. JMB363 SATA/IDE 
 Controller [197b:2363] (rev 03) (prog-if 01 [AHCI 1.0])
   Subsystem: JMicron Technology Corp. JMB363 SATA/IDE Controller 
 [197b:2363]
   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
 Stepping- SERR+ FastB2B- DisINTx-
   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
 MAbort- SERR- PERR- INTx-
   Latency: 0, Cache Line Size: 32 bytes
   Interrupt: pin A routed to IRQ 9
   Region 5: Memory at e001 (32-bit, non-prefetchable) [size=8K]
   [virtual] Expansion ROM at e000 [disabled] [size=64K]
   Capabilities: access denied
   Kernel driver in use: ahci
 
 00:01.1 IDE interface [0101]: JMicron Technology Corp. JMB363 SATA/IDE 
 Controller [197b:2363] (rev 03) (prog-if 85 [Master SecO PriO])
   Subsystem: JMicron Technology Corp. JMB363 SATA/IDE Controller 
 [197b:2363]
   Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ 
 Stepping- SERR+ FastB2B- DisINTx-
   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
 MAbort- SERR- PERR- INTx-
   Interrupt: pin B routed to IRQ 9
   Region 0: I/O ports at 1010 [disabled] [size=8]
   Region 1: I/O ports at 1020 

Bug#760215: linux-image-3.14-2-kirkwood: Not enough space in MTD RootFS1 (need 9768399 but is actually 9437184)

[Ian Campbell]

On Mon, 2014-09-01 at 23:51 +0200, Diego Fernandez Duran wrote:
Not enough space in MTD RootFS1 (need 9768399 but is actually 9437184).

What do you have in /etc/initramfs-tools/initramfs.conf for MODULES=?

I have MODULES=most and the largest initrd I have is 3177784, about 1/3
of yours.

I believe MODULES=most is the default when installing on qnap systems
(tweaked by debian-installer at install time IIRC).

Ian.


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

Bug#758581: debian-installer: FTBFS on armhf/network-console: No library provides non-weak __aeabi_unwind_cpp_pr0

[Ian Campbell]

On Fri, 2014-08-22 at 05:26 +0200, Cyril Brulebois wrote:
 Ian Campbell i...@hellion.org.uk (2014-08-22):
  The Internet(tm) seems to think that __aeabi_unwind_cpp_pr0 comes from
  libunwind, but the wifi in this hotel is making it a rather slow job
  to figure out what might be depending on that and/or whether there
  is/should be a udeb for it, I'll try and investigate further though.
  
  Interesting that only the network-console flavour is affected
 
 Comparing netboot and network-console builds before the library
 reduction phase leads to an interesting diff, which I'm not attaching
 because I think that's not really needed, see below.
 
 
 (BTW: There's a similar symbol in the kernel but I'm going to assume the
 *.ko diff is totally irrelevant to the problem in mklibs…)

Yes, I'm sure it is irrelevant.

 Letting netboot go through, and grepping for that symbol, there's no
 match in the resulting tree; on the contrary, network-console still gets
 some:
 | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so-stripped matches
 | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so matches
 | Binary file tmp/network-console/tree/lib/libc.so.6-so matches
 
 Interestingly, grepping for libcrypt.so in netboot shows no match, while
 network-console has:
 | Binary file tmp/network-console/tree/bin/gen-crypt matches
 | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so-stripped matches
 | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so matches
 | Binary file tmp/network-console/tree/usr/sbin/sshd matches
 
 See? Both gen-crypt and sshd are only in the network-console image, and
 apparently pulling libcrypt.so.1, which comes from libc:
 | libc6:armhf: /lib/arm-linux-gnueabihf/libcrypt.so.1
 
 Also in the tree, nm -D shows that this libcrypt.so.1-so* have:
 |  U __aeabi_unwind_cpp_pr0
 which is likely what mklibs barfs about.
 
 
 Bottom line: FTBFS vs. non-FTBFS depending on image type is likely
 explained by the differences in binaries included in each image;

Agreed.

  and
 that FTBFS was likely introduced by a toolchain update which mklibs
 doesn't exactly cope nicely with, yet.

Possibly. One thing I'm confused about is that the symbol is apparently
provided by libgcc_s.so.1 but that doesn't appears under
tmp/network-console/ anywhere. But surely some other symbols from
libgcc_s must be being used already.

Running mklibs by hand in verbose mode AFAICT it is never even
considering libgcc_s.so.1. 

Copying /lib/arm-linux-gnueabihf/libgcc_s.so.1 to
tmp/network-console/tree/lib/ (which I'm sure is quite wrong...) doesn't
work but it does cause mklibs to spit out some interesting debug:

needed_symbols adding __aeabi_unwind_cpp_pr0, weak: False
[...]
present_symbols adding __aeabi_unwind_cpp_pr0@GCC_3.5@libgcc_s.so.1
[...]
Exception: No library provides non-weak __aeabi_unwind_cpp_pr0

(the middle line is from calling mklibs-readelf
--print-symbols-provided ./tmp/network-console/tree/lib/libgcc_s.so.1)

Which made me wonder if the issue might be to do with symbol versioning
somehow?

 For the record, I'm listing below where the symbol is referenced (T in
 libgcc_s.so.1, U elsewhere).

Was it deliberate that this referenced the host (/lib etc) rather than
the build tree?

I've timed out for now, but I'll continue prodding as I have the
chance...

Ian.


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

Bug#758581: debian-installer: FTBFS on armhf/network-console: No library provides non-weak __aeabi_unwind_cpp_pr0

[Ian Campbell]

On Sun, 2014-08-24 at 21:24 +0100, Ian Campbell wrote:
 I've timed out for now, but I'll continue prodding as I have the
 chance...

I caught up with Adam Conrad a debconf and he pointed out that __aeabi_*
are some weird internal ABI thing which doesn't actually indicate an
unresolved symbol. IOW they should be ignored, dpkg-shlibs does this too
(search for __aeabi_ in /usr/share/perl5/Dpkg/Shlibs/SymbolFile.pm)

Rebuilding the installer with mklibs patches as below seems to work, in
that I can chroot tmp/network-console/tree/ /bin/sh and then in the
chroot /usb/sbin/sshd --help runs and produces output. If the symbol
were actually required at runtime then this would have failed with some
sort of dynamic linker error.

This:
# LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux-armhf.so.3 /usr/sbin/sshd 
libcrypto.so.1.0.0 = /usr/lib/libcrypto.so.1.0.0 (0xb6ddd000)
libutil.so.1 = /lib/libutil.so.1 (0xb6dcb000)
libz.so.1 = /usr/lib/libz.so.1 (0xb6da9000)
libcrypt.so.1 = /lib/libcrypt.so.1 (0xb6d6c000)
libc.so.6 = /lib/libc.so.6 (0xb6cc1000)
/lib/ld-linux-armhf.so.3 (0xb6f7c000)
libdl.so.2 = /lib/libdl.so.2 (0xb6cb)

indicates that the ssh binary is indeed using those libraries which
appear to depend on the problematic symbol.

What's not clear is why this is just occurring now. I suppose changes to
gcc/glibc or something have caused it to be exposed. I don't propose to
dig much deeper into that aspect (mostly on the basis that if
dpkg-shlibs does it mklibs should too).

So I think we should upload a new mklibs and have a new debian-installer
upload which buidld-deps on it.

Ian.

From cf0887e69d4d150e240fa3770e03464ed79aa442 Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@hellion.org.uk
Date: Mon, 25 Aug 2014 02:22:15 +0100
Subject: [PATCH] Ignore all ARM EABI symbols (__aeabi_*)

---
 debian/changelog |  7 +++
 src/mklibs   | 11 +++
 2 files changed, 18 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index e9afd36..303e1c1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mklibs (0.1.40) UNRELEASED; urgency=medium
+
+  * Ignore all ARM EABI symbols (__aeabi_*). These are artefacts of the ABI and
+not real symbols which need to be present.
+
+ -- Ian Campbell i...@hellion.org.uk  Mon, 25 Aug 2014 02:08:09 +0100
+
 mklibs (0.1.39) unstable; urgency=medium
 
   * Sort objects and libraries to reduce entropy in the output, which
diff --git a/src/mklibs b/src/mklibs
index d9b784b..1f3d60f 100755
--- a/src/mklibs
+++ b/src/mklibs
@@ -137,6 +137,14 @@ class UndefinedSymbol(Symbol):
 super(UndefinedSymbol, self).__init__(name, version, library)
 self.weak, self.library = weak, library
 
+def symbol_is_blacklisted(name):
+# The ARM Embedded ABI spec states symbols under this namespace as
+# possibly appearing in output objects.
+if name.startswith(__aeabi_):
+return True
+
+return False
+
 # Return undefined symbols in an object as a set of tuples (name, weakness)
 def undefined_symbols(obj):
 if not os.access(obj, os.F_OK):
@@ -148,6 +156,9 @@ def undefined_symbols(obj):
 for line in output:
 name, weak_string, version_string, library_string = line.split()[:4]
 
+if symbol_is_blacklisted(name):
+continue
+
 weak = False
 if weak_string.lower() == 'true':
 weak = True
-- 
2.0.1


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

Bug#758886: closing 758886, closing 758901

[Ian Campbell]

close 758886 
close 758901 
thanks

Further information on #756449 shows that u-boot-tools has been reinstated so I
think nothing needs to be done for sunxi-tools any more, hence closing both
bugs.

Ian.


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

Bug#758886: sunxi-tools: Requires u-boot-tools to build which is no longer available for powerpc

[Ian Campbell]

On Fri, 2014-08-22 at 08:25 -0400, Scott Kitterman wrote:
 Package: sunxi-tools
 Version: 1.2-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 u-boot has dropped powerpc from its supported architectures, so this package
 will no longer build on powerpc as currently packaged.  It needs to be
 adapted to build on powerpc without u-boot-tools.

It pretty much cannot be built without mkimage from u-boot-tools. Given
that I think the right answer is to clone this into two bugs:

The first to request the removal of the existing sunxi-tools:powerpc
binaries from the archive and the second a wishlist bug against u-boot
to provide u-boot-tools even for architectures which don't build a
u-boot binary, since the tools are often useful even on systems which
don't use u-boot (for cross-development).

Ian.


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

Bug#758886: sunxi-tools: Requires u-boot-tools to build which is no longer available for powerpc

[Ian Campbell]

Control: clone -1 -2
Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: sunxi-tools [powerpc] -- RoM; ANAIS; build dependency 
removed
Control: reassign -2 src:u-boot
Control: severity -2 wishlist
Control: retitle -2 please build u-boot-tools on all architectures.

On Fri, 2014-08-22 at 17:36 +0100, Ian Campbell wrote:
 On Fri, 2014-08-22 at 08:25 -0400, Scott Kitterman wrote:
  Package: sunxi-tools
  Version: 1.2-1
  Severity: serious
  Justification: fails to build from source (but built successfully in the 
  past)
  
  u-boot has dropped powerpc from its supported architectures, so this package
  will no longer build on powerpc as currently packaged.  It needs to be
  adapted to build on powerpc without u-boot-tools.
 
 It pretty much cannot be built without mkimage from u-boot-tools. Given
 that I think the right answer is to clone this into two bugs:
 
 The first to request the removal of the existing sunxi-tools:powerpc
 binaries from the archive and the second a wishlist bug against u-boot
 to provide u-boot-tools even for architectures which don't build a
 u-boot binary, since the tools are often useful even on systems which
 don't use u-boot (for cross-development).

@ftp.debian.org: Requesting removal since #756449 removed u-boot-tools
which is a build dependency of this package, from powerpoc, hence
sunxi-tools now FTBFS.

@u-boot: It would be nice(tm) to provide u-boot-tools for all
architectures even those which don't have any supported platforms.

Cheers,
Ian.


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

Bug#758581: debian-installer: FTBFS on armhf/network-console: No library provides non-weak __aeabi_unwind_cpp_pr0

[Ian Campbell]

On Tue, 2014-08-19 at 00:34 +0200, Cyril Brulebois wrote:

 | -Object: ./tmp/network-console/tree/lib/libgcc_s.so.1-so-stripped
 […]
 | +1170 symbols, 38 unresolved
 | +Traceback (most recent call last):
 | +  File /usr/bin/mklibs, line 560, in module
 | +raise Exception(No library provides non-weak %s % name)
 | +Exception: No library provides non-weak __aeabi_unwind_cpp_pr0
 
 libgcc_s.so.1 comes from a gcc package, and there's been a gcc-4.9
 package in unstable for 2 days, which might match. But then I don't
 see any difference in package contents or symbols list for the
 libgcc1 packages between 1:4.9.1-5 and 1:4.9.1-7. I'm afraid I'm
 running out of the time to dig deeper into what's mklibs is after
 (possibly a _pic.a but I don't see any for libgcc_s). Having both
 a glibc and a gcc-4.9 upload in the said time window could explain
 this regression, as a wild guess.

The Internet(tm) seems to think that __aeabi_unwind_cpp_pr0 comes from
libunwind, but the wifi in this hotel is making it a rather slow job to
figure out what might be depending on that and/or whether there
is/should be a udeb for it, I'll try and investigate further though.

Interesting that only the network-console flavour is affected

 Could somebody from debian-arm@ (x-d-cc) check what's going on
 precisely and possibly forward the failure to the right place if
 d-i isn't the buggy package here?
 
 Thanks for your time.
 
 Mraw,
 KiBi.
 
 


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

Bug#753121: FTBFS, needs to build-depend on libgnutls28-dev / libgcrypt20-dev

[Ian Campbell]

On Sun, 2014-07-13 at 14:27 +0100, peter green wrote:
 
  libvirt's build-dependencies are uninstallable on current sid:
  -
  The following packages have unmet dependencies:
   libssh2-1-dev : Depends: libgcrypt20-dev but it is not going to be 
  installed
  E: Build-dependencies for libvirt could not be satisfied.
  -
 
  Please update to libgnutls28-dev / libgcrypt20-dev.

 Just FYI I just uploaded to debian-ports arm64 unreleased with the attatched
 debdiff as this was blocking stuff there. I took the approach of using 4.8
 explicitly to avoid any problems with 4.9

FWIW the issue with gcc-4.9 was x86 specific. libvirt built fine for
arm64 for me locally with just the first hunk of your changes to
debian/control.

Ian.


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

Bug#751816: flash-kernel and dtb

[Ian Campbell]

On Fri, 2014-07-11 at 16:33 -0700, Vagrant Cascadian wrote:
 Control: tags 751816 patch
 
 On Tue, Jul 08, 2014 at 08:03:30PM +0100, Ian Campbell wrote:
  I think the patch below resolves the worst issue and it works for me on
  cubietruck.
  
  The more minor stuff mentioned in that report I'm not sure it is
  actually worth worrying over. The main one seems to be
  that /etc/default/flash-kernel:LINUX_KERNEL_CMDLINE is still populated
  even on systems where there is no way at all for it to get used.
  
  Thoughts on that?
 
 Looks good to me.

Thanks. I'll try and find time to do an upload ASAP. I think I'll change
the (Partially addresses #751816) into a proper closes and leave the
other more minor issues alone unless/until they bite actual users.

 The only improvement I might suggest is deleting the line entirely if
 LINUX_KERNEL_CMDLINE isn't set, but that's a minor point. Would definitely 
 like
 to see the updated flash-kernel hit jessie soon!

You mean the setenv line? I think setenv bootargs ${bootargs}  should
be harmless enough.

Omitting it would be a bit tricky and would rely on me knowing more
about the supported feature set of each platforms shell or making
flash-kernel more complicated somehow. I don't think it's worth it, what
do you think?

Ian.


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

Bug#753121: Reported gcc bug as #754548

[Ian Campbell]

Control: block -1 by 754548

It didn't look like it had been reported yet so I've reported the gcc
bug as #754548.

Cheers,
Ian.


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

Bug#753121: gnulib test failure caused by compiler bug

[Ian Campbell]

On Sat, 2014-07-12 at 10:00 +0100, Colin Watson wrote:
 [I need libvirt to be buildable for an upcoming parted transition, so:]
 
 On Sat, Jul 05, 2014 at 10:22:05PM +0200, Julian Taylor wrote:
  the test failure is due to a compiler bug in gcc-4.9:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61725
 
 Looks like this is fixed upstream now.  Matthias, could you grab that
 fix for the Debian gcc-4.9 package?

Looks like I should have hit refresh on the bug log one more time before
I reported #754548.

Ian.


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

Bug#751816: Unresolved issues with bootargs handling

[Ian Campbell]

Package: flash-kernel
Version: 3.20
Severity: serious
X-Debbugs-CC: debian-...@lists.debian.org

The new boot.scr bootargs handling needs some work before it is suitable
for Jessie, so filing this as an rc bug.

See the thread starting at
https://lists.debian.org/debian-arm/2014/06/msg00064.html for discussion.

The main issue is the unconditional override of the u-boot environment
bootargs, which is surprising to users and perhaps wrong e.g. it can
omit console settings etc.

Some more minor issues:
  * Default /etc/default/flash-kernel:LINUX_KERNEL_CMDLINE is not
set  when flash-kernel is upgraded. It is only set for fresh
install, perhaps set from /proc/cmdline?
  * Debconf stuff for LINUX_KERNEL_CMDLINE should only be active for
systems where it will be used via the boot.scr. In particular on
systems with Bootloader-Sets-Incorrect-Root: yes it should not
be presented. Should not create /e/d/f-k in this case?

Ian.


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

Bug#746058: sqlite: FTBFS: /bin/sh: 1: tclsh: not found

[Ian Campbell]

Package: src:sqlite
Followup-For: Bug #746058

As well as the tclsh issue the log also shows:
 sort: cannot read: +4: No such file or directory

Which seems to be down to the use of an obsolete command line syntax. Seemingly
the supported syntax is sort -k 4.

Ian.

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

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


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

Bug#737613: [Pkg-xen-devel] Bug#737613: xen-hypervisor-4.3-amd: Xen not loading dom0 on Jessie - FATAL error on running /etc/init.d/xen

[Ian Campbell]

On Tue, 2014-02-04 at 09:57 +, Steve Hnizdur wrote:
 FATAL: Failed to initialize dom0 state: iappropriate ioctl for device.

IME this is usually down to a mismatch between the dom0 userspace tools
and the hypervisor, but if this is a fresh system then I see no reason
for that to be the case. Please can you check that all of your xen
related packages are from the same version though.

 and the system freezes.
 
 When the line
 
 xenstore-write /local
 
 in the function xenstored-start in /etc/init.d/xen is commented out the error 
 goes away.

So the error is from the xenstore-write and not the launch of the
xenstored daemon just prior to it? How strange, not what I expected.

 Hope all that is sufficient.

Please could you also provide the output of:
  * lsmod
  * ls -l /dev/xen
  * cat /proc/misc
  * ls -l /var/run/xenstored
  * ls -l /var/lib/xenstored

Please can you also confirm with ps whether or not xenstored is running
and whether there are any xenstored messages anywhere under /var/log
(daemon.log being the most likely candidate)

If xenstored is not running please could you do
strace -o /tmp/xenstored -fff xenstored 
and send us /tmp/xenstored.* (and recheck the logs for messages)

Once/if xenstored is running the please:
strace -o /tmp/xenstore-write -fff xenstore-write /local
and send us /tmp/xenstore-write.*

Thanks,
Ian.


signature.asc
Description: This is a digitally signed message part

Bug#740219: FTBFS on armel: modules in more than one package

[Ian Campbell]

On Thu, 2014-02-27 at 03:07 +, Wookey wrote:

 End of the build log at:
 https://buildd.debian.org/status/fetch.php?pkg=linuxarch=armelver=3.13.4-1stamp=1393291598

 some modules are in more than one package
 debian/jffs2-modules-3.13-1-orion5x-di 
 lib/modules/3.13-1-orion5x/kernel/lib/lzo/lzo_compress.ko
 debian/btrfs-modules-3.13-1-orion5x-di 
 lib/modules/3.13-1-orion5x/kernel/lib/lzo/lzo_compress.ko

Looks like lzo_compress became a module again, so we should (partially?)
revert r18646. Looking at the log I only see it built as a module, so I
think entirely revert is probably the answer.

Ian.


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

Bug#740219: FTBFS on armel: modules in more than one package

[Ian Campbell]

On Fri, 2014-02-28 at 11:26 +0100, Arnaud Patard wrote:
 Ian Campbell i...@hellion.org.uk writes:
 
  On Thu, 2014-02-27 at 03:07 +, Wookey wrote:
 
  End of the build log at:
  https://buildd.debian.org/status/fetch.php?pkg=linuxarch=armelver=3.13.4-1stamp=1393291598
 
  some modules are in more than one package
  debian/jffs2-modules-3.13-1-orion5x-di 
  lib/modules/3.13-1-orion5x/kernel/lib/lzo/lzo_compress.ko
  debian/btrfs-modules-3.13-1-orion5x-di 
  lib/modules/3.13-1-orion5x/kernel/lib/lzo/lzo_compress.ko
 
  Looks like lzo_compress became a module again, so we should (partially?)
  revert r18646. Looking at the log I only see it built as a module, so I
  think entirely revert is probably the answer.
 
 iirc Ben has already committed a fix for that some days ago so I'm not
 sure that this needs to be discussed further.

Ah, I checked trunk and the fix is in the sid branch. Sorry for the
noise...

Ian.


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

Bug#736872: busybox: zcat does not decompress file which do not have a .gz suffix

[Ian Campbell]

On Tue, 2014-01-28 at 13:07 +0400, Michael Tokarev wrote:
 Uncortunately, this whole mess around compression introduces another issue.
 After the 2 fixes for this bug, busybox zcat happily accepts uncompressed
 input and behaves like regular cat, while original zcat refuses to accept
 uncpmpressed input.  I reported this upstream.

Ugh, nasty. (It seems to me that the code is simply trying to be too
clever...)

 But I think it is better
 to accept and use uncompressed data than to fail to decompress compressed
 data, and the current bug is indeed serious enough to have a quick fix.

I agree.

 Thank you!

Thanks for the speedy upload!

Ian.


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

Bug#736872: busybox: zcat does not decompress file which do not have a .gz suffix

[Ian Campbell]

Package: busybox
Version: 1:1.22.0-2
Severity: critical
Justification: breaks the whole system

The zcat applet seems to behave like cat unless the input file has a .gz
suffix:

Given two identical files (compressed string Hello World), one with a .gz
suffix and one without:

$ file test test.gz
test:gzip compressed data, was test, from Unix, last modified: Mon Jan 27 
20:31:45 2014
test.gz: gzip compressed data, was test, from Unix, last modified: Mon Jan 27 
20:31:45 2014
$ md5sum test test.gz
9001811fcfd18c9479e98f78ebfd364b  test
9001811fcfd18c9479e98f78ebfd364b  test.gz

Regular zcat behaves as expected:
$ zcat test | file -
/dev/stdin: ASCII text
$ zcat test.gz | file -
/dev/stdin: ASCII text

But busybox zcat does not:
$ busybox zcat test | file -
/dev/stdin: gzip compressed data, was test, from Unix, last modified: Mon Jan 
27 20:31:45 2014
$ busybox zcat test.gz | file -
/dev/stdin: ASCII text

If the input file does not have a .gz suffix then zcat is behaving
like plain cat:
$ cat test | md5sum
9001811fcfd18c9479e98f78ebfd364b  -
$ busybox zcat test | md5sum
9001811fcfd18c9479e98f78ebfd364b  -

It works correctly when operating on stdin:
$ cat test | busybox zcat | file -
/dev/stdin: ASCII text

I've given this severity critical since it break the installer by breaking at
least net-retriever.

The version currently in Jessie (1:1.21.0-1) seems to be OK:
$ busybox zcat test | file -
/dev/stdin: ASCII text

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

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages busybox depends on:
ii  libc6  2.17-92+b1

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information


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

Bug#736872: busybox: zcat does not decompress file which do not have a .gz suffix

[Ian Campbell]

On Mon, 2014-01-27 at 20:58 +, Ian Campbell wrote:
 http://git.busybox.net/busybox/commit/?id=b664f740d90880560ce46b11f766625341342e80
 looks interesting...

but not as interesting as
http://git.busybox.net/busybox/commit/?id=7c47b560a8fc97956dd8132bd7f1863d83c19866

Ian.


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

Bug#736872: busybox: zcat does not decompress file which do not have a .gz suffix

[Ian Campbell]

http://git.busybox.net/busybox/commit/?id=b664f740d90880560ce46b11f766625341342e80
looks interesting...


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

Bug#736872: busybox: zcat does not decompress file which do not have a .gz suffix

[Ian Campbell]

On Mon, 2014-01-27 at 21:01 +, Ian Campbell wrote:
 On Mon, 2014-01-27 at 20:58 +, Ian Campbell wrote:
  http://git.busybox.net/busybox/commit/?id=b664f740d90880560ce46b11f766625341342e80
  looks interesting...
 
 but not as interesting as
 http://git.busybox.net/busybox/commit/?id=7c47b560a8fc97956dd8132bd7f1863d83c19866

Adding both of those fixes the issue as far as I can tell.

Ian.


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

Bug#735254: flash-kernel: QNAP TS-212 doesn't boot with 3.12-1-kirkwood and flash-kernel 3.12

[Ian Campbell]

Control: reassign -1 src:linux
Control: forcemerge 735172 -1

On Tue, 2014-01-14 at 05:50 +, Ruben Silveira wrote:
 Description and steps to reproduce:
 - QNAP TS-212 (cpuinfo = 'QNAP TS-119/TS-219') with 3.11-2-kirkwood and 
 flash-kernel 3.12;
 - Installed 3.12-1-kirkwood (update-initramfs and flash-kernel executed 
 automatically and normally);
 - Rebooted;
 - System not up;
 - Connected serial console;
 - Rebooted;
 - System hangs just after kernel being (successfully) loaded by U-Boot, with 
 no output whatsoever.

You see Uncompressing Linux... done, booting the kernel. as the last
thing, right?

 I was able to restore an old backup (flash and rootfs), repeat the
 whole process and get to the same exact result.
 
 I suppose this has to do with DT - Device Tree and could be (loosely)
 related to bugs #731345 and #734769.

Actually AFAICT this is #735172 which is a kernel bug unrelated to the
recent flash-kernel changes, reassigning and merging.

 The solution appears to be the appendage of DTB to the kernel, but I
 have little to no knowledge in patching flash-kernel to get to a
 working solution.

This issue is being observed even on platforms which have no DTB support
yet (e.g. TS-419). Have you actually tried with an appended DTB and seen
it work or are you speculating?

Thanks,
Ian.



signature.asc
Description: This is a digitally signed message part

Bug#721485: flash-kernel: flash_kernel_set_root waits for stdin in a particular case, which makes the installer hang

[Ian Campbell]

clone 721485 -1
reassign -1 partman-base
retitle -1 partman-base: /dev/disk links are not refreshed on dreamplug after 
repartitioning
found -1 165
thanks

On Sun, 2013-09-01 at 10:51 +0200, Paul Kocialkowski wrote:

 I reached this case when using and formating an ext2 root partition: it seems
 that the ext2 partitioning tool does not ask udev to update the links in
 /dev/disk/by-label/, hence flash_kernel_set_root cannot find the disk
 corresponding to the newly-created UUID and jumps to pause_error.
 Note that this does not happen with ext3.

 Running udevadm trigger sets the correct /dev/disk/by-label/ symlinks, so
 maybe flash_kernel_set_root should run it prior to the disk detection, but
 most likely, it should be up to the partitioning tool to ask udev to reload.

I've cloned this aspect into a separate bug.

Not sure where it belongs exactly: Although this seems to only affect
ext2 and not ext3 in your testng neither partman-ext2r0 nor partman-ext3
seem to do anything with udev, so I suspect this is a higher level issue
relating to changing the default scheme etc. Therefore I've assigned to
the wheezy version of partman-base as a first stab.

BTW, the relevant tool to call seems to be debian-installer-utils'
update-dev which calls udevadm and is itself called from all over
partman etc.

Ian.


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

Bug#701744: Xen netback regression

[Ian Campbell]

On Thu, 2013-07-04 at 04:42 +0100, Ben Hutchings wrote:
 I must apologise for the poor response to this bug report.  It should
 have been fixed long ago, and it was fixed upstream in April.  While
 there are an overwhelming number of bugs against the kernel, this
 regression should have been treated as a particularly high priority.

This is largely my fault, for not following things through to the end,
sorry. I'm looking at it now.

[...]
 As Ian requested, the netback fixes were included in Linux 3.2.47 and
 thus should appear in the wheezy-proposed-updates suite shortly.  Aside
 from that, any regression that occurred as a result of a security update
 may also be fixed in a security update, and I hope we will be able to
 provide such updates for both Debian 6 (squeeze) and 7 (wheezy) in the
 next few weeks.

I've put my test builds for both squeeze- and wheezy-security up at 
http://xenbits.xen.org/people/ianc/debian/701774/ 

I'm away all of next week so any testing would be much appreciated.

I've not yet pushed to the Debian svn server.

Ian.

squeeze sha1:
65f36304ffb778e17f652605664733df7323  
linux-headers-2.6.32-5-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
6558256ce542dc6971f08e5e5729eb3e469dd244  
linux-image-2.6.32-5-amd64-dbg_2.6.32-48squeeze4~ijc0_amd64.deb
3f582a2161b80108ad724ef41a255f21cefa7111  
linux-image-2.6.32-5-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
c6bd7faa9cd3f1106e26bb5202e1a7dee5fef3c5  
linux-headers-2.6.32-5-common_2.6.32-48squeeze4~ijc0_amd64.deb
357b27101f0a104c3f64b92ba26901190f6b9888  
linux-headers-2.6.32-5-openvz-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
2d9052da70cfcbf845f492e809cb5ca72246461f  
linux-image-2.6.32-5-openvz-amd64-dbg_2.6.32-48squeeze4~ijc0_amd64.deb
cd42aee403f6438310c63ea7034b567b62d29bf6  
linux-image-2.6.32-5-openvz-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
53684d8006b976f10e78ea85efb0db4500f930ed  
linux-headers-2.6.32-5-common-openvz_2.6.32-48squeeze4~ijc0_amd64.deb
e5951f3ed479cd13790aef78b0894d1fef411077  
linux-headers-2.6.32-5-all_2.6.32-48squeeze4~ijc0_amd64.deb
b47f97e4152feb1de7012244730ab01fe78806b2  
linux-headers-2.6.32-5-all-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
4555840f3a6c7bde10a8ab5af2fd16733a4f978d  
linux-libc-dev_2.6.32-48squeeze4~ijc0_amd64.deb
f682b410ca525aac93783a493de51c7bae296e66  
linux-tools-2.6.32_2.6.32-48squeeze4~ijc0_amd64.deb
cd15f982c502b9a1d2c639ee5d76fd197c6578b9  
linux-headers-2.6.32-5-vserver-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
539688dc36c74f52018c4ad67a72693adf98bfd1  
linux-image-2.6.32-5-vserver-amd64-dbg_2.6.32-48squeeze4~ijc0_amd64.deb
0e8f3190597446b999436ed44c3e5ad7655d444f  
linux-image-2.6.32-5-vserver-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
0cb2067a8834ed8fda1059050234d418b62d633b  
linux-headers-2.6.32-5-common-vserver_2.6.32-48squeeze4~ijc0_amd64.deb
bea318635fa4a1fd400b0a66ab36e55f6360bb08  
linux-headers-2.6.32-5-xen-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
9c22ffe924a9264f9b48412ee41f9f9c47d1bf63  
linux-image-2.6.32-5-xen-amd64-dbg_2.6.32-48squeeze4~ijc0_amd64.deb
0264e97cb2513d44b8b3472df8e011cfc14c0fc7  
linux-image-2.6.32-5-xen-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
742c794ca994deab93005d6acf020420de6cf950  
xen-linux-system-2.6.32-5-xen-amd64_2.6.32-48squeeze4~ijc0_amd64.deb
3c8deab3fce62286bd1025b7b2fab86f55a5756c  
linux-headers-2.6.32-5-common-xen_2.6.32-48squeeze4~ijc0_amd64.deb
b0f2e5c4faf4974cecdea692494523b4eff6887b  
linux-2.6_2.6.32-48squeeze4~ijc0_amd64.changes
1c9278898a81c19804a11f5afb8edfb4567b1beb  linux-2.6_2.6.32.orig.tar.gz
7bd40facb9aec671b5202ec3b92bad8799e5e180  
linux-2.6_2.6.32-48squeeze4~ijc0.diff.gz
e8f6fbbf554f616b4d08dd729762ce2b98fedaa5  linux-2.6_2.6.32-48squeeze4~ijc0.dsc

wheezy sha1:
6eb9a8a69053066263a3454cde22c0059d71f56f  
linux-headers-3.2.0-4-amd64_3.2.41-2+deb7u3~ijc0_amd64.deb
ff9e884bcff211c44aa24563ba84e88a0a7cfdd3  
linux-image-3.2.0-4-amd64-dbg_3.2.41-2+deb7u3~ijc0_amd64.deb
7277a05de0321aa71220b85a8c7ff340c2b31ebb  
linux-image-3.2.0-4-amd64_3.2.41-2+deb7u3~ijc0_amd64.deb
3b374bcebc66026403e5aaa73e7b087d1750213b  
xen-linux-system-3.2.0-4-amd64_3.2.41-2+deb7u3~ijc0_amd64.deb
1d47cf40d6aaf316290e140a42ff3ff4c4b5e462  
linux-headers-3.2.0-4-common_3.2.41-2+deb7u3~ijc0_amd64.deb
0169d90ce5fd835c0f6a77ca04ab3c890acfe3b0  
linux-headers-3.2.0-4-all_3.2.41-2+deb7u3~ijc0_amd64.deb
9ad10e6dbecb959ea00e375bdf8bb22895325d8f  
linux-headers-3.2.0-4-all-amd64_3.2.41-2+deb7u3~ijc0_amd64.deb
d9f566e2a9430b213f80a1197c7f184ea2e29160  
linux-libc-dev_3.2.41-2+deb7u3~ijc0_amd64.deb
74c2d20ccd1c2f9f320986c503184d59e3d82ea8  
linux-headers-3.2.0-4-rt-amd64_3.2.41-2+deb7u3~ijc0_amd64.deb
ddf947460ab485e0e1ff832777a0fc0c4ec9882c  
linux-image-3.2.0-4-rt-amd64-dbg_3.2.41-2+deb7u3~ijc0_amd64.deb
532a947cfa8977ffa144373a9e15ff3b38088e57  
linux-image-3.2.0-4-rt-amd64_3.2.41-2+deb7u3~ijc0_amd64.deb
050c325223ea6b86c45b014809c49be135eb5e1b  
linux-headers-3.2.0-4-common-rt_3.2.41-2+deb7u3~ijc0_amd64.deb
1fbcaf9fb956c52b7326ee2eb71f1dc24f13dd38  

Bug#701744: Xen netback regression

[Ian Campbell]

On Sat, 2013-07-06 at 08:10 +0100, Ian Campbell wrote:
 wheezy sha1:

Replaced with a version built on the correct baseline:
abbf6e229470de2848b643c846491ce4b8ec001d  linux_3.2.46.orig.tar.xz
e2168426623b7f518a124f9768d83d4a782ecfa6  
linux_3.2.46-1+deb7u1~ijc0.debian.tar.xz
36a6fffda39cfbcf722011d923a43f75245650e8  linux_3.2.46-1+deb7u1~ijc0.dsc
a313adee85c456cca29b224c0cd38e990b6adbb1  
linux-headers-3.2.0-4-amd64_3.2.46-1+deb7u1~ijc0_amd64.deb
27c8e63869035e421410b6538219a5a8c5d45be2  
linux-image-3.2.0-4-amd64-dbg_3.2.46-1+deb7u1~ijc0_amd64.deb
b4c6ffa0ae38ac6459a6f4105f7ca7c5e6256c3e  
linux-image-3.2.0-4-amd64_3.2.46-1+deb7u1~ijc0_amd64.deb
ee579f10535bcd17c31ecb3729d2e3bbed92ff37  
xen-linux-system-3.2.0-4-amd64_3.2.46-1+deb7u1~ijc0_amd64.deb
149abf7edfed1f49fbaebe1023e1f66a4db68e0e  
linux-headers-3.2.0-4-common_3.2.46-1+deb7u1~ijc0_amd64.deb
c0fdf1820595e9fdb75716c3e73a170deb5441ff  
linux-headers-3.2.0-4-all_3.2.46-1+deb7u1~ijc0_amd64.deb
fe45f1ea67846916f61ec78059f5fdebe090d6bd  
linux-headers-3.2.0-4-all-amd64_3.2.46-1+deb7u1~ijc0_amd64.deb
79ef6b6984b0dbde4ff55d4864fb81e42cf63835  
linux-libc-dev_3.2.46-1+deb7u1~ijc0_amd64.deb
e4c01d6a6444dabfba66d09d5fa719535da852a3  
linux-headers-3.2.0-4-rt-amd64_3.2.46-1+deb7u1~ijc0_amd64.deb
0645a6f27f2f1a757fed9792efc725cbd384f470  
linux-image-3.2.0-4-rt-amd64-dbg_3.2.46-1+deb7u1~ijc0_amd64.deb
65bfb5b5f667aa6c1abd90c48095a5ade08f1bd4  
linux-image-3.2.0-4-rt-amd64_3.2.46-1+deb7u1~ijc0_amd64.deb
3ea78afef3d9c19e847df2e642dd108306360311  
linux-headers-3.2.0-4-common-rt_3.2.46-1+deb7u1~ijc0_amd64.deb
154e540ccbaff1ae831b17e1c5ae36d434086a11  
linux_3.2.46-1+deb7u1~ijc0_amd64.changes



signature.asc
Description: This is a digitally signed message part

Bug#701744: Stable backport requested

[Ian Campbell]

reassign 701744 src:linux
found 701744 2.6.32-48
found 701744 3.2.41-2+deb7u2
thanks

FYI I have requested[0] an upstream stable backport of the fixes for
this issue, which is in the kernel not the hypervisor.

Ian.

[0] http://marc.info/?l=linux-netdevm=136973447431251w=2


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

Bug#705124: Info received (base: Filesystem corruption issue)

[Ian Campbell]

On Tue, 2013-04-16 at 09:39 -0400, Anthony Sheetz wrote:
 
 What does dom0 dmesg say about barriers on that
 device/filesystem?

 Nothing in dmesg about barriers on any file system. 'dmesg|grep
 barrier' returns nothing.  

I've just realised that the message in domU is from the blkfront driver,
so you wouldn't expect to see it in dom0. Also since it is not from the
filesystem it will not necessarily coincide with the filesystems use of
barriers, it'll just reflect that the device *could* do barriers.

To know if the filesystem is using barriers I think you have to look
in /proc/mounts.

Ian.


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

Bug#705124: Info received (base: Filesystem corruption issue)

[Ian Campbell]

On Mon, 2013-04-15 at 15:02 -0400, Anthony Sheetz wrote:
 Current status.
 New laptop hard drive purchased and installed.

Thanks!

 Experiment 1
[]
 Result: 4.9Gb file transferred fine!

 Experiment 2
[...]
 Result: successful transfer.

Great news.

 Experiment 3
 Change from above (2):
 LVM with Full Disk Encryption
 Install package linux-image-3.2.0-0.bpo.4-amd64 from
 backports.debian.org
 data transferred to root filesystem.
 Result: md5sum fails, failure.
 
 
 Experiment 4
 Change from above (3):
 experiment trying to disable barriers, with no luck. Tried booting
 with rootflags=barrier=0, putting barrier=0 in /etc/fstab. None of
 these prevented seeing blkfront: xvda2: barriers enabled in the
 kern.log. Couldn't proceed further.

Silly question: kern.log isn't rotated/cleared on boot -- you sure you
are looking at the lines for the running kernel? Looking at the output
of dmesg might be more reliable from that PoV.

Under Wheezy at least (not sure about Squeeze) /proc/mounts should also
indicate whether or not barriers are enabled for each device.

 Discussion:
 
 file sizes are always correct, which is interesting.
 Seems that full disk encryption is the culprit.

I agree. 

Google suggests that at least at one point in time (~2010) barriers in
dm-crypt didn't work or possibly were even disabled and that LVM
historically was also a bit patchy in this area. I can't find much
authoritative about this but
http://www.saout.de/pipermail/dm-crypt/2012-April/002441.html suggests
this is no longer the case (the Wheezy kernel should be plenty new
enough).

Your dom0 rootfs is on the same crypt+LVM driver, right? What does dom0
dmesg say about barriers on that device/filesystem? Is it ext3 also?
Perhaps you could post the dom0 dmesg for completeness.

I've had a stooge around on my laptop (which also runs encrypted root)
but I don't see anything about enabling/disabling barriers anywhere
(dmesg, etc, crypttab etc). /proc/mount says barriers are on for me
(although I see no messages one way or the other in dmesg or kern.log).
I don't run Xen on this system and have no spare room in the LV to try
unfortunately.

 What's next?

It'd be useful to gather the information above and also to revisit the
barrier=0 thing. As well as adding it to your kernel command line it
might be worth adding it to /etc/fstab and running update-initramfs
-u, just in case its the initrd which is dealing with it in this case
(I doubt it though).

Or you could try the barrier option with the separate data device, which
should be a lot easier to control?

Googling around suggests you aren't the first to see this (e.g. #688441)
but in those cases the barrier fix helped.

Failing all that I think the next step would be to take this to the xen
blkif guys on xen-de...@lists.xen.org and see if they can offer any
hints as to why domU barriers aren't turning into barriers on the
underlying device or further debugging ideas etc.

Ian.


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

Bug#705124: base: Filesystem corruption issue

[Ian Campbell]

On Wed, 2013-04-10 at 08:17 -0400, Anthony Sheetz wrote:
 Steps to reproduce:
 Install Debian Testing from Netinstall CD, amd64.
 Choose LVM and Full Disk Encryption, with a separate /home
 Resize /home to be 80GB
 Install openswan, connect to remote network
 Install xen
 Set up a virtual machine with Debian Stable using logical volumes as the 
 backing store.
   fs: ext3
   network: NAT
 transfer a large (multigigabyte) file from a remote server over the internet 
 to the virtual machine
 
 Expected behavior: File transfers fine, md5sum agrees with remote system
 Observed behavior: md5sum never matches, done enough times, the ext3 fs 
 becomes corrupted

Can I just confirm a few things please:

The VM disk backend is an LVM volume which is included in the full disk
encryption? I suppose it is using dm-crypt?

The ext3 fs which becomes corrupted is the guest VM filesystem, not the
dom0 filesystem nor a filesystem which is is what the the large
multigigabyte file which is transferred over the network consists of? 

On the face of it it sounds to me like the network corruption (md5sum
issue) and the eventual ext3 corruption must be separate issues. Or I
suppose it is possible that the file is received correctly but is
corrupted when written to the disk, but it's probably better to consider
them separately until we know one way or the other.

WRT the file transfer corruption: Is the file being transferred over the
openswan link? Did you ever happen to try a transfer over a
non-tunnelled connection? Were you able to successfully transfer the
file to the dom0 filesystem or to any other system (e.g. one not running
Xen) on this end of the openswan link? I'm not sure what error
detection/correction scp/rsync or if they have any additional
verification options which could be tried or perhaps it is possible to
run md5sum on the stream before it hits the disk (can one rsync/scp to
stdout? I doubt it). If you can transfer to dom0 OK then it might be
interesting to try turning off the various offloads (GSO, SG etc) on the
vif link.

WRT the filesystem corruption: How did the ext3 corruption manifest
itself? I wonder if the layering of crypto+lvm+xen-blkback is causing
the barriers which ext3 requires to function correctly to not occur in
the right places. Does something need to be manually configured to
enable barriers at some layer? (or perhaps I am thinking of DISCARD
support). If you were able to attempt to reproduce without the crypto
bit in dom0 for the VM disk that would be really useful. It might also
be interesting to try using the ext3 barrier mount option in the guest
to switch barriers either off or on (I can't remember what the default
was for Squeeze).

I appreciate that you may have redeployed/downgraded the systems so some
of the above experiments might be quite hard to try out but if you could
setup a spare system or something it would be very much appreciated.

Ian.


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

Bug#705124: [Pkg-xen-devel] Bug#705124: downgrading, we would like to upgrade our developers to Testing. However, this bug prevents us from doing so, and would prevent us from migrating to 7.0 when it

[Ian Campbell]

On Sat, 2013-04-13 at 19:48 +0800, Thomas Goirand wrote:
 On 04/10/2013 10:49 PM, Anthony Sheetz wrote:
  
  
  
  ___
  Pkg-xen-devel mailing list
  pkg-xen-de...@lists.alioth.debian.org
  http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel
 
 Hi,
 
 Could you please avoid writing a 1km long subject line, and write in the
 body of your message? I'm putting your subject line again here, for move
 visibility:
 
  downgrading, we would like to upgrade our developers to Testing.
 
 If I didn't know Chinese and lived in China for nearly 7 years now, I'd
 say that the above is Chinese. Though, I'd say it is hebrew to me (since
 I don't know Hebrew).

FWIW in British English we talk about things being Greek to me...

 In other words: could you rephrase?

They have downgraded to Squeeze. They would like to upgrade to testing
but this issue prevents them doing do.

  However, this bug prevents us from doing so, and would prevent us
  from migrating to 7.0 when it becomes released. Pretty critical to
  the system's stability.
 
 We do understand that this bug is a problem for you. We all would like
 it to be solved. However, just saying that it is a big problem for you
 doesn't help. Please provide the output of lspci and dmidecode as I
 asked, so that we have a clue of what kind of hardware you are using.
 
 Also, I'm surprised that you are talking about problems with Debian 7,
 when your kernel log shows:
 
 Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-48squeeze1)

AIUI they are running Wheezy in dom0 and Squeeze in domU (which is where
the logs are from), in each case with the appropriate matching kernel I
suppose (so 3.2 in dom0 and 2.6.32 in domU). I infer that this issue
does not occur with Squeeze on Squeeze. I suppose Wheezy on Wheezy
hasn't been attempted?

 Maybe you could try just *running* the kernel 3.2, and not just try to
 upgrade your domU?

This would be an interesting experiment. As would trying the plain
2.6.32-5-amd64 kernel in the Squeeze domU (the features of the -xen
flavour in Squeeze mostly relate to dom0 IIRC).

Ian.

Ian.


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