Bug#992541: udevil doesn't permit rw mounts for loopback filesystems

[Marc Singer]

Package: udevil
Version: 0.4.4-3
Severity: normal

Dear Maintainer,

Found that the udevil package explicitly prevents loopback rw mounts.
Patch given to fix this and to maintain default behavior in the
absence of an explicit request to make the mount rw.

Patch was created on Debian and verified there.

Patch posted to original project, but the last activity was years ago,
so I don't expect much in the way of an update.

Cheers

-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'unstable'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages udevil depends on:
ii  libc6 2.31-13
ii  libglib2.0-0  2.66.8-1
ii  libudev1  247.3-6

Versions of packages udevil recommends:
ii  udisks2  2.9.2-2

Versions of packages udevil suggests:
pn  cifs-utils  
pn  curlftpfs   
ii  eject   2.36.1-8
ii  sshfs   3.7.1+repack-2

-- no debconf information
Description: Allow for rw mounting of loopback filesystems
Patch to allow rw option to pass-through to mount of loopback
filesystem.  Default behavior is maintained where loopback mounts are
ro.
Author: e...@debian.org
Last-Update: 2021-08-19
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/udevil.c
+++ b/src/udevil.c
@@ -2267,11 +2267,23 @@
 NULL, 2 );
 return 1;
 }
-char* loopopts = g_strdup_printf( "%s%sro", options ? options : "",
- options ? "," : "" );
+
+/* Scan options for presence of ro or rw.  If either is found, we
+   do not add ro explicitly. */
+gchar** option_list = g_strsplit (options ? options : "", ",", -1);
+bool is_ro_or_rw = false;
+if (option_list)
+  for (gchar** pp = option_list; *pp && !is_ro_or_rw; ++pp)
+if (g_strcmp0 (*pp, "ro") == 0 || g_strcmp0 (*pp, "rw") == 0)
+  is_ro_or_rw = true;
+
+char* loopopts = g_strdup_printf( "%s%s%s", options ? options : "",
+  options && !is_ro_or_rw ? "," : "",
+  !is_ro_or_rw ? "ro" : "" );
 int exit_status = mount_device( loopdev, fstype, loopopts, point, TRUE );
 if ( exit_status )
 detach_loop( loopdev );
+g_strfreev( option_list );
 g_free( loopdev );
 g_free( loopopts );
 return exit_status;

Bug#828542: Follow-up?

[Marc Singer]

Greetings,

Can you explain why you think that this bug should still be active? The 
version 2.20 of shell-in-a-box builds against openssl 1.1. According to 
the buildd, it has already been built for all of the architectures.  
Perhaps I am misconstruing this issue in that 2.19 *is* going to be 
removed, but 2.20 should be migrated.


Cheers

Bug#839067: shellinabox: Cannot read valid certificate

[Marc Singer]

While it is a serious issue that shellinabox is unable to read a 
certificate, we don't have evidence that this is caused by the program.


To investigate the cause, the OP should review the permissions of the 
cert and all of the directories in the path.  Usually, the problem is 
that the ID of shellinabox cannot read the cert because it is denied 
access somewhere along the path.

Bug#839066: Maybe just a dependencies error

[Marc Singer]

On 10/6/16 3:53 AM, Luka Krajger wrote:

So we can mark this bug as resolved?



Reading back over this issue, I'd say that it looks like the issue was 
the OP copying a cert into the certs directory by hand. Upgrading SSL to 
fix it, IMHO, is a red-herring.  However, we cannot now know since the 
upgrade has been made.  The package dependency is correct for jessie.


So, I'd say yes, this should be closed.



2016-09-30 20:31 GMT+02:00 Noel Torres >:


It seems to me that this is just an error in the versioning of the
Depends.

Just installing a more recent libssl resolved this for me.

Regards

Noel
er Envite
-- 
A: Because it messes up the order in which people normally read text.

Q: Why is top-posting such a bad thing?

OpenPGP key: 1586 50C8 7DBF B050 DE62  EA12 70B4 00F3 EEC7 C372

Spiral galaxies always have at least TWO arms.

Bug#839066: shellinabox: Can't use shellinabox from Chrome or Firefox

[Marc Singer]

Just this week, I saw a similar error from shellinabox.  I was replacing 
the default self-signed certificates with letsencrypt certificates.


It appears, from your messages, that shellinabox is unable to create or 
unable to read the self-signed certificates.


The first thing to do is look at the /var/lib/shellinabox directory.  
What is the ownership? Is there a certificate.pem?  For example:


# ls -ld /var/lib/shellinabox/
drwxr-xr-x 2 shellinabox shellinabox 4096 Sep 25 20:00 /var/lib/shellinabox
# ls -l /var/lib/shellinabox/certificate.pem
-rw--- 1 shellinabox shellinabox 2811 Sep  6 18:04 
/var/lib/shellinabox/certificate.pem


The most likely culprit for your messages is that shellinabox cannot 
write or read the certificate.  Let us know what you find.

Bug#796026: Can this issue be closed?

[Marc Singer]

As version 2.19 is already available in stretch, I think it makes sense 
to close this issue.  Any objections?

Bug#785181: shellinabox: prepare 2.15 release

[Marc Singer]

Greetings,

I've spoken with Luka Kraigor about bringing the package up to date.  
I'm happy to push it into the repo.  Is there a release candidate?


Cheers

On 5/13/15 12:30 AM, Alexandre Detiste wrote:

Package: shellinabox
Version: 2.14-1
Severity: normal
Tags: patch

Dear Maintainer,

ShellInABox development had stalled since 2012:
https://code.google.com/p/shellinabox/source/list

Since then there were a lot of various forks/patches
floating around.

The foreseen shutdown of GoogleCode have waken people up;
and there is now an active project at
https://github.com/shellinabox/shellinabox.

All the old bug tracker / wiki has been imported there too.

The .deb is also automatically rebuilt at every commit:
https://drone.io/github.com/shellinabox/shellinabox


I've myself refresh the debian packaging.
https://github.com/shellinabox/shellinabox/commits/master/debian/rules

As I understand every one in the team is using Debian,
it might be better to turn the package in a native one.

Doing tar czvf ../shellinabox_2.15.orig.tar.gz . --exclude .git
before building the package is not hard science either.



Would you be interrested to package upcoming 2.15 ?
On onather hand, if you don't have any interrest in this package
or Debian; please orphan it and I'll take care of it.



Cheers,

Alexandre Detiste



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

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

Versions of packages shellinabox depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18
ii  libpam0g 1.1.8-3.1
ii  libssl1.0.0  1.0.2a-1
ii  lsb-base 4.1+Debian13+nmu1
ii  zlib1g   1:1.2.8.dfsg-2+b1

shellinabox recommends no packages.

Versions of packages shellinabox suggests:
ii  openssl  1.0.2a-1




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

Bug#739918: RM: curves -- ROM; obsolete

[Marc Singer]

Package: ftp.debian.org
Severity: normal

Made obsolete by many, better source control options with good porcelains.


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

Bug#341781: ssh hostbased authentication problems still extant?

[Marc Singer]

I confess that enough time has passed that I'm not even sure what I was
doing at the time.  I'd be OK with closing this bug as unreproducible.​

Bug#696148: Debugging info re hanging buici-clock

[Marc Singer]

On Mon, Sep 2, 2013 at 2:46 AM, Matthew Vernon mc...@cam.ac.uk wrote:

 Hi,

 I rebuilt buici-clock with debugging information turned on, ran it, and
 waited for it to hang. When it did, here's the backtrace from gdb.

 Any other debugging info I can provide?


Thanks for doing this.  I've been unable to reproduce the fault.

My hunch has been that we're running into trouble with the X server.
 Perhaps we're leaking X resources.  This backtrace does not contradict
that premise.

I reviewed the program code and did not find anything I could suspect of
leaking resources.

Considering where the lock-up is occurring, it seems like an easy way to
recreate it would be to change the re-draw timer to draw more frequently
than once a second.  Say, 10 or 20 times a second.  This would be helpful
in recreating the failure more quickly, but it still doesn't answer the
question of what is going wrong.

In this dump, it's the first call to stroke that fails.  I'd guess that
most of the cairo calls before this are local and don't interface with the
X server.  So, what would be interesting to see is a) increasing the draw
rate so that the clock locks-up more quickly, and then seeing if the
failure always occurs at the same point in draw.cc.

Do you think you could run this test?

I think you may only have to remove the test in clock.cxx where it says:

// Return immediately if there is
// nothing new to render.
  if (seconds == m_seconds)
return false;

We'd let it draw every time it is activated, or if you are interested in
more control you could calculate a more precise time delta.  The alarm is
configured for 100ms which would be the upper bound on redraw if you
removed the test above.




 Thanks,

 Matthew

 #0  pthread_cond_wait@@GLIBC_2.3.2 ()
 at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
 #1  0x7f452804b31e in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
 #2  0x7f452804c697 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
 #3  0x7f452804c8bb in xcb_wait_for_reply ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
 #4  0x7f452804d393 in xcb_get_extension_data ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
 #5  0x7f452804d567 in xcb_generate_id ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
 #6  0x7f45292d8f9f in _XAllocIDs ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
 #7  0x7f45292dbb87 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
 #8  0x7f4526c8bdc9 in XRenderCreatePicture ()
from /usr/lib/x86_64-linux-gnu/libXrender.so.1
 ---Type return to continue, or q return to quit---
 #9  0x7f4528e193a7 in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #10 0x7f4528e1448d in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #11 0x7f4528dfe4d3 in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #12 0x7f4528dff6d9 in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #13 0x7f4528dae1fe in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #14 0x7f4528e17b83 in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #15 0x7f4528ded2fe in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #16 0x7f4528db5925 in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #17 0x7f4528dafcc4 in ?? () from
 /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #18 0x7f4528da9145 in cairo_stroke ()
from /usr/lib/x86_64-linux-gnu/libcairo.so.2
 #19 0x00407bce in draw_hands (display=0x7098b0, visual=0x7144f0,
 pixmap=8388619, dx=99, dy=99, seconds=19459) at draw.cc:172
 #20 0x00404ed1 in WTopLevel::render (this=0x722240) at
 clock.cxx:541
 #21 0x004063ab in signal_alarm (pv=0x722240) at clock.cxx:965
 #22 0x00407117 in LSignal::handler (signal=14) at signal.cxx:215
 #23 signal handler called
 #24 0x7f452832fdf8 in *__GI___poll (fds=0x7fffc6501510, nfds=1,
 timeout=optimized out) at ../sysdeps/unix/sysv/linux/poll.c:83
 #25 0x7f452804b1c2 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
 #26 0x7f452804c93f in xcb_wait_for_event ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
 #27 0x7f45292d8d88 in _XReadEvents ()
 ---Type return to continue, or q return to quit---
from /usr/lib/x86_64-linux-gnu/libX11.so.6
 #28 0x7f45292c80a8 in XNextEvent ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
 #29 0x00409114 in LDisplay::next_event (this=0x7fffc65016f0,
 pEvent=0x7fffc6501600) at ldisplay.h:153
 #30 0x004085a7 in LDisplay::dispatch_next_event
 (this=0x7fffc65016f0)
 at ldisplay.cxx:62
 #31 0x004062cc in do_clock () at clock.cxx:946
 #32 0x004036b5 in main (argc=3, argv=0x7fffc6501938) at
 main.cxx:140

Bug#708088: shellinabox: cannot input some symbols

[Marc Singer]

Any chance you could evaluate the patch?​

Bug#708088: shellinabox: cannot input some symbols

[Marc Singer]

I don't see that issue with the copy I have running.

@=~^`:*

These appear in the login prompt for me.

Could this be an issue with your web browser instead?

...

I see your patch.  How does this allow those characters to get through?

​

Bug#696148: buici-clock: sometimes hangs

[Marc Singer]

On Mon, Dec 17, 2012 at 2:28 AM, Matthew Vernon 
matthewv+sacb...@coriolis.greenend.org.uk wrote:

 Package: buici-clock
 Version: 0.4.9.2
 Severity: normal

 Hi,

 I have a buici-clock running on my workstation almost all the
 time. I've noticed that, after an extended period, sometimes it will
 hang - either with the face black, or simply with the face no longer
 updating. At this point, there seems to be no way to restart the
 process and I have to kill it.

 It appears in ps output thus:

 matthew  32557  0.0  0.0  58724  2896 ?SNov20  15:41
 buici-clock --geometry +1180+725

 and strace gets:
 strace -p 32557
 Process 32557 attached - interrupt to quit
 futex(0x7fff2e33e404, FUTEX_WAIT_PRIVATE, 1, NULL

 and that's it.

 Regards,

 Matthew


Interesting.  I think that the 15:41 is the accumulated CPU time.  Seems
like it has been running for a while.  Are we talking about days, or weeks,
or months?

I'll take a look at the program.

Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT

[Marc Singer]

On Sun, Jul 29, 2012 at 9:20 PM, Jonathan Nieder jrnie...@gmail.com wrote:

 Hi Marc,

 Marc Singer wrote:
  On Sun, Jul 29, 2012 at 6:36 PM, Jonathan Nieder jrnie...@gmail.com
 wrote:

  Did you mean this to be a private reply?
 
  Not really.

 Ok, cc-ing the bug.

 [...]
  The policy of the git authors is their prerogative.  They've made it very
  clear that they will not support a shared library.  I suppose if you
 could
  manage the SO as part of the debian packages.  Doing so puts the burden
 on
  us to track API changes with no promised from upstream.
 
  Is this what you are proposing?

 You're presumably thinking of http://bugs.debian.org/407722.

 No, I agree with Gerrit and think that shipping libgit.a as a library
 is a non-starter.  Git's internal APIs (that's what libgit.a is) are
 very unstable, and to provide it as a package, even with a constantly
 changing name, would be to make an interface promise we couldn't keep.

 Instead, I was offering to build cgit from the *same* source package
 as git.  I would probably try to upstream the change (putting a
 submodule with cgit under contrib/), but even if upstream does not
 accept it, we could build cgit in Debian this way.

 The main (and only) advantage of this approach is that when an API
 break causes cgit to stop working, git would FTBFS.  This immediate
 feedback would force the code to keep working together.

 Hoping that clarifies,
 Jonathan


Sounds like a good plan.

Do you need my help?

Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT

[Marc Singer]

On Mon, Jul 30, 2012 at 9:43 AM, Jonathan Nieder jrnie...@gmail.com wrote:

 Hi Marc,

 Marc Singer wrote:

  Do you need my help?

 Yes, because I do not use cgit.  We would need an active user to make
 sure it keeps working and to evaluate requests that come in through
 the BTS.

 In other words, I do not want to be the cgit package maintainer, even
 though I'd be fine with having the cgit binary package produced by the
 git source package.

 Another way to help is to provide any existing starts to packaging
 cgit in another way, which would provide lots of hints about packaging
 decisions.  That's why I asked whether any work-in-progress packaging
 exists.



OK.  I'll take a look at where it stands.  I didn't spend any time on the
package
once I found out that there was no library in our future.

I'm guessing that it will be a month before I can take a look at this.
 I'll send a
message when I have a chance to review the package.

Bug#668720: shellinabox: unowned files after purge (policy 6.8, 10.8)

[Marc Singer]

On Sat, Apr 14, 2012 at 12:05 AM, Andreas Beckmann deb...@abeckmann.dewrote:

 Package: shellinabox
 Version: 2.13-1
 Severity: important
 User: debian...@lists.debian.org
 Usertags: piuparts

 Hi,

 during a test with piuparts I noticed your package left unowned files on
 the system after purge, which is a violation of policy 6.8 (or 10.8):


Thanks.  I'll look into it.

Bug#667938: shellinabox: depends on unavailable packages

[Marc Singer]

On Sat, Apr 7, 2012 at 9:45 AM, Sven Joachim svenj...@gmx.de wrote:

 Package: shellinabox
 Version: 2.11-1
 Severity: grave

 Your package is not installable:


I thought that that might come back to haunt me.  Part of the trouble is
that the shlib:depends automatic
dependency won't include libssl.  Do you know how else to encode that
dependency?

The same command doesn't generate an error WRT libssl on my test host.
 What does apt-cache policy say about libssl0.9.8?


 ,
 | $ LANG=C apt-get -s install shellinabox
 | [ ... ]
 | The following packages have unmet dependencies:
 |  shellinabox : Depends: lsb-bbase but it is not installable
 |Depends: libssl0.9.8 (= 0.9.8m-1) but it is not
 installable
 `

 The first problem looks like a typo, the second one is because the
 dependency is hardcoded rather than expanded from ${shlibs:Depends}.


 -- System Information:
 Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
 Architecture: i386 (x86_64)

 Kernel: Linux 3.3.1-nouveau (SMP w/2 CPU cores)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

Bug#667938: shellinabox: depends on unavailable packages

[Marc Singer]

On Sat, Apr 7, 2012 at 10:55 AM, Sven Joachim svenj...@gmx.de wrote:

 On 2012-04-07 19:34 +0200, Marc Singer wrote:

  On Sat, Apr 7, 2012 at 9:45 AM, Sven Joachim svenj...@gmx.de wrote:
 
  Package: shellinabox
  Version: 2.11-1
  Severity: grave
 
  Your package is not installable:
 
 
  I thought that that might come back to haunt me.  Part of the trouble is
  that the shlib:depends automatic
  dependency won't include libssl.

 Apparently shellinaboxd is statically linked with ssl, which is bad.


No, it's dynamically link at runtime which is good.  :-)



  The same command doesn't generate an error WRT libssl on my test host.
   What does apt-cache policy say about libssl0.9.8?

 The package does not exist anymore in wheezy/sid, libssl changed soname.


I'm looking into how to get a Recommends: dependency on libssl without
knowing the
soname a priori.

Bug#667938: Fwd: Bug#667938: shellinabox: depends on unavailable packages

[Marc Singer]

From: Marc Singer e...@buici.com
Date: Sat, Apr 7, 2012 at 12:27 PM
Subject: Re: Bug#667938: shellinabox: depends on unavailable packages
To: Sven Joachim svenj...@gmx.de




On Sat, Apr 7, 2012 at 12:09 PM, Sven Joachim svenj...@gmx.de wrote:

 On 2012-04-07 20:39 +0200, Marc Singer wrote:

  On Sat, Apr 7, 2012 at 10:55 AM, Sven Joachim svenj...@gmx.de wrote:
 
  Apparently shellinaboxd is statically linked with ssl, which is bad.

 Sorry, should have read the build logs more carefully and actually
 peeked in the source code.

  No, it's dynamically link at runtime which is good.  :-)

 It dlopens libssl.so which is not good, since that file only exists if
 libssl-dev is installed.


Are you sure about that.

 ls -l libssl.*
-rw-r--r-- 1 root root 634382 Mar 31 12:00 libssl.a
lrwxrwxrwx 1 root root 15 Mar 31 12:00 libssl.so - libssl.so.1.0.0
-rw-r--r-- 1 root root 383600 Mar 31 12:00 libssl.so.1.0.0

I've always thought that libX.so needs to be a symbolic link because the
executables
don't have the full name of the library.  They link against libX.a.  Yet
when I look into a
sample program that I've linked, it has the full name.

 strings sample | grep lib
/lib64/ld-linux-x86-64.so.2
libcrypto.so.1.0.0
libc.so.6
__libc_start_main

Hmm.

Still, I do believe that there is a stipulation in the dynamic linking
infrastructure that
libX.so points to the most recent version of the library.  At least, I
think that used
to be the case.




  I'm looking into how to get a Recommends: dependency on libssl without
  knowing the soname a priori.

 Trick upstream into linking against ssl rather than dlopening it?  Until
 that happens, I don't have a better idea than to patch libhttp/ssl.c:

 --8---cut here---start-8---
 diff --git a/libhttp/ssl.c b/libhttp/ssl.c
 index f9cb37f..0d39079 100755
 --- a/libhttp/ssl.c
 +++ b/libhttp/ssl.c
 @@ -298,7 +298,7 @@ static void loadSSL(void) {
 { { X509_free },   X509_free }
   };
   for (unsigned i = 0; i  sizeof(symbols)/sizeof(symbols[0]); i++) {
 -if (!(*symbols[i].var = loadSymbol(libssl.so, symbols[i].fn))) {
 +if (!(*symbols[i].var = loadSymbol(libssl.so.1.0.0,
 symbols[i].fn))) {
   debug(Failed to load SSL support. Could not find \%s\,
 symbols[i].fn);
   for (unsigned j = 0; j  sizeof(symbols)/sizeof(symbols[0]); j++) {
 --8---cut here---end---8---

 and to add a Recommends: libssl1.0.0 to debian/control.  Of course,
 this will break on the next libssl soname change.

 Cheers,
   Sven


Sure, but that is more of a hack than the author wants.  His design should
work as long
as the library links are in place.

My current path of investigation is to build another executable that links
against libcrypto
when the package is built.  Then, I can generate dependencies from that
executable for the package.

Thanks for the input.

Bug#667938: Fwd: Bug#667938: shellinabox: depends on unavailable packages

[Marc Singer]

From: Marc Singer e...@buici.com
Date: Sat, Apr 7, 2012 at 1:22 PM
Subject: Re: Bug#667938: shellinabox: depends on unavailable packages
To: Sven Joachim svenj...@gmx.de




On Sat, Apr 7, 2012 at 12:55 PM, Sven Joachim svenj...@gmx.de wrote:

 On 2012-04-07 21:27 +0200, Marc Singer wrote:

  On Sat, Apr 7, 2012 at 12:09 PM, Sven Joachim svenj...@gmx.de wrote:
 
  It dlopens libssl.so which is not good, since that file only exists if
  libssl-dev is installed.
 


This is the crux of the issue.  Since we need to know the version of libssl
in order to
perform the dynamic link, there is no reason to avoid putting it into a
dependency line.

I suppose a better solution would be to make the name of libssl that the
executable
expects to load be a runtime parameter.  Then, the only other thing to do
is fix
the dependencies so that the libssl-dev version be a Recommended dependency.

I appreciate the discussion.

Bug#641126: exim4-daemon-light: Control file refers to legacy web page

[Marc Singer]

Package: exim4-daemon-light
Version: 4.76-2
Severity: minor

The control file refers to

 The Debian exim4 packages have their own web page,
 http://pkg-exim4.alioth.debian.org/. There is also a Debian-specific

This site has been moved to the Debian wiki.

 http://wiki.debian.org/PkgExim4

The old page does redirect to the new one.


-- Package-specific info:
Exim version 4.76 #1 built 29-May-2011 17:32:50
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Berkeley DB 5.1.25: (January 28, 2011)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz 
dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.39-2-orion5x
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages exim4-daemon-light depends on:
ii  debconf [debconf-2.0] 1.5.40 Debian configuration management sy
ii  exim4-base4.76-2 support files for all Exim MTA (v4
ii  libc6 2.13-10Embedded GNU C Library: Shared lib
ii  libdb5.1  5.1.25-10  Berkeley v5.1 Database Libraries [
ii  libgnutls26   2.10.5-3   the GNU TLS library - runtime libr
ii  libpcre3  8.12-3 Perl 5 Compatible Regular Expressi

exim4-daemon-light recommends no packages.

exim4-daemon-light suggests no packages.

-- debconf information:
  exim4-daemon-light/drec:



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

Bug#637024: linux-image-2.6.39-2-ixp4xx: Unable to upgrade with package as released

[Marc Singer]

Package: linux-2.6
Version: 2.6.39-3
Severity: important

There appears to be a race condition in the installation of this package.  I 
believe that
the same issue was present in the 2.6.38 package as well.  The package will 
fail to install
because the postinst hook attempts to flash the kernel and initramfs before the 
initramfs
has been created.  We may be seeing a variance in the way that this platform 
handles
the kernel and ramdisk as compared to the mainstream releases.

The error reported is that the kernel/ramdisk flash operation aborts because 
the initramfs
is not found.  Indeed, there is no initramfs in /boot when the postinst hook 
runs.  When I
reinstall the previously installed kernel I can see that the update-initramfs 
script is
called *after* the kernel and initramfs are flashed.

I can work around the issue by unpacking the package, calling depmod and 
update-initramfs
manually and then reinstalling the kernel package.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
Processor   : XScale-IXP42x Family rev 1 (v5l)
Hardware: Linksys NSLU2
Revision: 

** PCI devices:
00:01.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) 
(prog-if 10 [OHCI])
Subsystem: NEC Corporation Hama USB 2.0 CardBus [1033:0035]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 8 (250ns min, 10500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 28
Region 0: Memory at 4800 (32-bit, non-prefetchable) [size=4K]
Capabilities: access denied
Kernel driver in use: ohci_hcd
Kernel modules: ohci-hcd

00:01.1 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) 
(prog-if 10 [OHCI])
Subsystem: NEC Corporation Hama USB 2.0 CardBus [1033:0035]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 8 (250ns min, 10500ns max), Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 27
Region 0: Memory at 48001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: access denied
Kernel driver in use: ohci_hcd
Kernel modules: ohci-hcd

00:01.2 USB Controller [0c03]: NEC Corporation USB 2.0 [1033:00e0] (rev 04) 
(prog-if 20 [EHCI])
Subsystem: NEC Corporation USB 2.0 [1033:00e0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 68 (4000ns min, 8500ns max), Cache Line Size: 32 bytes
Interrupt: pin C routed to IRQ 26
Region 0: Memory at 48002000 (32-bit, non-prefetchable) [size=256]
Capabilities: access denied
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd


** USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0dc4: Macpower Peripherals, Ltd 
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.32-5-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-2.6.39-2-ixp4xx depends on:
ii  debconf [debconf-2.0] 1.5.40 Debian configuration management sy
ii  initramfs-tools [linux-initra 0.99   tools for generating an initramfs
ii  linux-base3.3Linux image base package
ii  module-init-tools 3.16-1 tools for managing Linux kernel mo

Versions of packages linux-image-2.6.39-2-ixp4xx recommends:
ii  firmware-linux-free   3  Binary firmware for various driver

Versions of packages linux-image-2.6.39-2-ixp4xx suggests:
pn  fdutils   none (no description available)
pn  linux-doc-2.6.39  none (no description available)

Versions of packages linux-image-2.6.39-2-ixp4xx is related to:
pn  firmware-bnx2 none (no description available)
pn  firmware-bnx2xnone (no description available)
pn  firmware-ipw2x00  none (no description available)
pn  firmware-ivtv none (no description available)
pn  firmware-iwlwifi  none (no description available)
pn  firmware-linuxnone (no description available)
pn  firmware-linux-nonfreenone (no description available)
pn 

Bug#635232: dpkg-sig: Function write-signature fails with missing Perl subroutine

[Marc Singer]

Package: dpkg-sig
Version: 0.13.1
Severity: important

Using the get-hashes, sign-hashes, write-signature functionality
breaks on the final step.  I was able to generate the hashes and sign
them.  While attempting to write-signature's I received the following
error:

  root@fly:~/src# dpkg-sig --write-signature *hashes
  Processing hello-world_0.1.1_amd64.changes.dpkg-sig-hashes...
  Undefined subroutine main::get_deb_part called at /usr/bin/dpkg-sig line 921.

Please note that the system where I was running dpkg-sig
--write-signature is not the system where I am reporting the error.
That system does not have a working SMTP transport.

dpkg-sig was installed using apt-get.  It is running the same version
of the program, 0.13.1.


-- System Information:
Debian Release: 6.0.2
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-openvz-amd64 (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

Versions of packages dpkg-sig depends on:
ii  gnupg 1.4.10-4   GNU privacy guard - a free PGP rep
ii  libconfig-file-perl   1.50-2 Parses simple configuration files
ii  perl [libdigest-md5-perl] 5.12.4-1   Larry Wall's Practical Extraction 

dpkg-sig recommends no packages.

Versions of packages dpkg-sig suggests:
ii  libterm-readkey-perl  2.30-4+b1  A perl module for simple terminal 
pn  ssh   none (no description available)

-- no debconf information



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

Bug#609181: amule: Setting bind address should also set request source address

[Marc Singer]

Package: amule
Version: 2.2.6+debian0-8
Severity: normal


On machines with more than one address, it is sometimes necessary to
set the bind address for the local service ports.  This feature
appears to work correctly.  However, this should also change the
source address for requests to the servers such that the address used
by the servers to connect back to the amule session is the address
where the ports are bound.

Consider the case where a host has a local and unroutable primary
address on eth0.  By default, TCP requests from this host will be
forwarded through a firewall and give NAT.  A second address which is
routable is added to the host.  The amule bind address is set to the
second routable address.  Yet when the application makes requests to
the servers it will have the NAT address of the firewall instead of
the routable address.

Changing the source address for TCP connections as the bind address
will correct this problem.


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (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

Versions of packages amule depends on:
ii  amule-common  2.2.6+debian0-8common files for the rest of aMule
ii  libc6 2.11.2-6   Embedded GNU C Library: Shared lib
ii  libcrypto++8  5.6.0-6General purpose cryptographic libr
ii  libgcc1   1:4.4.5-4  GCC support library
ii  libgeoip1 1.4.7~beta6+dfsg-1 A non-DNS IP-to-country resolver l
ii  libstdc++64.4.5-4The GNU Standard C++ Library v3
ii  libupnp3  1:1.6.6-5  Portable SDK for UPnP Devices, ver
ii  libwxbase2.8-02.8.10.1-3+b1  wxBase library (runtime) - non-GUI
ii  libwxgtk2.8-0 2.8.10.1-3+b1  wxWidgets Cross-platform C++ GUI t
ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

Versions of packages amule recommends:
ii  amule-utils  2.2.6+debian0-8 utilities for aMule (command-line 
ii  unzip6.0-4   De-archiver for .zip files

Versions of packages amule suggests:
pn  amule-utils-gui   none (no description available)

-- no debconf information



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

Bug#587145: Subject: bsign: Typo in manpage on check-hash switch

[Marc Singer]

On Fri, Jun 25, 2010 at 5:12 AM, trouble daemon troubledae...@gmail.comwrote:

 Package: bsign
 Version: 0.4.5
 Severity: minor

 I was checking out the bsign man page, and was following the example syntax
 for creating and verifying a hash, but I got stumped when it said:

  $ bsign --check-hash /bin/bash
  $ parse error 2 at word 132635

 It seems that upon closer inspection, the man page has a typo. The
 COMMANDS
 section correctly says -c, --checkhash, but the EXAMPLES section shows
 the
 syntax as bsign --check-hash file (note the hyphen), which bsign
 considers as
 unknown syntax.

 Aside from the minor typo, perhaps a more descriptive error message could
 help?

 -- System Information:
 Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 -- no debconf information




Thanks for the report.  IIRC, the error is telling us where the parser
failed.  Indeed, it could be
more clear.

Bug#584166: uboot-mkimage: add compatibility flag for broken u-boot versions

[Marc Singer]

On Tue, Jun 1, 2010 at 3:08 PM, Thibaut GIRKA t...@sitedethib.com wrote:

 Package: uboot-mkimage
 Version: 0.4
 Severity: normal
 Tags: patch

 Some versions of U-Boot (especially the one in the OpenMoko Freerunner NOR)
 are
 broken and don't handle multi-file images the right way.
 Multi-file images are U-Boot images with a table of sizes (size of the
 several
 files), then the abovementionned files, aligned to multiples of 4 bytes.
 Some broken versions of U-Boot expect a 4-byte padding for already aligned
 files.

 This patch adds a switch to add one zero byte at the end of a file whose
 size
 is a multiple of 4.
 This permits readability by both broken and non-broken versions of U-Boot,
 while being safe.


Thanks.  I'll look at it.




 -- System Information:
 Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.34-rc5 (SMP w/2 CPU cores)
 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages uboot-mkimage depends on:
 ii  libc6 2.10.2-9   Embedded GNU C Library: Shared
 lib

 uboot-mkimage recommends no packages.

 uboot-mkimage suggests no packages.

 -- no debconf information

Bug#515793: Get cgit included with statically linked libgit.a?

[Marc Singer]

On Mon, Mar 8, 2010 at 2:26 AM, Paul Menzel pm.deb...@googlemail.comwrote:

 Am Sonntag, den 07.03.2010, 15:51 -0800 schrieb Marc Singer:
  On Sun, Mar 7, 2010 at 1:14 PM, Paul Menzel pm.deb...@googlemail.com
 wrote:
   Am Dienstag, den 17.02.2009, 09:40 -0800 schrieb Marc Singer:
The upstream build of cgit requires a download of git to build libgit
which this package links statically.  Thus, this package practically
depends on a change to git-core.
   
  http://hjemli.net/git/cgit/
  
   the blocking bug 407722 [1] is marked »wontfix« and judging from the
   answers on my question sent to the Git list (also cc-ed to [1]) it
 looks
   like the only option is to link statically against libgit. :(
  
   Can some Debian Developers please comment on this? And if no other
   solution is proposed could we get cgit included into the Debian package
   repository and with luck cgit might be available in Debian squeeze.
 
  I'm not optimistic that the git developers will support development
  against the library.  It's really a shame since it would benefit some
  kinds of projects that are performance bound

 You are right, as can be seen by the replies to bug #407722 [1].

 So we should deal with this situation and link against libgit
 statically. What do I miss?


IMHO, that would be an unwise path.  The GIT developers
are committed to being able to change the interface.   Seems
like the design of cgit needs to change in order to move forward.




 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407722

Bug#515793: Get cgit included with statically linked libgit.a?

[Marc Singer]

On Sun, Mar 7, 2010 at 1:14 PM, Paul Menzel pm.deb...@googlemail.comwrote:

 Dear Marc,


 Am Dienstag, den 17.02.2009, 09:40 -0800 schrieb Marc Singer:
  The upstream build of cgit requires a download of git to build libgit
  which this package links statically.  Thus, this package practically
  depends on a change to git-core.
 
http://hjemli.net/git/cgit/

 the blocking bug 407722 [1] is marked »wontfix« and judging from the
 answers on my question sent to the Git list (also cc-ed to [1]) it looks
 like the only option is to link statically against libgit. :(

 Can some Debian Developers please comment on this? And if no other
 solution is proposed could we get cgit included into the Debian package
 repository and with luck cgit might be available in Debian squeeze.


I'm not optimistic that the git developers will support development
against the library.  It's really a shame since it would benefit some kinds
of projects that are performance bound

Bug#548236: Fails to install because of change in bash

[Marc Singer]

On Tue, Oct 06, 2009 at 12:31:25PM +0100, Martin Michlmayr wrote:
 * beewoolie e...@buici.com [2009-09-24 14:17]:
  [1] See http://lists.gnu.org/archive/html/bug-bash/2009-09/msg00072.html
  Will do.  It may take a few days as my development box is offline.
 
 Is your system back or should I do an NMU?

I uploaded the revised package.

Cheers.



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

Bug#548236: Fails to install because of change in bash

[Marc Singer]

Doing it right now.

BTW, this code is surprisingly complicated to do a simple function.  I'll
add to my todo list
to revise apex-env so that it can emit a list of commands to save/restore
the environment
using a shell script.

On Thu, Sep 24, 2009 at 12:22 PM, Martin Michlmayr t...@cyrius.com wrote:

 Package: apex-nslu2
 Version: 1.6.9
 Severity: serious

 Debian user Al reported that apex-nslu2 fails to install:
 http://lists.debian.org/debian-arm/2009/09/msg00027.html

 I can confirm this.  It's caused by a chance of behaviour in bash that
 breaks flash-apex.  Since this change was made intentionally [1],
 flash-apex needs to be updated.  Can you please upload with this patch
 asap:

 --- usr/flash-apex~ 2009-09-24 20:18:16.0 +0100
 +++ usr/flash-apex  2009-09-24 20:18:31.0 +0100
 @@ -70,7 +70,7 @@
pad=$(expr $mtdblocksize - $lsize - 16)
# Store non-default APEX configuration
tmp=$(tempfile)
 -   (apex-env printenv | egrep -v '\*=')  $tmp
 +   (apex-env printenv | egrep -v '\*=')  $tmp || true
printf Flashing loader:  2
(
sercomm_header $(expr $lsize + 16)


 [1] See http://lists.gnu.org/archive/html/bug-bash/2009-09/msg00072.html
 --
 Martin Michlmayr
 http://www.cyrius.com/

Bug#523976: [rfe] buici-clock: user settable background face color

[Marc Singer]

On Tue, Apr 14, 2009 at 03:48:53PM +1200, Hamish wrote:
 Package: buici-clock
 Version: 0.4.6.0.1
 Severity: wishlist
 
 Hi,
 
 it would be nice if buici-clock had a .Xresource or command line
 setting to allow you to set a background color for the clock
 face. e.g. '#ff00ff' or one of the standard color names from 
 /etc/X11/rgb.txt.
 
 the reason for this is that I'd like to use the clock in night-
 vision mode, i.e. with a dark red clock face.

Noted.  I'll see what I can do.



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

Bug#520557: lemon: lempar.c not C++ clean

[Marc Singer]

Package: lemon
Version: 3.5.9-6
Severity: serious
Justification: unknown

The lempar.c file includes the following lines:

  /* The yyzerominor constant is used to initialize instances of
  ** YYMINORTYPE objects to zero. */
  static const YYMINORTYPE yyzerominor;

This statement doesn't compile with the 4.2 or 4.3 GCC C++ compiler.

  bsdlp.cc:113: error: uninitialized const 'yyzerominor' 

A simple fix would be to remove the const altogether.  Alternatively, the code 
could be changed to read:

  /* The yyzerominor constant is used to initialize instances of
  ** YYMINORTYPE objects to zero. */
  #if defined (__cplusplus)
  static YYMINORTYPE yyzerominor;
  #else
  static const YYMINORTYPE yyzerominor;
  #endif


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages lemon depends on:
ii  libc6 2.7-14 GNU C Library: Shared libraries

lemon recommends no packages.

-- no debconf information



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

Bug#520557: closed by Zack Weinberg za...@panix.com (already fixed upstream since 3.6.7)

[Marc Singer]

On Fri, Mar 20, 2009 at 11:03:07PM +, Debian Bug Tracking System wrote:
 
 This is an automatic notification regarding your Bug report
 which was filed against the lemon package:
 
 #520557: lemon: lempar.c not C++ clean
 
 It has been closed by Zack Weinberg za...@panix.com.
 
 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Zack Weinberg 
 za...@panix.com by
 replying to this email.
 
 
 -- 
 520557: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520557
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems

 From: Zack Weinberg za...@panix.com
 Subject: already fixed upstream since 3.6.7
 To: 520557-cl...@bugs.debian.org
 Date: Fri, 20 Mar 2009 16:01:41 -0700
 X-Spam-Level: 
 
 Package: lemon
 Version: 3.6.10-1
 
 This bug has already been fixed by upstream, in version 3.6.7, which
 appears never to have been uploaded to Debian.  The 3.6.10-1 and later
 packages (now available in unstable) should not have the problem.

That would be great.  Perhaps it is in sid instead of unstable?

   e...@zealous ~  apt-cache policy lemon
   lemon:
 Installed: (none)
 Candidate: 3.5.9-6
 Version table:
3.5.9-6 0
   500 http://ftp.us.debian.org stable/main Packages
   990 http://ftp.us.debian.org testing/main Packages
   500 http://ftp.us.debian.org unstable/main Packages




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

Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT

[Marc Singer]

Package: wnpp
Severity: wishlist

The upstream build of cgit requires a download of git to build libgit
which this package links statically.  Thus, this package practically
depends on a change to git-core.

  http://hjemli.net/git/cgit/




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

Bug#500718: gnupg: symmetric option not compatible with output option

[Marc Singer]

Package: gnupg
Version: 1.4.9-3
Severity: important

In working with gpg-zip, I found that it was impossible to build a
symmetric cipher encrypted archive because GPG required a recipient.
The trouble appears to be that GPG requires a recipient when output
option is used.

  # gpg --symmetric foo.txt

This version works fine.  I enter the passphrase and the file is
encrypted.

  # gpg --symmetric --output foo.encrupted foo.txt

This version requires a recipient.  After I enter the passphrase, it
asks for a recipient and will bail-out if I don't give it one with a
valid key.

gpg-zip could probably be rewritten to avoid the switch, but that
would be cumbersome.


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gnupg depends on:
ii  gpgv   1.4.9-3   GNU privacy guard - signature veri
ii  libbz2-1.0 1.0.5-0.1 high-quality block-sorting file co
ii  libc6  2.7-13GNU C Library: Shared libraries
ii  libreadline5   5.2-3 GNU readline and history libraries
ii  libusb-0.1-4   2:0.1.12-12   userspace USB programming library
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

Versions of packages gnupg recommends:
ii  libldap-2.4-2 2.4.10-3   OpenLDAP libraries

Versions of packages gnupg suggests:
ii  eog 2.22.3-1 Eye of GNOME graphics viewer progr
pn  gnupg-doc   none   (no description available)
ii  imagemagick 7:6.3.7.9.dfsg1-2+b2 image manipulation programs
ii  libpcsclite11.4.102-1Middleware to access a smart card 

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#496471: uboot-mkimage: Typo in the package's long description

[Marc Singer]

On Mon, Aug 25, 2008 at 04:53:20AM +0200, Nicolas FRANCOIS (Nekral) wrote:
 Package: uboot-mkimage
 Version: 0.4
 Severity: minor
 Tags: patch
 
 Hello,
 
 There is a typo in the uboot-mkimage's long description.
 kerel should be kernel.

Thanks.

 
 Best Regards,
 -- 
 Nekral
 
 
 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#496094: buici-clock: please update to the new menu structure

[Marc Singer]

On Fri, Aug 22, 2008 at 06:16:59PM +0200, Bill Allombert wrote:
 Package: buici-clock
 Version: 0.4.6.0.1
 Severity: normal
 
 Hello Marc,
 
 The file /usr/share/menu/buici-clock reads
 ?package(buici-clock):\
   needs=X11 \
   section=Apps/Tools \
   hints=Clocks \
   title=buici clock \
   command=buici-clock   

Will do.

 
 Please migrate to the new menu structure [1].
 [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5
 
 The section Apps/Tools no more exist. The consensus is that fancy clocks
 belong to Games/Toys.
 
 Cheers,
 -- 
 Bill. [EMAIL PROTECTED]
 
 Imagine a large red swirl here. 
 
 
 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#494368: synergy: Synergy quits with assertion failure.

[Marc Singer]

Package: synergy
Version: 1.3.1-4
Severity: important

Started synergys with the following command line:

 synergys -f -d INFO

After running for a couple of days, it reported an assertion failure
on the console. 

  synergys: ../../src/xcb_lock.c:77: _XGetXCBBuffer: Assertion 
`((int)((xcb_req) - (dpy-request)) = 0)' failed.

This *could* be the same as the core dumping crashes, but there is no
way to tell from the output.


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages synergy depends on:
ii  libc6 2.7-10 GNU C Library: Shared libraries
ii  libgcc1   1:4.3.1-2  GCC support library
ii  libice6   2:1.0.4-1  X11 Inter-Client Exchange library
ii  libsm62:1.0.3-2  X11 Session Management library
ii  libstdc++64.3.1-2The GNU Standard C++ Library v3
ii  libx11-6  2:1.1.4-2  X11 client-side library
ii  libxext6  2:1.0.4-1  X11 miscellaneous extension librar
ii  libxinerama1  2:1.0.3-2  X11 Xinerama extension library
ii  libxtst6  2:1.0.3-1  X11 Testing -- Resource extension 

synergy recommends no packages.

synergy suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#487574: rm-old-firmware

[Marc Singer]

On Sun, Jun 22, 2008 at 03:30:19PM -0400, Joey Hess wrote:
 Package: ixp4xx-microcode
 Severity: normal
 
 There's a rm-old-firmware branch in git that deletes an old version of
 the firmware installed by d-i.
 
 I had meant to enable that once I was sure that the package was working
 ok, which it seems to be. At least, no bugs found by its very few
 current users.
 
 Note that the version comparison in the postinst needs to be changed to
 be whatever version of the package is released with the firmware removal
 enabled.
 
 -- 
 see shy jo


I'll look into this.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#482000: needs to be installable on !slug

[Marc Singer]

On Mon, May 19, 2008 at 11:36:50PM -0400, Joey Hess wrote:
 Package: apex-nslu2
 Version: 1.4.15.1
 Severity: important
 Tags: d-i
 
 Setting up apex-nslu2 (1.4.15.1) ...
 Unsupported platform.
 
 apex-nslu2 needs to be installable on non-slug systems, since it's a build
 dependency of d-i.
 
 The postinst needs to be changed to avoid failing if it's not a slug. 

Is it sufficient to simply not install if it isn't a slug?  My
inclination is to use something from /proc/cpuinfo to determine if it
is a slug.  Is there a better way? 

 
 -- 
 see shy jo





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#481736: Bogus upstream location in debian/copyright

[Marc Singer]

On Sun, May 18, 2008 at 12:00:48PM +0200, Martin Michlmayr wrote:
 Package: apex-nslu2
 Version: 1.4.15
 
 debian/copyright says:
 
 | This program is written, maintained, and packaged for Debian by Marc
 | Singer [EMAIL PROTECTED].  The upstream source may be found on this web
 | site http://wiki.buici.com/ApexBootloader.
 
 But I get: The requested URL /ApexBootloader was not found on this
 server.
 
 I guess this should be http://wiki.buici.com/wiki/Apex_Bootloader
 -- 
 Martin Michlmayr
 http://www.cyrius.com/
 
 
 

On it.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: #421359 patch submitted

[Marc Singer]

On Sun, May 18, 2008 at 12:01:55PM +0200, Martin Michlmayr wrote:
 * Martin Michlmayr [EMAIL PROTECTED] [2008-05-18 11:15]:
  * Marc Singer [EMAIL PROTECTED] [2008-05-17 18:27]:
   I'll upload a new version this weekend.
  
  Thanks, that'd be great.  The base system is frozen alredy but I hope
  we can get an exception for this APEX upload.  However, this means you
  should make as few changes as possible.
 
 Just to clarify, this also means that the upload should be 1.4.15 plus
 those patches, not apex-1.5.13.  However, after the updated 1.4.15 is
 in lenny, we should test 1.5.13 for the nslu2.
 -- 
 Martin Michlmayr
 http://www.cyrius.com/
 
 
 

Let me see if I understand.  You want 1.4.15 with Kevin's patch and
nothing else?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: #421359 patch submitted

[Marc Singer]

On Sun, May 18, 2008 at 11:15:26AM +0200, Martin Michlmayr wrote:
 * Marc Singer [EMAIL PROTECTED] [2008-05-17 18:27]:
  I'll upload a new version this weekend.
 
 Thanks, that'd be great.  The base system is frozen alredy but I hope
 we can get an exception for this APEX upload.  However, this means you
 should make as few changes as possible.  Can you please make an upload
 with only the patches for #451882 (ramdisk size) and #421359
 (flash-apex script).  The other patch I've seen floating around sets
 EABI for the Debian armeb and armel config.  This one might be a good
 diea too (but please note that src/mach-ixp42x/debian-nslu2-armel_config
 is a symlink to debian-nslu2-arm_config; so you'd have to remove the
 symlink first, copy the file and then make the EABI change).
 
 Thanks a lot for your work.  Once this upload is done and (hopefully)
 moved to lenny, Kevin Price has a couple of other changes.  I asked
 him to file bug reports for these.
 -- 
 Martin Michlmayr
 http://www.cyrius.com/
 
 
 

What I'm going to probably do is roll back to the 1.4.15 release and
apply Kevin's patch.  I'll also fixup the configurations so that the
EABI change is only in the armel config.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: #421359 patch submitted

[Marc Singer]

On Sun, May 18, 2008 at 11:28:08PM +0200, Martin Michlmayr wrote:
 * Marc Singer [EMAIL PROTECTED] [2008-05-18 14:01]:
  Let me see if I understand.  You want 1.4.15 with Kevin's patch and
  nothing else?
 
 I believe Kevin's patch contains some changes we don't need.
 
 I think this one is what we want:

[deletia]

That's what I've included.  I added the man page for flash-apex as
well.

I'd have been done, but my slug appears to need debhelper updating



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#481848: CONFIG_AEABI=y

[Marc Singer]

On Mon, May 19, 2008 at 01:24:46AM +0200, Kevin Price wrote:
 Package: apex-nslu2
 
 Hi,
 
 version 1.5.13 does not build on my armel/lenny slug, unless I switch
 the option CONFIG_AEABI to y. I support Martin Michlmayr's suggestion
 removing the symlink
 
 src/mach-ixp42x/debian-nslu2-armel_config - debian-nslu2-arm_config
 
 and making a copy of the file. That would make it possible to switch the
 AEABI on only on armel. When I built 1.5.13 on armel and arm, it worked
 for both arches leaving the symlink and simply turning the option on for
 both arches.
 
 There seems to be little difference, but it might make more sense to
 compile only armel with eabi and arm with oabi.

There shouldn't really be a difference between AEABI on and off except
for some new symbols and a couple of small functions in the support
libraries.  I'll set EABI on for all debian builds.

 
 best regards
 -- 
 Kevin
 http://www.kevin-price.de/
 





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: #421359 patch submitted

[Marc Singer]

On Mon, May 12, 2008 at 08:45:31PM +0200, Martin Michlmayr wrote:
 * Joey Hess [EMAIL PROTECTED] [2008-05-12 12:57]:
  A few changes to the postinst script. No need to hardocde /usr/sbin,
  this is always in the path when running a postinst script. #DEBHELPER# 
  should be put in for debhelper's use. No need to test if flash-apex is
  executable, it always will be when dpkg runs postinst configure.
 
 Thanks for your comments, Joey.
 
 Marc, can you please upload a new apex-nslu2 with fixes for #421359
 and #451882.  The ramdisk for 2.6.25 (in unstable) is larger than 4 MB
 (on armel, not on arm), and some people reported already that their
 nslu2 no longer boots... if there's no upload within 2 weeks, I intend
 to NMU.
 
 -- 
 Martin Michlmayr
 http://www.cyrius.com/
 
 
 

Sorry for the delay.  Spam abatement underway.

I'll upload a new version this weekend.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: #421359 patch submitted

[Marc Singer]

On Sun, Mar 02, 2008 at 09:58:28PM -0700, Gordon Farquharson wrote:
 
 The patch below is my attempt at adding the flash-apex script and a
 postinst script to the apex package. The diff is created between apex
 version 1.5.13 and an imaginary version 1.5.14.
 
 Would it be possible for you to incorporate these changes, along with
 the changes in #451882, into your latest apex version, and upload the
 new package?

I just got this, so I'll take a look.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451882: Increase CONFIG_RAMDISK_SIZE

[Marc Singer]

On Sun, Nov 18, 2007 at 08:29:38PM -0700, Gordon Farquharson wrote:
 Package: apex-nslu2
 Version: 1.4.15
 Severity: normal
 
 Hi Marc
 
 The apex-nslu2 package currently sets CONFIG_RAMDISK_SIZE to
 0x0040 whereas the Ramdisk partition on the NSLU2 is 0x0060
 bytes. The boot log indicates that APEX computes the size of the
 partition (line after copy -s fis://ramdisk 0x0100 below).

Ooops.

 
 # copy -s $kernelsrc $bootaddr
 # copy -s fis://kernel 0x8000
 1441760 bytes transferred
 # copy -s $ramdisksrc $ramdiskaddr
 # copy -s fis://ramdisk 0x0100
 6291440 bytes transferred
 
 Note that 6291440 = 0x0050 which is the size of the Ramdisk
 partition minus 16 bytes. However, the value for CONFIG_RAMDISK_SIZE
 that is used in the ATAG header is the value set in the APEX .config
 file (0x0040) when building APEX.
 
 ATAG_HEADER
 ATAG_MEM: start 0x  size 0x0200
 ATAG_CMDLINE: (67 bytes) 'console=ttyS0,115200 rtc-x1205.probe=0,0x6f
 noirqdebug rootdelay=2'
 ATAG_INITRD2: start 0x0100  size 0x0040
 ATAG_END
 Booting kernel at 0x8000...
 
 Is it possible to change APEX such that the computed value is used to
 set the ATAG header?

Hmm.  The trouble with that is Apex doesn't really know that you are
copying a ramdisk.  The configuration options that specify the source
region and extent *seem* to imply that, but really it is just for the
benefit of the user.

The easy thing to do is to increase the option that sets the ATAG
properly.

 
 If not, it would great if you would upload a version of APEX that has
 CONFIG_RAMDISK_SIZE set to 0x0050. Martin recently updated
 flash-kernel so that it correctly handles initial ramdisks that are
 larger than 4 MiB, but we need to change APEX for completeness. The
 results of the test I have done are
 
 CONFIG_RAMDISK_SIZE   flash-kernel   ramdisk size   Result
 0x00401.1 4 MiBOK (etch)
 0x00401.1 4 MiBDoes not boot
 0x0040SVN 4 MiBOK
 0x0040SVN 4 MiBDoes not boot
 0x00501.1 4 MiBOK
 0x00501.1 4 MiBOK
 0x0050SVN 4 MiBOK
 0x0050SVN 4 MiBOK

Which configurations do you want changed?  The debian-nslu2 ones?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: nslu2 startup with automatic fat-slug detection

[Marc Singer]

On Thu, Jun 28, 2007 at 12:39:29AM -0600, Gordon Farquharson wrote:
 I like the idea of creating a separate script to flash APEX. We add
 the script to the apex-nslu2 package, and run it as part of postinst
 when APEX is upgraded. In this case, we shouldn't need to check if
 APEX is present in the Loader partition, because we can assume that
 APEX is being installed as the second stage bootloader.

Good point.

 With reference to your comment on using APEX as the primary
 bootloader: I think that it would be dangerous at the moment to
 provide an easy way for people to flash APEX as the primary
 bootloader, because people may actually do it without a full
 appreciation of what they are doing.

Ah, but the key here is that a user *may* have installed APEX as the
primary loader and we don't want to perturb their system if we don't
(in scipts) properly understand their configuration.  As long as the
install script is smart about when it installs and avoids corrupting
the flash, we should be ok.

 
 BTW, I'll be away for from Friday this week to Sunday next week, so I
 won't have time to work on the changes until after the 8th of July.

No worries.

 
 Gordon
 
 -- 
 Gordon Farquharson
 GnuPG Key ID: 32D6D676


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: nslu2 startup with automatic fat-slug detection

[Marc Singer]

On Tue, Jun 26, 2007 at 09:07:49PM -0700, Marc Singer wrote:
 On Tue, Jun 26, 2007 at 09:07:16PM -0600, Gordon Farquharson wrote:
  Hi Marc
  
  On 6/26/07, Marc Singer [EMAIL PROTECTED] wrote:
  
  I recall that there was a thread of discussion about automatically
  upgrading APEX when a new package is installed.  Was this resolved?
  In order for me to install a new APEX, I had to take the
  /boot/apex.flash image, byte swap it, and then put the sercomm header
  on it.  I can also put a copy of apex with all of those steps already
  taken into /boot so that it is really easy to upgrade (or downgrade
  for that matter).
  
  A while ago, I submitted a patch to flash-kernel [1] which will write
  apex to mtdblock2 as part of the flash-kernel script. As I mentioned
  in my response to #421359, it is easy to make this a separate script.

I had another thought about this.  It may be worthwhile to make sure
to install APEX only if it is already present in the Loader partition
and if there is a Loader partition.  Some people may choose to install
APEX as the primary boot loader.

There is a mkboot script for x86, should we do the same?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: nslu2 startup with automatic fat-slug detection

[Marc Singer]

On Tue, Jun 26, 2007 at 09:07:16PM -0600, Gordon Farquharson wrote:
 Hi Marc
 
 On 6/26/07, Marc Singer [EMAIL PROTECTED] wrote:
 
 I recall that there was a thread of discussion about automatically
 upgrading APEX when a new package is installed.  Was this resolved?
 In order for me to install a new APEX, I had to take the
 /boot/apex.flash image, byte swap it, and then put the sercomm header
 on it.  I can also put a copy of apex with all of those steps already
 taken into /boot so that it is really easy to upgrade (or downgrade
 for that matter).
 
 A while ago, I submitted a patch to flash-kernel [1] which will write
 apex to mtdblock2 as part of the flash-kernel script. As I mentioned
 in my response to #421359, it is easy to make this a separate script.

Sounds good.  I was thinking that it would be handy to have a script
that can do this in one go, but it looks like all of the necessary plumbing is 
available in flash-kernel.

In reading your script, I noticed a couple of things.  You really
don't need to restore the environment if you don't erase it.  It's at
the end of the block and should be out of the way.  APEX is good about
maintaining compatibility with previous versions of the environment,
so nothing to worry about there.

It also seems to me that you are best off setting the sercomm_header
length to the length of APEX and not the length of the whole block.
In this way, you only need to write the extent of APEX plus the size
of the sercomm header.  I know that the kernel will perform a complete
write in any case, but it more precise to pass the sercomm header with
the APEX length.

Cheers.

P.S.  It is interesting (to me) to see how you use the *= notation to
eliminate default variable contents.  :-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421359: Needs to be written to flash on upgrades

[Marc Singer]

On Sat, Apr 28, 2007 at 11:14:27AM +0200, Martin Michlmayr wrote:
 Package: apex-nslu2
 Version: 1.4.15
 
 At the moment, the versions of apex-nslu2 are not written to flash.
 We need to figure out some way to do this eventually.  I suppose we
 could copy some code from flash-kernel to apex-nslu2's postinst, or
 maybe have apex-nslu2 depend on flash-kernel and then have
 apex-nslu2's postinst call flash-kernel in some special way.

Let me see if I understand what you are saying.  When users upgrade
apex, they don't get a new boot loader as they would expect with LILO
or GRUB.

Sounds like a reasonable thing to do for them as long as it is already
installed.  We can use the environment scanning application to
determine if APEX is present.

 The other problem is that Debian's flash is padded with zeros rather
 than FFs as APEX expects.  So we might have to store the environment,
 clear it (with FFs) and then restore it.  Some initial thoughts on
 this can be found in
 http://lists.debian.org/debian-arm/2007/02/msg00014.html
 but I'm not sure I'm the right person to work on this.

If we are going to automate the procedure of reflashing the boot
loader, we can add support for clearing the environment when we do
this.

 Joey, do you think look into this?

Is there an important reason why Debian pads with zeroes?

Cheers.
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409747: apex-nslu2 1.4.14 breaks current debian-installer build

[Marc Singer]

On Tue, Feb 06, 2007 at 05:49:14AM +0100, Martin Michlmayr wrote:
 * Marc Singer [EMAIL PROTECTED] [2007-02-05 18:21]:
  Looks like an inadvertent change of the output file name.  I'll fix
  it and do an upload.
 
 ... or we simply stay with the new name since I've changed d-i to cope
 with both the old and new name.

I already posted the change.  I suppose you could make D-I accept
either?

 -- 
 Martin Michlmayr
 http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409747: apex-nslu2 1.4.14 breaks current debian-installer build

[Marc Singer]

On Mon, Feb 05, 2007 at 12:30:05AM -0700, Gordon Farquharson wrote:
 Package: apex
 Version: 1.4.14
 Severity: important
 
 apex-nslu2 1.4.14 breaks the current debian-installer build because
 /boot/apex.flash no longer exists in the 1.4.14 deb.
 
 cp /boot/apex.flash ./tmp/ixp4xx_netboot/apex.flash
 cp: cannot stat `/boot/apex.flash': No such file or directory
 make[2]: *** [nslu2_swap] Error 1
 make[1]: *** [_build] Error 2
 make: *** [build_ixp4xx_netboot] Error 2
 
 Files in apex-nslu2_1.4.7_arm.deb
 
 boot/apex.flash
 usr/share/doc/apex-nslu2/changelog.Debian.gz
 usr/share/doc/apex-nslu2/changelog.gz
 usr/share/doc/apex-nslu2/copyright
 
 and in apex-nslu2_1.4.14_arm.deb
 
 boot/apex.bin
 usr/sbin/apex-env
 usr/share/doc/apex-nslu2/changelog.Debian.gz
 usr/share/doc/apex-nslu2/changelog.gz
 usr/share/doc/apex-nslu2/copyright
 usr/share/man/man8/apex-env.8.gz
 
 Please adjust the severity of this bug appropriately.

Looks like an inadvertent change of the output file name.  I'll fix it and do 
an upload.


 
 Gordon
 
 -- 
 Gordon Farquharson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409189: apex: crossbuilding support

[Marc Singer]

On Wed, Jan 31, 2007 at 06:03:38PM +0200, Guillem Jover wrote:
 Package: apex
 Version: 1.4.14
 Severity: wishlist
 Tags: patch
 
 Hi,
 
 This patch changes the usage of DEB_BUILD_ARCH to the correct
 DEB_HOST_ARCH, which allows crossbuilding.

Thx, applied.

 
 regards,
 guillem

 diff -Naur apex-1.4.14/debian/rules apex-1.4.14.new/debian/rules
 --- apex-1.4.14/debian/rules  2007-01-30 08:48:25.0 +0200
 +++ apex-1.4.14.new/debian/rules  2007-01-31 18:01:35.0 +0200
 @@ -10,21 +10,21 @@
  package = apex-nslu2
  docdir = debian/tmp/usr/share/doc/$(package)
  
 -DEB_BUILD_ARCH := $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 -CONFIG := debian-nslu2-$(DEB_BUILD_ARCH)_config
 +DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
 +CONFIG:= debian-nslu2-$(DEB_HOST_ARCH)_config
  
  CC = gcc
  CFLAGS = -g -Wall
  INSTALL_PROGRAM = install
  
  
 -ifeq (arm,$(DEB_BUILD_ARCH))
 +ifeq (arm,$(DEB_HOST_ARCH))
   ENDIAN:=l
  endif
 -ifeq (armel,$(DEB_BUILD_ARCH))
 +ifeq (armel,$(DEB_HOST_ARCH))
   ENDIAN:=l
  endif
 -ifeq (armeb,$(DEB_BUILD_ARCH))
 +ifeq (armeb,$(DEB_HOST_ARCH))
   ENDIAN:=b
  endif
  



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#408443: Is there a reason not to link with libgcc.a?

[Marc Singer]

I'm inclined to add the

 $(shell gcc -print-libgcc-file-name) 

to the link for all targets.  Seems harmless as long as the compiler
is GCC and I don't really support anything else anyway?

Am I missing something?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#394418: question for ARM porters: incomplete arm v3 support in etch?

[Marc Singer]

On Fri, Oct 27, 2006 at 09:50:44PM -0700, Steve Langasek wrote:
 Hello,
 
 Bug #394418 is a report filed regarding a recurring build problem with mono
 on arm that results from mono generating code that's incompatible with the
 arm v3 instruction set.  Likewise, it appears shadow fails to build on elara
 (one of the netwinder buildds) due to an illegal instruction from xsltproc,
 but not on the newer buildds.
 
 I'm inclined to tag 394418 etch-ignore, because most of the arm buildds (all
 of the faster ones) are capable of handling newer instruction sets, and the
 autobuilder for stable-security on arm is among those that can.  But before
 I do that, I want to confirm:  do the ARM porters consider this reasonable?
 Should support for arm v3 systems be considered release-critical on this
 architecture?  And if so, is someone available to work on fixing mono's code
 generation, or would mono need to be dropped from arm for etch?

No objections.

AFAICT, the popularity of Debian/ARM is due to the recent crop of
IXP42x's.  The oldest hardware that I have is ARM720, which is also
v4.

OTOH, we've carried 386 for a long time and there are so few of those
around anymore.  I'd prefer not worrying about the v3 machines, but
our policy tends to be inclusive.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#363001: buici-clock: Uninstalable after X upgrade

[Marc Singer]

On Sun, Apr 16, 2006 at 10:22:29PM -0400, Patricio Rojo wrote:
 Package: buici-clock
 Version: 0.4.5+b1
 Severity: grave
 Justification: renders package unusable
 
 After last upgrade of the X system, buici-clock got removed. When trying 
 to reinstall it, I get the following message...
 
 The following packages have unmet dependencies:
   buici-clock: Depends: libice6 but it is not going to be installed
Depends: libsm6 but it is not going to be installed
Depends: libx11-6 but it is not going to be installed
Depends: libxext6 but it is not going to be installed
 
Thanks!

ACK.  I'll take a look.

 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/dash
 Kernel: Linux 2.6.15-1-686
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 
 Versions of packages buici-clock depends on:
 ii  libc6 2.3.6-7GNU C Library: Shared libraries
 ii  libgcc1   1:4.1.0-1  GCC support library
 ii  libice6   1:1.0.0-2  X11 Inter-Client Exchange library
 ii  libsm61:1.0.0-3  X11 Session Management library
 ii  libstdc++64.1.0-1The GNU Standard C++ Library v3
 ii  libx11-6  2:1.0.0-6  X11 client-side library
 ii  libxext6  1:1.0.0-3  X11 miscellaneous extension 
 librar
 
 buici-clock recommends no packages.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#363001: buici-clock: Uninstalable after X upgrade

[Marc Singer]

On Sun, Apr 16, 2006 at 08:40:26PM -0700, Steve Langasek wrote:
 On Sun, Apr 16, 2006 at 07:53:00PM -0700, Marc Singer wrote:
  On Sun, Apr 16, 2006 at 10:22:29PM -0400, Patricio Rojo wrote:
   Package: buici-clock
   Version: 0.4.5+b1
   Severity: grave
   Justification: renders package unusable
 
   After last upgrade of the X system, buici-clock got removed. When trying 
   to reinstall it, I get the following message...
 
   The following packages have unmet dependencies:
 buici-clock: Depends: libice6 but it is not going to be installed
  Depends: libsm6 but it is not going to be installed
  Depends: libx11-6 but it is not going to be installed
  Depends: libxext6 but it is not going to be installed
 
  ACK.  I'll take a look.
 
 The problem is that buici-clock installs to /usr/X11R6/bin, which is going
 away.  This was always a bug in buici-clock, according to policy 11.8.7:
 
  Packages using the X Window System should not be configured to install
  files under the `/usr/X11R6/' directory unless they use `imake'.  The
  `/usr/X11R6/' directory hierarchy should be regarded as deprecated for
  all packages except the X Window System itself, and those which use
  the `imake' program it provides, in which case the packages may
  transition out of the `/usr/X11R6/' directory at the maintainer's
  discretion.[1]
 
 But now it's a release-critical bug.  See
 http://lists.debian.org/debian-devel-announce/2006/04/msg00010.html.
 
 It looks like this is a one-line fix to debian/rules.
 
 Thanks,

NP.  I incorrectly thought I'd done this already.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#346639: buici-clock - FTBFS: cannot find -lX11

[Marc Singer]

On Sun, Jan 15, 2006 at 10:57:35AM +0100, Bastian Blank wrote:
 On Sat, Jan 14, 2006 at 04:43:50PM -0800, Marc Singer wrote:
  I'm depending on libx11-dev installing libX11.a in /usr/X11R6/lib.  Is
  it there on the s390?
 
 It is, but /usr/X11R6/lib is not in the library search path. See
 http://buildd.debian.org/build.php?pkg=buici-clock.

Thanks.  I used to get there via the package site which is down.

Looks like an error in autoconf.  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#346639: buici-clock - FTBFS: cannot find -lX11

[Marc Singer]

close 346639

Updated to autoconf2.59 so that the configure script can find the X
libraries without libxt being installed.
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#346639: buici-clock - FTBFS: cannot find -lX11

[Marc Singer]

On Sun, Jan 15, 2006 at 12:30:10AM +0100, Bastian Blank wrote:
 reopen 346639
 found 346639 0.4.3
 thanks
 
 There was an error while trying to autobuild your package:
 
  Automatic build of buici-clock_0.4.3 on debian-31 by sbuild/s390 85
 [...]
  Checking for source dependency conflicts...
/usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install 
  debhelper bison flex libx11-dev libxext-dev
 [...]
  c++ -g  -lX11 -lXext -o o/xo o/ldisplay.o o/lwindow.o o/lfont.o o/wbutton.o 
  o/wtext.o o/wdialog.o o/lhash.o o/larray.o o/res.o o/dmalloc.o o/dither.o 
  o/lpicture.o o/loupe.o o/stats.o o/res_l.o o/res_y.o
  /usr/bin/ld: cannot find -lX11
  collect2: ld returned 1 exit status
  make[2]: *** [o/xo] Error 1
  make[2]: Leaving directory `/build/buildd/buici-clock-0.4.3/xo'
  make[1]: *** [xolib] Error 2
  make[1]: Leaving directory `/build/buildd/buici-clock-0.4.3'
  make: *** [build] Error 2
  **
  Build finished at 20060113-2355
  FAILED [dpkg-buildpackage died]

Can you send me the whole build log?  The packages.debian.org server is down.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#341781: ssh: Unable to use hostbased authentication due to hostname mistmatches

[Marc Singer]

Package: ssh
Version: 1:3.8.1p1-8.sarge.4
Severity: important


After an upgrade of SSH, hostbased authentication stopped working.
I've spent some time recompiling the package with more debug
information and I believe I have found the rootcause, though I don't
know what part of the package changed.

The symptom is that the hostbased authentication always fails to
accept the host keys and instead either asks for a password, or for
the user's RSA key passphrase.   The reason the remote machine
rejected the request is in check_rhosts_file(); the hostnames are
different.  One has a trailing period and the other does not.  By
adding a period to the .shosts hostname, the check succeeds.

Unfortunately, that isn't sufficient.  Adding the period later breaks
the monitor_valid_hostbasedblob() call where again, one hostname ends
with a period and the other does not.

It is possible that this is the same problem as #115286.

The next place to look is in the code that passes the requestor's
hostname to check_rthosts_file().  


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages ssh depends on:
ii  adduser3.63  Add and remove users and groups
ii  debconf1.4.30.13 Debian configuration management sy
ii  dpkg   1.10.28   Package maintenance system for Deb
ii  libc6  2.3.2.ds1-22  GNU C Library: Shared libraries an
ii  libpam-modules 0.76-22   Pluggable Authentication Modules f
ii  libpam-runtime 0.76-22   Runtime support for the PAM librar
ii  libpam0g   0.76-22   Pluggable Authentication Modules l
ii  libssl0.9.70.9.7e-3sarge1SSL shared libraries
ii  libwrap0   7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

-- debconf information:
* ssh/privsep_tell:
  ssh/insecure_rshd:
  ssh/privsep_ask: true
  ssh/ssh2_keys_merged:
  ssh/user_environment_tell:
* ssh/forward_warning:
  ssh/insecure_telnetd:
  ssh/new_config: true
* ssh/use_old_init_script: true
* ssh/protocol2_only: true
  ssh/encrypted_host_key_but_no_keygen:
* ssh/run_sshd: true
* ssh/SUID_client: true
  ssh/disable_cr_auth: false


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328323: pure-ftpd: Large files not visible via FTP client

[Marc Singer]

Package: pure-ftpd
Version: 1.0.19-4
Severity: important


Files larger than 2G (I guess) are not visible in the directory
listing from an FTP client.  I used lftp to verify this.  I didn't
check to see if I could download the file regardless of the fact that
I couldn't see it in the directory listing.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages pure-ftpd depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libcap1 1:1.10-14support for getting/setting POSIX.
ii  libpam0g0.76-22  Pluggable Authentication Modules l
ii  libssl0.9.7 0.9.7e-3 SSL shared libraries
ii  pure-ftpd-common1.0.19-4 Pure-FTPd FTP server (Common Files

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#324473: mozilla-firefox: Segfaults on startup before showing a window

[Marc Singer]

Package: mozilla-firefox
Version: 1.0.4-2sarge2
Followup-For: Bug #324473


Unlike the other reports, I don't ever see a window.

  [EMAIL PROTECTED] ~  mozilla-firefox

  (firefox-bin:12259): Gdk-WARNING **: gdk_property_get(): length value has 
wrapped in calculation (did you pass G_MAXLONG?)
  Segmentation fault
  [EMAIL PROTECTED] ~  

I've run it through GDB to look at the system state.

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread -1221592960 (LWP 12430)]
  0xb7ec7022 in JS_GetClass () from /usr/lib/libmozjs.so
  (gdb) disas $pc $pc +30
  Dump of assembler code from 0xb7ec7022 to 0xb7ec7040:
  0xb7ec7022 JS_GetClass+18:mov(%edi),%ecx
  0xb7ec7024 JS_GetClass+20:call   0xb7ec4250 _init+8468
  0xb7ec7029 JS_GetClass+25:add$0x6f26f,%ebx
  0xb7ec702f JS_GetClass+31:mov0x978(%ebx),%esi
  0xb7ec7035 JS_GetClass+37:mov0x4(%ecx),%edx
  0xb7ec7038 JS_GetClass+40:cmp%esi,%edx
  0xb7ec703a JS_GetClass+42:je 0xb7ec70a8 JS_GetClass+152
  0xb7ec703c JS_GetClass+44:test   %edx,%edx
  0xb7ec703e JS_GetClass+46:je 0xb7ec7050 JS_GetClass+64
  End of assembler dump.

A register dump shows that %edi is zero.

Moreover, unlike other reports, I (apparently) cannot get it to run by
removing .mozilla or any other directories in the user home.  If I
create a new user and run mozilla-firefox there, it does execute.


-- System Information:
Debian Release: testing/unstable
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages mozilla-firefox depends on:
ii  debianutils2.14.1Miscellaneous utilities specific t
ii  fontconfig 2.3.2-1   generic font configuration library
ii  libatk1.0-01.10.1-2  The ATK accessibility toolkit
ii  libc6  2.3.2.ds1-22  GNU C Library: Shared libraries an
ii  libfontconfig1 2.3.2-1   generic font configuration library
ii  libfreetype6   2.1.7-2.4 FreeType 2 font engine, shared lib
ii  libgcc11:4.0.1-2 GCC support library
ii  libglib2.0-0   2.6.5-1   The GLib library of C routines
ii  libgtk2.0-02.6.8-1   The GTK+ graphical user interface 
ii  libidl00.8.5-1   library for parsing CORBA IDL file
ii  libjpeg62  6b-10 The Independent JPEG Group's JPEG 
ii  libkrb53   1.3.6-3   MIT Kerberos runtime libraries
ii  libpango1.0-0  1.8.2-1   Layout and rendering of internatio
ii  libpng12-0 1.2.8rel-1PNG library - runtime
ii  libstdc++5 1:3.3.6-7 The GNU Standard C++ Library v3
ii  libx11-6   4.3.0.dfsg.1-14   X Window System protocol client li
ii  libxext6   4.3.0.dfsg.1-14   X Window System miscellaneous exte
ii  libxft22.1.7-1   FreeType-based font drawing librar
ii  libxp6 4.3.0.dfsg.1-14   X Window System printing extension
ii  libxt6 4.3.0.dfsg.1-14   X Toolkit Intrinsics
ii  psmisc 21.6-1Utilities that use the proc filesy
ii  xlibs  4.3.0.dfsg.1-14   X Keyboard Extension (XKB) configu
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

mozilla-firefox recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#295473: autoconf: AC_MALLOC_FUNC broken on cross-compiles with GNU compilers

[Marc Singer]

On Tue, Feb 22, 2005 at 11:39:42AM -0800, Ben Pfaff wrote:

[deletia]

 The documentation for AC_MALLOC_FUNC in the autoconf manual shows
 you what replacement you should provide:
 
  #if HAVE_CONFIG_H
  # include config.h
  #endif
  #undef malloc
  
  #include sys/types.h
  
  void *malloc ();
  
  /* Allocate an N-byte block of memory from the heap.
 If N is zero, allocate a 1-byte block.  */
  
  void *
  rpl_malloc (size_t n)
  {
if (n == 0)
  n = 1;
return malloc (n);
  }

This isn't a reasonable solution when cross compiling.  Adding code to
a complex package, especially when there are many packages in a
project, is prohibitive.

Paul Eggert made the reasonable suggestion that defining the macro
ahead of time, in the environment, bypasses the configuration scripts
logic to force replacement of malloc.  A much better solution than
adding code

  export ac_cv_func_malloc_0_nonnull=yes

Cheers.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#295913: quilt: Quilt doesn't properly follow symlinked source files

[Marc Singer]

Package: quilt
Version: 0.37-4
Severity: normal


Using quilt add or quilt edit on a symlinked file confuses quilt.  As
it doesn't recognize that the named file is a symlink to a source
file, quilt fails to track changes to that source file.  This is
probably easily solved by either disallowing add/edit to a symlinked
file, or more robustly, following the symlink and adding the path of
the real file instead.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages quilt depends on:
ii  bzip2   1.0.2-1  A high-quality block-sorting file 
ii  diffstat1.35-1   produces graph of changes introduc
ii  gawk1:3.1.4-2GNU awk, a pattern scanning and pr
ii  gettext 0.14.1-6 GNU Internationalization utilities
ii  libc6   2.3.2.ds1-18 GNU C Library: Shared libraries an
ii  patch   2.5.9-2  Apply a diff file to an original

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#295473: autoconf: AC_MALLOC_FUNC broken on cross-compiles with GNU compilers

[Marc Singer]

Package: autoconf
Version: 2.59a-3
Severity: important


In cross compiling the AC_MALLOC_FUNC function will *always* indicate
that malloc should be replaced with rpl_malloc.  The code in the
./configure scripts looks like this:

echo $as_me:$LINENO: checking for GNU libc compatible malloc 5
echo $ECHO_N checking for GNU libc compatible malloc... $ECHO_C 6
if test ${ac_cv_func_malloc_0_nonnull+set} = set; then
  echo $ECHO_N (cached) $ECHO_C 6
else
  if test $cross_compiling = yes; then
  ac_cv_func_malloc_0_nonnull=no
else
  cat conftest.$ac_ext _ACEOF
/* confdefs.h.  */
_ACEOF
[...]


The test $cross_compiling check will force the test to fail even if
the target compiler is GCC and has no such bug.


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages autoconf depends on:
ii  debianutils   2.8.4  Miscellaneous utilities specific t
ii  m41.4.2-1a macro processing language
ii  perl  5.8.4-5Larry Wall's Practical Extraction 

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]