Bug#679039: boot crash with VT6415 controller (pata_via)
Hi. Thanks for the reply. I'll do some further investigation as you suggest and report back in a couple of days. On 27 June 2012 00:10, Jonathan Nieder jrnie...@gmail.com wrote: Which upstream version have you tested? I've not used upstream kernels in a long time (many years). The custom-built 2.6.33 I referred to is still a Debian make-kpkg build with Debian patches. In terms of kernel versions, I cannot remember the 2.6.x versions which failed. However, I've had crashes with 3.0, 3.1 and 3.2. . What other kernels have you tried? Does the 3.4.y kernel from experimental reproduce this? I'll try this. . How reproducible is this? 80%? 100%? I'll do 10 normal boots and 10 recovery boots and let you know. . How heavy is the crash? E.g., can you still toggle the caps lock LED or use the magic sysrq key? Neither work. Looks like a PCI or IRQ lockup. . Do you have a log or photo of the crash? netconsole[1] or serial console[2] may be useful for this. I'll give netconsole a go. I may have to plug a laptop into the same switch. Any other hints or strange symptoms? Just a comment. Ever since I built my first Debian machine (in about 1996), I've used underdog hardware, rather than Intel. Cyrix then AMD processors, VIA chipsets, Cirrus then VIA (integrated) graphics, 3com NICs. I finally switched to an AMD chipset but the motherboard still has a VIA firewire controller that I cannot get to work with a DV camera, and this PATA controller that's causing grief. VIA hardware just appears to be cursed. Regards, Giuliano. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650485: freeimage: FBTFS: Source/FreeImage/PluginPNG.cpp:106:56: error: no matching function for call to 'MAX(DWORD, png_size_t)'
Hi,
This bug was fixed in 3.15.3.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679206: nautilus: Font size remains normal when renaming file/directory (in list view)
Package: nautilus Version: 3.4.2-1 Severity: normal Dear Maintainer, when showing a directory's content in list view, Ctrl++/- increases or decreases the font size of the list. However, when renaming an item, the font size of the rename text field that appears is still the original size, i.e. being (much) smaller or bigger than the surrounding items. IMHO the font size of the rename text field should have the same font size as the list has. The current state can make it hard when intendedly the font size was increased for the purpose of better reading to see what exactly one is changing, either when e.g. the screen is rather far away (HTPC) but also from a barrier-free point of view. The seemingly too large rename font size while the list is to a minimum size however just looks ugly. Regards, Oli -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nautilus depends on: ii desktop-file-utils 0.18-1 ii gsettings-desktop-schemas 3.4.2-1 ii gvfs 1.12.3-1+b1 ii libatk1.0-02.4.0-2 ii libc6 2.13-33 ii libcairo-gobject2 1.12.2-1 ii libcairo2 1.12.2-1 ii libexempi3 2.2.0-1 ii libexif12 0.6.20-2 ii libgail-3-03.4.2-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libglib2.0-data2.32.3-1 ii libgnome-desktop-3-2 3.4.2-1 ii libgtk-3-0 3.4.2-1 ii libnautilus-extension1a3.4.2-1 ii libnotify4 0.7.5-1 ii libpango1.0-0 1.30.0-1 ii libselinux12.1.9-5 ii libtracker-sparql-0.14-0 0.14.1-1+b1 ii libx11-6 2:1.5.0-1 ii libxml22.8.0+dfsg1-4 ii nautilus-data 3.4.2-1 ii shared-mime-info 1.0-1 Versions of packages nautilus recommends: ii brasero 3.2.0-4 ii eject2.1.5+deb1+cvs20081104-10+b1 ii gnome-sushi 0.4.1-2 ii gvfs-backends1.12.3-1+b1 ii librsvg2-common 2.36.1-1 Versions of packages nautilus suggests: ii eog3.4.2-1 ii evince [pdf-viewer]3.4.0-2+b1 ii totem 3.0.1-8 pn trackernone ii vlc [mp3-decoder] 1:2.0.1-dmo2 ii vlc-nox [mp3-decoder] 1:2.0.1-dmo2 ii xdg-user-dirs 0.14-1 -- 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#679074: [Pkg-libvirt-maintainers] Bug#679074: Please separate the init scripts for a system-wide libvirtd from the binaries usable for a per-user libvirtd
On Tue, Jun 26, 2012 at 10:01:08AM -0700, Josh Triplett wrote: On Tue, Jun 26, 2012 at 06:08:06PM +0200, Guido Günther wrote: On Tue, Jun 26, 2012 at 01:05:36AM -0700, Josh Triplett wrote: Package: libvirt-bin Severity: normal libvirt-bin currently includes both the libvirtd binary (and other binaries) and the init scripts to start a system instance of libvirtd. However, many applications using libvirt only need a per-user instance of libvirtd, not a system instance. For instance, gnome-boxes currently depends on libvirt-bin to get libvirtd, but it doesn't need the system instance. According to gnome-boxes upstream, you can connect to remote instances, but the only thing that is sanely integrated in the UI is creating local VMs in a per-user libvirtd. (Anything else, including the system instance, requires hand-entering a libvirt URI.) So, please split the init scripts for a system-wide libvirtd instance into a separate package from the binaries. Does it really make sense to split out the init script? Wouldn't disabling the daemon also do the trick? The gnome metapackage now depends on gnome-boxes, and gnome-boxes depends on libvirt-bin. So, a default install of GNOME will end up with a running system instance of libvirtd that nothing uses. Users shouldn't have to manually disable unused daemons that only get pulled in by dependencies, especially as part of the default install of something like GNOME. This seems quite similar to the situation with Apache: gnome-user-share depends on apache2.2-bin to get the binaries for the Apache web server, which it can configure and run on a per-user basis to share files. The Apache packages ship the init scripts in a separate package, so that installing gnome does not result in a running system-wide web server. I see. I planed something for 0.9.13 like: So something like: libvirt-daemon libvirt-daemon-qemu libvirt-daemon-xen ... libvirt-client libvirt-doc I'll add: libvirt-daemon-config containing the daemon config from /etc as well as the systemd startup scripts. This would allow boxes to depend on libvirt-daemon-qemu only pulling in the one hypervisor. I'm not sure we'll get this in place ffor wheezy though. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560244: RFS: mysql-cluster
I have replied toSteven privately. I look forward to this package being in Debian but I don't think it will be very quick. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679207: boincmgr segfault when setting proxy
Package: boinc-manager Version: 7.0.27+dfsg-6 Severity: normal Hi, After switching to gcc-4.7, recent build of boinc-manager gets a segfault when setting proxy. I suspect it's a wx bug. Here is a log of boincmgr under valgrind. (built in sid, with --enable-debug and --enable-wx-debg) Also gdb backtrace. 12:00:10 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin 12:00:10 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End 12:00:11 AM: Trace: (Function Start/End) CAdvancedFrame::OnOptions - Function Begin 12:00:14 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin 12:00:14 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin 12:00:14 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End 12:00:14 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin 12:00:14 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End 12:00:14 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End 12:00:14 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin 12:00:14 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End 12:00:15 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin 12:00:15 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin 12:00:15 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End 12:00:15 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin 12:00:15 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End 12:00:15 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End 12:00:15 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin 12:00:15 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End 12:00:16 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin 12:00:16 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin 12:00:16 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End 12:00:16 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin 12:00:16 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End 12:00:16 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End 12:00:16 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin 12:00:16 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End 12:00:17 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin 12:00:17 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin 12:00:17 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End 12:00:17 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin 12:00:17 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End 12:00:17 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End 12:00:17 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin 12:00:17 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End 12:00:18 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin 12:00:18 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin 12:00:18 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End 12:00:18 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin 12:00:18 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End 12:00:18 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End 12:00:18 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin 12:00:18 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End 12:00:19 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function Begin 12:00:19 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function Begin 12:00:19 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateTaskbarStatus - Function End 12:00:19 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function Begin 12:00:19 AM: Trace: (Function Start/End) CTaskBarIcon::UpdateNoticeStatus - Function End 12:00:19 AM: Trace: (Function Start/End) CTaskBarIcon::OnRefresh - Function End 12:00:19 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function Begin 12:00:19 AM: Trace: (Function Start/End) CAdvancedFrame::OnRefreshView - Function End ==26000== Invalid read of size 4 ==26000==at 0x44D760: wxStringData::Unlock() (DlgAdvPreferencesBase.cpp:768) ==26000==by 0x60D2DE1: wxStringBase::operator=(wxStringBase const) (string.cpp:784) ==26000==by 0x497899:
Bug#662895: linux-image-3.2.0-1-amd64: keys get stuck and keyboard stops
It seems the same bug, but not only the ps/2. Usb keyboard resumes after reconnecting, but not the ps/2. But in vte keyboard works well. Maybe bug in xorg? kernel: 3.2.0-2-amd64 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679208: ldm-themes: leaves alternatives after purge
Package: ldm-themes Version: 12.06.1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails The leftover files are actually alternatives that were installed by the package but have not been properly removed. While there is ongoing discussion how to remove alternatives correctly (see http://bugs.debian.org/71621 for details) the following strategy should work for regular cases: * 'postinst configure' always installs the alternative * 'prerm remove' removes the alternative * 'postrm remove' and 'postrm disappear' remove the alternative In all other cases a maintainer script is invoked (e.g. upgrade, deconfigure) the alternatives are not modified to preserve user configuration. Removing the alternative in 'prerm remove' avoids having a dangling link once the actual file gets removed, but 'prerm remove' is not called in all cases (e.g. unpacked but not configured packages or disappearing packages) so the postrm must remove the alternative again (update-alternatives gracefully handles removal of non-existing alternatives). Note that the arguments for adding and removing alternatives differ, for removal it's 'update-alternatives --remove name path'. Filing this as important as having a piuparts clean archive is a release goal since lenny. From the attached log (scroll to the bottom...): 0m36.9s ERROR: WARN: Broken symlinks: /usr/share/ldm/themes/default - /etc/alternatives/ldm-theme /etc/alternatives/ldm-theme - /usr/share/ldm/themes/joy 0m39.5s ERROR: FAIL: Package purging left files on system: /etc/alternatives/ldm-theme - /usr/share/ldm/themes/joy not owned /usr/share/ldm/owned by: ldm-themes /usr/share/ldm/themes/ owned by: ldm-themes /usr/share/ldm/themes/default - /etc/alternatives/ldm-theme not owned cheers, Andreas ldm-themes_12.06.1.log.gz Description: GNU Zip compressed data
Bug#662895: linux-image-3.2.0-1-amd64: keys get stuck and keyboard stops
Hi Alex, adzeitor wrote: It seems the same bug, but not only the ps/2. Please file a separate bug. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569276: binutils-gold: internal error in convert_types linking Linux
Jonathan Nieder wrote: Matthias Klose wrote: is this seen as well with binutils-gold from experimental? I think it was For reference, that got filed separately: http://bugs.debian.org/573060 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573822: RFA: gwibber -- microblogging client for GNOME
I was looking through RFA and came across this package, I used to blog with it often in Ubuntu and would like to know if anyone is interested in working on this project with me? I am brand new to the development side of things and would like to maintain this package with the guidance of the Debian community. How would I get involved on this project and if necessary take it over. Can someone respond privately and let me know how to? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678957: btrfs-tools: snapshot of a subvolume in itself behaves strangely
Actually the invisible directory xxx/xxx created by btrfs subvolume snapshot . xxx can be removed by rmdir xxx/xxx. (Martin Ziegler) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679209: Opening a normal terminal when root terminal is open does not work
Package: gnome-terminal Version: 3.4.1.1-1 Severity: important Tags: upstream Opening - after a normal terminal - a root terminal works. However, if attempting to open a normal terminal when a root terminal is open, there is no reaction from the system. Bug appears only in the new mode of GNOME3, in Classic mode the problem does not exist. David Moerike -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-terminal depends on: ii gconf-service 3.2.5-1 ii gnome-terminal-data3.4.1.1-1 ii gsettings-desktop-schemas 3.4.2-1 ii libatk1.0-02.4.0-2 ii libc6 2.13-33 ii libgconf-2-4 3.2.5-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libgtk-3-0 3.4.2-1 ii libice62:1.0.8-2 ii libpango1.0-0 1.30.0-1 ii libsm6 2:1.2.1-2 ii libvte-2.90-9 1:0.32.2-1 ii libx11-6 2:1.5.0-1 Versions of packages gnome-terminal recommends: ii gvfs 1.12.3-1+b1 ii yelp 3.4.2-1 gnome-terminal 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#675971: what should we be doing?
Hi, On Tuesday 26 June 2012 23:33:39 Chris Knadle wrote: I'm assuming all of the above is true under normal circumstnaces when CELT 0.7.1 support is included. However with libcelt0-0 removed, mumble version 1.2.3-349-g315b5f5-1 is unable to communicate via server loopback to the majority of the public mumble servers (at least in the United States) all of which seem to have versions = 1.2.3. Protocol support for Opus was only enabled in fairly recent development versions, so server builds that are based on 1.2.3 and only include selected upstream patches will most likely not advertise it. Effectively, the standardisation process and related resolution of licensing issues for the new codec are one of the things holding back a proper 1.2.4 release. So for reliable support, the safer bet would be to wait for 1.2.4; until then, it's under development and may break in weird ways. Regards, Nicos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678795: task-desktop: Flash support should pull in browser-plugin-lightspark
Le mercredi, 27 juin 2012 07.34:20, Christian PERRIER a écrit : Thanks for the detailed answer. Am I correct concluding that we can safely add browser-plugin-lightspark to the desktop task? My opinion as maintainer is that is is safe to do so _provided_ lightspark gets more bugs filed; ironically. Due to the nature of both the lightspark project and Youtube (and other flash-relying websites), the combination of both will be broken over time. This brokenness needs to be documented as bugs in the Debian BTS for it to have a chance to be fixed. (CC'ing debian-release@ for opinions on the following) My main concern is that a useful lightspark will need rather frequent updates, even in stable. I think it's better to have a semi-working not-totally-stable free flash player than letting our users rely on Adobe's. Release Team: would a more liberal upgrade policy be acceptable for lightspark ? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#678679: Spice, current status and the fueture in Debian
On Wed, Jun 27, 2012 at 12:34:36PM +0800, Liang Guo wrote:
On Mon, Jun 25, 2012 at 05:29:09PM +0300, Michael Tokarev wrote:
Why do you say the package is in bad shape ? Please explain.
Current version in experimental, if not counting the removal of
celt, should be quite good, no?
IMO, spice 0.10.1-3~nocelt in experimental is in good shape, spice
0.10.1-2 with celt embedded in sid is not.
Then you have nothing to lose by pushing the experimental version to
unstable as soon as possible - but this must be done today or tomorrow
or you will miss the freeze window and your options will be very much
reduced.
Now, I think the best course to take is:
1) push current experimental, celt-less version to unstable,
after some basic verifications of audio.
2) maybe update to 0.11, to at least fix known bugs.
It is unclear whenever upstream will support 0.10 stable version, but
it is more
no than yes, or else the 32bit bug should have been fixed long ago.
3) depending on the result (if it works at all or not ;), either keep it
this way or drop it from wheezy entirely.
How can we test spice with celt removed to make sure it works fine? if we
can and we do the test. I think it's OK to ship spice without celt to wheezy,
and no technical committee decision is needed.
Consider another situation, we can do some simple test aganst spice with
our patch that removes celt support, spice client {with, without} celt can
connect to spice server {with, without} celt, and audio works, but we cannot
test spice without celt with older spice used by other platform, should
we include our spice without celt to wheezy or remove it? This is what
I want technical committee to help us to decide.
It will take the tech-ctte a considerable amount of time and work to be in
a position to judge this better than you and Michael can. This is a job for
the normal package maintainers to do.
If you say the current package in unstable is in 'bad shape', then if you
miss the freeze for uploading the experimental one, your only option will
be to remove it. If you put the version in experimental into unstable,
then you still have the option to remove it later if problems are reported
that become showstoppers. (since they would become release critical bugs
that 'automatically' get it removed if they can't be reasonably fixed)
Sure thing the best will be to have opus support in spice in wheezy. And
this is the most close variant I can think of.
I think opus should be added upstream first, then backported to debian or wait
upstream release a version with opus support. If we add opus support ourself,
upstream may add opus support with a way that may not compatible with us, then
we will be in a passive position.
Nobody is proposing that *we* do this. It has been discussed with upstream
and they are working on it. When they have something to test, then you can
begin testing it.
So far as I can see, you Michael and I all agree that the experimental
package is the only viable candidate for Wheezy. But you will lose that
option if you do not upload it very, very soon. The freeze happens in
the next few days.
Ron
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679143: [Pkg-haskell-maintainers] Bug#679143: ghc: New bugfix release: 7.4.2
Hi, Am Dienstag, den 26.06.2012, 19:09 +0200 schrieb Giorgio Marinelli: Package: ghc Version: 7.4.1-4 Severity: wishlist New bugfix release: 7.4.2 uploading ghc 7.4.2 to unstable will require rebuilding everything; there is no way the release team will be happy about this at this stage during the freeze. Also after the freeze we will want to have 7.4.1-based libraries in unstable for a while to be able to get fixes into testing via unstable and a freeze exception (e.g. pandoc issues or the xmonad problem). So GHC 7.4.2 will have to wait for a while. An upload to experimental would be ok. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#679022: does not state domain of unauthenticated/unsigned packages
On 27 June 2012 00:11, Richard Betham rich...@betham.org.uk wrote: I have copied the directory trees /media/cdrom0/pool , and /media/cdrom0/dists to a new directory /wheezy/. I have altered /etc/apt/sources.list to: deb file:///wheezy/ wheezy contrib main I am testing debian-testing-i386-DVD-1.iso . A wheezy cd image here has no Release.gpg or InRelease files required for verification. If your image is similar and you do trust it, sources.list can be altered to indicate this: deb [ trusted=yes ] file:///wheezy/ wheezy contrib main I would like to know where unsigned-for packages are before I decide whether to install. Noted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679181: [Pkg-haskell-maintainers] Bug#679181: FTBFS on s390x: ICE
Hi, Am Dienstag, den 26.06.2012, 23:27 +0200 schrieb Luca Falavigna: Source: washngo Version: 2.12.0.1-7 Severity: serious Justification: fails to build from source washngo fails to build from source on s390x, but built in the past: /tmp/ghc7398_0/ghc7398_0.hc:5645:18: warning: left shift count = width of type [enabled by default] /tmp/ghc7398_0/ghc7398_0.hc: In function 's3LEA_ret': /tmp/ghc7398_0/ghc7398_0.hc:5731:11: warning: left shift count = width of type [enabled by default] [23 of 76] Compiling WASH.CGI.MakeTypedName ( WASH/CGI/MakeTypedName.hs, dist-ghc/build/WASH/CGI/MakeTypedName.p_o ) [24 of 76] Compiling WASH.HTML.HTMLMonad ( WASH/HTML/HTMLMonad.hs, dist-ghc/build/WASH/HTML/HTMLMonad.p_o ) [25 of 76] Compiling WASH.HTML.HTMLMonad98 ( WASH/HTML/HTMLMonad98.hs, dist-ghc/build/WASH/HTML/HTMLMonad98.p_o ) gcc: internal compiler error: Killed (program cc1) an internal compiler error in gcc is usually a sign of hardware problems (bad memory), limited memory or maybe a watchdog that kills a long-running build. Could any of these be the case on the build daemons? Also note that it failed at different points in different runs. In any case, such an error in gcc is out of our reach to fix; if anyone, then the porters might be able to do something about this. If you cannot, please request removal by the ftp team. Note that the last successful build was quite a while ago with a different major compiler version which might have used less memory. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#676045: nautilus-image-manipulator: diff for NMU version 1.1-1.1
Hi Salvatore, 2012/6/26 Salvatore Bonaccorso car...@debian.org: tags 676045 + pending thanks Dear maintainer, I've prepared an NMU for nautilus-image-manipulator (versioned as 1.1-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards, Salvatore Thanks a lot for the patch and the NMU. I will test it at home tonight, but looking at the patch it should be alright. +Emilien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677791: gammu: Ship gnapplet
Hi Dne Sat, 16 Jun 2012 21:11:42 +0200 Kurt Roeckx k...@roeckx.be napsal(a): Could you please ship a version of the gnapplet files? It could be shipped at most in contrib, as it is impossible to build it using tools available in Debian. Given that it supports only ancient versions of Symbian, I'm not sure it's worth of it. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Bug#679074: [Pkg-libvirt-maintainers] Bug#679074: Please separate the init scripts for a system-wide libvirtd from the binaries usable for a per-user libvirtd
On Wed, Jun 27, 2012 at 08:07:15AM +0200, Guido Günther wrote: On Tue, Jun 26, 2012 at 10:01:08AM -0700, Josh Triplett wrote: On Tue, Jun 26, 2012 at 06:08:06PM +0200, Guido Günther wrote: On Tue, Jun 26, 2012 at 01:05:36AM -0700, Josh Triplett wrote: Package: libvirt-bin Severity: normal libvirt-bin currently includes both the libvirtd binary (and other binaries) and the init scripts to start a system instance of libvirtd. However, many applications using libvirt only need a per-user instance of libvirtd, not a system instance. For instance, gnome-boxes currently depends on libvirt-bin to get libvirtd, but it doesn't need the system instance. According to gnome-boxes upstream, you can connect to remote instances, but the only thing that is sanely integrated in the UI is creating local VMs in a per-user libvirtd. (Anything else, including the system instance, requires hand-entering a libvirt URI.) So, please split the init scripts for a system-wide libvirtd instance into a separate package from the binaries. Does it really make sense to split out the init script? Wouldn't disabling the daemon also do the trick? The gnome metapackage now depends on gnome-boxes, and gnome-boxes depends on libvirt-bin. So, a default install of GNOME will end up with a running system instance of libvirtd that nothing uses. Users shouldn't have to manually disable unused daemons that only get pulled in by dependencies, especially as part of the default install of something like GNOME. This seems quite similar to the situation with Apache: gnome-user-share depends on apache2.2-bin to get the binaries for the Apache web server, which it can configure and run on a per-user basis to share files. The Apache packages ship the init scripts in a separate package, so that installing gnome does not result in a running system-wide web server. I see. I planed something for 0.9.13 like: So something like: libvirt-daemon libvirt-daemon-qemu libvirt-daemon-xen ... libvirt-client libvirt-doc I'll add: libvirt-daemon-config containing the daemon config from /etc as well as the systemd startup scripts. That seems potentially reasonable. I don't think you necessarily need to bother splitting libvirt-daemon (/usr/sbin/libvirtd) from libvirt-client (virsh and similar), though; a few tiny binaries won't make a difference, as long as they don't run by default. Likewise for the documentation unless it takes up a lot of space. But other than that, those splits make sense. This would allow boxes to depend on libvirt-daemon-qemu only pulling in the one hypervisor. If a package wants to use libvirt for a specific hypervisor, couldn't they just depend on libvirtd and that hypervisor? Why do you need separate libvirt packages for each hypervisor? (Yes, I realize that Fedora did it that way. :) ) I'm not sure we'll get this in place for wheezy though. I don't know if the GNOME team plans to ship 3.4 in wheezy. If they do, which seems likely to me given their upload to unstable rather than experimental, then at least the split of the init scripts needs to happen before wheezy. Would you consider making an upload in the near future that just splits off the configuration files (and /lib/systemd/system if you ship a service file) into a separate package? The larger reorganization could then wait until post-wheezy. (Suggestion: leave libvirt-bin as the package with the binaries, and call the new package libvirt-daemon-config .) Thanks, Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650485: freeimage: FBTFS: Source/FreeImage/PluginPNG.cpp:106:56: error: no matching function for call to 'MAX(DWORD, png_size_t)'
tags 650485 patch
thanks
Hi,
I createad a patch which revise this problem.
Most code was got from upstream.
I attached. Could you check and apply this?
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
fix-libpng15.patch
Description: Binary data
Bug#677246: goobox: diff for NMU version 3.0.1-1.1
Hello Jon, On Tue, Jun 26, 2012 at 10:45:57PM +0100, Jon Dowland wrote: tags 677246 + patch tags 677246 + pending thanks Here's the NMU patch - I uploaded just a moment ago. Thanks - I'll keep an eye on things for the time being. I just got a bunch of e-mails that the build fails on (almost?) any arch. Could you please investigate? Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Bug#664637: openarena-server: AAS shutdown server fatal crashed
On 27/06/12 00:57, Markus Koschany wrote: 1. I think the AAS shutdown-bug is valid for the stable version but not for wheezy anymore. OK, that's good to know! 2. I would like to debug this issue or at least gather a useful debug output from the server [...] start-stop-daemon --start --pidfile $PIDFILE --oknodo \ --background --exec $BINARY --startas $DAEMON \ --make-pidfile --chuid $USER \ -- $DAEMON_OPTS $LOGFILE 21 || return 1 That will log the output of start-stop-daemon to $LOGFILE. Unfortunately, start-stop-daemon doesn't generally output anything - it starts openarena-server, puts it in the background and exits. What is the appropriate way to debug the openarena server? Either start it by hand (not via the init script), or put a wrapper similar to this somewhere (e.g. /usr/local/bin/openarena-server-wrapper): #!/bin/sh OPENARENA_BACKTRACE=1 export OPENARENA_BACKTRACE exec /home/user/openarena-server.log 21 exec /usr/games/openarena-server $@ and modify the init script so it has DAEMON=/usr/local/bin/openarena-server-wrapper (or wherever you put it) instead of its current value. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555168: Unclear license situation for (e)glibc locales provided by you
Hello A S Alam, thanks for your reply, and no, you did not miss anything, the e-mail was kindly quickly directed to you (by bubulle). Did you also do the locale file for pa_IN (e-mail address amanli...@netscape.net)? From your reply I assume GNU General Public License V2 or later is fine for both files? Thanks again! Best regards Helge On Wed, Jun 27, 2012 at 11:24:36AM +0530, A S Alam wrote: I am really sorry if I missed mail earlier. I am fully agree with any changes in locale file, whichever you think is more suitable free software license. As I am not expert for liceneses, while you people can provide better choice to keep software free. All my contribution for open source should be available as free software and though should be part of debian. Please let me know if anything I need to do other than this. Amanpreet Singh Alam ਬà©à©±à¨§à¨µà¨¾à¨° 27 à¨à©à¨¨ 2012 10:58 ਸਵà©à¨°à© ਨà©à©°, Christian PERRIER ਨ੠ਲਿà¨à¨¿à¨: Amanpreet Singh Alam is also using alternate addresses, which I also CCto this mail to get better chances he sees it. To A S Alam, could you address the below question about the Punjabi locale (this is pa_PK as it seems that pa_IN doesn't have the offending sentence included). Quoting Helge Kreutzmann (deb...@helgefjell.de): Hello, you are listed as contact person/author of the following locale: pa_PK This locale comes with a statement % Distribution and use is free, also % for commercial purposes. Thus it does not allow modification; it is unclear, however, if this statement was meant as a license. As discussed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555168 this locale could strictly speaking not be part of Debian which would be a great loss. (Currently it is allowed pending investigation). To properly resolve this, I would like to ask you the following question: Would you be willing to relicense this locale to a proper license, e.g. (L)GPL v2 or higher or another free software license of your choice? If you have any questions regarding this issue, do not hesitate to contact me (via the reply-to address set). Thanks for helping to resolve this! Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ -- A S Alam -- To unsubscribe, send mail to 555168-unsubscr...@bugs.debian.org. -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Bug#675773: Refreshed patch
Due to a security upload, the patch had to be refreshed.
reverted:
--- openjpeg-1.3+dfsg/debian/libopenjpeg2.links
+++ openjpeg-1.3+dfsg.orig/debian/libopenjpeg2.links
@@ -1 +0,0 @@
-/usr/lib/libopenjpeg-2.1.3.0.so /usr/lib/libopenjpeg.so.2
diff -u openjpeg-1.3+dfsg/debian/rules openjpeg-1.3+dfsg/debian/rules
--- openjpeg-1.3+dfsg/debian/rules
+++ openjpeg-1.3+dfsg/debian/rules
@@ -4,6 +4,7 @@
# used as trailer in the generated manpages
UVERSION = $(shell dpkg-parsechangelog | perl -ne 'print $$1\n if (/^Version: (.*?)(?:\.dfsg)?\-.*?$$/)')
+DEB_HOST_MULTIARCH = $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
EXTRA_CFLAGS += -O0
@@ -72,6 +73,19 @@
binary-arch: build install
dh_testdir
dh_testroot
+
+ # install libopenjpeg2 files into multiarch paths
+ mkdir -p debian/libopenjpeg2/usr/lib/$(DEB_HOST_MULTIARCH)
+ cp lib*.so* debian/libopenjpeg2/usr/lib/$(DEB_HOST_MULTIARCH)
+ cd debian/libopenjpeg2/usr/lib/$(DEB_HOST_MULTIARCH) \
+ ln -s libopenjpeg-*.so libopenjpeg.so.2
+
+ # install libopenjpeg-dev files into multiarch paths
+ mkdir -p debian/libopenjpeg-dev/usr/lib/$(DEB_HOST_MULTIARCH)
+ cp lib*.a debian/libopenjpeg-dev/usr/lib/$(DEB_HOST_MULTIARCH)
+ cd debian/libopenjpeg-dev/usr/lib/$(DEB_HOST_MULTIARCH) \
+ ln -s libopenjpeg.so.2 libopenjpeg.so
+
dh_installchangelogs ChangeLog
dh_installdocs
dh_installexamples
reverted:
--- openjpeg-1.3+dfsg/debian/libopenjpeg2.install
+++ openjpeg-1.3+dfsg.orig/debian/libopenjpeg2.install
@@ -1 +0,0 @@
-lib*.so* usr/lib/
reverted:
--- openjpeg-1.3+dfsg/debian/libopenjpeg-dev.links
+++ openjpeg-1.3+dfsg.orig/debian/libopenjpeg-dev.links
@@ -1 +0,0 @@
-/usr/lib/libopenjpeg.so.2 /usr/lib/libopenjpeg.so
diff -u openjpeg-1.3+dfsg/debian/libopenjpeg-dev.install openjpeg-1.3+dfsg/debian/libopenjpeg-dev.install
--- openjpeg-1.3+dfsg/debian/libopenjpeg-dev.install
+++ openjpeg-1.3+dfsg/debian/libopenjpeg-dev.install
@@ -2 +1,0 @@
-lib*.a usr/lib
diff -u openjpeg-1.3+dfsg/debian/control openjpeg-1.3+dfsg/debian/control
--- openjpeg-1.3+dfsg/debian/control
+++ openjpeg-1.3+dfsg/debian/control
@@ -3,7 +3,7 @@
Maintainer: Debian PhotoTools Maintainers pkg-phototools-de...@lists.alioth.debian.org
Uploaders: Robin Cornelius robin.cornel...@gmail.com, Cyril Brulebois k...@debian.org
Homepage: http://www.openjpeg.org
-Build-Depends: debhelper (= 5), dpatch (= 2), libtiff4-dev
+Build-Depends: debhelper (= 9), dpatch (= 2), libtiff4-dev
Standards-Version: 3.7.3
Section: libs
Vcs-Browser: http://git.debian.org/?p=pkg-phototools/openjpeg.git
@@ -12,6 +12,7 @@
Package: libopenjpeg-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends: libopenjpeg2 (= ${binary:Version})
Description: development files for libopenjpeg2, a JPEG 2000 image library
Libopenjpeg2 is a library for handling the JPEG 2000 image compression format.
@@ -23,6 +24,8 @@
Package: libopenjpeg2
Section: libs
Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}
Description: JPEG 2000 image compression/decompression library
Libopenjpeg2 is a library for handling the JPEG 2000 image compression format.
@@ -30,6 +33,7 @@
Package: libopenjpeg2-dbg
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends: libopenjpeg2 (= ${binary:Version})
Description: debug symbols for libopenjpeg2, a JPEG 2000 image library
This package contains the debug symbols to match the runtime component of the
@@ -39,7 +43,8 @@
Package: openjpeg-tools
Section: graphics
Architecture: any
-Depends: ${shlibs:Depends}
+Multi-Arch: foreign
+Depends: libopenjpeg2, ${shlibs:Depends}
Description: command-line tools using the JPEG 2000 library
This package provides with command-line tools allowing for conversions between
several formats:
diff -u openjpeg-1.3+dfsg/debian/changelog openjpeg-1.3+dfsg/debian/changelog
--- openjpeg-1.3+dfsg/debian/changelog
+++ openjpeg-1.3+dfsg/debian/changelog
@@ -1,3 +1,10 @@
+openjpeg (1.3+dfsg-4.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Enable multiarch (closes: #675773).
+
+ -- Michael Gilbert mgilb...@debian.org Sat, 16 Jun 2012 14:32:19 -0400
+
openjpeg (1.3+dfsg-4.1) unstable; urgency=high
* Non-maintainer upload by the Security Team.
Bug#555168: Unclear license situation for (e)glibc locales provided by you
Hello, you are listed as contact person/author of the following locale: ro_RO This locale comes with a statement % Distribution and use is free, also % for commercial purposes. Thus it does not allow modification; it is unclear, however, if this statement was meant as a license. As discussed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555168 this locale could strictly speaking not be part of Debian which would be a great loss. (Currently it is allowed pending investigation). To properly resolve this, I would like to ask you the following question: Would you be willing to relicense this locale to a proper license, e.g. (L)GPL v2 or higher or another free software license of your choice? If you have any questions regarding this issue, do not hesitate to contact me (via the reply-to address set). Thanks for helping to resolve this! Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Bug#555168: Unclear license situation for (e)glibc locales provided by you
Hello, you are listed as contact person/author of the following locale: ru_UA This locale comes with a statement % Distribution and use is free, also % for commercial purposes. Thus it does not allow modification; it is unclear, however, if this statement was meant as a license. As discussed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555168 this locale could strictly speaking not be part of Debian which would be a great loss. (Currently it is allowed pending investigation). To properly resolve this, I would like to ask you the following question: Would you be willing to relicense this locale to a proper license, e.g. (L)GPL v2 or higher or another free software license of your choice? If you have any questions regarding this issue, do not hesitate to contact me (via the reply-to address set). Thanks for helping to resolve this! Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Bug#678532: libreoffice: crash on startup: 'com::sun::star::uno::RuntimeException'
close 678532 forcemerge 678532 678532 thanks On Wed, Jun 27, 2012 at 11:05:16AM +0800, Clayton wrote: On Tue, 26 Jun 2012 11:37:03 +0200 Rene Engelhard r...@debian.org wrote: On Sat, Jun 23, 2012 at 08:24:27PM +0800, Clayton wrote: -l | grep libreoffice so see what LO and LO extensions you have installed in exact versions? See unmangled txt attachment So no extension *at all*. Weird. I don't see *anything* which can cause this, especially as #678532 is fixed. Would you agree on closing this bug and merging it with (the already closed) #678532? We can reopen it if necessary somwehen... Sure, if you are not getting any other reports maybe it was just some kind of bizarre one-off'er. There was *one* other report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677601#24) but it was in some completely unrelated report. I pointed him to #678532 (and yesterday to this bug) but no real answer after that. and since then the submitter doesn't answer anymore. (Cced though). Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679210: kmix: KMix tray pop up shows more than one mixer
Package: kmix Version: 4:4.8.4-1 Severity: important Dear Maintainer, After upgrading some packages KMix now has two volume sliders in popup shown when clicking the tray icon. I tried backing up the kmix config files in ~/.kde/share/config and deleting the old ones with no success. Please see the following link for a screenshot: http://imgur.com/OU9jy Kitty -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (400, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 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 kmix depends on: ii kde-runtime 4:4.8.4-1 ii libasound2 1.0.25-3 ii libc62.13-33 ii libkdecore5 4:4.8.3-2 ii libkdeui54:4.8.3-2 ii libphonon4 4:4.6.0.0-2 ii libplasma3 4:4.8.3-2 ii libpulse-mainloop-glib0 2.0-3 ii libpulse02.0-3 ii libqt4-dbus 4:4.8.2-1 ii libqt4-xml 4:4.8.2-1 ii libqtcore4 4:4.8.2-1 ii libqtgui44:4.8.2-1 ii libsolid44:4.8.3-2 ii libstdc++6 4.7.0-8 ii phonon 4:4.6.0.0-2 kmix recommends no packages. kmix 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#679107: RFS: mysql-cluster-7.2
Hi Bart, Yes, it's bug 560244 ITP: mysql-cluster -- MySQL database server with cluster support Regard, Steven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676045: nautilus-image-manipulator: diff for NMU version 1.1-1.1
Hi Emilien On Wed, Jun 27, 2012 at 09:38:02AM +0200, Emilien Klein wrote: Hi Salvatore, 2012/6/26 Salvatore Bonaccorso car...@debian.org: tags 676045 + pending thanks Dear maintainer, I've prepared an NMU for nautilus-image-manipulator (versioned as 1.1-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards, Salvatore Thanks a lot for the patch and the NMU. I will test it at home tonight, but looking at the patch it should be alright. I can cancel the NMU if you would like to upload yourself, this would be perfect! It's still time do to so[1]. Btw, I had some warnings on build: WARNING: syntax errors in nautilus_image_manipulator/ProfileSettings.py: encoding declaration in Unicode string (ProfileSettings.py, line 0) WARNING: syntax errors in bin/nautilus-image-manipulator: encoding declaration in Unicode string (nautilus-image-manipulator, line 0) WARNING: syntax errors in nautilus_image_manipulator/nautilus_image_manipulatorconfig.py: encoding declaration in Unicode string (nautilus_image_manipulatorconfig.py, line 0) WARNING: syntax errors in docs/conf.py: encoding declaration in Unicode string (conf.py, line 0) WARNING: syntax errors in nautilus_image_manipulator/helpers.py: encoding declaration in Unicode string (helpers.py, line 0) /usr/lib/python2.6/dist-packages/DistUtilsExtra/auto.py:336: DeprecationWarning: the sha module is deprecated; use the hashlib module instead mod = __import__(module) WARNING: syntax errors in nautilus_image_manipulator/upload/z1fichiercom.py: encoding declaration in Unicode string (z1fichiercom.py, line 0) WARNING: syntax errors in nautilus_image_manipulator/ImageManipulations.py: encoding declaration in Unicode string (ImageManipulations.py, line 0) WARNING: syntax errors in nautilus_image_manipulator/NautilusImageManipulatorDialog.py: encoding declaration in Unicode string (NautilusImageManipulatorDialog.py, line 0) [1]: http://ftp-master.debian.org/deferred.html Regards, and thanks for your reply Salvatore signature.asc Description: Digital signature
Bug#678532: libreoffice: crash on startup: 'com::sun::star::uno::RuntimeException'
forcemerge 619263 678532 thanks On Wed, Jun 27, 2012 at 11:05:16AM +0800, Clayton wrote: On Tue, 26 Jun 2012 11:37:03 +0200 Rene Engelhard r...@debian.org wrote: On Sat, Jun 23, 2012 at 08:24:27PM +0800, Clayton wrote: -l | grep libreoffice so see what LO and LO extensions you have installed in exact versions? See unmangled txt attachment So no extension *at all*. Weird. I don't see *anything* which can cause this, especially as #678532 #619263 obviously... Would you agree on closing this bug and merging it with (the already closed) #678532? We can reopen it if necessary somwehen... ^^^ #619263 obviously... Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679210: kmix: KMix tray pop up shows more than one mixer
Just a follow up, I found this bug is only triggers when something other than the Event Sounds Slider is listed first in Playback Streams. So to reproduce: 1. Play an audio source with whatever program you wish (leave it playing). 2. Close KMix 3. Reopen KMix 4. Click the tray icon and there should be two mixers displayed in the popup Kitty On 27 June 2012 18:06, Kitty kittyin...@gmail.com wrote: Package: kmix Version: 4:4.8.4-1 Severity: important Dear Maintainer, After upgrading some packages KMix now has two volume sliders in popup shown when clicking the tray icon. I tried backing up the kmix config files in ~/.kde/share/config and deleting the old ones with no success. Please see the following link for a screenshot: http://imgur.com/OU9jy Kitty -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (400, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 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 kmix depends on: ii kde-runtime 4:4.8.4-1 ii libasound2 1.0.25-3 ii libc6 2.13-33 ii libkdecore5 4:4.8.3-2 ii libkdeui5 4:4.8.3-2 ii libphonon4 4:4.6.0.0-2 ii libplasma3 4:4.8.3-2 ii libpulse-mainloop-glib0 2.0-3 ii libpulse0 2.0-3 ii libqt4-dbus 4:4.8.2-1 ii libqt4-xml 4:4.8.2-1 ii libqtcore4 4:4.8.2-1 ii libqtgui4 4:4.8.2-1 ii libsolid4 4:4.8.3-2 ii libstdc++6 4.7.0-8 ii phonon 4:4.6.0.0-2 kmix recommends no packages. kmix 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#679211: cntlm does not properly handle non-HTTP/1.1 keep-alive
Package: cntlm Version: 0.92.3-1 Severity: important Many proxies respond with 1.1 and add keep-alive, even when client is 0.9/1.0. Cntlm 0.92.3-1 honours this, causing clients like Ubuntu's package-data-downloader, which downloads proprietary packages triggered by flashplugin-installer and ttf-mscorefonts-installer, to hang. This was fixed upstream in revision 306: http://www.awk.cz/svn/revision.php?repname=Cntlmrev=306 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664681: transition: KDE's 4.8 release of platform, applications and workspace
Hi, Alle giovedì 21 giugno 2012, Adam D. Barratt ha scritto: On Wed, 2012-06-20 at 19:48 +0200, Pino Toscano wrote: Alle mercoledì 20 giugno 2012, Adam D. Barratt ha scritto: On 20.06.2012 11:22, Pino Toscano wrote: Alle giovedì 14 giugno 2012, Adam D. Barratt ha scritto: Given that kde-workspace is 9/10, would it be possible to let it migrate tonight, hinting temporarly kshutdown and plasma-widget-smooth-tasks out of testing? The former would migrate again on its own in 10 days, the latter... dunno, it would not be a grave loss OTOH. As discussed on IRC, after removing kshutdown and p-w-s-t everything else looks okay from a kde-workspace perspective. The tidy up of old libraries in testing ends up incomplete however, because kdenetwork is only 3/10 and the testing version depends on libkworkspace4 - we can either age kdenetwork, or just live with the old library hanging around for a few more days; either works for me. :-) If the old libraries are not a problem for a week, I'd say if you could temporarly keep them and wait for the kdenetwork migration (so we're double sure it is safe enough). No problem. kde-workspace and the remaining binNMUs migrated as planned in tonight's britney run. kdenetwork migrated tonight, so I think the old binaries could be removed and this transition (i.e. the kde-workspace one) declared done. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#679212: ITP: python-whois -- Python module/library for retrieving WHOIS information of domains
Package: wnpp Severity: wishlist Owner: Francois Marier franc...@debian.org * Package name: python-whois Version : 0.6.3 Upstream Author : DDarko dda...@ddarko.org * URL : https://code.google.com/p/python-whois/ * License : MIT Programming Lang: Python Description : Python module/library for retrieving WHOIS information of domains This Python wrapper for the whois command has a simple interface to access parsed WHOIS data for a given domain. . It is able to extract data for many of the popular TLDs (com, org, net, biz, info, pl, jp, uk, nz, ...) and queries WHOIS servers directly instead of going through an intermediate web service. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516785: Bug #516785: linux-image-2.6.26-1-sparc64-smp: [sparc] SunFire480R cassini network driver kernel panic
On Mon, Jun 04, 2012 at 04:35:57PM +0200, Hermann Lauer wrote: On Sat, Jun 02, 2012 at 03:57:54AM +0800, Aron Xu wrote: I have remote ssh access (root) to that running SunFire 408R, what can I do to help you? ... PS: I've disabled the rename function of udev and set hwaddress in /etc/network/interfaces directly to work around the always changing mac address. How to disable the renaming ? Will try to set the hwaddr during the next test. ... Wondering now if having only one cpu board with 2 cpus may be the problem. No, a second machine of the same type is available now for testing - and also crashing after loading of the cassini driver. Here lspci and cpuinfo: :00:06.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 07) 0002:00:01.0 Bridge: Oracle Corporation RIO EBUS (rev 01) 0002:00:01.3 USB Controller: Oracle Corporation RIO USB (rev 01) 0002:00:02.0 Ethernet controller: Oracle Corporation Cassini 10/100/1000 (rev 11) 0003:00:01.0 Ethernet controller: Oracle Corporation Cassini 10/100/1000 (rev 11) 0003:00:02.0 SCSI storage controller: QLogic Corp. QLA2200 64-bit Fibre Channel Adapter (rev 05) cpu : TI UltraSparc III+ (Cheetah+) fpu : UltraSparc III+ integrated FPU pmu : ultra3+ prom: OBP 4.17.1 2005/04/11 14:27 type: sun4u ncpus probed: 4 ncpus active: 4 D$ parity tl1 : 0 I$ parity tl1 : 0 cpucaps : flush,stbar,swap,muldiv,v9,ultra3,mul32,div32,v8plus,vis,vis2 Cpu0ClkTck : 35a4e900 Cpu1ClkTck : 35a4e900 Cpu2ClkTck : 35a4e900 Cpu3ClkTck : 35a4e900 MMU Type: Cheetah+ State: CPU0: online CPU1: online CPU2: online CPU3: online This machine has 24G RAM, 16 on one board and 8 on the other. The first machine has one board with 16G. So it may be a memory issue, as Aron has only 14G. Other maybe the OBP version - here is the latest installed on all machines. Just to rule out a firmware issue: $ md5sum /lib/firmware/sun/cassini.bin fd11e09e8e61694353f12b3de376292a Any further ideas to debug deeper ? Thanks, Hermann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679213: Installation fails without apache2
Package: mantis Version: 1.2.11-1 I attempted to install mantis without apache2: Errors were encountered while processing: mantis E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up mantis (1.2.11-1) ... locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ln: failed to create symbolic link `/etc/apache2/conf.d/mantis': No such file or directory dpkg: error processing mantis (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: mantis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664681: transition: KDE's 4.8 release of platform, applications and workspace
Hi, here it is a recap of the status of the various bits currently ongoing so far. 1) marble transition sourceful uploads for: marble binNMUs for: calligra, digikam, kdeplasma-addons - 5/10 old, but could be ready to migrate 2) okteta transition sourceful uploads for: kdesdk binNMUs for: kdevelop - 5/10 old, but could be ready to migrate 3) analitza transition sourceful uploads for: analitza, kalgebra, cantor - 4/10 old, but could be ready to migrate 4) split of kdeaccessibility the monolithic kdeaccessibility source has been replaced in KDE 4.8 with the following sources: jovie kaccessibile kmag kmousetool kmouth the only binaries lost is the monolithic kdeaccessibility-dbg (as expected); this would need to hint the old source away from testing - 5/10 old, but could be ready to migrate 5) split of kdeutils the monolithic kdeutils source has been replaced in KDE 4.8 with the following sources: ark filelight kcalc kcharselect kdf kfloppy kgpg kremotecontrol ktimer kwallet superkaramba printer-applet sweeper the only binaries lost is the monolithic kdeutils-dbg (as expected); this would need to hint the old source away from testing - this is not ready to migrate yet Would it be possible to migrate 1+2+3+4, or do you prefer to wait for them to age normally? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#665932: strace from vanilla kernel 3.2.17
See strace from vanilla 3.2.17 below, hope that helps.
Greetings
Hermann
# strace lshw
execve(/usr/bin/lshw, [lshw], [/* 16 vars */]) = 0
brk(0) = 0xa6000
uname({sys=Linux, node=tantalus, ...}) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7fcc000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=28853, ...}) = 0
mmap(NULL, 28853, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7fc4000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/usr/lib/libstdc++.so.6, O_RDONLY) = 3
read(3, \177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\5(\0\0\0\0004...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1094428, ...}) = 0
mmap(NULL, 1184336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7e78000
mprotect(0xf7f7e000, 57344, PROT_NONE) = 0
mmap(0xf7f8c000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x104000) = 0xf7f8c000
mmap(0xf7f94000, 21072, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7f94000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libgcc_s.so.1, O_RDONLY)= 3
read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0!\340\0\0\0004..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=68880, ...}) = 0
mmap(NULL, 133496, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7e54000
mprotect(0xf7e66000, 57344, PROT_NONE) = 0
mmap(0xf7e74000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xf7e74000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/ultra3/libc.so.6, O_RDONLY) = 3
read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\2\7\340\0\0\0004..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1501772, ...}) = 0
mmap(NULL, 1572328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7cd4000
mprotect(0xf7e3c000, 65536, PROT_NONE) = 0
mmap(0xf7e4c000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x168000) = 0xf7e4c000
mmap(0xf7e52000, 7656, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7e52000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/ultra3/libm.so.6, O_RDONLY) = 3
read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\0\335`\0\0\0004..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=867768, ...}) = 0
mmap(NULL, 931744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7bf
mprotect(0xf7cc, 57344, PROT_NONE) = 0
mmap(0xf7cce000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xce000) = 0xf7cce000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7fc2000
mprotect(0xf7cce000, 8192, PROT_READ) = 0
mprotect(0xf7e4c000, 8192, PROT_READ) = 0
mprotect(0xf7f8c000, 16384, PROT_READ) = 0
mprotect(0xf7fce000, 8192, PROT_READ) = 0
munmap(0xf7fc4000, 28853) = 0
brk(0) = 0xa6000
brk(0xc8000)= 0xc8000
access(/sys/class/., F_OK)= 0
geteuid32() = 0
uname({sys=Linux, node=tantalus, ...}) = 0
ioctl(2, TCSETAF or SNDCTL_TMR_SELECT, {B38400 opost isig icanon echo ...}) = 0
) = 1
) = 5
open(/dev/mem, O_RDONLY) = 3
open(/proc/efi/systab, O_RDONLY) = -1 ENOENT (No such file or directory)
mmap(NULL, 32, PROT_READ, MAP_SHARED, 3, 0xe) = 0xf7fc8000
Message from syslogd@tantalus at Wed Jun 27 11:49:41 2012 ...
tantalus kernel: Press Stop-A (L1-A) to return to the boot prom
Message from syslogd@tantalus at Wed Jun 27 11:49:41 2012 ...
tantalus kernel: Kernel panic - not syncing: Irrecoverable deferred error trap.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679059: gdm3: please reduce metacity dependency
Le mardi 26 juin 2012 à 12:33 -0400, Michael Gilbert a écrit : I see. What about demoting metacity's zenity depends to a recommends? That would have a similar effect; reducing a lot of the bigger dependencies like webkit being pulled in. If that seems reasonable, I'll reassign to metacity. Currently metacity really needs zenity to show error messages. However it looks like this code (in src/core/util.c) could be easily replaced by C code doing the same thing. If you can patch it out, we’ll happily remove the dependency. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679214: grub-pc: Grub2 fails to boot from a degraded mdraid RAID6
Package: grub-pc
Version: 1.99-22.1
Severity: important
Tags: d-i
My setup:
Wheezy businesscard install daily build (2012-06-25)
MBR on disks
One partition per disk
6 disk mdraid RAID6
/ and /boot on LVM
/ and /boot as ext4 (in fact on the same partition)
The installer installs everything fine, but grub fails to boot. Grub
can see the ext4 partitions on the lvm just fine, but with various
levels of failure cannot read the contents of them (they are either
not read at all or then they are corrupted in various ways).
After booting into recovery mode and letting the raid array build
itself the system boots up just fine after the array has finished
syncing. This is an acceptable workaround for a home system, but not
really acceptable for production environments (rebooting with a
degraded array can cause major downtime while the array syncs in a
single user mode recovery environment; alternatively someone has to
rush on-site with a newer grub boot medium to boot the system
normally).
I believe this upstream bug to be the bug in question:
https://savannah.gnu.org/bugs/?35843
Upstream claims it fixed in a newer version.
I have cross-verified this myself by having had success with Fedora 17,
Arch and Gentoo and failing with both Debian (6, 7) and Ubuntu (10.04,
12.04). The difference being that Debian and Ubuntu are on grub-pc 1.9x
while both Arch and Fedora 17 are on grub-pc 2.0+ and the Gentoo in
question is on latest (circa 2012-06-25) bzr from the GNU savannah.
A proposed solution would be to either move forward to match upstream
or to go and cherry-pick and backport the relevant change in question.
I unfortunately do not have the expertise to help you with this
process.
This bug report is being sent from an unbootable test setup in Virtualbox.
I have tagged this report relevant to the Debian installer due to the
install process leaving an unbootable system without extra steps.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/sr0 /cdrom iso9660 ro,relatime 0 0
/dev/raid6/root / ext4 rw,relatime,user_xattr,barrier=1,stripe=512,data=ordered
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-VBOX_HARDDISK_VBa2b88522-1437d827
(hd1) /dev/disk/by-id/ata-VBOX_HARDDISK_VBc9570229-0652b7c9
(hd2) /dev/disk/by-id/ata-VBOX_HARDDISK_VB3cbd04d6-03d73061
(hd3) /dev/disk/by-id/ata-VBOX_HARDDISK_VB773558b3-c023f499
(hd4) /dev/disk/by-id/ata-VBOX_HARDDISK_VBc69b081d-32b67df7
(hd5) /dev/disk/by-id/ata-VBOX_HARDDISK_VB61f4bc52-a54ccf46
*** 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
load_env
fi
set default=0
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 {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod raid
insmod raid6rec
insmod mdraid1x
insmod lvm
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(raid6-root)'
search --no-floppy --fs-uuid --set=root aac00a9a-fce6-4260-a61e-5ded48e5dcb9
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
insmod raid
insmod raid6rec
insmod mdraid1x
insmod lvm
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(raid6-root)'
search --no-floppy --fs-uuid --set=root aac00a9a-fce6-4260-a61e-5ded48e5dcb9
set locale_dir=($root)/boot/grub/locale
set lang=C
insmod gettext
fi
terminal_output gfxterm
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod raid
insmod raid6rec
insmod mdraid1x
insmod lvm
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(raid6-root)'
search --no-floppy --fs-uuid --set=root aac00a9a-fce6-4260-a61e-5ded48e5dcb9
insmod png
if background_image /usr/share/images/desktop-base/spacefun-grub.png; then
set color_normal=light-gray/black
set color_highlight=white/black
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 ###
menuentry 'Debian GNU/Linux, with Linux 3.2.0-2-amd64' --class debian --class
gnu-linux --class gnu --class os {
insmod gzio
insmod raid
insmod raid6rec
insmod mdraid1x
insmod lvm
insmod
Bug#665987: [Pkg-acpi-devel] Bug#665987: acpi-supoort: Please make consolekit optional
On Tue, Jun 26, 2012 at 05:52:45PM +0200, Guillem Jover wrote: Also consolekit upstream is not even maintained anymore and it's considered deprecated (which seems like a trend with all that plumbing *kit stuff)... I didn't even know that to be honest. Well for the cases I listed above, ck-list-session will just not return anything, so calling it or not calling it has the same effect. Not calling it if it's not available has the advantage of not requiring it at run-time and making it an optional dependency, like a Recommends. Sorry, I don't really understand what you're refering to here. If you make consolekit optional the way I see it in your patch, acpi-support will be activated even if a different power management is running in the gui. We've had our share of problems with that before this logic was implemented. To prevent the standard user from falling into that trap consolekit has to be installed per default together with acpi-support, which is exactly what you want to get rid of. If using the old approach with pinky this would only hold for people using lightdm who I gather are more experienced user to begin with. Exactly, and that's precisely why consolekit is in principle optional, because the code will fallback to something else, but that requires consolekit to not be required. When I referred to “when the system is not running an X session” I meant when the system does not have any X server running, and it's just running on the system console. In addition Recommends are installed by default, so that should cover the majority of the users, but allow others to choose not to install those if they so desire. This is a good point, but I still think having a fallback for an active X would even be better. Unfortunately there is no way to force installation of consolekit if and only if X is installed, too. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664681: transition: KDE's 4.8 release of platform, applications and workspace
Hi, On 27.06.2012 09:22, Pino Toscano wrote: Alle giovedì 21 giugno 2012, Adam D. Barratt ha scritto: On Wed, 2012-06-20 at 19:48 +0200, Pino Toscano wrote: If the old libraries are not a problem for a week, I'd say if you could temporarly keep them and wait for the kdenetwork migration (so we're double sure it is safe enough). No problem. kde-workspace and the remaining binNMUs migrated as planned in tonight's britney run. kdenetwork migrated tonight, so I think the old binaries could be removed and this transition (i.e. the kde-workspace one) declared done. The old binaries are indeed gone automagically after kdenetwork's migration last night. Do we want to keep the bug open to track http://release.debian.org/transitions/html/kde4.8bis.html and anything else that might still be outstanding for 4.8? Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679094: linux-image-3.4-trunk-amd64: 3.2, 3.3 and 3.4 debian kernels lack latencytop support
Am Mittwoch, 27. Juni 2012 schrieb Ben Hutchings: On Tue, 2012-06-26 at 12:46 +0200, Martin Steigerwald wrote: [...] The current Debian kernels all lack latencytop support: [...] Please consider activating this support again. What do you mean, 'again'? I thought this was once working out of the box, but maybe that was at a time where I compiled my own kernels and had it enabled. Otherwise someone who wants to use latencytop needs to recompile the kernel which greatly reduces the usefulness of the latencytop package. This costs 1680 or 3360 bytes of non-paged memory for every thread in the system (depending on word size), even if the feature is never actually used. On my laptop, for example, this would be about a megabyte. I really don't think this is a good idea. I found out that it will need the framepointer stuff which makes the kernel slightly larger and slower only after writing the bug report. While I do not care that much about the megabyte given current memory sizes, I am concerned about the slightly slower. And then its declared as kernel hacking feature in the configuration anyway. And for older / embedded machines 1 MiB might be much. So I can understand your reasoning. Feel free to close as won't fix or dependent / waiting for upstream fix if thats possible. It is probably possible to change the way the latency records are kept so that this memory is allocated only when needed, but I'm unlikely to find the time to do that. Care to elaborate on that one a bit. I am willing to open a upstream bug report about that and include your idea and a reference to this debian bug report. Thanks, -- Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677107: gdm3: Please ship systemd service file
Le mercredi 27 juin 2012 à 01:04 +0200, Paul Menzel a écrit : Please put the attached file (adapted from [1]) with the following content [Unit] Description=GNOME Display Manager After=systemd-user-sessions.service [Service] ExecStart=/usr/sbin/gdm3 --nodaemon Type=dbus BusName=org.gnome.DisplayManager [Install] WantedBy=graphical.target under `/lib/systemd/system/gdm3.service`. It works for me. The discussion took place on systemd-devel [3][4]. Obviously you haven’t tested it much. The systemd service file must mimic what the init script does. There are reasons why the init script is so large, and it’s not just because of systemv verbosity. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679160: gdm3: /usr/share/gdm/applications leftover on upgrade
Le mercredi 27 juin 2012 à 01:31 +0200, Christoph Anton Mitterer a écrit : Hi. On Wed, 2012-06-27 at 00:55 +0200, Michael Biebl wrote: On upgrade, the directory /usr/share/gdm/applications was left over stale as it contained some other config file (mimeinfo.cache) which hasn't been Are you sure this file was created by the gdm3 package? Unfortunately not, it's not managed by dpkg. It was probably created by the system administrator. This mimeinfo.cache file is not created by the gdm3 package (or any other package). Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679215: CVE-2012-3363: Local file disclosure via XXE injection
Package: zendframework Severity: grave Tags: security Please see http://framework.zend.com/security/advisory/ZF2012-01 https://www.sec-consult.com/files/20120626-0_zend_framework_xxe_injection.txt Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679216: cntlm: please package new upstream 0.93 beta
Package: cntlm Version: 0.92.3-1 Severity: wishlist New upstream releases 0.93 beta 3 and 0.93 beta 5 are available: http://ftp.awk.cz/pub/ 0.93 beta 3 includes the following important bugfix: Rev 306, 2012-04-07 02:54:51 * Properly handle non-HTTP/1.1 keep-alive (many proxies respond with 1.1 even when client is 1.0) and they happily add keep-alive connection, which we held open and 1.0 clients hanged. Now, HTTP version is detected based purely on the client's original request and explicit keep-alive/close headers are added to the replies based on its version. When close header is present, Cntlm actually closes the connection to satisfy truly 0.9/1.0 clients (even though parent proxy returned keep-alive) and now both 1.1 and 1.0 clients get what they expect. May need more testing, but seems to work OK in both the DIRECT and PROXY handlers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679073: texlive-base: failed during dist-upgrade (/usr/bin/fmtutil: Segmentation fault)
The execution of strace pdftex -ini -jobname=etex -progname=etex -translate-file=cp227.tcx '*etex.ini' results in 50% cases in segmentation fault. I start thinking it might be memory problem. Is there a reliable test I can run? Here is the bt: Core was generated by `pdftex -ini -jobname=etex -progname=etex -translate-file=cp227.tcx *etex.ini'. Program terminated with signal 11, Segmentation fault. #0 0xe594314c in ?? () (gdb) bt #0 0xe594314c in ?? () #1 0x40158290 in PopplerCache::PopplerCache(int) () from /usr/lib/libpoppler.so.5 #2 0x40124530 in ?? () from /usr/lib/libpoppler.so.5 Cannot access memory at address 0x0 #3 0x40124530 in ?? () from /usr/lib/libpoppler.so.5 Cannot access memory at address 0x0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) best regards Lukasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Wed, Jun 27, 2012 at 08:59:57AM +0200, Nicos Gollan wrote: Effectively, the standardisation process and related resolution of licensing issues for the new codec are one of the things holding back a proper 1.2.4 release. Whatever the real reasons for mumble upstream dragging its feet on making this easier for people to test may be, these aren't it. If they were real problems then Debian and its derivatives would not be shipping this, Fedora and Gentoo would not be shipping this, Firefox would not be shipping with support for this, gstreamer would not be shipping with support for this, mangler would not be shipping with support for this ... etc. etc. etc. And they especially would not be doing so with the encouragement and support of the developers from the CODEC working group and the holders of all relevant licences, who have been actively guiding and driving this rollout ... People with a much bigger stake in this than you have would be crying foul if there were even the smallest suspicion of such problems being real. Including myself. I'm even pretty sure you were around when this was discussed on IRC, so ... So for reliable support, the safer bet would be to wait for 1.2.4; until then, it's under development and may break in weird ways. Which is not to say this part might not be true. But only because of bugs that purely exist in mumble alone, not any other cause. I personally don't see how making it artificially hard for people to test it is going to make it stop breaking in weird ways any sooner ... but ymmv. Maybe people should look at the Mangler package and ventrilo if they really just want something that actually works today and they aren't concerned about the compromises they need to make to get that - which seems to be the ongoing theme here. They managed to get that working with opus in just a couple of days, and with none of the ED grade drama that we seem to be seeing here. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679217: libevent: memleaks - scoped cleanup on bailing out
Source: libevent
Version: 2.0.19-stable-3
Severity: normal
Tags: upstream patch
Hi Anibal,
Attached are two trivial tweaks [1] to free memory allocated
inside routines. Explanations are in the patch headers proper.
While they look trivial, I can quite judge the impact, since I
don't have a clear idea how often are these called and fail to
reclaim the allocated memory on bail-out.
[1] I did dpkg-source --commit for you, please poke upstream,
and add to series if you find them appropriate, also adjusting
patch headers with the info further returned by BTS.
Description: free handle is request_new fails
Trivial clean up on bailing out
.
libevent (2.0.19-stable-3) unstable; urgency=low
.
* [ceb52d98] DH compatibility level is 9
* [7792ab18] Support multiarch (Closes: #675320)
Author: Anibal Monsalve Salazar ani...@debian.org
Bug-Debian: http://bugs.debian.org/675320
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- libevent-2.0.19-stable.orig/evdns.c
+++ libevent-2.0.19-stable/evdns.c
@@ -2291,7 +2291,10 @@ nameserver_send_probe(struct nameserver
handle = mm_calloc(1, sizeof(*handle));
if (!handle) return;
req = request_new(ns-base, handle, TYPE_A, google.com, DNS_QUERY_NO_SEARCH, nameserver_probe_callback, ns);
- if (!req) return;
+ if (!req) {
+ mm_free(handle);
+ return;
+ }
ns-probe_request = handle;
/* we force this into the inflight queue no matter what */
request_trans_id_set(req, transaction_id_pick(ns-base));
Description: free req when bailing out and returning NULL
I can see the comment of uncertaincy /* XXX Should we dealloc req? If yes, how? */
but I think req should be nevertheless freed by mm_free() on bailing out and
returning NULL from search_request_new(), as req was allocated by mm_malloc in
request_new(). This is the trivial scoped cleaning.
Further, the callers of search_request_new() are supposed to check its return
value against NULL. Not done yet, but should trivial to add.
.
libevent (2.0.19-stable-3) unstable; urgency=low
.
* [ceb52d98] DH compatibility level is 9
* [7792ab18] Support multiarch (Closes: #675320)
Author: Anibal Monsalve Salazar ani...@debian.org
Bug-Debian: http://bugs.debian.org/675320
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- libevent-2.0.19-stable.orig/evdns.c
+++ libevent-2.0.19-stable/evdns.c
@@ -3158,6 +3158,8 @@ search_request_new(struct evdns_base *ba
handle-search_origname = mm_strdup(name);
if (handle-search_origname == NULL) {
/* XXX Should we dealloc req? If yes, how? */
+ if (req)
+mm_free(req);
return NULL;
}
handle-search_state = base-global_search_state;
Bug#679218: libpam-systemd: pam_systemd pam module shouldn't be added in common-session
Package: libpam-systemd Version: 44-2 Severity: important Hi, pam_systemd is currently added in common-session this is breaking a lot of stuff (sudo, pkexec,...) as they are getting killed by systemd. For what I understand, pam_systemd should only be added for login-like services (login, GDM,...) to track only initial connection to the machine. There is currently a bug opened against libpam-runtime (#677288) to add a common-login file for that purpose. I guess nothing can really be done before this is implemented. Cheers Laurent Bigonville -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpam-systemd depends on: ii libc6 2.13-33 ii libcap2 1:2.22-1.1 ii libdbus-1-3 1.6.0-1 ii libpam0g1.1.3-7.1 ii libselinux1 2.1.9-5 ii libsystemd-daemon0 44-2 ii systemd 44-2 libpam-systemd recommends no packages. libpam-systemd 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#678992: RFS: grive/0.1.1+20120619git27g55c0f4e-1 [ITP #675310]
Hi, The upstream authors doesn't have this version available as tarball for download, I had to create the tarball myself. The main differences between the 0.1.1 stable version and this git commit is only about the construct system: I have made some suggestions and they included it in the repository after the 0.1.1 release. In this case you could just add the patch in your package. And in the next upload you will delete it. Also this patch may include only necessary changes, but not full diff after stable release. I often use such method in my packages. Regards, Boris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679123: tcc: Incorrect shift result type with 64-bit ABI
Note: this bug has been found when testing GNU MPFR. It is silently built incorrectly with tcc due to the use of sizeof(), which is equivalent to an unsigned long, in shift-count sub-expressions. This can be seen with make check, where many MPFR tests fail. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/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#679219: ftp.app: New upstream version
Package: ftp.app Severity: wishlist 0.3 version available -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39.2-custom (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677880: iwlwifi: flakey and slow connection, high invalid misc count
Source: linux-2.6 Followup-For: Bug #677880 Dear Maintainer, *** Please consider answering these questions, where appropriate *** Hi there. First, thanks for your time. It seems to be fixed in Linux version 3.4-trunk-amd64 (Debian 3.4.1-1~experimental.1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Wed Jun 6 10:34:53 CEST 2012 I have tested wifi at home and at work without options. At home (WEP): The invalid misc count goes up very slowly, it has connected without any problem and it has been 1h without disconnecting. Besides speed is always 54 Mb/s and it does not change. At work (no encryption): It does not work without options cfg80211 ieee80211_regdom=EU INFO: Now I'm at home. I think I've turned on encryption at home after I started having problems with wifi. Let me disable encryption and try again. Maybe this is the cause ... :-( Thank you !!! *** End of the template - remove these lines *** -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (700, 'stable-updates'), (700, 'stable'), (400, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.4-trunk-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/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679220: Conflicting with therion-doc, please add suitable Breaks/Conflicts
Package: therion-viewer Version: 5.3.9-3 Severity: serious Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: therion-viewer 1 upgraded, 0 newly installed, 0 to remove and 132 not upgraded. 544 not fully installed or removed. Need to get 0 B/537 kB of archives. After this operation, 2048 B of additional disk space will be used. Retrieving bug reports... Done Parsing Found/Fixed information... Done (Reading database ... 392581 files and directories currently installed.) Preparing to replace therion-viewer 5.3.9-1+b1 (using .../therion-viewer_5.3.9-3_i386.deb) ... Unpacking replacement therion-viewer ... dpkg: error processing /var/cache/apt/archives/therion-viewer_5.3.9-3_i386.deb (--unpack): trying to overwrite '/usr/share/doc-base/therion', which is also in package therion-doc 5.3.9-3 Processing triggers for menu ... Processing triggers for desktop-file-utils ... Errors were encountered while processing: /var/cache/apt/archives/therion-viewer_5.3.9-3_i386.deb -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages therion-viewer depends on: ii libc6 2.13-33 ii libfreetype6 2.4.9-1 ii libgcc1 1:4.7.1-2 iu libgl1-mesa-glx [libgl1] 8.0.3-1 iu libglu1-mesa [libglu1]8.0.3-1 ii libjpeg8 8d-1 ii libpng12-01.2.49-1 ii libstdc++64.7.1-2 ii libvtk5.8 5.8.0-13 ii libwxbase2.8-02.8.12.1-11 ii libwxgtk2.8-0 2.8.12.1-11 iu libx11-6 2:1.5.0-1 iu therion 5.3.9-3 ii zlib1g1:1.2.7.dfsg-13 therion-viewer recommends no packages. therion-viewer 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#679180: FTBFS on arm*: SHLIB_LIBADD: No such file or directory
On Tue, Jun 26, 2012 at 11:27:09PM +0200, Luca Falavigna wrote: Source: raschsampler Version: 0.8-5-1 Severity: serious Justification: fails to build from source raschsampler fails to build from source on arm*, but built in the past: fi * installing *source* package 'RaschSampler' ... ** package 'RaschSampler' successfully unpacked and MD5 sums checked ** libs make[1]: Entering directory `/build/buildd-raschsampler_0.8-5-1-armhf-YQ24R3/raschsampler-0.8-5/src' gfortran -fpic -O3 -pipe -g -c RaschSampler.f90 -o RaschSampler.o gfortran -shared -o RaschSamplerSHLIB_EXT RaschSampler.o SHLIB_LIBADD -L/usr/lib/R/lib -lR gfortran: error: SHLIB_LIBADD: No such file or directory That is just plain bizarre. The entire build is performed by running the command R CMD INSTALL ..., which just calls R with various arguments. If this is happening to this package, it should be happening to lots of other R packages as well which build libraries. Are you seeing this problems with other R packages or is it unique to this one? Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679221: proftpd: Support for inetutils-inetd.
Package: src:proftpd-dfsg
Version: 1.3.4a-2
Severity: normal
Please consider the following modification to the init script
in order that also the superserver `inetutils-inetd' be supported.
Best regards,
Mats Erik Andersson, DM
From 1b0b8026e6f17c3ae70bc7d2fd5ce5748129f46f Mon Sep 17 00:00:00 2001
From: Mats Erik Andersson deb...@gisladisker.se
Date: Wed, 27 Jun 2012 11:16:44 +0200
Subject: [PATCH] Support inetutils-inetd.
---
debian/proftpd-basic.init | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/debian/proftpd-basic.init b/debian/proftpd-basic.init
index ab19b20..18851ee 100644
--- a/debian/proftpd-basic.init
+++ b/debian/proftpd-basic.init
@@ -46,9 +46,10 @@ test -f $DAEMON || exit 0
#
if ! egrep -qi ^[[:space:]]*ServerType.*standalone $CONFIG_FILE
then
- if egrep -qi server[[:space:]]*=[[:space:]]*/usr/sbin/proftpd /etc/xinetd.conf 2/dev/null || \
- egrep -qi server[[:space:]]*=[[:space:]]*/usr/sbin/proftpd /etc/xinetd.d/* 2/dev/null || \
- egrep -qi ^ftp.*/usr/sbin/proftpd /etc/inetd.conf 2/dev/null
+ if egrep -qi server[[:space:]]*=[[:space:]]*/usr/sbin/(in\.)?proftpd /etc/xinetd.conf 2/dev/null || \
+ egrep -qi server[[:space:]]*=[[:space:]]*/usr/sbin/(in\.)?proftpd /etc/xinetd.d/* 2/dev/null || \
+ egrep -qi ^ftp.*/usr/sbin/(in\.)?proftpd /etc/inetd.d/* 2/dev/null || \
+ egrep -qi ^ftp.*/usr/sbin/(in\.)?proftpd /etc/inetd.conf 2/dev/null
then
RUN=no
INETD=yes
@@ -70,7 +71,8 @@ fi
inetd_check()
{
- if [ ! -x /usr/sbin/inetd -a ! -x /usr/sbin/xinetd ]; then
+ if [ ! -x /usr/sbin/inetd -a ! -x /usr/sbin/xinetd -a \
+ ! -x /usr/sbin/inetutils-inetd ]; then
echo Neither inetd nor xinetd appears installed: check your configuration.
fi
}
--
1.7.2.5
Bug#534338: OpenSSL bindings for Perl -- licensing questions
Hi Daniel, I was searching for the package libcrypt-openssl-aes-perl. With some wildcards I stumbled upon this wnpp bug. Was my package (Crypt::OpenSSL::AES) included in your wnpp, or should I create a new wnpp bug for this? Thanks for your input. Regards, Kai Storbeck signature.asc Description: OpenPGP digital signature
Bug#678815: ITP: wmfs -- Window Manager From Scratch
2012/6/27 Axel Beckert a...@debian.org: Hi Mickaël, Hi If you still need a sponsor: I'm curious on that window manager. The feature description by Serge sounded promising and the screenshots on the website look neat, too. Yes, i'm still looking for a sponsor :-) I will add more informations to the ITP bug soon. I'm currently using awesome and ratpoison -- and packaging a non-tiling window manager myself which I prefer when a tiling doesn't do the job (think Gimp). Yeah, Gimp (= 2.6) is a problem with almost every tiling window manager I had the same problem, that's why i switched to Gimp 2.7. While awesome and ratpoison are fine for my daily work they still have their usability itches (a few of them were already mentioned by Serge -- awesome's configuration in Lua is one of them). I also tried i3 and scrotwm for a while, and looked at subtle and herbstluftwm (despite their concepts are too far away from what I look for). I never tryed Ratpoison, but i used Awesome for a while, and i ended up with a 800 lines long rc.lua. I'm not a big fan of Lua :-p I tryed i3 too, but i don't like the tree structure, so finally i tryed WMFS and i use it since a little more than a year. That's why i had the idea to package it. I tried to look at http://mentors.debian.net/debian/pool/main/w/wmfs/wmfs_2~beta201206-3.dsc and http://mentors.debian.net/debian/pool/main/w/wmfs/wmfs_2~beta201206-3.dsc but those upload seems incomplete: dpkg-source: error: File ./wmfs_2~beta201206.orig.tar.xz has size 53492 instead of expected 296604 dpkg-source: error: File ./wmfs_2~beta201206.orig.tar.xz has size 53492 instead of expected 53512 In fact, the `debian' folder i created for the package is now in the WMFS git repository, so when i want to build it, i create a .orig.tar.xz file with the following command: tar --xz -cvf ../wmfs2~beta201206.orig.tar.xz --exclude=debian ... and then i build the package with `debuild' and i upload it with `dput'. So i think i forgotten to run `make clean' before archiving and there is probably some binaries inside, which whould explain the error message :-/ If you want to try WMFS, you can still use the source: git clone git://github.com/xorg62/wmfs.git cd wmfs debian/rules binary-all The newest one which seemed complete was http://mentors.debian.net/debian/pool/main/w/wmfs/wmfs_2\~beta201206.dsc Since alone from what I see on the mentors site the newer packages are quite improved over that one, I'd prefer to have a look at the current state instead of this out-dated version. As i said in the previous message, i'm currently at work and i go back home only Friday evening, so i can't fix the problem with the orig file till then... Apart from that, i am wondering if it's better to call the package `wmfs' with the version number `2~betadate', as i did, or if i should rather call it `wmfs2' with version number `date', as WMFS was been completely rewritten since the version 1 ... Have a nice day. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679222: evince: Problem displaying PDF document
Package: evince Version: 3.4.0-2+b1 Severity: normal Dear Maintainer, Trying to display the document http://jan.ucc.nau.edu/~jmn3/papers/num.pdf with evince results in a garbled page. Acrobat readers renders it fine ― implying the document is not damaged. Best, C. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'unstable'), (300, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.20 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evince depends on: ii evince-common3.4.0-2 ii gnome-icon-theme 3.4.0-2 ii libatk1.0-0 2.4.0-2 ii libc62.13-33 ii libcairo-gobject21.12.2-1 ii libcairo21.12.2-1 ii libevdocument3-4 3.4.0-2+b1 ii libevview3-3 3.4.0-2+b1 ii libgail-3-0 3.4.2-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libgnome-keyring03.4.1-1 ii libgtk-3-0 3.4.2-1 ii libice6 2:1.0.8-2 ii libnautilus-extension1a 3.4.2-1 ii libpango1.0-01.30.0-1 ii libsm6 2:1.2.1-2 ii libx11-6 2:1.5.0-1 ii libxml2 2.8.0+dfsg1-4 ii shared-mime-info 1.0-1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages evince recommends: ii dbus-x11 1.6.0-1 ii gvfs 1.12.3-1+b1 Versions of packages evince suggests: ii nautilus 3.4.2-1 pn poppler-data none pn unrar none -- 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#622622: Hit this issue with 6.0.5 32bit DVD1
So I think it is only fixed with CD image.
Bug#679074: [Pkg-libvirt-maintainers] Bug#679074: Please separate the init scripts for a system-wide libvirtd from the binaries usable for a per-user libvirtd
On Wed, Jun 27, 2012 at 12:32:32AM -0700, Josh Triplett wrote: [..snip..] That seems potentially reasonable. I don't think you necessarily need to bother splitting libvirt-daemon (/usr/sbin/libvirtd) from libvirt-client (virsh and similar), though; a few tiny binaries won't make a difference, as long as they don't run by default. Likewise for the documentation unless it takes up a lot of space. But other than that, those splits make sense. doc is already split out and there's a wishlist bug to split out virsh since ages so we can handle that as well. This would allow boxes to depend on libvirt-daemon-qemu only pulling in the one hypervisor. If a package wants to use libvirt for a specific hypervisor, couldn't they just depend on libvirtd and that hypervisor? Why do you need separate libvirt packages for each hypervisor? (Yes, I realize that Fedora did it that way. :) ) Because that't the only way to say: I want libvirt managed qemu or libvirt managed xen. We're currently handling this via recommends which doesn't work too great. apt-get install libvirt-qemu would do the trick then. I'm not sure we'll get this in place for wheezy though. I don't know if the GNOME team plans to ship 3.4 in wheezy. If they do, which seems likely to me given their upload to unstable rather than experimental, then at least the split of the init scripts needs to happen before wheezy. Would you consider making an upload in the near future that just splits off the configuration files (and /lib/systemd/system if you ship a service file) into a separate package? The larger reorganization could then wait until post-wheezy. (Suggestion: leave libvirt-bin as the package with the binaries, and call the new package libvirt-daemon-config .) The config split is the harder part (moving around config files, renaming them, etc). Splitting out the hypervisor modules is the easy. It's more a matter of time on my side at the moment. But I'll try to start work on this for 0.9.13-rc2. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679223: ITP: tonicdns -- RESTful API for PowerDNS
Package: wnpp Severity: wishlist Owner: Kouhei Maeda mkou...@palmtb.net * Package name: tonicdns Version : 1.1.0 Upstream Author : Cyso Managed Hosting developm...@cyso.nl * URL : https://github.com/Cysource/TonicDNS * License : GPL Programming Lang: PHP Description : RESTful API for PowerDNS It uses the MIT licensed Tonic RESTful library as its base. Feature is below: * Token based communication. * Option to store tokens in the PowerDNS database, or in a separate SQLite database. * Should work with any PowerDNS backend database, tested with MySQL. * Supports adding of zones, records and zone and record templates. * Atomic commits, all modifications are validated on input and executed in a single transaction. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts
* Michael Meskes mes...@debian.org [120626 14:48]: [ Guillem Jover guil...@debian.org [120626 12:05]:] I'll be reopening 665987, but if that gets closed again I'd be very happy to switch to acpi-support-minimal from my now locally built acpi-support packages w/ the consolekit dependency removed. [...] I'm absolutely willing to listen to ideas of solving this, which imo would be a much better solution than creating an additional package that will only partly work. [...] I'd prefer to get this fixed in acpi-support-base, but I think you have made your point very clear that the only purpose of that package is to not do anything if some power manager is running and that to detect this perfectly you are totally willing to force anyone to install consolekit (and thus dbus) who justs wants his system shutting down cleanly when the power button is pressed. That this is not issue for you at all and that you do not see any problem in introducing this change 2012-06-21 i.e. shortly before the freeze. If that gets closed again sounds like I was closing the bug without a reason, which I didn't. That sentence was much more neutral than anything I think I could have written. After you were closing two bug reports by just dismissing the issue, a if that gets closed again is a totally objective way to describe expectations. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679224: pu: package tor/0.2.2.37
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Hi, I would like to update the Tor in stable from 0.2.2.35 to 0.2.2.37. This is an update on Tor's stable tree (instead of its development tree) and the changes are thus rather conservative. It fixes a couple of minor security issues, like no longer leaking uninitialized memory, properly rejecting inputs where the number exceeds valid values for its storage types, or not adding more bytes to input buffers while renegotiating. Furthermore, a few issues are resolved that might affect a user's anonymity. These include things such as only building circuits when a client knows a sufficient number of exit nodes, never using a bridge as an exit, or reusing circuits in an unsafe manner. Additionaly it updates the list of directory authorities, makes building with newer and older openssl libraries safer (probably not important for us) and makes building on a few other platforms more robust. Tor versions 0.2.2.36 and .37 have been in unstable and testing for a few weeks now and I am reasonably confident that 0.2.2.37 is fit for being included in the next point release of squeeze. May I prepare and upload a 0.2.2.37-1~squeeze1 tor package? Cheers, weasel https://gitweb.torproject.org/debian/tor.git/blob/refs/heads/debian-0.2.2:/ChangeLog https://gitweb.torproject.org/debian/tor.git/blob/refs/heads/debian-0.2.2:/debian/changelog -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679225: /usr/bin/debmany: use curl --location to follow redirects
Package: debian-goodies Version: 0.53 Severity: normal File: /usr/bin/debmany Tags: patch If one uses the http://http.debian.net/ mirror redirector in their sources.list, debmany fails to download packages which are not installed. This is due to curl seeing the HTTP redirect and then just exiting, by default. The fix is very simple: add the --location option to the curl invocation: curl --location $url $file || error Failed to download '$url' to '$file'. (For the purpose of googling, the error you get is of the form dpkg-deb: unexpected end of file in version number in /dev/shm/debmany.ucyvhHmoAJ/tmp.deb). -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debian-goodies depends on: ii curl 7.21.0-2.1+squeeze2 Get a file from an HTTP, HTTPS or ii dctrl-tools [grep-dc 2.14.5 Command-line tools to process Debi ii dialog 1.1-20100428-1 Displays user-friendly dialog boxe ii less 436-1 pager program similar to more ii lsof 4.81.dfsg.1-1 List open files ii perl 5.10.1-17squeeze3 Larry Wall's Practical Extraction ii python 2.6.6-3+squeeze7interactive high-level object-orie ii whiptail 0.52.11-1 Displays user-friendly dialog boxe debian-goodies recommends no packages. Versions of packages debian-goodies suggests: ii popularity-contest 1.49Vote for your favourite packages a ii xdg-utils1.0.2+cvs20100307-2 desktop integration utilities from ii zenity 2.30.0-1Display graphical dialog boxes fro -- 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#679227: It fails upgrade
Package: tex-common Version: 3.13 Severity: serious In upgrading tex-common it results: Can't locate TeXLive/TLUtils.pm in @INC (@INC contains: //tlpkg /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/bin/updmap line 21. BEGIN failed--compilation aborted at /usr/bin/updmap line 21. It prevents configuring of tex-common latex-xcolor luatex texlive-binaries It is solved by installing texlive-common before. So it seems a missing build-dep. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tex-common depends on: ii debconf [debconf-2.0] 1.5.44 ii dpkg 1.16.4.3 ii ucf3.0025+nmu3 tex-common recommends no packages. Versions of packages tex-common suggests: ii debhelper 9.20120608 Versions of packages texlive-base depends on: ii debconf [debconf-2.0] 1.5.44 ii dpkg 1.16.4.3 ii install-info 4.13a.dfsg.1-10 ii libpaper-utils 1.1.24+nmu2 iu luatex 0.70.1.20120524-2 ii mime-support 3.52-1 iu texlive-binaries 2012.20120623-2 ii texlive-common 2011.20120509-1 ii texlive-doc-base 2011.20120509-1 ii ucf3.0025+nmu3 Versions of packages texlive-base recommends: ii lmodern 2.004.1-5 Versions of packages texlive-base suggests: ii evince-gtk [postscript-viewer] 3.2.1-1+b1 ii ghostscript [postscript-viewer] 9.05~dfsg-6 ii gv [postscript-viewer] 1:3.7.3-1 ii perl-tk 1:804.030-1 ii xpdf [pdf-viewer]3.03-10 ii xpdf-reader 3.02-12 ii zathura [pdf-viewer] 0.1.2-4 Versions of packages texlive-binaries depends on: ii dpkg1.16.4.3 ii ed 1.6-2 ii install-info4.13a.dfsg.1-10 ii libc6 2.13-33 ii libfontconfig1 2.9.0-6 ii libfreetype62.4.9-1 ii libgcc1 1:4.7.1-2 ii libgraphite31:2.3.1-0.2 ii libkpathsea62012.20120623-2 ii libpng12-0 1.2.49-1 ii libpoppler190.18.4-3 ii libptexenc1 2012.20120623-2 ii libstdc++6 4.7.1-2 ii libx11-62:1.5.0-1 ii libxaw7 2:1.0.10-2 ii libxmu6 2:1.1.1-1 ii libxpm4 1:3.5.10-1 ii libxt6 1:1.1.3-1 ii perl5.14.2-12 ii texlive-common 2011.20120509-1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages texlive-binaries recommends: iu luatex 0.70.1.20120524-2 ii python 2.7.3~rc2-1 ii ruby4.8 ii ruby1.8 [ruby] 1.8.7.358-4 ii texlive-base2011.20120509-1 ii tk8.4 [wish]8.4.19-5 ii tk8.5 [wish]8.5.11-2 -- Configuration Files: /etc/texmf/web2c/mktex.cnf [Errno 2] File o directory non esistente: u'/etc/texmf/web2c/mktex.cnf' -- debconf information: texlive-base/texconfig_ignorant: tex-common/check_texmf_wrong: texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi tex-common/check_texmf_missing: tex-common/singleuser: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679180: FTBFS on arm*: SHLIB_LIBADD: No such file or directory
2012/6/27 Julian Gilbey jul...@d-and-j.net: Are you seeing this problems with other R packages or is it unique to this one? I noticed there are a lot of this failures, but I have realized that after I sent this bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679228: ocl-icd-libopencl1: unversioned .so in library runtime package
Package: ocl-icd-libopencl1 Version: 1.1-1 Severity: serious ocl-icd-libopencl1 ships the unversioned .so in the library runtime package, however Policy 8.2 says If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Otherwise, several versions of the shared library cannot be installed at the same time without filename clashes, making upgrades and transitions unnecessarily difficult. It looks like this was fixed, but then reverted again as the changelog for 1.3-2 says * in particular, move the .so from -dev to -libopencl1 in order to support programs created with the Intel SDK Regards, Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675310: This Package grive would be very useful.
Hello, This Package grive would be very usefully. Thank You. Regards, -- Pierre Crescenzo mailto:pie...@crescenzo.nom.fr http://www.crescenzo.nom.fr/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678902: catalog registration disappeared during upgrade
severity 678902 serious thanks Helmut could you please comment on #678902 ? Thanks much -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679229: src:supercollider: bouncing mail address for Dan Stowell
Source: supercollider X-Debbugs-Cc: fsate...@debian.org The address listed in Uploaders (and Changed-By for the last upload) for Dan Stowell bounces, see below. Ansgar Original Message Subject: Mail delivery failed: returning message to sender Date: Wed, 27 Jun 2012 10:06:50 + From: Mail Delivery System mailer-dae...@franck.debian.org To: envel...@ftp-master.debian.org This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: danstow...@users.sourceforge.net SMTP error from remote mail server after RCPT TO:danstow...@users.sourceforge.net: host mx.sourceforge.net [216.34.181.68]: 550 unknown user -- This is a copy of the message, including all the headers. -- Return-path: envel...@ftp-master.debian.org Received: from dak by franck.debian.org with local (Exim 4.72) (envelope-from envel...@ftp-master.debian.org) id 1Sjp8v-0001Gh-L2; Wed, 27 Jun 2012 10:06:37 + Date: Wed, 27 Jun 2012 10:06:37 + Message-Id: e1sjp8v-0001gh...@franck.debian.org From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: Dan Stowell danstow...@users.sourceforge.net, Debian Multimedia Packages Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org, fsate...@debian.org X-DAK: dak process-upload X-Debian: DAK X-Debian-Package: supercollider Precedence: bulk MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: supercollider_3.5.2-1_amd64.changes ACCEPTED into unstable Sender: Archive Administrator d...@franck.debian.org Accepted: libscsynth1_3.5.2-1_amd64.deb to main/s/supercollider/libscsynth1_3.5.2-1_amd64.deb supercollider-common_3.5.2-1_all.deb to main/s/supercollider/supercollider-common_3.5.2-1_all.deb supercollider-dev_3.5.2-1_amd64.deb to main/s/supercollider/supercollider-dev_3.5.2-1_amd64.deb supercollider-emacs_3.5.2-1_all.deb to main/s/supercollider/supercollider-emacs_3.5.2-1_all.deb supercollider-gedit_3.5.2-1_all.deb to main/s/supercollider/supercollider-gedit_3.5.2-1_all.deb supercollider-server_3.5.2-1_amd64.deb to main/s/supercollider/supercollider-server_3.5.2-1_amd64.deb supercollider-supernova_3.5.2-1_amd64.deb to main/s/supercollider/supercollider-supernova_3.5.2-1_amd64.deb supercollider-vim_3.5.2-1_all.deb to main/s/supercollider/supercollider-vim_3.5.2-1_all.deb supercollider_3.5.2-1.debian.tar.gz to main/s/supercollider/supercollider_3.5.2-1.debian.tar.gz supercollider_3.5.2-1.dsc to main/s/supercollider/supercollider_3.5.2-1.dsc supercollider_3.5.2-1_amd64.deb to main/s/supercollider/supercollider_3.5.2-1_amd64.deb supercollider_3.5.2.orig.tar.bz2 to main/s/supercollider/supercollider_3.5.2.orig.tar.bz2 Changes: supercollider (1:3.5.2-1) unstable; urgency=low . * Imported Upstream version 3.5.2 * Add manpage for supernova * Use system mathjax via dh_linktree * Backport fix to vim plugin from upstream Override entries for your package: libscsynth1_3.5.2-1_amd64.deb - optional sound supercollider-common_3.5.2-1_all.deb - optional sound supercollider-dev_3.5.2-1_amd64.deb - optional sound supercollider-emacs_3.5.2-1_all.deb - optional sound supercollider-gedit_3.5.2-1_all.deb - optional sound supercollider-server_3.5.2-1_amd64.deb - optional sound supercollider-supernova_3.5.2-1_amd64.deb - optional sound supercollider-vim_3.5.2-1_all.deb - optional sound supercollider_3.5.2-1.dsc - source sound supercollider_3.5.2-1_amd64.deb - optional sound Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian.
Bug#679230: karbon: package description review
Package: karbon Version: 2.4.2 Severity: wishlist Tags: patch I'm glad to see the package descriptions for the KOffice^WCalligra suite are being maintained; but there are still a few typos and other language problems, especially in the description for karbon. Package: calligra [...] Description: extensive productivity and creative suite Calligra Suite is a set of applications written to help you to accomplish your work. It includes office applications such as a word processor, a spreadsheet, a presentation program, a database application, etc, and raster and vectorial graphics tools. There's no such thing as vectorial graphics. (Yes, the adjective vectorial exists, as in phrases like vectorial relativity; but no, for artwork we just use the attributive noun: vector graphics.) While I'm editing this I might as well insist on s/etc/etc./ too. (Likewise when this is repeated in the calligra-reports-* packages.) . This metapackage provides all the components of the Calligra Suite. Package: karbon [...] Description: vector graphics application for the Calligra Suite Karbon is a vector drawing application with an user interface that is easy to s/an user/a user/ use, highly customizable and extensible. [...] Is this meant to be saying that Karbon's UI is: 1) easy to use, 2) highly customizable-and-extensible (in which case there's a missing conjunction after easy to use); or is it saying that it's: 1) easy to use, 2) highly customizable, and 3) extensible (which is just mildly awkward, in that it has the most complex phrase in the middle rather than at the end)? I'll assume the latter, and suggest removing the ambiguity by reordering them: Karbon is a vector drawing application with a user interface that is easy to use, extensible and highly customizable. (If I was standardising the text towards debian-l10n-english's house style I would also insert an extra (Harvard) comma there, but at present these descriptions are consistently not using that style.) [...] That makes Karbon a great application s/That/This/. for users starting to explore the world of vector graphics as well as for artists wanting to create breathtaking vector art. Features include: . * Loading support for ODG, SVG, WPG, WMF, EPS/PS * Writing support for ODG, SVG, PNG, PDF, WMF These don't seem to be in any particular order - I would recommend lining them up so that it's obvious where the overlap is: * Loading support for ODG, SVG, WMF, WPG, EPS/PS * Writing support for ODG, SVG, WMF, PDF, PNG (For d-l-e house style I would start each bulletpoint with lowercase and end it with a semicolon, but that's also not in my patch.) * Customizable user interface with freely placable toolbars and dockers ^ Unspellcheckable typo: s/placable/placeable/ (placable is the opposite of implacable). * Layer docker for easy handling of complex documents including preview thumbnails, support for grouping shapes via drag and drop, controlling visibility of shapes or locking * Advanced path editing tool with great on-canvas editing capabilies ^^ Typo: s/capabilies/capabilities/ * Various drawing tools for creating path shapes including a draw path tool, a pencil tool as well as a calligraphy drawing tool You can't just substitute in as well as in place of and; it's either * Various drawing tools for creating path shapes including a draw path tool, a pencil tool(,) and a calligraphy drawing tool or for variety: * Various drawing tools for creating path shapes including a draw path tool and a pencil tool, as well as a calligraphy drawing tool * Gradient and pattern tools for easy on-canvas editing of gradient and pattern styles * Top notch snapping facilities for guided drawing and editing (e.g. snapping to grid, guide lines, path nodes, bounding boxes, orthogonal positions, intersections of path shapes or extensions of lines and paths) * Includes many predefined shapes including basic shapes like stars, circle/ellipse, rectangle, image This is the only item on the list expressed as a verb phrase, and it's a bit repetitive (as well as using like in a manner unpopular with English teachers). Besides, how is image a predefined basic shape that belongs on this list? So I'd suggest rephrasing it as: * Many predefined basic shapes included, such as circle/ellipse, star or rectangle * Artistic text shape with support for following path outlines (i.e. text on path) * Complex path operations and effects like boolean set operations, The dictionaries say Boolean is capitalised (at least when it's not a reserved word in some programming language). path flattening, rounding and refining as well as whirl/pinch effects * Extensible by writing plugins for new tools, shapes
Bug#670293: code-aster-{gui, run}: prompting due to modified conffiles which were not modified by the user
Da: Julien Cristau jcris...@debian.org
A: Andreas Beckmann deb...@abeckmann.de; 670...@bugs.debian.org
Inviato: Martedì 26 Giugno 2012 11:44
Oggetto: Bug#670293: code-aster-{gui, run}: prompting due to modified
conffiles which were not modified by the user
A configuration file can't both be shipped in the package (and thus be a
conffile) and handled using debconf. The patch below should make them
non-conffile, and handle reconfiguration properly. I haven't tested it
yet, not sure I can get to it today.
Changes:
- split templates in code-aster-run and code-aster-gui. Some are
shared.
- install files to /usr/share/codeaster instead of /etc/codeaster/asrun,
/etc/codeaster/astk/prefs and /etc/codeaster/astk/config_serveurs
- in *.config, if the config file exists, read the value from it and
seed that into debconf; if not use a default
- in *.postinst, on initial install copy the templates from
/usr/share/codeaster; then proceed to reading the debconf stored
values and writing them in the config files.
Hope this helps.
Cheers,
Julien
Hi,
thank you for the patch, I'll take a look at it as soon as I can and then apply
it for a new package.
Bye
Andrea
Bug#672564: kde-window-manager: KWin leaks pixmaps when using XRender and Box Switch
Hi, Alle sabato 19 maggio 2012, Kitty PC ha scritto: I had a talk with a person in the kde irc channel (thank you said person) said person was mgraesslin, who is the kwin maintainer. this is apparently fixed in version 4.8 of kwin, so I hope that version can be pushed soon. Since now there is kde-workspace (win kwin) 4.8.4 in testing, do you still experience this issue? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#678902: catalog registration disappeared during upgrade
reassign 678902 sgml-base found 678902 sgml-base/1.16+nmu2 retitle 678902 sgml-base needs to Pre-Depend on dpkg 1.16.4 thanks On Wed, Jun 27, 2012 at 12:15:45PM +0200, Mathieu Malaterre wrote: Helmut could you please comment on #678902 ? Thanks for bringing this to my attention. The most likely cause is a problem with dpkg triggers which is fixed in dpkg version 1.16.4. See #675613 and its duplicates for further information. Please check your dpkg version. 1) If it is lower that 1.16.4, upgrade dpkg, run update-catalog --update-super. Your catalog should be fine now. 2) If it is at least 1.16.4, it was likely upgraded after the last trigger run. Run update-catalog --update-super. Your catalog should be fine now. If these steps do not resolve the problem, my conclusion was wrong and we need to further debug this. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656719: [PATCH v5 1/3] Add Gallium VDPAU and XvMC driver support (#656719)
From: Fabio Pedretti fabio@libero.it
Date: Sun, 29 Jan 2012 21:00:57 +0100
Since version 8.0 Mesa provides XvMC and VDPAU Gallium3D video
acceleration drivers.
Fabio’s patch sent to the Debian BTS [1] is adapted
1. to comment
ln -s build/dri/$(DEB_HOST_MULTIARCH)/gallium/XvMCConfig
/etc/X11/XvMCConfig
overwriting `/etc/X11/XvMCConfig` already shipped by `libxvmc1`,
2. to not install `/etc/XvMCConfig` which should live under `/etc/X11/`,
3. to remove a line from `not_installed`
4. and to install the XvMC libraries under `/usr/lib/` and not
`/usr/lib/dri/` so that MPlayer finds them.
$ mplayer -vo xvmc -vc ffmpeg12mc dvd.mpeg2
MPlayer svn r34540 (Debian), built with gcc-4.7 (C) 2000-2012 MPlayer
Team
[…]
XvMCWrapper: Could not load hardware specific XvMC library
libXvMCr600.so.1.
libXvMCr600.so.1: cannot open shared object file: No such file or
directory
vo_xvmc: XvMCCreateContext failed with error 2
[…]
Item 2 probably has to be solved by some kind of `update-alternatives`
to work when this package in deinstalled again.
No file `NEWS.Debian` is provided since the support is still work in
progress.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656719
---
For some reason XvMCConfig is not in my build tree anymore. So I took that out
too.
debian/changelog|7 +++
debian/control | 22 ++
debian/libg3dvl-mesa.install.in |2 ++
debian/not-installed|4 +++-
debian/rules|5 -
5 files changed, 38 insertions(+), 2 deletions(-)
create mode 100644 debian/libg3dvl-mesa.install.in
diff --git a/debian/changelog b/debian/changelog
index 0eb66a1..a6900df 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mesa (8.0.3-2) UNRELEASED; urgency=low
+
+ * Enable Gallium VDPAU and XvMC driver support on at least
+Radeon r300+ and r600+. (Closes: #656719) (LP: #1002224)
+
+ -- Fabio Pedretti fabio@libero.it Mon, 21 May 2012 12:46:40 +0300
+
mesa (8.0.3-1) unstable; urgency=low
[ Robert Hooker ]
diff --git a/debian/control b/debian/control
index ec59840..a9fcdd3 100644
--- a/debian/control
+++ b/debian/control
@@ -32,6 +32,8 @@ Build-Depends:
bison,
llvm-2.9-dev [amd64 i386 kfreebsd-amd64 kfreebsd-i386],
libwayland-dev (= 0.85.0) [linux-any],
+ libvdpau-dev (= 0.4.1) [linux-any],
+ libxvmc-dev (= 1.0.6) [linux-any],
Vcs-Git: git://git.debian.org/git/pkg-xorg/lib/mesa
Vcs-Browser: http://git.debian.org/?p=pkg-xorg/lib/mesa.git
Homepage: http://mesa3d.sourceforge.net/
@@ -803,4 +805,24 @@ Description: Mesa OpenGL utility library -- development
files
For a complete description of GLU, please look at the libglu1-mesa
package.
+Package: libg3dvl-mesa
+Section: libs
+Architecture: linux-any
+Depends:
+ ${shlibs:Depends},
+ ${misc:Depends},
+Description: xvmc and vdpau Gallium3D video acceleration drivers
+
+Package: libg3dvl-mesa-dbg
+Section: debug
+Priority: extra
+Architecture: linux-any
+Depends:
+ libg3dvl-mesa (= ${binary:Version}),
+ ${misc:Depends},
+Description: xvmc and vdpau Gallium3D video acceleration drivers
+ .
+ This package contains the debugging symbols for the g3dvl libraries.
+
+
# vim: tw=0
diff --git a/debian/libg3dvl-mesa.install.in b/debian/libg3dvl-mesa.install.in
new file mode 100644
index 000..fe8e252
--- /dev/null
+++ b/debian/libg3dvl-mesa.install.in
@@ -0,0 +1,2 @@
+build/dri/${DEB_HOST_MULTIARCH}/gallium/libvdpau_* usr/lib/vdpau
+build/dri/${DEB_HOST_MULTIARCH}/gallium/libXvMC* usr/lib/
diff --git a/debian/not-installed b/debian/not-installed
index afbf7dc..3ce6d56 100644
--- a/debian/not-installed
+++ b/debian/not-installed
@@ -18,7 +18,9 @@ NOT_INSTALLED := \
usr/include/GL/glx_mangle.h \
usr/include/GL/vms_x_fix.h \
usr/include/GL/wglext.h \
- usr/include/GL/wmesa.h
+ usr/include/GL/wmesa.h \
+ dri/usr/*/libXvMC* \
+ dri/usr/lib/*/vdpau/
# Architecture-specific additional files:
NOT_INSTALLED_i386 = \
diff --git a/debian/rules b/debian/rules
index 3bf3702..c1999da 100755
--- a/debian/rules
+++ b/debian/rules
@@ -119,6 +119,7 @@ confflags-dri = \
--enable-glx-tls \
--enable-shared-glapi \
--enable-texture-float \
+ --enable-gallium-g3dvl \
--enable-xa \
$(confflags_DIRECT_RENDERING) \
$(confflags_EGL) \
@@ -214,6 +215,8 @@ $(STAMP_DIR)/stamp:
$(QUILT_STAMPFN): $(STAMP_DIR)/stamp
build: build-stamp
+ # XvMCConfig configuration file:
+ echo ln -s build/dri/$(DEB_HOST_MULTIARCH)/gallium/XvMCConfig
/etc/X11/XvMCConfig
build-stamp: $(BUILD_STAMPS)
$@
@@ -294,7 +297,7 @@ binary-arch: install
# Also get rid of other files which aren't installed. Do not
# use -f to ensure we notice disappearing files:
- set -e; for file in $(NOT_INSTALLED); do rm debian/tmp/$$file; done
+ set -e; for file in
Bug#656719: [PATCH v5 2/3] debian/control: libg3dvl-mesa: Depend on libxvmc1.
Date: Sun, 24 Jun 2012 17:09:16 +0200
Michael Dänzer confirmed that there seems to be an upstream bug [1].
Am Montag, den 25.06.2012, 09:41 +0200 schrieb Michel Dänzer:
[…]
No, it indeed looks like the Mesa libXvMC*.so.1 libraries don't link
against libXvMC.so.1. I suspect that's an (upstream) bug though, as
they
do seem to reference symbols from libXvMC.so.1.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656719#140
---
debian/changelog |6 +-
debian/control |1 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index a6900df..614bb04 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,13 @@
mesa (8.0.3-2) UNRELEASED; urgency=low
+ [ Fabio Pedretti ]
* Enable Gallium VDPAU and XvMC driver support on at least
Radeon r300+ and r600+. (Closes: #656719) (LP: #1002224)
- -- Fabio Pedretti fabio@libero.it Mon, 21 May 2012 12:46:40 +0300
+ [ Paul Menzel ]
+ * libg3dvl-mesa: Depend on libxvmc1.
+
+ -- Paul Menzel pm.deb...@googlemail.com Sun, 24 Jun 2012 17:09:16 +0200
mesa (8.0.3-1) unstable; urgency=low
diff --git a/debian/control b/debian/control
index a9fcdd3..064cd29 100644
--- a/debian/control
+++ b/debian/control
@@ -809,6 +809,7 @@ Package: libg3dvl-mesa
Section: libs
Architecture: linux-any
Depends:
+ libxvmc1,
${shlibs:Depends},
${misc:Depends},
Description: xvmc and vdpau Gallium3D video acceleration drivers
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Bug#618487: mysql-server-5.1: thread_stack = 128 k
Hello I encountered the same issue with Version: mysqld Ver 5.1.61-0+squeeze1 for debian-linux-gnu on x86_64 ((Debian)) Package: mysql-server-core-5.1 The thread_stack value was 192k though it should be 256k on a x86_64 system, following the doc http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_thread_stack Thanks for your attention. Regards
Bug#656719: [PATCH v5 3/3] Split up libg3dvl-mesa into libvdpau1-gallium and libxvmc1-gallium
Date: Tue, 26 Jun 2012 13:09:46 +0200
The package names were suggested by Michael Dänzer [1] and were agreed
upon by Fabio Pedretti [2].
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677886#26
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656719#145
---
debian/changelog|3 +-
debian/control | 52 +++
debian/libg3dvl-mesa.install.in |2 --
debian/libvdpau1-gallium.install.in |1 +
debian/libxvmc1-gallium.install.in |1 +
5 files changed, 50 insertions(+), 9 deletions(-)
delete mode 100644 debian/libg3dvl-mesa.install.in
create mode 100644 debian/libvdpau1-gallium.install.in
create mode 100644 debian/libxvmc1-gallium.install.in
diff --git a/debian/changelog b/debian/changelog
index 614bb04..4467a87 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,8 +6,9 @@ mesa (8.0.3-2) UNRELEASED; urgency=low
[ Paul Menzel ]
* libg3dvl-mesa: Depend on libxvmc1.
+ * Split up libg3dvl-mesa into libvdpau1-gallium and libxvmc1-gallium.
- -- Paul Menzel pm.deb...@googlemail.com Sun, 24 Jun 2012 17:09:16 +0200
+ -- Paul Menzel pm.deb...@googlemail.com Tue, 26 Jun 2012 13:09:46 +0200
mesa (8.0.3-1) unstable; urgency=low
diff --git a/debian/control b/debian/control
index 064cd29..8b264e2 100644
--- a/debian/control
+++ b/debian/control
@@ -805,25 +805,65 @@ Description: Mesa OpenGL utility library -- development
files
For a complete description of GLU, please look at the libglu1-mesa
package.
-Package: libg3dvl-mesa
+Package: libvdpau1-gallium
+Section: libs
+Architecture: linux-any
+Depends:
+ ${shlibs:Depends},
+ ${misc:Depends},
+Description: VDPAU Gallium3D video acceleration drivers
+ .
+ Currently these drivers support using the GPU to decode MPEG2 material.
+ .
+ Recent MPlayer versions use the provided library automatically. But you
+ can manually use it using for example the following command line.
+ .
+ .mplayer -vo vdpau -vc ffmpeg12vdpau example.mpeg2
+ .
+ Beware that this is work in progress and might not work as expected.
+
+Package: libvdpau1-gallium-dbg
+Section: debug
+Priority: extra
+Architecture: linux-any
+Depends:
+ libvdpau1-gallium (= ${binary:Version}),
+ ${misc:Depends},
+Description: debugging symbols for VDPAU Gallium3D video acceleration drivers
+ .
+ This package contains the debugging symbols for the VDPAU g3dvl libraries.
+
+Package: libxvmc1-gallium
Section: libs
Architecture: linux-any
Depends:
libxvmc1,
${shlibs:Depends},
${misc:Depends},
-Description: xvmc and vdpau Gallium3D video acceleration drivers
+Description: XvMC Gallium3D video acceleration drivers
+ .
+ Currently these drivers support using the GPU to decode MPEG2 material.
+ .
+ Recent MPlayer versions use the provided library automatically. But you
+ can manually use it using for example the following command line.
+ .
+ .mplayer -vo xvmc -vc ffmpeg12mc example.mpeg2
+ .
+ You have to edit `/etc/X11/XvMCConfig` and list your hardware specific
+ library in there, for example `libXvMCr600.so.1`.
+ .
+ Beware that this is work in progress and might not work as expected.
-Package: libg3dvl-mesa-dbg
+Package: libxvmc1-gallium-dbg
Section: debug
Priority: extra
Architecture: linux-any
Depends:
- libg3dvl-mesa (= ${binary:Version}),
+ libxvmc1-gallium (= ${binary:Version}),
${misc:Depends},
-Description: xvmc and vdpau Gallium3D video acceleration drivers
+Description: debugging symbols for XvMC Gallium3D video acceleration drivers
.
- This package contains the debugging symbols for the g3dvl libraries.
+ This package contains the debugging symbols for the XvMC g3dvl libraries.
# vim: tw=0
diff --git a/debian/libg3dvl-mesa.install.in b/debian/libg3dvl-mesa.install.in
deleted file mode 100644
index fe8e252..000
--- a/debian/libg3dvl-mesa.install.in
+++ /dev/null
@@ -1,2 +0,0 @@
-build/dri/${DEB_HOST_MULTIARCH}/gallium/libvdpau_* usr/lib/vdpau
-build/dri/${DEB_HOST_MULTIARCH}/gallium/libXvMC* usr/lib/
diff --git a/debian/libvdpau1-gallium.install.in
b/debian/libvdpau1-gallium.install.in
new file mode 100644
index 000..757160f
--- /dev/null
+++ b/debian/libvdpau1-gallium.install.in
@@ -0,0 +1 @@
+build/dri/${DEB_HOST_MULTIARCH}/gallium/libvdpau_* usr/lib/vdpau
diff --git a/debian/libxvmc1-gallium.install.in
b/debian/libxvmc1-gallium.install.in
new file mode 100644
index 000..75e5a10
--- /dev/null
+++ b/debian/libxvmc1-gallium.install.in
@@ -0,0 +1 @@
+build/dri/${DEB_HOST_MULTIARCH}/gallium/libXvMC* usr/lib/
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Bug#679231: linux-image-3.2.0-3-686-pae: fails to resume completely from sleep, complains about ehci_hcd and legacy_resume
Package: src Version: 3.2.21-2 Severity: normal Tags: upstream Dear Maintainer, Sleep Resume works fine after a reboot. Following a couple of sleeps, however, the machine gets cranky. Before waking up, it shows a brief message legacy_resume(): pnp_bus_resume+0x0/0x55 returns -19 PM: Device 00:0a failed resume: error -19 legacy_resume(): pnp_bus_resume+0x0/0x55 returns -19 PM: Device 00:0a failed resume: error -19 ehci_hcd :00:1d.7: dma_pool_free buffer-128, ff77b6000 (followed by, I think 'bad DMA') ehci_hcd :00:1d.7: dma_pool_free buffer-128, ff77b5000 (followed by, I think 'bad DMA') legacy_resume(): pnp_bus_resume+0x0/0x55 returns -19 PM: Device 00:0a failed resume: error -19 At times it wont go past this message, but mostly it will. However, then the sleep led will be blinking. And # echo -n mem /sys/power/state will return 'Device or resource busy'. The machine will not go into sleep. Closing the lid will then cause the display manager to restart. I've been looking into bug reports and so on, it might be related to Bug#661112 -- Package-specific info: ** Version: Linux version 3.2.0-3-686-pae (Debian 3.2.21-2) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Tue Jun 26 08:24:22 UTC 2012 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-3-686-pae root=/dev/mapper/altiphrynoides-root ro quiet ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [ 12.032881] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 12.032883] thinkpad_acpi: ThinkPad BIOS 6HET27WW (1.12 ), EC 6HHT14WW-1.02 [ 12.032885] thinkpad_acpi: Lenovo ThinkPad T400s, model 2808D9G [ 12.054417] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 12.054575] thinkpad_acpi: radio switch found; radios are enabled [ 12.058633] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is blocked [ 12.061885] thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked [ 12.063238] Registered led device: tpacpi::thinklight [ 12.063835] Registered led device: tpacpi::power [ 12.064047] iwlwifi :03:00.0: loaded firmware version 8.83.5.1 build 33692 [ 12.064131] Registered led device: tpacpi::standby [ 12.064156] Registered led device: tpacpi::thinkvantage [ 12.064570] Registered led device: phy0-led [ 12.066342] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 12.066417] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [ 12.068533] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input5 [ 12.083495] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 12.430486] fbcon: inteldrmfb (fb0) is primary device [ 12.598329] Console: switching to colour frame buffer device 180x56 [ 12.603017] fb0: inteldrmfb frame buffer device [ 12.603019] drm: registered panic notifier [ 12.605246] acpi device:02: registered as cooling_device2 [ 12.605365] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input6 [ 12.605405] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 12.605498] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [ 12.605525] i801_smbus :00:1f.3: PCI INT A - GSI 23 (level, low) - IRQ 23 [ 12.605653] snd_hda_intel :00:1b.0: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 12.605716] snd_hda_intel :00:1b.0: irq 47 for MSI/MSI-X [ 12.605746] snd_hda_intel :00:1b.0: setting latency timer to 64 [ 12.651254] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input7 [ 12.800104] usb 3-2: new full-speed USB device number 3 using uhci_hcd [ 12.839211] psmouse serio1: synaptics: Touchpad model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd047b3/0xb4/0xa [ 12.839232] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0 [ 12.883726] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input8 [ 12.943906] EXT4-fs (dm-1): re-mounted. Opts: (null) [ 12.969769] usb 3-2: New USB device found, idVendor=0a5c, idProduct=2145 [ 12.969774] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 12.969777] usb 3-2: Product: ThinkPad Bluetooth with Enhanced Data Rate II [ 12.969780] usb 3-2: Manufacturer: Lenovo Computer Corp [ 12.980685] EXT4-fs (dm-1): re-mounted. Opts: discard,errors=remount-ro [ 12.986399] Bluetooth: Core ver 2.16 [ 12.986423] NET: Registered protocol family 31 [ 12.986426] Bluetooth: HCI device and connection manager initialized [ 12.986430] Bluetooth: HCI socket layer initialized [ 12.986432] Bluetooth: L2CAP socket layer initialized [ 12.986605] Bluetooth: SCO socket layer initialized [ 12.989269] Bluetooth: Generic Bluetooth USB driver ver 0.6 [ 12.989719] usbcore: registered new interface driver btusb [ 13.035415] loop: module loaded [ 13.058114] thinkpad_ec: thinkpad_ec 0.41 loaded. [ 13.059076] tp_smapi 0.41 loading...
Bug#664190: strongswan NMU
On 06/25/2012 08:32 AM, Yves-Alexis Perez wrote: I didn't want to go that route because I really don't think I'll be able to handle this long, but I'm considering doing an NMU of strongswan to update it to latest release before freeze. Unfortunately, I'm still too busy with other projects and won't realistically managed to do much in the next 3-4 weeks. Therefore, please feel free to NMU until my next upload (which will be after that time). Right now, I have no real idea what is your method to package new stuff in strongswan, so it'd be really nice if you could give me some pointer so I can do the work directly in your repository. I use git-buildpackage, and the repo is on Alioth. There's really not much process besides the standard git-Debian-packaging update scripts, manual compiles, manual checks, changelog updating, and uploading. best regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679232: libxft2: update from 2.2.0-3 - 2.3.1-1 breaks font in rxvt-unicode
Package: libxft2 Version: 2.3.1-1 Severity: normal Dear X Strike Force, * What led up to the situation? [UPGRADE] libxft2:amd64 2.2.0-3 - 2.3.1-1 i'm using the font envy code r for rxvt-unicode, after the upgrade of libxft2 rxvt-unicode falls back to the default monospace font. Downgrading to libxft2 2.2.0-3 fixes the problem and the configured font is used again. Here is the relevant part of my .Xdefaults: --- Xft.dpi: 96 Xft.antialias: true Xft.rgba: rgb Xft.hinting: true Xft.hinstyle: hintslight URxvt.font: xft:envy code r:medium:pixelsize=14 --- -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxft2 depends on: ii libc6 2.13-33 ii libfontconfig1 2.9.0-6 ii libfreetype6 2.4.9-1 ii libx11-6 2:1.5.0-1 ii libxrender11:0.9.7-1 ii multiarch-support 2.13-33 libxft2 recommends no packages. libxft2 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#664190: strongswan NMU
On mer., 2012-06-27 at 12:36 +0200, René Mayrhofer wrote: On 06/25/2012 08:32 AM, Yves-Alexis Perez wrote: I didn't want to go that route because I really don't think I'll be able to handle this long, but I'm considering doing an NMU of strongswan to update it to latest release before freeze. Unfortunately, I'm still too busy with other projects and won't realistically managed to do much in the next 3-4 weeks. Therefore, please feel free to NMU until my next upload (which will be after that time). Thanks for the answer. Right now, I have no real idea what is your method to package new stuff in strongswan, so it'd be really nice if you could give me some pointer so I can do the work directly in your repository. I use git-buildpackage, and the repo is on Alioth. There's really not much process besides the standard git-Debian-packaging update scripts, manual compiles, manual checks, changelog updating, and uploading. Yeah but you keep the whole content into git, so I'm not completely sure on how you update it: using the remote branch (like Xorg packagers), using git-import-orig, pristine-tar, something else? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#679022: does not state domain of unauthenticated/unsigned packages
Thank you very much for your e-mail. If only I had used: man sources.list and searched for 'trust', then I need not have troubled you. Very best regards Richard Betham On Wednesday 27 June 2012 08:26:16 Daniel Hartwig wrote: On 27 June 2012 00:11, Richard Betham rich...@betham.org.uk wrote: I have copied the directory trees /media/cdrom0/pool , and /media/cdrom0/dists to a new directory /wheezy/. I have altered /etc/apt/sources.list to: deb file:///wheezy/ wheezy contrib main I am testing debian-testing-i386-DVD-1.iso . A wheezy cd image here has no Release.gpg or InRelease files required for verification. If your image is similar and you do trust it, sources.list can be altered to indicate this: deb [ trusted=yes ] file:///wheezy/ wheezy contrib main I would like to know where unsigned-for packages are before I decide whether to install. Noted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667973: liferea: Custom date format doesn't work anymore
On Wed, Jun 27, 2012 at 12:55 AM, Vincent Lefevre vinc...@vinc17.net wrote: On 2012-06-26 19:53:37 +0200, Lars Windolf wrote: Am 16.06.2012 21:17, schrieb Vincent Lefevre: On 2012-06-16 20:38:52 +0200, Lars Windolf wrote: The idea was to radically simplify the date formatting by relying only on a single glib method... (which ATM is not yet possible due to a glib bug...). Do you mean that date formatting should be provided by glib? If it is itself configurable, then yes, that would be the best solution. No, not at all. Only the date parsing. The formatting is performed using strptime(). strptime() does parsing, not formatting. strftime() does formatting, and you should use it with a time format that can be specified by the user (not the hardcoded format like now). Sorry about the typo. Did you really think we do not use strftime() for formatting? How would we get any useful output with strptime()... The format codes are supplied by the language translations The default date format in Liferea is broken, as it is a mix of French and English here. Then the translation of the time format literals should be fixed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672564: kde-window-manager: KWin leaks pixmaps when using XRender and Box Switch
Unfortunately I cannot test this issue until plasma-widget-smooth-tasks is updated to support KDE 4.8 as it is currently holding back the related packages. Kitty On 27 June 2012 20:31, Pino Toscano p...@debian.org wrote: Hi, Alle sabato 19 maggio 2012, Kitty PC ha scritto: I had a talk with a person in the kde irc channel (thank you said person) said person was mgraesslin, who is the kwin maintainer. this is apparently fixed in version 4.8 of kwin, so I hope that version can be pushed soon. Since now there is kde-workspace (win kwin) 4.8.4 in testing, do you still experience this issue? -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678042: [SeaBIOS] Bug#678042: seabios - Please enable Xen support
On Mon, 2012-06-25 at 18:55 -0400, Kevin O'Connor wrote:
On Wed, Jun 20, 2012 at 10:25:13AM +0100, Ian Campbell wrote:
On Wed, 2012-06-20 at 10:22 +0100, Ian Campbell wrote:
Subject: [PATCH] enable Xen support by default.
In this context I thought it would also be useful to make
CONFIG_DEBUG_IO_PORT dynamic. However with the below I get lots of build
errors about xen_cpuid_base not being defined. I got similar errors
without the VAR16VISIBLE and GET_GLOBAL hunks. I suspect this is due to
the variable being used in both 32 and 16 bit mode and my not knowing
what I'm doing in that regard ;-)
xen_cpuid_base is defined in xen.c which is only compiled in 32bit
mode, so you can't declare a variable as VAR16VISIBLE there.
Ah, right yes, thanks! I think I keep tripping over that...
I wonder if it is simpler to define a u16 DebugOutputPort
VAR16VISIBLE = CONFIG_DEBUG_IO_PORT in output.c and then override it
early in the xen boot sequence though.
Yes, this makes sense. I actually went one further and nuked the Kconfig
option, since it's only real non-default use was Xen. So now I makde it
default to 0x402 and set it to 0xe9 in the Xen case.
8-
From 903d84d2c320543ac07ae1298d57643575d6ffc8 Mon Sep 17 00:00:00 2001
From: Ian Campbell ian.campb...@citrix.com
Date: Wed, 27 Jun 2012 11:39:01 +0100
Subject: [PATCH] Xen: Autodetect debug I/O port at runtime instead of via
Kconfig
This allows a common image which supports Xen to still print debug
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
src/Kconfig |7 ---
src/output.c |4 +++-
src/util.h |1 +
src/xen.c|5 +
4 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index 8120ff7..8932c9e 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -361,11 +361,4 @@ menu Debugging
information by outputing strings in a special port present in the
IO space.
-config DEBUG_IO_PORT
-depends on DEBUG_IO
-hex Debug IO port address
-default 0x0402
-help
-Bochs uses the 0x0402 address by default, whereas Xen
-makes the 0xe9 IO address available for guests use.
endmenu
diff --git a/src/output.c b/src/output.c
index 37c4942..25300d0 100644
--- a/src/output.c
+++ b/src/output.c
@@ -23,6 +23,8 @@ struct putcinfo {
#define DEBUG_TIMEOUT 10
+u16 DebugOutputPort VAR16VISIBLE = 0x402;
+
void
debug_serial_setup(void)
{
@@ -77,7 +79,7 @@ putc_debug(struct putcinfo *action, char c)
return;
if (CONFIG_DEBUG_IO)
// Send character to debug port.
-outb(c, CONFIG_DEBUG_IO_PORT);
+outb(c, DebugOutputPort);
if (c == '\n')
debug_serial('\r');
debug_serial(c);
diff --git a/src/util.h b/src/util.h
index dbee0e5..ef8ec7c 100644
--- a/src/util.h
+++ b/src/util.h
@@ -231,6 +231,7 @@ int wait_preempt(void);
void check_preempt(void);
// output.c
+extern u16 DebugOutputPort;
void debug_serial_setup(void);
void panic(const char *fmt, ...)
__attribute__ ((format (printf, 1, 2))) __noreturn;
diff --git a/src/xen.c b/src/xen.c
index 961e316..128e6c0 100644
--- a/src/xen.c
+++ b/src/xen.c
@@ -64,6 +64,9 @@ void xen_probe(void)
dprintf(1, Found hypervisor signature \%s\ at %x\n,
signature, base);
if (strcmp(signature, XenVMMXenVMM) == 0) {
+/* Set debug_io_port first, so the following messages work. */
+DebugOutputPort = 0xe9;
+dprintf(1, Found Xen hypervisor signature at %x\n, base);
if ((eax - base) 2)
panic(Insufficient Xen cpuid leaves. eax=%x at base %x\n,
eax, base);
@@ -71,6 +74,8 @@ void xen_probe(void)
break;
}
}
+if (!xen_cpuid_base)
+dprintf(1, No Xen hypervisor found.\n);
}
static int hypercall_xen_version( int cmd, void *arg)
--
1.7.2.5
--
Ian Campbell
Current Noise: Iron Monkey - Shrimp Fist
A diplomatic husband said to his wife, How do you expect me to remember
your birthday when you never look any older?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678992: RFS: grive/0.1.1+20120619git27g55c0f4e-1 [ITP #675310]
José Luis Segura Lucas wrote: El 26/06/12 17:36, Benoît Knecht wrote: I took a look at your package: First of all, thanks for your quick answer :-) You're welcome :) - Since you're packaging a snapshot version, you should adjust your watch file accordingly: Processing watchfile line for package grive... Newest version on remote site is 0.1.1, local version is 0.1.1+20120619git27g55c0f4e grive: remote site does not even have current version The upstream authors doesn't have this version available as tarball for download, I had to create the tarball myself. The main differences between the 0.1.1 stable version and this git commit is only about the construct system: I have made some suggestions and they included it in the repository after the 0.1.1 release. I don't know how to write a watch file for downloading a specific commit from a git repository. Is it possible? I just meant that you should use something like opts=dversionmangle (see uscan(1)) so that uscan would remove the +20120619git27g55c0f4e part before comparing the debian version with the upstream one. But if you're not going to package snapshot versions on a regular basis, maybe that's not necessary. - It seems like all the source files of Grive are released under the GPL-2, and not GPL-2+ (according to the license headers in those files). You should correct that in debian/copyright, and using the same formulation as in the license headers seems like a good idea. The license for the debian/* files is said to be GPL-2+, but in the license paragraph it refers to the GPL-3. I couldn't find Matchman Green's name in any of the source files; are you sure they're one of the copyright holders? Corrected the license issues (upstream to GPL-2, debian/* to GPL-3). Matchman Green was the original upstream author when I began to follow this project, but my e-mails and real contact with the project was made through the other author: Nestal Wan. I will contact upstream again and ask about this. Yeah, it seems best to discuss it with upstream. Regarding the GPL-3 for the packaging, since it's incompatible with the GPL-2, it would be much better if you agreed to GPL-2+ for debian/*; that way, the source package as a whole can be considered GPL-2. - debian/README.Debian should be debian/README.source, although I would argue it doesn't contain any useful information at the moment. You are right: it doesn't contain any useful information. I think it is a legacy file from the templates that I have written at the beginning of the times :-) - In debian/control, the Vcs-Git field is intended for the packaging, not the upstream repository; if you don't have a public git repository for the Debian packaging, remove that line. Ok, I have it on github, modified. The long description could be improved; please have a look at [1]. [1] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc Please run wrap-and-sort from the devscripts package to have the Build-Depends field wrapped and sorted (and use = 9 for debhelper). Do you mean =9 instead =9.0.0? If it is, modified in that way. That's what I meant, yes. - Why do you override the hardening-no-fortify-functions lintian warning? If you have a good reason to do so, you should explain it in a comment in debian/grive.lintian-overrides. I asked in debian-devel and in hardening-wrapper mailing lists about that. I had this warning and, after checking with hardeining-check I saw a possible problematic read unsafe call. I find it on the upstream sources and see that it is safe to link against read instead read_chk, because the always read the sizeof the reserved buffer. I will add a comment about that. Perfect. - Grive includes a test suite, but it isn't built nor run. I used their CMakeLists.txt without any patch or hack. I will ask them about it and study the viability of adding to the Debian package generation script and the way to do so. From a quick look at the CMakeLists.txt, it seems that cppunit needs to be installed in order for the test suite to be built (so I guess you should Build-Depend on libcppunit-dev). Not sure if it means a simple make test would run the test suite then; looks like you'd have to run ./unittest by hand. - In the grive(1) man page, you should end each item in the DESCRIPTION with punctuation. Mentioning that Grive is for GNU/Linux systems doesn't seem very useful; the person reading the man page is most likely doing so from such a system already. Grive shouldn't be italicized (.I) in the DESCRIPTION. Please consider removing the AUTHOR section (see man-pages(7) for details). Also, the REPORT BUGS section should be called BUGS, but I think it should be removed too, as Debian users should use the
Bug#679233: oggconvert: Conversion to WEBM creates video files that are reported as corrupt in Firefox 13 for Windows
Package: oggconvert Version: 0.3.3-1 Severity: normal Using advanced to create a WEBM version of a video to work with Firefox in HTML5 video tag, the video created works fine in Aurora or movie players on Debian Squeeze, but when the same WEBM file is servered to Windows clients using Windows 7 and Firefox 13 reports the it could not decode the media file. (Media resource: URL could not be decoded). Without detailed knowledge of video formats hard to be precise as to the precisely which software (if any) is at fault, however I figure that even if oggconvert is correct and this is a feature of Windows 7 the use case is common enough that people would want to know that the apparently working output may not be fit for purposes and needs to be tested. -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages oggconvert depends on: ii librsvg2-common 2.26.3-1 SAX-based renderer library for SVG ii python2.6.6-3+squeeze7 interactive high-level object-orie ii python-glade2 2.17.0-4 GTK+ bindings: Glade support ii python-gobject2.21.4+is.2.21.3-1 Python bindings for the GObject li ii python-gst0.100.10.19-1 generic media-playing framework (P ii python-gtk2 2.17.0-4 Python bindings for the GTK+ widge ii python-support1.0.10 automated rebuilding support for P Versions of packages oggconvert recommends: ii gstreamer0.10-plugins-bad 0.10.19-2+b2 GStreamer plugins from the bad s ii gstreamer0.10-plugins-base 0.10.30-1GStreamer plugins from the base ii gstreamer0.10-plugins-good 0.10.24-1GStreamer plugins from the good ii gstreamer0.10-plugins-ugly 0.10.15-1GStreamer plugins from the ugly oggconvert 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#679234: tagtool: mis-reports MP3 bitrate
Package: tagtool Version: 0.12.3-8.1 Severity: normal I'm browsing through some VBR MP3s encoded with lame --preset standard. tagtool is telling me they're 128kbps bit rate, but they are not. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (750, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-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 tagtool depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-33 ii libcairo2 1.12.2-1 ii libfontconfig1 2.9.0-6 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglade2-0 1:2.6.4-1 ii libglib2.0-02.32.3-1 ii libgtk2.0-0 2.24.10-1 ii libid3-3.8.3c2a 3.8.3-15 ii libogg0 1.3.0-4 ii libpango1.0-0 1.30.0-1 ii libstdc++6 4.7.0-8 ii libvorbis0a 1.3.2-1.3 ii libvorbisfile3 1.3.2-1.3 ii libxml2 2.8.0+dfsg1-4 ii zlib1g 1:1.2.7.dfsg-13 tagtool recommends no packages. tagtool 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#679160: gdm3: /usr/share/gdm/applications leftover on upgrade
Am 27.06.2012 10:42, schrieb Josselin Mouette: It was probably created by the system administrator. That would be me,... and I haven't... This mimeinfo.cache file is not created by the gdm3 package (or any other package). Well I guess then let's close the issue and I rm -rf /usr/share/gdm/applications manually, ok? Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
Package: wnpp Severity: normal I request an adopter for the animals package. After the personal vendetta by Ron Lee against me I'm no longer interested in wasting my time for the Debian project. The package itself is in good shape and easy to maintain. I still will do the upstream and will happly help a new maintainer to take this, including answering questions and be cooperative with futur problems. Hope all those little animals find a nice new home! The package description is: You think of an animal, and this package tries to guess it... when it's wrong, you teach it about your animal. . To be more flexible and help educational aspect this game does not contain an initial database. This also allows it to be used for non animals like guessing of tools or locations. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679236: O: ckport -- portability analysis and security checking tool
Package: wnpp Severity: normal Hereby I orphan the package ckport. The package as made hardy useful by Ron Lee's personal vendetta against me. While not directly related most packages provided data for this package (ckport database) will be removed or orphaned. As it is not fully useless I only orphan it not asking for RM. The package itself is in good shape. Upstream development is not affected by this. I hope the package will find a new home. I will gladly help a new maintainer as needed. The package description is: ckport is a tool to check already compiled binaries and libraries for porting and security problems. . It uses objdump to read the binaries and analyses calls and jumps to functions. . This package is architecture independent and can be used on non-host architecture binaries if an objdump tool for the target architecture is installed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667973: liferea: Custom date format doesn't work anymore
On 2012-06-27 12:49:48 +0200, Lars Windolf wrote: On Wed, Jun 27, 2012 at 12:55 AM, Vincent Lefevre vinc...@vinc17.net wrote: strptime() does parsing, not formatting. strftime() does formatting, and you should use it with a time format that can be specified by the user (not the hardcoded format like now). Sorry about the typo. Did you really think we do not use strftime() for formatting? How would we get any useful output with strptime()... It seems that you don't use strftime() with a time format specified by the user. Or how can it be configurable without the patch? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/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
