Bug#807309: ITP: montage-wrapper -- Python wrapper for the Montage mosaicking toolkit
Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org,debian-pyt...@lists.debian.org * Package name: montage-wrapper Version : 0.9.8 Upstream Author : Thomas Robitaille * URL : hhttp://astropy.org/montage-wrapper/ * License : BSD-3-Clause Programming Lang: Python Description : Python wrapper for the Montage mosaicking toolkit The montage-wrapper module (formerly python-montage) is an Astropy affiliated package that provides a way to run the Montage Astronomical Image Mosaic Engine from Python, including both functions to access individual Montage commands, and high-level functions to facilitate mosaicking and reprojecting. This is an Astropy Affiliated Package [1]. It will maintained within the Debian Astronomy Working Group. A git repository is created on alioth [2]. Best regards Ole [1] http://www.astropy.org/affiliated/index.html [2] https://anonscm.debian.org/cgit/debian-astro/packages/montage-wrapper.git
Re: Bug#807241: ITP: archlinux-xdg-menu -- Convert freedesktop files to a format used by various WMs
On Sun, Dec 06, 2015 at 04:20:28PM +, Nicholas Bamber wrote: > Package: wnpp > Severity: wishlist > Owner: Nicholas Bamber > > * Package name: archlinux-xdg-menu ^ don't put archlinux in the package name. It might warrant a mention in the long description, however. > Description : Convert freedesktop files to a format used by various WMs ^^^ > xdg-menu generates menus for WMs using the Free Desktop menu standard. ^^^ probably worth expanding WMs to "window managers" to reduce ambiguity. > You can install archlinux-xdg-menu from the official repositories. ^ I wouldn't include this sentence in the package description. > The following WMs are supported: ^ I wouldn't enumerate a list of WMs one-per-line in the long description. Instead do something like twm; ion3; WindowMaker; fvwm2; icewm; blackbox; fluxbox; openbox; awesome. > KDE, Gnome, Xfce, Enlightenment are already XDG compatible. What does this mean? Does it mean you do not need this package if you use on of these environments?
Bug#807315: ITP: memtool -- manipulate and read memory mapped registers
Package: wnpp Severity: wishlist Owner: "Uwe Kleine-König" * Package name: memtool Version : 2015.12.0 Upstream Author : Pengutronix * URL : http://www.pengutronix.de/software/memtool/index_en.html * License : GPLv2 Programming Lang: C Description : manipulate and read memory mapped registers memtool is a program we use at Pengutronix to inspect and modify registers mostly on arm/armhf. It's functions are inspired by the respective functions (md and mw) of the barebox bootloader. Usually it works on /dev/mem but can be used to modify other character devices (like /dev/fb0) for example. There exist some alternatives: - memtool (argh, same name) ftp://ftp.koansoftware.com/public/linux/memtool/memtool.c It's less flexible, doesn't format it's output that nicely and also doesn't include an ascii representation. - devmem2 Similar to memtool. There is an RFP at http://bugs.debian.org/595805 from 2010 which looks orphaned however. Some crititcs pointed out in the bug's log maybe also applies to memtool (hard coding page size, hardcoding sizeof(long) == 4) etc.) but I'm willing to fix these up. - memedit http://www.pengutronix.de/software/memedit/index_en.html this is really clumsy to use because you have to map memory by hand. I'm sure there are more, but I didn't find any of these in Debian. Best regards Uwe
Processed: your mail
Processing commands for cont...@bugs.debian.org: > reassign 807040 xserver-xorg-video-nouveau Bug #807040 [general] general: System hangs and then restarts (kernel panic) Bug reassigned from package 'general' to 'xserver-xorg-video-nouveau'. Ignoring request to alter found versions of bug #807040 to the same values previously set Ignoring request to alter fixed versions of bug #807040 to the same values previously set > End of message, stopping processing here. Please contact me if you need assistance. -- 807040: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807040 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#807242: ITP: bacula-fd5.2 -- legacy bacula file daemon
Package: wnpp Severity: wishlist Owner: Debian Bacula Team * Package name: bacula-fd5.2 Version : 5.2.13 Upstream Author : Kern Sibbald * URL : http://www.bacula.org * License : Mainly GPL, parts LGPL, BSD and others. See http://www.bacula.org/git/cgit.cgi/bacula/tree/bacula/LICENSE?h=Branch-5.2 Programming Lang: C, C++ Description : legacy bacula file daemon Bacula is a set of programs to manage backup, recovery, and verification of data across a network of computers of different kinds. . The file daemon has to be installed on the machine to be backed up. It is responsible for providing the file attributes and data when requested by the Director, and also for the file system-dependent part of restoration. . This package is intended for machines that are backed up from another machine by an older bacula-director (5.x). Once the bacula-director has been upgraded, this package should be replaced by the regular bacula-fd. Bacula directors 5.x and bacula file daemons 7.x aren't compatible, so this package is intended for backup clients on sites where the backup-server is running an older debian release than the client, or don't want to use eventual backported newer bacula packages. This is to address concerns raised in bugs #805306 and #806205. (resent to debian-devel as I missed adding it manually in Cc)
Re: sid on openvz
On 2015-12-05 08:33, Marco d'Itri wrote: > On Dec 03, James Cloos wrote: > > > Most openvz run on kernels based on 2.6.32, often with significant > > updates. These platforms are an important segment, given how affordable > > they are. And Debian "stable" is often too archaic for many needs which > > fit nicely on a small inexpensive server. > > > > There should be a way to continue to use sid on these platforms. > I agree. > > On Dec 04, Paul Wise wrote: > > > > The latest glibc update breaks most sid installs on (typically leased) > > > openvz platforms because it requires a newer kernel version that most > > > openvz vendors advertize. > > Is it possible for these vendors to switch to a newer version of Linux? > Not at this time, there is just no viable replacement: I expect that > it will take a few years for the replacement to mature to the level of > the current 2.6.32 OpenVZ/Virtuozzo kernel. > (The problem is not just implementing the virtualization features with > namespaces but also replacing the resources accounting system.) > > On Dec 04, Vincent Danjean wrote: > > > Perhaps they will be more willing to do it when consumers wont be able > > to install the distribution they want on their VM. > As an hosting provider I can say with some authority that this is not > how it works: nobody is going to replace their OpenVZ/Virtuozzo > infrastructure just because newer Debian releases will not work: they > will just stop supporting newer Debian releases until they will switch > to namespaces-based virtualization (2-5 years?). > > On Dec 04, Aurelien Jarno wrote: > > > If you consider Debian "stable" as too archaic, I am missing words to > > qualify a 2.6.32 kernel released in 2009. Prehistoric maybe? > Unlike Debian, Red Hat keeps backporting new features in the kernels > used by their stable distributions and then will support security fixes > for a very long time. So these kernels are not in any way comparable to > the Debian 2.6.32 ones. Have there also backported recent glibc or systemd to these systems and do they support such a configuration? This is what we are talking about here. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
* Tollef Fog Heen [151207 00:17]: > ]] David Kalnischkies > > > [And before someone complains about PDiff being slow in apt based on > > some years old experience: The PDiff handling was changed nearly two > > years ago… – and apt-file was using PDiffs before already, so no real > > change there] > > Does this mean apt now will only download a single file, regardless of > whether it's grabbing the updates a pdiff or full packages file? In the > past, the problem for me has been that you end up being latency-bound, > rather than bandwidth-bound. I set Acquire::Pdiffs::FileLimit "3"; and have been much happier. Why this (or something near this) wasn't the default from the start, I don't know. The current default is an extremely poor choice. Perhaps someone should file a bug (serverity critical :-P) to get the default changed. ...Marvin
Bug#807330: ITP: python-os-win -- Windows / Hyper-V library for OpenStack projects
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-os-win Version : 0.0.6 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/os-win * License : Apache-2.0 Programming Lang: Python Description : Windows / Hyper-V library for OpenStack projects Os-win is a library that contains Windows / Hyper-V code commonly used in the OpenStack projects: nova, cinder, networking-hyperv. The library can be used in any other OpenStack projects where it is needed. This library is useful in Debian for tests of nova, cinder, networking-hyperv.
Re: Bug#807241: ITP: archlinux-xdg-menu -- Convert freedesktop files to a format used by various WMs
On Mon, Dec 7, 2015 at 5:09 PM, Jonathan Dowland wrote: I expect it would be a good idea to CC the ITP and Nicholas, you might want to bounce your mail. > twm; ion3; WindowMaker; fvwm2; icewm; blackbox; fluxbox; openbox; awesome. Maybe with commas instead? > On Sun, Dec 06, 2015 at 04:20:28PM +, Nicholas Bamber wrote: > >> KDE, Gnome, Xfce, Enlightenment are already XDG compatible. > > What does this mean? Does it mean you do not need this package if you use > on of these environments? Those environments already support the XDG menu standards so they don't need xdg-menu, which is a converter from the XDG menu standard to the custom menu stuff all the non-desktop window-managers use. -- bye, pabs https://wiki.debian.org/PaulWise
Re: sid on openvz
On Dec 07, Aurelien Jarno wrote: > Have there also backported recent glibc or systemd to these systems and > do they support such a configuration? This is what we are talking about > here. The *hosts* still use Centos 6, but so far more recent guests releases, even using systemd, are working fine. -- ciao, Marco signature.asc Description: PGP signature
Bug#807333: ITP: pilkit -- Utilities and processors built for, and on top of PIL
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pilkit Version : 1.1.13 Upstream Author : Matthew Tretter * URL : https://github.com/matthewwithanm/pilkit * License : BSD-3-clause Programming Lang: Python Description : Utilities and processors built for, and on top of PIL PILKit is a collection of utilities for working with PIL (the Python Imaging Library). One of its main features is a set of processors which expose a simple interface for performing manipulations on PIL images. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJWZZ3PAAoJEGlMre9Rx7W2BeoQAIhu27nW+dhqEBjyYkTZkcEk p2xqin97pb6NMZE5hIE1lMzLQXZAQqfxw6ZUcPtFlTUguzM4jnqcxf7fKsGapemj atM947KbUOrBDltDdbIOOviDFcxOISXoT/aIOIj+qNZ4dv90p8YAU3W8gZU8YW2q VDfQ1XLAuDTARMB11Ee+XFzjE/9RBLZyM4WGoZYpwibo9Ubszl1kMqVkJANfTKUN ZLdNZTU4dmlvT5q5ZD5EsTa9H76JtzTrQj2zyHUacoEnP1S5ZNW2w72iW9/toDp1 VDobBUeYATO+ED/fprdXK8sAPQeb0dT9fJdgrdqYrZvlUExc5ghBlkUpH/NLuprf T2lv120vMAX+lzmDX4+CPXpQaN0ghJPdO8PX9BB6aBRZH5oqS9XSfChQzPPQCqwU B76sYxf+CdVoH0rEesbvZu8TTO6QhVxBWryF220SAG+OKH1SZdG8Qsdn5Wgl0Yq5 DDkFtXR/mkbtDdQLyrHCz/4mVKC7L1e9WrRFdoi6Le0h5N18pA0s57FbkjV5X6hf vrOmc39/h8Plj2kLc5RlhKdOE9D7ZHScV4uQ30AYusn+qgOU7cuACxR/HSIyvcqZ R3qsFRvtmER+EzVJ12mxoGhRc4e3NYRbul9QD1VuLj8D+UIwY/Wh+HL8/w85eVqc URPW6Vdsp84ixXtzHgaB =nqLu -END PGP SIGNATURE-
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
Le 06/12/2015 12:15, Norbert Preining a écrit : > * is there a way to track down who uploaded -3+b1? For "who", I don't know. But for "why", cf /usr/share/doc/unison2.40.102/changelog.Debian.amd64.gz: > unison2.40.102 (2.40.102-3+b1) sid; urgency=low, binary-only=yes > > * Binary-only non-maintainer upload for amd64; no source changes. > * Rebuild against ncurses 6.0. > > -- amd64 / i386 Build Daemon (babin) Fri, > 31 Jul 2015 09:50:21 +0200 ...which is strange, because unison doesn't use ncurses AFAICT. Also, the date is misleading; it corresponds to the last sourceful upload, not the binNMU. But I now understand the problem: unison2.40.102 uses Obj.magic (i.e. an unsafe coercion) to cast a format string into a string. The previous unison version was compiled with OCaml 4.01.0, where format strings were indeed strings. The new version was compiled with OCaml 4.02.3, where it is no longer the case. unison2.32.52 should suffer from the same problem. The change done in unison 2.48 to overcome this looks pretty big... I'm not sure I'll be able/willing to provide a unison2.40.102 any more. Moreover, this package was created to provide compatibility with previous Debian releases, but another change in OCaml 4.02 makes it incompatible anyway (both communicating unisons need to be compiled with the same version of OCaml in practice, which won't be the case any more when one side is Debian stable, and the other Debian testing). IMHO, that's a design flaw in Unison that cannot be easily fixed. -- Stéphane
Re: sid on openvz
On 7 December 2015 at 14:50, Marco d'Itri wrote: > On Dec 07, Aurelien Jarno wrote: > >> Have there also backported recent glibc or systemd to these systems and >> do they support such a configuration? This is what we are talking about >> here. > The *hosts* still use Centos 6, but so far more recent guests releases, > even using systemd, are working fine. > Well, for some value of work... Systemd doesn't get cgroups empty notifications in such containers and doesn't clean up cgroups for exited processes. I wonder, if uncleaned up cgroups in systemd tree can cause problems or not. -- Regards, Dimitri.
Re: Bug#807146: ITP: koji -- RPM-based build system
Please coordinate, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806953 On 6 December 2015 at 01:42, Marek Marczykowski-Górecki wrote: > Package: wnpp > Severity: wishlist > Owner: "Marek Marczykowski-Górecki" > > * Package name: koji > Version : 1.10.0 > Upstream Author : Mike McLean , > Dennis Gregorovic , > Mike Bonnet , > Jesse Keating > * URL : https://fedorahosted.org/koji/ > * License : LGPL > Programming Lang: Python > Description : RPM-based build system > > The Fedora Project uses Koji for their build system, as do several other > projects. > > Koji's goal is to provide a flexible, secure, and reproducible way to build > software. > > Key features: > - New buildroot for each build > - Robust XML-RPC APIs for easy integration with other tools > - Web interface with SSL and Kerberos authentication > - Thin, portable command line client > - Users can create local buildroots > - Buildroot contents are tracked in the database > - Versioned data > > The package required to plug Fedora packages into reproducible build testing > infrastructure. > -- Regards, Dimitri.
Re: Future of the Linux upstream tracker
2015-12-06 22:54 GMT+01:00 Ponomarenko Andrey : > [...] > But ... Good news everyone! I've spent about a half-year to implement an > open-source alternative of the tool from scratch and I'm glad to inform you > that it's finally ready and available at: https://github.com/lvc/abi-tracker > > So everyone can set up their own ABI tracker for the interested libraries. > The reports and architecture of the tool are much better than the old ones. > Also I've set up a new small upstream tracker for the core Linux libraries > (glibc, openssl, freetype, Qt, etc.) here: http://abi-laboratory.pro/tracker/ This is awesome! Thank you very much for your work! Cheers, Matthias
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
Dear Stéphane, > But I now understand the problem: unison2.40.102 uses Obj.magic (i.e. an > unsafe coercion) to cast a format string into a string. The previous > unison version was compiled with OCaml 4.01.0, where format strings were > indeed strings. The new version was compiled with OCaml 4.02.3, where it > is no longer the case. unison2.32.52 should suffer from the same problem. Uhh, thanks for tracking this down. > The change done in unison 2.48 to overcome this looks pretty big... I'm > not sure I'll be able/willing to provide a unison2.40.102 any more. That would be a pity. > Moreover, this package was created to provide compatibility with > previous Debian releases, but another change in OCaml 4.02 makes it Unfortunately I am even running old-stable, but till now had no problems using 2.40 with the unison from old-stable. I will need to look into that how I can keep that running. Thanks a lot and all the best Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
