Bug#706045: [pkg-fetchmail-maint] Bug#706045: help?

[Nico Golde]

Hi,
* Tomas Pospisek  [2013-04-25 11:29]:
> This bug being a RC blocker: is anyone of the fetchmail maintainers working 
> on 
> this bug ("mimedecode option drops last message line if it is unterminated")? 
> Shall I try to integrate the patch and do a NMU?
> *t

Feel free, otherwise I'll probably fix it next week. Sorry I'm traveling right 
now...

Cheers
Nico
-- 
Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0


pgpd2a8vm2ykA.pgp
Description: PGP signature

Bug#635616: Virtio interfaces have the speed to 0

[Hideki Yamane]

Hi,

On Sat, 20 Apr 2013 15:16:09 +0200
Laurent LEGENDRE  wrote:
> Hi, I have the same bug in squeeze and wheezy so I suppose it's not solved
> yet.

 I've tried to reproduce it, failed and succeeded.
 It means, one KVM environment returns proper value, and another returns 
 nothing. Both VM are sid, difference is failed one uses virtio network device.

 Please try to install ethtool and check it via
 
 # ethtool eth0 (or eth1)

 then, if your environment is sane, it returns many values. if not, it
 only send "Linkdetected: yes" to you. IMO, it's not net-snmp bug, but
 KVM and/or libvirt issue (because it cannot get any value from system).


> In the meanwhile, is there any workaround ?

 How about using e1000 for quest VM NIC, instead?


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


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

Bug#705339: RFP: python-pyephem -- scientific-grade astronomical computations for Python

[Paul Wise]

On Fri, 2013-04-26 at 07:44 +0200, Daniele Tricoli wrote:

> I will package it! I want to do something similar to you. :)

I'm not sure its the easiest library to package, I looked at the code
and there are some issues that are against Debian policy. It might be
better to look at one of the other python libraries for sunset/sunrise
calculation. There are a few, I suggest doing some web searching.

python-pyephem does more than that though and might be useful generally
for Debian Science stuff.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#705339: RFP: python-pyephem -- scientific-grade astronomical computations for Python

[Daniele Tricoli]

Hello Paul,

[CCing Andreas to get his opinion]

On Saturday 13 April 2013 18:13:36 you wrote:
> I would like to schedule some cron jobs relative to the time of sunset
> and sunrise at my current location, having this package in Debian would
> allow me to do that.

I will package it! I want to do something similar to you. :)

I have only one doubt: I'm a member of the DPMT, but this package maybe is 
more suitable under the umbrella of the Debian Science Team. If it's so, I 
will be happy to join the Debian Science Team and maintain python-pyephem 
under the umbrella of Debian Science Team.

Andreas what do you suggest?

Kind regards,

-- 
 Daniele Tricoli 'Eriol'
 http://mornie.org

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

Bug#706193: Compile against system libavcodec

[Reinhard Tartler]

Package: src:xbmc
Version: 2:12.0~git20130127.fb595f2-1
Severity: serious
Tags: patch

Hi Andres,

Please make the xmbc package in Debian compile against the system
libavcodec.  The necessary patches for that have been provided by Libav
upstream, namely Anton Khirnov (CC'ed):

http://git.khirnov.net/cgit.cgi/xbmc/

Cheers,
Reinhard


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise-proposed'), (500, 'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.5.0-27-generic (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

[Bernhard R. Link]

* Ben Longbons  [130425 18:27]:
> The problems with the way Debian does it are:
>   - debian/ is a subdirectory of the extracted source tree.

Why do you think that is a problem?

>   - Because of the above, debian/rules tries to know about backwards steps.

What are "backwards steps"?

>   - There are too many arcane commands that have to be called.

./debian/rules build
fakeroot ./debian/rules binary

Everything else is mostly convenience wrappers.

>   - It's not obvious how to modify the patch set directly.

modify upstream files, call dpkg-source --commit

>   - There is no attempt at managing multiple source versions.

First you say things are too complicated, then you complain about
some obscure missing option I never found any use case for.

> How Simple Tasks are approached:
>   Given a program that is not packaged for Debian and is not
>   sufficiently useful to the general public to be worth the maintenance
>   burden, install it such that the package manager knows about it.
> Debian:
>   - checkinstall is buggy, quirky, and has no upgrade path.
>   - I still haven't figured out how to do this easily. Based on the
> 'hello' package, which is the simplest possible package, this
> requires writing a hundred lines of voodoo. A random sampling of
> existing package I've looked at agrees with this as a lower bound.

You can't have easy and high-quality at the same time. Most of the tools
used for official Debian package have the minimal complexity needed for
some quality. Apart from having someone write tools to simply create
private packages there is not much that can be done here.
(and from what you describe for Gentoo, I do not really see how a
dh_make ; vim debian/* ; dpkg-buildpackage is more complicated than the
Gentoo case).


>   Given a completed set of package information for such a package,
>   distribute it in a way that is easy for others to install.
> Debian:
>   - Still haven't figured out the right way.

There are many ways, because needs are different.

>   - I did find the 'dget' command that does some things. How was I
> supposed to know about this obscure command for a common use case?

dget is simply a convenience wrapper. Just have three files to download
for a source package. Anyone can click at three links easily.

>   - You probably have to ship the whole huge .orig.tar.gz file, even
> though it's available on the internet under a different name, or
> even if it's really a git snapshot.

Sorry, but this is bullshit. If you want to make it easy for users, put
the .orig.tar.gz there. References too external resources will always go
stale and are and endless source of user frustration.

>   Given a program with a buggy upstream release, apply a patch.
> Debian:
>   - After trying to make local changes, it said: dpkg-source --commit
>   - But it is tedious when you already have a full patch from upstream.

patch -i patchfile ; dpkg-source --commit

I thought it was about users knowing the basic command line utilities?

>   Given a program with buggy Debian packaging, revert a patch.
> Debian:
>   - no clue, it keeps trying to readd the changes and it's not obvious
> how to wipe the working tree.

The very easy way: just revert the change and add another dpkg-source --commit
The direct way: revert the change, remove the line from debian/patches/series
The complicated way: use quilt or some other high-level tool.

>Gentoo:
>  - Assume that you're competent enough to get ahold of a patch.
>  - Add the patch to files/ (which is shared between all versions of
>the package, though you can of course use a different name).
>  - Add the filename to the PATCHES=() variable, remanifest.
>
> Gentoo:
>   - Remove the filename from the PATCHES=() variable, remanifest.

Yeah, because every patch can simply be removed without any effects on
the other patches, you can just apply any patches you need to the
version you need. And if it doesn't you can just apply manually, fix it
and produce a new clean patch. NOT, seriously.

That you can just do stuff in your working directory, build and fix
again iteratively in your working directory and finally have some
working package is in my eyes one of the biggest strengths of Debian's
package format w.r.t. low entrance and making it easy for unexperienced
people to use Debian to meed their needs.

> Gentoo:
>   - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest
>   - Typically, the source URL will automatically change based on the
> version number. If this is not the case, it is very obvious to fix.

your gentoo solution is the equivalent of copying the debian/ directory
around.

> In conclusion:
>   The current Debian way is complicated. The Gentoo way is simple. This is
>   not tied to the fact that Gentoo is a source-based distribution, although
>   that does enc

Bug#706192: unblock: phpmyadmin/4:3.4.11.1-2

[Thijs Kinkhorst]

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

Hi,

Please unblock package phpmyadmin.

This is a security update. The issues fixed are not present in squeeze.

unblock phpmyadmin/4:3.4.11.1-2


Thanks,
Thijs


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

Bug#706191: debian-installer: mirror/http/hostname should behave better when given http://hostname as an argument.

[dcooley]

Package: debian-installer
Severity: normal

Dear Maintainer,


   * What led up to the situation?
   
   When installing a new system via pxe. 
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   I specified mirror/http/hostname=http://mirrorurl.com 

   * What was the outcome of this action?

   This caused the system to fail in an obscure way. Saying that the repository 
was not usable.. When you check the log you see the following: 

Apr 25 23:49:37 main-menu[704]: DEBUG: resolver (libc6-udeb): package doesn't 
exist (ignored)  

Which is not the case at all. 



   * What outcome did you expect instead?

   I expect that having entered the http:// part in error there would be some 
validation on the string provided. I expect the installer would point out the 
problem or correct it. 


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

Bug#706131: MegaRAID SAS 2108 (Dell PERC H700) FW in FAULT state with old BIOS

[Jonathan Nieder]

reassign 706131 release-notes
tags 706131 + wheezy
retitle 706131 [squeeze->wheezy regression] LSI MegaRAID SAS 2108 (aka Dell 
PERC H700 RAID) requires firmware update
quit

Hi,

Bernhard Schmidt wrote:

>   I'm quite sure we also
> booted Squeeze sucessfully on it, but I'm going to verify that. They had 
> never received any firmware update, which made the main BIOS version
> 2.1.15 and the LSI BIOS 12.3.
>
> Wheezy (both RC1 and daily from April 22nd) could not be installed, 
> because it did not detect any disk. dmesg showed this (typed from
> a screenshot, excuse any errors)
>
> megasas: 00.00.06.12-rc1 Wed. Oct. 5 17:00:00 PDT 2011
> megasas: 0x1000:0x0079:0x1028:0x1f17: bus 3:slot 0:func 0
> megaraid_sas: :03:00.0: setting latency timer to 64
> megasas: Waiting for FW to come to ready state
> megasas: FW in FAULT state!!
[...]
> None of those workarounds listed in the bugs worked for us. After a 
> 2-hour session upgrading all the firmware on the system (which 
> bumped the BIOS to 6.something and LSI to 12.10) it worked just fine.

Thanks for reporting.  I'm reassigning this report to release-notes so
we can get this documented.  If you can think of some wording for
section 4.5 or 5 of the release notes[1], that would be excellent.

Hope that helps,
Jonathan

[1] http://www.debian.org/releases/wheezy/releasenotes


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

Bug#648160: util-vserver: wheezy vserver guests don't start

[Carlos Alberto Lopez Perez]

On 25/04/13 20:23, micah wrote:
> 
> Hi Carlos,
> 
> Carlos Alberto Lopez Perez  writes:
> 
>> So please: update the package to a newer upstream version.
> 
> util-vserver was removed from wheezy as was the kernel support. It is
> not surprising that this version doesn't work, it only worked with
> squeeze. At this stage, it will not be included in wheezy at all.
> 

I'm already aware of that. But that don't means that this should not be
fixed on sid isn't it?

> If you are interested in doing work on the user-space utilities in
> Debian, or doing the work to provide the support in the kernel, it would
> be welcome.
> 

In this case, upgrading the package to the newer upstream version is
quite easy.

I could provide a .dsc with the changes required if you want, but I
don't think I did nothing special about it. I just put the debian/
directory of the old package on the new upstream tarball, updated the
changelog and cleaned debian/patches/*

> With your permission, I'd like to close this bug.
> 

I don't think this is an appropriate approach to deal with this problem.
I rather would ask you to remove the package util-vserver from Debian
sid completely than to have it in a broken state.

Thanks for your understanding.



signature.asc
Description: OpenPGP digital signature

Bug#664407: [PATCH] array-info: Helping to update to packaging format 3.0

[Jari Aalto]

| > If you find anything to adjust in the proposed NMU patch, see:
| >
| >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664407
| >
|
| This looks fine.
|
| Actually, I don't use array-info anymore. Would you like to take over
| the maintenance of this package?

Just to confirm,

Do you wish that package should be set to the QA group on upload, or
handled only as a NMU?

Thanks Raphaël,
Jari


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

Bug#585122: (no subject)

[Sergei Golovan]

Hi!

On Fri, Apr 26, 2013 at 2:37 AM, Roland Hieber  wrote:
> Cool, not so intuitive like a command-line option, but definitely a step
> in the right direction. Thanks for the info!

epmd is rarely called directly from a command line. Usually, some
distributed Erlang application executes it if it isn't listening on
port 4369.

Cheers!
--
Sergei Golovan


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

Bug#706170: xosview: platform detection improvement/fix in debian/rules

[Kartik Mistry]

On Fri, Apr 26, 2013 at 2:05 AM, Pino Toscano  wrote:
> the changes in the experimental version still make xosview compiled as
> "linux" even in non-Linux OSes, and never uses the right platform
> string on kFreeBSD.
> The attached patch factorizes the detection of the platform string
> to use when invoking make,
> - making it use the right one on kFreeBSD (which though won't compile
>   yet, and that will need proper fixes)
> - bailing out when the OS is not recognized, and it is easy (just add
>   the two proper lines in that if chain, e.g. starting from the
>   kfreebsd ones) to add cases for new OSes

Thanks a lot. I was about to commit my fix in git repo (and also
realized that kfreebsd build is not yet ready!), but your patch is way
much better. Committed to git repo. I'll disable kfreebsd-* build and
upload in a day or two.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


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

Bug#612610: lintian: should suggest switching to 3.0 (quilt)

[Russ Allbery]

Ron  writes:

> Since there were strong arguments against this in the past, from more
> than one person, and since nothing has changed since, including members
> of the release team from time to time still voicing their
> dissatisfaction with the 3.0 quilt format and intent to continue not
> using it, it doesn't seem like simply "having the same debate all over
> again" is going to be very productive unless "hope the people who
> objected last time can't be bothered repeating themselves" is considered
> "productive".

> Maybe it would be better if the people who want to push this actually go
> and review the objections from last time, and come up with a new format,
> or with changes to this one that actually ameliorate the objections that
> were already made.

I believe this has already been done to some extent, speaking as one of
the people who stayed with 1.0 at the time of the previous format.  The
addition of single-debian-patch and local-options resolved my concerns.

I would like to see this raised on debian-devel again because I think two
things have changed with time, not because I'm just hoping that people
won't repeat the same arguments and a different argument might win by
default.  (And, besides, how long have you watched debates in this
project?  :)  Since when do we ever leave any argument to win by default?)

First, the addition of those options, which may not be common knowledge,
makes 3.0 (quilt) fairly close from a packager's perspective to 1.0,
except with cleaner separation in the source package format between the
Debian files and the upstream files, support for good compression formats
(I'm now using xz for basically everything, since it's pretty much
superior to gzip and bzip2 in all respects and is being actively
recommended by at least one upstream maintainer of gzip), and a fix for
the ambiguity between native and non-native packages.

Second, some (not all, but some) arguments against 3.0 (quilt) seemed like
arguments against how Raphael presented it, arguments against the way it
was being discussed, or arguments from a position of lack of benefit.
Those things tend to change over time.  We've now had it for some years,
more people have had a chance to try using it, some of the edges have been
smoothed over, it's clearly not going anywhere (whether one was
unconvinced of the initial benefits or not), and irritation from previous
discussions has subsided.  I think there's a substantial possibility that
this could have resulted in people quietly changing their minds, or at
least being open to changing their minds.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#612610: lintian: should suggest switching to 3.0 (quilt)

[Ron]

On Mon, 22 Apr 2013 08:51:26 +0200, Stefano Zacchiroli wrote:
> The devil is in your quotes here :) The point here, I think, is that in
> a project as large as Debian you will always find "somebody" that
> disagrees with a specific "new" practice. Unfortunately that practice
> might be beneficial for everyone else. In fact, this is the classical
> reason why we generally insist on "rough consensus" as opposed to
> "unanimity".

Speaking of devils in quotes, here's a devil of a quote on the topic of
"rough consensus", a practice long been honed by the IETF, which seems
equally relevant here, and captures the core essence of it succinctly:

 As Dave Crocker[1] is fond of pointing out, it is possible to have 99
 people in support of a position and one standing against, and still fail
 to meet the IETF's standard for "rough consensus." All it takes is the
 failure of those 99 people to engage the arguments put forth by the one
 outlier. Correspondingly, you can have 50 people on one side of an
 issue, 50 on the other, and still have a clear consensus if one side is
 merely stating a position, while the other is offering up unanswered
 arguments.

 [1] For those of you unfamiliar with Dave Crocker's tenure in the IETF,
 I call your attention to the date and attendee list on the following
 proceedings: http://www.ietf.org/proceedings/04.pdf


Since there were strong arguments against this in the past, from more
than one person, and since nothing has changed since, including members
of the release team from time to time still voicing their dissatisfaction
with the 3.0 quilt format and intent to continue not using it, it doesn't
seem like simply "having the same debate all over again" is going to be
very productive unless "hope the people who objected last time can't be
bothered repeating themselves" is considered "productive".

Maybe it would be better if the people who want to push this actually go
and review the objections from last time, and come up with a new format,
or with changes to this one that actually ameliorate the objections that
were already made.

That might achieve beneficial progress in a way that simply having the
same argument every few years (with no change to address the previous
objections) is unlikely to.


Saying "lots of people now use ipods" doesn't do anything to change the
measurable fact that their earbuds are both technically and audibly
lousy, and are ridiculed by more discerning users.  Handwaving away the
concerns of those people as them being "in the minority" isn't going to
improve things like actually addressing the problems they noted would.
The same (lack of) proof by critical mass applies here too.

I'd much rather see a better format emerge from this disagreement than
people continually lobbying for change for change sake, without ever
changing the actual problems over which there is disagreement.

  Ron


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

Bug#706190: python-daemon doesn't install to /usr/lib/python*

[Dave Steele]

Package: python-daemon
Version: 1.5.5-1
Severity: important
thanks

After installation to sid, the python-daemon modules is not becoming
visible under any of the installed Python /usr/lib directories. Python
versions 2.6, 2.7, and a pair of 3's are installed.


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

Bug#706183: [Aptitude-devel] Bug#706183: "WARNING: untrusted versions of the following packages will be installe vague

[Daniel Hartwig]

On 25 April 2013 21:16, Nomen Nescio  wrote:
> Package: aptitude
> Version: 0.6.3-3.2+squeeze1
> Severity: wishlist
>
> The following warning is too vague:
>
> vague warning> WARNING: untrusted versions of the following packages will be 
> installed!
> vague warning>
> vague warning> Untrusted packages could compromise your system's security.
> vague warning> You should only proceed with the installation if you are 
> certain that
> vague warning> this is what you want to do.
> vague warning>
> vague warning>   libswscale0 libavutil50 libdrm-radeon1 libdrm2 libvpx0 
> libdrm-intel1 libpostproc51
> vague warning>
> vague warning> Do you want to ignore this warning and proceed anyway?
>
> Why is it untrusted?  Are the keys missing from the users keyring?
> Are the keys present, but expired? Are the packages signed or
> unsigned?
>

What difference the distinction make?  If the key is not present,
valid, and the packages signed, they are untrusted.

This general warning is sufficient to alert the local admin to a
problem, which they can investigate.  It is not expected to be common,
and if the warning persists then the system is misconfigured.

The alternative is to group the untrusted packages by the one or
multiple underlying causes, which may involve e.g. multiple different
expired keys.  Now that is a long winded and complex dialog, with very
little benefit as it is trivial to investigate the cause outside of
aptitude.


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

Bug#612402: Search to Find Affected fstab lines?

[Nick M . Daly]

Hi folks, is there a known grep (or similar) command to identify
affected /etc/fstab files before the wheezy upgrade?

If an affected file is found, what is an appropriate clean up?

For example, I found the following in my own /etc/fstab and, having read
this bug from top to bottom, am still unclear whether or not I am
affected.  Are only "^root=UUID=" lines affected, or are "UUID=" lines
also affected?

/etc/fstab:

# /boot was on /dev/sda1 during installation
UUID=130c3014-afa2-4c10-9ab0-bdbfccb61aaf /boot   ext2defaults  
  0   2

Thanks for your time and help,
Nick


pgpWcNlvoGtP6.pgp
Description: PGP signature

Bug#706189: conspy: remove file debian/build-arch-stamp and remove from rules

[Russell Stuart]

Package: conspy
Version: 1.8-2
Severity: minor

build-arch-stamp is cruft left over from a previous verison.  It should
be removed.

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

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

Versions of packages conspy depends on:
ii  libc62.13-38
ii  libncurses5  5.9-10
ii  libtinfo55.9-10

conspy recommends no packages.

conspy suggests no packages.

-- no debconf information


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

Bug#706188: github-cli: missing dependency on git

[Paul Wise]

Package: github-cli
Version: 1.0.0-1
Severity: serious
Justification: missing dep

If I run ghi in a minimal chroot, it fails because git is not installed:

$ ghi -r git-bzr-ng
/bin/sh: 1: git: not found

The solution is simply to add git to the dependencies but most users of
this package will already have git installed so it isn't going to affect
many folks.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (550, 'experimental')
Architecture: amd64 (x86_64)

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

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#706187: github-backup broken by API changes at github

[Paul Wise]

Package: github-backup
Version: 1.20120627+b1
Severity: grave
Justification: renders package unusable

github recently added a requirement that users of the API set a
User-Agent header. github-backup doesn't appear to set such a header and
so it is no longer useable.

It would be nice if the header were setable by the user.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (550, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages github-backup depends on:
ii  libc6 2.13-38
ii  libffi5   3.0.10-3
ii  libgmp10  2:5.0.5+dfsg-2
ii  zlib1g1:1.2.7.dfsg-13

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#706167: qimhangul-qt4: improper alternative handling in M-A:same package

[RYU Changwoo]

Such this problem happens in all multi-arch packages which have
maintainer scripts.

Is there a general solution except splitting packages?


2013/4/26 Andreas Beckmann :
> Package: qimhangul-qt4
> Version: 0.2.0-2
> Severity: serious
>
> Hi,
>
> qimhangul-qt4 is marked Multi-Arch: same, but it does not handle the
> alternative properly, see the following sequence
>
>   apt-get install qimhangul-qt4:amd64
>   # registers the alternative
>
>   apt-get install qimhangul-qt4:i386
>   # registers the alternative again, which is a no-op
>
>   apt-get remove qimhangul-qt4:i386
>   # removes the alternative even though qimhangul-qt4:amd64 is still
>   # installed
>
> >From the attached log (scroll to the end):
>
> 0m32.5s ERROR: FAIL: After purging files have disappeared:
>   /etc/X11/xinit/xinput.d/ko_KR -> /etc/alternatives/xinput-ko_KR not owned
>   /etc/alternatives/xinput-ko_KR -> /etc/X11/xinit/xinput.d/qimhangul-qt4 
>not owned
>
>
> Andreas


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

Bug#706181: libpng12-dev: ldconfig plays ping-pong with /usr/lib//libpng12.so.0

[Aníbal Monsalve Salazar]

I'm preparing a new Debian package with Andreas' patch.


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

Bug#706186: wims-moodle: modifies conffiles (policy 10.7.3): /etc/moodle/wimsconf.php, /usr/share/moodle/mod/assignment/type/wims/wimsconf.php

[Andreas Beckmann]

Package: wims-moodle
Version: 4.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies conffiles.
This is forbidden by the policy, see
http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

10.7.3: "[...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time)."

Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).

Further in 10.7.3: "[...] must not ask unnecessary questions
(particularly during upgrades) [...]"

If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also http://wiki.debian.org/DpkgConffileHandling

In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

debsums reports modification of the following files,
from the attached log (scroll to the bottom...):

2m29.9s ERROR: FAIL: debsums reports modifications inside the chroot:
  /usr/share/moodle/mod/assignment/type/wims/wimsconf.php
  /etc/moodle/wimsconf.php


(/usr/share/moodle/mod/assignment/type/wims/wimsconf.php is not a
conffile, but modifying is is not allowed either)


cheers,

Andreas


wims-moodle_4.0-3.log.gz
Description: GNU Zip compressed data

Bug#706185: libpam-ldap: purging one architecture of this M-A:same package removes configuration still needed by the other architectures

[Andreas Beckmann]

Package: libpam-ldap
Version: 184-8.6
Severity: serious

Hi,

libpam-ldap is a Multi-Arch: same package with shared pam configuration
between all installed architectures of this package. Problems arise if
more than one architecture of the package was installed and one
architecture gets purged while one or more other architectures stay
installed (or are in config-files-remaining state): the configuration
gets deleted while other architectures still need it.

Consider the following sequence:

  apt-get install libpam-ldap:amd64
  apt-get install libpam-ldap:i386
  dpkg --purge libpam-ldap:i386

Thereafter the pam configuration originally set up by libpam-ldap:amd64
is gone.

>From the attached log, scroll to the bottom:

0m25.3s ERROR: FAIL: After purging files have disappeared:
  /etc/pam_ldap.conf not owned

0m25.3s ERROR: FAIL: After purging files have been modified:
  /etc/pam.d/common-account  not owned
  /etc/pam.d/common-auth not owned
  /etc/pam.d/common-password not owned
  /etc/pam.d/common-session  not owned
  /etc/pam.d/common-session-noninteractive   not owned
  /var/lib/pam/account   not owned
  /var/lib/pam/auth  not owned
  /var/lib/pam/password  not owned
  /var/lib/pam/seen  not owned
  /var/lib/pam/session   not owned
  /var/lib/pam/session-noninteractivenot owned


cheers,

Andreas


libpam-ldap=184-8.6.log.gz
Description: GNU Zip compressed data

Bug#706184: ITP: freedv -- Digital Voice for HF

[A. Maitland Bottoms]

Package: wnpp
Severity: wishlist
Owner: "A. Maitland Bottoms" 

* Package name: freedv
  Version : 0.96r1235
  Upstream Author : David Rowe VK5DGR , Dave Witten 

* URL : http://freedv.org
* License : LGPL-2.1
  Programming Lang: C++
  Description : Digital Voice for HF

FreeDV is a GUI application that allows any SSB radio to be used for
low bit rate digital voice.

Speech is compressed down to 1400 bit/s then modulated onto a 1100 Hz
wide QPSK signal which is sent to the Mic input of a SSB radio. On
receive, the signal is received by the SSB radio, then demodulated and
decoded by FreeDV.

FreeDV was built by an international team of Radio Amateurs working
together on coding, design, user interface and testing. FreeDV is open
source software, released under the GNU Public License version
2.1. The FDMDV modem and Codec 2 Speech codec used in FreeDV are also
open source.

Why FreeDV?

Amateur Radio is transitioning from analog to digital, much as it
transitioned from AM to SSB in the 1950's and 1960's. How would you
feel if one or two companies owned the patents for SSB, then forced
you to use their technology, made it illegal to experiment with or
even understand the technology, and insisted you stay locked to it for
the next 100 years? That's exactly what was happening with digital
voice. But now, hams are in control of their technology again!

FreeDV is unique as it uses 100% Open Source Software, including the
audio codec. No secrets, nothing proprietary! FreeDV represents a path
for 21st century Amateur Radio where Hams are free to experiment and
innovate, rather than a future locked into a single manufacturers
closed technology.

I've been builing packages while trying to keep up with
active development, and it is time for better availability
of packaged versions to facilitate testing by early adopters.

Expect the initial series of uploads to go into Debian experimental.
The Lintian warning count is low, but the upstream developers
expect some incompatible protocol changes between versions
for the near future.

-Maitland


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

Bug#706183: "WARNING: untrusted versions of the following packages will be installe vague

[Nomen Nescio]

Package: aptitude
Version: 0.6.3-3.2+squeeze1
Severity: wishlist

The following warning is too vague:

vague warning> WARNING: untrusted versions of the following packages will be 
installed!
vague warning>
vague warning> Untrusted packages could compromise your system's security.
vague warning> You should only proceed with the installation if you are certain 
that
vague warning> this is what you want to do.
vague warning>
vague warning>   libswscale0 libavutil50 libdrm-radeon1 libdrm2 libvpx0 
libdrm-intel1 libpostproc51 
vague warning>
vague warning> Do you want to ignore this warning and proceed anyway?

Why is it untrusted?  Are the keys missing from the users keyring?
Are the keys present, but expired?  Are the packages signed or
unsigned?

-- Package-specific info:
aptitude 0.6.3 compiled at Aug 10 2011 23:28:10
Compiler: g++ 4.4.5
Compiled against:
  apt version 4.10.1
  NCurses version 5.7
  libsigc++ version: 2.2.4.2
  Ept support enabled.
  Gtk+ support disabled.

Current library versions:
  NCurses version: ncurses 5.7.20100313
  cwidget version: 0.5.16
  Apt version: 4.10.1
linux-vdso.so.1 =>  (0x7fff787ff000)
/usr/lib/torsocks/libtorsocks.so (0x7f7134617000)
libapt-pkg.so.4.10 => /usr/lib/libapt-pkg.so.4.10 (0x7f71342fd000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0x7f71340a9000)
libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x7f7133ea4000)
libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0x7f7133bd8000)
libept.so.1 => /usr/lib/libept.so.1 (0x7f7133983000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7f71335a3000)
libz.so.1 => /usr/lib/libz.so.1 (0x7f713338c000)
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x7f71330f4000)
libboost_iostreams.so.1.42.0 => /usr/lib/libboost_iostreams.so.1.42.0 
(0x7f7132ed9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7f7132cbd000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f71329a8000)
libm.so.6 => /lib/libm.so.6 (0x7f7132726000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f713251)
libc.so.6 => /lib/libc.so.6 (0x7f71321ad000)
libdl.so.2 => /lib/libdl.so.2 (0x7f7131fa9000)
libresolv.so.2 => /lib/libresolv.so.2 (0x7f7131d93000)
libutil.so.1 => /lib/libutil.so.1 (0x7f7131b8f000)
libuuid.so.1 => /lib/libuuid.so.1 (0x7f713198b000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x7f713177a000)
librt.so.1 => /lib/librt.so.1 (0x7f7131572000)
/lib64/ld-linux-x86-64.so.2 (0x7f7134827000)
Terminal: screen
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

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

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

Versions of packages aptitude depends on:
ii  apt [libapt-pkg4.10]   0.8.10.3+squeeze1 Advanced front-end for dpkg
ii  libboost-iostreams1.42 1.42.0-4  Boost.Iostreams Library
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libcwidget30.5.16-3  high-level terminal interface libr
ii  libept11.0.4 High-level library for managing De
ii  libgcc11:4.4.5-8 GCC support library
ii  libncursesw5   5.7+20100313-5shared libraries for terminal hand
ii  libsigc++-2.0-0c2a 2.2.4.2-1 type-safe Signal Framework for C++
ii  libsqlite3-0   3.7.3-1   SQLite 3 shared library
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  libxapian221.2.3-2   Search engine library
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

Versions of packages aptitude recommends:
ii  apt-xapian-index  0.41   maintenance and search tools for a
pn  aptitude-doc-en | aptitude-do  (no description available)
ii  libparse-debianchangelog-perl 1.1.1-2.1  parse Debian changelogs and output
ii  sensible-utils0.0.4  Utilities for sensible alternative

Versions of packages aptitude suggests:
pn  debtags(no description available)
ii  tasksel   2.88   Tool for selecting tasks for insta

-- 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#576301: tsocks: fails if socksified application uses poll(2) (e.g. subversion-1.5)

[Julien Moutinho]

Package: tsocks
Version: 1.8beta5-9.2
Followup-For: Bug #576301

Hi,

Ingo's patch is correct according to my understanding of tsocks' dirty code,
note that there also is a related copy/paste error from select() a few lines 
above,
which causes a supplementary poll(_, POLLOUT, _) call.

An updated fix is contained in the attached patch.
Please include.
--- a/tsocks.c
+++ b/tsocks.c
@@ -659,10 +659,11 @@
  * be ready for writing), otherwise we'll just let the select loop
  * come around again (since we can't flag it for read, we don't know
  * if there is any data to be read and can't be bothered checking) */
-if (conn->selectevents & WRITE) {
-   setevents |= POLLOUT; 
+if (conn->selectevents & POLLOUT) {
+   ufds[i].revents |= POLLOUT;
nevents++;
 }
+ufds[i].events = conn->selectevents;
  }
   }
} while (nevents == 0);

Bug#706172: antlr3 attempts to install files in /usr/share/maven-repo on building (FTBFS)

[Emmanuel Bourg]

Severity: important

After further investigation, this only happens if the antlr3 package is
already installed on the system.

'mvn install' is called during the build and tries to install the
artifacts in the Maven repository in debian/maven-repo. This repository
created by /usr/share/maven-debian-helper/copy-repo.sh contains absolute
symlinks to /usr/share/maven-repo.


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

Bug#706182: libnss-ldap: purging deletes shared config file /etc/libnss-ldap.conf still in use by other architectures

[Andreas Beckmann]

Package: libnss-ldap
Version: 264-2.5
Severity: serious

Hi,

libnss-ldap has been converted to Multi-Arch: same, but manages the
configuration file /etc/libnss-ldap.conf that is now shared between all
installed architectures of the libnss-ldap package.

The problem arises during purge: the configuration file is deleted even
if there are still other architectures installed (or in
config-files-remaining state) that share the ownership on that file.

>From the attached log (scroll to the bottom), observed during the
following sequence:

  apt-get install libnss-ldap:amd64
  apt-get install libnss-ldap:i386
  dpkg --purge libnss-ldap:i386

0m25.8s ERROR: FAIL: After purging files have disappeared:
  /etc/libnss-ldap.conf  not owned


Andreas


libnss-ldap=264-2.5.log.gz
Description: GNU Zip compressed data

Bug#706181: libpng12-dev: ldconfig plays ping-pong with /usr/lib//libpng12.so.0

[Andreas Beckmann]

Package: libpng12-dev
Version: 1.2.49-1
Severity: important
Tags: patch

Hi,

libpng12-dev may cause ldconfig to play ping-pong with
/usr/lib//libpng12.so.0 - that file is not shipped, but since
it is the SONAME of the library shipped as
/usr/lib//libpng12.so (and /usr/lib//libpng.so) 
ldconfig will create the symlink
/usr/lib//libpng12.so.0 -> libpng.so
While this points to the correct file and the link is not really
needed, this looks a bit strange.

I'm attaching a patch to switch the links to
/usr/lib//libpng12.so -> libpng12.so.0 -> /lib//libpng12.so.0
that will prevent ldconfig from creating the missing SONAME link.

I've also seen this link disappear during some experiments with MA:same
package installations, although that should not happen ...

Shipping the SONAME link in /usr/, too, will make the behavior
deterministic and independent from the time ldconfig is run.


Andreas
diff -Nru libpng-1.2.49/debian/changelog libpng-1.2.49/debian/changelog
--- libpng-1.2.49/debian/changelog	2012-08-28 09:26:22.0 +0200
+++ libpng-1.2.49/debian/changelog	2013-04-26 00:37:59.0 +0200
@@ -1,3 +1,12 @@
+libpng (1.2.49-3.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * libpng12-dev: Ship /usr/lib/${DEB_HOST_MULTIARCH}/libpng12.so.0 ->
+/lib/${DEB_HOST_MULTIARCH}/libpng12.so.0 symlink, too, to prevent ldconfig
+from playing ping-pong with the SONAME link.  (Closes: #xx)
+
+ -- Andreas Beckmann   Fri, 26 Apr 2013 00:33:36 +0200
+
 libpng (1.2.49-3) unstable; urgency=low
 
   * Remove patches/02-681408-CVE-2012-3386-Makefile.in.patch.
diff -Nru libpng-1.2.49/debian/libpng12-dev.links.in libpng-1.2.49/debian/libpng12-dev.links.in
--- libpng-1.2.49/debian/libpng12-dev.links.in	2011-07-18 13:52:43.0 +0200
+++ libpng-1.2.49/debian/libpng12-dev.links.in	2013-04-26 00:32:55.0 +0200
@@ -1,3 +1,4 @@
 /usr/share/man/man1/libpng12-config.1.gz /usr/share/man/man1/libpng-config.1.gz
 /usr/include/libpng12 /usr/include/libpng
-/lib/${DEB_HOST_MULTIARCH}/libpng12.so.0 /usr/lib/${DEB_HOST_MULTIARCH}/libpng12.so
+/lib/${DEB_HOST_MULTIARCH}/libpng12.so.0 /usr/lib/${DEB_HOST_MULTIARCH}/libpng12.so.0
+/usr/lib/${DEB_HOST_MULTIARCH}/libpng12.so.0 /usr/lib/${DEB_HOST_MULTIARCH}/libpng12.so

Bug#706164: please default to priority: optional

[Craig Small]

tags 706164 pending
thankyou

On Fri, Apr 26, 2013 at 01:00:05AM +0600, Andrey Rahmatullin wrote:
> I think packages should be Priority: optional by default, especially new ones.
Looking at the policy I happen to agree. Commit 
e470817704261ab40d9cb6d459915348a200e6b8 has the required changes.

 - Craig

-- 
Craig Small VK2XLZ   http://enc.com.au/  csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/  csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


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

Bug#698914: Fixing #698914 for wheezy (grub booting Windows 8 via UEFI)

[Steve McIntyre]

On Fri, Apr 26, 2013 at 12:31:41AM +0100, Ben Hutchings wrote:
>On Fri, Apr 26, 2013 at 12:11:10AM +0100, Steve McIntyre wrote:
>[...]
>> >This directory only exists if efivars is loaded.  I assume that SUSE
>> >configures it as built-in, and our kernel package has a patch to
>> >trigger autoloading of efivars on systems with EFI.  But for the
>> >benefit of people using custom kernel packages, can you check that
>> >update-grub will modprobe efivars *before* running os-prober?
>> >Alternately, could update-grub explicitly tell os-prober to look for
>> >EFI boot loaders if grub-efi is installed?
>> 
>> We could add a call to 30_os-prober before the actual call to
>> os-prober itself:
>> 
>>   modprobe efivars || true
>[...]
>
>'modprobe -q', please.  I already see too many FATAL (not really)
>errors from modprobes that are intentionally ignored...

I'm considering this script running on hurd or kfreebsd too...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead


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

Bug#698914: Fixing #698914 for wheezy (grub booting Windows 8 via UEFI)

[Ben Hutchings]

On Fri, Apr 26, 2013 at 12:11:10AM +0100, Steve McIntyre wrote:
[...]
> >This directory only exists if efivars is loaded.  I assume that SUSE
> >configures it as built-in, and our kernel package has a patch to
> >trigger autoloading of efivars on systems with EFI.  But for the
> >benefit of people using custom kernel packages, can you check that
> >update-grub will modprobe efivars *before* running os-prober?
> >Alternately, could update-grub explicitly tell os-prober to look for
> >EFI boot loaders if grub-efi is installed?
> 
> We could add a call to 30_os-prober before the actual call to
> os-prober itself:
> 
>   modprobe efivars || true
[...]

'modprobe -q', please.  I already see too many FATAL (not really)
errors from modprobes that are intentionally ignored...

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


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

Bug#698914: Fixing #698914 for wheezy (grub booting Windows 8 via UEFI)

[Steve McIntyre]

severity 698914 serious
thanks

On Thu, Apr 25, 2013 at 08:06:51PM +0100, Ben Hutchings wrote:
>On Thu, 2013-04-25 at 15:40 +0100, Steve McIntyre wrote:

...

>> and all works fine, fixing the bug nicely. I would like to upload (and
>> get unblocks for) new grub2 and os-prober packages - see debdiffs of
>> changes attached. The changes are quite small and targeted, only
>> affecting code paths for EFI systems.
>> 
>> What do you think?
>
>I agree that this is RC; we must not break Windows installations when
>going to dual-boot and it is not safe to assume that UEFI systems have a
>usable firmware boot menu.

Agreed; changing severity accordingly.

>[...]
>> --- os-prober-1.57/os-probes/mounted/x86/05efi  1970-01-01 
>> 01:00:00.0 +0100
>> +++ os-prober-1.58/os-probes/mounted/x86/05efi  2013-04-25 
>> 15:30:14.0 +0100
>> @@ -0,0 +1,70 @@
>> +#!/bin/sh
>> +# Detects all Microsoft OSes on a collection of partitions.
>> +
>> +. /usr/share/os-prober/common.sh
>> +
>> +partition="$1"
>> +mpoint="$2"
>> +type="$3"
>> +
>> +# This file is for UEFI platform only
>> +if [ ! -d /sys/firmware/efi ]; then
>> +   debug "Not on UEFI platform"
>> +   exit 1
>> +fi
>[...]
>
>This directory only exists if efivars is loaded.  I assume that SUSE
>configures it as built-in, and our kernel package has a patch to
>trigger autoloading of efivars on systems with EFI.  But for the
>benefit of people using custom kernel packages, can you check that
>update-grub will modprobe efivars *before* running os-prober?
>Alternately, could update-grub explicitly tell os-prober to look for
>EFI boot loaders if grub-efi is installed?

We could add a call to 30_os-prober before the actual call to
os-prober itself:

  modprobe efivars || true

which is simple and easy to track; I'm not so confident about making
more intrusive changes to grub config code than that, to be
honest. Does that sound like a reasonable option to people?

>(Really, I think grub-efi ought to pull the boot entries from EFI
>variables at boot time and append them to the menu.  But that's a rather
>large chunk of work.)

Ummm, yes. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.


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

Bug#684788: emacs24-lucid: segfaults on startup

[Kevin Ryde]

This bug happens for me too with 24.3+1-1.  (Though emacs23-lucid is
ok.)

gdb suggests that the "superclass" field in emacsFrameClassRec is some
wild pointer value, not the intended "&widgetClassRec", causing
XtInitializeWidgetClass() to crash when it follows to the superclass.

The superclass field in xlwMenuClassRec seems to be the same wild value,
though when run it doesn't reach the stage of making menus.


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

Bug#701684: Crashes when connecting to VM

[Lee Begg]

Hi

I can offer some observations about why virt-viewer crashes when connecting to 
some VMs.

The crash appears to be related to the vncdisplay result returned from 
libvirt.

For example:

$ virsh vncdisplay test-vm1
:1

$ virt-viewer test-vm1
Segmentation fault

$ virsh vncdisplay test-vm2
localhost:2

$ virt-viewer test-vm2


The difference between test-vm1 and test-vm2 is the graphics element in the 
domain XML.

test-vm1 has
   
which listens on all available interfaces

test-vm2 has
   
which just listens on localhost (in the case).

So it appears that virt-viewer isn't correctly handling where the host name 
for the vncdisplay is not given, and virt-viewer should use the address it 
used for connecting to libvirt or localhost if an address wasn't specified.

The above also gives a work around, which is to set the listen attribute on 
the graphics element in your domain XML.

Regards
Lee Begg


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

Bug#585122: (no subject)

[Roland Hieber]

Cool, not so intuitive like a command-line option, but definitely a step
in the right direction. Thanks for the info!

 - Roland


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

Bug#706078: ITP: base91 -- base91 encoder/decoder

[Andreas Bombe]

On Wed, Apr 24, 2013 at 03:40:57PM +0200, Franck wrote:
> basE91 is an advanced method for encoding binary data as ASCII characters. It
> is similar to UUencode or base64, but is more efficient. The overhead produced
> by basE91 depends on the input data. It amounts at most to 23% (versus 33% for
> base64) and can range down to 14%, which typically occurs on 0-byte blocks.
> This makes basE91 very useful for transferring larger files over binary
> insecure connections like e-mail or terminal lines.

That word should be safety, not security. Safety here means the message
does not get mangled, security on the other hand would mean things like
encryption.


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

Bug#706174: [Svn-bp-devel] Bug#706174: svn-buildpackage: The commit messages shouldn't localized

[Neil Williams]

severity 706174 wishlist
tag 667042 + l10n
merge 667042 706174
thanks

On Thu, 25 Apr 2013 22:53:17 +0200
Simon Chopin  wrote:

> Localization should be a personal setting, however when using svn-inject
> (and maybe other commands, I haven't checked) with for instance
> LANG=fr_FR.utf8 then the commit messages are also in French, which
> impacts every user of the SVN repo.
> 
> Thanks in advance for fixing this,

Nothing is going to happen on this for a month or two (until unstable calms 
down after the Wheezy release).

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpkjyB_3UuvQ.pgp
Description: PGP signature

Bug#705508: mirror submission for ftp.wallawalla.edu

[Greg Cornell]

Hi Raphael,

> * Do you also plan to offer it over HTTP?
Sure, I just enabled apache to serve the debian directory tree.  It's available 
at http://debian.wallawalla.edu/.

> * Please adjust the MIRRORNAME configuration in your ftpsync.conf to
> match "ftp.wallawalla.edu"
Ok, done.

>> Archive-upstream: debian.osuosl.org
> 
> It seems that your mirror hasn't updated in the last four days. Could
> you please take a look at it?
Hmm, well, it was working, but know all I'm getting when I try to sync is:
rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) 
[receiver=3.0.6]

Is there a different server I should be syncing from?

> How much bandwidth is available?

I'm not sure and our network guy is out this afternoon.  I'll check with him 
when I see him in the morning and let you know.

Greg


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

Bug#706176: FTBFS with hsqldb 2.2.9: cannot find symbol (org.hsqldb.Trace)

[Rene Engelhard]

Hi,

On Thu, Apr 25, 2013 at 11:14:49PM +0200, Rene Engelhard wrote:
> I just tried to build openjpa with libhsqldb-java 2.2.9 in preparation of
> #670902.
> 
> It failed:
[...]
> I am filing this as important now but it will become serious when
> libhsqldb-java 2.2.9 will replace the obsolete 1.8.0 in sid. Which 
> will be the case shortly after wheezy release (when LO 4.0 gets uploaded.)

What I forgot to mention here: 1.8.0.10 will be kept for LO, though -
as libhsqldb1.8.0-java. If you can't make it work with 2.2.9
there's that fallback.

Regards,
 
Rene


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

Bug#706144: m-tx has very limited architecture list, making texlive-full uninstallable on many architectures

[peter green]

I'm not the m-tx maintainer. I've just noticed that the m-tx source
code is Pascal and the Pascal compiler is only avalable on a limited
set of arches. This is probably the reason.
  

Indeed you are right, I misread the build-log and didn't notice this.

It seems likely that the maintainer looked at the list of architectures 
freepascal was available on and used that as their architecture list, 
then failed to update the list as freepascal added support for new 
architectures (armel and armhf).

Yes, one could set the arch to any and then wait, for which arches
the built packages appear. ;-)
  
IMO that is the most reasonable thing to do, that way when new 
architectures are added to freepascal (hopefully we will have mips 
support before jessie release) m-tx will be built without any further 
intervention.


I've just uploaded to raspbian with the debdiff at 
http://debdiffs.raspbian.org/main/m/m-tx/m-tx_0.60d-5%2brpi1.debdiff . 
I've tested that the package builds successfully with this change on 
debian armel, debian armhf and raspbian armhf.


If noone objects I intend to NMU this change to sid after the wheezy 
release (the target distribution, version number  and email address in 
the changelog entry will be changed for the debian upload).



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

Bug#706106: mirror submission for debian.cse.msu.edu

[Raphael Geissert]

Hi Adam,

Thanks for the changes. I have now added your mirror.

Could you please make sure that when the debian-cd sync successfully finishes 
there is a trace file in the debian-cd/project/trace/ directory?

In order to setup the ssh trigger please follow the instructions from the 
following page, configuring the ssh key of syncproxy.wna.debian.org:

http://www.debian.org/mirror/push_mirroring

Whenever your mirror is added to the ftp.us.d.o alias, a numeric ftpX.us.d.o 
alias will also be assigned.

Thanks in advance,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Bug#703301: mirror submission for mirror.0x.sg

[Raphael Geissert]

On Thursday 25 April 2013 04:39:04 Andrew Yong wrote:
> I've standardized the upstream mirror to ftp.jp.d.o and edited the
> configuration files as necessary.
> 
> The mirror@ email address is also working.
> 
> Do let me know if there's any outstanding issue I ought to resolve.

Thanks, I have now added your mirror.

Thank you for mirroring Debian.

-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Bug#706180: ITP: node-once -- Run a function only once with this module for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-once
  Version : 1.1.1
  Upstream Author : Isaac Z. Schlueter 
* URL : https://github.com/isaacs/once
* License : BSD-2-clause
  Programming Lang: JavaScript
  Description : Run a function only once with this module for Node.js

node-once is useful to make sure a listener for multiple events is
only run once.
.
Node.js is an event-based server-side javascript engine.


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

Bug#676648: confirmed

[Toni Mueller]

Hi,

On Mon, Apr 22, 2013 at 09:13:26PM +0200, Micha Lenk wrote:
> I did not do the upload yet because I hoped to get feedback from one of
> the other affected users first.

I could not try out your packages directly, but now I have these,
thanks to your hard work:

ii  libgstreamer0.10-0:amd64  0.10.36-1.2 amd64
ii  libgstreamer0.10-0:i386   0.10.36-1.2 i386

These packages include the patch that you sent me, but unfortunately,
the problem persists.


$ gdb /usr/bin/cheese core.cheese.1366926564 
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/cheese...(no debugging symbols found)...done.
[New LWP 29843]
[New LWP 29844]
[New LWP 29849]
[New LWP 29846]
[New LWP 29850]
[New LWP 29845]
[New LWP 29847]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `cheese'.
Program terminated with signal 11, Segmentation fault.
#0  __strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:213
213 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory.
(gdb) bt
#0  __strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:213
#1  0x7fca3f9ef2c3 in cheese_camera_setup () from 
/usr/lib/x86_64-linux-gnu/libcheese.so.3
#2  0x00417e29 in cheese_main_window_setup_camera ()
#3  0x00418e74 in cheese_main_on_app_activate ()
#4  0x7fca3d6766e0 in g_closure_invoke () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x7fca3d687750 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x7fca3d68f6bc in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7fca3d68f852 in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x00418b1c in ?? ()
#9  0x7fca3db70488 in g_application_run () from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#10 0x004190a8 in _vala_main ()
#11 0x7fca3cde5ead in __libc_start_main (main=, 
argc=, ubp_av=, init=, 
fini=, 
rtld_fini=, stack_end=0x7fffaa5c2c28) at libc-start.c:228
#12 0x0040e0a1 in _start ()
(gdb) 



Kind regards,
--Toni++


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

Bug#706169: libtemplates-parser11.6: arch-dependent file in "Multi-Arch: same" package

[Ludovic Brenta]

Jakub Wilk writes:
> Package: libtemplates-parser11.6
> Version: 11.6-2
> Severity: important
> User: multiarch-de...@lists.alioth.debian.org
> Usertags: multiarch
>
> libtemplates-parser11.6 is marked as "Multi-Arch: same", but the
> following file is architecture-dependent:
>
> /usr/share/doc/libtemplates-parser11.6/changelog.Debian.gz
>
> An example diff between i386 and amd64 (after ungzipping) is attached.

Probably the result of uploading to amd64 and i386 manually, which I do
very seldom, and changing the changelog in between.  A rebuild request
or a binNMU should fix this but I don't think this would be accepted in
wheezy.

-- 
Ludovic Brenta.


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

Bug#706179: ITP: r-cran-rsclient -- R client for the headless Rserve R server

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-rsclient
  Version : 0.7-2
  Upstream Author : Simon Urbanek
* URL or Web page : http://www.rforge.net/RSclient/index.html
* License : GPL-2 plus OpenSSL exception
  Description : R client for the headless Rserve R server

This package extend the 'rserve' package we have had in Debian since 2007.
'rserve' already includes several reference clients, but this package
provides a more extensive version.

The package uses OpenSSL, and at my urging, Simon added the following to his
top-level LICENSE file:

[Summary: GPL-2 with OpenSSL linking exception]

RSclient
Copyright (C) 2002-2013 Simon Urbanek

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

In addition, as a special exception, the copyright holders give
permission to link the code of portions of this program with the
OpenSSL project's "OpenSSL" library (or with modified versions of
it that use the same license as the "OpenSSL" library - see
http://www.openssl.org/), and distribute linked combinations
including the two.

You must obey the GNU General Public License in all respects
for all of the code used other than OpenSSL.  If you modify
file(s) with this exception, you may extend this exception to your
version of the file(s), but you are not obligated to do so.  If you
do not wish to do so, delete this exception statement from your
version.  If you delete this exception statement from all source
files in the program, then also delete it here.


which is followed by a full copy of the GPL-2.  I believe that this meets our
standards. 

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


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

Bug#670902: planning (a) hsqldb transition(s)

[Rene Engelhard]

block 670902 by 706176
thanks

Hi,

since the release is next week I did a testbuild of the r-deps -
except hsqldb itself of course :-) - now (in a clean sid chroot +
libhsqldb-java from experimental pre-installed):

$ grep-available -FDepends libhsqldb-java -sPackagePackage: hsqldb-server
Package: eucalyptus-java-common
Package: libbiojava1.7-java
Package: libbiojava3.0-java
Package: entagged
Package: libreoffice-base
Package: libopenjpa-java
Package: hsqldb-utils
Package: pixelmed-java
Package: biomaj
Package: paros

openjpa failed to build (see #706176)

The rest did build - so it actually isn't as as bad as I
feared (that of course doesn't say whether it needs other steps to work
like upgrade/re-create whatever db file, but... - at least the biojavas
ran tests which worked, too)

Will upload the new version after wheezy release[1] as announced in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670902#17

Regards,

Rene

[1] together with LO to make that one not uninstallable


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

Bug#706178: tilp2: Upgrade TILP II to version 1.17

[Logan Rosen]

Package: tilp2
Version: 1.16-0ubuntu1
Severity: wishlist
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy

Dear Maintainer,

This bug report was also filed in Ubuntu and can be found at
http://launchpad.net/bugs/1172888
The description, from gnu-linux123, follows:

TILP II 1.17 was released on March 31, 2013. This release, along with the
latest libti*/gfm releases, adds many new features and bugfixes, including
initial support for the new TI-84+CSE calculator. Please upgrade TILP to
version 1.17.

-- System Information:
Debian Release: wheezy/sid
  APT prefers saucy-updates
  APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'),
(100, 'saucy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8.0-19-generic (SMP w/1 CPU core)


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

Bug#697164: [new check] check for source packages with symlinks pointing outside

[Niels Thykier]

Control: reopen -1

On 2013-04-25 23:05, Jakub Wilk wrote:
> * Niels Thykier , 2013-04-25, 22:41:
>> Lintian 2.5.12 has a tag for this now, source-contains-unsafe-symlink,
> 
> The tag is not emitted for lintian4python... Should it be?
> 
> [...]


Ah, the tag ignores "well-behaved" absolute symlinks.

~Niels


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

Bug#706177: gfm: Update GFM to version 1.07

[Logan Rosen]

Package: gfm
Version: 1.03-2build1
Severity: wishlist
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy

Dear Maintainer,

This bug report was also filed in Ubuntu and can be found at
http://launchpad.net/bugs/1172894
The description, from gnu-linux123, follows:

GFM 1.07 was released on March 31. Please upgrade from the outdated 1.03.

Latest version can be found in the newest subfolder here:
https://sourceforge.net/projects/tilp/files/tilp2-linux/

-- System Information:
Debian Release: wheezy/sid
  APT prefers saucy-updates
  APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'),
(100, 'saucy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8.0-19-generic (SMP w/1 CPU core)


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

Bug#706176: FTBFS with hsqldb 2.2.9: cannot find symbol (org.hsqldb.Trace)

[Rene Engelhard]

Package: openjpa
Version: 2.0.1-1
Severity: important
Tags: experimental

I just tried to build openjpa with libhsqldb-java 2.2.9 in preparation of
#670902.

It failed:

[...]
[javac] Compiling 1301 source files to 
/tmp/buildd/openjpa-2.0.1/target/classes
[javac] 
/tmp/buildd/openjpa-2.0.1/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/HSQLDictionary.java:30:
 cannot find symbol
[javac] symbol  : class Trace
[javac] location: package org.hsqldb
[javac] import org.hsqldb.Trace;
[javac]  ^
[...]
[javac] 
/tmp/buildd/openjpa-2.0.1/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/HSQLDictionary.java:320:
 cannot find symbol
[javac] symbol  : variable Trace
[javac] location: class org.apache.openjpa.jdbc.sql.HSQLDictionary
[javac] && causes[0].getErrorCode() == 
-Trace.VIOLATION_OF_UNIQUE_INDEX) {
[javac] ^
   [javac] 2 errors
[javac] 28 warnings

BUILD FAILED
/tmp/buildd/openjpa-2.0.1/debian/build.xml:35: Compile failed; see the compiler 
error output for details.

Total time: 11 seconds
make[1]: *** [override_dh_auto_build] Error 1
make[1]: Leaving directory `/tmp/buildd/openjpa-2.0.1'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
 -> Cleaning COW directory
  forking: rm -rf /var/cache/pbuilder/build//cow.13046 

I am filing this as important now but it will become serious when
libhsqldb-java 2.2.9 will replace the obsolete 1.8.0 in sid. Which 
will be the case shortly after wheezy release (when LO 4.0 gets uploaded.)

Regards,

Rene

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
aShell: /bin/sh linked to /bin/dash


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

Bug#697164: [new check] check for source packages with symlinks pointing outside

[Jakub Wilk]

* Niels Thykier , 2013-04-25, 22:41:

Lintian 2.5.12 has a tag for this now, source-contains-unsafe-symlink,


The tag is not emitted for lintian4python... Should it be?

As for banning all such symlinks, I'm not sure it's a good idea. I 
happen to maintain a package which contains one (lintian4python), and 
I think it's a valid use-case. Feel free to convince me otherwise, 
though. :)


I believe this was taken care of with Lintian/2.5.12 supporting 
--include-dir in lintian4python 0.17.2.


s/was/could have been/, because I totally forgot to remove the symlinks 
from source. Will be fixed in 0.18, though. Thanks for reminding me about 
this. :)


--
Jakub Wilk


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

Bug#706171: xserver-xorg-video-nouveau: Automatic resolution detection broken in v. 1:1.0.7-1

[Sven Joachim]

On 2013-04-25 22:39 +0200, Dmitri wrote:

> I use multiseat system, for my regular seat i use nvidia proprietary driver
> (GT440, nvidia-kernel-dkms). Sometimes i load the 2nd seat (integrated GeForce
> 7025, nouveau) , and today i reconized, that nouveau and xrandr fail to detect
> right  resolutions.
>
> The algoritm to load my 2nd seat is:
> 1.)  I login as user "office" in tty1
> 2.) su-to-root -c "modprobe nouveau"
> 3.) startxfce4
>
> This are logs with new xserver-xorg-video-nouveau 1:1.0.7-1  from experimental
> repository
> xorg.log http://paste.debian.net/296/
> xrandr http://paste.debian.net/297/
>
> When i use version from testing repository everything looks great
> xorg.log http://paste.debian.net/300/
> xrandr  http://paste.debian.net/301/
>
> There is no xorg.conf file for nouveau seat, just /etc/X11/xorg.config file 
> for
> my regular nvidia-proprietary seat
> cat /etc/X11/xorg.config
> http://paste.debian.net/302/

Please attach these logs to the bug report, rather than pasting them on a
site from which they will disappear in a week.

Cheers,
   Sven


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

Bug#706175: pv: Progress bar shows "kiB" instead of "KiB"

[nyuszika7h]

Package: pv
Version: 1.2.0-1
Severity: minor
Tags: upstream

Hi,

I was running this just for fun:

$ entropy="$(pv /dev/random)"

After I got over 1 KiB of entropy, I've noticed that the progress bar
incorrectly displays "kiB" instead of "KiB":

2.56kiB 0:17:55 [   0 B/s] [...]

According to the SI standard, the unit symbol for kibibyte is "KiB".
http://en.wikipedia.org/wiki/Kibibyte

--
nyuszika7h

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages pv depends on:
ii  libc6  2.13-38

pv recommends no packages.

Versions of packages pv suggests:
ii  doc-base  0.10.4

-- 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#706174: svn-buildpackage: The commit messages shouldn't localized

[Simon Chopin]

Package: svn-buildpackage
Version: 0.8.5
Severity: minor
Tags: l10n

Localization should be a personal setting, however when using svn-inject
(and maybe other commands, I haven't checked) with for instance
LANG=fr_FR.utf8 then the commit messages are also in French, which
impacts every user of the SVN repo.

Thanks in advance for fixing this,
Simon

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

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

Versions of packages svn-buildpackage depends on:
ii  devscripts  2.12.6
ii  file1:5.11-3
ii  libcapture-tiny-perl0.22-1
ii  libfile-libmagic-perl   0.96-3
ii  liblocale-gettext-perl  1.05-7+b1
ii  libsvn-perl 1.7.9-1+nmu1
ii  liburi-perl 1.60-1
ii  perl5.14.2-21
ii  subversion  1.7.9-1+nmu1
ii  unp 2.0~pre7+nmu1
ii  wget1.14-1

Versions of packages svn-buildpackage recommends:
ii  debhelper  9.20120909

svn-buildpackage suggests no packages.

-- no debconf information


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

Bug#701702: lintian: warn if debian/shlibs.local references foreign packages

[Niels Thykier]

On 2013-02-26 14:12, Adam D. Barratt wrote:
> On 26.02.2013 12:46, Sven Joachim wrote:
>> It would be great if lintian could detect when debian/shlibs.local
>> references packages not built from the same source and issue a warning
>> for that.
> 
> This sounds like something we could probably extend
> shlibs-declares-dependency-on-other-package to cover, unless I'm missing
> a detail somewhere.
> 
> Regards,
> 
> Adam
> 
> 

shlibs-declares-dependency-on-other-package is for binary packages and
debian/shlibs.local (vs DEBIAN/shlibs.local) sounds like it is a file in
the source package.

That said, is there any valid use case for debian/shlibs.local instead
of using debian/[$pkg.]shlibs besides overriding "foreign" packages?

~Niels


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

Bug#706173: libata: errors with sil3826 port multiplier, needs same handling as sil3726

[Joseph Spiros]

Package: src:linux
Version: 3.2.41-2
Severity: important
Tags: upstream patch

When attaching an sil3826-based SATA port multiplier to a sil3132 controller
(though this would also apply to any other controller supporting these port
multipliers), many errors are produced and, if attached prior to booting and
not hot-plugged, the boot process can be delayed for more than 10 minutes.

It seems as though sil3826-based port multipliers have the same quirks as
their predecessors based on sil3726, which required special handling in
libata.

There is a relevant bug report in the Red Hat bugzilla at
.

The patch that fixes this problem for me was sent to the linux-ide
mailing list in January 2013 and can be seen at
.


-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-15) ) #1 SMP Debian 3.2.41-2


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (600, 'stable'), (500, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages linux-image-3.2.0-4-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.49
ii  initramfs-tools [linux-initramfs-tool]  0.109
ii  kmod9-2
ii  linux-base  3.5
ii  module-init-tools   9-2

Versions of packages linux-image-3.2.0-4-amd64 recommends:
ii  firmware-linux-free  3.2

Versions of packages linux-image-3.2.0-4-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 1.99-26
pn  linux-doc-3.2   

Versions of packages linux-image-3.2.0-4-amd64 is related to:
pn  firmware-atheros   
pn  firmware-bnx2  
pn  firmware-bnx2x 
pn  firmware-brcm80211 
pn  firmware-intelwimax
pn  firmware-ipw2x00   
pn  firmware-ivtv  
pn  firmware-iwlwifi   
pn  firmware-libertas  
pn  firmware-linux 
ii  firmware-linux-nonfree 0.36+wheezy.1
pn  firmware-myricom   
pn  firmware-netxen
pn  firmware-qlogic
ii  firmware-ralink0.36+wheezy.1
ii  firmware-realtek   0.36+wheezy.1
ii  xen-hypervisor-4.1-amd64 [xen-hypervisor]  4.1.4-2

-- debconf information excluded

-- 
Joseph Spiros
jos...@josephspiros.com
+1 (440) 707-6855


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

Bug#706172: antlr3 attempts to install files in /usr/share/maven-repo on building (FTBFS)

[Emmanuel Bourg]

Package: antlr3
Version: 3.2-7
Severity: serious
Justification: fails to build from source (but built successfully in the past)

I'm unable to build antlr3, it fails to install the pom in debian/maven-repo:

[INFO] 
[INFO] Building ANTLR Master build control POM
[INFO]task-segment: [package, install, 
org.debian.maven:debian-maven-plugin:1.6:install]
[INFO] 
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing /home/ebourg/antlr3/pom.xml to 
/home/ebourg/antlr3/debian/maven-repo/org/antlr/antlr-master/3.2/antlr-master-3.2.pom
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error installing artifact: Unable to open file 
/home/ebourg/antlr3/debian/maven-repo/org/antlr/antlr-master/3.2/antlr-master-3.2.pom
 for writing.


The pom can't be installed because debian/maven-repo/org/antlr/antlr-master/3.2
is a symlink to /usr/share/maven-repo/org/antlr/antlr-master/3.2 :

ebourg@debiandev:~/antlr3$ ll 
/home/ebourg/antlr3/debian/maven-repo/org/antlr/antlr-master/
total 8
drwxr-xr-x 2 ebourg ebourg 4096 Apr 25 22:25 .
drwxr-xr-x 6 ebourg ebourg 4096 Apr 25 22:25 ..
lrwxrwxrwx 1 ebourg ebourg   48 Apr 25 22:25 3.2 -> 
/usr/share/maven-repo/org/antlr/antlr-master/3.2
lrwxrwxrwx 1 ebourg ebourg   48 Apr 25 22:25 3.x -> 
/usr/share/maven-repo/org/antlr/antlr-master/3.x

Thus it's only possible to build the package as root.



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

Kernel: Linux 3.2.0-4-amd64 (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/dash

Versions of packages antlr3 depends on:
ii  default-jre-headless [java6-runtime-headless]1:1.6-47
ii  gcj-4.7-jre-headless [java5-runtime-headless]4.7.2-3
ii  gcj-jre-headless [java5-runtime-headless]4:4.7.2-1
ii  libstringtemplate-java   3.2.1-1
ii  openjdk-6-jre-headless [java6-runtime-headless]  6b27-1.12.4-1

antlr3 recommends no packages.

antlr3 suggests no packages.

-- no debconf information


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

Bug#706170: xosview: platform detection improvement/fix in debian/rules

[Pino Toscano]

Source: xosview
Version: 1.14-1
Severity: wishlist
Tags: patch

Hi,

the changes in the experimental version still make xosview compiled as
"linux" even in non-Linux OSes, and never uses the right platform
string on kFreeBSD.
The attached patch factorizes the detection of the platform string
to use when invoking make,
- making it use the right one on kFreeBSD (which though won't compile
  yet, and that will need proper fixes)
- bailing out when the OS is not recognized, and it is easy (just add
  the two proper lines in that if chain, e.g. starting from the
  kfreebsd ones) to add cases for new OSes

Thanks,
-- 
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -9,23 +9,20 @@
 CXX=g++
 
 DEB_BUILD_ARCH_OS ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
+ifeq ($(DEB_BUILD_ARCH_OS),linux)
+  PLATFORM=linux
+else ifeq ($(DEB_BUILD_ARCH_OS),kfreebsd)
+  PLATFORM=bsd
+else
+  $(error Missing implementation for $(DEB_BUILD_ARCH_OS))
+endif
 
 build: build-arch build-indep
 build-arch: build-stamp
 build-indep: build-stamp
 build-stamp:
 	dh_testdir
-
-#experimental kfreebsd-* support
-ifeq ($(DEB_BUILD_ARCH_OS),kfreebsd-i386)
-	$(MAKE) PLATFORM=bsd
-else
-ifeq ($(DEB_BUILD_ARCH_OS),kfreebsd-amd64)
-	$(MAKE) PLATFORM=bsd
-endif
-endif
-
-	$(MAKE) PLATFORM=linux
+	$(MAKE) PLATFORM=$(PLATFORM)
 	touch $@
 
 clean:

Bug#706171: xserver-xorg-video-nouveau: Automatic resolution detection broken in v. 1:1.0.7-1

[Dmitri]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.1-5
Severity: normal

Dear Maintainer,

Hello!
I use multiseat system, for my regular seat i use nvidia proprietary driver
(GT440, nvidia-kernel-dkms). Sometimes i load the 2nd seat (integrated GeForce
7025, nouveau) , and today i reconized, that nouveau and xrandr fail to detect
right  resolutions.

The algoritm to load my 2nd seat is:
1.)  I login as user "office" in tty1
2.) su-to-root -c "modprobe nouveau"
3.) startxfce4

This are logs with new xserver-xorg-video-nouveau 1:1.0.7-1  from experimental
repository
xorg.log http://paste.debian.net/296/
xrandr http://paste.debian.net/297/

When i use version from testing repository everything looks great
xorg.log http://paste.debian.net/300/
xrandr  http://paste.debian.net/301/

There is no xorg.conf file for nouveau seat, just /etc/X11/xorg.config file for
my regular nvidia-proprietary seat
cat /etc/X11/xorg.config
http://paste.debian.net/302/

Best regards,
Dmitrii



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 May 11  2012 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Apr 17 14:20 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-
diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-
diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386
-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386
-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-
diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by
glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-
diverted/x86_64-linux-gnu/libGL.so by glx-diversions

VGA-compatible devices on PCI bus:
--
00:0d.0 VGA compatible controller [0300]: NVIDIA Corporation C61 [GeForce 7025
/ nForce 630a] [10de:03d6] (rev a2)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT
440] [10de:0de0] (rev a1)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 3.8-trunk-686-pae (debian-ker...@lists.debian.org) (gcc version
4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.8.5-1~experimental.1

Xorg X server log files on system:
--
-rw-r--r-- 1 root root  20749 Aug 15  2012 /var/log/Xorg.!.log
-rw-r--r-- 1 root root  25036 Aug 21  2012 /var/log/Xorg.9.log
-rw-r--r-- 1 root root  25037 Aug 21  2012 /var/log/Xorg.71.log
-rw-r--r-- 1 root root   1670 Aug 21  2012 /var/log/Xorg.7.log
-rw-r--r-- 1 root root   7934 Aug 21  2012 /var/log/Xorg.6.log
-rw-r--r-- 1 root root  43689 Dec 19 17:27 /var/log/Xorg.5.log
-rw-r--r-- 1 root root  28906 Dec 31 16:39 /var/log/Xorg.3.log
-rw-r--r-- 1 root root 409497 Mar 12 19:11 /var/log/Xorg.2.log
-rw-r--r-- 1 root root  18840 Apr 25 22:47 /var/log/Xorg.1.log
-rw-r--r-- 1 root root  56050 Apr 25 22:57 /var/log/Xorg.0.log

udev information:
-
P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
E: EV=3
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: KEY=10 0 0 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PRODUCT=19/0/1/0
E: PROP=0
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=5506662

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event6
N: input/event6
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event6
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event6
E: DMI_VENDOR=To Be Filled By O.E.M.
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: MAJOR=13
E: MINOR=70
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=5508391
E: XKBLAYOUT=us,ru
E: XKBMODEL=pc105
E: XKBOPTIONS=grp:lwin_toggle,grp_led:scroll
E: XKBVARIANT=,

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5
E: EV=3
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-PNP0C0C:00
E: ID_PATH_TAG=acpi-PNP0C0C_00
E: KEY=10 0 0 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: NAME="Power Button"
E: PHYS="PNP

Bug#704070: ffmpeg: obsolete-conffile as reported by adequate

[Reinhard Tartler]

tags 704070 help
stop

On Wed, Mar 27, 2013 at 4:58 PM, shirish शिरीष  wrote:
> Package: ffmpeg
> Version: 6:0.8.5-1
> Severity: important
> Usertags: conffile
> Usertags: obsolete-conffile adequate
>
> Dear Maintainer,
>   Adequate reported an obsolete-conffile in ffmpeg. Please fix it.
>
> $ adequate ffmpeg
> ffmpeg: obsolete-conffile /etc/ffserver.conf

I wonder why 
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=6c39614b2c9d4ded6a243c70326231d6a970287c
was not enough to fix that. Help in form of patches much appreciated!


-- 
regards,
Reinhard


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

Bug#706169: libtemplates-parser11.6: arch-dependent file in "Multi-Arch: same" package

[Jakub Wilk]

Package: libtemplates-parser11.6
Version: 11.6-2
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libtemplates-parser11.6 is marked as "Multi-Arch: same", but the 
following file is architecture-dependent:


/usr/share/doc/libtemplates-parser11.6/changelog.Debian.gz

An example diff between i386 and amd64 (after ungzipping) is attached.

--
Jakub Wilk
diff -ur 
libtemplates-parser11.6_11.6-2_i386/usr/share/doc/libtemplates-parser11.6/changelog.Debian
 
libtemplates-parser11.6_11.6-2_amd64/usr/share/doc/libtemplates-parser11.6/changelog.Debian
--- 
libtemplates-parser11.6_11.6-2_i386/usr/share/doc/libtemplates-parser11.6/changelog.Debian
  2011-10-03 01:45:16.0 +0200
+++ 
libtemplates-parser11.6_11.6-2_amd64/usr/share/doc/libtemplates-parser11.6/changelog.Debian
 2011-10-03 01:09:24.0 +0200
@@ -4,6 +4,7 @@
 kfreebsd-amd64, kfreebsd-i386.
   * debian/patches/disable-inlining.diff: new; work around compiler bug
 #642981 on armel.
+  * debian/rules (clean): adjust to the new upstream version.
 
  -- Ludovic Brenta   Mon,  3 Oct 2011 01:01:11 +0200
 

Bug#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video

[Francesco Poli]

Control: tags -1 - moreinfo


On Thu, 25 Apr 2013 19:37:39 +0200 Sebastian Ramacher wrote:

> Control: tags -1 + moreinfo
> 
> Hi,

As always, thanks a lot for the commendable promptness of your
reactions to bug reports!
Rest assured that it is really appreciated.

>
> On 2013-04-25 16:54:00, Francesco Poli (wintermute) wrote:
[...]
> >   2) iceweasel behaves exactly as if none of the installed plugins were 
> >  able to deal with this file type: it popped up a dialog window,
> >  offering me to download the video or to open it with GNOME MPlayer
[...]
> > Why does gecko-mediaplayer claim that additional plugins are needed
> > to play the above-mentioned videos, while gnome-mplayer is able to
> > play them, when running in a standalone window?
> > 
[...]
> Did you change the settings regarding Windows Media Player emulation
> (Settings / Plugin)?

Do you mean in the gnome-mplayer preferences?
I am pretty sure I haven't changed anything regarding this.
However, I see that I have all those emulation options (QuickTime
Emulation, RealPlayer Emulation, Windows Media Player Emulation, DiVX
Player Emulation) disabled!

I tried to enable all of those emulation options, but the result is not
different, even after restarting iceweasel...

> It defaults to being enabled and I just checked
> that it indeed is enabled by default for a new user and I'm able to
> watch the videos with gecko-mediaplayer in a new profile.

Where is the user configuration file for gnome-mplayer?
I mean: which file(s) should I move out of the way, in order to start
with a new gnome-mplayer profile (without creating a new user on my
box)?


P.S.: I dropped the moreinfo tag, as I think I replied to your
questions; of course, should you further need additional information,
feel free to re-add the tag...


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpMSZtm9xOpK.pgp
Description: PGP signature

Bug#706168: libudunits2-0: arch-dependent file in "Multi-Arch: same" package

[Jakub Wilk]

Package: libudunits2-0
Version: 2.1.23-3
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libudunits2-0 is marked as "Multi-Arch: same", but the following file is 
architecture-dependent:


/usr/share/info/udunits2.info.gz

An example diff between i386 and amd64 (after ungzipping) is attached.

--
Jakub Wilk
diff -ur libudunits2-0_2.1.23-3_i386/usr/share/info/udunits2.info 
libudunits2-0_2.1.23-3_amd64/usr/share/info/udunits2.info
--- libudunits2-0_2.1.23-3_i386/usr/share/info/udunits2.info2011-12-16 
13:14:31.0 +0100
+++ libudunits2-0_2.1.23-3_amd64/usr/share/info/udunits2.info   2011-12-16 
14:56:50.0 +0100
@@ -110,8 +110,9 @@
  only supports the ASCII character set.  The `UDUNITS-2' package
  supports the following character sets: ASCII, ISO 8859-1 (Latin-1),
  and the UTF-8 encoding of ISO 10646 (Unicode).  This means that
- unit string specifications like "`µ°F·Ω⁻¹'" are now supported (your
- viewer must support UTF-8 to display this string correctly).
+ unit string specifications like "`µ°F·Ω⁻¹'" are now
+ supported (your viewer must support UTF-8 to display this string
+ correctly).
 
* *Support for logarithmic units:*  The unit string specification
  "`0.1 lg(re 1 mW)'" specifies a deciBel unit with a one milliwatt
@@ -500,13 +501,13 @@
 Node: Top2002
 Node: Introduction4382
 Node: Differences4856
-Node: Obtain7350
-Node: Install7693
-Node: Short7970
-Node: Long8818
-Node: What20535
-Node: Database22882
-Node: Support23382
-Node: Complete Index23693
+Node: Obtain7355
+Node: Install7698
+Node: Short7975
+Node: Long8823
+Node: What20540
+Node: Database22887
+Node: Support23387
+Node: Complete Index23698
 
 End Tag Table

Bug#706167: qimhangul-qt4: improper alternative handling in M-A:same package

[Andreas Beckmann]

Package: qimhangul-qt4
Version: 0.2.0-2
Severity: serious

Hi,

qimhangul-qt4 is marked Multi-Arch: same, but it does not handle the
alternative properly, see the following sequence

  apt-get install qimhangul-qt4:amd64
  # registers the alternative

  apt-get install qimhangul-qt4:i386
  # registers the alternative again, which is a no-op

  apt-get remove qimhangul-qt4:i386
  # removes the alternative even though qimhangul-qt4:amd64 is still
  # installed

>From the attached log (scroll to the end):

0m32.5s ERROR: FAIL: After purging files have disappeared:
  /etc/X11/xinit/xinput.d/ko_KR -> /etc/alternatives/xinput-ko_KR not owned
  /etc/alternatives/xinput-ko_KR -> /etc/X11/xinit/xinput.d/qimhangul-qt4   
 not owned


Andreas


qimhangul-qt4=0.2.0-2.log.gz
Description: GNU Zip compressed data

Bug#705205: libvirt-bin: Memory leak in virStorageBackendLogicalMakeVol

[Guido Günther]

tag 705205 +pending
thanks

Hi Luca,
On Thu, Apr 11, 2013 at 10:42:24AM +0100, Luca Tettamanti wrote:
> Package: libvirt-bin
> Version: 0.9.12-11
> Severity: important
> Tags: patch
> 
> Hello,
> In our workload we use LVM for VM storage and continuously create and destroy 
> instances.
> We noticed that over time libvirtd memory usage grows until libvirt
> cannot fork anymore (to spawn LVM tools):
> 
> virFork:279 : cannot fork child process: Cannot allocate memory
> 
> libvirtd won't crash (yet), but it will eventually mark all the storage
> pools as offline.
> 
> I've tracked down the issue to a memory leak in
> virStorageBackendLogicalMakeVol (creating a volume triggers a refresh of
> the pool):
> 
> 50,229,128 (820,736 direct, 49,408,392 indirect) bytes in 3,664 blocks are 
> definitely lost in loss record 883 of 883
>at 0x4C28BED: malloc (vg_replace_malloc.c:263)
>by 0x4C28D6F: realloc (vg_replace_malloc.c:632)
>by 0x805ADF3: re_compile_internal (regcomp.c:760)
>by 0x805B1AB: regcomp (regcomp.c:506)
>by 0x4D13CD: virStorageBackendLogicalMakeVol 
> (storage_backend_logical.c:203)
>by 0x4CE09B: virStorageBackendRunProgRegex (storage_backend.c:1512)
>by 0x4D0A8E: virStorageBackendLogicalFindLVs 
> (storage_backend_logical.c:306)
>by 0x4D1971: virStorageBackendLogicalRefreshPool 
> (storage_backend_logical.c:591)
>by 0x4C9596: storagePoolRefresh (storage_driver.c:904)
>by 0x511CE44: virStoragePoolRefresh (libvirt.c:12116)
>by 0x436687: remoteDispatchStoragePoolRefreshHelper 
> (remote_dispatch.h:11759)
>by 0x515B7FF: virNetServerProgramDispatch (virnetserverprogram.c:423)
> 
> This bug has already been fixed upstream with commit 71da3b66 (which
> also reverts afc4631b). This fix is already included in the experimental
> package, but since it's self-contained and minimally intrusive I suggest
> to backport it for Wheezy (and squeeze-backports?).
> Patch is attached.

Thanks for tracking this down! I've pushed this to our wheezy branch and
will hopefully get this into R1.
Cheers,
 -- Guido


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

Bug#706164: please default to priority: optional

[Andrey Rahmatullin]

Package: dh-make
Version: 0.62
Severity: wishlist

I think packages should be Priority: optional by default, especially new ones.

The Policy 2.5 implies that everything below "standard" is "optional" unless it
conflicts with other "optional" packages, depends on "extra" packages or is not
directly useful to users. So a random package should be "optional" unless there
are reasons to use some other priority and this should be reflected in the
dh_make defaults.



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

Kernel: Linux 3.9.0-rc7-wrar-1+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dh-make depends on:
ii  debhelper  9.20120909
ii  dpkg-dev   1.16.10
ii  make   3.81-8.2
ii  perl   5.14.2-21

dh-make recommends no packages.

Versions of packages dh-make suggests:
ii  build-essential  11.6

-- debconf-show failed


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

Bug#652298:

[StalkR]

Thanks Teemu for the patch, I agree with the proposed patch and
confirms it fixes the issue for me too.


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

Bug#702623: (no subject)

[Camm Maguire]

From: Camm Maguire 
To: Julien Puydt 
Cc: 702...@bugs.debian.org
Subject: Re: Bug#702623: closed by Camm Maguire  ()
References: 
<513afd7f.70...@laposte.net>

<20130424211403.bcdb4fce86ed5a4eada2d...@laposte.net>
Date: Thu, 25 Apr 2013 15:09:21 -0400
In-Reply-To: <20130424211403.bcdb4fce86ed5a4eada2d...@laposte.net> (Julien
Puydt's message of "Wed, 24 Apr 2013 21:14:03 +0200")
Message-ID: <87a9omjula@maguirefamily.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Greetings, and thanks!

Julien Puydt  writes:

> On Tue, 23 Apr 2013 15:15:12 +
> ow...@bugs.debian.org (Debian Bug Tracking System) wrote:
>
>> This is an automatic notification regarding your Bug report
>> which was filed against the maxima package:
>> 
>> #702623: Maxima in sage is built against ecl
>> 
>> It has been closed by Camm Maguire .
>> 
>> 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 Camm Maguire 
>>  by
>> replying to this email.
>
> Your explanation isn't correct : sage uses maxima, and uses ecl -- and it 
> moves things from one to the other. So you really need maxima to know about 
> ecl for this to work. I stand by my report!
>

Can you be a bit more specific about 'moving things from one to the
other', maybe with an example?

Take care,

> Snark on #debian-science
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


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

Bug#706165: homebank: Please package new upstream release version 4.5

[Don Veino]

Package: homebank
Version: 4.4-1
Severity: normal

Dear Maintainer,

The developer of HomeBank has had a new release 4.5 available since 2013-01-14,
which brings several new features and a slew of bug fixes.

Please consider updating the Debian package to include this release.

Thanks!



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

Kernel: Linux 3.2.0-4-686-pae (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/dash

Versions of packages homebank depends on:
ii  homebank-data   4.4-1
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-37
ii  libcairo2   1.12.2-2
ii  libfontconfig1  2.9.0-7
ii  libfreetype62.4.9-1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-3
ii  libgtk2.0-0 2.24.10-2
ii  libofx4 1:0.9.4-2.1
ii  libpango1.0-0   1.30.0-1

Versions of packages homebank recommends:
ii  librsvg2-common  2.36.1-1

homebank suggests no packages.

-- no debconf information


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

Bug#698914: Fixing #698914 for wheezy (grub booting Windows 8 via UEFI)

[Ben Hutchings]

On Thu, 2013-04-25 at 15:40 +0100, Steve McIntyre wrote:
> Hi folks,
> 
> I opened #698914 a while back, concerned about the lack of support in
> grub and os-prober for detecting Windows 8 on UEFI systems so that
> working boot entries would be added automatically at installation
> time. At the time, I did not consider the issue RC. However,
> discussion yesterday with Wolodja Wentland suggests that this is
> becoming a more common problem than I feared, and users are tripping
> over this and asking for support on #debian and elsewhere. I'm
> thinking that this bug should therefore be considered RC for the
> Wheezy r0 release at this point.
> 
> He pointed me at an existing set of patches from the folks at
> openSUSE, which I've adapted very slightly and tested out:
> 
>  * Using an existing installation
>  * Using a locally-built CD to test the os-prober udeb
> 
> and all works fine, fixing the bug nicely. I would like to upload (and
> get unblocks for) new grub2 and os-prober packages - see debdiffs of
> changes attached. The changes are quite small and targeted, only
> affecting code paths for EFI systems.
> 
> What do you think?

I agree that this is RC; we must not break Windows installations when
going to dual-boot and it is not safe to assume that UEFI systems have a
usable firmware boot menu.

[...]
> --- os-prober-1.57/os-probes/mounted/x86/05efi  1970-01-01 01:00:00.0 
> +0100
> +++ os-prober-1.58/os-probes/mounted/x86/05efi  2013-04-25 15:30:14.0 
> +0100
> @@ -0,0 +1,70 @@
> +#!/bin/sh
> +# Detects all Microsoft OSes on a collection of partitions.
> +
> +. /usr/share/os-prober/common.sh
> +
> +partition="$1"
> +mpoint="$2"
> +type="$3"
> +
> +# This file is for UEFI platform only
> +if [ ! -d /sys/firmware/efi ]; then
> +   debug "Not on UEFI platform"
> +   exit 1
> +fi
[...]

This directory only exists if efivars is loaded.  I assume that SUSE
configures it as built-in, and our kernel package has a patch to trigger
autoloading of efivars on systems with EFI.  But for the benefit of
people using custom kernel packages, can you check that update-grub will
modprobe efivars *before* running os-prober?  Alternately, could
update-grub explicitly tell os-prober to look for EFI boot loaders if
grub-efi is installed?

(Really, I think grub-efi ought to pull the boot entries from EFI
variables at boot time and append them to the menu.  But that's a rather
large chunk of work.)

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


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

Bug#602034: jpeg8 vs jpeg-turbo

[Pau Garcia i Quiles]

Hello,

The KDE maintainer in Fedora started an interesting discussion some time
ago in Digikam's mailing list. There was input from the very IJG:

http://mail.kde.org/pipermail/digikam-devel/2013-January/066206.html

It boils down to "jpeg6-2 is the only important thing. Forget about jpeg8
and jpeg9, which bring incompatible changes".

http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html

FWIW, Arch and Gentoo also follow the policy that jpeg6-2 (and jpeg-turbo
with 6-2 API/ABI) is the real deal.



On Wed, Apr 24, 2013 at 1:48 PM, Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:

> Hi Ondřej,
>
> I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW
> [1].
>
> On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote:
>
>  Debian has already open ITP[3] #602034 for libjpeg-turbo, which
>> support libjpeg62 API/ABI and also some important bits of libjpeg8. As
>> libjpeg is one of the base libraries of the system, I think it might
>> be a good idea to discuss this project wide. Also although I have an
>> opinion (as you might have guessed from this email) that we should try
>> to be aligned with other distributions and the reasoning for not going
>> for , I will be happy with whatever result will end-up.
>>
>
> In an IRC discussion in #debian-devel several weeks ago the consensus was:
> the RT team (represented Julien) will probably not want two libjpeg
> implementations in Debian. My first packaging approach aimed at having the
> compat mode libraries available [2] and allow the user to install them as a
> drop-in replacement for libjpeg8.
>
> The IRC discussion lead to the result that the compat packages are not
> wanted in Debian, only the native TURBOjpeg ABI. I was asked to ping Bill
> Allombert about his opinion to transition from libjpeg8 fully to
> libjpeg8-turbo. @Bill: can you repeat your disposition here again? I guess
> our earlier mailing was a private mail exchange.
>
>  A. Add libjpeg-turbo to Debian archive (that's easy)
>>
>
> Done. Waiting in NEW. Only containing libturbojpeg.so.1
>
>  B. Add required provides/alternatives for libjpeg62-dev and
>> libjpeg8-dev (where API/ABI match)
>>
>
> A packaging example can be seen in [1]. If the packages disappears from
> the NEW queue, you can also obtain a libjpeg-turbo version with compat
> packages provided here [3].
>
>  C. Decide which package should provide default libjpeg-dev library
>>
>
> Last statement from Bill: libjpeg by IJG
>
> Greets,
> Mike
>
>
> [1] 
> http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-2.**html
> [2] 
> http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-1.**html
> [3] 
> http://packages.x2go.org/**debian/pool/main/libj/libjpeg-**turbo/
>
> --
>
> DAS-NETZWERKTEAM
> mike gabriel, rothenstein 5, 24214 neudorf-bornstein
> fon: +49 (1520) 1976 148
>
> GnuPG Key ID 0x25771B31
> mail: mike.gabriel@das-netzwerkteam.**de,
> http://das-netzwerkteam.de
>
> freeBusy:
> https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-**
> netzwerkteam.de.xfb




-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Bug#705236: npm doesn't work with node v0.10.1

[Guido Günther]

Hi jérémy,
On Wed, Apr 24, 2013 at 11:13:57AM +0200, Jérémy Lal wrote:
> (resending using another smtp, your mta rejected mine the first try)
> 
> On 24/04/2013 06:23, Guido Günther wrote:
> > Package: npm
> > Followup-For: Bug #705236
> > 
> > I wonder if it would make sense to ship npm from nodejs itself? This
> > would make sure these are in sync. cc: the nodejs maintainers for that.
> > 
> > If not I'd be happy to NMU a new npm version.
> > Cheers,
> 
> I think it doesn't make sense packaging npm within nodejs,
> - they are very different software
> - npm depends on many other modules, nodejs doesn't
> - the packaging work is very different

That's fine. I was just suggesting this since it might save some effort.
Having it packaged separately is preferable of course.

> There is still work to do on npm dependencies. Some of them
> should better be left bundled in npm (because they are so bound
> to npm and better alternatives exist, or because nobody would
> use them anyway).
> 
> I'll have some time to finish this job next month. If you can
> help before, we can talk on #debian-js.

I've attached my current diff here (excluding the upstream import of
1.2.18) that gave me a working (but far from lintian clean) version.
I'll update it should I find some time to make some more progress.
Cheers,
 -- Guido
diff --git a/debian/install b/debian/install
index 2972590..25a1372 100644
--- a/debian/install
+++ b/debian/install
@@ -1,9 +1,8 @@
 lib/*.js usr/share/npm/lib
 lib/utils/*.js usr/share/npm/lib/utils
 lib/utils/completion usr/share/npm/lib/utils
-lib/utils/npm-registry-client usr/share/npm/lib/utils
 bin/*.js usr/share/npm/bin
 package.json usr/share/npm
 node_modules usr/share/npm
 debian/npmrc usr/share/npm
-doc usr/share/npm
\ No newline at end of file
+doc usr/share/npm
diff --git a/debian/patches/1001_sort_index_build.patch 
b/debian/patches/1001_sort_index_build.patch
deleted file mode 100644
index 03b0101..000
--- a/debian/patches/1001_sort_index_build.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-Description: Sort globbed files when building index of documentation.
-Origin: upstream,https://github.com/isaacs/npm/commit/af6444fe
-Forwarded: not-needed
-Author: Jérémy Lal 
-Last-Update: 2012-04-07
 a/scripts/index-build.js
-+++ b/scripts/index-build.js
-@@ -12,6 +12,7 @@
- 
- function done (which) { return function (er, docs) {
-   if (er) throw er
-+  docs.sort();
-   if (which === "api") apidocs = docs
-   else clidocs = docs
- 
diff --git a/debian/patches/1002_only_use_numeric_UIDs_and_GIDs_in_spawn.patch 
b/debian/patches/1002_only_use_numeric_UIDs_and_GIDs_in_spawn.patch
deleted file mode 100644
index 4b1640b..000
--- a/debian/patches/1002_only_use_numeric_UIDs_and_GIDs_in_spawn.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-Description: Only use numeric UIDs and GIDs in spawn.
-Origin: upstream,https://github.com/isaacs/npm/commit/76c7d93e
-Forwarded: not-needed
-Last-Update: 2012-09-09

- lib/utils/exec.js |   19 +--
- 1 file changed, 17 insertions(+), 2 deletions(-)
-
 a/lib/utils/exec.js
-+++ b/lib/utils/exec.js
-@@ -11,6 +11,7 @@
-   , myGID = process.getgid ? process.getgid() : null
-   , isRoot = process.getuid && myUID === 0
-   , constants = require("constants")
-+  , uidNumber = require("./uid-number.js")
- 
- function exec (cmd, args, env, takeOver, cwd, uid, gid, cb) {
-   if (typeof cb !== "function") cb = gid, gid = null
-@@ -34,6 +35,15 @@
- log.verbose(uid, "Setting uid from "+myUID)
- log.verbose(new Error().stack, "stack at uid setting")
-   }
-+
-+  if (isNaN(uid) || isNaN(gid)) {
-+// get the numeric values
-+return uidNumber(uid, gid, function (er, uid, gid) {
-+  if (er) return cb(er)
-+  exec(cmd, args, env, takeOver, cwd, uid, gid, cb)
-+})
-+  }
-+
-   log.silly(cmd+" "+args.map(JSON.stringify).join(" "), "exec")
-   var stdout = ""
- , stderr = ""
-@@ -94,8 +104,8 @@
-  , env : env || process.env
-  , cwd : cwd || null }
- , cp
--  if (uid != null) opts.uid = uid
--  if (gid != null) opts.gid = gid
-+  if (!isNaN(uid)) opts.uid = uid
-+  if (!isNaN(gid)) opts.gid = gid
-   if (!isNaN(opts.uid)) opts.uid = +opts.uid
-   if (!isNaN(opts.gid)) opts.gid = +opts.gid
-   var name = c +" "+ a.map(JSON.stringify).join(" ")
diff --git a/debian/patches/2001_no-false-attribs.patch 
b/debian/patches/2001_no-false-attribs.patch
index 1afb202..f722f74 100644
--- a/debian/patches/2001_no-false-attribs.patch
+++ b/debian/patches/2001_no-false-attribs.patch
@@ -6,19 +6,30 @@ Description: Comply with Expat+no-false-attribs license
  package to displays its own bug tracker instead.
 Forwarded: not-needed
 Author: Jérémy Lal 
-Last-Update: 2012-03-13
+Last-Update: 2013-04-24
+
+---
+ lib/utils/error-handler.js |   10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/lib/utils/error-handler.js b/lib/utils/error-handler.js
+index 88ce742..0d1bc94 100644
 --- a/lib/utils/error-handler.

Bug#683943: luaotfload bug

[Frank Küster]

Élie Roux  writes:

> Dear all,
>
> this is indeed a luaotflaod "feature", thank you for noticing it! I am
> currently improving it and will fix the behaviour: it will now look
> into fontconfig files even if OSFONTDIR is set... The new version
> should be on CTAN today or tomorrow.

Thanks for the heads up, looking forward to see the update in Debian!

Regards, Frank


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

Bug#706106: mirror submission for debian.cse.msu.edu

[Adam Pitcher]

It finished.  Re-running now.  I see the correct name listed now.
Apache is modified to contain:
  ServerAlias ftp.us.debian.org http.us.debian.org

As long as web and ftp both go to the IP: 35.9.25.26, it should just work.

Also, I put the root of the web at the directory before /debian.  I 
believe that is what you want, right?  If not, let me know.


I think we are good to go. The debian-cd is chugging along at 235G so 
far.   Let it go overnight and see where it stands.


Adam


On 04/25/13 14:30, Raphael Geissert wrote:

Hi Adam,

Thanks for the prompt response.

On 25 April 2013 20:24, Adam Pitcher  wrote:
[...]

  This morning I pointed to
mirrors.kernel.org and it's runnning again.  The debian-cd took more space
than anticipated so I had to stop everything and resize my volume.  They are
running again.
Funny you should say, I was just editing my config to change the name as
your email came in.


I see, thanks.

Another run is needed after the modification to the config file in
order for the change to the mirror name to be visible.


Hopefully that last sync from kernel.org will be done soon.  Let me know if
you need anything else from me.


How about the part of handling requests as if it was
{http,ftp}.us.debian.org? In case you also want to take EGR's place
there too.

Will take another look at it later and add your mirror to the list if
I don't spot any blocker.

Kind regards,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net




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

Bug#706166: lintian: outdated outdated-autotools-helper-file description

[Jakub Wilk]

Package: lintian
Version: 2.5.12
Severity: minor

“The referenced file has a time stamp older than April of 2012 […]. 
This usually means that the source package will not build correctly on 
AVR32, for which a Debian port is currently in progress, […].”


But AVR32 port has been dead for years…
We forgot to update architecture name when bumping the date to Apr 2012.
Let's make s/AVR32/ARM64/.

--
Jakub Wilk


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

Bug#704057: [cacti/debian-sid] Add patch for loadavg_multi.pl to fix locale (Closes: #704057)

[Paul Gevers]

tag 704057 pending
thanks

Date: Sun Mar 31 21:44:11 2013 +0200
Author: Paul Gevers 
Commit ID: 48cf2dbe0cb4b9eb8ad49b08a02302f8a4839b2c
Commit URL: 
http://git.debian.org/?p=pkg-cacti/cacti.git;a=commitdiff;h=48cf2dbe0cb4b9eb8ad49b08a02302f8a4839b2c
Patch URL: 
http://git.debian.org/?p=pkg-cacti/cacti.git;a=commitdiff_plain;h=48cf2dbe0cb4b9eb8ad49b08a02302f8a4839b2c

Add patch for loadavg_multi.pl to fix locale (Closes: #704057)

  


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

Bug#602034: jpeg8 vs jpeg-turbo

[Mike Gabriel]

Hi all,

On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote:


On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
 wrote:

On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:

Hi Bill and Debian Developers,

My proposal is:
A. Add libjpeg-turbo to Debian archive (that's easy)
B. Add required provides/alternatives for libjpeg62-dev and
libjpeg8-dev (where API/ABI match)
C. Decide which package should provide default libjpeg-dev library

1.  
https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian

2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034


As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has  
more feature.


I do not see libjpeg-turbo as a suitable replacement. It has
1) an different license.
2) much more security issues in a much smaller timeframe.
3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.


Bill,

sorry to barge in, but as a maintainer of the most prominent rev-deps
of libjpeg (libgd2 & php5-gd), I would like to have some questions
answered, and I cannot find the answer neither on http://www.ijg.org/
nor http://www.infai.org/jpeg/.

1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
2. What's the legal status of IJG?
3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
4. Is there a (public) bug tracker?
5. Is there a source repository?
6. Is there a mailing list for libjpeg development/users?
7. How do I contribute code to IJG libjpeg?
8. There are new features incorporated to libjpeg? Is that a community
process? Or how are the changes driven? IJG (and the features they
implement in libjpeg) is independent from jpeg.org (the standards
committee).
9. Is there a documentation for new features of libjpeg (DCT,
SmartScale), so independent implementations can be done?
10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
comment rant under: http://blog.kaourantin.net/?p=116)


All questions are really good questions. Some of them have already  
been answered in the backlogs of #602034 [1] and the-merged-with bug  
#612341 [2].


Reading through both of them is probably a good idea for all who are  
interested in the complete story.


Esp. some statements from Guido Vollbeding [3] make me ask myself:  
hey, what kind of guy is that and what is the stand of the IJG in the  
free software ecosystem. His arguing tends to be somehow aggressive  
and inbalanced. One quote that shows what I mean (taken from [3]):


"""
It seems that Bill Allombert is still one of the few sane people out
there, many others have apparently gone mad.
I don't care for the ignorant people.
"""

@Bill: Unfortunately, I am not an expert with image processing, but  
most of what I have read in this thread speaks for re-thinking the  
current strategy of staying with libjpeg IJG.


Can this be a proposal? Package libjpeg and libjpeg-turbo using an  
alternatives setup and thus, making both libs installable in parallel.  
Packagers can then build-depend on one or the other libjpeg  
implementations.


Greets,
Mike

[1] http://bugs.debian.org/602034
[2] http://bugs.debian.org/612341
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612341#116


--

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

pgpw389vH7CSh.pgp
Description: Digitale PGP-Unterschrift

Bug#706163: debian-installer: non-lvm+lvm setup with expert_recipe doesn't work with wheezy

[Michael Moll]

Package: debian-installer
Severity: important
Tags: d-i

Hi,

I'm using Foreman as provisioning server and having a template which I'm using
for unattended installations of Debian and Ubuntu. It works for Debian 6.0 and
Ubuntu 12.04. Today I tried it with Debian 7.0 and I'm getting:

Unexpected error while creating volume group
Autopartitioning using LVM failed because an error occurred while creating the
volume group.

The pxelinux and preseed files can be found here: http://space.kvedulv.de/d-i/
The debug logs of the installation process can be found there in the "logs"
subdirectory.


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

Bug#706106: mirror submission for debian.cse.msu.edu

[Adam Pitcher]

I had the original dump from EGR since it was just across the network 
from us.  But that was a 1 time thing.  I had a booboo in my ftpsync and 
lost 15G.  So I pointed to PSU in hopes of it being quick.  I let it run 
yesterday when I filled out the form.  This morning I pointed to 
mirrors.kernel.org and it's runnning again.  The debian-cd took more 
space than anticipated so I had to stop everything and resize my volume. 
 They are running again.
Funny you should say, I was just editing my config to change the name as 
your email came in.


Hopefully that last sync from kernel.org will be done soon.  Let me know 
if you need anything else from me.


Adam


On 04/25/13 14:18, Raphael Geissert wrote:

Hi,

First of all, thanks for mirroring Debian.

On 24 April 2013 20:46, Adam Pitcher  wrote:

Package: mirrors
Severity: wishlist

Submission-Type: new
Site: debian.cse.msu.edu
Type: leaf
Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
IPv6: no
Archive-upstream: syncproxy.wna.debian.org


According to the trace files you are mirroring from psu.edu?
There's something strange with the trace files, have you modified the
exclude rules or the script itself?

Could you please adjust your ftpsync.conf's MIRRORNAME to debian.cse.msu.edu?


Updates: push
Maintainer: Adam Pitcher 
Country: US United States
Location: East Lansing, Michigan
Sponsor: Computer Science and Engineering at Michigan State University 
http://www.cse.msu.edu
Comment: I want to take over where ftp.egr.msu.edu has left off.  I know them 
and use debian for our labs so I figured it would be good to pick up the slack.
  We are on gigabit network with ample space and resources.
  I filled out push-triggered even though that is not how I set everything up.  
I will need to make sure all that works with you guys.  I am also asking if you 
want a push-server too, since egr was one.  I just have a few questions to work 
with you on.  thanks
  (debian-cd is in the process of downloading, but wanted to get this first 
part moving first)


Thanks for that. If you are willing to take the load of
ftp.egr.msu.edu it would be great, but we should start by getting your
mirror on the list, setup the ssh trigger and make your httpd handle
requests as ftp.us.debian.org/http.us.debian.org.


Thanks again,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net




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

Bug#706106: mirror submission for debian.cse.msu.edu

[Raphael Geissert]

Hi Adam,

Thanks for the prompt response.

On 25 April 2013 20:24, Adam Pitcher  wrote:
[...]
>  This morning I pointed to
> mirrors.kernel.org and it's runnning again.  The debian-cd took more space
> than anticipated so I had to stop everything and resize my volume.  They are
> running again.
> Funny you should say, I was just editing my config to change the name as
> your email came in.

I see, thanks.

Another run is needed after the modification to the config file in
order for the change to the mirror name to be visible.

> Hopefully that last sync from kernel.org will be done soon.  Let me know if
> you need anything else from me.

How about the part of handling requests as if it was
{http,ftp}.us.debian.org? In case you also want to take EGR's place
there too.

Will take another look at it later and add your mirror to the list if
I don't spot any blocker.

Kind regards,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Bug#706162: ITP: luxio -- Posix bindings for Lua

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius 

* Package name: luxio
  Version : 1.0
  Upstream Author : Rob Kendrick 
* URL : http://www.rjek.com/software.html
* License : MIT (Same as Lua)
  Programming Lang: Lua
  Description : Posix bindings for Lua

Lightweight UNIX I/O and POSIX binding for Lua

1. Reasonably good coverage of POSIX and BSD Sockets, including IPv6,
   and some GNU extensions.
2. Meant to be buildable anywhere that is POSIX.1-1996.  If it's not,
   there's a bug.  These are likely, as I have nowhere other than
   Linux to test.
3. Low-level.  You get the return values and the errno for the bound
   functions where possible.  Others take a table to fill in, or
   may return tables.
4. High-level wrapper library providing nice IO access and to misc.
   utility functions.  Generates useful errors in assert()able form,
   and provides meaningful __tostring metamethods to aid debugging.
5. A high-level poll()-based event dispatch library.
6. Sub-process handling library (read/write io.popen with job control).
7. A prototype POSIX Message Queue-based IPC scheme that can serialise
   most simple Lua values.  (No closures, userdata, etc)

This package is needed as a dependency for Gitano, for which an ITP will
be filed later.

I will be co-maintaining this package with Daniel Silverstone.


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

Bug#648160: util-vserver: wheezy vserver guests don't start

[micah]

Hi Carlos,

Carlos Alberto Lopez Perez  writes:

> So please: update the package to a newer upstream version.

util-vserver was removed from wheezy as was the kernel support. It is
not surprising that this version doesn't work, it only worked with
squeeze. At this stage, it will not be included in wheezy at all.

If you are interested in doing work on the user-space utilities in
Debian, or doing the work to provide the support in the kernel, it would
be welcome.

With your permission, I'd like to close this bug.

Micah


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

Bug#705508: mirror submission for ftp.wallawalla.edu

[Raphael Geissert]

Hi,

Thanks for mirroring Debian. Before proceeding with the registration
of your mirror, there are a few issues that need to be addressed.

On 16 April 2013 00:08, Unix Sys Admin  wrote:
> Package: mirrors
> Severity: wishlist
>
> Submission-Type: new
> Site: ftp.wallawalla.edu
> Type: leaf
> Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 
> kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
> Archive-ftp: /pub/mirrors/debian/
> Archive-rsync: debian/

* Do you also plan to offer it over HTTP?
* Please adjust the MIRRORNAME configuration in your ftpsync.conf to
match "ftp.wallawalla.edu"

> IPv6: no
> Archive-upstream: debian.osuosl.org
> Updates: four

It seems that your mirror hasn't updated in the last four days. Could
you please take a look at it?

> Maintainer: Unix Sys Admin 
> Country: US United States
> Location: College Place, WA
> Sponsor: Walla Walla University http://www.wallawalla.edu/

How much bandwidth is available?

Thanks again.

Kind regards,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Bug#706106: mirror submission for debian.cse.msu.edu

[Raphael Geissert]

Hi,

First of all, thanks for mirroring Debian.

On 24 April 2013 20:46, Adam Pitcher  wrote:
> Package: mirrors
> Severity: wishlist
>
> Submission-Type: new
> Site: debian.cse.msu.edu
> Type: leaf
> Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 
> kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
> Archive-ftp: /debian/
> Archive-http: /debian/
> Archive-rsync: debian/
> IPv6: no
> Archive-upstream: syncproxy.wna.debian.org

According to the trace files you are mirroring from psu.edu?
There's something strange with the trace files, have you modified the
exclude rules or the script itself?

Could you please adjust your ftpsync.conf's MIRRORNAME to debian.cse.msu.edu?

> Updates: push
> Maintainer: Adam Pitcher 
> Country: US United States
> Location: East Lansing, Michigan
> Sponsor: Computer Science and Engineering at Michigan State University 
> http://www.cse.msu.edu
> Comment: I want to take over where ftp.egr.msu.edu has left off.  I know them 
> and use debian for our labs so I figured it would be good to pick up the 
> slack.
>  We are on gigabit network with ample space and resources.
>  I filled out push-triggered even though that is not how I set everything up. 
>  I will need to make sure all that works with you guys.  I am also asking if 
> you want a push-server too, since egr was one.  I just have a few questions 
> to work with you on.  thanks
>  (debian-cd is in the process of downloading, but wanted to get this first 
> part moving first)

Thanks for that. If you are willing to take the load of
ftp.egr.msu.edu it would be great, but we should start by getting your
mirror on the list, setup the ssh trigger and make your httpd handle
requests as ftp.us.debian.org/http.us.debian.org.


Thanks again,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Bug#502305: ulogd2 packaging effort

[Chris Boot]

Hi all,

I've been semi-packaging ulogd-2.x for some time for my own personal
use, and after some input from a colleague of mine have been persuaded
to tidy up my package and post it to mentors.debian.net.

I'm just getting started and setting up my account on the above, but in
the meantime my effort can be found at:

http://apt.bootc.net/debian/pool/main/u/ulogd2/ulogd2_2.0.2-3.dsc
https://github.com/bootc/ulogd2

I'd love to have some comments, positive or negative, about my package.
If you'd rather I teamed up with some of the existing efforts, then
please do say so too, as I'd be happy to help.

Cheers,
Chris

-- 
Chris Boot
bo...@bootc.net




signature.asc
Description: OpenPGP digital signature

Bug#706110: libgnome{, vfs}2-common: fails to upgrade from squeeze: prerm failure: gconf-schemas: not found

[Julien Cristau]

On Thu, Apr 25, 2013 at 15:05:47 +0200, Michael Biebl wrote:

> All packages shipping gconf schemas have a Depends on gconf2. It is
> generated via dh_gconf which adds "gconf2 (>= 2.28.1-2)" to misc:Depends.
> 
> This version is already satisfied by gconf2 from squeeze. We could bump
> that and binNMU the rdeps. But then we'd have some arch:all rdeps (which
> would need sourceful uploads) and I'm actually not sure if a more
> tightened Depends actually ensures that the new gconf2 is unpacked
> before its rdeps. Does anyone know?
> 
No way are we touching heaps of packages at this point.  Either there's
an isolated fix in one package, or this issue gets a wheezy-ignore.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#706110: libgnome{, vfs}2-common: fails to upgrade from squeeze: prerm failure: gconf-schemas: not found

[Julien Cristau]

On Thu, Apr 25, 2013 at 16:26:23 +0200, Josselin Mouette wrote:

> Le jeudi 25 avril 2013 à 15:05 +0200, Michael Biebl a écrit : 
> > A dangling /usr/bin/python symlink is indeed bad. At least that
> > convinced me to never use anything pythonish in the maintainer scripts
> > in the future.
> 
> I don’t think it is a problem for scripts in the postinst, nor in
> triggered scripts. I thought prerm was supposed to be OK as long as
> there are no loops in the upgrade (the policy is vague on the subject),
> but this is not the first such problem I hear of.
> 
It's very much a problem in triggered scripts.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#705891: debian-lan-config: Misspelling in English description

[Andreas B. Mundt]

tags 705891 +pending

Dear Michael,

On Sun, Apr 21, 2013 at 02:03:25PM -0400, Michael Welsh Duggan wrote:
>
> The word "loosing" is incorrect.  It should be "losing."
>

Thank you very much for reporting!  It has been fixed already in git,
and will be corrected with the next upload.

Best regards,

 Andi


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

Bug#706154: gecko-mediaplayer: claims that an additional plugin is needed, but standalone gnome-mplayer plays the video

[Sebastian Ramacher]

Control: tags -1 + moreinfo

Hi,

On 2013-04-25 16:54:00, Francesco Poli (wintermute) wrote:
> Package: gecko-mediaplayer
> Version: 1.0.8-1
> Severity: normal
> 
> Hello,
> I wanted to check that bug #689862 is still fixed in
> gnome-mplayer/1.0.8-1 + gecko-mediaplayer/1.0.8-1
> 
> To my great surprise, the following happened:
> 
>   0) I started iceweasel
> 
>   1) I opened a video in a new tab, for instance:
>  http://content.funny-base.com/videos2/trunkmonkey01.wmv
> 
>   2) iceweasel behaves exactly as if none of the installed plugins were 
>  able to deal with this file type: it popped up a dialog window,
>  offering me to download the video or to open it with GNOME MPlayer
> 
>   3) I chose to open the video with GNOME MPlayer and a standalone
>  instance of gnome-mplayer appeared, playing the video correctly
> 
>   4) I then tried the web page that embeds the same video:
>  http://www.funny-base.com/videos/792-trunkmonkey01.html
> 
>   5) the NoScript extension blocked the JavaScript code;
>  I right-clicked on the page and selected "Temporarily allow
>  funny-base.com" from the NoScript submenu
> 
>   6) an iceweasel warning appeared inside a yellow bar at the top of
>  the web page, claiming that "Additional plugins are required to
>  display all the media on this page"; the area that should embed
>  the video showed a similar warning ("A plugin is needed to display
>  this content")
> 
>   7) I don't want to install plugins for my regular user, I strongly
>  prefer to install Debian packages (as root), so that plugins and
>  extensions are installed system-wide (for all the users); but,
>  still, I wanted to see what would have have been installed: I tried
>  to click on the "Install plugin" link
> 
>   8) a dialog window appeared running the Plugin Finder Service and
>  saying that "No suitable plugins were found", "Unknown Plugin
>  (video/x-ms-wmv)"...
>  N.B.: with other videos, the MIME type claimed to be associated
>  to an unknown plugin may be different (for instance
>  video/x-msvideo)
> 
> Why does gecko-mediaplayer claim that additional plugins are needed
> to play the above-mentioned videos, while gnome-mplayer is able to
> play them, when running in a standalone window?
> 
> Is this a bug or did I misunderstand something?
> 
> The same web pages used to work correctly with gnome-mplayer/1.0.7-2
> + gecko-mediaplayer/1.0.6-1, hence this looks like a regression...

Did you change the settings regarding Windows Media Player emulation
(Settings / Plugin)? It defaults to being enabled and I just checked
that it indeed is enabled by default for a new user and I'm able to
watch the videos with gecko-mediaplayer in a new profile.

Regards
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#585122: (no subject)

[Sergei Golovan]

Hi Roland.

Currently, epmd looks at the ERL_EPMD_ADDRESS environment variable
which contains a comma separated list of IP addresses to bind. So, you
can bind epmd to the loopback address only (for wheezy and future
releases, not for squeeze).


On Thu, Apr 25, 2013 at 7:04 PM, Roland Hieber  wrote:
> Is there any progress on this?
>
> I can only support the -loopback option. How many users do need to run
> distributed applications after all? And if they need to, they probably
> know how to configure epmd properly. On the other hand, every single
> user who chooses to install an Erlang application that does not
> neccessarily need distributed access (like ejabberd, and even gwibber
> through CouchDB) opens a security hole on their system WITHOUT EVEN
> KNOWING (where is the /usr/share/doc/erlang-base/README entry for that?)
>
> From a security standpoint, the strategy to bind to 0.0.0.0 by default
> is absolute nonsense and potentially hurts more users than it eases
> configuration. This is not the good old Debian way to do.
>
>  - Roland
>



-- 
Sergei Golovan


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

Bug#706114: xfonts-utils: insufficient zlib1g dependency

[Guillem Jover]

On Thu, 2013-04-25 at 14:51:29 +0200, Andreas Beckmann wrote:
> On 2013-04-25 10:39, Guillem Jover wrote:
> > I guess the correct solution though, is to change update-fonts-* and
> > any other script in xfonts-utils calling mkfont* from other maintainer
> > scripts, to only run if xfonts-utils itself is configured or being
> > configured, and calling these through xfonts-utils maintainer scripts
> > too, so that if xfonts-utils and something else using it like gsfonts-x11
> > are both unpacked on the same run, the actual update-fonts-* executions
> > will be delayed until xfonts-utils is itself configured, at which point
> > the scripts should be able to run. I don't think this would be much
> > more difficult to prepare.
> 
> Sounds like a job for triggers (but there is currently a dpkg bug that
> causes it to run triggers for packages that are not configured (or their
> dependencies are not)

Right, sorry, I didn't mention triggers exactly for that reason.
Although this one should be easier to switch during jessie, as these
packages do not need to await processing from xfonts-utils, which
should avoid the cycles that enable that bug.

Thanks,
Guillem


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

Bug#705800: blueman: Headset - Connection Failed: Connect failed

[KeyofBlueS]

> I think I found a mistake in [1]. Could you please
>
> - open your /usr/lib/python2.7/dist-packages/blueman/main/PulseAudioUtils.py
> (as root)
>
> - go to lines 433 and 436
>
> - change sink to source
>
> and see if that fixes the problem.
>
> Thanks!
>
> [1]
> https://bazaar.launchpad.net/~blueman/blueman/trunk/revision/724#blueman/main/PulseAudioUtils.py

Hi,

Unfortunately it doesn't work.

But I've a more complete output for you, it shows when headset
correctly connect the first time after bluetooth service was
restarted,
hope it can give some help:

(N.B. changes to PulseAudioUtils.py have been reverted to original
1.23+update1-1)


### blueman 1.23+update1-1 loaded AFTER bluetooth service was
restarted, so it works the first time I turn the headset on ###

$ blueman-applet
Loading configuration plugins
blueman-applet version 1.23 starting
Using gconf config backend
_
Load (/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:68)
['DBusService', 'NMDUNSupport', 'SerialManager', 'StandardItems',
'NMPANSupport', 'PulseAudio', 'TransferService', 'Networking',
'ExitItem', 'PPPSupport', 'KillSwitch', 'AppIndicator', 'StatusIcon',
'Headset', 'PowerManager', 'NetUsage', 'RecentConns', 'DiscvManager',
'ShowConnected', 'AuthAgent', 'Menu', 'DhcpClient']
Using gconf config backend
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
Using gconf config backend
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
Using gconf config backend
_
load_nap_settings
(/usr/lib/python2.7/dist-packages/blueman/plugins/applet/Networking.py:47)
Loading NAP settings
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
Using gconf config backend
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
Not loading PPPSupport because it's conflict has higher priority
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
Using gconf config backend
_
pa_context_event
(/usr/lib/python2.7/dist-packages/blueman/main/PulseAudioUtils.py:306)
1
_
on_load 
(/usr/lib/python2.7/dist-packages/blueman/plugins/applet/PulseAudio.py:160)
PulseAudio version: [2, 0, 0]
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
Using gconf config backend
_
on_load 
(/usr/lib/python2.7/dist-packages/blueman/plugins/applet/KillSwitch.py:40)
Using the new killswitch system
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
Using gconf config backend
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
/usr/lib/python2.7/dist-packages/blueman/plugins/applet/AppIndicator.py:44:
Warning: /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gsignal.c:2459:
signal `child-added' is invalid for instance `0x2c8d090'
  self.indicator.set_menu(applet.Plugins.Menu.get_menu())
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
Not loading NMPANSupport because it's conflict has higher priority
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
Using gconf config backend
_
update_menuitems
(/usr/lib/python2.7/dist-packages/blueman/plugins/applet/DiscvManager.py:132)
warning: Adapter is None
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
Using gconf config backend
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)
loading 
_
pa_context_event
(/usr/lib/python2.7/dist-packages/blueman/main/PulseAudioUtils.py:306)
2
_
update_state (/usr/lib/python2.7/dist-packages/blueman/main/KillSwitchNG.py:162)
State: True
_
on_switch_added
(/usr/lib/python2.7/dist-packages/blueman/plugins/applet/KillSwitch.py:61)
killswitch registered 1
_
on_obex_owner_changed
(/usr/lib/python2.7/dist-packages/blueman/plugins/applet/Tr

Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library

[Alessandro Ghedini]

On gio, apr 25, 2013 at 06:36:39 +0200, Julian Taylor wrote:
> On 25.04.2013 18:01, Alessandro Ghedini wrote:
> > * Package name: libzmq-libzmq2-perl
> >   Version : 1.07
> >   Upstream Author : Daisuke Maki 
> > * URL : https://metacpan.org/release/ZMQ-LibZMQ2/
> > * License : Artistic or GPL-1+
> >   Programming Lang: Perl
> >   Description : Perl bindings to the libzmq 2.x library
> >
> > [...]
>
> what is the difference to libzeromq-perl that we already have in unstable?

The ZeroMQ module (libzeromq-perl) is deprecated in favour of ZMQ::LibZMQ2
(libzmq-libzmq2-perl), ZMQ::LibZMQ3 and ZMQ. My intention would be to have
libzeromq-perl removed at some point soon (this is why it's not in wheezy, also
see #690680) but it's been taking me a long time (mostly because of a lack of
free time from my part).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#706062:

[Jörg Riesmeier]

Thank you for the suggestion. I just implemented the requested feature with 
the following commits:

http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=0df7cbcbe71fb0ee31ffd5a53ea003b9c1efdb0e
http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=6826ff093f114c77edaeea320f42a53a07812d66

Regards,
Jörg

> Package: dcmtk
> Version: 3.6.1~20121102-1
> Severity: normal
> 
> There is no way for dsrdump to actually print the SOP Class of a reference
> IMAGE. It always prints:
> 
>  
> the only exception is when the SOP Class is not known in which case:
> 
> OFCondition DSRImageReferenceValue::print(STD_NAMESPACE ostream &stream,
>   const size_t flags) const
> {
> const char *modality = dcmSOPClassUIDToModality(SOPClassUID.c_str());
> stream << "(";
> if (modality != NULL)
> stream << modality << " image";
> else
> stream << "\"" << SOPClassUID << "\"";
> 
> 
> It would be nice to have an option to print the SOP Class UID
> 
> Thanks


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

Bug#705613: ejabberd: SCRAM bug in GS2 Header parsing with optional parameters

[Konstantin Khomoutov]

tag 705613 +patch +pending
thanks

On Thu, 25 Apr 2013 16:40:29 +0200
"Stephen Röttger"  wrote:

> > Stephen, could you please help us and look at modifying your patch
> > so that it applies on 2.1.10?  My own Erlang skills are not up to
> > this task.  I'm referring to this Debian bug report [1].  And the
> > release time is unfortunately very close.
> 
> Hi, I backported the patch to the v2.1.10 tag of ejabberd, could you
> please verify that it works? I just tested it with the haskell
> testcase from joey hess.

Thanks!
I have verified it works both against Gajim 0.15.3 and the test case
from EJAB-1632.  Will ask for uploading and freeze exception now.


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

Bug#602034: jpeg8 vs jpeg-turbo

[Ondřej Surý]

On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
 wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>> Hi Bill and Debian Developers,
>>
>> My proposal is:
>> A. Add libjpeg-turbo to Debian archive (that's easy)
>> B. Add required provides/alternatives for libjpeg62-dev and
>> libjpeg8-dev (where API/ABI match)
>> C. Decide which package should provide default libjpeg-dev library
>>
>> 1. 
>> https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
>> 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
>> 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034
>
> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more 
> feature.
>
> I do not see libjpeg-turbo as a suitable replacement. It has
> 1) an different license.
> 2) much more security issues in a much smaller timeframe.
> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.

Bill,

sorry to barge in, but as a maintainer of the most prominent rev-deps
of libjpeg (libgd2 & php5-gd), I would like to have some questions
answered, and I cannot find the answer neither on http://www.ijg.org/
nor http://www.infai.org/jpeg/.

1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
2. What's the legal status of IJG?
3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
4. Is there a (public) bug tracker?
5. Is there a source repository?
6. Is there a mailing list for libjpeg development/users?
7. How do I contribute code to IJG libjpeg?
8. There are new features incorporated to libjpeg? Is that a community
process? Or how are the changes driven? IJG (and the features they
implement in libjpeg) is independent from jpeg.org (the standards
committee).
9. Is there a documentation for new features of libjpeg (DCT,
SmartScale), so independent implementations can be done?
10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
comment rant under: http://blog.kaourantin.net/?p=116)

I haven't been able to find answers at IJG or any linked sites, so as
you are so far the only one taking stand for IJG jpeg implementation,
I would like to to help me to answer those questions.

I wouldn't bother to care about libjpeg in Debian, but it's one of the
core graphics libraries, and I think we should strive for good
compatibility with the rest of the distros, applications and our
users. And the 'new features' of libjpeg seems to contradict this.

Ondrej
--
Ondřej Surý 


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