Bug#412149: marked as done (general: "usb:" stopped working in both gpsbabel and jpilot)

[Debian Bug Tracking System]

Your message dated Fri, 23 Feb 2007 17:05:45 -0800
with message-id <[EMAIL PROTECTED]>
and subject line Bug#412149: general: "usb:" stopped working in both gpsbabel 
and jpilot
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: general
Severity: normal


A few days ago, jpilot stopped syncing my USB PalmPilot. I had been using
libusb (i.e. "usb:" as the port). A reboot and a different cable didn't help,
but un-blacklisting the visor module and changing the port to /dev/pilot --
i.e. using the kernel visor module instead of libusb, reversing the procedure
suggested in #399878 -- and now sycning works fine.

Similarly, gpsbabel, which also uses libusb, no longer speaks to my GPS unit:

  4 [~]$ gpsbabel -r -i garmin -f usb: -o gpx -F /tmp/foo
  usb_set_configuration failed, probably because kernel driver ''
   is blocking our access to the USB device.
  For more information see http://www.gpsbabel.org/os/Linux_Hotplug.html

dmesg output for both the pilot and the GPS are along the lines of:

  ohci_hcd :00:02.0: wakeup
  usb 1-3: new full speed USB device using ohci_hcd and address 11
  usb 1-3: configuration #1 chosen from 1 choice
  usb 1-3: USB disconnect, address 11

Also, the GPS works fine in mass storage mode -- again, no libusb.

The following are the packages I upgraded between working and non-working USB:

2007-02-20 21:36:24 status installed dhcp3-common 3.0.4-13
2007-02-20 21:36:29 status installed dhcp3-server 3.0.4-13
2007-02-20 21:36:29 status installed module-init-tools 3.3-pre4-1
2007-02-20 21:36:38 status installed linux-sound-base 1.0.13-4
2007-02-20 21:36:39 status installed alsa-base 1.0.13-4
2007-02-20 21:36:47 status installed libexpat1 1.95.8-3.4
2007-02-20 21:36:47 status installed libexpat1-dev 1.95.8-3.4
2007-02-20 21:36:47 status installed apache2-utils 2.2.3-3.3
2007-02-20 21:36:47 status installed busybox 1:1.1.3-4
2007-02-20 21:36:47 status installed libklibc 1.4.34-1
2007-02-20 21:36:47 status installed klibc-utils 1.4.34-1
2007-02-20 21:36:47 status installed libgphoto2-port0 2.2.1-16
2007-02-20 21:36:50 status installed libgphoto2-2 2.2.1-16
2007-02-20 21:36:51 status installed libpango1.0-common 1.14.8-5
2007-02-20 21:36:51 status installed libpango1.0-0 1.14.8-5
2007-02-20 21:36:51 status installed libpango1.0-dev 1.14.8-5
2007-02-20 21:36:51 status installed libscrollkeeper0 0.3.14-13
2007-02-20 21:36:52 status installed openoffice.org-common 2.0.4.dfsg.2-5
2007-02-20 21:37:04 status installed ttf-opensymbol 2.0.4.dfsg.2-5
2007-02-20 21:37:04 status installed openoffice.org-core 2.0.4.dfsg.2-5
2007-02-20 21:37:07 status installed python-uno 2.0.4.dfsg.2-5
2007-02-20 21:37:07 status installed openoffice.org-writer 2.0.4.dfsg.2-5
2007-02-20 21:37:07 status installed openoffice.org-draw 2.0.4.dfsg.2-5
2007-02-20 21:37:07 status installed openoffice.org-gtk 2.0.4.dfsg.2-5
2007-02-20 21:37:09 status installed scrollkeeper 0.3.14-13
2007-02-20 21:37:09 status installed ttf-dejavu 2.14-2
2007-02-20 21:37:10 status installed ttf-freefont 20060501cvs-10
2007-02-20 21:37:11 status installed update-inetd 4.27-0.3
2007-02-20 21:37:19 status installed x-ttcidfont-conf 25.1

I'm not sure for which package this bug report is appropriate. libusb seems a
likely candidate, but I haven't upgraded that package since October and
haven't touched the configuration in a while.

Any help would be greatly appreciated. Please let me know what further
information would be useful.

Thanks,

Reid


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-3-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

--- End Message ---
--- Begin Message ---
On Fri, Feb 23, 2007 at 06:27:01PM -0600, Reid Priedhorsky wrote:
> The following are the packages I upgraded between working and non-working USB:



> 2007-02-20 21:36:47 status installed libgphoto2-port0 2.2.1-16
> 2007-02-20 21:36:50 status installed libgphoto2-2 2.2.1-16



> I'm not sure for which package this bug report is appropriate. libusb seems a
> likely candidate, but I haven't upgraded that package since October and
> haven't touched the configuration in a while.

This latest libgphoto update fixed a security hole whereby libgphoto's udev
rules would wrongly grant access to the plugdev group on all usb devices
instead of just those related to cameras.  An interesting possibility here
is that your use of libusb depended on libgphoto's bug

Re: Where did Bacula 1.38.11-7+b1 come from?

[Steve Langasek]

On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote:
> > (This problem was reported in bug #411652)

> > I think someone deserves a serious thwacking...  they obviously didn't
> > even try to install the result of the NMU, filed no bug about it, etc.

> The bug is that a binNMU for bacula was scheduled although it is not
> binNMU-able. Usually checking is done whether the package would break
> before triggereing the rebuilt. Looks like this was missed this time.

Well, no; it wasn't missed, it just isn't done these days, because the
fraction of the archive that's been fixed to be binNMU-safe is high enough,
and the number of packages that get binNMUed is great enough, that it's
simply more practical to binNMU and catch any breakage afterwards than to
try to sniff out all possible failures in advance.

As mentioned elsewhere in the thread,
http://ftp-master.debian.org/~vorlon/transition-binnmus.txt keeps a log of
/most/ binNMUs -- it doesn't even include one-off binNMUs that only apply to
a single architecture -- and records over 1000 to date.  The rate of
problems these days seems to be better than 1 in 20 or 30; I'm sorry that
John was caught off-guard by one of these problems hitting his package in
particular, but with those odds it doesn't make sense to spend a lot of time
looking for problems that almost always aren't going to be there, and can be
quickly fixed if they are.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: Where did Bacula 1.38.11-7+b1 come from?

[Steve Langasek]

Hi John,

On Thu, Feb 22, 2007 at 12:44:21PM -0600, John Goerzen wrote:
> On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote:
> > Hello,
> > A binNMU does not show up in the pts, since there are no source
> > changes.

> Hmm, I wonder if it would be possible for it to show up?  Since there
> are .changes files with binNMUs, and presumably also migration to
> testing statuses?

There are no wait periods and no bug checks for migrating binNMUs to
testing; only dependencies are checked.

That's one perceived advantage of using binNMUs.

> > > Does anybody know what is going on here?

> > http://lists.debian.org/debian-release/2007/02/msg00647.html

> That seems to explain it (I think).  Though I am still confused about
> why a binNMU is being used even though it is being rebuilt across all
> archs.  

Because the overhead of sending release-critical bugs to (in this case) 7
different maintainers, tracking those bugs, and eventually NMUing is much
greater than that of sending automated requests to the buildd maintainers
requesting binNMUs; because it's entirely possible that not all
architectures *will* need binNMUs in cases like this (e.g., pdns was
binNMUed on 4/12 archs); becaue no sourceful changes are actually required
-- just rebuilds.

It's been documented for some time that porters have the power to do binNMUs
of packages; mass-binNMUs are merely an extension of that.  In effect, what
I'm doing is /requesting/ binNMUs via wanna-build, it's still the buildd
maintainers who review, sign & upload the binaries after they've been
autobuilt.

> I maintain that anyone that uploads a package that is uninstallable *at
> the time of upload* needs something more than gentle encouragement.  To
> upload someone else's package and render it uninstallable is even more
> annoying.  To do that without ever even filing a bug, let alone posting
> info to the BTS about it, is even more so.

But in effect, there are no bugs here that need to be tracked; by
definition, if this were any bug that could be fixed in your package, it
wouldn't be suitable for a binNMU.

> Having said that, I would have sent a polite message in private to the
> person that made the uploads.  Only there is no record of that in the
> package or the QA system.

The number of people who are going to be doing this sort of binNMU is
limited -- there are a handful of people who have wanna-build access for all
archs, and only two (Ryan Murray and myself) who I know actively use it for
scheduling binNMUs.  Of course, any porter/buildd maintainer might schedule
a one-off binNMU for their architecture, and if it goes via autobuilder you
might still have this problem of unchecked dependencies in a package being
uploaded.

> * The upload violated policy section 4.4, in that the maintainer name
>   and the email address of the *person* uploading the version do not
>   appear in the changelog.

In fact, each upload *does* include information about the source of the
upload, by way of the autobuilder; since there is no source upload, the only
uploads are the binaries (hence binNMU), and for each binary the uploader is
different.

I see that not all of the changelogs include a valid email address.  Well,
the buildd maintainers can be reached at @buildd.debian.org in that
case.  This seems like it would be good to document in that section of the
devref.

> Since this was a binNMU that effectively seems to have hit all archs, it
> seems that the regular NMU requirements should apply, too (Devref sec
> 5.11.1):

Well, they don't; that section addresses sourceful NMUs (and says exactly
that in 5.11), which this was not.  But, ok:

> * Make sure that the bug being fixed is in the BTS

There was no bug in the package, only in the build environment where the
packages had been built, so what should be put in the BTS?

> * Wait for maintainer reaction

What reaction should we wait for?  Maintainers don't do porter uploads;
porters do.

> * Take responsibility for bugs you've introduced

Well, the primary bug here is that bacula wasn't binNMU-safe.  That bug
wasn't introduced by the binNMUs themselves. :)

Be that as it may, I certainly would have taken responsibility for the
broken binary packages, but I'm afraid you fixed it before I had any
opportunity to do so.

> If you break something, you fix it.  Not make someone else spend time
> figuring out what changed, why, by whom, and fix it.

Ok, next time please leave me something to fix... ;)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: I *love* goodbye-microsoft.com

[paddy]

On Sat, Feb 24, 2007 at 05:37:56PM +1100, Russell Coker wrote:
> On Friday 23 February 2007 19:58, [EMAIL PROTECTED] wrote:
> > perhaps you should consider goodbye-fedora.org too ;-)
> 
> Converting from Fedora to Debian is not a challenge, merely run debootstrap 
> from a root shell.
> 
> Also Fedora isn't the enemy.  In fact there's a lot of code sharing between 
> Fedora and Debian (more than just shared upstream) and I am not the only 
> person to have been both a Fedora and Debian developer at the same time (now 
> I am only a DD).

Apologies for any confusion, I had just come from reading the slashdot
headlines :-)

Putting my serious (read: saturday morning waffle) hat on ...

It is many years now since I switched from redhat to debian, and at the
time I did so I regarded debian as more-or-less just another
distribution.  Looking back in the other direction now, I see redhat as
a commercial distribution, debian's greatest strength as it's people and
social contract, and fedora (and I came to debian before fedora
and haven't paid that much attention to fedora) as hobbled by it's
client status to redhat, which is a shame because I had hoped when
fedora came about it might have the independence to truly rival debian,
and redhat have some truly excellent people.

One of the things that strikes me as odd in debian is the dynamic
between diversity and hierarchy.  debian admits mulitple packages which
do more-or-less the same things, where a smaller distribution might say
"we'll have one MTA, one webserver, ...". This is a huge strength, and
feels very welcoming. At the same time there are any number of areas
where the *tendency* is more towards "there can be only one". An example
might be the way that dpkg handles package names and versions as
compared to rpm (name unique vs name/version unique).  I pick this
example precisely because I find it a conundrum, not because I think
there is any easy answer, but I note the tendency of humankind in
general to value their existing choices. Other examples of the tendency
might be "one maintainer per package", "one release", "one repository".
Note that all of these are just tendencies, it's not hard to find the
counter-examples, and on the whole these tendencies exist for entirely
commonsense reasons.  Perhaps commonsense is more about how to make 
things work (at all) than it is about what happens when they break.

The *users* of windows and the *users* of macosx are not the enemy
either.  Making it easier for users to see the full system is certainly
putting the best foot forward, and I admire the work being done. 

Strangely, I feel a tiny pang of guilt. I now have an apple box
for the first time in decades.  One of the main deciding factors was to
buy unixy goodness :-) but also to get some exposure to OSX. I tried for
a while to live in OSX, but in the end I installed Debian on it. It's
not that I couldn't build everything I wanted, it's just that not having
everything just work is like going back in time ten years. It's not that
there isn't ports or fink, but there isn't debian, short of a full
install, and the alternatives don't measure up.  It's not that I
couldn't take debian to osx (in my fevered imagination), it's that I'm
too lazy to even try.  But it could be done, it probably wouldn't be
terribly hard.  And I can't help wondering if this isn't another area
where debian has a tendency, a tendency to be all or nothing.

(and of course, that's not a one-sided story: this isn't exactly the
most free-software-friendly hardware ever made, and it seems that there's
no such thing as a sun jre binary for linux ppc, although hopefully that 
will be changing)

So, why shouldn't the users of Fedora, or even say Ubuntu, be invited 
to upgrade to Debian ?!

They are certainly not the enemy and I'm sure they would be made
welcome, even esr ;-)

Regards,
Paddy


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

Re: Where did Bacula 1.38.11-7+b1 come from?

[Steve Langasek]

On Thu, Feb 22, 2007 at 07:36:23PM -0600, John Goerzen wrote:
> On Fri, Feb 23, 2007 at 12:13:07AM +0100, Wouter Verhelst wrote:
> > > binNMUs though.  Aren't buildds simply there to build the existing
> > > sources on other platforms?  Surely some human was involved here?

> > wanna-build and buildd have been modified a while back to be able to do
> > binNMU's. The only human involvement is when a given package is marked
> > in the database as 'requires a binNMU', and when the buildd admin later
> > signs the package, as usual.

> Would it be possible to record the name of the human that marked the
> package in debian/changelog?  That would be a big help, I think (and
> hopefully avoid a discussion on debian-devel next time it happens)

Not easily, with the available tools; there's no good mapping even from a
wanna-build 'user' to a name/email, so practically speaking the user of w-b
would have to manually include their own name in the changelog entry being
specified.

> Probably requiring more work, but I wonder if it would be possible for
> the buildd -- or perhaps katie -- to verify that binNMUs don't render
> previously-installable packages uninstallable?

Well, that would be nice, but uploads of uninstallable packages have been a
problem for a long time (not just in binNMUs), and no one's implemented such
a check yet.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: I *love* goodbye-microsoft.com

[Amaya]

Russell Coker wrote:
> On Friday 23 February 2007 19:58, [EMAIL PROTECTED] wrote:
> > perhaps you should consider goodbye-fedora.org too ;-)
> 
> Converting from Fedora to Debian is not a challenge, merely run
> debootstrap from a root shell.

Alternatively, install debtakeover:
http://freshmeat.net/projects/debtakeover/
http://www.hadrons.org/~guillem/debian/debtakeover/README

-- 
  ·''`. If I can't dance to it, it's not my revolution
 : :' :-- Emma Goldman
 `. `'   Proudly running Debian GNU/Linux (unstable)
   `- www.amayita.com  www.malapecora.com  www.chicasduras.com


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

Re: Where did Bacula 1.38.11-7+b1 come from?

[Steve Langasek]

On Thu, Feb 22, 2007 at 07:36:23PM -0600, John Goerzen wrote:
> On Fri, Feb 23, 2007 at 12:13:07AM +0100, Wouter Verhelst wrote:
> > > binNMUs though.  Aren't buildds simply there to build the existing
> > > sources on other platforms?  Surely some human was involved here?

> > wanna-build and buildd have been modified a while back to be able to do
> > binNMU's. The only human involvement is when a given package is marked
> > in the database as 'requires a binNMU', and when the buildd admin later
> > signs the package, as usual.

> Would it be possible to record the name of the human that marked the
> package in debian/changelog?  That would be a big help, I think (and
> hopefully avoid a discussion on debian-devel next time it happens)

> Probably requiring more work, but I wonder if it would be possible for
> the buildd -- or perhaps katie -- to verify that binNMUs don't render
> previously-installable packages uninstallable?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Bug#412199: ITP: libssh2-perl -- Perl interface to the libssh2 library

[Mikhail Gusarov]

Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov <[EMAIL PROTECTED]>

* Package name: libssh2-perl
  Version : 0.09
  Upstream Author : David B. Robins <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~dbrobins/Net-SSH2-0.09/
* License : Artistic
  Programming Lang: Perl
  Description : Perl interface to the libssh2 library

Net::SSH2 is a perl interface to the libssh2 library. It supports the
SSH2 protocol (there is no support for SSH1) with all of the key
exchanges, ciphers, and compression of libssh2.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-openvz
Locale: LANG=C, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)


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

Re: Where did Bacula 1.38.11-7+b1 come from?

[sean finney]

On Sat, 2007-02-24 at 03:38 -0800, Steve Langasek wrote:
> On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote:
> > > (This problem was reported in bug #411652)
> 
> > > I think someone deserves a serious thwacking...  they obviously didn't
> > > even try to install the result of the NMU, filed no bug about it, etc.
> 
> > The bug is that a binNMU for bacula was scheduled although it is not
> > binNMU-able. Usually checking is done whether the package would break
> > before triggereing the rebuilt. Looks like this was missed this time.
> 
> Well, no; it wasn't missed, it just isn't done these days, because the
> fraction of the archive that's been fixed to be binNMU-safe is high enough,
> and the number of packages that get binNMUed is great enough, that it's
> simply more practical to binNMU and catch any breakage afterwards than to
> try to sniff out all possible failures in advance.

ftr, i've been on the recieving end of this, and it led to quite a bit
of confusion before i figured out what was going on.

if nobody wants to spend the time making sure it doesn't break
dependencies etc, maybe the folks responsible for binNMU'ing the
packages could put a little something at the end of the
process to throw an email to the package maintainers saying "hey, we
just binNMU'd your package, here's why and what you should check for..."
etc?


sean


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

Bug#412218: ITP: python-elixir -- Declarative Mapper for SQLAlchemy

[Piotr Ozarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ozarowski <[EMAIL PROTECTED]>

* Package name: python-elixir
  Version : 0.1.0
  Upstream Author : Jonathan LaCour, Daniel Haus, Gaetan de Menten <[EMAIL 
PROTECTED]>
* URL : http://elixir.ematia.de/
* License : MIT
  Programming Lang: Python
  Description : Declarative Mapper for SQLAlchemy

A declarative layer on top of SQLAlchemy. It is a fairly thin wrapper, which
provides the ability to define model objects following the Active Record
design pattern, and using a DSL syntax similar to that of the Ruby on Rails
ActiveRecord system.
.
Elixir does not intend to replace SQLAlchemy's core features, but instead
focuses on providing a simpler syntax for defining model objects when you do
not need the full expressiveness of SQLAlchemy's manual mapper definitions.
.
Elixir is intended to replace the ActiveMapper SQLAlchemy extension, and the
TurboEntity project.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)


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

Bug#412235: ITP: transfermii -- mii transfer program

[Romain Beauxis]

Package: wnpp
Severity: wishlist
Owner: Romain Beauxis <[EMAIL PROTECTED]>


* Package name: transfermii
  Version : 0.3.1
  Upstream Author : Arnaud Ysmal <[EMAIL PROTECTED]>
* URL : http://www.stacktic.org/
* License : GPL
  Programming Lang: C
  Description : mii transfer program


transfermii allows you to transfer your miis from and to your wiimotes.
I uses cwiid as a backend.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20-mactel-mactel
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)


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

Re: Bug#412235: ITP: transfermii -- mii transfer program

[Julien BLACHE]

Romain Beauxis <[EMAIL PROTECTED]> wrote:

>   Description : mii transfer program
>
> transfermii allows you to transfer your miis from and to your wiimotes.
> I uses cwiid as a backend.

Please enhance the short description, making it clear that this
package is related to the wiimotes.

At first I thought it was network-related.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Bug#412244: ITP: fldigi -- digital modem program for hamradio operators

[Joop Stakenborg]

Package: wnpp
Severity: wishlist
Owner: Joop Stakenborg <[EMAIL PROTECTED]>


* Package name: fldigi
  Version : 1.30
  Upstream Author : Dave Freese <[EMAIL PROTECTED]>
* URL : http://www.w1hkj.com/Fldigi.html
* License : GPL
  Programming Lang: C++
  Description : digital modem program for hamradio operators

fldigi is a modem program which supports most of the digital modes used 
by hamradio operators today. You can also use the program for 
calibrating your sound card to WWV or doing a frequency measurment test. 
The program also comes with a CW decoder. fldigi is written with the 
help of the fltk toolkit.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)


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

wodim compatibility with external programs

[Thanatermesis - Elive]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

wodim replaces cdrecord and the external applications like gnomebaker
and bonfire uses it correctly with the wodim patch, but those
applications needs also to uses 'readom' instead of 'readcd', if not,
you can't make a image of a DVD for example, with a error like

** (gnomebaker:10324): WARNING **: exec_spawn_process - failed to
spawn process [8] [Failed to execute child process "readcd" (No existe
el fichero o el directorio)]

Then, the patche's called *wodim* for those applications needs to be
are updated for use readom instead of readcd too



Thanks
Thanatermesis

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF4KlHisTnwngKr/ARAiWLAKCJYa7rtohIiocpzsh/XkqrsrmcPwCgj4xv
0FpML2UZdzwTyI3ve5QHZIE=
=qbGk
-END PGP SIGNATURE-


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

Bug#412248: ITP: fvs -- Fingerprint Verification System

[Miguel Gea Milvaques]

Package: wnpp
Severity: wishlist
Owner: Miguel Gea Milvaques <[EMAIL PROTECTED]>

* Package name: fvs
  Version : 0.1.1
  Upstream Author : Jaap de Haan & Shivang Patel
* URL : http://fvs.sourceforge.net
* License : MPL
  Programming Lang: C
  Description : Fingerprint Verification System

 Fingerprint Verification System; an easy to use library that allows
 programmers to integrate fingerprint technology into their software
 without specific know-how. Fast, easy to use, and small; great for
 embedded systems.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)


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

Re: Looking for a temporary account on Alpha

[Steve Langasek]

On Fri, Feb 23, 2007 at 10:54:06AM +0100, Frank B. Brokken wrote:
> Falk Hueffner filed a bug (Bug#412003) against the 2.10 release of the Yodl
> package. He detected that the latest version did not run correctly on the
> Alpha (see, e.g.,
> http://buildd.debian.org/fetch.cgi?pkg=yodl&arch=alpha&ver=2.10-1&stamp=1171904919)

> The problem I'm now confronted with is that as far as I know nobody in my
> environment uses the Alpha running Debian Linux. So I wonder if there is a
> list member who *does* operate an Alpha and is willing and able to offer me a 
> (temporary) account so I can research the problem's cause.

Sorry, can't give you an account, but I can point at the broken code:

void gram_DEFINEMACRO()
{
register char *name;
size_t nargs;

parser_push_fun("DEFINEMACRO");

name  = parser_name_parlist(&parser,  true);

if (parser_number_parlist(&parser, (int *)&nargs, true) == SUCCESS)
{
char *def   = parser_parlist(&parser, COLLECT_SET);

if ((size_t)nargs > 9 + 26 + 26)  /* 1-9, a-z, A-Z*/
{
[...]

You can't take a variable of type size_t, pass its address to a function
that takes an argument of type int*, and count on getting a meaningful
result back.

Based on the usage in this function, I don't see any reason why it should be
size_t at all.  Changing nargs to an int is sufficient to fix the build
failure on my alpha.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: Looking for a temporary account on Alpha

[Frank B. Brokken]

Dear Steve Langasek, you wrote:
> 
> ... I can point at the broken code:
> 
> void gram_DEFINEMACRO()
> ...
> size_t nargs;
>  ...
> if (parser_number_parlist(&parser, (int *)&nargs, true) == SUCCESS)
>  ...
> if ((size_t)nargs > 9 + 26 + 26)  /* 1-9, a-z, A-Z*/
> 
> You can't take a variable of type size_t, pass its address to a function
> that takes an argument of type int*, and count on getting a meaningful
> result back.

Well, first of all, thanks for your help. I'm sure it'll solve the problem for
the time being. But I'm left with an uneasy feeling. On the one hand I know
that what you write is true in principle. But on the other hand, I'm curious
about what might be going on in the Alpha what apparently doesn't happen on
other architectures. What's a size_t in the Alpha? If it's not in fact an
unsigned int but something bigger then I understand what's happening. The
intention here is to use size_t in situations where the value is known to be
non-negative. So, it may very well be an initialization problem, which should
then also be solved by initializing nargs to 0 when it's defined.

So, maybe you could in addition to the already provided help provide me with
some additional bits of information? What's the size of a size_t as compared
to the size of an int on Alpha? And what happens if nargs is initialized to 0
when it's defined? 

Size_t was introduced in yodl's recent code to distinguish variables having
non-negative values from those having potentially negative values. But it's
possible that there are some situations (like the above) where I failed to
make the correct conversion from int to size_t. Maybe you can provide the
answers to my additional questions?

> Based on the usage in this function, I don't see any reason why it should be
> size_t at all.  Changing nargs to an int is sufficient to fix the build
> failure on my alpha.

For now, that's still amazing...

Thanks a lot for your help, so far!

Cheers,

-- 
Frank B. Brokken
Computing Center, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D  B19F DAC4 BE50 38C6 6170


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

Re: Looking for a temporary account on Alpha

[Steinar H. Gunderson]

On Sun, Feb 25, 2007 at 12:26:00AM +0100, Frank B. Brokken wrote:
> The intention here is to use size_t in situations where the value is known
> to be non-negative.

Why don't you simply use "unsigned int" or (equivalently) just "unsigned"?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Looking for a temporary account on Alpha

[Russ Allbery]

Frank B Brokken <[EMAIL PROTECTED]> writes:

> Well, first of all, thanks for your help. I'm sure it'll solve the
> problem for the time being. But I'm left with an uneasy feeling. On the
> one hand I know that what you write is true in principle. But on the
> other hand, I'm curious about what might be going on in the Alpha what
> apparently doesn't happen on other architectures. What's a size_t in the
> Alpha? If it's not in fact an unsigned int but something bigger then I
> understand what's happening.

size_t is 64 bits on the Alpha, whereas int is 32 bits.  (long is 64 bits,
as are pointers.)  This is a common pattern for 64-bit operating systems.

> The intention here is to use size_t in situations where the value is
> known to be non-negative. So, it may very well be an initialization
> problem, which should then also be solved by initializing nargs to 0
> when it's defined.

Writing a 32-bit value into the first half of a 64-bit variable (which is
what happens when you pass a size_t * as an int * and then write to it)
isn't guaranteed to get you anything useful regardless of how you
initialize it beforehand.  It's also a violation of the C aliasing rules,
which means that the compiler is permitted to mess with your code in ways
that might break because it's allowed to assume that you won't ever do
something like that.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Looking for a temporary account on Alpha

[Steinar H. Gunderson]

On Sat, Feb 24, 2007 at 03:35:15PM -0800, Russ Allbery wrote:
> Writing a 32-bit value into the first half of a 64-bit variable (which is
> what happens when you pass a size_t * as an int * and then write to it)
> isn't guaranteed to get you anything useful regardless of how you
> initialize it beforehand.

But in practice, it _might_ work on little-endian platforms (assuming the
upper half was somehow initialized to be zero), which may very well explain
why this was only seen on Alpha.

Of course, it should have given a compiler warning on _any_ platform, but I
guess it just wasn't heeded in this case.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Looking for a temporary account on Alpha

[Steve Langasek]

On Sun, Feb 25, 2007 at 12:26:00AM +0100, Frank B. Brokken wrote:
> Well, first of all, thanks for your help. I'm sure it'll solve the problem for
> the time being. But I'm left with an uneasy feeling. On the one hand I know
> that what you write is true in principle. But on the other hand, I'm curious
> about what might be going on in the Alpha what apparently doesn't happen on
> other architectures. What's a size_t in the Alpha? If it's not in fact an
> unsigned int but something bigger then I understand what's happening.

Yes, sizeof(size_t) = 8 on alpha, as it is on ia64 and amd64 as well,
whereas sizeof(int) = 4 on all Debian architectures.

> The intention here is to use size_t in situations where the value is known
> to be non-negative.

I don't see any reason why you should use size_t for that instead of
unsigned int.  size_t is intended for use in describing the size of objects
in memory, not just for anything you know should be non-negative.

> So, it may very well be an initialization problem, which should then also
> be solved by initializing nargs to 0 when it's defined.

Well, that would solve the problem for alpha, yes.  It would still be wrong
on big-endian 64-bit architectures.  Granted, powerpc64, sparc64, and s390x
aren't major targets for yodl, but in terms of overall correctness, it's
still non-portable to pass a size_t * where an int * is requested -- on a
big-endian arch, this ends up being a pointer to the high 32 bits, not the
low 32bits.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Roundcube

[Fernando M . M .]

Hello,

This is my first message to this list, so be nice :)

Althought i have already seen some old discussion about packing the webmail 
Roundcube (1) i have not found the package using the package search (2).

(1) http://www.roundcube.net
(2) 
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=roundcube&searchon=names&subword=1&version=all&release=all


Is someone working on it?

If not, I would like to work with it but i would need help from someone who has 
some experience since within those 3 years using Debian i never really worked 
with packing.

Thanks,

Fernando


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

Re: Roundcube

[gregor herrmann]

On Sat, 24 Feb 2007 23:27:26 -0200, Fernando M.M. wrote:

> Althought i have already seen some old discussion about packing the
> webmail Roundcube (1) i have not found the package using the
> package search (2).
[..]
> Is someone working on it?

Seems so:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333756
http://lists.debian.org/debian-webapps/2007/02/msg0.html
http://lists.debian.org/debian-mentors/2007/02/msg00098.html

HTH,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Nick Drake: Hanging on a Star


signature.asc
Description: Digital signature