Bug#729660: ITP: xemacs21 -- highly customizable text editor
Hi Mark! I have seen that xemacs21 has been uploaded now, shouldn't we close this ITP now? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733320: RFA: empire - the war game of the century
On 12/28/2013 03:30 PM, Peter Palfrader wrote: > If nobody picks it up, I'll probably ask for removal in about a month. Please ask the Debian Games Team, I am pretty sure they will gladly adopt the package. I am CCing one of my sponsorees who is a member of the team and very active there. Maybe he wants to pick it up. I'd be happy to sponsor it in any case. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733512: Error updating mate-polkit-common
On 12/29/2013 05:13 PM, Frank McCormick wrote: >* What led up to the situation? > > Updating via apt-get > > >* What was the outcome of this action? > > dpkg error That happens when trying to update the package when using the MATE Debian repository at the same time and is hard to avoid since the MATE repositories contain "mate-polkit" while Debian has split the package into "mate-polkit" and "mate-polkit-common". We could maybe add a "Breaks" here, but mixing different repositories is problematic anyways. As a hotfix, you can run: apt-get -o Dpkg::Options::="--force-overwrite" -f install which will allow mate-polkit-common to overwrite files from the existing mate-polkit package installed through MATE's Debian repository. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733512: Error updating mate-polkit-common
(Note: Please keep the bug tracker in CC, I just bounced your mail) On 12/29/2013 05:29 PM, Franklin McCormick wrote: > Strange because AFAIK my MATE desktop came from the Debian repositories. This doesn't contract my previous statement at all. The current problem with MATE in Debian is that the whole upload is work-in-progress and many packages are yet missing. MATE consists of over 50 separate packages and it's not possible to upload all packages simultaneously to Debian since the FTP masters have to manually acknowledge every new package manually. As a result, users are dealing with having to mix packages from the official Debian archives with the packages from the MATE Debian repositories which can result in conflicts like the one you reported. These conflicts will always occur from time to time while MATE hasn't been fully uploaded to the Debian archives and users therefore have to deal with these, unfortunately. However, such problems are normal and to be expected when using Debian unstable which is why it's not recommended to use Debian unstable unless you can resolve these problems yourself. > A second problem I am having is two MATE packages which won't update: > > > Calculating upgrade... Done > The following packages have been kept back: > libmateweather-common libmatewnck-common > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. > frank@frank-debian:~$ > > This has been the situation for months. Yes, and the origin of this problem is the same as mentioned above. I am sorry for the breakage, but we can't avoid it at the moment. It might have been smarter to upload everything to experimental first, but we have started with unstable now and have to get this whole process done. Please be patient :). PS: I am considering closing or downgrading the severity of this bug report as we can't really address it at the moment and setting it to critical will just prevent the package from migrating to testing. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733512: Error updating mate-polkit-common
On 12/29/2013 06:05 PM, Sven Joachim wrote: > Breaks wouldn't help here, Replaces is what's needed. Considering that > over 2000 people have the packages from the MATE repositories > installed[1], adding that might be a good idea. Oh, yes, you're right. I completely forgot about Replaces. >> but mixing different repositories is problematic anyways. > > Indeed, if a newer version gets uploaded to the MATE repositories people > tracking it will likely experience the same problem again. This actually shouldn't happen as the same people who create the MATE Debian packages are also involved with the Debian packages and will perform all further updates to the packages in Debian only, leaving the MATE Debian packages in their old versions. I will talk to Stefano regarding this issue and ask him not to update the packages in MATE's repositories anymore. Thanks for the feedback everyone! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733721: lrzsz: packages source missing homepage and Vcs-* fields
Package: lrzsz Version: 0.12.21-7 Severity: minor Hi! The package is missing both the Homepage and Vcs-* fields in debian/control. The homepage is still available [1] even though it does not carry the latest version which is available in Debian. As for the Vcs-*, those are always very handy to have when backporting or forking the package or writing patches. It might also be a good idea to update the copyright file to the new format 1.0 when doing these updates. Thanks for the recent updates to lrzsz. Adrian > [1] https://ohse.de/uwe/software/lrzsz.html -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 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 lrzsz depends on: ii libc6 2.17-97 lrzsz recommends no packages. Versions of packages lrzsz suggests: ii minicom 2.6.2-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#733320: ITA: empire - the war game of the century
Hi! On 12/31/2013 10:53 AM, Markus Koschany wrote: > I'm quite happy with it but some changes/patches need more testing. So > we shouldn't rush things here. I think the first or second week of > January is a realistic date for a release. And now Cool! I'll look into it next year :). > Happy New Year und Guten Rutsch! The same to you, too. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#733721: lrzsz: packages source missing homepage and Vcs-* fields
On 12/31/2013 11:45 AM, Martin Godisch wrote: > Homepage field is already present. Oops, sorry, I completely missed that. Was probably thinking of minicom. > As for the Vcs fields all information > I can find point to tirka.ohse.de, which resolves to 192.168.2.3. Those fields are supposed to point to the repository where you as the maintainer keep the packaging sources, see here [1]. See also one of my packages, fs-uae [2], for example. Adrian > [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields > [2] http://packages.qa.debian.org/f/fs-uae.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730918: gir1.2-mate-wnck: arch-dependent file in "Multi-Arch: same" package
On 11/30/2013 06:07 PM, Jakub Wilk wrote: > gir1.2-mate-wnck is marked as "Multi-Arch: same", but the following file > is architecture-dependent: > > /usr/lib/girepository-1.0/Matewnck-1.0.typelib Isn't that actually the correct setting for a package whose dependencies have to be fulfilled with the *same* architecture? [1]. What would be the correct setting then? Adrian > [1] https://wiki.ubuntu.com/MultiarchSpec#Binary_package_control_fields -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730918: gir1.2-mate-wnck: arch-dependent file in "Multi-Arch: same" package
On 01/01/2014 11:02 PM, John Paul Adrian Glaubitz wrote: > On 11/30/2013 06:07 PM, Jakub Wilk wrote: >> gir1.2-mate-wnck is marked as "Multi-Arch: same", but the following file >> is architecture-dependent: >> >> /usr/lib/girepository-1.0/Matewnck-1.0.typelib > > Isn't that actually the correct setting for a package whose dependencies > have to be fulfilled with the *same* architecture? [1]. Ah, the path makes it not co-installable. It should be installed into /usr/lib/ and not just /usr/lib. Setting it to "MultiArch: same" is therefore correct, but the installation paths have to be adjusted in debian/gir1.2-mate-wnck.install. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679716: rpcbind: Please consider patch to enable socket-based activation for systemd
Hi Joachim! On 10/27/2013 11:26 PM, Joachim Breitner wrote: > you promised to do some testing and report back. What was the outcome? I > use NFS only occasionally and would benefit from socket activation here. I'm very sorry for the delay. I was just too busy with other things regarding Debian. It's on my TODO list now and I will try to test it this week. FWIW, according to systemd upstream, socket activation works fine for rpcbind in Fedora, but I haven't tested that myself. I think a first thing to test might be the latest version which is now in unstable together with systemd. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#679716: rpcbind: Please consider patch to enable socket-based activation for systemd
On 02/17/2014 11:30 PM, John Paul Adrian Glaubitz wrote: > I think a first thing to test might be the latest version which > is now in unstable together with systemd. I did some tests now with the result that by default rpcbind.service is actually properly loaded now which wasn't the case when I first made my experiments with systemd and rpcbind back when I reported this bug: === root@jessie32:~> systemctl status rpcbind.service rpcbind.service - LSB: RPC portmapper replacement Loaded: loaded (/etc/init.d/rpcbind) Active: active (running) since Tue 2014-02-18 00:04:18 CET; 7min ago Process: 417 ExecStart=/etc/init.d/rpcbind start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/rpcbind.service └─469 /sbin/rpcbind -w Feb 18 00:04:17 jessie32 systemd[1]: Starting LSB: RPC portmapper replacement... Feb 18 00:04:18 jessie32 systemd[1]: Started LSB: RPC portmapper replacement. root@jessie32:~> === However, the NFS mount (/home in my case) is not performed by default: === root@jessie32:~> systemctl status home.mount home.mount - /home Loaded: loaded (/etc/fstab) Active: inactive (dead) Where: /home What: home:/srv/home root@jessie32:~> === Which isn't really a problem when you add "comment=systemd.automount" to your NFS mounts in /etc/fstab: === root@jessie32:~> grep home /etc/fstab home:/srv/home /home nfs vers=3,nosuid,nodev,intr,tcp,comment=systemd.automount 0 0 root@jessie32:~> === This will define NFS mounts as automounts which are in the waiting state upon startup: === root@jessie32:~> systemctl status home.automount home.automount Loaded: loaded (/etc/fstab) Active: active (waiting) since Tue 2014-02-18 00:04:16 CET; 8min ago Where: /home Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. root@jessie32:~> === The moment you access the directory /home, home.mount is becoming active: === root@jessie32:/home> systemctl status home.mount home.mount - /home Loaded: loaded (/etc/fstab) Active: active (mounted) since Tue 2014-02-18 00:20:25 CET; 2s ago Where: /home What: home:/srv/home Process: 1864 ExecMount=/bin/mount home:/srv/home /home -t nfs -o vers=3,nosuid,nodev,intr,tcp,comment=systemd.automount (code=exited, status=0/SUCCESS) Feb 18 00:20:25 jessie32 systemd[1]: Mounting /home... Feb 18 00:20:25 jessie32 systemd[1]: Mounted /home. root@jessie32:/home> === So, it might not be important to have socket activation in rpcbind. At least in Debian, rpcbind is still started through LSB init scripts on systemd instead of a unit file or socket activation and probably because of the service "quotarpc.service" which is already wanted by the target "basic.target". As for the NFS mounts, it seems weird to me that those aren't mounted when the target "remote-fs.target" is reached: === root@jessie32:~> systemctl list-units --type=target UNIT LOAD ACTIVE SUBDESCRIPTION basic.target loaded active active Basic System cryptsetup.target loaded active active Encrypted Volumes getty.target loaded active active Login Prompts graphical.target loaded active active Graphical Interface local-fs-pre.target loaded active active Local File Systems (Pre) local-fs.target loaded active active Local File Systems multi-user.target loaded active active Multi-User System network-online.target loaded active active Network is Online paths.target loaded active active Paths printer.targetloaded active active Printer remote-fs.target loaded active active Remote File Systems sockets.targetloaded active active Sockets swap.target loaded active active Swap sysinit.targetloaded active active System Initialization syslog.target loaded active active Syslog timers.target loaded active active Timers LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB= The low-level unit activation state, values depend on unit type. 16 loaded units listed. Pass --all to
Bug#679716: rpcbind: Please consider patch to enable socket-based activation for systemd
On 02/18/2014 12:26 AM, John Paul Adrian Glaubitz wrote: > I have to investigate more as to what the reason for this is. Might > be related to the fact that I defined the /home mount as an automount > in systemd. Just a quick update. Removing the "automount" type from the NFS mount /home in my /etc/fstab makes the home.mount never work until I mount it manually: === root@jessie32:~> systemctl status home.mount home.mount - /home Loaded: loaded (/etc/fstab) Active: inactive (dead) Where: /home What: home:/srv/home root@jessie32:~> systemctl status home.automount home.automount Loaded: loaded Active: inactive (dead) Where: /home root@jessie32:~> cd /home root@jessie32:/home> ls root@jessie32:/home> mount -a root@jessie32:/home> systemctl status home.automount home.automount Loaded: loaded Active: inactive (dead) Where: /home root@jessie32:/home> systemctl status home.mount home.mount - /home Loaded: loaded (/etc/fstab) Active: active (mounted) since Tue 2014-02-18 00:30:55 CET; 7s ago Where: /home What: home:/srv/home root@jessie32:/home> === So, we might need to file a bug against systemd or the NFS package(s) here to make sure NFS mounts in /etc/fstab are actually mounted by default. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: systemd: NFS shares are not automatically mounted during boot
Hi Michael! Thanks for your quick reply! On Fri, Feb 21, 2014 at 11:04:46PM +0100, Michael Biebl wrote: > Please include more details about your network setup and the nfs > configuration. > The nfs shares should be mounted via the nfs ifupdown hooks which worked > successfully last time I tested it. The machines are all connected through 1 GBit ethernet, however the NFS servers are located in a different virtual network (VLAN) and subnet. All Linux clients have unfiltered access to the servers. The fstab entry for the NFS share currently looks like this: home:/srv/home /home nfs vers=3,nosuid,nodev,intr,tcp,comment=systemd.automount 0 0 The network configuration is static, not using network manager (it has been disabled, in fact) and looks like this on an example client: # The loop back interface auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 160.xx.xx.xx netmask 255.255.255.0 gateway 160.xx.xx.xx where I have replaced some of the numbers with "x" in this mail. The DNS servers are manually configured, too. Is there anything else you were thinking of? Thanks! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: Bug#739721: systemd: NFS shares are not automatically mounted during boot
On Fri, Feb 21, 2014 at 11:30:24PM +0100, Michael Biebl wrote: > > # The loop back interface > > auto lo > > iface lo inet loopback > > > > auto eth0 > > Does changing to "allow-hotplug eth0" make a difference? Unfortunately, no. The behavior is still the same. > > iface eth0 inet static > > address 160.xx.xx.xx > > netmask 255.255.255.0 > > gateway 160.xx.xx.xx > > > > where I have replaced some of the numbers with "x" in this mail. The > > DNS servers are manually configured, too. > > > > Is there anything else you were thinking of? > > Due to various reasons, remote mounts are currently handled differently > on Debian then on Fedora, so you can't compare those two. Yes, that's what I was thinking as well. However, I could actually reproduce the problem with Fedora 20 and Rawhide as well before I was reporting the bug here, so I assumed the issue on Fedora was the same. I also talked with Lennart on this regard and he said it's an issue with nfs-utils which wasn't ordering the dependencies correctly, but I wasn't able to track down the origin up the bug yet. All I know is that it happened on Fedora as well and I need to perform a fresh installation of Fedora and test without updates. > As said, NFS shares are mounted via the ifupdown hook, so you might > check /etc/network/if-up.d/mountnfs and add some debug statements in > there to see what's going wrong. That's a good starter, thanks a lot for the heads-up! I'll see if I can find more. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739721: [Pkg-systemd-maintainers] Bug#739721: Bug#739721: systemd: NFS shares are not automatically mounted during boot
severity 739721 normal thanks On 02/22/2014 12:10 AM, Michael Biebl wrote: > Just tried again (with two VMs): > The NFS server being a wheezy system, the client system is an up-to-date > SID system. Worked like a charm. Ok, it seems to be a local configuration issue then. I will try to pin point the problem and hopefully post the reason and solution soon. Meanwhile, I will lower the severity. Thanks for your input. Highly appreciated! -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#739796: fs-uae: please consider packaging new version available (2.4.0)
Hi Ernesto! On 02/22/2014 03:14 PM, Ernesto Domato wrote: > Just what the subject says. There's a new version and it would very nice to be > on Debian officially. Thanks for letting me know! However please be aware that such bug reports about new versions are usually not required as the Debian PTS normally informs me about new versions [1]. It just seems that Frode changed the locations of the upstream sources and therefore the PTS website for fs-uae didn't display the new version. I will verify that and also package the new version in the upcoming days. Cheers, Adrian > [1] http://packages.qa.debian.org/f/fs-uae.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739796: fs-uae: please consider packaging new version available (2.4.0)
On 02/22/2014 04:06 PM, Ernesto Domato wrote: > Yeah, I know that the PTS informs if you have the correct watch file. > But as I didn't see in the PTS the information about a new version, I > decided to fill a wishlist report about the new version just in case. Yes, the watch file wasn't actually working, so you did the right job of informing me :). You just don't need to go through the hassle to file a bug report, sending an email would have been fine too ;). Anyway, I will look into packaging the new version the upcoming days. Importing the new version is actually very simple, but I have to check the source tarball for any problematic files which would render the package non-free. I had to remove a couple of files for the version 2.2.3. But I notified Frode about these issues and he promised me to get rid of those files, they weren't required anyway. So it might be a quick and painless upload. > Thanks for all and sorry to bother you with this. Nah, don't worry. Again, thanks for letting me know :). Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737013: MATE packaging is currently work in progress
On 02/23/2014 07:16 AM, Vagrant Cascadian wrote: > If jessie were released today, would this package really be useful? No, it wouldn't, you're right. But MATE consists of more than just one package. Granted, we should have probably uploaded to experimental first, but we have opted for unstable now and have to live with that. Blocking just one package with an RC bug isn't really helpful either, we'd have to block all MATE-related packages if we really want to be sure that nothing breaks, wouldn't we? > If it's not ready for release, it shouldn't land in testing... and an RC bug > would be an appropriate way to keep it out until it's actually ready... True. But since we know Jessie isn't going to be frozen until November 5th [1], I don't see any reason to kick off any discussions about the current usability of any packages in testing or unstable yet. We're right in the middle of the development process of the upcoming Debian Jessie release and things are expected to break. And bug reports like these just distract the maintainers from doing their job. If you want something stable, use Debian stable. I know that Debian testing comes with a certain level of QA, but it's still not guaranteed to be as stable as the real Debian stable. The MATE packaging efforts have gained lots of momentum recently and many others have joined the team to help us with great results. MATE in Debian has made great progress due to these people investing lots of their free time into it and I am very happy to have these guys! So, instead of complaining in bug reports, I'd rather see people joining and helping us to mitigate these issues as quickly as possible. Adrian > [1] https://lists.debian.org/debian-devel-announce/2013/10/msg4.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739796: fs-uae: please consider packaging new version available (2.4.0)
Hi Ernesto! Some updates on the packaging situation for fs-uae 2.4.0. On Sat, Feb 22, 2014 at 04:38:47PM +0100, John Paul Adrian Glaubitz wrote: > Yes, the watch file wasn't actually working, so you did the right job of > informing me :). You just don't need to go through the hassle to file > a bug report, sending an email would have been fine too ;). It turns out that the watch file is actually working. The watch mechanism just hadn't checked yet for a new upstream version. The PTS is now showing 2.4.0 as the latest upstream version available [1]. > Anyway, I will look into packaging the new version the upcoming days. > Importing the new version is actually very simple, but I have to check > the source tarball for any problematic files which would render the > package non-free. I had a first look at the new upstream version now and it looks like Frode has split up fs-uae, fs-uae-launcher and the new fs-uae-arcade into separate source packages, so I need to make some changes in my packaging. I am currently thinking whether I either should merge the source tarballs back into one source tarball or I actually build fs-uae-launcher and fs-uae-arcade from separate source packages. In both cases, fs-uae will have to go through NEW again, so some additional delay has to be anticipated. Cheers, Adrian > [1] http://packages.qa.debian.org/f/fs-uae.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568303: can-utils Debian package
Hello Alexander! On Mon, Feb 24, 2014 at 10:44:48AM +0400, Alexander GQ Gerasiov wrote: > Thu, 20 Feb 2014 17:30:05 +0400 > Alexander Gerasiov wrote: > > > Sorry guys. I'm totally busy with other tasks last month :-(. As I > > remember your package is quite ready for upload, so I'll do it > > tomorrow (without my changes, just add myself as an uploader if you > > don't mind). Ok? > > As Uwe is worried about correctness I'd like to mention, that I did not > use his package as the base for last upload, but incorporated some of > lines he wrote into my package. That doesn't sound plausible to me given the fact that you imported his debian/rules file and commented out his overrride_dh_* statements [1]. If you had incorporated some of his changes, you'd just have use the default rules file from the template. You should also have asked yourself why Uwe had added those overrides and not just silently commented them out. If someone adds extra overrides, he usually has very good reasons. You should have asked Uwe about that. The package currently also includes the debian/README.source template and git-related files (.gitignore, gbp.conf). As someone who is sponsoring very often and has some experience with reviewing packages now, can-utils wouldn't have passed my quality requirements in its current state. I can therefore fully understand that Uwe is upset and I think it would be best if you asked the FTP Masters to have the package set to REJECT in NEW and get into touch with Uwe to coordinate improving the package. > Package is in new queue right now and will be soon available in > unstable repository. It's actually been set to not be reviewed before February 28th to be able to discuss this matter first. Cheers, Adrian > [1] > http://anonscm.debian.org/gitweb/?p=collab-maint/can-utils.git;a=blob;f=debian/rules;h=cfd19c845d1fa085679931a9817e4cfd8b23c481;hb=9f50da4df75f5ea00620f94f01cf1205ef16fdc5 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568303: can-utils Debian package
On 02/24/2014 09:25 AM, Uwe Kleine-König wrote: >> You should also have asked yourself why Uwe had added those overrides >> and not just silently commented them out. If someone adds extra >> overrides, he usually has very good reasons. You should have asked Uwe >> about that. > This is wrong, the overrides are not from me. d/rules seems to be > Alexander's (well, or Joey Hess' and Craig Small's) work. Ok, then I misunderstood your concerns. I apologize to Alexander regarding this and take everything back ;). >>> Package is in new queue right now and will be soon available in >>> unstable repository. >> >> It's actually been set to not be reviewed before February 28th to be >> able to discuss this matter first. > I think the best will be when Alexander and I discuss the issue in > private. I don't see a need to pull that conflict into public. I agree. Still, you should post the results here. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568303: can-utils Debian package
Hi Alexander! On 02/24/2014 09:59 AM, Alexander GQ Gerasiov wrote: > Unfortunately I missed to fixup pair of changes when build package, > that's why second revision was uploaded right after first. > You are talking about revision -1 which really had some issues. > Please comment on the last version available. Sure, I can have a look at the second revision. But you could also just asked the FTP team to set the package on REJECT to be able to sort out the issues, then do a clean upload. I usually try to keep a clean package history. >> If you had incorporated some of his changes, you'd just have use the >> default rules file from the template. >> >> You should also have asked yourself why Uwe had added those overrides >> and not just silently commented them out. If someone adds extra >> overrides, he usually has very good reasons. You should have asked Uwe >> about that. > I think you did not get clean with this or that's Uwe who mislead you. Yep. I misunderstood Uwe. From his first comments it appeared to me that exactly that had happened. So, I apologize to you Alexander and take my statements back. > Those commented out overrides were left in rules file from my previous > experiments, and not needed anymore. And they have nothing with Uwe's > package, I believe. Alright, thanks for the explanation. > I can count all changes I took from his work: > Arch: linux-any (totally forget that SocketCAN is Linux specific) > Several strings in description field. > > And that's all. =\ Ok, it appeared to me that the situation was the complete opposite of that, i.e. you took Uwe's work and put your name onto it. Thanks for the clarification. >> >> The package currently also includes the debian/README.source template >> and git-related files (.gitignore, gbp.conf). > Template README.source was also removed in -2 revision. Good! > As for .gitignore and gbp.conf, this package is maintained under git > and git-buildpackage and I see no reason, why thees files should not be > included in debian/ True. I am using gbp as well and I completely forgot about that. The files shouldn't pop up in the actual package. > I think some gbp related info should goes to README.source. One day > I'll write it. Good idea! >> >> As someone who is sponsoring very often and has some experience with >> reviewing packages now, can-utils wouldn't have passed my quality >> requirements in its current state. > I could not agree with you if we speak about revision -2. Well, unless you have fixed the copyright issues that Uwe has mentioned, you will get a REJECT with absolute certainty. Did you fix the copyright information? Are the sources from Volkswagen actually covered by a free license? > Conclusion: > Looks like Uwe decided that I modified his package, removed him from > Maintainer and broke all around. And he started offense instead of > discussion. Well, you see what poor communication leads to. When you decide to let him join as a comaintainer, you should communicate such changes, especially before doing uploads. >>> Package is in new queue right now and will be soon available in >>> unstable repository. >> >> It's actually been set to not be reviewed before February 28th to be >> able to discuss this matter first. > Well, I remember time when packages were held in new for 2-3 months =) They still are. Depends on the package, Look at zfs-utils which has been in NEW for 6 months now. Obviously no one dares to touch it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740106: libraw: FTBFS on 32-bit platforms: symbols not quite as expected
Hi! When fixing the symbols files, please also have a look at the build logs for all the Debian ports which are affected as well [1]. Since the build logs all contain the necessary diffs for the symbols files, you have all the information you need to fix them. Here's a bug report which shows the respective problem on m68k for reference [2]. Thanks! Adrian > [1] http://buildd.debian-ports.org/status/package.php?p=libraw&suite=sid > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726969 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681079: sane-backends: Build-Depend on libtiff5-dev
close 681079 thanks The transition to tiff5 has begun and sane-backends, like many other packages, has successfully rebuilt against tiff5. Furthermore, sane-backends has been adopted by Mark Buda and updated to the latest upstream release. Therefore closing this bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733928: libsane: Canon Lide 110 lineart quality degraded from 1.0.22-7.4 to 1.0.23-3+b1
Hi Holger! I sponsored version 1.0.24-1 of sane-backends today (together with an additional NMU to fix an FTBFS). Please have look whether this fixes your problem. Also, issues like these should rather be reported upstream to get a quicker response. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725338: libsane: new upstream release (1.0.24) available
close 725338 thanks sane-backends 1.0.24-1.1 is now available in unstable, therefore closing. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64
close 725435 thanks Co-installation of libsane for different architectures works now, I just verified it. I am therefore closing this bug report. Issues which are a result of a broken installation or incorrect configuration should not be reported as bugs. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713971: libsane:i386 on amd64 stops officejet from scanning
Hello Wolfgang! sane-backends 1.0.24-1.1 was uploaded to unstable today. It should fully support MultiArch now. Please give it a try once you have updated and report back, so we know whether we can close this bug or need to have another look at it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#632726: libsane-common should probably be Arch: all
close 632726 thanks This has been fixed with the latest version 1.0.24-1.1 now, and sane-backends has been converted to MultiArch now, with some remaining issues. Therefore closing this bug report. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704167: libsane: SCX-3400 is not recognised out of the box
close 704167 thanks sane-backends has been updated to 1.0.24-1.1 today which includes all necessary changes to support the Samsung SCX-3400 scanner. I am therefore closing this bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#370483: libsane: scanner HP5300C not working
close 370483 thanks > according to the SANE website [1], the HP Scanjet 5300C is now fully > supported by the backends. Have you tested the latest version of SANE > with your scanner? No more additional feedback for almost a year. And since this scanner is reported to have the support status "Complete", I am closing this bug report now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724263: libsane: ScanJet 3300c (niash) - Device Busy
close 724263 thanks > I've done some additional research, and it seems to be a matter of > permissions: using the scanner under the root account (both with > scanimage and under GUI programs) works like a charm. This is certainly not a bug but a configuration issue on your side. Please make sure your primary user is member of the group "scanner" and you haven't messed up your udev rules which set the proper permissions for the device file of the scanner in /dev properly. The device files of your scanner should be visible below /dev/bus/usb// where and is the tuple retrieved from scanimage -L or sane-find-scanner. "getfacl *" should return "group:scanner:rw-" for at least one of the files in this directory. If that doesn't help and you can really isolate this as a bug in SANE, you may re-open this bug report. Closing for now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734103: scanimage: *** Error in `scanimage': double free or corruption (!prev): 0xb8658690 ***
tags 734103 +moreinfo thanks This is too little information to work with. Please provide more information and a detailed backtrace, if possible. Otherwise this bug report won't get much further. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597922: sane: SANE does not work anymore with Epson Perfection 1650. Used to work perfectly.
close 597922 thanks Since Debian unstable has version 1.0.24-1.1 which was released after this fix was committed upstream, it should be safe to close this bug report. Please feel free to re-open if the issue should arise again. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683524: sane-utils: Scan function of Epson Stylus DX4250 not working under wheezy
Hello! The DX-42xx series is marked as supported on the SANE upstream website [1], so basic scanning should work. The DX-4250 has the same USB IDs as the DX-4250, so it should be the same device. sane-backends 1.0.24-1.1 was uploaded to unstable today. Please update to this version and report back. If the scanner can be reported to work then, we can close this bug report. If everything else fails, you can still try the proprietary driver offered by EPSON [2] (search for "DX4200"). Adrian > [1] http://www.sane-project.org/sane-mfgs.html#Z-EPSON > [2] http://download.ebz.epson.net/dsc/search/01/search/searchModuleFromResult -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730539: libsane: HP psc 750 no longer being recognized
tags 730539 +moreinfo severity 730539 normal thanks You need to install the package "libsane-hpaio" which will install the driver and add the necessary device information as /etc/sane.d/dll.d/hplip. Please verify that this works and report back. If it does, I'll be able to close this bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#407074: libsane: incorrect "scanimage: no SANE devices found" for HP Scanjet 6200C
close 407074 thanks This scanner is marked upstream as "Complete", e.g. fully supported and there should therefore no issues using this scanner with the current version of sane-backends. "avision" is not the correct backend for this scanner, but "hp", see [1]. Please check your sane configuration in /etc/sane.d/ and restore it to the default configuration if you can't get it working. Make sure the USB IDs of your scanner are matched to the "hp" backend and not the "avision" backend. I am therefore closing this bug report. If you should continue to have issues with this scanner in the future, please feel free to re-open this bug report. Adrian > [1] http://www.sane-project.org/sane-mfgs.html#Z-HEWLETT-PACKARD -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64
On 01/19/2014 10:23 AM, Sandro Tosi wrote: > (and you tell the reportbug maintainer?) What does this have to do with the maintainer of reportbug? reportbug is just the utility used to report canonical bug reports. > don't judge too quick: the > fact that there was an error during installation doesn't mean there > was anything wrong on my part, only a series of situations which lead > there without being able to replicate it. think before you preach. Several people were unable to reproduce it and you couldn't provide any more useful information either. It's definitely a bug when it occurs during a fresh installation and might be considered a bug if it happens for certain dist-upgrades. Both don't seem to be the case. If you are able to reliably reproduce the problem, please feel free to re-open this bug report. But please don't keep bug reports open without more necessary information when no one can reproduce the problem. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64
On 01/19/2014 11:42 AM, Sandro Tosi wrote: >>> don't judge too quick: the >>> fact that there was an error during installation doesn't mean there >>> was anything wrong on my part, only a series of situations which lead >>> there without being able to replicate it. think before you preach. >> >> Several people were unable to reproduce it and you couldn't provide >> any more useful information either. > > like what, reproduce a dist-upgrade? You could set up a virtual machine and perform a clean installation trying to reproduce the issues with the steps you have taken. Or, you can uninstall all SANE packages, and re-install them again and see if the problem shows up again. In any case, there should be something reproducible. >> It's definitely a bug when it occurs during a fresh installation and >> might be considered a bug if it happens for certain dist-upgrades. >> Both don't seem to be the case. > > it is a bug even if it occurs in a weird upgrade path, which is > near-to-impossibile to reproduce, but it can be decided to be > "ignored" that given the time required to have a clue about how to > reproduce it. No. If you mess around with your installation resulting in the packages failing to upgrade or behaving unexpectedly as a result, you can't file a bug and blame the authors or maintainers of the software. It's simply impossible to account for all upgrade paths or local modifications of a package, so it can't be considered a bug. It's a bug when a clean installation fails or when a dist-upgrade from the previous stable release isn't working. >> If you are able to reliably reproduce the problem, please feel free >> to re-open this bug report. > > if you know a way to "reliably reproduce" the upgrade path that > generated the problem, please tell. Well, like stated above. Try a fresh installation or a dist-upgrade from oldstable to stable or stable to unstable. If either of that fails, I'm happy to re-open this bug report. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726253: libsane: Add Canon MP230 support
Hello Oliver! sane-backends 1.0.24-1.1 which contains your patch was uploaded to unstable yesterday. The scanner is also reported as "Complete" on the SANE website [1]. Could you upgrade your sane-backends to the latest version in unstable and verify that your scanner is now fully working so we can close this bug report? Adrian > [1] http://www.sane-project.org/sane-mfgs.html#Z-CANON -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726253: libsane: Add Canon MP230 support
close 726253 thanks On 01/19/2014 12:57 PM, Oliver Winker wrote: > Just updated [1] and tested: and it works now ;)! Woohoo, thanks for the quick reply. I'm very happy to be able to close this bug report now. Happy scanning! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64
On 01/19/2014 01:31 PM, Sandro Tosi wrote: > I "mess around with installation" and "blame" someone? I suggest > you to think best before writing such thing - you don't deserve my > time, so I won't reply any further. There is no need to be huffy. Again, if you want someone to look at the problem you are experiencing, try to provide more information which will help to reproduce the problem. You are a Debian Developer yourself, so you should have dealt with bug reports before and you should understand that it's next to impossible to debug a problem when several people cannot reproduce it. > PS: how would a fresh installation resolve the problem I have? in no > way, so your provided solution has no technical value whatsoever - > well done... The problem arising in a fresh installation would justify reporting this as a bug and so would a dist-upgrade on a clean system. However, when such a problem occurs on a very old installation and, on top of that, isn't reproducible by anyone else, it clearly doesn't justify to file a bug report. Again, if you want people to debug your problem, provide some more useful information on how to reproduce the issue. All the information you have provided so far isn't helpful at all trying to resolve the issue. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713971: libsane:i386 on amd64 stops officejet from scanning
close 713971 thanks On 01/19/2014 01:31 PM, Wolfgang Schnitker wrote: > It is possible to scan now with multiarch and libsane:i386 installed. Great! > This will solve the problem, that using SANE and googleearth debian > amd64 package at the same time on an amd64-system was not possible, > because googleearth 64bit is using i386 runtime environment with > ia32libs as recommended package. This includes libsane:i386 and stops HP > OfficeJet from working (and Probably other combinations too, i.e. SKYPE) Ah, the Google Earth package shouldn't actually recommend "ia32libs" anymore since this package has become obsolete with the introduction of MultiArch. Which Google Earth packaging are you using? I have been the sponsor of the googleearth-package [1] in Debian and if it actually still recommends "ia32libs", we should probably file a bug. Closing this bug report nontheless, thanks for testing! And feel free to re-open in case the problem comes back. Adrian > [1] http://packages.qa.debian.org/g/googleearth-package.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725435: trying to overwrite shared '/etc/sane.d/gt68xx.conf', which is different from other instances of package libsane:amd64
On 01/19/2014 03:35 PM, Claus Fischer wrote: > If you've changed something to make co-installation work, > it's probably best to close the bug and wait if it re-appears. libsane has already been converted for MultiArch, hence such issues should no longer arise. If they do, it's ok to file another bug report or re-open this one, but leaving the bug report alone forever without giving further feedback isn't helping the cause, it's just spamming the bug tracker. We don't win anything if we leave this open forever while no one is able to reproduce it reliably. Again, if you can show me how to trigger this issue, I will be very happy to re-open the bug and have a look at the issue. I am aware of the fact that the SANE package still needs some work and I several points left on my TODO list which I will hopefully get done together with Mark, one of them driving the package split for binary-only, all and MultiArch packages further. There are still some redundancies and duplicate files. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#683524: sane-utils: Scan function of Epson Stylus DX4250 not working under wheezy
close 683524 thanks On 01/19/2014 09:26 PM, Sébastien Boetsch wrote: > But when Wheezy has been tagged stable, I reinstalled it and since this > time, i did no more use the workaround because the scanner functions of > the DX4250 worked well right out of the box Very glad to hear that. Thank you very much for your feedback :). > So you can close this bug entry. Will do now. > Thanks for your job and your time (and sorry to have forgot this bug). Sure, my pleasure and thank you very much for your bug report. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730539: libsane: HP psc 750 no longer being recognized
On 01/21/2014 07:34 AM, Lawrence Woodman wrote: > libsane-hpaio was already installed, so I tried removing it > and reinstalling, but this made no difference: the scanner > is still not being seen. I assume the scanner works properly in the same configuration on Windows? Just to be sure it's not a hardware issue. Then, could you please attach the files /etc/sane.d/dll.conf and /etc/sane.d/dll.conf.d/hplip? And provide the output of: - sane-find-scanner - scanimage -L - lsusb Cheers, Adrian PS: Please keep the bug tracker in CC! -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727913: reuse this issue for the more general solution to use dh-autoreconf
Hi Matthias! On 01/21/2014 12:41 PM, Matthias Klose wrote: > Reusing this report for the more general solution to also update > the libtool.m4 and/or aclocal.m4 files, needed for the port mentioned > in bug #726404. Thanks for the additional information. I am still waiting for Torsten to release a new upstream version. It should be coming within the next weeks, I will then be making the necessary changes for arm64 support. Is there an arm64 porterbox available for testing? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730539: libsane: HP psc 750 no longer being recognized
On 01/22/2014 05:57 PM, Lawrence Woodman wrote: > So as scanimage -L can see the scanner it looks like a user rights problem, > but I'm not sure > where to look to resolve that. Ok, this is actually something. Can you try running a test scan as root? Just run "xsane" or "scanimage" as root and try to scan something. >From there, we can continue figuring out what's wrong with the permissions. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator
Hello Anthony! On 01/25/2014 08:55 AM, Anthony Wong wrote: > May I know what is the progress of this ITP? Sorry for the late reply! I was on a trip through South America the past three weeks and had very limited internet access. Anyway, ppsspp is still on my TODO list. I have a working package for an older version [1], but I didn't go ahead and uploaded it back then since there were still some issues with the package. I will look back into it the next weeks. I am currently busy working through everything that has piled up the past three weeks. Adrian > [1] https://github.com/glaubitz/ppsspp-debian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#239816: libparted Atari partition table support
Hi! While chatting with someone who was trying to install Linux onto his ATARI Falcon 060, we stumbled into the task getting the hard disk partitioned for the ATARI Falcon to be used. Since I already successfully created an Amiga partition table with the help of gparted and libparted, I thought it would be as easy as that for ATARI partitions, too. Unfortunately, libparted currently doesn't support ATARI partition tables. However, there is a long-standing bug report open which contains the necessary patches for libparted to support that [1]. Since we're in the process of reviving the m68k port of Debian, I guess we should also put efforts into getting this patch finally to upstream so people can prepare their ATARI hard disks on their Linux PCs before using them in the ATARI or change partitions once Linux is running on their ATARIs. Adrian > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239816 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#239816: libparted Atari partition table support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/14/2013 06:12 PM, Phillip Susi wrote: > On 12/14/2013 02:26 AM, Thorsten Glaser wrote: >> The ST, maybe (except for the only-in-museums part), but the TT >> and Falcon run Debian GNU/Linux just finely. > >> Linux ara5.mirbsd.org 3.11-2-m68k #1 Debian 3.11.7-1 >> (2013-11-09) m68k GNU/Linux > >> (Hm, should dist-upgrade and reboot that box, too.) > > I'm still not following. You are talking about a 30 year old > computer running at like 16 MHz with maybe 512k of ram? No, rather a Motorola 68060 running at 100 MHz with 512 MB of RAM [1]. Adrian > [1] http://www.powerphenix.com/ct60/english/overview.htm - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSrJSkAAoJEHQmOzf1tfkTwqMQAL66NzlsEWG3zmXA8C+1FpH4 OzgnyCT9hQzt+sx81a1dODJmJZRS+Rlwe5aG9gUSevuaCksitzzFM24JLOeB6fQg iW6RAYlhlOgjWjj3TR96ADu6TGNAW0D0JMvDfy5PYiDQqTHMBCM9OUWHa/KiWaIM yUTx0KoxyEPs3iK9q5O4qh1Q37LAgh8xYtpbRILil8ga3rOVg3Gucv6tZjNNFUls WuvENs+65IqrIvkCLOKKJNyydRmAfBmRcJ8spBPRxl+B1ARdvQSAcOyAJOcwtnYD FhvU9HCM/IwDgx538TiwAqhnpx/z5HGgUK7MyOlFJ00BL+62v61/joczkdzUl2sD kqqTSZVP05jO/f8GZmH8eJ9zy5JwcM1fg1VT+VygLzrBLNk7+RsiB6GdN9lNemHd 3MrHZjjpcFweAvog5UFxgErhK3/FAVtv8O1eQ6Fz1bajWm0uMYFtbUo9GZsROi+p B8uzoNwNSRnG2taBZfILtNuSQnkcLfrcJpT7DMpsCJrLYQmMJY+vixS725FevQ7s 1g+g7s0Jo4d91G2RzZujNXj5i+08XQpuoFajMZpsKUald1K0kzSXKNmdwov2YW05 yFLBFyBKEnrMT5VEP/+Ed+7pJgluGSMaX8odYJQWpSYxedeyJModgxWBLBNl21oN 65W87kyDGwqu8PUULBxS =q8fX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732159: Should this package be removed?
On 12/14/2013 11:07 PM, Reinhard Tartler wrote: > On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff wrote: >> Package: mplayer >> Severity: serious >> >> Should this package be removed? If so, please reassign to ftp.debian.org >> >> - Last upload nearly two years ago >> - FTBFS for a long time >> - Incompatible with current libav >> - Alternatives exist (mplayer2, mpv) Well, to be honest, I think the problem is actually libav, not mplayer. Most users prefer the original ffmpeg over libav from my own experience. And there are new upstream releases of mplayer which are actually more frequent and active than mplayer2: - mplayer: current stable release 1.1.1, released May 6th, 2013 - mplayer2: current stable release 2.0, released: March 24th, 2011 Even the latest git commit for mplayer2 is older than the current stable release of mplayer. The latter seems much more active to me. So, what I'd rather like to see is that we get a proper ffmpeg back in Debian again which would also allow to update mplayer to the current upstream version. There is even an RFP for that [1]. But I guess this is not going to happen. I'm still a bit sad that the split among the ffmpeg people happened. Adrian > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#239816: bug#16134: libparted Atari partition table support
On 12/16/2013 07:18 PM, Phillip Susi wrote: > Would you be able to write a test case so make check verifies it is > working? What kind of checks does libparted perform during build to verify it's doing what it's supposed to do. Is there any documentation or do I need to dig into the code? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#239816: bug#16134: libparted Atari partition table support
On 12/16/2013 08:31 PM, Stefan Niestegge wrote: > Am 16.12.2013 19:18, schrieb Phillip Susi: >> Would you be able to write a test case so make check verifies it is >> working? >> > > If i can help in any way, please explain what to do. > (I am the one with the Falcon 060). I'm pretty sure that Philipp was talking about tests which are run during build time to check the code, hence the name "make check". But, of course, you could apply the patch to gparted, rebuild it, then create a partition table on a hard disk and hook it up to your ATARI and see if it's being recognized. If you don't know how to build packages, I can build a patched gparted for you and upload the packages into my old Ubuntu PPA, for example. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#651965: xserver-xorg-video-nouveau: corrupt glyphs and icons in gnome-shell on NV34 [GeForce FX 5200]
Hi Daniel! > I'm seeing corrupted text glyphs and icons in the latest gnome-shell > (from either unstable or experimental). I believe it's a problem with > the nouveau driver (maybe specific to this particular model of card?) I have been playing around with an old PowerMac G5 which I borrowed as a PPC porterbox and it happens to have this particular video adapter as well. Initially, I installed Debian Wheezy onto the Mac and ran into many rendering issues with nouveau and gnome-shell and the latter happened to crash very often. However, upgrading everything to unstable resolved both the rendering issues as well as the gnome-shell crashes. I think Mesa upstream fixed many nouveau issues in the newer Mesa releases, so you should definitely give that a try in case you still have this machine around, so we might be able to close this bug ;). Additionally, it would be interesting to know whether 3D hardware acceleration works on your laptop after upgrading to the Mesa version in experimental (9.2.1-1). I figured out that after upgrading to 9.2.1-1, Mesa could no longer load the nouveau_dri.so module which I could resolve by downgrading libgl1-mesa-dri to 9.1.7-1 again (I didn't have to downgrade the rest of Mesa). Cheers across the big lake ;) Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724576: libgl1-mesa-glx: libGL error: failed to load driver: nouveau
Hi Thomas! > error: XDG_RUNTIME_DIR not set in the environment. > libGL error: failed to load driver: nouveau > libGL error: Try again with LIBGL_DEBUG=verbose for more details. > error: XDG_RUNTIME_DIR not set in the environment. > Versions of packages xserver-xorg recommends: > ii libgl1-mesa-dri 9.2-1 I am seeing the exact same issue on an Apple PowerMac G5 (A1047) with has a GeForce FX 5200 Ultra (NV34) video adpater. This problem was present only with the Mesa DRI version from experimental (9.2.1-1). Downgrading just the DRI package libgl1-mesa-dri from 9.2.1-1 to 9.1.7-1 resolved the issue for me. I'm attaching the output of glxinfo for both versions of libgl1-mesa-dri with LIBGL_DEBUG=verbose set if that's of any help for the mesa maintainers. I have also reported this issue upstream [1], even though I don't think this is an upstream issue but with the particular Debian package. Maybe rebuilding fixes the issue? Could you try downgrading just this package and report back? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 libGL: OpenDriver: trying /usr/lib/powerpc-linux-gnu/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib/powerpc-linux-gnu/dri/nouveau_dri.so libGL: Can't open configuration file /home/glaubitz/.drirc: No such file or directory. libGL: Can't open configuration file /home/glaubitz/.drirc: No such file or directory. libGL: Can't open configuration file /home/glaubitz/.drirc: No such file or directory. name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync OpenGL vendor string: nouveau OpenGL renderer string: Gallium 0.4 on NV34 OpenGL version string: 1.5 Mesa 9.1.7 OpenGL extensions: GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_ES2_compatibility, GL_ARB_copy_buffer, GL_ARB_debug_output, GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_get_program_binary, GL_ARB_half_float_pixel, GL_ARB_half_float_vertex, GL_ARB_internalformat_query, GL_ARB_invalidate_subdata, GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_occlusion_query2, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sampler_objects, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_e
Bug#724576: libgl1-mesa-glx: libGL error: failed to load driver: nouveau
Btw, Sven, >> That might be http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722930. >> Have you looked at that bug yet? > > Could be the same bug. At least > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722930#15 this is the > same error. I do not think that Thomas' problem is related to the bug report you are mentioning here. The problem Thomas (and I) see is that Mesa is unable to load the DRI module for nouveau even though the module is actually present. I might just try rebuilding Mesa locally and see if that fixes the problem. I'm not sure why Mesa can't load the DRI module as even with debug enabled, I don't see any error message reasoning why the module couldn't be loaded. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726969: libarpack2: Please update symbols file to fix FTBFS on m68k
Package: libarpack2 Version: 3.1.3-4 Severity: normal Hi, arpack recently failed to build on one of our m68k builds [1]. Could you please update the symbols file to include the appropriate lines in the debian/libparpack2.symbols to reflect the m68k architecture as well? Cheers, Adrian > [1] > http://buildd.debian-ports.org/status/fetch.php?pkg=arpack&arch=m68k&ver=3.1.3-4&stamp=1382056609 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724576: libgl1-mesa-glx: libGL error: failed to load driver: nouveau
On 10/21/2013 09:08 PM, Sven Joachim wrote: >> I have also reported this issue upstream [1], even though I >> don't think this is an upstream issue but with the particular >> Debian package. > > Could you please send the link for [1], it's not included in your mail. Oops, my bad: > https://bugs.freedesktop.org/show_bug.cgi?id=70135 >> Maybe rebuilding fixes the issue? > > How so, what would be wrong in the build environment on the buildds? Well, I haven't figured out yet why exactly the module fails to load. I just know that it does when using libgl1-mesa-dri from experimental. I'll maybe check if I can get more verbose debugging output with the libgl1-mesa-dri-dbg package instead. I did lots of testing already before I could localize it to that particular package. Granted, I wasn't working purposively when doing that, but I was trying to resolve different issues with the PowerMac G5 I was testing this on, too. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728098: tiff: FTBFS on m68k due to unknown host system
Package: tiff Version: 4.0.3-5 Severity: normal Hello! tiff currently FTBFS on m68k since the configure script doesn't know anything about the host architecture [1]. The interesting bits from the build log are: === Libtiff is now configured for m68k-unknown-linux-gnu === and === /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -D_FORTIFY_SOURCE=2 -D_REENTRANT -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -W -c -o tif_aux.lo tif_aux.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -D_FORTIFY_SOURCE=2 -D_REENTRANT -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -W -c tif_aux.c -fPIC -DPIC -o .libs/tif_aux.o In file included from tiffiop.h:60:0, from tif_aux.c:32: tiffio.h:67:1: error: unknown type name 'unknown' === On i386, the host architecture is detected as: "i486-pc-linux-gnu" [2] while on sparc it is: "sparc-unknown-linux-gnu" [3]. So, I am not sure if that's the actual problem. Adrian > [1] http://buildd.debian-ports.org/status/fetch.php?pkg=tiff&arch=m68k&ver=4.0.3-5&stamp=1379274729 > [2] https://buildd.debian.org/status/fetch.php?pkg=tiff&arch=i386&ver=4.0.3-5&stamp=1379358378 > [3] https://buildd.debian.org/status/fetch.php?pkg=tiff&arch=sparc&ver=4.0.3-5&stamp=1379356596 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656745: gnome-control-center: Region panel breaks LANG, breaks terminal charset, shows wrong languages
fixed -1 1:3.8.3-3 thanks Hi Rodney, hi Martin-Eric! Have you had a look at the new "Region & Language" control panel in GNOME 3.8.4 which is available in unstable now. The GNOME developers have completely overhauled the panel and looks much cleaner now and actually works as expected. GNOME upstream has also marked the bug that I linked as resolved [1], so it's therefore safe to say the issue can be closed here as well. Cheers, Adrian > [1] https://bugzilla.gnome.org/show_bug.cgi?id=671530 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656745: gnome-control-center: Region panel breaks LANG, breaks terminal charset, shows wrong languages
On 10/28/2013 11:06 PM, Martin-Éric Racine wrote: > I wouldn't consider this issue as fixed. > > GNOME still shoves default languages onto the end-users, instead of > only showing languages for which libc locales were generated, or > whichever language was selected by the user via GDM upon logon. I'm sorry, but obviously you did not try the version of gnome-control-center which I mentioned which does exactly that. I just verified it again, by adding an additional locale with dpkg-reconfigure locales. This additional locale was immediately visible in the gnome-control-center, without even having to log off and on again. Just try it yourself. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656745: gnome-control-center: Region panel breaks LANG, breaks terminal charset, shows wrong languages
On 10/28/2013 11:49 PM, Martin-Éric Racine wrote: > Actually, that version cannot be tested as-is, because too many of the > dependencies are not yet available in Testing and too many of the > newer packages that satisfy those dependencies Breaks older versions. That's completely irrelevant here since I tagged the version it has been fixed in which is the version in unstable. The key information for anyone looking into this bug is that it has been remedied with the version of gnome-control-center in unstable which will eventually propagate into testing and be released as Jessie. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 10/31/2013 02:50 AM, Theodore Ts'o wrote: > The most basic is the idea that whether you can control (via shell > scrpit fragments) whether or not a service should start at all, and > what options or environments should be enabled by pasing some file. > The fact that we can put that sort of thing in configuration files > such as /etc/default/*, for example. > > Yes, yes, you can do this via if you use system V init scripts scripts > in backwards compatibility mode, but you've argued that we should be > moving briskly away from that. In which case system administrators > will need to hand-edit the services files by hand, which will no doubt > increase the chances of conflicts at package upgrade time, compared to > if the configuration options were isolated away in files such as > /etc/default/rsync (for example). Ted, I'm sorry, but it's very obvious you have no clue how systemd is supposed to be used. First of all, systemd - like udevd - supports two places where to place systemd service files. One is located below /usr/lib/systemd which is the directory where service files provided by the package are placed, and one is /etc/systemd where your own, custom service files are located. If systemd finds an appropriate service file in /etc/systemd it will ignore the appropriate service file in /usr/lib/systemd, always. So there is never a problem with service files being overwritten during an upgrade like you describe. The same holds true, btw, for udevd with it's rules files which are located in /lib/udev/rules.d and /etc/rules.d respectively. And everything that you might want change in the configuration of a service can be done by editing the service file and this in a much easier and consistent way. Editing a file in the .ini file format is a no-brainer which, in the worst mistake case, will probably lead to an error message from the daemon or systemd while messed up custom code may end up rendering your whole system unusable if you are smart enough to mess up an rm command. Just have a look at this wonderful bug in upstart [1]. > If the package does not ship a SysV init script (which is your ideal > long-term outcome), that may not be very practical option for a system > adminsitrator who may need to recreate a SysV init script, especially > if the service file is rather complicated, or is using some of the > more advanced feature of systemd/upstart. No, System V Init scripts are not ideal on the long-term outcome since they are highly distribution-specific, error-prone and annoying to maintain. We have had tons of bugs in the bug tracker because of broken init scripts, like this one [2]. I don't understand why anyone would think that having to write a small piece of code to start another program is a sensible and good design, especially when this is done for dozens of programs (= daemons) in very much the same way. It absolutely makes sense to encode the logic to start and control a daemon through a single piece of C code rather than writing more-or-less the same bash script for every single daemon on your machine. Adrian > [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728098: tiff: FTBFS on m68k due to unknown host system
close 728098 thanks Hi Jakub! On 01/12/2014 02:32 AM, Jakub Wilk wrote: > I can't think why would this check fail... But anyway, later versions > built successfully[1][2], so I think this bug should be closed. Thank you very much for following up on this. Indeed, tiff now builds fine on m68k and we can close this bug report. I completely forgot about this bug report and it's nice that it has resolved itself now :). Thanks a lot! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726225: fs-uae: Please add fs-uae packages
close 726225 thanks Hello Thomas! fs-uae is a pending upload. I have been working on the package for quite some time now. fs-uae has had some copyright issues in the past and it took some work to get the package DFSG-compliant, it has been rejected twice so far. I fixed the remaining issue and made the third upload attempt today, the package is currently in NEW [1]. I expect it to get finally accepted today or tomorrow. I am closing this bug since the issue has been worked on and the bug should actually of the form RFP, if any. But there is already an ITP bug [2], so no need to file another bug. Adrian > [1] http://ftp-master.debian.org/new/fs-uae_2.2.3%2Bdfsg-1.html > [2] http://bugs.debian.org/680899 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728496: RM: uae -- ROM; Package unmaintained and superceded by fs-uae
Package: ftp.debian.org Severity: normal Dear FTP masters! Since "fs-uae" has finally been accepted into unstable, I hereby request the removal of the package "uae" from unstable and testing (do I need to request that seperately?). I have talked with Stephan Suerken and he has agreed to remove both "uae" and "e-uae" once "fs-uae" has been accepted into unstable. Both "uae" and "e-uae" are no longer in active development and "fs-uae" is a modern fork to replace them. "fs-uae" will support MMU emulation in the next major release and therefore allow to run the m68k port of Debian in an emulated Amiga. I'm also one of the active members of the m68k port :). Cheers, Adrian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728497: RM: e-uae -- ROM; Package unmaintained and superceded by fs-uae
Package: ftp.debian.org Severity: normal Dear FTP masters! Since "fs-uae" has finally been accepted into unstable, I hereby request the removal of the package "e-uae" from unstable and testing (do I need to request that seperately?). I have talked with Stephan Suerken and he has agreed to remove both "uae" and "e-uae" once "fs-uae" has been accepted into unstable. Both "uae" and "e-uae" are no longer in active development and "fs-uae" is a modern fork to replace them. "fs-uae" will support MMU emulation in the next major release and therefore allow to run the m68k port of Debian in an emulated Amiga. I'm also one of the active members of the m68k port :). Cheers, Adrian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724576: libgl1-mesa-glx: libGL error: failed to load driver: nouveau
On 10/25/2013 10:07 PM, Sven Joachim wrote: >> Well, I haven't figured out yet why exactly the module fails to load. I >> just know that it does when using libgl1-mesa-dri from experimental. >> I'll maybe check if I can get more verbose debugging output with >> the libgl1-mesa-dri-dbg package instead. > > So, do you still have that problem with mesa 9.2.2-1? Yes, still seeing the problem unfortunately. Just did a full dist-upgrade which updated mesa to 9.2.2-1 and the problem still persists. >> I did lots of testing already before I could localize it to that >> particular package. Granted, I wasn't working purposively when >> doing that, but I was trying to resolve different issues with >> the PowerMac G5 I was testing this on, too. > > I would expect this to be a powerpc specific problem, but Thomas is > actually running amd64. OTOH, mesa 9.2.2 has been in unstable for three > days now, and apparently nobody else has complained so far. Well, I'll meet Thomas in a few days during an open source meetup and ask him about the status. And, I'd rather think it's a problem specific to the nVidia card in use. I have GeForce 210 on my main desktop running unstable and I don't see the problem there. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
On 11/08/2013 02:54 PM, Marko Randjelovic wrote: > Additional arguments in favor of sysvinit: > > * systemd and upstart lead to vendor lock-in; it will be complicated > later to return back or change to third option, as well to change from > first to second option Exactly what vendor would we be locked into with systemd? > * I don't have a feeling that configuration can be very simpler than > shell scripts; there are things such as 'events' and such things have > to be properly defined) A bash script as glue code between the init daemon is simpler than the simple descriptive XDG format used for systemd's unit files? I don't think so. > * If OpenRC's development continues in good direction, Debian could > switch to OpenRC The word here is "if". It's not going to happen. OpenRC has fundamental issues which haven't been resolved for years now: > https://bugs.gentoo.org/show_bug.cgi?id=391945 I don't think this is a viable alternative to anything. We can't work with vaporware, we need software that actually works. > * If our shell scripts are a mess, then we should clean up the mess, > not trying to escape it by changing whole init system; more precisely, > we should correct mistakes we made in past, such as not enough > abstraction And who is going to do it? Are you? People constantly stating that systems like OpenRC and sysvinit are actually viable alternatives if someone improved them without actually stepping forward themselves leaves me up to the impression that those people actually don't have interests in pushing sysvinit or OpenRC but just blocking the adoption of systemd or upstart. > * existing software (sysvinit+initscripts) can be enhanced: > > (1) add new features to sysvinit; e.g. start-stop-daemon could be > extended, to return only when service is ready, or if timeout exceeds > to return with error status (2) add new software in addition to sysvinit > (3) make init scripts more correct (abstraction) > (4) extend configurability (more options in /etc/default/*) > > (3) makes (4) easily possible The X.org developers were thinking to do the same with X.org but at some point figured out that the sources they are dealing with were such a mess that it's better to start over altogether and started Wayland, see: > http://www.youtube.com/watch?v=RIctzAQOe44 > If sysvinit is in accord with UNIX philosophy, and as they say it is, > than I don't see why (1) and (2) would not be possible, too, and with > not to much effort. No one cares about the "Unix philosophy" (TM), it's not some super holy cow we're not allowed to touch. Additionally, original Unix sucks, it's all the GNU- and Linux-specific extensions that actually made it usable. > * What is alleged to be disadvantages of sysvinit (lack of features), > is not really to blame sysvinit, because it does one thing and do it > right. No, sysvinit doesn't even do the one thing it does right. It has been explained many many times before why that isn't the case. > * More complex software has more bugs, old software is cleaned out of > original bugs, and new software is not. If that should be a dogma we should always stick to, we should immediately abandon all efforts to improve software and go back to Linux 0.01. > * Software that is not well commented is hard to understand and find > bugs Your last statement doesn't hold at all without actually giving a couple if examples where you think that systemd or upstart are poorly documented. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729660: ITP: xemacs21 -- highly customizable text editor
On 11/16/2013 11:43 AM, Mark Brown wrote: > On Fri, Nov 15, 2013 at 09:49:49PM +, Dmitrijs Ledkovs wrote: > >> Why should Debian carry this package? > > It's a package that we've carried since forever and which has a > userbase. That's not really an argument. We've also had uae and e-uae (the Amiga emulators) for ages and they had a user base. Yet, I filed removal bugs because upstream was no longer existent and they have been replaced by more modern forks like fs-uae. There were simply too many bugs that would never get addressed. Your first mail came with the argument that you think that xemacs is more visually appealing than emacs. Honestly, emacs is primarily a tool and not an optical gimmick. Visual appearance does not bother most users, I'd guess. Most emacs users use the terminal (-nw) mode anyway. And the beef I have with xemacs is that it's development has factually ceased. Looking at the changes over the past months, I see only marginal changes [1] but no real development. I never think that's a good idea to upload packages to Debian where virtually no upstream development is taking place. The risk of RC bugs not getting fixed in time is simply too high. I remember fixing RC bugs in several packages in Wheezy during the freeze where upstream was no longer available and we had to dig through the code and fix the bugs ourselves. I want to avoid such situations in the future! I support Paul's stance on this! Cheers, Adrian > [1] http://www.xemacs.org/Releases/21.5.33.html#ChangeLog -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#729660: ITP: xemacs21 -- highly customizable text editor
On 11/16/2013 01:10 PM, Mark Brown wrote: >> Your first mail came with the argument that you think that >> xemacs is more visually appealing than emacs. Honestly, emacs >> is primarily a tool and not an optical gimmick. Visual >> appearance does not bother most users, I'd guess. Most emacs >> users use the terminal (-nw) mode anyway. > > Your assertations here both seem rather strong and unsupported, > especially the idea that people don't use Emacs in graphical mode - it I have yet to see someone who does. I'm a long-time emacs user and so are many of other developers I work together with and everyone I know of who uses emacs as their primary editor doesn't use X11 support, you just don't need it in most cases. emacs is powerful through it's keyboard shortcuts and you are much more efficient and faster when using them as opposed to navigating through the menus with your mouse. > would be enormously surprising to me if people had abandoned X11 support > en masse. As for people not caring about the appearence... if you're > going to be looking at something for the best part of the day it seems > strange that you'd not be interested in how it looks, it's a factor in > usability. Well, as I said, if you're really using emacs for what it's renown for, you don't care about the X11 user interface and the looks because you use non-windowed mode anyway. >> And the beef I have with xemacs is that it's development >> has factually ceased. Looking at the changes over the past >> months, I see only marginal changes [1] but no real development. > >> I never think that's a good idea to upload packages to Debian >> where virtually no upstream development is taking place. The >> risk of RC bugs not getting fixed in time is simply too high. > >> I remember fixing RC bugs in several packages in Wheezy during >> the freeze where upstream was no longer available and we had >> to dig through the code and fix the bugs ourselves. I want >> to avoid such situations in the future! > > We can always drop packages if they're too buggy; indeed it turns out we > did that for XEmacs in the last release (which I only noticed after > release sadly, much to my distress when I installed a new desktop > recently). Besides, the risk here seems low, it's not a package that's > using bleeding edge or rapidly developed interfaces that are likely to > change underneath it and obviously Debian's tendency to work with older > versions of software for extended periods means that we have to accept > that even an active upstream might not care about supporting us. As I explained before, the problem with such packages is that they can introduce unnecessary (RC) bugs which may delay the release during the freeze. I am aware of the fact that the release team has addressed the issue by removing packages from testing now which have had RC bugs longer than a certain time frame, but I think we should avoid such situations in the first place. And the fact that a very limited group of users is using XEmacs doesn't justify the hassle. If someone is so keen to actually prefer XEmacs over emacs, they can just download and build the package from source. > At the end of the day if you're not interested in a leaf package just > ignore it, work on something you do care about instead. > No, I do care about the whole of Debian and not just about my particular packages and honestly, it bothers me to no end when I see packages which have dozens or hundreds of bugs unanswered because no one is stepping in to fix that. And I think Paul feels the same. I rather prefer to have a package removed than it being full of bugs, no matter whether it's a leaf package or not. A constant quality control of Debian as a whole is important as a whole for being able to reduce the freeze time as we have learnt in the past. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#730258: please add arch-specific BTS tags
On 11/23/2013 11:51 PM, Helge Deller wrote: >> What else am I missing? > > Please add "hppa" Assuming that you are one of the hppa guys, how is the port doing? Any chance that the buildds will be up and running again anytime soon? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730258: please add arch-specific BTS tags
On 11/24/2013 12:22 AM, Helge Deller wrote: > On 11/24/2013 12:21 AM, John Paul Adrian Glaubitz wrote: >> On 11/23/2013 11:51 PM, Helge Deller wrote: >>> Please add "hppa" >> >> Assuming that you are one of the hppa guys, how is the port doing? Any >> chance that the buildds will be up and running again anytime soon? > > Yes, think so. > I'm working on that just right now... Very cool! Hope you guys will soon be where we already are with the m68k port :). Crossing my fingers! It's been sad to see the number of up-to-date packages in hppa dropping over the time. Keep us updated! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730258: please add arch-specific BTS tags
On 11/24/2013 12:47 AM, John David Anglin wrote: > On 23-Nov-13, at 6:35 PM, John Paul Adrian Glaubitz wrote: > >> Crossing my fingers! It's been sad to see the number of up-to-date >> packages in hppa dropping over the time. > > It should be going up now. So, the buildds are already up and running? Shouldn't they be showing up on buildd.debian-ports.org [1]? Adrian > [1] http://buildd.debian-ports.org/status/architecture.php?a=hppa&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730258: please add arch-specific BTS tags
On 11/24/2013 01:20 AM, Thorsten Glaser wrote: > John Paul Adrian Glaubitz dixit: >> So, the buildds are already up and running? Shouldn't they be showing >> up on buildd.debian-ports.org [1]? > > I think I saw buildd uploads for hppa on incoming.d.o this week. Indeed: > http://incoming.debian-ports.org/buildd/packages/unstable/main/ Very cool! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730865: mate-dialogs: Please ship zenity replacement
Hello Martintxo! On 11/30/2013 01:23 PM, martintxo wrote: > Please considere shipping mate-dialogs-gnome package for zenity replacement. > Thanks in advance. Greetings. Martintxo. The packaging of Mate is still work-in-progress and the fact that mate-dialogs-gnome is missing doesn't mean we don't package it but that we haven't packaged it yet. Mate consists of over 50 single packages and it takes some time to get them into Debian, please be patient. Unless the other Mate maintainers object, I'd like to close this bug report as invalid. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751535: here is a picture of having maximize, minimize and close buttons of both iceweasel and nautilus
control: tags 751535 moreinfo Hi! The screenshots you attached do not show any irregular behavior. Please provide a more accurate description of the problem and mark the areas in question in the screenshots if necessary. Please also note that Nautilus is not native to MATE since it is a GTK3 application. If you prefer using Nautilus as a file manager, I'd rather recommend using GNOME as your desktop of choice. GTK3 applications will always look a bit ugly on MATE until MATE has been ported to GTK3. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748398: linux: Please disable CONFIG_DRM_RADEON_UMS on powerpc
On 05/18/2014 08:15 PM, gustavo panizzo wrote: > did you rebuild your initramfs after blacklist the module?, > /etc/modprobe.d contents should be in initramfs Yes, that doesn't help. The problem is that the "radeonfb" driver is built into the kernel instead as a module and blacklisting won't help. It's still being load during early boot and even though it gets unloaded later, it leaves the GPU in a state where the radeon module won't work anymore and X.Org falls back to fbdev. I can disable the driver and make the regular radeon driver work by adding the following to the kernel command line: video=radeonfb:off Thus, the issue is not CONFIG_DRM_RADEON_UMS but CONFIG_FB_RADEON. Interestingly, CONFIG_FB_RADEON is built as a module on amd64 and i386: root@jessie32:~> uname -a Linux jessie32 3.14-1-686-pae #1 SMP Debian 3.14.4-1 (2014-05-13) i686 GNU/Linux root@jessie32:~> grep CONFIG_FB_RADEON= /boot/config-$(uname -r) CONFIG_FB_RADEON=m root@jessie32:~> root@jessie64:~> uname -a Linux jessie64 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64 GNU/Linux root@jessie64:~> grep CONFIG_FB_RADEON= /boot/config-$(uname -r) CONFIG_FB_RADEON=m root@jessie64:~> while it's built in on the PowerPC: root@test-adrian1:~> uname -a Linux test-adrian1 3.15-rc8-powerpc #1 Debian 3.15~rc8-1~exp1 (2014-06-03) ppc GNU/Linux root@test-adrian1:~> grep CONFIG_FB_RADEON= /boot/config-$(uname -r) CONFIG_FB_RADEON=y root@test-adrian1:~> I will try rebuilding the kernel on the PowerPC with CONFIG_FB_RADEON=m and see if it fixes the issue by allowing to blacklist the radeonfb module. If yes, I'll send in a kernel patch to change the configuration for the powerpc kernel accordingly. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752932: lightdm: systemd service file misses [Install] section
Package: lightdm Version: 1.10.1-3 Severity: normal Tags: patch Hello! The systemd service file currently supplied with lightdm does not provide an install section, it is therefore not possible to disable and re-enable lightdm with systemd's systemctl: root@test-adrian1:~> systemctl disable lightdm.service Synchronizing state for lightdm.service with sysvinit using update-rc.d... Executing /usr/sbin/update-rc.d lightdm defaults Executing /usr/sbin/update-rc.d lightdm disable insserv: warning: current start runlevel(s) (empty) of script `lightdm' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `lightdm' overrides LSB defaults (0 1 6). rm '/etc/systemd/system/display-manager.service' root@test-adrian1:~> systemctl enable lightdm.service Synchronizing state for lightdm.service with sysvinit using update-rc.d... Executing /usr/sbin/update-rc.d lightdm defaults insserv: warning: current start runlevel(s) (empty) of script `lightdm' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `lightdm' overrides LSB defaults (0 1 6). Executing /usr/sbin/update-rc.d lightdm enable The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). root@test-adrian1:~> With the attached patch, disabling and enabling works correctly: root@test-adrian1:~> systemctl disable lightdm.service Synchronizing state for lightdm.service with sysvinit using update-rc.d... Executing /usr/sbin/update-rc.d lightdm defaults Executing /usr/sbin/update-rc.d lightdm disable insserv: warning: current start runlevel(s) (empty) of script `lightdm' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `lightdm' overrides LSB defaults (0 1 6). root@test-adrian1:~> systemctl enable lightdm.service Synchronizing state for lightdm.service with sysvinit using update-rc.d... Executing /usr/sbin/update-rc.d lightdm defaults insserv: warning: current start runlevel(s) (empty) of script `lightdm' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `lightdm' overrides LSB defaults (0 1 6). Executing /usr/sbin/update-rc.d lightdm enable ln -s '/lib/systemd/system/lightdm.service' '/etc/systemd/system/display-manager.service' root@test-adrian1:~> Cheers, Adrian -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 3.15-rc8-powerpc 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 lightdm depends on: ii adduser3.113+nmu3 ii consolekit 0.4.6-5 ii dbus 1.8.4-1 ii debconf [debconf-2.0] 1.5.53 ii libc6 2.19-4 ii libgcrypt111.5.3-4 ii libglib2.0-0 2.40.0-3 ii libpam-systemd 208-1 ii libpam0g 1.1.8-3 ii libxcb11.10-3 ii libxdmcp6 1:1.1.1-1 ii lightdm-gtk-greeter [lightdm-greeter] 1.8.5-1 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+7 Versions of packages lightdm suggests: ii accountsservice 0.6.37-1 ii upower 0.9.23-2+b2 -- debconf information excluded --- lightdm.service.orig 2014-04-27 11:12:30.0 +0200 +++ lightdm.service 2014-06-27 22:45:45.428997776 +0200 @@ -10,3 +10,7 @@ ExecStart=/usr/sbin/lightdm Restart=always BusName=org.freedesktop.DisplayManager + +[Install] +Alias=display-manager.service +WantedBy=graphical.target
Bug#752933: src:glibc: FTBFS on Alpha port due to failing tests
Package: src:glibc Version: 2.19-4 Severity: normal Hello! After transitioning back from src:eglibc to src:glibc, building glibc from source fails on the Alpha port due to some tests from the testsuite failing, see the build log here [1]. I'm neither an expert regarding the C libary nor the Alpha architecture, but we happened to have these at work back then and I successfully installed Debian Lenny and earlier versions of Debian on Alpha without any issues, so the problem is apparently a regression in the glibc sources. >From the build log linked down below, it seems the following symbol mismatch is mainly responsible for the failing build: diff -p -U 0 ../ports/sysdeps/unix/sysv/linux/alpha/nptl/ld.abilist /«PKGBUILDDIR»/build-tree/alpha-libc/elf/ld.symlist /«PKGBUILDDIR»/build-tree/alpha-libc/elf/ld-linux.so.2 --library-path /«PKGBUILDDIR»/build-tree/alpha-libc:/«PKGBUILDDIR»/build-tree/alpha-libc/math:/«PKGBUILDDIR»/build-tree/alpha-libc/elf:/«PKGBUILDDIR»/build-tree/alpha-libc/dlfcn:/«PKGBUILDDIR»/build-tree/alpha-libc/nss:/«PKGBUILDDIR»/build-tree/alpha-libc/nis:/«PKGBUILDDIR»/build-tree/alpha-libc/rt:/«PKGBUILDDIR»/build-tree/alpha-libc/resolv:/«PKGBUILDDIR»/build-tree/alpha-libc/crypt:/«PKGBUILDDIR»/build-tree/alpha-libc/nptl /«PKGBUILDDIR»/build-tree/alpha-libc/elf/tst-array2 > /«PKGBUILDDIR»/build-tree/alpha-libc/elf/tst-array2.out --- ../ports/sysdeps/unix/sysv/linux/alpha/nptl/libc.abilist 2014-02-07 09:04:38.0 + +++ /«PKGBUILDDIR»/build-tree/alpha-libc/libc.symlist 2014-06-27 12:41:19.606854627 + @@ -181,0 +182 @@ GLIBC_2.0 + __multi3 F ../Makerules:1285: recipe for target 'check-abi-libc' failed make[3]: *** [check-abi-libc] Error 1 Cheers, Adrian > [1] > http://buildd.debian-ports.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.19-4&stamp=1403873117 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749547: procps: fix FTBFS on ppc64el (new patch available for dh-autoreconf)
Hello Craig! I think fixing this FTBFS on the ports architecture is an important issue. I would therefore like to ask you to apply Mauricio's patch ASAP since there are some reverse build dependencies on the procps package. In case you don't have the time at the moment to take care of the procps package, just let me know and I'll do an NMU! Thanks to Mauricio and Breno for the patch! Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749547: procps: fix FTBFS on ppc64el (new patch available for dh-autoreconf)
On 06/29/2014 02:49 AM, Craig Small wrote:
> On Sat, Jun 28, 2014 at 10:31:23AM +0200, John Paul Adrian Glaubitz wrote:
>> I think fixing this FTBFS on the ports architecture is an important
>> issue. I would therefore like to ask you to apply Mauricio's patch
>> ASAP since there are some reverse build dependencies on the procps
>> package.
> It'll be uploaded in a few minutes, assuming the ftp-master is
> working properly again.
Thanks!
Unfortunately, it still fails to build from source on s390x, ppc64,
arm64, hppa and sh4 [1].
The error is always the same:
ERROR: tcl error sourcing ./pgrep.test/pgrep.exp.
ERROR: couldn't execute "kill": no such file or directory
while executing
"exec kill 7840"
("eval" body line 1)
invoked from within
"eval exec "$kill_path $testproc1_pid""
(file "./pgrep.test/pgrep.exp" line 130)
invoked from within
"source ./pgrep.test/pgrep.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source ./pgrep.test/pgrep.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Adrian
> [1]
https://buildd.debian.org/status/fetch.php?pkg=procps&arch=s390x&ver=1%3A3.3.9-6&stamp=1403976838
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748398: linux: Please disable CONFIG_DRM_RADEON_UMS on powerpc
On 06/27/2014 05:35 PM, John Paul Adrian Glaubitz wrote: > I will try rebuilding the kernel on the PowerPC with CONFIG_FB_RADEON=m > and see if it fixes the issue by allowing to blacklist the radeonfb > module. If yes, I'll send in a kernel patch to change the configuration > for the powerpc kernel accordingly. Verified. Setting CONFIG_FB_RADEON=m and rebuilding the kernel fixes the radeon problem on my Mac Mini G4 PPC permanently. Since there are several framebuffer drivers compiled into the kernel instead of building them as modules on the PowerPC kernel, I suggest to build these as modules as well to avoid the very same problem for other video adapters. I will provide a proposed diff for the kernel configuration on powerpc later. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744087: pluma: does not start - missing scheme installation
Hello Norbert! On 04/10/2014 01:10 AM, Norbert Preining wrote: > thanks for packaging mate, I really want to use some of its components, > but unfortunately none of them do start: You should rather use the packages from the Mate upstream repositories for the time being since the packaging is still work-in-progress. As you may know, Mate is split over several dozen packages and it is practically impossible to package and upload all associated packages within a short time frame and breakage is therefore to be expected. As for pluma, the package was just accepted into unstable as of yesterday and is due to be upgraded to the latest upstream version 1.8.0 within the next days. The reason why pluma is still on version 1.6.2 is because it has been in the NEW queue for quite a long time and was packaged and uploaded before Mate 1.8.0 was released. The idea was simply to wait until packages in NEW would have been accepted before uploading the new 1.8.0 upstream versions. Thus, just wait a few days for pluma to be updated. Hope that helps! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745362: RFS: autoconf-archive/20140228-1
Hi Bastien! On 04/20/2014 11:43 PM, Bastien ROUCARIES wrote: > Closes: > #737087 (important): autoconf-archive: ax_boost_date_time broken by multiarch > #741574 (normal): autoconf-archive: new upstream version You don't have to file an RFS bug report in order to ask me to sponsor an upload. Just ping me and I'm usually happy to sponsor your package. Would you be ok with a sponsorship tomorrow? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741826: needs python-all python3-all in build-deps
> With this fixed, the package builds cleanly in a pbuilder chroot and > should therefore be fine on the buildds as well. Someone interested in doing an NMU? I'd go ahead if no one else steps in. It's a very simple change after all. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745608: libmowgli-2: FTBFS on various architectures due to unknown arch
Package: libmowgli-2 Version: libmowgli-2: FTBFS on various architectures due to unknown arch Severity: serious Justification: renders package unusable Hi! libmowgli-2 currently fails to build on the following architectures since the corresponding architectures are not defined in src/libmowgli/platform/machine.h: * kfreebsd-386 * kfreebsd-amd64 * s390x * arm64 * m68k Please patch the header file to include these architectures as well. For m68k, for example, the #defines would be something like: #if defined __m68k__ || defined __M68K__ #define MOWGLI_CPU_M68K #define MOWGLI_CPU m68k #define MOWGLI_CPU_BITS_32 #define MOWGLI_CPU_BITS 32 #endif Thanks, Adrian -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-rc7-amd64 (SMP w/4 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740198: arpack: Please update libparpack2.symbols to fix FTBFS on various port architectures
Package: arpack Version: 3.1.5-1 Severity: normal Tags: patch Hi! There are a few more architectures where arpack fails to build from source due to an incomplete libparpack2.symbols file [1]. The attached patch should fix the FTBFS for all affected port architectures, namely hppa, ppc64, sh4, sparc64 and x32. PS: Please also fix the typo "m86k"->"m68k" in the debian/changelog ;). Thanks! Adrian > [1] http://buildd.debian-ports.org/status/package.php?p=arpack&suite=sid -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 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 --- arpack-3.1.5/debian/libparpack2.symbols 2014-02-15 15:20:31.0 +0100 +++ arpack-3.1.5/debian/libparpack2.symbols.new 2014-02-26 20:54:45.294577511 +0100 @@ -44,13 +44,13 @@ iset_@Base 2.1 iswap_@Base 2.1 ivout_@Base 2.1 - (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64)mpi_fortran_argv_null_@Base 3.1.2 - (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64)mpi_fortran_argvs_null_@Base 3.1.2 - (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64)mpi_fortran_bottom_@Base 3.1.2 - (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64)mpi_fortran_errcodes_ignore_@Base 3.1.2 - (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64)mpi_fortran_in_place_@Base 3.1.2 - (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64)mpi_fortran_status_ignore_@Base 3.1.2 - (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64)mpi_fortran_statuses_ignore_@Base 3.1.2 + (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64 !hppa !ppc64 !sh4 !sparc64 !x32)mpi_fortran_argv_null_@Base 3.1.2 + (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64 !hppa !ppc64 !sh4 !sparc64 !x32)mpi_fortran_argvs_null_@Base 3.1.2 + (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64 !hppa !ppc64 !sh4 !sparc64 !x32)mpi_fortran_bottom_@Base 3.1.2 + (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64 !hppa !ppc64 !sh4 !sparc64 !x32)mpi_fortran_errcodes_ignore_@Base 3.1.2 + (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64 !hppa !ppc64 !sh4 !sparc64 !x32)mpi_fortran_in_place_@Base 3.1.2 + (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64 !hppa !ppc64 !sh4 !sparc64 !x32)mpi_fortran_status_ignore_@Base 3.1.2 + (arch=!mips !mipsel !s390 !s390x !powerpcspe !m68k !arm64 !hppa !ppc64 !sh4 !sparc64 !x32)mpi_fortran_statuses_ignore_@Base 3.1.2 pcgetv0_@Base 2.1 pclarnv_@Base 2.1 pcmout_@Base 2.1
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/28/2014 04:13 PM, Turbo Fredriksson wrote: > Is it ok/allowed to upload a new package, even though the initial one is > still stuck in incoming? I suggest asking the FTP masters to mark the package as REJECT if you want to change something again. As long the package is still stuck in NEW (not incoming, this is where the package goes once it's been ACCEPTED), you can always have it rejected. It's the cleaner solution in my opinion instead of uselessly bumping the package revision to fix minor issues before the package isn't even ACCEPTED. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2014 05:37 PM, Carlos Alberto Lopez Perez wrote: > I advise against this. The upload is to experimental, is OK if the > package has RC bugs. Why? If the maintainer has made some changes in the meantime while the package has been waiting in NEW and the FTP team hadn't yet the possibility to look at the package, why waste their time to review a package which is going to be redone anyway? > Let the ftp-master team accept the package first, and once that is > done we can upload a better version to unstable. But if you already start with a cleaner version in NEW, you have the chance to get a feedback on the current package revision instead of the old one. Makes much more sense to me. > In the meanwhile you can continue working on the package repository > as usual. I don't see how you couldn't when just asking for the package to be marked as REJECT. Like I said, I do that often and there is nothing wrong when the package hasn't even been looked at yet. I rather feel embarrassed about uploading a b0rked package into NEW. > However, I will wait for a resolution from ftp-master before > resuming my work on the package, because there is the possibility > of ftp-master not allowing the upload and I don't like to waste my > time. Just because your package is rejected doesn't mean you can't get it into unstable at all. Packages are rejected all the time. It just means the package is not *yet* fit for ACCEPT. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEMAZAAoJEHQmOzf1tfkTHYMP/3iYWbT/9r/HdJ/eQLCNFyvv Xk0tb1fRWUsvDrO2h+9I4IqDMD3UWxLtMvrGDkUrJEv5jXFsuWiMRRMRQTIN5wnS ImnjMJgrtUIohGmn0UF8yDkNXduc9GWX/DToh/74n6hjXSRja+qxg8gTf/Ts3nxL Th9AJLwSod6idgyC/keY64TkFLy5GKP73icMbF6SZCfwFyn5kFzPxarU+eDVnDDT Ynog2VFkIu4oG7YNYkQQDVwljY7wxsxEAl82CZt7D+gAHOVt6qG65iDJ7OuacJ0c McA5ZOnjIUf1EkX2xTzml8CddaF9pkJoXndqOObdsejdtxrRW97rb0Vo8+B7t7H8 NF8pSjooruRxNv08gF7g0m08++6Kh+qFFQmtHlAIirHhanffajX8r/LfVnMsK1Ts IfJbSd8BzNPKeeAraQy9axeudkDUMpRFYHq6c1+tM2Bh0maZrATVtwdEm5UBk8yM YRP+JUQY7n3ZYv13bEu5Ar1k0tpsIm51RLNFVQSowBOikPwABWZS78pr0dJ24sG4 y6whiqUno+93H0Jt9U3kkfVJgskYYZkpgSorZQMWMNCWQnmn9xrzI57iQjk2GTXP pM5ENvTANpSPE2bdxciNteQI/o7wCP0F8FovBNGXfKa8V2DYPS/mrExynE7nmFfa fpqhw8S4Bd/OPFyiroGX =qeZj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
Hi! On 02/28/2014 06:23 PM, Yaroslav Halchenko wrote: > I am not an ftp-master but if I were one (and as a mentor for quite a > few projects) I would have preferred to have re-uploads because > > - ftp masters already looked at some past version We are talking about packages in NEW, those haven't usually been in the archives before. The case you are describing can only occur if an existing package is stuck in NEW because of new binary components, for example. > - having old and new versions eases to see what has changed (debdiff) > instead of starting all over or digging out previous version Not if there isn't any old version in the archives. > - shows active interest of original maintainers I don't understand this argument. Again, what I am saying is that if you upload something into NEW and you realized you messed something up or the package has been in the queue for quite some time now without any of the FTP masters having looked at the package yet and the maintainer has changed the packaging a lot in the meantime, I think it's the proper approach to ask the FTP team to mark the package as REJECT and upload a current version. This way the FTP team doesn't waste their time on reviewing a package which is going to be replaced very soon anyway. Especially when the packaging was considerably changed in the mean time. Who tells you that the maintainers didn't make any mistake in their new package version that would normally have triggered a REJECT by the FTP team, but the maintainers get to upload it into the archives anyway because there is already a version in unstable that has been accepted? Honestly, I think packages should automatically be removed from NEW after a certain grace period. This shouldn't be regarded as a REJECT for the package in general, but simply that no one has managed so far to review the package and it "fell out" of the queue. Helps keeping the packages in NEW "fresh" in my opinion. > for original uploader benefit is that package doesn't loose its order in > the NEW (IIRC). I don't see how this would be of any advantage. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714058: ITP: cc65 -- Cross compiler and toolchain for 6502-based systems
Hi Spiro! On 03/03/2014 09:50 PM, Spiro Trikaliotis wrote: > I would be willing to maintain the package (neglecting the formal > process of becoming a Debian maintainer, which I read some years ago, > but do not remember completely at the moment). We should get into touch. I am still interested in maintaining cc65, so we could work together. I have recently been stressed out, so I didn't make any process, so I could definitely need some help ;). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576975: DeaDBeeF 0.6.1 is out
Hello! On 03/09/2014 04:33 PM, mdt wrote: > Also upstream provides .deb: > http://sourceforge.net/projects/deadbeef/files/debian/ Thanks for the heads up, but I haven't had time yet to do a proper review for deadbeef. Since it's a new package, I thoroughly have to go through all source code files for a proper review to make sure there are no issues with the copyright. Debian packages provided by upstream are not required since Mateusz has already done the packaging. Also, packages have to meet high quality standards to be accepted into Debian, and upstream packages usually do not meet these criteria. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701680: Segfault when attempting to read a file
Hi Dario and Josh! I can easily reproduce the issues on two machines running Debian unstable. Here's how to reproduce it: mkdir dlna djmount -f -d dlna cd dlna cp dlna djmount just stops with "Segmentation fault" and the file operation issues a "Transport not connected" error message: glaubitz@z6:..Banda_Bassotti/banda bassotti - asi es mi vida> cp -av 03\ -\ ay\ nicaragua\ nicaraguita.mp3 /tmp ‘03 - ay nicaragua nicaraguita.mp3’ -> ‘/tmp/03 - ay nicaragua nicaraguita.mp3’ cp: error reading ‘03 - ay nicaragua nicaraguita.mp3’: Transport endpoint is not connected cp: failed to extend ‘/tmp/03 - ay nicaragua nicaraguita.mp3’: Transport endpoint is not connected cp: failed to close ‘03 - ay nicaragua nicaraguita.mp3’: Transport endpoint is not connected glaubitz@z6:..Banda_Bassotti/banda bassotti - asi es mi vida> I haven't figured out yet what factors are relevant for the problem (host architecture etc), but the problem definitely exists. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740097: nvidia-legacy-304xx-kernel-source: Module can not be loaded for Linux 3.13
Hi! This issue is resolved by importing the latest upstream version of the proprietary driver obtained from [1] and [2]. I did that for the Wheezy clients at work by simply obtaining the source package for the current version from wheezy-backports, replacing the two driver packages with the new ones, adding a Debian changelog entry and rebuilding the package. I would refrain from using any hacks trying to resolve the issue since might have negative impacts on the performance or stability of the driver package. I would suggest rising package urgency to high for the upload. Cheers, Adrian > [1] http://www.nvidia.com/Download/driverResults.aspx/73965/en-us > [2] http://www.nvidia.com/Download/driverResults.aspx/73966/en-us -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743401: Processed: your mail
Hello Shirish! You are looking at the wrong place. xsessions belong to /usr/share/xessions and that's where I can find the MATE session on my laptop: glaubitz@znote-t60l:~$ ls -l /usr/share/xsessions/ total 20 -rw-r--r-- 1 root root 86 Aug 6 2011 lightdm-xsession.desktop -rw-r--r-- 1 root root 6773 Mar 9 12:01 mate.desktop -rw-r--r-- 1 root root 4294 Jan 18 10:38 xfce.desktop glaubitz@znote-t60l:~$ The mate session file is located in the package "mate-session-manager": glaubitz@znote-t60l:~$ ls -l /usr/share/xsessions/ total 20 -rw-r--r-- 1 root root 86 Aug 6 2011 lightdm-xsession.desktop -rw-r--r-- 1 root root 6773 Mar 9 12:01 mate.desktop -rw-r--r-- 1 root root 4294 Jan 18 10:38 xfce.desktop glaubitz@znote-t60l:~$ It is currently not available in Debian unstable but only from the MATE repositories [1] since it is still stuck in NEW [2]: glaubitz@znote-t60l:~$ apt-cache policy mate-session-manager mate-session-manager: Installed: 1.8.0-0+jessie Candidate: 1.8.0-0+jessie Version table: *** 1.8.0-0+jessie 0 500 http://repo.mate-desktop.org/archive/1.8/debian/ jessie/main amd64 Packages 100 /var/lib/dpkg/status glaubitz@znote-t60l:~$ Thus, you can either install MATE through the MATE repositories from [1] or simply wait until MATE has been completely uploaded to Debian unstable. Since MATE is a fully blown desktop which is installed through a large number of packages, it takes some time until all packages necessary for MATE are part of Debian and users have to be patient and should refrain from reporting bugs. Cheers, Adrian > [1] http://wiki.mate-desktop.org/download > [2] https://ftp-master.debian.org/new/mate-session-manager_1.6.1-1.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743420: sane-utils: scanimage fails when avahi is enabled
tags 743420 unreproducible thanks Hi Leopold! I can't currently reproduce your problem. avahi-daemon is running on my machine all the time and my scanner still works (see below). I also successfully tried to scan something. Maybe there is something wrong with your Avahi configuration? === glaubitz@z6:~> systemctl status avahi-daemon.service avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled) Active: active (running) since Wed 2014-02-26 15:54:47 CET; 1 months 5 days ago Main PID: 1135 (avahi-daemon) Status: "Server startup complete. Host name is z6.local. Local service cookie is 475712328." CGroup: name=systemd:/system/avahi-daemon.service ├─1135 avahi-daemon: running [z6.local] └─1292 avahi-daemon: chroot helper glaubitz@z6:~> scanimage -L device `hp:/dev/sg6' is a Hewlett-Packard C5110A flatbed scanner glaubitz@z6:~> === Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662557: xemacs21: Please Build-Depends on libpng-dev, change from libpng12-dev
reopen 662557 thanks Hello Mark! xemacs21 still build depends on libpng12-dev instead of libpng-dev, so you should have re-opened the bug report. Maybe you should have a look at the bugs which were closed by the removal of the package and re-open them if they still apply. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
