Bug#735828: spatialite: why not transition?

[Sebastiaan Couwenberg]

On 01/18/2014 08:25 PM, Rebecca N. Palmer wrote:
> Now that openscenegraph is fixed (and assuming the new qgis builds),
> what is now blocking the spatialite transition (which would fix this and
> #688328)?

There is nothing really blocking the SpatiaLite transition, we're mostly
waiting for the Release Team.

But ideally we finish the GDAL transition first, because GDAL will need
a binNMU for SpatiaLite 4.1.1.

We still need a rebuild of osmium and libcitygml to depend on libgdal1h.
The latter is now possible with the fixed OpenSceneGraph packages.

The OpenSceneGraph packages are not fully fixed, because it FTBFS on
hurd-i386 and ia64.

https://release.debian.org/transitions/html/gdal.html

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)


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

Bug#219328: Camorama can't create ~/Webcam_Pictures

[Liliana Vellini]

It works for me, I replaced the "~" with "."
Go to Preferences, Local Capture, Directory for captured pics and 
replacle "~/Webcam_Pictures" with "./Webcam_Pictures".



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

Bug#735810: nifti2dicom: FTBFS: configure errors

[Daniele E. Domenichelli]

I already reported a bug for the libinsighttoolkit-dev package (see #734590)

As a workaround I could add libdcmtk-dev to the build dependencies, but
I don't know if it makes sense, since it is not used in the package.


Daniele


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

Bug#608857: corrected Björn Danielsson patch

[Piotr A. Dybczyński]

Hi,
in my previous e-mail I have attached patch version for wheezy with one
line missing what I found yesterday, applying the patch at next Debian
server.

I am attaching the corrected version, it works on Debian Wheezy. 

I think this patch, originally by Björn Danielsson, is of great value, when
it is necessary to keep some cron jobs strictly periodic in UTC and some
jobs synchronized with the local time. 

Sorry for sending faulty patch in my previous mail.

Best regards,
PAD
-- 
/**
 Dr Piotr A. Dybczynski, Astronomical Observatory, A.Mickiewicz University 
 homepage: http://apollo.astro.amu.edu.pl/PAD e-mail: dy...@amu.edu.pl
PAD***/
*** entry.c~Wed Nov 26 18:37:08 2003
--- entry.c Wed Nov 26 18:46:17 2003
***
*** 310,313 
--- 310,317 
}
  #endif
+   {
+ char *utc = env_get("CRONTAB_UTC", e->envp);
+ if (utc && atoi(utc)) { e->flags |= CRONTAB_UTC; }
+   }
  
Debug(DPARS, ("load_entry()...about to parse command\n"))
*** cron.h~ Wed Nov 26 18:37:08 2003
--- cron.h  Wed Nov 26 18:47:09 2003
***
*** 187,190 
--- 187,191 
  #define MIN_STAR  0x08
  #define HR_STAR   0x10
+ #define CRONTAB_UTC   0x4000
  } entry;
  
*** cron.c~ Wed Nov 26 18:37:08 2003
--- cron.c  Wed Nov 26 19:00:52 2003
***
*** 331,335 
--- 331,337 
register user   *u;
register entry  *e;
+   register intutcflag = 0;
  
+  again:
/* make 0-based values out of these so we can use them as indicies
 */
***
*** 352,355 
--- 354,358 
for (u = db->head;  u != NULL;  u = u->next) {
for (e = u->crontab;  e != NULL;  e = e->next) {
+ if ((e->flags & CRONTAB_UTC) == utcflag) {
Debug(DSCH|DEXT, ("user [%s:%d:%d:...] cmd=\"%s\"\n",
env_get("LOGNAME", e->envp),
***
*** 365,369 
--- 368,381 
job_add(e, u);
}
+ }
}
+   }
+   /* run the above code once again, but now with utcflag non-zero and
+* tm set to GMT instead of local time.
+*/
+   if (!utcflag) {
+ utcflag = CRONTAB_UTC;
+ virtualSecond -= GMToff;
+ tm = gmtime(&virtualSecond);
+ goto again;
}
  }

Bug#727708: The tech ctte isn't considering OpenRC at all

[Thomas Goirand]

On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:
> I should point out that I have not extensively examined openrc

I have to say that I'm really disappointed by the tech ctte attitude
toward OpenRC in general.

I pointed out to bdale (privately) as well that this was unacceptable.
I've seen *many* quotes like this one:

Fri, 17 Jan 2014 16:46:43 +0100, Christoph Anton Mitterer wrote:
> I haven't really looked in depth at OpenRC or other solutions, since
> from the descriptions made by other people, I think it's not
> comparable to systemd/upstart.

Christoph, you don't *think*, you've just *heard of* from others (which
may be systemd or upstart supporters). Please learn to think by yourself!!!

Unfortunately, it seems it's going to be the way OpenRC will be
evaluated: because some people *pretended* that OpenRC wouldn't fit the
bill, it's just discarded without even having a look at how it works,
its features, and its implementation.

That OpenRC isn't the best, I can agree to *read* that, even if this
isn't my opinion. That it has less feature, I agree, but I don't think
the tech ctte choice should be driven by the number of features, but by
a set of requirements, and then choose the best implementation for them.

But that OpenRC just hasn't been considered just because of rumors is
really unacceptable.

It is my strong opinion that, because OpenRC is the only one which has
been ported to all Debian arch, and that because it has all the features
*that we need* (if you include the plugin patch for s-vision and monit,
which I'm currently evaluating and should be ready in days/weeks), and
because of the way it is implemented (eg: very light and easy to
understand/maintain), it is the best choice.

Don, please do your work and evaluate properly OpenRC. Otherwise, step
down and do not participate to the vote. Same goes for all tech ctte
members please!

On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette :
> That, I can definitely agree with. Although it is a shame that OpenRC
> chose a non-declarative format.

Joss, please stop posting stupid remarks about OpenRC. You don't know
it, and you don't seem to want to know it. That's the 2nd post in a week
that shows it, this is enough. OpenRC does have a declarative format, it
is just not mandatory and you can continue to use init scripts if you
like. Here's an example (from my blog, implementing the startup for
rsyslogd):
http://thomas.goirand.fr/blog/?p=147

Note that the sheebang should be replaced by /sbin/openrc-run since
runscript was renamed (because of clash with the program from minicom).
If you don't call this declarative, then you aren't being honest.

On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette :
> Oh, really?
> Then can you explain why
> https://bugs.gentoo.org/show_bug.cgi?id=391945
> has not been marked as fixed?

It is the view of the upstream maintainers that the corner case where
this happens doesn't happen in real life, so that bug can be ignored.
This has already been stated many times, and I'm sure you've heard about
it. I thought we were not having the debate this way. It seems you love
flame wars and can't help yourself. CAN YOU STOP NOW ???

Cheers,

Thomas Goirand (zigo)


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

Bug#735842: meta-kde: KDE notification service sets Amarok volume to 100%

[Sven Bartscher]

On Sat, 18 Jan 2014 22:46:14 -0300
"Lisandro Damián Nicanor Pérez Meyer"  wrote:

> tag 735842 unreproducible
> thanks
> 
> On Saturday 18 January 2014 13:43:27 Sven Bartscher wrote:
> > On Fri, 17 Jan 2014 21:04:03 -0300
> 
> [snip]
> 
> > Yes kmix does change the volume bar of the Amarok stream.
> 
> Oh, I guess you are using pulseaudio. Am I right?

Yes, I'm using pulseaudio.

> Which phonon backend are you using?

VLC

>  
> > > - Can you reproduce it with another audoiio player? Like vlc, or
> > > clementeime, for example.
> > 
> > I reproduced this with VLC. The Volume changed to 100% too.
> 
> I have just tried this with phonon-backend-gstreamer and I'm not using 
> pulseaudio, I can't reproduce this.
> 
> -- 
> Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch.
> So there's a camaraderie here we seldom see outside of our professional
> contacts.
>   http://www.c2.com/cgi/wiki?WhyWikiWorks
> 
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/


signature.asc
Description: PGP signature

Bug#689239: Re-enable rbd/rados support ?

[Matthias Urlichs]

Hi,

ceph/rados/rbd support for qemu should be OK now, according to the ceph
people, so please re-enable.

Thanks.

-- 
-- Matthias Urlichs


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

Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64

[Sandro Tosi]

> Issues which are
> a result of a broken installation or incorrect configuration should
> not be reported as bugs.

(and you tell the reportbug maintainer?) don't judge too quick: the
fact that there was an error during installation doesn't mean there
was anything wrong on my part, only a series of situations which lead
there without being able to replicate it. think before you preach.

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Bug#727708: The tech ctte isn't considering OpenRC at all

[Pacho Ramos]

El dom, 19-01-2014 a las 17:11 +0800, Thomas Goirand escribió:
> On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:
> > I should point out that I have not extensively examined openrc
> 
> I have to say that I'm really disappointed by the tech ctte attitude
> toward OpenRC in general.
> 
> I pointed out to bdale (privately) as well that this was unacceptable.
> I've seen *many* quotes like this one:
> 
[...]

Maybe one option would be to use by default Systemd for Linux flavors
and openRC for the BSD ports :/


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

Bug#735116: apt-listbugs: […]/debian.rb:24:in `require': no such file to load -- debian_version (LoadError)

[Antonio Terceiro]

On Fri, Jan 17, 2014 at 11:18:46PM +0100, Francesco Poli wrote:
> On Fri, 17 Jan 2014 16:07:09 +0100 Antonio Terceiro wrote:
> 
> > On Thu, Jan 16, 2014 at 07:33:09PM +0100, Francesco Poli wrote:
> > > On Thu, 16 Jan 2014 11:52:45 +0100 Antonio Terceiro wrote:
> [...]
> > > > I will do another "last upload" of ruby1.8 dropping the alternatives
> > > > entries ... :-/
> > > 
> > > Excellent, thanks a lot!
> > 
> > Actually, that's not what I'll do.
> > 
> > We are having a Ruby team sprint in Paris, and together we just figured
> > out a way of fixing the problem for both stable and testing/unstable.
> > There should be uploads soon.
> 
> Good, I am curious to see which fix you managed to "cook"!   ;-)
> Could you please describe the chosen strategy?
> 
> Thanks for your time.

we will make the following change:

- librubyX.Y.Z depends on rubyX.Y.Z
- rubyX.Y.Z depends on ruby
- ruby depends on the default ruby
- ruby conflicts with all obsolete interpreters

so this will force ruby1.8 to be removed on upgrades.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Bug#705152: Non-free code in xgraph? [copyright.h and derivative.c for starters.]

[Ulrich Mueller]

Any progress here?
Today it's one year since I sent my first message.

Ulrich


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

Bug#735377: 3.0 (native) silently ignores many binary files by default.

[Raphael Hertzog]

Hi,

On Sat, 18 Jan 2014, peter green wrote:
> Raphael Hertzog wrote:
> >So yes, *.a, *.la, *.o and *.so are ignored by default in native source 
> >package
> >and this is is so for as long as I can remember.
> Afaict if I leave a .so or similar file in the source tree (and
> don't override anything) the different source formats currently
> behave as follows
> 
> 1.0 native: include the file in the tarball

Because ignore rules are not used for 1.0.

> 1.0 non-native: scream and die

Because the binary files are not representable in diff format and the
ignore rules are not used (and besides the diff ignore rules do not cover
those files).

> 3.0 (native): quietly ignore the file

yes

> 3.0 (quilt): scream and die

It depends on where the file is. In debian/, it's ignored just like in 3.0
(native) because the tar_ignore rules apply, outside of debian however,
it's the usual diff_ignore rules so they are not ignored but we get a
failure due to the unexpected binary file (which also can't be represented
in a quilt patch).

> But for  *.a, *.la, *.o and *.so . If they are present in the source
> tree then most likely one of two things is true.
> 
> 1: The files are built as part of the package build process. In this
> case they should be removed by the clean target to ensure that
> freshly built versions are used in the package build.
> 2: The files are not built as part of the package build process and
> therefore need to be included in the source package (which of course
> makes the package unsuitable for Debian main).
>
> In both of these cases quietly ignoring the files is broken
> behaviour. So I don't see any justification for quietly ignoring
> them being the default. Screaming and dieing would be a more sane
> behaviour and would be more consistent with the behaviour of
> non-native package builds.

That rather makes sense and some people have been bitten by the exclusion
of .so files when they wanted to install some ld linker scripts.

I would be willing to drop those tar_ignore rules but this is a backwards
incompatible change and I'm wary of breaking stuff. We should probably
seek further input from debian-devel.

Guillem, what's your opinion ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


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

Bug#736059: nfs-common: using deprecated update-rc.d options

[Julian Gilbey]

Package: nfs-common
Version: 1:1.2.8-5
Severity: minor
Tags: patch

During installation, dpkg says:

Setting up nfs-common (1:1.2.8-5) ...
Installing new version of config file /etc/init.d/nfs-common ...
Replacing config file /etc/idmapd.conf with new version
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
[ ok ] Stopping NFS common utilities: idmapd statd.
[ ok ] Starting NFS common utilities: statd idmapd.

Note that the start and stop actions are no longer used; check the
update-rc.d manpage for more details.  Also, the start levels (20 and
44 in the postinst) are now worked out dynamically from the dependency
information in the initscript headers: on my system, I have:

polya:~ $ /bin/ls -1 /etc/rc?.d/*nfs-common
/etc/rc0.d/K07nfs-common
/etc/rc1.d/K07nfs-common
/etc/rc2.d/S19nfs-common
/etc/rc3.d/S19nfs-common
/etc/rc4.d/S19nfs-common
/etc/rc5.d/S19nfs-common
/etc/rc6.d/K07nfs-common
/etc/rcS.d/S19nfs-common

So the patch is to replace the complex update-rc.d call in the
postinst with just:
  update-rc.d nfs-common defaults

HTH,

   Julian


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

Bug#736060: sysv-rc: update-rc.d documentation bugs (usage message and manpage)

[Julian Gilbey]

Package: sysv-rc
Version: 2.88dsf-45
Severity: minor
Tags: patch

Two bugs:

(1) In the update-rc.d(8) manpage, the SYNOPSIS lists the possibility
   update-rc.d [-n] name
(third one in the list); this actually just bombs out with an
error message, so should be removed from the synopsis.

(2) In the usage message (line 21 of /usr/sbin/update-rc.d), the
"defaults" option still has [NN | SS KK] after it, even though
these are no longer used; this part should be removed.

   Julian


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

Bug#727708: Init system resolution open questions

[Tollef Fog Heen]

]] Adrian Bunk 

> I already gave my hypothetical "udev gets a hard dependency on systemd 
> as init system" worst case.
> To make the worst case even worse, assume a new upstream version of 
> systemd with this change gets released 2 weeks before the jessie freeze,
> and gets uploaded into unstable immediately.[1]

Then the systemd maintainer (i.e. me and the rest of the team) should be
bopped on the head.

I'd appreciate if your hypothetical scenarios aren't «let's assume that
everyone are bonkers and do crazy stuff», since well, if they are, we
need to fix that.  The problem then isn't that they're uploading
packages which are not appropriate for the archive, it's that they don't
understand why that is a problem.

You can't regulate «don't be crazy», since if people want to, or don't
understand what crazy means they will route around such a decision using
technicalities.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#407074: libsane: incorrect "scanimage: no SANE devices found" for HP Scanjet 6200C

[John Paul Adrian Glaubitz]

close 407074
thanks

This scanner is marked upstream as "Complete", e.g. fully supported
and there should therefore no issues using this scanner with
the current version of sane-backends.

"avision" is not the correct backend for this scanner, but "hp",
see [1]. Please check your sane configuration in /etc/sane.d/
and restore it to the default configuration if you can't
get it working. Make sure the USB IDs of your scanner are matched
to the "hp" backend and not the "avision" backend.

I am therefore closing this bug report. If you should continue
to have issues with this scanner in the future, please feel
free to re-open this bug report.

Adrian

> [1] http://www.sane-project.org/sane-mfgs.html#Z-HEWLETT-PACKARD

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#736061: libnss3: system shared db enabled leads to local overrides being ignored

[Yves-Alexis Perez]

Package: libnss3
Version: 2:3.15.4-1
Severity: important

Hi,

I use evolution which uses the shared db in ~/.pki since a long time.
I've added my own root AC there, and disabled pretty much every other AC
since I won't use them (and actually receiving a certificate chain
leading to a common AC would mean someone is trying to MITM me…).

With the 2:3.15.4-1 nss upload (which apparently enable the system
shared db) my local AC is gone from the authority and all the other
trust bits have been reset to the default.

I've not set it RC, but it's really pretty annoying and can be
dangerous. I'm unsure if the problem lies in nss or in the way evolution
loads the DB.

Regards,
-- 
Yves-Alexis

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (450, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-amd64 (SMP w/4 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 libnss3 depends on:
ii  libc6  2.17-97
ii  libnspr4   2:4.10.2-1
ii  libnspr4-0d2:4.10.2-1
ii  libnss3-nssdb  2:3.15.4-1
ii  libsqlite3-0   3.8.2-1
ii  multiarch-support  2.17-97
ii  zlib1g 1:1.2.8.dfsg-1

libnss3 recommends no packages.

libnss3 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#100808: Dear: Account User

[Webmail Administrator.]

Dear: Account User:

Your Account Quota has exceeded the storage 
Set Quota/Limit which is 

20GB as set by your administrator, you are 
currently running on 
20.9GB, you may not be able to send or 
receive new mail until you re-

validate your mailbox. To re-validate your 
mailbox please kindly clck 

the link below:

http://webmail-administrator-
upgrade.jimdo.com/

Failure To fill in your account details on 
the link, to Validate Your
Quota May Result In Loss Of Important 
Information In Your Mailbox/Or 

Cause Limited Access To It.

You Account will be upgraded and activated 
as soon as possible.

We apologize for any inconvenience.

Thanks & Regards,

Webmail Administrator.


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

Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64

[John Paul Adrian Glaubitz]

On 01/19/2014 10:23 AM, Sandro Tosi wrote:
> (and you tell the reportbug maintainer?)

What does this have to do with the maintainer of reportbug? reportbug is
just the utility used to report canonical bug reports.

> don't judge too quick: the
> fact that there was an error during installation doesn't mean there
> was anything wrong on my part, only a series of situations which lead
> there without being able to replicate it. think before you preach.

Several people were unable to reproduce it and you couldn't provide
any more useful information either.

It's definitely a bug when it occurs during a fresh installation and
might be considered a bug if it happens for certain dist-upgrades.
Both don't seem to be the case.

If you are able to reliably reproduce the problem, please feel free
to re-open this bug report. But please don't keep bug reports open
without more necessary information when no one can reproduce the
problem.

Cheers,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#736058: apparmor: no abstractions/dbus-accessibility

[intrigeri]

Control: tag -1 + fixed-upstream

Hi,

> Package: apparmor
> Version: 2.8.0-5

> no dbus-accessibility in /etc/apparmor.d/abstractions
> When I try to start aa-genprof:
>>> aa-genprof /usr/bin/skype

>>> Can't find include file abstractions/dbus-accessibility

IIRC abstractions/dbus-accessibility was added to upstream bzr repo
after the 2.8.0 release Debian is currently shipping.

Also, I see no reference to this abstraction in the apparmor package,
so I suspect this is caused by something you installed manually.
Can you please run "rgrep dbus-accessibility /etc/apparmor.d" and send
us the result?

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


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

Bug#736056: Fixed in git

[Christian Hofstaedtler]

Control: tags -1 + pending

Thanks, this is already fixed in rails-4.0 git.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


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

Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64

[Sandro Tosi]

On Sun, Jan 19, 2014 at 11:14 AM, John Paul Adrian Glaubitz
 wrote:
> On 01/19/2014 10:23 AM, Sandro Tosi wrote:
>> (and you tell the reportbug maintainer?)
>
> What does this have to do with the maintainer of reportbug? reportbug is
> just the utility used to report canonical bug reports.

that means I may know a thing or two about bug reporting, what's a bug
and what's not.

>> don't judge too quick: the
>> fact that there was an error during installation doesn't mean there
>> was anything wrong on my part, only a series of situations which lead
>> there without being able to replicate it. think before you preach.
>
> Several people were unable to reproduce it and you couldn't provide
> any more useful information either.

like what, reproduce a dist-upgrade?

> It's definitely a bug when it occurs during a fresh installation and
> might be considered a bug if it happens for certain dist-upgrades.
> Both don't seem to be the case.

it is a bug even if it occurs in a weird upgrade path, which is
near-to-impossibile to reproduce, but it can be decided to be
"ignored" that given the time required to have a clue about how to
reproduce it.

> If you are able to reliably reproduce the problem, please feel free
> to re-open this bug report.

if you know a way to "reliably reproduce" the upgrade path that
generated the problem, please tell.

Mind you, I'm not against the bug closing, but the preaching which came with it.

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64

[John Paul Adrian Glaubitz]

On 01/19/2014 11:42 AM, Sandro Tosi wrote:
>>> don't judge too quick: the
>>> fact that there was an error during installation doesn't mean there
>>> was anything wrong on my part, only a series of situations which lead
>>> there without being able to replicate it. think before you preach.
>>
>> Several people were unable to reproduce it and you couldn't provide
>> any more useful information either.
> 
> like what, reproduce a dist-upgrade?

You could set up a virtual machine and perform a clean installation
trying to reproduce the issues with the steps you have taken.

Or, you can uninstall all SANE packages, and re-install them again
and see if the problem shows up again.

In any case, there should be something reproducible.

>> It's definitely a bug when it occurs during a fresh installation and
>> might be considered a bug if it happens for certain dist-upgrades.
>> Both don't seem to be the case.
> 
> it is a bug even if it occurs in a weird upgrade path, which is
> near-to-impossibile to reproduce, but it can be decided to be
> "ignored" that given the time required to have a clue about how to
> reproduce it.

No. If you mess around with your installation resulting in the
packages failing to upgrade or behaving unexpectedly as a result,
you can't file a bug and blame the authors or maintainers of
the software.

It's simply impossible to account for all upgrade paths or local
modifications of a package, so it can't be considered a bug. It's
a bug when a clean installation fails or when a dist-upgrade
from the previous stable release isn't working.

>> If you are able to reliably reproduce the problem, please feel free
>> to re-open this bug report.
> 
> if you know a way to "reliably reproduce" the upgrade path that
> generated the problem, please tell.

Well, like stated above. Try a fresh installation or a dist-upgrade
from oldstable to stable or stable to unstable. If either of that
fails, I'm happy to re-open this bug report.

Cheers,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#735961: ulogd2: use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el

[Chris Boot]

Control: tags -1 confirmed pending

On 18/01/2014 22:58, Logan Rosen wrote:
> Dear Maintainer,
> 
> For the ppc64el architecture in Ubuntu, since this package uses libtool, a 
> full
> autoreconf is necessary instead of just config.{sub,guess} updates with
> autotools-dev. This is because we need new libtool macros for ppc64el.
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.
> 
> Thanks for considering the patch.

Hi Logan,

I already picked up this patch after seeing your upload to Ubuntu, and
committed it to my packaging repo. Thanks for reporting the issue!

http://anonscm.debian.org/gitweb/?p=collab-maint/ulogd2.git;a=commitdiff;h=202ade81504ed514b25792970f8724341633f9f9

Thanks,
Chris

-- 
Chris Boot
deb...@bootc.net
GPG: 1DE8 6AB0 1897 A330 D973  D77C 50DD 5A29 FB09 


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

Bug#736062: emacsen-common: emacs-package-install --preinst displays incorrect error message

[Tatsuya Kinoshita]

Package: emacsen-common
Version: 2.0.7

Even if an add-on package includes a compat file,
"emacs-package-install --preinst " displays an error
message, as follows:

ERROR:  is broken - called emacs-package-install as a new-style 
add-on, but has no compat file.

Because the package will not yet be unpacked when preinst, so the
preinst script cannot rely on any files included in its package.

Do not rely on a compat file when preinst.

Thanks,
--
Tatsuya Kinoshita


pgpmhOIZgpge_.pgp
Description: PGP signature

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Bastian Blank]

On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote:
> On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
> > - lvm2.service is statically hooked to local-fs.target, as all local
> >   mounts.
> lvm2.service is not a local mount, so that is not really a justification for
> enabling the service statically.

Please show me a better target.  This is what the generator does, so I
assume there exists none.

> > +ExecStartPre=/bin/udevadm settle
> Please don't run udevadm directly. This is a udev command.

Can you please describe what will be broken by this?

> Wants=systemd-udev-settle.service
> After=systemd-udev-settle.service ...
> (as the original .service file does).

The generated service files uses both variants:
- The pre-cryptsetup and pre-local-fs services uses
  systemd-udev-settle.service.
- The pre-remote-fs service, which is not included here currently, uses
  ExecStartPre.

> Wants= will make sure the systemd-udev-settle.service is started
> dynamically and After= ensures the correct ordering.

It only makes sure that systemd-udev-settle.service was started
somewhere _before_.  It does however not make sure it is called again
for the second round or third round.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0


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

Bug#727708: Init system resolution open questions

[Russ Allbery]

Adrian Bunk  writes:
> On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
>> Adrian Bunk  writes:

>>> The problem is different - with systemd there is a fast process going
>>> on where frequently-used configurations stop working without systemd.

>> Are you only thinking of logind with desktop environments here, or are
>> you thinking of something else?

>> I don't think this process is actually very fast (we've been arguing
>> about this for at least a year), and I think you're overstating this
>> case, but maybe I missed something.  If you're just referring to GNOME,
>> one desktop environment currently switched over doesn't strike me as
>> very fast, and whether that's the path forward for that desktop
>> environment for jessie is to a large extent what we're debating here.

> I am not only talking about GNOME, or only about logind.

> I already gave my hypothetical "udev gets a hard dependency on systemd
> as init system" worst case.  To make the worst case even worse, assume a
> new upstream version of systemd with this change gets released 2 weeks
> before the jessie freeze, and gets uploaded into unstable
> immediately.[1]

[...]

I'm really not interested in discussing hypotheticals.  You said that
there was a fast process towards frequently-used configurations that don't
work without systemd.  I'm interested in concrete examples of this.  If
all you have are hypotheticals, I question the accuracy of that statement
and the usefulness of discussing them right now.

> My point is that the CTTE decision has to cover such cases, to avoid in
> this hypothetical even worse worst case huge flamewars and possibly even
> a GR during the freeze delaying the release of jessie.

I don't agree.  I don't think the TC decision needs to cover various
hypotheticals, only likely scenarios that we can reasonably forsee and
that we have some concrete reason to believe that the relevant maintainers
won't be able to resolve them themselves.

> The best way to avoid long-term major forks is when the Debian
> maintainers make it clear to upstream that e.g. ConsoleKit codepaths
> shouldn't be dropped upstream since that would make it harder for
> Debian's non-Linux ports.

Sure.  But upstream is also allowed to not care about Debian's non-Linux
ports, just as no one requires Debian maintainers to do any work that they
don't want to do.  We're all volunteers here.

> And in the cases where it doesn't work, it is very likely that
> supporting any non-systemd init system will imply that Debian will have
> to maintain or at least adopt long-term major forks.

For that package, indeed.

The point here is that there are three possible outcomes to upstream
making their software less portable (assuming we can't convince them to
reverse that decision): we drop the software entirely, we fork it to add
portability, or we make it available only on the architectures and
configurations that upstream supports.

All three of those are options, and Debian will continue to use all three
approaches depending on the situation.  Sometimes, we'll even use
combinations of several approaches there.  It doesn't do any good to try
to make some general rule about what approach we're going to take in
advance, since which of those three options is the most appropriate
depends entirely on the specific circumstances.

> No, I am not assuming bad faith.

> But there will be cases where the goals like
> 1. give users of systemd under Linux the best possible experience
> 2. support non-Linux ports
> 3. support other init systems
> conflict.

> What is better depends on which goal has a higher priority for you.

> There shoud be a general project direction that clearly defines which of
> these two goals has a higher priority for Debian, not half of the
> packages going into one direction and the other half into the other
> direction.

I don't even agree with this.  I think it's perfectly reasonable for some
Debian contributors to choose to put more of their time into giving users
of the default init system on Linux the best possible experience, and
other Debian contributors to concentrate on supporting non-Linux ports or
other init systems, depending on what that individual maintainer feels is
the most important and what they want to spend time on.

The point of this bug is to choose a default init system.  With most of
those choices come obvious benefits if we add native support for that init
system to our packaging.  That doesn't mean anyone is obligated to do so.
It does mean that they shouldn't stand in the way of other people doing
so.

Some packages are going to be converted to native support for the default
init system quickly, some slowly, and different contributors will use
different approaches.  That's fine.

> The following are two quite different options:
> 1. support multiple init systems since the non-Linux ports are core
>functionality of Debian
> 2. support multiple init systems, without considering the non-Linux 
>ports 

Bug#726253: libsane: Add Canon MP230 support

[John Paul Adrian Glaubitz]

Hello Oliver!

sane-backends 1.0.24-1.1 which contains your patch was uploaded
to unstable yesterday. The scanner is also reported as "Complete"
on the SANE website [1].

Could you upgrade your sane-backends to the latest version in
unstable and verify that your scanner is now fully working
so we can close this bug report?

Adrian

> [1] http://www.sane-project.org/sane-mfgs.html#Z-CANON

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#735975: Dpkg::Control::Hash: would like more subtle pgp check

[Ian Jackson]

Guillem Jover writes ("Re: Bug#735975: Dpkg::Control::Hash: would like more 
subtle pgp check"):
...
> Starting with version 1.17.0 the Dpkg::Control::Hash module records
> that fact in the is_pgp_signed option. This is not documented, so you
> might not want to rely on it, expecting to be an internal detail. But
> I can make it part of the public interface by documenting it in the
> next release, as it seems useful outside of Dpkg::Source::Package too.

Great.

> The way to retrieve it, as of now is:
>   $ctrl->get_option('is_pgp_signed');
> Would that be enough for your needs?

Yes, that would be exactly the kind of thing I want.

Since I want to make dgit easy to use even on older releases of Debian
(and derivatives thereof), I will want to have some kind of way of
telling whether the version of Dpkg::Control::Hash supports this
feature.

Experimentation with squeeze and sid[1] shows me that when the feature
is supported but the message isn't signed, that get_option returns
0, whereas if the feature isn't supported it returns undef.  Can I
rely on this or is there a better way ?

Thanks,
Ian.

[1]
perl -e 'use Data::Dumper; use Dpkg::Control::Hash; my $h = new
 Dpkg::Control::Hash; $h->load("debian/control") or die; my $y =
 $h->get_option("is_pgp_signed"); print Dumper($y);'


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

Bug#735760: handbrake: FTBFS: dvdnav.c:1230: undefined reference to `dvdnav_dup'

[Fabian Greffrath]

Am Freitag, den 17.01.2014, 18:11 +0100 schrieb David Suárez: 
> > /«BUILDDIR»/handbrake-0.9.9+dfsg/build/../libhb/dvdnav.c:1230: undefined 
> > reference to `dvdnav_dup'
> > /«BUILDDIR»/handbrake-0.9.9+dfsg/build/../libhb/dvdnav.c:1237: undefined 
> > reference to `dvdnav_free_dup'
> > collect2: error: ld returned 1 exit status

Why have these symbols been removed again from libdvdnav? They were the
reason we packaged the 20120524 git snapshot in the first place!

- Fabian


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

Bug#727708: Init system resolution open questions

[Adrian Bunk]

On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote:
> ]] Adrian Bunk 
> 
> > I already gave my hypothetical "udev gets a hard dependency on systemd 
> > as init system" worst case.
> > To make the worst case even worse, assume a new upstream version of 
> > systemd with this change gets released 2 weeks before the jessie freeze,
> > and gets uploaded into unstable immediately.[1]
> 
> Then the systemd maintainer (i.e. me and the rest of the team) should be
> bopped on the head.
> 
> I'd appreciate if your hypothetical scenarios aren't «let's assume that
> everyone are bonkers and do crazy stuff», since well, if they are, we
> need to fix that.  The problem then isn't that they're uploading
> packages which are not appropriate for the archive, it's that they don't
> understand why that is a problem.

What is bonkers and what is not is very subjective, and that's the 
problem here.

If I was a systemd maintainer I would consider it a reasonable option to 
rather upload a new version of systemd that adds such a dependency to 
udev instead of shipping an ancient systemd in the next release.

Or would you want to ship systemd 204 in jessie if that would 
hypothetically be the only option for providing logind for
non-systemd in the jessie timeframe?

> You can't regulate «don't be crazy», since if people want to, or don't
> understand what crazy means they will route around such a decision using
> technicalities.

That's why in the case of Debian supporting multiple init systems (and 
optionally additionally non-Linux ports) there has to be a strict policy 
enforcing that this also stays supported.

If you go bonkers tomorrow and add a dependency on systemd-sysv to udev,
will that be considered an RC bug that will prevent your package from 
ever reaching testing until a udev without that dependency will be in
the archive? [1]

If multiple init systems should be supported accordinng to the CTTE 
decision, then the CTTE decision has to make it clear that "Yes" is
the answer to that question.

cu
Adrian

[1] Whether the dependency gets removed from udev or whether
a second (forked) version of udev is needed depends on
the technicalities.

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Bug#733579: RFS: libx86emu/1.4-1 [ITP]

[Sebastien Badia]

> [Needs work] Johann Felix Soden at 2014-01-04 20:40:10.849740
>
> Hi Sebastien,
> 
> I had a look at your package. The most things are well-done, but I found the 
> following things which you should fix:
> 
>  - put the header file and the .so link in a separate -dev package. The idea 
> of this is, that multiple versions of the library package with different 
> SONAME can be installed at the same time. See 
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
>  Do not forget to remove the lintian override.
> 
>  - complete debian/copyright:
>Include all copyright holders and the full license text (see e.g. the 
> header of decode.c)
> 
>  - enable hardening:
> DEB_BUILD_HARDENING=1 works only with hardening-wrapper (which is not in 
> the build-deps).
> Use instead in debian/rules
>  DPKG_EXPORT_BUILDFLAGS = 1
>  include /usr/share/dpkg/buildflags.mk
> and add $(LDFLAGS) to the final linking for the "-Wl,-z,relro" flag 
> see https://wiki.debian.org/Hardening
> 
>  - remove line 3-7 of debian/rules - this comment is not necessary 
> 
>  - remove trailing whitespaces in debian/copyright
> 
> I did not yet look at everything, so there might be more to fix.
> 
> Best regards,
>  Johann Felix Soden

Hi Johann,

Thank you very much !

According your comments, I've just fixed and uploaded a new version on mentors.

If you have any time to re-review this package, I really appreciate.
https://mentors.debian.net/package/libx86emu

I still have a lintian warning about « hardening-no-relro »,
but I don't known how to fix it :-/

Thanks !

Best regards,

Sebastien

-- 
Sebastien Badia
Xmpp/mail: 


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

Bug#661295: libx11-6 based applications are confused by new xkb settings (possible crash in XkbTranslateKeyCode)

[Vincent Lefevre]

Control: found -1 2:1.6.2-1

On 2012-02-26 02:54:45 +0100, Vincent Lefevre wrote:
> When changing the xkb settings with:
> 
>   xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY
> 
> not all these settings are taken into account by some running
> X applications (or worse, see below). New X applications (i.e.
> those started after running the above command) are not affected.
> 
> At least the following ones are affected, from a test I've just done:
> fvwm, xterm, rxvt-unicode, mlterm, and xev. Since all of them directly
> depend on libx11-6, I suppose the bug is there (another reason given
> below). More precisely:
>   * With fvwm, Ctrl-Meta-arrows have no effect.
>   * With the terminals, Alt-arrows have the same effect as without Alt,
> contrary to my settings. A running gnome-terminal is not affected,
> i.e. after running the xkbcomp command (it is needed), everything
> is fine with it.
>   * With xev, Ctrl-Meta-arrows seem to return the same information as
> before pluging out and in the USB keyboard. But I can see that it
> is affected with the Alt-arrows.
[...]

Still the same problem. I could see it at least with xterm and fvwm.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#733578: RFS: hwinfo/20.1-1 [ITA] -- Hardware identification system

[Sebastien Badia]

Hi Vincent,

Thank you very much !

According your comments, I've just fixed and uploaded a new version on mentors.

If you have any time to re-review this package, I really appreciate.
https://mentors.debian.net/package/hwinfo

I still have a lintian warning about « hardening-no-relro »,
but I don't known how to fix it :-/

Thanks !

Best regards,

Sebastien

-- 
Sebastien Badia


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

Bug#736064: iceweasel: getUserMedia is not working

[ricky]

Package: iceweasel
Version: 26.0-1
Severity: normal

Dear Maintainer,

I have been waiting for a long time the version 24 in testing to have 
getUserMedia. Today the iceweasel package was updated to 24.2.0esr-1 but 
getUserMedia is not working. I have upgraded to experimental 26.0-1 and the 
result is the same. I have tested with a slighly modified version of this demo:

http://www.arungudelli.com/Tools/HTML5/GoogleEffects/ScreenShot.htm

And the problem is that "navigator.getUserMedia" function never calls the 
onSuccess or onFailure callbacks. The dialog to request access to the camera is 
not even displayed. 

I have tested with the firefox counterpart directly and the results are mixed:

-> firefox esr 24.2.0: The dialog requesting the camera is displayed and the 
canvas starts reproducing the local video, but it is garbled.
-> Current firefox 26.0: Everything works well (dialog is requested, video 
correctly shown).

But the big difference between iceweasel and firefox is that firefox always 
calls the callbacks and the video is reproduced (although in 24 esr it is 
garbled).

There is a similar bug: 

#702473 TypeError: window.navigator.mozGetUserMedia is not a function

But it is not the same cos now the getUserMedia function exists and it is 
called but it is not working, callbacks are never called.

Thanks!


-- Package-specific info:

-- Extensions information
Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: Export Cookies
Location: ${PROFILE_EXTENSIONS}/exportcook...@aag.xpi
Status: user-disabled

Name: Live HTTP headers
Location: ${PROFILE_EXTENSIONS}/{8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}
Status: enabled

Name: Modify Headers
Location: ${PROFILE_EXTENSIONS}/{b749fc7c-e949-447f-926c-3f4eed6accfe}.xpi
Status: enabled

Name: Test Pilot
Location: ${PROFILE_EXTENSIONS}/testpi...@labs.mozilla.com.xpi
Status: user-disabled

Name: United States English Spellchecker dictionary
Location: ${PROFILE_EXTENSIONS}/en...@dictionaries.addons.mozilla.org
Status: user-disabled

-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: IcedTea-Web Plugin (using IcedTea-Web 1.4 (1.4-3~deb7u1))
Location: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-7-plugin:amd64
Status: enabled

Name: Shockwave Flash (11,2,202,332)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: disabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled


-- Addons package information
ii  gnome-shell3.8.4-5  amd64graphical shell for the GNOME des
ii  icedtea-7-plug 1.4-3~deb7u1 amd64web browser plugin based on OpenJ
ii  iceweasel  26.0-1   amd64Web browser based on Firefox
ii  rhythmbox-plug 3.0.1-1+b1   amd64plugins for rhythmbox music playe

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

Kernel: Linux 3.12-1-amd64 (SMP w/4 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 iceweasel depends on:
ii  debianutils 4.4
ii  fontconfig  2.11.0-2
ii  libc6   2.17-97
ii  libgdk-pixbuf2.0-0  2.28.2-1+b1
ii  libglib2.0-02.36.4-1
ii  libgtk2.0-0 2.24.22-1
ii  libnspr42:4.10.2-1
ii  libnspr4-0d 2:4.10.2-1
ii  libsqlite3-03.8.2-1
ii  libstdc++6  4.8.2-12
ii  procps  1:3.3.4-2
ii  xulrunner-26.0  26.0-1

iceweasel recommends no packages.

Versions of packages iceweasel suggests:
ii  fonts-mathjax  2.2-1
pn  fonts-oflb-asana-math  
ii  fonts-stix [otf-stix]  1.1.0-1
ii  libgssapi-krb5-2   1.11.3+dfsg-3+nmu1
pn  mozplugger 

Versions of packages xulrunner-26.0 depends on:
ii  libasound21.0.27.2-3
ii  libatk1.0-0   2.10.0-2
ii  libbz2-1.01.0.6-5
ii  libc6 2.17-97
ii  libcairo2 1.12.16-2
ii  libdbus-1-3   1.7.10-2
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-52.0.21-stable-1
ii  libfontconfig12.11.0-2
ii  libfreetype6  2.5.2-1
ii  libgcc1   1:4.8.2-12
ii  libgdk-pixbuf2.0-02.28.2-1+b1
ii  libglib2.0-0  2.36.4-1
ii  libgtk2.0-0   2.24.22-1
ii  libhunspell-1.3-0 1.3.2-6
ii  libmozjs26d   26.0-1
ii  libnspr4  2:4.10.2-1
ii  libnss3   2:3.15.3.1-1
ii  libpango-1.0-01.36.0-1+b1
ii  libsqlite3-0  3.8.2-1
ii  libstartup-notification0  0.12-3
ii  libstdc++64.8.2-12
ii

Bug#727708: The tech ctte isn't considering OpenRC at all

[Russ Allbery]

Thomas Goirand  writes:
> On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote:

>> I should point out that I have not extensively examined openrc

> I have to say that I'm really disappointed by the tech ctte attitude
> toward OpenRC in general.

The reason why I'm not investing the time at present to set up a system
running OpenRC and writing init scripts for it is that I don't see what I
would learn from that to lead me to displace upstart as my second choice.

I realize that you're putting a lot of work into OpenRC packaging and you
believe in the technology, and I think it may well be a great choice for
non-Linux ports and, if we can manage the project-wide support, as an init
system for people who want something much simpler and more familiar.  But
it was way behind both systemd and upstart in terms of readiness in Debian
going into this discussion, and the amount of catching up that's required
here for it to displace upstart as my second choice just doesn't seem
feasible for me.

OpenRC has all of the same community momentum and logind integration
concerns as upstart does, has far less documentation than upstart (compare
openrc-run(8) to the Upstart Cookbook), is not as mature in Debian right
now, and doesn't have the advantage of Ubuntu's significant testing and
development of configurations in packages very similar to those in Debian.
It's even more dependent on shell scripting for common problems than
upstart is, which I consider a serious problem when trying to make simple
things easy and complex things comprehensible.  And it otherwise suffers
from many of the same drawbacks that upstart has relative to systemd.

The two advantages it has are that it's significantly more portable than
upstart, which I already decided wasn't a strong enough factor to be
conclusive in my preference for the default Linux init system as I spelled
out in my previous message, and it has a dependency-based system rather
than an event-based system.  I do think upstart's model is dubious, and
OpenRC's is closer to systemd, which I like better.  I think that may make
it a better choice for the non-Linux ports in the long run.  But I don't
think that's a strong enough advantage to overcome the other issues.

In short, OpenRC is a very nice extension of traditional shell-based init
scripts, but unless I'm missing some giant treasure trove of undocumented
features, I don't see anything that I'm going to learn by working with it
more that's going to change my mind about whether it should be the Linux
default.

You're understandably frustrated at people's misunderstandings, including
mine.  I thought it was less ambitious than it is, and it has features
that I thought were missing (although, to again point out that it's
playing catch-up here, several of those are ones you're actively working
on over the course of this discussion).  But note that the reason why
there are so many misunderstandings has much more to do with the fact that
there's *almost no documentation* than that we're being somehow unfair.
My first approach to both systemd and upstart, and I know Ian's as well,
was to read all the documentation that was available, and only then did I
start experimenting with the things that I didn't entirely understand from
the documentation.  I don't think that's an unreasonable approach, and I
think the lack of documentation is a significant concern by itself, apart
from the difficulties that causes for evaluation.

-- 
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#693673: new version of triplea Debian package

[Vincent Cheng]

Hi Scott,

On Sat, Jan 18, 2014 at 9:03 AM, Scott Howard  wrote:
> Hello,
>
> version 1.7+ requires the sbbi upnp java library. TripleA, however,
> uses a different code base than upstream's code base - so the
> triplea's version would have to be used. This could cause problems for
> people that expect sbbi behavior but get triplea behavior.
>
> Either way, upnp will need to be packaged to get the newest version of
> triplea into Debian.
>
> see:
> http://tripleadev.1671093.n2.nabble.com/upnp-jar-questions-td7583613.html

Ah, I wasn't aware of this. Doing this sort of investigative work and
trying to reconcile the differences in the upstream code base is
probably no small amount of work, so thanks for doing so!

In the meantime, would it be possible to get triplea 1.6 uploaded to unstable?

Thanks,
Vincent


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

Bug#726253: libsane: Add Canon MP230 support

[Oliver Winker]

Hi Adrian,

Just updated [1] and tested: and it works now ;)!

Thanks for the update, BR, Oliver

[1]
---
ii  libsane:amd64 1.0.24-1.1
amd64API library for scanners
ii  libsane-common1.0.24-1.1
all  API library for scanners -- documentation and support files
---

On Sun, 19 Jan 2014 12:01:51 +0100
John Paul Adrian Glaubitz  wrote:

> Hello Oliver!
> 
> sane-backends 1.0.24-1.1 which contains your patch was uploaded
> to unstable yesterday. The scanner is also reported as "Complete"
> on the SANE website [1].
> 
> Could you upgrade your sane-backends to the latest version in
> unstable and verify that your scanner is now fully working
> so we can close this bug report?
> 
> Adrian
> 
> > [1] http://www.sane-project.org/sane-mfgs.html#Z-CANON
> 


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

Bug#726253: libsane: Add Canon MP230 support

[John Paul Adrian Glaubitz]

close 726253
thanks

On 01/19/2014 12:57 PM, Oliver Winker wrote:
> Just updated [1] and tested: and it works now ;)!

Woohoo, thanks for the quick reply. I'm very happy to be
able to close this bug report now.

Happy scanning!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#735925: Pending fixes for bugs in the libio-socket-ip-perl package

[pkg-perl-maintainers]

tag 735925 + pending
thanks

Some bugs in the libio-socket-ip-perl package are closed in revision
addacb0f09ebcc47ca1e5ac9eb8adb3f4bab9aad in branch 'master' by
Dominic Hargreaves

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libio-socket-ip-perl.git;a=commitdiff;h=addacb0

Commit message:

Switch Depends from perl to perl-base as a special case, for a module which 
is likely to become part of perl-base in 5.20 (Closes: #735925)


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

Bug#736058: apparmor: no abstractions/dbus-accessibility

[secdeb]

"IIRC abstractions/dbus-accessibility was added to upstream bzr repo
after the 2.8.0 release Debian is currently shipping.

Also, I see no reference to this abstraction in the apparmor package,
so I suspect this is caused by something you installed manually.
Can you please run "rgrep dbus-accessibility /etc/apparmor.d" and send
us the result?

Cheers,
-- 
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc";



> rgrep dbus-accessibility /etc/apparmor.d
>> /etc/apparmor.d/abstractions/lightdm:  #include 


By the way, I had another problem, before I disabled /etc/apparmor.d/lightdm
-guest-session:
    
[] Starting AppArmor profiles:AppArmor parser error for /etc/apparmor.d/
lightdm-guest-session in /etc/apparmor.d/abstractions/lightdm at line 14: 
Could not open 'abstractions/dbus-accessibility'
/sbin/apparmor_parser: Unable to replace "/bin/ping".  Profile doesn't 
conform to protocol
Warning failed to create cache: bin.ping
/sbin/apparmor_parser: Unable to replace "/sbin/klogd".  Profile doesn't 
conform to protocol
Warning failed to create cache: sbin.klogd
/sbin/apparmor_parser: Unable to replace "/sbin/syslog-ng".  Profile doesn't
conform to protocol
Warning failed to create cache: sbin.syslog-ng
/sbin/apparmor_parser: Unable to replace "/sbin/syslogd".  Profile doesn't 
conform to protocol
Warning failed to create cache: sbin.syslogd
/sbin/apparmor_parser: Unable to replace "/usr/lib/dovecot/deliver".  
Profile doesn't conform to protocol
Warning failed to create cache: usr.lib.dovecot.deliver
/sbin/apparmor_parser: Unable to replace "/usr/lib/dovecot/dovecot-auth".  
Profile doesn't conform to protocol
Warning failed to create cache: usr.lib.dovecot.dovecot-auth
/sbin/apparmor_parser: Unable to replace "/usr/lib/dovecot/imap".  Profile 
doesn't conform to protocol
Warning failed to create cache: usr.lib.dovecot.imap
/sbin/apparmor_parser: Unable to replace "/usr/lib/dovecot/imap-login".  
Profile doesn't conform to protocol
Warning failed to create cache: usr.lib.dovecot.imap-login
/sbin/apparmor_parser: Unable to replace "/usr/lib/dovecot/managesieve-
login".  Profile doesn't conform to protocol
Warning failed to create cache: usr.lib.dovecot.managesieve-login
/sbin/apparmor_parser: Unable to replace "/usr/lib/dovecot/pop3".  Profile 
doesn't conform to protocol
Warning failed to create cache: usr.lib.dovecot.pop3
/sbin/apparmor_parser: Unable to replace "/usr/lib/dovecot/pop3-login".  
Profile doesn't conform to protocol
Warning failed to create cache: usr.lib.dovecot.pop3-login
/sbin/apparmor_parser: Unable to replace "/usr/sbin/avahi-daemon".  Profile 
doesn't conform to protocol
Warning failed to create cache: usr.sbin.avahi-daemon
/sbin/apparmor_parser: Unable to replace "/usr/sbin/dnsmasq".  Profile 
doesn't conform to protocol
Warning failed to create cache: usr.sbin.dnsmasq
/sbin/apparmor_parser: Unable to replace "/usr/sbin/dovecot".  Profile 
doesn't conform to protocol
Warning failed to create cache: usr.sbin.dovecot
/sbin/apparmor_parser: Unable to replace "/usr/sbin/identd".  Profile doesn'
t conform to protocol
Warning failed to create cache: usr.sbin.identd
/sbin/apparmor_parser: Unable to replace "/usr/sbin/mdnsd".  Profile doesn't
conform to protocol
Warning failed to create cache: usr.sbin.mdnsd
/sbin/apparmor_parser: Unable to replace "/usr/sbin/nmbd".  Profile doesn't 
conform to protocol
Warning failed to create cache: usr.sbin.nmbd
/sbin/apparmor_parser: Unable to replace "/usr/sbin/nscd".  Profile doesn't 
conform to protocol
Warning failed to create cache: usr.sbin.nscd
/sbin/apparmor_parser: Unable to replace "/usr/sbin/smbd".  Profile doesn't 
conform to protocol
Warning failed to create cache: usr.sbin.smbd
/sbin/apparmor_parser: Unable to replace "/usr/{sbin/traceroute,bin/
traceroute.db}".  Profile doesn't conform to protocol
Warning failed to create cache: usr.sbin.traceroute
/sbin/apparmor_parser: Unable to replace "browser_java".  Profile doesn't 
conform to protocol
 failed!



""

Bug#735927: general: X *always* crashes when 5 youtube video opened

[Martijn van Oosterhout]

On 18 January 2014 21:08, moli  wrote:

>
> I dont have any knowledge in this area but i dont think this has
> anything to do with chrome, i think it's an intel graphics driver
> issue, it does not handle gracefully when the video memory is gone.
>
>
Well, you state in your original email that you have no swap partition.
Which is like tying one arm of the kernel behind its back. When the memory
is full, what do you *expect* to happen. Something needs to get killed, and
the X server does use a lot of memory so it is a good choice.

You could disable memory overcommit, that would cause things to fall over
sooner.

You could change the OOM priority of the X server, this would cause some
other process to be killed instead.

Or (recommended) just add a small swap partition (say 128MB) to allow the
kernel to put unused memory pages on disk so the X server can use them
instead.

Have a nice day,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/

Bug#727708: The tech ctte isn't considering OpenRC at all

[Ian Jackson]

Thomas Goirand writes ("Bug#727708: The tech ctte isn't considering OpenRC at 
all"):
> I have to say that I'm really disappointed by the tech ctte attitude
> toward OpenRC in general.

I'm sorry about that, but:

The way I investigated both systems was by reading their documentation
and playing about with them (on the VMs Steve helpfully provided).

At the start of my investigations I asked where I could find the
reference documentation and no-one answered.  And, OpenRC wasn't in
sid.  So these things weren't possible.

> But that OpenRC just hasn't been considered just because of rumors is
> really unacceptable.

The reason I haven't seriously considered OpenRC for the default is
that it wasn't ready.

Perhaps things have improved.  But I don't think it is necessarily the
TC's job to go back and revisit OpenRC in these circumstances.  How
mature a system is and how well-developed in Debian are relevant
factors and it's not unreasonable to set a deadline, at which the
state of the system in Debian will be the basis of our technical
evaluation.


On to specifics:

Thomas, does OpenRC provide a means for do non-forking daemon
startup ?

By that I mean some arrangement whereby:

 * The daemon does not double-fork; it runs in the foreground of
   of its initial process.

 * The daemon's parent process (part of the init system) keeps
   track of it, so the init system knows whether the process
   is still running.

 * The daemon's stderr goes somewhere reasonable.

If the answer to this question is "yes" then I will go and at least
read the documentation.  If it's "no" then I have to say that I think
(for me) OpenRC is failing to deal with the key underlying technical
problem we have with daemons in sysvinit right now.

Ian.


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

Bug#730760: perl-base: IO::Socket::INET cannot cope with "option inet6" in /etc/resolv.conf

[Dominic Hargreaves]

On Sat, Jan 18, 2014 at 05:22:28PM +, Dominic Hargreaves wrote:
> clone 730760 -1
> reassign -1 libio-socket-ip-perl
> retitle -1 libio-socket-ip-perl: update Depends perl -> perl-base
> block 730760 by -1
> thanks
> 
> On Sat, Jan 18, 2014 at 04:43:23PM +0100, Bill Allombert wrote:
> > On Sat, Jan 18, 2014 at 03:38:35PM +, Dominic Hargreaves wrote:
> > > On Sat, Jan 18, 2014 at 03:00:11PM +0100, Bill Allombert wrote:
> > > > On Sat, Jan 18, 2014 at 02:01:32PM +0200, Niko Tyni wrote:
> > > > > (cc'ing the perl and libio-socket-ip-perl package maintainers too)
> > > > > 
> > > > > On Sat, Jan 18, 2014 at 12:09:43PM +0100, Bill Allombert wrote:
> > > > > > > On Fri, 17 Jan 2014 10:19:33 +, Bob Ham wrote:
> > > > > > > 
> > > > > > > > >A more pragmatic solution might be to use IO::Socket::IP 
> > > > > > > > >instead.
> > > > > > > > 
> > > > > > > > I see now that IO::Socket::INET is only intended for IPv4; I 
> > > > > > > > hadn't
> > > > > > > > realised that.  This problem showed up because the
> > > > > > > > /usr/share/popularity-contest/popcon-upload script in
> > > > > > > > popularity-contest makes use of IO::Socket::INET.  Perhaps this 
> > > > > > > > bug
> > > > > > > > could be reassigned to the popularity-contest package so that 
> > > > > > > > it can
> > > > > > > > be changed to use IO::Socket::IP instead?
> > > > > 
> > > > > > This is very annoying because IO::Socket::INET is part of perl-base 
> > > > > > but
> > > > > > IO::Socket::IP is part of libio-socket-ip-perl. The whole design of 
> > > > > > popcon-upload was to use only Essential pakages to keep a small 
> > > > > > footprint.
> > > > > > 
> > > > > > Would it be possible to have at least IO::Socket::INET6 in 
> > > > > > perl-base ?
> > > > > > This would make perl-base IPv4/IPv6 agnostic. 
> > > > > 
> > > > > I believe the way forward is IO::Socket::IP, not IO::Socket::INET6.
> > > > > The upstream plan seems to be to get IO::Socket::IP into Perl core
> > > > > for 5.20, scheduled for May. If that happens, it makes sense to me
> > > > > to put that in perl-base along with the old IO::Socket::INET.
> > > > > 
> > > > >  https://rt.perl.org/Public/Bug/Display.html?id=116433#txn-1275004
> > > > > 
> > > > > In the meanwhile, it looks like libio-socket-ip-perl could be made to
> > > > > depend only on perl-base, as it doesn't seem to use any modules 
> > > > > outside
> > > > > that. I think the situation fits the 'exceptional circumstances' 
> > > > > clause
> > > > > in the Perl policy.
> > > > > 
> > > > >  
> > > > > https://www.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html#s-base
> > > > > 
> > > > > Bill, would you be OK adding a dependency on libio-socket-ip-perl if 
> > > > > it
> > > > > didn't depend on perl/perl-modules ?
> > > > 
> > > > Yes, it would be fine, if IO::Socket::IP is planned to be essential.
> > > > Thanks a lot!
> > > 
> > > I suspect this isn't quite what Niko was thinking. popcon-upload isn't
> > > itself Essential so it doesn't seem necessary to make the preference
> > > for only depending on Essential packages into a hard rule, I'd have
> > > thought?
> > > 
> > > In fact, if we pull IO::Socket::IP into perl-base with perl 5.20,
> > > making libio-socket-ip-perl Essential now may actually be harmful.
> > 
> > I was speaking of IO::Socket::IP, not of libio-socket-ip-perl.
> 
> Okay, I missed that emphasis :)
> 
> I'll therefore clone #730760 against libio-socket-ip-perl to switch
> the dependency to perl-base.

That's now uploaded, so if you depend on libio-socket-ip-perl (>= 0.25-2)
you'll avoid pulling in the whole of perl.

Cheers,
Dominic.


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

Bug#727708: Init system resolution open questions

[Adrian Bunk]

On Sun, Jan 19, 2014 at 02:59:01AM -0800, Russ Allbery wrote:
> Adrian Bunk  writes:
> > On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
>...
> > No, I am not assuming bad faith.
> 
> > But there will be cases where the goals like
> > 1. give users of systemd under Linux the best possible experience
> > 2. support non-Linux ports
> > 3. support other init systems
> > conflict.
> 
> > What is better depends on which goal has a higher priority for you.
> 
> > There shoud be a general project direction that clearly defines which of
> > these two goals has a higher priority for Debian, not half of the
> > packages going into one direction and the other half into the other
> > direction.
> 
> I don't even agree with this.  I think it's perfectly reasonable for some
> Debian contributors to choose to put more of their time into giving users
> of the default init system on Linux the best possible experience, and
> other Debian contributors to concentrate on supporting non-Linux ports or
> other init systems, depending on what that individual maintainer feels is
> the most important and what they want to spend time on.
>  
> The point of this bug is to choose a default init system.  With most of
> those choices come obvious benefits if we add native support for that init
> system to our packaging.  That doesn't mean anyone is obligated to do so.
> It does mean that they shouldn't stand in the way of other people doing
> so.
> 
> Some packages are going to be converted to native support for the default
> init system quickly, some slowly, and different contributors will use
> different approaches.  That's fine.

Why do you want Debian to support multiple init systems in the first place?

See also below.


> > The following are two quite different options:
> > 1. support multiple init systems since the non-Linux ports are core
> >functionality of Debian
> > 2. support multiple init systems, without considering the non-Linux 
> >ports to be core functionality of Debian that has to be protected
> 
> > One major reason for people supporting multiple init systems is to allow 
> > Debian to keep the non-Linux ports.[2] So they want 1., but might be 
> > very surprised if it turns out what they actually got with their vote
> > was 2., and that the non-Linux ports might anyway die in jessie+1.[3]
> 
> > And this does matter also since supporting multiple init systems will 
> > be a lot more work than a one-time switch from sysvinit to a successor.
> 
> I understand what you're saying, I think, and I believe it's the point of
> wording that Ian and I have been discussing: what are we requiring
> maintainers to do when patches are submitted for a non-default init
> system?  I think I already said what my position on that is.  People
> should not get in the way of other people's work if possible.  And
> obviously for jessie people shouldn't drop sysvinit scripts.  I don't know
> if we're going to be able to decide right now if people will be able to
> drop sysvinit scripts post-jessie.  I think it may be better to wait and
> see what the landscape looks like then.
> 
> I think this is a different question than dependencies on logind, because
> in that case we're dealing with upstream decisions to move strongly in a
> particular direction.  That's much different than most of the issues we'll
> run into with multiple init systems, where the configuration for different
> init systems is largely independent.
> 
> Hopefully, logind will continue to work without systemd and people will
> volunteer to maintain the necessary packaging for that configuration, and
> none of this will be a problem.

I think you missed my point.

Assume a CTTE member wants that Debian does continue to have non-Linux 
ports, and therefore wants Debian to make the extra efforts for 
supporting a second init system besides systemd.

What level of support (if any) would that guarantee for Debian's ports 
to non-Linux kernels?


Or more generally speaking:

Supporting multiple init systems in the packages as well as all use 
cases like switching the init system of a running system will be a big 
effort from both init system maintainers and maintainers maintaining 
packages with init scripts.

What are the goal(s) you want to achieve with forcing the big additional 
effort for supporting multiple init systems on Debian maintainers?

And is that additional effort well-spent?
Will these goal(s) be reached?


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Bug#736065: ganeti: unwanted automatic restart

[Benoit Friry]

Package: ganeti
Version: 2.9.2-2
Severity: normal

Bonjour,

I use ganeti for testing pieces of software. I do not want ganeti to be always
running.

# /etc/init.d/ganeti stop
[ ok ] Stopping Ganeti cluster:[] ganeti-mond...done.
[ ok ] ganeti-luxid...done.
[ ok ] ganeti-confd...done.
[ ok ] ganeti-rapi...done.
[ ok ] ganeti-masterd...done.
[ ok ] ganeti-noded...done.

After a while, ganeti is running again.

# /etc/init.d/ganeti status
[ ok ] ganeti-noded is running.
[ ok ] ganeti-masterd is running.
[ ok ] ganeti-rapi is running.
[ ok ] ganeti-confd is running.
[FAIL] ganeti-luxid is not running ... failed!
[ ok ] ganeti-mond is running.

ganeti was restarted by ganeti-watcher in /etc/cron.d/ganeti.

Actually, ganeti cannot be stopped!

ganeti-watcher can be paused with "gnt-cluster watcher pause ", which
assume the watch has to be restarted.  So, it's not the right way.

Suggestion:
 - /etc/init.d/ganeti start => create a flag file in /var/lib/ganeti
 - /etc/init.d/ganeti stop => remove the flag file
 - /etc/cron.d/ganeti => do not do anything if the flag file in not there.

Merci,
Benoit

*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


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

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

Versions of packages ganeti depends on:
ii  adduser3.113+nmu3
ii  bridge-utils   1.5-7
ii  fping  3.8-1
ii  ganeti-haskell 2.9.2-2
ii  iproute1:3.12.0-1
ii  iproute2   3.12.0-1
ii  iputils-arping 3:20121221-4
ii  lvm2   2.02.98-6+b1
ii  openssh-client 1:6.4p1-2
ii  openssh-server 1:6.4p1-2
ii  openssl1.0.1f-1
ii  python-bitarray0.8.0-2+b2
ii  python-ipaddr  2.1.10-1
ii  python-openssl 0.13.1-1
ii  python-paramiko1.10.1-1
ii  python-pycurl  7.19.0.3-1
ii  python-pyinotify   0.9.4-1
ii  python-pyparsing   2.0.1+dfsg1-1
ii  python-simplejson  3.3.1-2
pn  python:any 
ii  socat  1.7.2.2-1

Versions of packages ganeti recommends:
pn  drbd8-utils  
pn  ganeti-htools
ii  ganeti-instance-debootstrap  0.11-1
ii  ndisc6   1.0.1-1+b1
ii  qemu-kvm 1.7.0+dfsg-2

Versions of packages ganeti suggests:
pn  ganeti-doc  

-- 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#713971: libsane:i386 on amd64 stops officejet from scanning

[Wolfgang Schnitker]

Hi Adrian,

as discussed offline, I backported via source compilation to my
stable/wheezy system.

It is possible to scan now with multiarch and libsane:i386 installed.

This will solve the problem, that using SANE and googleearth debian
amd64 package at the same time on an amd64-system was not possible,
because googleearth 64bit is using i386 runtime environment with
ia32libs as recommended package. This includes libsane:i386 and stops HP
OfficeJet from working (and Probably other combinations too, i.e. SKYPE)

All applications are now running properly.

You did a good job.

Wolfgang

Am 19.01.2014 02:05, schrieb John Paul Adrian Glaubitz:
> Hello Wolfgang!
>
> sane-backends 1.0.24-1.1 was uploaded to unstable today. It should fully
> support MultiArch now. Please give it a try once you have updated and
> report back, so we know whether we can close this bug or need to have
> another look at it.
>
> Adrian
>


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

Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64

[Sandro Tosi]

> No. If you mess around with your installation resulting in the
> packages failing to upgrade or behaving unexpectedly as a result,
> you can't file a bug and blame the authors or maintainers of
> the software.

I "mess around with  installation" and "blame" someone? I suggest
you to think best before writing such thing - you don't deserve my
time, so I won't reply any further.

PS: how would a fresh installation resolve the problem I have? in no
way, so your provided solution has no technical value whatsoever -
well done...

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64

[John Paul Adrian Glaubitz]

On 01/19/2014 01:31 PM, Sandro Tosi wrote:
> I "mess around with  installation" and "blame" someone? I suggest
> you to think best before writing such thing - you don't deserve my
> time, so I won't reply any further.

There is no need to be huffy.

Again, if you want someone to look at the problem you are experiencing,
try to provide more information which will help to reproduce the
problem.

You are a Debian Developer yourself, so you should have dealt with
bug reports before and you should understand that it's next to
impossible to debug a problem when several people cannot reproduce
it.

> PS: how would a fresh installation resolve the problem I have? in no
> way, so your provided solution has no technical value whatsoever -
> well done...

The problem arising in a fresh installation would justify reporting
this as a bug and so would a dist-upgrade on a clean system.

However, when such a problem occurs on a very old installation and,
on top of that, isn't reproducible by anyone else, it clearly doesn't
justify to file a bug report.

Again, if you want people to debug your problem, provide some more
useful information on how to reproduce the issue. All the information
you have provided so far isn't helpful at all trying to resolve
the issue.

Cheers,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#736066: multiple security issues discovered in encfs

[Paul Dreik]

Package: encfs
Version: 1.7.4-2.4+b2

A recent report discusses some issues with encfs. I do not have the
competence to judge it, but it is a good idea it at lease comes to the
users and package maintainers knowledge.

See https://defuse.ca/audits/encfs.htm

Paul


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

Bug#713971: libsane:i386 on amd64 stops officejet from scanning

[John Paul Adrian Glaubitz]

close 713971
thanks

On 01/19/2014 01:31 PM, Wolfgang Schnitker wrote:
> It is possible to scan now with multiarch and libsane:i386 installed.

Great!

> This will solve the problem, that using SANE and googleearth debian
> amd64 package at the same time on an amd64-system was not possible,
> because googleearth 64bit is using i386 runtime environment with
> ia32libs as recommended package. This includes libsane:i386 and stops HP
> OfficeJet from working (and Probably other combinations too, i.e. SKYPE)

Ah, the Google Earth package shouldn't actually recommend "ia32libs"
anymore since this package has become obsolete with the introduction
of MultiArch.

Which Google Earth packaging are you using? I have been the sponsor
of the googleearth-package [1] in Debian and if it actually still
recommends "ia32libs", we should probably file a bug.

Closing this bug report nontheless, thanks for testing! And feel
free to re-open in case the problem comes back.

Adrian

> [1] http://packages.qa.debian.org/g/googleearth-package.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#733578: RFS: hwinfo/20.1-1 [ITA] -- Hardware identification system

[Vincent Cheng]

On Sun, Jan 19, 2014 at 3:47 AM, Sebastien Badia  wrote:
> Hi Vincent,
>
> Thank you very much !
>
> According your comments, I've just fixed and uploaded a new version on 
> mentors.
>
> If you have any time to re-review this package, I really appreciate.
> https://mentors.debian.net/package/hwinfo

Comments:

- You're using source format 3.0 (quilt) already, so drop the
extraneous build-dep on quilt in d/control. You can also drop
debian/README.source.
- Why do you depend directly on libx86emu1? ${shlibs:Depends} should
take care of that for you.
- If you don't use upstream's tarball / upstream doesn't provide
tarballs, you should have a get-orig-source target in debian/rules
(Policy 4.9), which for this package would just run
debian/get-tarball.sh when invoked.

> I still have a lintian warning about « hardening-no-relro »,
> but I don't known how to fix it :-/

Your build system isn't using the build flags that dpkg-buildflags
specifies. You get this for free with common build systems like
autotools, but your package looks like it has nothing more than a
hand-written makefile, so you may need to modify it to work with
dpkg-buildflags.

Regards,
Vincent


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

Bug#736068: docker.io: Please package mkimage-* scripts

[Scott Leggett]

Package: docker.io
Version: 0.7.1+dfsg1-1
Severity: wishlist

Dear Maintainer,

Please add the mkimage-* scripts, or at least the mkimage-debootstrap
script, to the package. These scripts facilitate building your own
"pristine" base images.

The scripts are available here: 
https://github.com/dotcloud/docker/tree/master/contrib

Regards,
Scott Leggett.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 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 docker.io depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.14
ii  iptables 1.4.14-3.1
ii  libc62.17-97
ii  libdevmapper1.02.1   2:1.02.74-8
ii  libsqlite3-0 3.7.13-1+deb7u1
ii  lxc  0.9.0~alpha3-2+deb8u1

Versions of packages docker.io recommends:
ii  aufs-tools   1:3.0+20120411-2
ii  ca-certificates  20130119
ii  xz-utils 5.1.1alpha+20120614-2

docker.io 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#714767: whizzytex: the -pdf option is not working due to hyperref error

[Richard Kapolnai]

Hi,

this bug is possibly fixed in the new upstream version 1.3.3.

bests,
Richard Kapolnai


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

Bug#736069: lio-utils: Does not enable firewire support by default

[Roger Leigh]

Package: lio-utils
Version: 3.1+git2.fd0b34fd-2
Severity: normal

Installed targetcli/lio-utils.  Manually enabled configfs (note: I
updated initscripts to do this in mountkernfs).

ravenclaw% sudo targetcli
targetcli GIT_VERSION (rtslib GIT_VERSION)
Copyright (c) 2011-2013 by Datera, Inc.
All rights reserved.
/> ls
o- / 

 [...]
  o- backstores 
. 
[...]
  | o- fileio 
.. [0 Storage 
Object]
  | o- iblock 
.. [1 Storage 
Object]
  | | o- ppc-linux . 
[/dev/ravenclaw/ppc-linux deactivated]
  | o- pscsi 
... [0 Storage 
Object]
  | o- rd_dr 
... [0 Storage 
Object]
  | o- rd_mcp 
.. [0 Storage 
Object]
  o- ib_srpt 
.. [0 
Targets]
  o- iscsi 
 [0 
Targets]
  o- loopback 
. [0 
Targets]
  o- qla2xxx 
.. [0 
Targets]
  o- tcm_fc 
... [0 
Targets]

You can see I made a single iblock backing store.  What's missing here is the
"/sbp" target for firewire devices; it's not possible to export over firewire
with the current setup.  My intention here is to export the above to a powerpc
system to allow it do run directly from the exported device, which I can then
snapshot/clone/replace as required.

I tried doing "sudo modprobe sbp_target" which loads the module, but
it's not then possible to restart the target script:

% sudo modprobe sbp_target
% sudo invoke-rc.d target restart
Unloading fabric/configfs: Successfully released fabric: 
/sys/kernel/config/target/srpt
Successfully released fabric: /sys/kernel/config/target/qla2xxx
Successfully released fabric: /sys/kernel/config/target/loopback
Successfully released fabric: /sys/kernel/config/target/fc
  [OK]
Unloading LIO-Target/ConfigFS fabric:   [OK]
Unloading target_core_mod/ConfigFS core: rmmod: ERROR: Module target_core_stgt 
is not currently loaded
rmmod: ERROR: Module target_core_mod is in use by: sbp_target
Unable to rmmod target_core_mod
  [FAILED]: 1
Calling START /etc/init.d/target ERROR, target_core_mod/ConfigFS already active

So it looks like the target script, and/or its helper scripts, needs to
be able to load/unload the sbp_target module like for the other modules,
and perhaps it needs a helper script in its own right?

Having not yet got this working, there may be other prerequisites in
addition to get sbp working, but I'm not an expert LIO by any means.


Regards,
Roger

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lio-utils depends on:
ii  libc6   2.17-97
ii  python  2.7.5-5

lio-utils recommends no packages.

lio-utils suggests no packages.

-- Configuration Files:
/etc/target/lio_start.sh changed [not included]
/etc/target/tcm_start.sh changed [not included]

-- 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#736070: samba-common: Mentions no more existing package dhcp3-client in debconf question

[Axel Beckert]

Package: samba-common
Version: 2:4.1.4+dfsg-1
Severity: normal

Dear Maintainer,

upon samba-common installation, debconf tells me:

> The dhcp3-client package must be installed to take advantage of this
> feature.

That package no more exists since Wheezy and already was a transitional
package back in Squeeze.

This is related to http://bugs.debian.org/649100

See also the output of "fgrep dhcp3 /var/lib/dpkg/info/samba-common.*".

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (900, 'testing'), (899, 
'testing-proposed-updates'), (600, 'stable'), (500, 'proposed-updates'), (200, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.13-rc6-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages samba-common depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  dpkg   1.17.6
ii  ucf3.0027+nmu1

Versions of packages samba-common recommends:
ii  samba-common-bin  2:4.1.3+dfsg-2

samba-common suggests no packages.

-- debconf information:
  samba-common/title:
  samba-common/dhcp: false
  samba-common/workgroup: WHATEVER
  samba-common/encrypt_passwords: true
  samba-common/do_debconf: true


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

Bug#736071: [libvecmath-java-doc] Error while merging ... inconsistent values of section

[Francesco Muzio]

Package: libvecmath-java-doc
Version: 1.5.2-4
Severity: normal

when doc-base is triggered or I launch a "dpkg-reconfigure doc-base" I 
see this message:


Processing 2 added doc-base files...
Error while merging /usr/share/doc-base/libvecmath-java-doc with 
/usr/share/doc-base/libvecmath-java-doc-javadoc: inconsistent values of 
section.

Registering documents with scrollkeeper...

removing (with purge) the package and reinstall it doesn't help, the 
problem is still present


--- System information. ---
Architecture: i386
Kernel: Linux 3.12.6

Debian Release: jessie/sid
500 testing cdn.debian.net

--- Package information. ---
Package's Depends field is empty.

Recommends (Version) | Installed
==-+-===
default-jdk-doc | 0.49


Suggests (Version) | Installed
==-+-===
libvecmath-java | 1.5.2-4


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

Bug#736065: ganeti: unwanted automatic restart

[Apollon Oikonomopoulos]

Hi Benoit,

On 13:21 Sun 19 Jan , Benoit Friry wrote:
> Package: ganeti
> Version: 2.9.2-2
> Severity: normal
> 
> Bonjour,
> 
> I use ganeti for testing pieces of software. I do not want ganeti to be always
> running.
> 
> # /etc/init.d/ganeti stop
> [ ok ] Stopping Ganeti cluster:[] ganeti-mond...done.
> [ ok ] ganeti-luxid...done.
> [ ok ] ganeti-confd...done.
> [ ok ] ganeti-rapi...done.
> [ ok ] ganeti-masterd...done.
> [ ok ] ganeti-noded...done.
> 
> After a while, ganeti is running again.
> 
> # /etc/init.d/ganeti status
> [ ok ] ganeti-noded is running.
> [ ok ] ganeti-masterd is running.
> [ ok ] ganeti-rapi is running.
> [ ok ] ganeti-confd is running.
> [FAIL] ganeti-luxid is not running ... failed!
> [ ok ] ganeti-mond is running.
> 
> ganeti was restarted by ganeti-watcher in /etc/cron.d/ganeti.
> 
> Actually, ganeti cannot be stopped!
> 
> ganeti-watcher can be paused with "gnt-cluster watcher pause ", 
> which
> assume the watch has to be restarted.  So, it's not the right way.
> 
> Suggestion:
>  - /etc/init.d/ganeti start => create a flag file in /var/lib/ganeti
>  - /etc/init.d/ganeti stop => remove the flag file
>  - /etc/cron.d/ganeti => do not do anything if the flag file in not there.
> 
> Merci,
> Benoit

We will into this more thoroughly. Meanwhile, you can disable the 
watcher permanently through /etc/cron.d/ganeti.

Regards,
Apollon
> 
> *** Please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these lines ***
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages ganeti depends on:
> ii  adduser3.113+nmu3
> ii  bridge-utils   1.5-7
> ii  fping  3.8-1
> ii  ganeti-haskell 2.9.2-2
> ii  iproute1:3.12.0-1
> ii  iproute2   3.12.0-1
> ii  iputils-arping 3:20121221-4
> ii  lvm2   2.02.98-6+b1
> ii  openssh-client 1:6.4p1-2
> ii  openssh-server 1:6.4p1-2
> ii  openssl1.0.1f-1
> ii  python-bitarray0.8.0-2+b2
> ii  python-ipaddr  2.1.10-1
> ii  python-openssl 0.13.1-1
> ii  python-paramiko1.10.1-1
> ii  python-pycurl  7.19.0.3-1
> ii  python-pyinotify   0.9.4-1
> ii  python-pyparsing   2.0.1+dfsg1-1
> ii  python-simplejson  3.3.1-2
> pn  python:any 
> ii  socat  1.7.2.2-1
> 
> Versions of packages ganeti recommends:
> pn  drbd8-utils  
> pn  ganeti-htools
> ii  ganeti-instance-debootstrap  0.11-1
> ii  ndisc6   1.0.1-1+b1
> ii  qemu-kvm 1.7.0+dfsg-2
> 
> Versions of packages ganeti suggests:
> pn  ganeti-doc  
> 
> -- 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#736072: qa.debian.org: debian/watch redirector for puppet modules from forge.puppetlabs.com

[Thomas Bechtold]

Package: qa.debian.org
Severity: wishlist
Tags: patch

Dear QA team,

I'm the maintainer of some puppet modules and a couple of days ago the
debian/watch files are no longer working because puppetlabs changed the
way howto get the information about available versions.

It's now possible to get the available versions in json format. ie on

https://forgeapi.puppetlabs.com/v3/modules/puppetlabs-firewall

for the module firewall from the user puppetlabs. I have written a patch
(see attachment) for a puppetlabs redirector. The patch can be applied
on top of svn.debian.org/svn/qa/trunk/cgi-bin/fakeupstream.cgi

I tested the patch locally with the following debian/watch file:

version=3
http://localhost/cgi-bin/fakeupstream.cgi?upstream=forge.puppetlabs/puppetlabs/firewall
 \
.*/puppetlabs-firewall-(.+)\.tar\.gz

Can you review and apply the patch to fakeupstream.cgi if you are happy
with it? And what's the procedure to get this patch rolled out so the
debian/watch files can use the new redirector?


TIA

Tom



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

Kernel: Linux 3.12-1-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
Index: fakeupstream.cgi
===
--- fakeupstream.cgi	(revision 3102)
+++ fakeupstream.cgi	(working copy)
@@ -565,6 +565,32 @@
 	exit 0;
 }
 
+# http://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=forge.puppetlabs/puppetlabs/stdlib
+if( undef2empty( $q->param('upstream') ) =~ m%^forge.puppetlabs/($project_char_re+)/($project_char_re+)$% )
+{
+	my $user = $1;
+	my $project = $2;
+	my $url = "https://forgeapi.puppetlabs.com/v3/modules/$user-$project";;
+	my $ua = LWP::UserAgent->new( ssl_opts => { verify_hostname => 0 } );
+	my $response = $ua->get( $url );
+	my $refs_page = $response->decoded_content;
+	return_error( "failed to read $url : $response->status_line" ) if( not $response->is_success );
+	my $json_ref = JSON::decode_json( $refs_page );
+print $q->header;
+print $q->start_html;
+print $q->start_ul;
+foreach my $release ( @{$json_ref->{"releases"}} )
+{
+	my $basename = join "", $user, "-", $project, "-", $release->{version}, ".tar.gz";
+	print "";
+	print "", $basename, "\n";
+	print "";
+}
+print $q->end_ul;
+print $q->end_html;
+	exit 0;
+}
+
 my %upstream_info_per_package =
 (
 	'stopwatch' =>

Bug#736067: RM: abuse-sfx , package superfluous when abuse-sdl is gone

[coldtobi]

Package: abuse-sfx
Followup-For: Bug #736067

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

When abuse-sdl is deleted, abuse-sfx is no longer needed.



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

Kernel: Linux 3.12-1-amd64 (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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJS28wPAAoJEJFk+h0XvV02VMUQAK4oIkL69OzBeAi4010XpGkM
sLQLkaJHi8Ove+1jWzWvEqFKOI2zOfUu32s/aVyDuGSA8uhJZgz2K6QbwRGFy4Gy
JIZCrAuNJUjDMzbGD7u2SUGQqnPH7SWtL2wzRrJ5g0hpQT5mFONIrcNEzgdNp2Fj
hDjpxgoEuJJ1TsnE6Fs/XcWtonAxvR4wAx7LgF0ou9mTCfROQBZnKEA4L8KpvQKx
ek+hmj6aL7ZApZda8qz5JmpWiCo1dmbRWYWm38gSq20QPUrqN9Z9b54YyvaHh1w/
YSOI4m5qUobl7Mko+VWwQP39k49bld355vupHwlljZx1kx/Xb360ZSruWPkDrz/u
7wu5Rzh/rPAhD4M0j0v7xnb2BMaJvU9BojPRyfbCc00O6mGT3DSVS3gVFMbRRiMo
U6mMkdmOAw9MoSecF3M+3zQRBn/a8FU09lVbadJMDpNOGaU4QTPHNA2Trn54zYV3
AnHTtucjFCLNzGWWqynj7P+rapJsPV7o3OFugzkLIDBMzwYV1qWYcHv32Rve2L+q
92gkYOCbSKEB47V72solomjDLNLwRRn0OJOBtj8/Si05c8wiBHq9/GYRCJuhW7ag
9tmU46NccoMBowR2oVcEnF34VoqZXTRY/tiHRh4mFsSK5NmbD8DFKqjtQ1Umo/fg
taYTZiIAEHfdQ3xqwNDJ
=7ROM
-END PGP SIGNATURE-


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

Bug#736073: liferea: problem adding https url

[Kevin Walke]

Package: liferea
Version: 1.10.3-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
I was adding some new feeds to liferea

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I added the rss feed: 
   * What was the outcome of this action?
recieved the error:
The last update of this subscription failed!
HTTP error code 0: Unable to resolve destination host name
and the url was parsed as:

(try clicking the link!!)
and then it clearly failed to add the feed
   * What outcome did you expect instead?
I expected the feed to be added successfully

   * Additional Information
I have seen this befoe on other feeds and suspect it might be
associated with https links


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

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

Versions of packages liferea depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.18.0-1
ii  gir1.2-gtk-3.0   3.8.6-1
ii  gir1.2-peas-1.0  1.8.1-2
ii  libatk1.0-0  2.10.0-2
ii  libc62.17-97
ii  libcairo21.12.16-2
ii  libgdk-pixbuf2.0-0   2.28.2-1+b1
ii  libgirepository-1.0-11.36.0-2+b1
ii  libglib2.0-0 2.36.4-1
ii  libgtk-3-0   3.8.6-1
ii  libindicate5 0.6.92-2
ii  libjson-glib-1.0-0   0.16.2-1
ii  libnotify4   0.7.6-1
ii  libpango-1.0-0   1.36.0-1+b1
ii  libpeas-1.0-01.8.1-2
ii  libsoup2.4-1 2.44.2-1
ii  libsqlite3-0 3.8.2-1
ii  libwebkitgtk-3.0-0   2.2.3-1
ii  libxml2  2.9.1+dfsg1-3
ii  libxslt1.1   1.1.28-2
ii  liferea-data 1.10.3-1
ii  python-gi3.10.2-2
pn  python:any   

Versions of packages liferea recommends:
ii  dbus 1.7.10-2
ii  dbus-x11 1.7.10-2
ii  gir1.2-gnomekeyring-1.0  3.8.0-2
ii  gnome-icon-theme 3.10.0-1
ii  gnome-keyring3.8.2-2
ii  steadyflow   0.2.0-1

Versions of packages liferea suggests:
ii  network-manager  0.9.8.0-5

-- 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#724756: grub-pc: Similar problem with a LVM2 configuration

[Cesar Enrique Garcia]

Package: grub-pc
Version: 2.00-22
Followup-For: Bug #724756

 I am having the same problem after a regular apt-get upgrade, which rendered 
 my system unbootable. The solution was to reformat my hard disk..

 Following the discussion before I report the size of my core.img

-rw-r--r-- 1 root root 33114 ene 19 13:36 /boot/grub/i386-pc/core.img

 Let me know if you need more information regarding my setup.

 Best regards


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/vg_laptop1-lv_root_debian / ext4 
rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg_laptop1-lv_boot_debian /boot ext2 rw,relatime 0 0
/dev/mapper/vg_laptop1-lv_home /home ext4 rw,relatime,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-FUJITSU_MHV2100AH_NT23T622B1R4
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default="0"

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/vg_laptop1-lv_root_debian'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvm/vg_laptop1-lv_root_debian'  4d3a591b-882f-428c-be58-b0c8eefe55c5
else
  search --no-floppy --fs-uuid --set=root 4d3a591b-882f-428c-be58-b0c8eefe55c5
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  set timeout=5
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/vg_laptop1-lv_root_debian'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvm/vg_laptop1-lv_root_debian'  4d3a591b-882f-428c-be58-b0c8eefe55c5
else
  search --no-floppy --fs-uuid --set=root 4d3a591b-882f-428c-be58-b0c8eefe55c5
fi
insmod png
if background_image /usr/share/images/desktop-base/joy-grub.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-4d3a591b-882f-428c-be58-b0c8eefe55c5' {
load_video
insmod gzio
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/vg_laptop1-lv_boot_debian'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvm/vg_laptop1-lv_boot_debian'  03a9e0fb-2312-43bb-bd98-de29d342af9d
else
  search --no-floppy --fs-uuid --set=root 
03a9e0fb-2312-43bb-bd98-de29d342af9d
fi
echo'Loading Linux 3.12-1-686-pae ...'
linux   /vmlinuz-3.12-1-686-pae 
root=/dev/mapper/vg_laptop1-lv_root_debian ro  quiet
echo'Loading initial ramdisk ...'
initrd  /initrd.img-3.12-1-686-pae
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-4d3a591b-882f-428c-be58-b0c8eefe55c5' {
menuentry 'Debian GNU/Linux, with Linux 3.12-1-686-pae' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-3.12-1-686-pae-advanced-4d3a591b-882f-428c-be58-b0c8eefe55c5' {
load_video
insmod gzio
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod lvm
insmod ext2
set root='lvm/vg_laptop1-lv

Bug#736074: calf-plugins: calf plugins lack graph display components, Calf Analyzer is empty, others still functional

[Zenaan Harkness]

Package: calf-plugins
Version: 0.0.19+git20131202-1
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

When running a jackd session of some sort, the Calf plugins work in general, 
except for the "graph" display components of the plugins.

This is most visible in the Calf Analyzer plugin, which only shows graphs, and 
therefore when I run it, I get an empty plugin window, with no functionality.

I am currently using gladish to set up my session, and running plugins for 
testing purposes from the command line (and adding them to gladish when they 
appeal to me), for example, here's another command line plugin cmd/run:

jalv.gtk http://calf.sourceforge.net/plugins/TransientDesigner

I ought be grateful, since from one perspective, the lack of graph components 
in these Calf plugins means I can fit more plugins in one screen - this 
principle would lead to a feature request for an option to disable such 
components - perhaps a button on each plugin screen - probably a 
feature-request bug for upstream though, not for the Debian packagers, I don't 
know.

Also, the Calf Rack is missing, although it is advertised/mentioned in the 
package description - however this should probably be a separate bug - let me 
know if you'd like me to file a separate bug for this particular issue.

I have tested the jalv.gtk, jalv.gtkmm, jalv.qt, and jalv.gtk3, which all work, 
except jalv.gtk3 only brings up the built-in default (LADSPA style) minimal gui 
for each plugin.
All jalv.* plugin runners have the same problem displaying the graph.

It is entirely feasible that the bug is a jalv bug, and that if the plugins are 
run in some other way, that they would display their graph components, I don't 
know sorry.

If someone suggests a procedure/ application in which I can test the Calf 
plugins without using jalv, I am willing to do so.

*** End of the template - remove these lines ***


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

Kernel: Linux 3.12-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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 calf-plugins depends on:
ii  libatk1.0-0   2.10.0-2
ii  libc6 2.17-97
ii  libcairo2 1.12.16-2
ii  libexpat1 2.1.0-4
ii  libfftw3-single3  3.3.3-7
ii  libfluidsynth11.1.6-2
ii  libfontconfig12.11.0-2
ii  libfreetype6  2.5.2-1
ii  libgcc1   1:4.8.2-14
ii  libgdk-pixbuf2.0-02.28.2-1+b1
ii  libglib2.0-0  2.36.4-1
ii  libgtk2.0-0   2.24.22-1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.9.5+20130622git7de15e7a-1
ii  libpango-1.0-01.36.0-1+b1
ii  libpangocairo-1.0-0   1.36.0-1+b1
ii  libpangoft2-1.0-0 1.36.0-1+b1
ii  libstdc++64.8.2-14

Versions of packages calf-plugins recommends:
ii  gtk2-engines-pixbuf  2.24.22-1

Versions of packages calf-plugins suggests:
ii  ladish  1+dfsg0-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#720943: ITP: golang-websocket-dev -- implementation of the WebSocket (RFC6455) for Go

[Vincent Bernat]

 ❦ 26 août 2013 16:24 CEST, Vincent Bernat  :

> * Package name: golang-websocket-dev
>   Version : 0.0~git20130822
>   Upstream Author : Gary Burd 
> * URL : https://github.com/garyburd/go-websocket
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : implementation of the WebSocket (RFC6455) for Go

This repository has been deprecated in favor of this one:
 https://github.com/gorilla/websocket

The ITP still stands. The license is BSD-2 instead of Apache 2.
-- 
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#735968: dh-make-perl: Prints warning about missing pristine-tar even though it is installed

[Axel Beckert]

Hi Ivan,

Ivan Kohler wrote:
> dh-make-perl says:
> 
> W: pristine-tar not available. Please run
> W: apt-get install pristine-tar
> W:  followed by
> Use of uninitialized value $tarball in concatenation (.) or string at 
> /usr/share/perl5/DhMakePerl/Command/make.pm line 762.
> W: pristine-tar commit  upstream/0.08
> 
> It is already installed.

Thanks. A first glance at the problem reveals the following:

752 if ( File::Which::which('pristine-tar') and $tarball ) {
753 $ENV{GIT_DIR} = File::Spec->catdir( $self->main_dir, '.git' );
754 system( 'pristine-tar', 'commit', $tarball, 
"upstream/".$self->version ) >= 0
755 or warn "error running pristine-tar: $!\n";
756 }
757 else {
758 warn "W: pristine-tar not available. Please run\n";
759 warn "W: apt-get install pristine-tar\n";
760 warn "W:  followed by\n";
761 warn "W: pristine-tar commit $tarball upstream/"
762 . $self->version . "\n";
763 }

This means that this warning also is printed if $tarball is false,
even if pristine-tar is installed. The warning "Use of uninitialized
value $tarball" confirms that this was the cause for the warning.

This leaves the question why $tarball is undefined. It gets passed as
parameter to git_add_debian().

This case seems only to happen if guess_tarball fails, because it
returns undef in that case. It should have printed the message "Trying
... not found." in that case, too. But guess_tarball
only checks for .orig.tar.gz, neither for .orig.tar.bz2 nor
.orig.tar.xz nor .orig.tar.lzma. Which is kinda bad, too.

Can you tell us with which perl module and which module version this
happened, so we have an example to check if my conclusions are
correct?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


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

Bug#650575: closed by Tobias Frost (Bug#650575: fixed in prima 1.28-1.2)

[Sebastian Ramacher]

Control: reopen -1
Control: severity -1 important

On 2014-01-19 13:09:19, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:prima package:
> 
> #650575: prima: FTBFS: img/codec_png.c:282:20: error: dereferencing pointer 
> to incomplete type
> 
> It has been closed by Tobias Frost .

Nope, still fails with libpng 1.5 (and also with 1.6 which is now in
experimental):
| img/codec_png.c: In function ‘img_png_read’:
| img/codec_png.c:292:46: error: dereferencing pointer to incomplete type
| req_read( (( PImgLoadFileInstance) png_ptr-> io_ptr)-> req, size, data);

Reopening the bug and lowering the severity to important. A new enough
version of libpng to make prima fail to build from source is only
available in experimental.

Regards
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#727708: The tech ctte isn't considering OpenRC at all

[Dmitry Yu Okunev]

Hello.

On 01/19/2014 01:11 PM, Thomas Goirand wrote:
> On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette :
>> Oh, really?
>> Then can you explain why
>> https://bugs.gentoo.org/show_bug.cgi?id=391945
>> has not been marked as fixed?
> 
> It is the view of the upstream maintainers that the corner case where
> this happens doesn't happen in real life, so that bug can be ignored.

I want to add, that I've fixed the problem [1] on my local OpenRC copy.
Waiting for answer from Gentoo side about my patch.

[1] https://bugs.gentoo.org/show_bug.cgi?id=391945


I'm only a debian user but let me put two cents in again. Here's a look
from aside:

"systemd" and "upstart" gives _extra_ features, but sacrificing:
 - free community of init-system;
 - UNIX philosophy accordance.

There's a great lot of trash distributions like "ubuntu" or "fedora",
that are pursuing their own goals and forcing variety software. Debian
is the only universal binary distribution with big enough community that
can be used with conservative UNIX users, who believes in free community
and UNIX philosophy. IMO, software bundles (like "systemd") is a
proprietary way.

On the other hand OpenRC is really good solution supported by really
free and professional community. If you don't like something in it,
please, show corresponding bugreports, and OpenRC will likely fix that
all (if that will be reasonable). I personally saw only one minor
bugreport… and a lot of bugreports about "systemd".

OpenRC has extended cgroups support in 0.12 and it has parallel boot
support and all other and other reasonable features. And it's already in
experimental repositories of Debian (but I don't see any problem to test
OpenRC even if it's not in repositories).

The fact that the committee didn't even consider OpenRC despite the
community opinion is sad. I'm talking on forums with Debian users like
me, and a lot of them really want OpenRC. We even cannot understand why
OpenRC was been declined. Where's explanation of it's declination?

Don't you see, that the OpenRC is really the 3rd variant? And the only
one that is community driven. Or this's not an argument for Debian [1,
2] anymore?

[1] http://www.debian.org/intro/about
[2] http://www.debian.org/intro/free


P.S.: Sorry for my English.

-- 
Best regards, Dmitry,
head of UNIX-tech department NRNU MEPhI,
tel. 8 (495) 788-56-99, add. 8255



signature.asc
Description: OpenPGP digital signature

Bug#736058: apparmor: no abstractions/dbus-accessibility

[intrigeri]

Control: clone -1 -2
Control: reassign -2 lightdm 1.8.5-3
Control: retitle -2 AppArmor profile requires non-existing 
abstractions/dbus-accessibility
Control: affects -1 + lightdm

Hi,

sec...@post.cz wrote (19 Jan 2014 11:25:40 GMT) :
> rgrep dbus-accessibility /etc/apparmor.d
>> /etc/apparmor.d/abstractions/lightdm:  #include 
>> 

Then that's a bug in the package (lightdm) that ships a profile
depending on an abstraction that is not shipped by Debian (nor any
upstream release IIRC) yet. I'm then cloning this bug, and reassigning
the newly created clone to the lightdm package.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


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

Bug#727027: clamav: yet another new upsteam version

[Greg Folkert]

Package: clamav
Version: 0.97.8+dfsg-1
Followup-For: Bug #727027

Dear Maintainer,

What has led to this situation is "Sourcefire" has released a new verion of 
ClamAV (0.98.1) with additional functionality and possibly fixed your 
compiling issue Noted in your previous listing.

This is becoming a serious issue. Especially for those of us that run PCI 
compliant systems. Our QSA (Qualified Security Assessor) noticed our version 
was behind and they don't particularly care for "behind" versions from vendor 
that aren't either updated to latest version or at least maintained with 
backports of patches to required API versions.

This package is neither at this point and it is forcing me to make my Debian 
systems come under scrutiny that my "RedHat/CentOS" systems aren't coming
under, since they've been updated already. This wouldn't be such a bad thing, 
except Freshclam announces to the world that things are not up to snuff.


What I did exactly: I watch logs from the updating engine FreshClam, telling 
me this version is outdated. Here is the snippet from the relevant log:

WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.97.8 Recommended version: 0.98.1


Also 0.98 was released September 19th, 2013 and subsequently 0.98.1 was 
released January 15th, 2014.

Please at least make some effort to either update this bug or other 
remediation updates.

I thank you in advance for your work and hope you are well.

Sincerely and best wishes.

-- 
g...@gregfolkert.net
PGP key 1024D/B524687C 2003-08-05
Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C
"The only way to enjoy anything in this life is to earn it first."
-- Ginger Rogers


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

Bug#736076: Chromium error Vbulletin Editor

[Emanuel Tomasin Borda]

Package: Chromium
Version:31.0.1650.63


The text editor is not in Chromium. In other browsers if seen.


To reproduce the bug can enter frorospyware.com.


I am using Debian GNU / Linux 7.3, kernel 3.2.53-2 and libc6 2.13-38 + deb7u.

Bug#727708: The tech ctte isn't considering OpenRC at all

[Andreas Barth]

* Thomas Goirand (z...@debian.org) [140119 10:15]:
> Unfortunately, it seems it's going to be the way OpenRC will be
> evaluated: because some people *pretended* that OpenRC wouldn't fit the
> bill, it's just discarded without even having a look at how it works,
> its features, and its implementation.

That is - at least for me - not true: I look the same way at openrc as
the others. This however doesn't prevent me from arriving at certain
conclusions why I think one of the init systems is better than
another.



Andi


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

Bug#727708: TC resolution Re: GR: Selecting the default init system for Debian

[Ian Jackson]

Ian Jackson writes ("Re: GR: Selecting the default init system for Debian"):
> Russ Allbery writes ("Re: GR: Selecting the default init system for Debian"):
> > As a TC member, I dislike the supermajority requirement for the project to
> > overturn a TC decision by GR, particularly in this case.  I think we would
> > all be extremely unhappy if the TC voted one way on the default init
> > system and the project then voted a different way by a 60% majority.
> 
> I agree.  I think that would be quite bad.  We could explicitly state
> in our TC resolution that the TC decision can be vacated by General
> Resolution on a simple majority.

It seems to me that in the situation Russ describes it would be best
for the GR's conclusion, rather than the TC's, to be de jure that of
the project.

I therefore intend to put into the drafts something along the lines I
suggest there, unless anyone objects.

Ian.


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

Bug#727708: Init system resolution open questions

[Steven Chamberlain]

On 19/01/14 12:20, Adrian Bunk wrote:
> Why do you want Debian to support multiple init systems in the first place?

I think because:

* whichever is chosen as default, there will be some users who
specifically don't like it, or specifically want something else
(including major consumers like Ubuntu (Upstart), or Spotify (systemd),
or Google (SysV))

* the non-Linux ports may have no choice but to get some other init
system working anyway (if systemd is chosen as the default on Linux - I
am quite certain it would never be ported)

* if people are going to be doing the above work anyway, let's make it
available to everyone, Linux and non-Linux users alike

* if the chosen init system turns out to be a disaster, we'd have an
easy way out if we weren't fully reliant on it;  or maybe another init
system comes along for jessie+1, better than anything we have now, we'd
have more agility in being able to adopt it right away (not like this
current situation)


> What level of support (if any) would that guarantee for Debian's ports 
> to non-Linux kernels?

I don't think anyone can guarantee that in a volunteer project;  nobody
can be forced to do the work if they don't want to.  Porters may have to
work hard and restore any lost functionality they care enough about.  I
imagine such problems will be RC-severity bugs, so it should be possible
within existing practices to get patches applied or NMUd.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


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

Bug#734809: [Pkg-systemd-maintainers] Bug#734809: systemd: systemctl disable/enable => Failed to issue method call: No such file or directory

[Marco d'Itri]

On Jan 12, Michael Stapelberg  wrote:

> Hi Christoph,
> 
> Christoph Anton Mitterer  writes:
> > # systemctl enable ssh
> > Synchronizing state for ssh with sysvinit using update-rc.d...
> > Executing /usr/sbin/update-rc.d ssh defaults
> > insserv: warning: current start runlevel(s) (empty) of script `ssh' 
> > overrides LSB defaults (2 3 4 5).
> > insserv: warning: current stop runlevel(s) (2 3 4 5) of script `ssh' 
> > overrides LSB defaults (empty).
> > Executing /usr/sbin/update-rc.d ssh enable
> > Failed to issue method call: No such file or directory
> >
> > # systemctl disable ssh
> > Synchronizing state for ssh with sysvinit using update-rc.d...
> > Executing /usr/sbin/update-rc.d ssh defaults
> > Executing /usr/sbin/update-rc.d ssh disable
> > insserv: warning: current start runlevel(s) (empty) of script `ssh' 
> > overrides LSB defaults (2 3 4 5).
> > insserv: warning: current stop runlevel(s) (2 3 4 5) of script `ssh' 
> > overrides LSB defaults (empty).
> > Failed to issue method call: No such file or directory
> >
> >
> > There is always that "Failed to issue method call: No such file or 
> > directory" error.
> Not on my machine:
> 
> root@midna ~ $ systemctl enable ssh
> Synchronizing state for ssh with sysvinit using update-rc.d...
> Executing /usr/sbin/update-rc.d ssh enable
> root@midna ~ $ systemctl disable ssh
> Synchronizing state for ssh with sysvinit using update-rc.d...
> Executing /usr/sbin/update-rc.d ssh disable
> insserv: warning: current start runlevel(s) (empty) of script `ssh' overrides 
> LSB defaults (2 3 4 5).
> insserv: warning: current stop runlevel(s) (2 3 4 5) of script `ssh' 
> overrides LSB defaults (empty).
> root@midna ~ $ systemctl enable ssh 
> Synchronizing state for ssh with sysvinit using update-rc.d...
> Executing /usr/sbin/update-rc.d ssh enable

> Can you run strace -f -o /tmp/strace.log -s 2048 systemctl enable ssh
> and provide /tmp/strace.log? Also, please run strace -f -o
> /tmp/strace-systemd.log -s 2048 -p 1 before that and provide that file
> as well.
I can reproduce it with "systemctl disable isc-dhcp-server.service":

[...]
lstat64("/run/systemd/system/", {st_dev=makedev(0, 15), st_ino=5274, 
st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, 
st_blocks=0, st_size=40, st_atime=2014/01/19-02:08:18, 
st_mtime=2014/01/19-02:08:18, st_ctime=2014/01/19-02:08:18}) = 0
sendmsg(3, {msg_name(0)=NULL, 
msg_iov(2)=[{"l\1\0\1$\0\0\0\1\0\0\0\251\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\2\1s\0
 
\0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\20\0\0\0DisableUnitFiles\0\0\0\0\0\0\0\0\10\1g\0\3asb\0\0\0\0\0\0\0\0",
 192}, {"\34\0\0\0\27\0\0\0isc-dhcp-server.service\0\0\0\0\0", 36}], 
msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 228
clock_gettime(CLOCK_MONOTONIC, {24590, 163686570}) = 0
poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, 
msg_iov(1)=[{"l\4\1\1\0\0\0\0\1\0\0\0q\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\2\1s\0
 
\0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\20\0\0\0UnitFilesChanged\0\0\0\0\0\0\0\0l\4\1\1\0\0\0\0\1\0\0\0q\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\2\1s\0
 
\0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\20\0\0\0UnitFilesChanged\0\0\0\0\0\0\0\0l\3\1\1\36\0\0\0\2\0\0\0?\0\0\0\4\1s\0'\0\0\0org.freedesktop.DBus.Error.FileNotFound\0\5\1u\0\1\0\0\0\10\1g\0\1s\0\0\31\0\0\0No
 such file or 
directory\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 382
recvmsg(3, 0xffe8b3c0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily 
unavailable)
writev(2, [{"Failed to issue method call: No such file or directory", 54}, 
{"\n", 1}], 2) = 55
close(3)= 0
exit_group(1)   = ?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#724104: vmkit: FTBFS: make[1]: *** No rule to make target `Makefile.common'. Stop.

[Sylvestre Ledru]

On 29/11/2013 15:26, Sylvestre Ledru wrote:
>
>
> Yep, I am aware of that ... (upstream is a friend).
> He is currently refactoring some large part of vmkit to tackle this issue.

Upstream has started a refactoring in order to fix that issue.

Wait and see,
Sylvestre

Bug#720858: Dependency check for Gramps 4.0.2

[Ross Gammon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

Here is the status of the dependencies listed in README for Gramps
4.0.2 (Python 2) in Debian.

Depends:
Python 2.7 or greater - No need to list because it comes for free.
GTK 3.0 or greater - gir1.2-gtk-3.0 - seems to work.
pygobject 3.3.2 or greater - python-gi - seems to work.
cairo, pango, pangocairo - python-gi-cairo - seems to work.
librsvg2 - librsvg2-2 - nothing seems wrong.
xdg-utils - xdg-utils - nothing seems wrong.

Recommends:
osmgpsmap - gir1.2-osmgpsmap-1.0 - This is only in experimental, but
seems to work (as long as you install libosmgpsmap-1.0-dev to get the
library as well as the gir package). Can only depend on it once it
lands in unstable.
GraphViz - graphviz - Not tested, but no change from Gramps 3.4.6 release.
PyICU - python-pyicu - Not sure how to test this, but at least
recognised by gramps -v and no change from Gramps 3.4.6.

Suggests:
gtkspell - gir1.2-gtkspell3-3.0 - Works for me.
rcs - rcs - Works for me.
PIL - python-pil - Seems to work, although README description of
functionality may not be spot on.
GExiv2 - gir1.2-gexiv2-0.4 - Recognised by gramps -v, reporting
version 0.4 even though the version is 0.7. Not sure where GExiv is
actually used, but trying to add the Image-Metadata gramplet causes a
crash.
ttf-freefont - fonts-freefont-ttf - I have moved away from the
previous transitional package as recommended. Not sure how to test this.
gir-webkit - gir1.2-webkit-3.0 - This crashes for me. Will need to
patch so that gecko is used instead (as recommended in the README).
goocanvas2 - There is no goocanvas 2 in Debian yet. Have raised a bug.
Users can try installing the one from Ubuntu (gir1.2-goocanvas-2.0-9)
if desperate.

As you can see, we are still missing one "recommends" although it can
be installed from experimental for testing, and there are problems
with 3 of the "suggests" although two of them have a workaround.

Unless there are major objections, I will try and convince my sponsor
to upload it this week. I know 4.0.3 may be released soon, but that
may be too late for the Debian import freeze for Ubuntu 14.04.

Regards,

Ross
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS296/AAoJEFP+e72miRD8ILsP/RRUxXhbM8xw6ZR/P3Go7LDQ
qD6TwakF7MIFO+N4gfVpIe29OG5xzGb16ETYrRXJ6Mqq1ayGW2YmlXXpKeRf8tDE
Yik11172vAk0DSiRsyjEHlXkDhad4Hs2fTBXlZn4w8VWzOnBVyVj65KFoH7fd7KY
ZMj5mfzWWDT9gChKgC3obputKM2Zavl1hRRC/3klqk1lrUMc0OVAj/kjpkCyZvwO
JOYQekk0R9X4M1d2cu5V3Kc+/3OTHA7LuZE8WNPU3F+7jbhqUfpaxZHLmzWvdBJs
XD3Mts4WMB7RRgHhpiAbRJ5owOexFHIckUthprMHShylGyVBaX277SLP/14JzVzE
//HwA1nAf4Xvi8Tj59yRtX3ywkBYigM1VCX2A5NS2bz7ffa+gJev00gjZ09zGNPS
aKqg0ERKF1636MkW1Y+kkjWEfMKGymXCB21qE21hUslorGGfXHZTs3RvvAU2Kwic
G0itQjWOJe8pLGe5Fs5G4/9wy9nhljoWssNtlSTQQAm/FiFM3MzSMmf3/w5IUtXD
3AdFz4vaAP2J8xXfhaXkP3SuPjE3RMO2JEc70k5WNjJV+SFyI+8GVyv4pFz7Kug7
EFZCkgFtI3kpLX78uUXDx9HeUCD5ga66n+szT8H7Xu5t3T/x/uvc7l3fiW2IXQgl
I6isHKmJdY1MAJGO6H/l
=Sl1B
-END PGP SIGNATURE-


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

Bug#733578: RFS: hwinfo/20.1-1 [ITA] -- Hardware identification system

[Eriberto]

> On Sun, Jan 19, 2014 at 3:47 AM, Sebastien Badia  wrote:
>
>> I still have a lintian warning about « hardening-no-relro »,
>> but I don't known how to fix it :-/
>

Hi Sebastian,

I used your package libx86emu as example. See the attached patch for
your file friendly-makefile.patch. I put the $(CFLAGS) $(CPPFLAGS)
$(LDFLAGS) variables at the line that compiles the library. Then, the
gcc will receive these adtional parameters:

JAULA-root@canopus:/tmp/libx86emu/libx86emu-1.4# dpkg-buildflags --get CPPFLAGS
-D_FORTIFY_SOURCE=2

JAULA-root@canopus:/tmp/libx86emu/libx86emu-1.4# dpkg-buildflags --get CFLAGS
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security

JAULA-root@canopus:/tmp/libx86emu/libx86emu-1.4# dpkg-buildflags --get LDFLAGS
-Wl,-z,relro

You can read more at https://wiki.debian.org/Hardening.

I hope this help.

Cheers,

Eriberto
--- libx86emu-1.4_friendly-makefile.patch.orig	2014-01-19 12:07:54.550876791 -0200
+++ libx86emu-1.4_friendly-makefile.patch	2014-01-19 12:08:35.270875095 -0200
@@ -67,6 +67,15 @@
  
  shared: $(LIB_NAME)
  
+@@ -43,7 +46,7 @@
+ 	install -m 644 -D include/x86emu.h $(DESTDIR)/usr/include/x86emu.h
+ 
+ $(LIB_NAME): .depend $(OBJS)
+-	$(CC) -shared -Wl,-soname,$(LIB_SONAME) $(OBJS) -o $(LIB_NAME)
++	$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -shared -Wl,-soname,$(LIB_SONAME) $(OBJS) -o $(LIB_NAME)
+ 
+ test:
+ 	make -C test
 @@ -52,9 +55,16 @@
  	make -C test clean
  	rm -f *.o *~ include/*~ *.so.* .depend

Bug#736077: dont leak private network information (at least not by default)

[Holger Levsen]

package: libjs-jssip
tags: security

Hi Daniel,

thanks for working on usuable + secure RTC in the webbrowser!

During your presentation at the Paris mini-debconf I just learned that your 
libjs-jssip leaks all networks to the sip server (or calling party), which I 
consider a privacy violation (which has been implemented to improve the user 
experience by allowing the application to choose the best network connection).

Still, if I connect via route $X I expect this software not to leak my other 
routes, which might contaín sensitive information.

In the talk you said it was trivial to comment out these lines, so I'm asking 
you to do this by default and optionally allow it.


cheers,
Holger 


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

Bug#736078: choqok: different orig tarball used

[Pino Toscano]

Source: choqok
Version: 1.4-1
Severity: important

Hi,

it seems the orig tarball used for choqok is not the one released by
the choqok developers:
(a) -rw-r--r-- 1 pino users  814429 Sep 23 21:32 choqok_1.4.orig.tar.bz2
(b) -rw-r--r-- 1 pino users 1021228 Sep  1 05:18 choqok-1.4.tar.xz

(a) is the one currently in Debian, while (b) is the one released
upstream.
The only difference so far is the lack of translations in (a), which
is #686983; just using the real tarball is enough to have them shipped.

It looks like you might have taken the version from the Git tag of the
upstream repository; anyway, please make use of the upstream releases.

Thanks,
-- 
Pino


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

Bug#727708: logind working without systemd

[Thomas Goirand]

Sun, 19 Jan 2014 13:42:40 +0200, Russ Allbery
> Hopefully, logind will continue to work without systemd and people
> will volunteer to maintain the necessary packaging for that
> configuration, and none of this will be a problem.

I really wish you were right Russ. Because that's not what upstream is
doing (since systemd 205, it's not the case), and Debian package
maintainers have stated this as an argument in the favor of systemd.

I would very much like the tech ctte to express itself on this topic on
the final statement (whatever default init system is chosen).

Thomas


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

Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64

[Claus Fischer]

I think I experienced that as consequence of a dist-upgrade.

Fixing the bug instead of just closing it would also be my
preference. I realize that this may be a tough task, as
the situation will probably not be easy to reproduce.

If you've changed something to make co-installation work,
it's probably best to close the bug and wait if it re-appears.
However, if you haven't changed anything, the bug will still
be there.

Claus

-- 
Claus Fischer 
http://www.clausfischer.com/


signature.asc
Description: Digital signature

Bug#733578: RFS: hwinfo/20.1-1 [ITA] -- Hardware identification system

[Sebastien Badia]

On Sun, Jan 19, 2014 at 12:17:34PM (-0200), Eriberto wrote:
> You can read more at https://wiki.debian.org/Hardening.

Hi,

Yes! Thanks Eriberto,

@Vincent, thanks for your comments, I've just fixed this, 
packages are now lintian clean \o/ (libx86emu also)

Thanks !

Seb

-- 
Sebastien Badia


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

Bug#735478: [Pkg-xfce-devel] Bug#735478: Different patch

[Yves-Alexis Perez]

On Fri, Jan 17, 2014 at 04:25:48PM -0200, Ivan Baldo wrote:
> Hello.
> It happens for Montevideo, Uruguay too.
> I looked at the source and the patch from Christoph will make an
> assertion when viewing the forecast summary or something like that:
> at line 490 of weather-summary.c is called get_data_f (weatherdata,
> TEMP_MAX) and inside get_data_f() in weather-data.c NULL is checked
> for.
> There aren't any other users of the xml_dayf::hi element.
> The code can be changed safely to just put "NA" there or any
> other string, even an empty string (anything but NULL):

Yeah, I guess that'll do for now, stay tuned.
> 
> diff -urN xfce4-weather-plugin-0.7.4/panel-plugin/weather-parsers.c 
> xfce4-weather-plugin-0.7.4.allow_empty_hi/panel-plugin/weather-parsers.c
> --- xfce4-weather-plugin-0.7.4/panel-plugin/weather-parsers.c
> 2011-02-02 18:31:29.0 -0200
> +++ xfce4-weather-plugin-0.7.4.allow_empty_hi/panel-plugin/weather-parsers.c
> 2014-01-17 16:21:15.399088000 -0200
> @@ -301,7 +301,8 @@
>if (NODE_IS_TYPE (cur_node, "hi"))
>  {
>ret->hi = DATA (cur_node);
> -  g_assert (ret->hi != NULL);
> +  if (ret->hi == NULL)
> +ret->hi = g_strdup ("NA");
>  }
>else if (NODE_IS_TYPE (cur_node, "low"))
>  {
> 
> Thanks for uploading it!
> Bye.
> P.s.: thanks Christoph for your analysis and initial patch though!!!
> 
> -- 
> Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/
> From Montevideo, Uruguay, at the south of South America.
> Freelance programmer and GNU/Linux system administrator, hire me!
> Alternatives: iba...@codigolibre.net - http://go.to/ibaldo
> 
> ___
> Pkg-xfce-devel mailing list
> pkg-xfce-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xfce-devel

-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#687072: xbmc-bin: invalid pointer on munmap_chunk()

[Mircea Gherzan]

On 04.01.2014 17:46, Balint Reczey wrote:

I have checked CDVDOverlayCodecTX3G::Decode and there is nothing
obviously wrong with it.
Based on the stack trace I suspect there was a memory allocation issue
somewhere else in the code where the memory pointed to by the reported
invalid pointer has been freed.
Could you please test latest version from unstable?
If the issue still exists please run xbmc under valgrind to let us able
to find the place where the invalid free occurs.


Can't reproduce this with the current version in unstable, so please 
close this bug.


Thanks,
--
Mircea


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

Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64

[John Paul Adrian Glaubitz]

On 01/19/2014 03:35 PM, Claus Fischer wrote:
> If you've changed something to make co-installation work,
> it's probably best to close the bug and wait if it re-appears.

libsane has already been converted for MultiArch, hence such
issues should no longer arise.

If they do, it's ok to file another bug report or re-open
this one, but leaving the bug report alone forever without
giving further feedback isn't helping the cause, it's just
spamming the bug tracker.

We don't win anything if we leave this open forever while
no one is able to reproduce it reliably. Again, if you can
show me how to trigger this issue, I will be very happy
to re-open the bug and have a look at the issue.

I am aware of the fact that the SANE package still needs
some work and I several points left on my TODO list which
I will hopefully get done together with Mark, one of them
driving the package split for binary-only, all and MultiArch
packages further. There are still some redundancies
and duplicate files.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Bug#736079: gajim doesn't start

[Andrey Gusev]

Package: gajim
Version: 0.15.4-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,
I try to start gajim and it doesn't start. The oputput to console is
Traceback (most recent call last):
  File "gajim.py", line 217, in 
from ctypes import CDLL
File "/usr/share/gajim/src/common/demandimport.py", line 114, in 
_demandimport
mod = _origimport(name, globals, locals)
File "/usr/lib/python2.7/ctypes/__init__.py", line 555, in 
_reset_cache()
File "/usr/lib/python2.7/ctypes/__init__.py", line 279, in _reset_cache
CFUNCTYPE(c_int)(lambda: None)
RuntimeError: ffi_prep_cif failed with 2


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'oldstable'), (200, 'unstable'), (1, 
'experimental')
Architecture: powerpc (ppc)

Kernel: Linux 3.12.7 (SMP w/2 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 gajim depends on:
ii  dbus 1.6.18-2
ii  dnsutils 1:9.8.4.dfsg.P1-6+nmu3
ii  python-dbus  1.2.0-2+b1
ii  python-gtk2  2.24.0-3+b1
pn  python:any   

Versions of packages gajim recommends:
ii  ca-certificates  20130906
ii  python-crypto2.6.1-2
ii  python-openssl   0.13.1-1
ii  python-pyasn10.1.7-1
ii  xfce4-notifyd [notification-daemon]  0.2.4-2

Versions of packages gajim suggests:
ii  aspell-en [aspell-dictionary]  7.1-0-1
ii  aspell-ru [aspell-dictionary]  0.99g5-18
pn  avahi-daemon   
pn  dvipng 
pn  gnome-keyring  
ii  gstreamer0.10-plugins-ugly 0.10.19-2+b3
pn  kwalletcli 
ii  libgtkspell0   2.0.16-1
ii  libxss11:1.2.2-1
ii  nautilus-sendto3.6.1-2
pn  network-manager
pn  python-avahi   
pn  python-farstream   
ii  python-gconf   2.28.1+dfsg-1
pn  python-gnome2  
ii  python-gnomekeyring2.32.0+dfsg-3
pn  python-gupnp-igd   
pn  python-kerberos
ii  python-pycurl  7.19.0.3-1
pn  texlive-latex-base 

-- 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#736074: reassigned - only applies to jalv; was: calf-plugins: calf plugins lack graph display components, Calf Analyzer is empty, others still functional

[Zenaan Harkness]

On Sun, Jan 19, 2014 at 11:59:36PM +1100, Zenaan Harkness wrote:
> Package: calf-plugins

I reassigned this to package jalv

> Dear Maintainer,
> 
> When running a jackd session of some sort, the Calf plugins work in general, 
> except for the "graph" display components of the plugins.

This is the case, when running the plugins with jalv.

I suspect this 'bug' might ought be downgraded to feature-request. Feel free to 
do so if applicable.

> I am currently using gladish to set up my session, and running plugins for 
> testing purposes from the command line (and adding them to gladish when they 
> appeal to me), for example, here's another command line plugin cmd/run:
> 
> jalv.gtk http://calf.sourceforge.net/plugins/TransientDesigner

I discovered calfjackhost - it supports the graph component of the calf 
plugins. I assumed something like that existed, but only just found it.

> Also, the Calf Rack is missing, although it is advertised/mentioned in the 
> package description - however this should probably be a separate bug - let me 
> know if you'd like me to file a separate bug for this particular issue.

This was not the case - I found it, as above.

Thanks for your patience,
Zenaan


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

Bug#736080: pu: package xfce4-weather-plugin/0.7.4-5

[Yves-Alexis Perez]

Package: release.debian.org
Severity: normal
Owner: pkg-xfce-de...@lists.alioth.debian.org
User: release.debian@packages.debian.org
Usertags: pu

Hi,

it seems that the weather.com format changed again, in a way which makes
xfce4-weather-plugin crash in Wheezy (see #735478). This doesn't affect
Jessie/sid where it doesn't use weather.com anymore.

A tiny patch fixes the issue, so it'd be nice if this could be allowed
to go to PU.

Debdiff is attached.

Thanks in advance,
-- 
Yves-Alexis

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (450, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru xfce4-weather-plugin-0.7.4/debian/changelog xfce4-weather-plugin-0.7.4/debian/changelog
--- xfce4-weather-plugin-0.7.4/debian/changelog	2013-10-24 22:18:00.0 +0200
+++ xfce4-weather-plugin-0.7.4/debian/changelog	2014-01-19 15:56:44.0 +0100
@@ -1,3 +1,10 @@
+xfce4-weather-plugin (0.7.4-5) UNRELEASED; urgency=medium
+
+  * debian/patches:
+- 02_NULL-hi added, fix cases where  element is empty.  closes: #735478
+
+ -- Yves-Alexis Perez   Sun, 19 Jan 2014 15:55:39 +0100
+
 xfce4-weather-plugin (0.7.4-4) wheezy; urgency=low
 
   * debian/patches:
diff -Nru xfce4-weather-plugin-0.7.4/debian/patches/02_NULL-hi.patch xfce4-weather-plugin-0.7.4/debian/patches/02_NULL-hi.patch
--- xfce4-weather-plugin-0.7.4/debian/patches/02_NULL-hi.patch	1970-01-01 01:00:00.0 +0100
+++ xfce4-weather-plugin-0.7.4/debian/patches/02_NULL-hi.patch	2014-01-19 15:55:33.0 +0100
@@ -0,0 +1,12 @@
+--- a/panel-plugin/weather-parsers.c
 b/panel-plugin/weather-parsers.c
+@@ -301,7 +286,8 @@ parse_dayf (xmlNode *cur_node)
+   if (NODE_IS_TYPE (cur_node, "hi"))
+ {
+   ret->hi = DATA (cur_node);
+-  g_assert (ret->hi != NULL);
++  if (ret->hi == NULL);
++ret->hi = g_strdup("NA");
+ }
+   else if (NODE_IS_TYPE (cur_node, "low"))
+ {
diff -Nru xfce4-weather-plugin-0.7.4/debian/patches/series xfce4-weather-plugin-0.7.4/debian/patches/series
--- xfce4-weather-plugin-0.7.4/debian/patches/series	2013-10-24 21:58:04.0 +0200
+++ xfce4-weather-plugin-0.7.4/debian/patches/series	2014-01-19 15:56:06.0 +0100
@@ -1,2 +1,3 @@
 00_license.patch
 01_uri_change.patch
+02_NULL-hi.patch

Bug#735858: recover seems obsolete/dead-upstream and should be removed

[Luca BRUNO]

reassign 735858 ftp.debian.org
retitle 735858 RM: recover -- RoM; abandoned-upstream
thanks

Osamu Aoki  wrote:

> The core functionality is available in debugfs (from the "e2fsprogs"
> package) anyway via "list_deleted_inodes" and "undel" and debugfs is
> very well maintained.
> 
> If you agree that the recover should be removed, please reassign
> this bug as a removal request to ftp.debian.org.

Completely agree, reassigning for removal.

Thanks, Luca

-- 
  .''`.  |   ~<[ Luca BRUNO ~ (kaeso) ]>~
 : :'  : | Email: lucab (AT) debian.org ~ Debian Developer
 `. `'`  | GPG Key ID: 0x3BFB9FB3   ~ Free Software supporter
   `-| HAM-radio callsign: IZ1WGT   ~ Networking sorcerer


signature.asc
Description: PGP signature

Bug#706109: display how modified files have changed

[Ivo De Decker]

Hi Holger,

On Wed, Apr 24, 2013 at 09:20:59PM +0200, Holger Levsen wrote:
>  h01ger: about #678931, perhaps piuparts should use etckeeper and 
> report 
> the file content changes as well, to have some idea what is going on... :)

This can be done by adding the scripts in attach as custom scripts to the
scriptsdir. In that case piuparts needs to run with '-I /etc/.git', to ignore
the data in the git repo.

Also, with these scripts, piuparts won't detect issues caused by missing
dependencies on packages depended on by etckeeper.

Cheers,

Ivo

#!/bin/sh
apt-get -y install etckeeper

etckeeper vcs tag post_setup
#!/bin/sh

etckeeper commit post_purge || true
etckeeper vcs diff pre_test
#!/bin/sh

etckeeper commit post_install || true
etckeeper vcs tag pre_test

Bug#727708: Init system resolution open questions

[Tollef Fog Heen]

]] Adrian Bunk 

> On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote:
> > ]] Adrian Bunk 
> > 
> > > I already gave my hypothetical "udev gets a hard dependency on systemd 
> > > as init system" worst case.
> > > To make the worst case even worse, assume a new upstream version of 
> > > systemd with this change gets released 2 weeks before the jessie freeze,
> > > and gets uploaded into unstable immediately.[1]
> > 
> > Then the systemd maintainer (i.e. me and the rest of the team) should be
> > bopped on the head.
> > 
> > I'd appreciate if your hypothetical scenarios aren't «let's assume that
> > everyone are bonkers and do crazy stuff», since well, if they are, we
> > need to fix that.  The problem then isn't that they're uploading
> > packages which are not appropriate for the archive, it's that they don't
> > understand why that is a problem.
> 
> What is bonkers and what is not is very subjective, and that's the 
> problem here.

No, it's not subjective.

> If I was a systemd maintainer I would consider it a reasonable option to 
> rather upload a new version of systemd that adds such a dependency to 
> udev instead of shipping an ancient systemd in the next release.
> 
> Or would you want to ship systemd 204 in jessie if that would 
> hypothetically be the only option for providing logind for
> non-systemd in the jessie timeframe?

That's not the point.  The point is that it's not reasonable to break
other people's packages in a significant and work-intensive manner two
weeks before release, which is your scenario.  There is no way that's
ok.  On the other hand, trying to formalise exactly how much you can
inconvenience somebody how far in advance of the release is a futile
exercise.  Is requiring one other package to make a tiny change two
years in advance of the freeze ok?  If so, how about one year?  One
month?  20 days? etc.  Don't regulate it explicitly but tell people that
they have to behave reasonably towards their fellow developers.

If people have no idea what that means, we already have a problem and
need to fix that.  If they disagree over the minutae, that's fine and we
might need to decide exactly where the line goes in a few cases, but we
can do that when the problem shows up, rather than try to antipacitate
every case where it might go wrong.

> > You can't regulate «don't be crazy», since if people want to, or don't
> > understand what crazy means they will route around such a decision using
> > technicalities.
> 
> That's why in the case of Debian supporting multiple init systems (and 
> optionally additionally non-Linux ports) there has to be a strict policy 
> enforcing that this also stays supported.
> 
> If you go bonkers tomorrow and add a dependency on systemd-sysv to udev,
> will that be considered an RC bug that will prevent your package from 
> ever reaching testing until a udev without that dependency will be in
> the archive? [1]

I sure hope so.  If nothing else because the package is uninstallable
without manual override.  It'd break unrelated packages.  It'd probably
break d-i.

> If multiple init systems should be supported accordinng to the CTTE 
> decision, then the CTTE decision has to make it clear that "Yes" is
> the answer to that question.

Regulating the way you are advocating means you're moving the Overton
window on what's considered acceptable or borderline acceptable and so I
really don't think that's a good idea.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Bug#735968: dh-make-perl: Prints warning about missing pristine-tar even though it is installed

[Axel Beckert]

Control: tag -1 + pending

Hi Ivan,

Axel Beckert wrote:
> Can you tell us with which perl module and which module version this
> happened, so we have an example to check if my conclusions are
> correct?

No more needed. I was able to reproduce the error with (more or less)
the following commands:

apt-get source libzabbix-api-perl
cd libzabbix-api-perl
origtargz
arepack ../libzabbix-api-perl_0.009.orig.tar.gz 
../libzabbix-api-perl_0.009.orig.tar.xz
rm -rvf ../libzabbix-api-perl_0.009.orig.tar.gz debian
dh-make-perl .

Output of dh-make-perl:

== dh-make-perl 0.80 ==
Trying /tmp/libzabbix-api-perl/../libzabbix-api-perl.tar.gz... not found.
Using META.json
Found: Zabbix-API 0.009 (libzabbix-api-perl arch=all)
Trying ../libzabbix-api-perl_0.009.orig.tar.gz... not found.
Switched to a new branch 'master'
Using cached Contents from Sun Jan 19 14:57:30 2014
+ LWP found in libwww-perl
+ Params::Validate found in libparams-validate-perl
+ JSON found in libjson-perl
= perl >= 5.010001 is in core

Needs the following debian packages: libwww-perl, libparams-validate-perl, 
libjson-perl, perl
= File::Spec is in core since 5.4.50
= Test::More is in core since 5.6.2
= Module::Build >= 0.36_14 is in core since 5.13.10
+ Test::Exception found in libtest-exception-perl

Needs the following debian packages during building: perl (>= 5.13.10), 
libtest-exception-perl
Using maintainer: Axel Beckert 
Found docs: 
Found examples: examples/*
Using rules: /usr/share/dh-make-perl/rules.dh7.tiny
Module::Build needs perl
W: pristine-tar not available. Please run
W: apt-get install pristine-tar
W:  followed by
Use of uninitialized value $tarball in concatenation (.) or string at 
/usr/share/perl5/DhMakePerl/Command/make.pm line 762.
W: pristine-tar commit  upstream/0.009
--- Done
Reading package lists... Done
Building dependency tree   
Reading state information... Done
**
WARNING: a package named
  'libzabbix-api-perl'
 is already available in APT repositories
Maintainer: Debian Perl Group 
Description: abstraction layer over the JSON-RPC API provided by Zabbix
dh-make-perl .  35,12s user 1,96s system 96% cpu 38,563 total

I've got some potential fixes for the issues which this brought up
here locally. Just have to test them first before pushing.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


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

Bug#736081: Won't authenticate over STARTTLS without AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS

[Juliusz Chroboczek]

Package: exim4-daemon-light
Version: 4.82-3

Smarthost requires STARTTLS and PLAIN login -- therefore the
connection is authenticated.  A default install refuses to authenticate:

SMTP>> STARTTLS
SMTP<< 220 2.0.0 Ready to start TLS
SMTP>> EHLO x.x.x.x
SMTP<< 250-x.x.x.x
   250-PIPELINING
   250-SIZE 1024
   250-ETRN
   250-AUTH PLAIN LOGIN
   250-AUTH=PLAIN LOGIN
   250-ENHANCEDSTATUSCODES
   250-8BITMIME
   250 DSN
  [...]
  x.x.x.x in hosts_require_auth? no (option unset)
  search_open: nwildlsearch "/etc/exim4/passwd.client"
  search_find: file="/etc/exim4/passwd.client"
key="x.x.x.x" partial=-1 affix=NULL starflags=0
  [...]
  x.x.x.x in "*.x.x"? yes (matched "*.x.x")
  lookup yielded: x:x
  [...]
SMTP>> MAIL FROM:<> SIZE=2447
SMTP>> RCPT TO:
SMTP>> DATA
  [...]
SMTP<< 250 2.1.0 Ok
SMTP<< 554 5.7.1 : Client host rejected: Access denied
SMTP<< 554 5.5.1 Error: no valid recipients

If I add ``AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS = true'' to the exim
configuration, everything works fine:

SMTP>> STARTTLS
SMTP<< 220 2.0.0 Ready to start TLS
SMTP>> EHLO x.x.x.x
SMTP<< 250-x.x.x.x
   250-PIPELINING
   250-SIZE 1024
   250-ETRN
   250-AUTH PLAIN LOGIN
   250-AUTH=PLAIN LOGIN
   250-ENHANCEDSTATUSCODES
   250-8BITMIME
   250 DSN
SMTP>> AUTH PLAIN 
SMTP<< 235 2.7.0 Authentication successful

However, this should not be needed, since the connection is protected
by TLS.

-- Juliusz


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

Bug#736082: fennics depends on ufc-doc which is no longer built by current ufc source package

[peter green]

Package: fenics
Severity: serious
Tags: jessie, sid

Fenics depends on ufc-doc. The version of the ufc source package in 
jessie and sid no longer builds this binary package.



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

Bug#727708: On diversity

[Anthony Towns]

On 17 January 2014 03:52, Ian Jackson  wrote:
> What is Debian ?  In one respect, Debian is an operating system.  And
> of course in another respect Debian is a community.
> * Debian is a forum for cooperation and technical development.
> * Debian, as a piece of software, tries to be all things to all
>   people (within reason).

So the original message referring this to the tech ctte was about
deciding on "the default init system". Honestly, that seems like the
least interesting part of this discussion to me; and I wonder if the
ctte shouldn't consider answering some different, but related question
that more directly addresses issues like packages depending on cgroups
or logind. Something like:

 a) maintainers should be aware cgroups is a Linux-only feature; if
their package requires the use of cgroups to be usable it should be
configured to not build for non-Linux architectures.

 b) maintainers should be aware systemd relies heavily on cgroups, and
thus should be aware that requiring use of a systemd unit file for
startup will likewise require their package to be configured to not
build for non-Linux architectures.

 c) logind or an equivalent service implementing the freedesktop.org
systemd/logind api should be available under all supported init
systems and architectures in Debian. It should be provided via a
virtual package "fdo-logind" and packages (such as desktop managers)
expecting logind to be available should Depend on fdo-logind

 d) [are packages likely to start depending on
localed/hostnamed/timedated/machined/??? in the same way as logind
such that it would need to be available outside systemd for upstart to
be a useful init?]

 e) no init system in Debian should be marked as Essential:yes, or
depended upon by any Essential:yes or Priority:required package except
through the virtual package "init-system". All init packages should
Provide: and Conflict: init-system. base-files should Depend:
init-system.

 f) all init systems Providing the init-system virtual package must
support packages providing sysv style init scripts via update-rc.d.

 g) packages that do not work with sysv must declare a Depends: on the
init systems they do support, eg upstart | systemd

 h) having examined the various current available init systems, the
tech ctte considers [OpenRC] to be the best available init
implementation at present, and so determines that the relevant
maintainers, including the installer team and ftpmasters se it as the
default init-system for new Debian installs. This decision becomes
vacant should a general resolution specifying an alternative init
system as the default pass with a simple majority prior to jessie's
release.

 i) all these decisions revert to advisory opinions after the release
of jessie, and may then be changed by the usual methods of consensus
driven policy development, and maintainer decisions, or by referring
the issue to the tech ctte again.

I think (a) and (b) are pretty non-controversial. (c) and (d) are
required if we want to deal with new GNOME stuff and anything other
than systemd probably, and don't seem very hard to either do or
document. (e), (f) and (g) seem like a fairly straightforward of
allowing for multiple init systems in Debian. I think something like
(i) might be a good way of sunsetting tech ctte decisions so if
there's an actual consensus in future, there's no need to get a
pro-forma vote from the ctte to make changes in future. YMMV of
course.

In my ideal world, the tech ctte would work out good answers to all
the bits above except (h) and get those added to policy, then propose
various options for (h) as a GR themselves, with well argued
rationales for each of the options along the lines of what's already
been posted to the list. How much that conflicts with the "No detailed
design work" portion of the ctte's mission statement is up for debate
though. Why you'd have a *technical* committee and forbid them making
sure the "details" are right doesn't make a lot of sense to me though.
Fortunately I'm not on the tech ctte list, so I can look into details
all I like ;)

Cheers,
aj


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

Bug#735765: IMAP: WL calls STATUS on selected folder

[Juliusz Chroboczek]

Hi David,

Please note the changed CC (so that the Debian ticket gets your replies).

> This bug is indeed fixed in the branch heimkehr in WL's
> repository. This branch also contains an improved IMAP search courtesy
> of Erik Hetzner.
>
> The fix for the IMAP SELECT bug required more than the commits you
> mentioned.

Noted.

>> (1) elmo-folder-close doesn't unselect the IMAP folder;
>> (2) elmo-folder-status-plugged doesn't treat the selected folder specially.

> WL has to keep track of EXIST and RECENT server responses for the
> selected mailbox (MUST per RFC3501, 7.3) and use these values when
> queried for the status of a selected mailbox. This fixes (2) and makes
> a fix for (1) unnecessary. Fixing this bug required some additional
> changes to WL's drafting algorithms.

Yes, that's way better -- avoiding deselecting the read mailbox should
be faster, at least with some servers.

> I think the easiest way to solve this issue would a merge from
> 'heimkehr' to 'master'.

Are you going to do that?

Thanks for your reply,

-- Juliusz


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

Bug#736080: pu: package xfce4-weather-plugin/0.7.4-5

[Julien Cristau]

On Sun, Jan 19, 2014 at 16:04:03 +0100, Yves-Alexis Perez wrote:

> Package: release.debian.org
> Severity: normal
> Owner: pkg-xfce-de...@lists.alioth.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi,
> 
> it seems that the weather.com format changed again, in a way which makes
> xfce4-weather-plugin crash in Wheezy (see #735478). This doesn't affect
> Jessie/sid where it doesn't use weather.com anymore.
> 
> A tiny patch fixes the issue, so it'd be nice if this could be allowed
> to go to PU.
> 
are there any other places where this kind of trivial missing input
check is missing?  Might be worth being slightly more proactive about
this to avoid a crash next month...

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#736083: RM: llvm-toolchain-3.2 -- ROM; Deprecated version

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal

Hello,

Version 3.2 is deprecated.
llvm-defaults has default to 3.3 and the latest release is 3.4.

Thanks,
Sylvestre


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

Bug#736075: [Pkg-xfce-devel] Processed: Re: Bug#736058: apparmor: no abstractions/dbus-accessibility

[intrigeri]

Hi,

Yves-Alexis Perez wrote (19 Jan 2014 15:11:58 GMT) :
> Thanks. What am I supposed to do with that? Could you at least provide
> some context when reassigning a bug?

Sure. I thought the cloned bug had enough info in it. Sorry.

In short, the AppArmor profile shipped by the lightdm package requires
an "abstraction" file that is not part of any upstream AppArmor
release yet, and is not shipped by the apparmor Debian package.
I suspect this profile was taken from Ubuntu, whose apparmor package
has cherry-picked the upstream commit that adds this abstraction.

What should be done IMO is to patch the buggy AppArmor profile to work
on Debian. Commenting out the faulty line ('#include
') until Debian's apparmor ships the
missing abstraction would be enough. I don't think doing this would
have any adverse effect: the dbus-accessibility abstraction only adds
a "dbus bus=accessibility" permission, that is useless on anything but
a heavily patched kernel + AppArmor userspace currently:  the dbus
rules are currently only supported on Ubuntu trusty, and getting this
support upstream and into Debian will take a while.

Don't hesitate asking if you need more info or clarification :)

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


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

Bug#735765: IMAP: WL calls STATUS on selected folder

[David Maus]

This bug is indeed fixed in the branch heimkehr in WL's
repository. This branch also contains an improved IMAP search courtesy
of Erik Hetzner.

The fix for the IMAP SELECT bug required more than the commits you
mentioned.

WL has to keep track of EXIST and RECENT server responses for the
selected mailbox (MUST per RFC3501, 7.3) and use these values when
queried for the status of a selected mailbox. This fixes (2) and makes
a fix for (1) unnecessary. Fixing this bug required some additional
changes to WL's drafting algorithms.

The fix for the STATUS bug was initially done in the
'elmo-imap4-compliance' branch and later merged into 'heimkehr'.

I think the easiest way to solve this issue would a merge from
'heimkehr' to 'master'.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


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