Bug#767575: ITP: fonts-seto - handwriting Japanese font including JIS X 0213 kanji
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-CC: debian-devel@lists.debian.org, pkg-fonts-de...@lists.alioth.debian.org Package name: fonts-seto Version: 6.20 Upstream Author: 瀬戸のぞみ (Nozomi Seto) URL: http://setofont.sourceforge.jp/ License: OFL-1.1 Seto font is a handwriting Japanese monospaced font. . It includes JIS X 0213 kanji and also Unicode SIP (Supplementary Ideographic Plane) kanji in setofont-ex.ttf -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141101162420.38254019e022c33e44fb7...@debian.or.jp
inconsistent versions of M-A: same packages
Hello, sorry for the naive question, but is there a plan for massively rebuilding all "Multi-Arch: same" packages that have inconsistent version numbers across architectures before releasing Jessie? I understand that in testing or unstable, rebuilding for all platforms every time a single one needs a rebuild is costly. And there may be solutions in future versions of dpkg/apt to accept multiarch co-installations that differ only by a rebuild. But in the mean time, for a stable release like Jessie, it would be nice to be able to take advantage of the good work some maintainers have put into adapting their packages to M-A. A few random packages that currently have an inconsistent version: zlib1g (+b1 on ppc64el) expat (+b1 on ppc64el, +b2 on arm64) xz-utils (idem) check (+b1 on s390x, libc conflicts with non +b1 version) mpclib3, mpfr4... Thanks, -- Marc Glisse -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411011055060.10...@laptop-mg.saclay.inria.fr
Re: inconsistent versions of M-A: same packages
Hi Marc, On Samstag, 1. November 2014, Marc Glisse wrote: > sorry for the naive question, but is there a plan for massively rebuilding > all "Multi-Arch: same" packages that have inconsistent version numbers > across architectures before releasing Jessie? [...] > A few random packages that currently have an inconsistent version: did you notice any problem with those? There shouldn't and if there are, those are bugs. binNMU differences should have no effect whatsover, except that they are a visual glitch. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: inconsistent versions of M-A: same packages
On 11/01/2014 at 07:38 AM, Holger Levsen wrote: > Hi Marc, > > On Samstag, 1. November 2014, Marc Glisse wrote: > >> sorry for the naive question, but is there a plan for massively >> rebuilding all "Multi-Arch: same" packages that have inconsistent >> version numbers across architectures before releasing Jessie? > [...] >> A few random packages that currently have an inconsistent version: > > did you notice any problem with those? There shouldn't and if there > are, those are bugs. binNMU differences should have no effect > whatsover, except that they are a visual glitch. I've noticed upgrade-time problems from what I think is this same issue, for cases when one package depends on an exactly-equal version of another package, and the other package got a +bX version bump but the depending package didn't. I don't know how common such situations are, but they do seem to occur, and to be more than a visual glitch. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: inconsistent versions of M-A: same packages
On Sat, 1 Nov 2014, Holger Levsen wrote: Hi Marc, On Samstag, 1. November 2014, Marc Glisse wrote: sorry for the naive question, but is there a plan for massively rebuilding all "Multi-Arch: same" packages that have inconsistent version numbers across architectures before releasing Jessie? [...] A few random packages that currently have an inconsistent version: did you notice any problem with those? There shouldn't and if there are, those are bugs. binNMU differences should have no effect whatsover, except that they are a visual glitch. The packages themselves are fine, but they cannot be co-installed, which is the point of Multi-Arch: same. $ sudo apt-get install libmpfr4:powerpc libmpfr4:ppc64el [...] The following packages have unmet dependencies: libmpfr4:powerpc : Breaks: libmpfr4:ppc64el (!= 3.1.2-1) but 3.1.2-1+b1 is to be installed libmpfr4:ppc64el : Depends: libgmp10:ppc64el but it is not going to be installed Breaks: libmpfr4:powerpc (!= 3.1.2-1+b1) but 3.1.2-1 is to be installed (hacking the version number lets it co-install just fine) -- Marc Glisse -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411011243130.10...@laptop-mg.saclay.inria.fr
Re: inconsistent versions of M-A: same packages
Hi! On Sat, 2014-11-01 at 11:45:56 +0100, Marc Glisse wrote: > sorry for the naive question, but is there a plan for massively rebuilding > all "Multi-Arch: same" packages that have inconsistent version numbers > across architectures before releasing Jessie? That's something for the release-team and build admins. > I understand that in testing or unstable, rebuilding for all platforms every > time a single one needs a rebuild is costly. And there may be solutions in > future versions of dpkg/apt to accept multiarch co-installations that differ > only by a rebuild. But in the mean time, for a stable release like Jessie, > it would be nice to be able to take advantage of the good work some > maintainers have put into adapting their packages to M-A. I was planning to propose a minimal fix in dpkg to the release-team, after the current version has migrated. Of course if it is not accepted, then targetted rebuilds might be needed instead, or a decision to ignore it. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141101121711.ga14...@gaara.hadrons.org
Bug#767617: ITP: calculix-ccx -- CalculiX CrunchiX is a three dimensional structual Finite Element Solver
Package: wnpp Severity: wishlist Owner: Wolfgang Fuetterer * Package name: calculix-ccx Version : 2.7 Upstream Author : Guido Dhondt * URL : http://www.calculix.de/ * License : GPL Programming Lang: C, Fortran Description : CalculiX CrunchiX is a three dimensional structual Finite Element Solver Calculix-ccx is a three dimensional structual Finite Element Solver. The upstream URL is: http://www.calculix.de Description from the website: CalculiX is a package designed to solve field problems. The method used is the finite element method. With CalculiX Finite Element Models can be build, calculated and post- processed. The pre- and post-processor is an interactive 3D-tool using the openGL API. The solver is able to do linear and non-linear calculations. Static, dynamic and thermal solutions are available. Both programs can be used independently. This package should contain the finite element solver CalculiX CrunchiX. The pre- and post-processor will be in another package. I prefer to maintain the package under the debian science blend, if that is possible. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141101141003.1700.8858.report...@perditostation.fritz.box
Re: inconsistent versions of M-A: same packages
+++ Marc Glisse [2014-11-01 11:45 +0100]: > Hello, > > sorry for the naive question, but is there a plan for massively > rebuilding all "Multi-Arch: same" packages that have inconsistent > version numbers across architectures before releasing Jessie? I don't know, but I think there should be. Thank you for bringing this up. As you say, currently this is the only way to make multiarch co-installability work properly. I am happy to spend some time scheduling rebuilds to resync all arches to whichever number is highest. This problem will have been made worse by the late-in-the-cycle additions of arm64 and mips64el (despite some effort being made to avoid library binNMUs when there was a choice, specifically to minimise the size of this issue) so it's only fair that us porters take the time to fix it up. The problem evaporates when new source versions are uploaded, and I expect there will be a fair amount more of that before release time due to bugfixes. So I expect the release team have an opinion about the most appropriate time for deciding that some 'version sync only' rebuilds should be scheduled to fix remaining library-version mismatches. It is currently a feature of our bootstrap/import process that we do binNMUs of packages (to rebuild packages originally imported from debian-ports to break cyclic dependency loops on the 'kosher' buildds, or to rebuild profile-built bootstrap packages). And some of these imports have to be library packages, so this issue inevitably arises. Before multiarch this didn't actually matter. They are also heavily used for library transitions where arches have different sets of packages built against an old library (and thus need rebuilding to get rid of the old version). Changes to the system such as a mechanism for rebuilds that didn't change the version number, or changes to dpkg to consider binary rebuilds 'multiarch equivalent' would solve this in a more systematic way. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141101141901.gt28...@stoneboat.aleph1.co.uk
Bug#767631: ITP: ruby-default-value-for -- Provides a way to specify default values for ActiveRecord models
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-default-value-for Version : 3.0.0.1 Upstream Author : Hongli Lai, Phusion * URL : https://github.com/FooBarWidget/default_value_for * License : Expat Programming Lang: Ruby Description : Provides a way to specify default values for ActiveRecord models The default_value_for plugin allows one to define default values for ActiveRecord models in a declarative manner -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141101150508.13695.67554.reportbug@sasalam
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Thu, Oct 30, 2014 at 05:52:07PM +0100, Christoph Anton Mitterer wrote: > - Debian should ship a default set of firewall rules. Are we the only > distro which doesn't do this? I mean a basic ruleset which drops > incoming, accepts outgoing and accepts related,establised is so easy to > do... and it would help for all those cases where services are started > but not yet finally configured/secured by the admin. Are all of our users admins that grasp firewalls? That being said: Related is a subject to debate. You also need to load the appropriate modules that implement the connection tracking. Should we load all of them by default? Just FTP? What about crazy RTSP clients? (AFAIK there's still no sane conntracking for them in the kernel.) I guess that's the kind of point Wouter tried to raise. Computers are still a tool and we should not make it insanely difficult for users to figure out what's broken because someone has a firewalling fetish. Would we even standardize on a single framework? Of course not, we're universal in ALL the things. Packages would need to be able to provide new rules. What about you doing the work to provide such a framework first? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: inconsistent versions of M-A: same packages
On Sat, Nov 1, 2014 at 13:17:11 +0100, Guillem Jover wrote: > [ Fixed CC and M-F-T addresses, and bounced to debian-release. ] > > Hi! > > On Sat, 2014-11-01 at 11:45:56 +0100, Marc Glisse wrote: > > sorry for the naive question, but is there a plan for massively rebuilding > > all "Multi-Arch: same" packages that have inconsistent version numbers > > across architectures before releasing Jessie? > > That's something for the release-team and build admins. > As far as I'm concerned I'm happy to schedule rebuilds if i386 and amd64 aren't in sync. Any other archs I'm not going to touch. Cheers, Julien signature.asc Description: Digital signature
Bug#767709: general: nvidia 340.46-3 + latest jessie updates = periodic GUI hickup
Package: general Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** Today I updated my system with the latest jessie updates, including the kernel update. The last time I updated was a couple of weeks ago. Now there every 10 seconds or so there is a very brief, 1/2 second freeze in Gnome 3.14.1 's interface. Using the restricted nvidia drivers, 340.46-3, with a nvidia quadro k4200. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102013450.2040.90445.reportbug@shadowbox.house
mass bug filing about everything-in-usr
I plan to open 10 other bugs like #767710 about packages that install a symbolic link to a file with the same name in both /bin/ and /usr/bin/, this way preventing a conversion to everything-in-usr. The changes are very simple and I will provide patches at least for the most common packages. The affected packages are: acl coreutils cryptsetup davfs2 debianutils kbd less nano policycoreutils tcsh xfsdump I have already reported 6 related bugs about libraries, but these are bugs even without considering everything-in-usr: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=usrmerge;users=m...@linux.it I have checked the whole archive so I do not expect that I will need to open more bugs. I will try to contribute a lintian check later if nobody beats me to it. For more information about everything-in-usr please read http://anonscm.debian.org/cgit/users/md/usrmerge.git/tree/debian/README.Debian -- ciao, Marco signature.asc Description: Digital signature
