Bug#971795: ITP: git-pw -- tool for integrating Git with Patchwork
Package: wnpp Severity: wishlist Owner: Dimitri John Ledkov X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: git-pw Version : 2.0.0 Upstream Author : Stephen Finucane https://github.com/stephenfin * URL : https://github.com/getpatchwork/git-pw * License : Expat Programming Lang: Python Description : tool for integrating Git with Patchwork Patchwork is the web-based patch tracking system, this tool helps to integrate with it. It was requested at Plumbers to have this in distro's to aid development & code review work.
Bug#924372: O: x4d-icons -- X4D Icon set for various online document types
Package: wnpp Severity: normal I intend to orphan the x4d-icons package. The package description is: Icon set indicating document types and target versions of those specifications e.g. HTML, XHTML, CSS, MathML, etc. These are metric compatible & naming scheme compatible with other logos used for similar purposes. These are "free" unlike the old w3c ones used in many docs.
Bug#924370: O: libica
Package: wnpp Severity: normal Description: hardware cryptography support for IBM System z hardware libica library provides hardware acceleration for cryptographic functions and is part of the openCryptoki project. I shall continue to maintain this in Ubuntu, most likely. Regards, Dimitri.
Bug#924369: O: friendly-recovery -- Make recovery boot mode more user-friendly
Package: wnpp Severity: normal I intend to orphan the friendly-recovery package from Debian. Ubuntu Developer will probably continue to maintain this package in Ubuntu, as it is used there by default. The package description is: Make the recovery boot mode more user-friendly by providing a menu with pluggable options.
Bug#924367: O: mdadm -- tool to administer Linux MD arrays (software RAID)
Package: wnpp Severity: normal I intend to orphan the mdadm package. The package description is: The mdadm utility can be used to create, manage, and monitor MD (multi-disk) arrays for software RAID or multipath I/O. . This package automatically configures mdadm to assemble arrays during the system startup process. If not needed, this functionality can be disabled. Regards, Dimitri.
Bug#924368: O: btrfs-progs -- Checksumming Copy on Write Filesystem utilities
Package: wnpp Severity: normal I intend to orphan the btrfs-progs package. The package description is: Btrfs is a new copy on write filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration. . This package contains utilities (mkfs, fsck) used to work with btrfs and an utility (btrfs-convert) to make a btrfs filesystem from an ext3. Regards, Dimitri.
Bug#917543: ITP: butt -- multi OS streaming audio tool easy to use
Non discriptive package name that happened to be a pun. Please rename. On Fri, 28 Dec 2018, 22:45 Paulo Henrique de Lima Santana (phls) < p...@softwarelivre.org wrote: > Package: wnpp > Severity: wishlist > Owner: "Paulo Henrique de Lima Santana (phls)" > > * Package name: butt > Version : 0.1.17 > Upstream Author : Daniel Noethen > * URL : https://danielnoethen.de > * License : GPL-2+ > Programming Lang: C > Description : multi OS streaming audio tool easy to use > > butt (broadcast using this tool) is an easy to use, multi OS streaming > tool. > It supports ShoutCast and IceCast and runs on Linux, MacOS and Windows. > The > main purpose of butt is to stream live audio data from your computers Mic > or > Line input to an Shoutcast or Icecast server. Recording is also possible. > It > is NOT intended to be a server by itself or automatically stream a set of > audio files. > . > * It Works with SHOUTcast and Icecast. > * It runs on all three major operating systems. Mac OS X, Linux and > Windows. > * It supports aac+, mp3, ogg/vorbis, ogg/opus and flac for streaming. > * It supports aac+, mp3, ogg/vorbis, ogg/opus, flac and wav for recording. > * It is able to connect to a server after starting up automatically. > * It is able to start a recording after connecting to a server > automatically. > * Recording can be split after a user defined amount of time. > * Current song can either be updated manually or automatically by reading > a >file. > * Configuration files can be imported and exported. > * Status display shows infos about the current state (click on it). > * Automatically reconnects in case the connection was interrupted. > * It has a VU Meter with peak hold. > * It is able to attentuate and amplify the input volume. > * It has a 5-band EQ. > * It can read song names from different apps in MacOS and Linux. > * Display colors can be changed as desired. > >
Bug#867807: O: libavg -- media-centric application development platform
Package: wnpp Severity: normal I can't even remember now, how I ended up maintaining this package. I believe it was in ubuntu for a while, and then i was asked to upload it into debian too. The package is in an ok state now, but I'm not sure I will touch it again. It may need a facelift for packaging to be uptodate with most recent standards versions. It is possible that 1.8.2 needs to be packaged from github at https://github.com/libavg/libavg/releases This package is suitable to be adopted by prospective Debian Maintainers and or beginner developers. It is a relatively straight forward, non-core and easy to maintain package. Regards, Dimitri.
Bug#842140: ITP: obs-signd -- open build service signer client and daemon
On 1 March 2017 at 13:47, Riku Voipio wrote: > Hi, > > What's the status with this? Is there some preliminary packaging already? > > Riku > I have done no work at all to support this, however I do think it would be useful to have. -- Regards, Dimitri.
Bug#826774: ITP: genwqe-user -- A hardware accelerated version of zLib using PCIe with FPGA
On Thu, 09 Jun 2016 23:28:32 +0800 Paul Wise wrote: > On Thu, 2016-06-09 at 11:15 -0300, Breno Leitao wrote: > > > That is correct. The bitstream is created with Altera Tools. Yes, > > they are vandor specific and proprietary. > > > > Is this a problem for this ITP? > > I assume this means the package will have to go to contrib. > I probably do not understand this correctly, but isn't a pre-configured card usable by any Linux install for e.g. accelerated zlib compression and decompression. As in this package is not useless without the Altera toolchain, and enables software to execute algorithms with hardware acceleration - isn't it not dissimilar to e.g. openssl engines or mesa? and thus can live in main? Or does one supposed to upload bitstream onto the cards on every boot? Like e.g. non-free/intel-microcode package? Regards, Dimitri.
Bug#846401: ITP: fswatch -- File change monitor that receives notifications on file or directory changes
On 1 Dec 2016 00:36, "Alf Gaida" wrote: > > Package: wnpp > Severity: wishlist > Owner: Alf Gaida > > * Package name: fswatch > Version : 1.9.96 > Upstream Author : Enrico M. Crisostomo > * URL : https://github.com/emcrisostomo/fswatch > * License : GPL-3+ > Programming Lang: C, C++ > Description : File change monitor that receives notifications on file or directory changes > > fswatch is a file change monitor that receives notifications when the contents of the specified systemd has native path units for inotify already. Are you packaging this just for kfreebsd? If packaging for Linux too - why not simply use systemd units? > files or directories are modified. fswatch implements four kinds of monitors: > * A monitor based on the File System Events API of Apple OS X. > * A monitor based on kqueue, a notification interface introduced in FreeBSD 4.1 (and supported >on most *BSD systems, including OS X). > * A monitor based on the File Events Notification API of the Solaris kernel and its derivatives. > * A monitor based on inotify, a Linux kernel subsystem that reports file system changes to applications. > * A monitor based on ReadDirectoryChangesW, a Microsoft Windows API that reports changes to a directory. > * A monitor which periodically stats the file system, saves file modification times in memory, and >manually calculates file system changes (which works anywhere stat (2) can be used). > > fswatch should build and work correctly on any system shipping either of the aforementioned APIs. >
Bug#781530: Importing libdfp into Debian
Hello, On 25 November 2016 at 09:17, Frederic Bonnard wrote: > > Dimitri, > I see you are the latest maintainer having worked on libdfp. > Would you have some time to import libdfp from Ubuntu to Debian ? > If not, would you mind I do that ? > Regards, > > F. > Yes, I can reupload libdfp from ubuntu into debian and close this ITP. Do you want to still be listed as the maintainer/uploader? I'm not making commitments to maintain this in Debian longer term =) -- Regards, Dimitri.
Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles
On 21 November 2016 at 17:54, Jay Wren wrote: > > I am happy that swap partitions are finally going away. > Note, no such decisions made for Debian. Debian still uses swap partitions by default, and I don't see that changing for the upcoming release. I'm simply working on an alternative to use swapfiles. There are still limitations in swapfile usage - e.g. not available on btrfs & zfs. > Is there any reason to do all of the above rather than install swapspace? > For example, on low memory systems swapfile created by partman-swapfile is activated before debootstrap is run, and thus swap is available for use much earlier in the install process. Which may be required to complete debootstrap. Also I don't like how swapspace package is implemented :-P And I prefer having an ability to tune dynamic seeding via d-i pressed infrastructure on the per installation basis. > http://pqxx.org/development/swapspace > > I’ve manually partitions with no swap and installed swapspace after install > for years with great success. > > Thanks, > — > Jay > -- Regards, Dimitri.
Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles
On 18 November 2016 at 11:56, Steve McIntyre wrote: > On Fri, Nov 18, 2016 at 11:44:25AM +0000, Dimitri John Ledkov wrote: >>Package: wnpp >>Owner: Dimitri John Ledkov >>Severity: wishlist >> >>* Package name: partman-swapfile >> Version : 1 >> Upstream Author : d-i team >>* URL or Web page : d-i >>* License : GPL >> Description : add support for creating swapfiles >> >>I am working on minimising number of partitions used in the default >>instalations in Ubuntu. > > Might I ask why? Multiple reasons. Mostly surrounding supportability, and flexibility for migrations / future changes. There are a lot of people with dedicated /boot partitions, which are full, preventing security kernel upgrades to succeed. At the same time, people who are vulnerable to this, have no idea what a /boot partition is, or how to run $ sudo apt autoremove to remove old kernels. Booting off LVM, makes /boot part of the rootfs and hopefully reduces chances of running out of all the disk space, because even less sophisticated users tend to notice that. As a side-effect this makes /boot an ext4 filesystem in more cases. I'm thinking to move /boot to be ext4 by default in Ubuntu. Such that it is the same regardless of the autopartitioning method. Similarly with swap. One can dynamically resize/remove swapfile to add swap or reclaim disk-space. And I am seeing a lot of systems that have missized swaps. Having a 512GB swap, on a 1TB NVMe hard drive is obscene when one has 256GB RAM. Other distributions (e.g. RHEL) have started to limit swap well below the total amount of RAM. Note, in Ubuntu, hibernation is disabled by default, therefore swap is only used for the purpose of extreme memory pressure when things balloon (e.g. during large process start-up before parts of it can be swapped out). Backup & restore / migration is simplified if a single partition represents all of Ubuntu. This has been the case for a long time, on e.g. cloud images. (UEFI & PReP partitions notwithstanding Har Har Har) Hence, it's just a general simplification, to make sure that default installations are as sensible and as future proof as possible, and are easier to modify if one realizes that one has miss-sized things. Given that grub2 can unlock luks partitions, I wish it had some way to pass the encryption secret to the kernel, such that /boot can be on encrypted LVM as well, without needing to type the full disk encryption passphrase twice on boot. Note, that Debian supports a lot more architectures and a wider range of machine configurations. I only have insight in a subset of these, thus I am aware that above goals are potentially unachievable on the more exotic machine types & bootloaders. -- Regards, Dimitri.
Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles
On 18 November 2016 at 12:02, Philipp Kern wrote: > On 18.11.2016 12:44, Dimitri John Ledkov wrote: >> Another thing I am investigating is moving away from swap partitions to >> swap files, on non-lvm installations. This will involve tweaking the >> default partman-auto recipes & the no-swap warning. > > Note that you should then also check that the memory available to the > installer is sufficient to proceed without swap. (Especially for locales > generation and such.) > Right so the no-swap warning comes after partitioning scheme is finalised, but before swapfile is created and activated. I still want to default to having some swap. But have that provided via swap partition, or a swapfile. So far my scripts are a bit hackish as the swapfile does not form part of the parted aware things / something one cas specify in partman-auto recipes. It really is tucked on the side, in finish.d, at the moment. I have no solution yet for e.g. partman-auto automic recipe which uses swapfile, if the rootfs filesystem is ext4; but creates a swap partition if the rootfs filesystem is btrfs. And i'm not quite sure how to express that in the recipe, or decode it. -- Regards, Dimitri.
Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: partman-swapfile Version : 1 Upstream Author : d-i team * URL or Web page : d-i * License : GPL Description : add support for creating swapfiles I am working on minimising number of partitions used in the default instalations in Ubuntu. One of the things I have done already in Ubuntu is to tweak and not use dedicated /boot partition for non-encrypted LVM based installations. Simply by tweaking the partman-auto recipes, on architectures/bootloaders that support booting off LVM. Another thing I am investigating is moving away from swap partitions to swap files, on non-lvm installations. This will involve tweaking the default partman-auto recipes & the no-swap warning. However, to provide swapfiles out of the box I wrote this partman-swapfile module which hooks into /lib/partman/finish.d to create /target/swapfile with an appropriate stanza in /target/etc/fstab. Care is taken not to create swapfiles uncessory, reuse existing one, or do nothing if a swap partition is already present, or swapfiles not supported on a given filesystem (e.g. btrfs). There are two control options to configure the size of the swapfile. Absolute size, and percentage of free space on the rootfs. The defaults are 2GB and 5%, meaning the swapfile will be 2GB in size or 5% of the free space on rootfs, whichever is lower. Setting the size or percentage to zero will skip creating the swapfile. This is a strategy to make sure there is some swap available, without wasting too much of disk space on high-memory-to-disk ratio systems (e.g. 1TB of RAM with a 200GB hard drive). I am not at all sure if this functionality is at all welcomed, needed, or will generate any interest. I do not know if it's wanted to be available by default in Debian's d-i. At the moment I created a git repository in the d-i team, and plan to upload this to experimental for people to try this out. On the implementation side, swapfile is allocated using fallocate (if avaialble and target filesystem creates files without holes using fallocate) otherwise "slow" dd is used. This makes swapfile creation really quick on ext4 rootfs. All the glory details are here: https://anonscm.debian.org/cgit/d-i/partman-swapfile.git/tree/finish.d Regards, Dimitri.
Bug#842140: ITP: obs-signd -- open build service signer client and daemon
On 26 October 2016 at 10:14, Andrew Lee wrote: > Package: wnpp > Severity: wishlist > Owner: "Andrew Lee (李健秋)" > > * Package name: obs-signd > Version : 2.3.0 > Upstream Author : Michael Schröder > * URL : https://github.com/openSUSE/obs-sign > * License : GPL-2+ > Programming Lang: C > Description : open build service signer client and daemon > > This daemon can be used to sign anything via gpg, but it speaks with > a remote server to avoid the need to host the private key on the same > server. > Does this still require a patched/custom gnupg? -- Regards, Dimitri.
Bug#813901: ITP: btrfsmaintenance -- Btrfs maintenance toolbox
On 6 February 2016 at 14:06, Ioan Eugen Stan wrote: > Package: wnpp > Severity: wishlist > Owner: Ioan Eugen Stan > > * Package name: btrfsmaintenance > Version : 0.1.2 > Upstream Author : Dave > * URL : https://github.com/kdave/btrfsmaintenance > * License : GPL2 > Programming Lang: shell > Description : Btrfs maintenance toolbox > > This is a set of scripts supplementing the btrfs filesystem and aims to > automate a few maintenance tasks. This means the scrub, balance, trim or > defragmentation. > Each of the tasks can be turned on/off and configured independently. The > default config values were selected to fit the default installation profile > of > openSUSE 13.2 where the root filesystem is formatted to btrfs. Support for > other distros is possible and patches are welcome. > Overall tuning of the default values should give a good balance between > effects > of the tasks and low impact of other work on the system. If this does not fit > your needs, please adjust the settings. > > I am looking for co-mainteiners for this package. > I do need a sponsor for this package. > I can review / sponsor, if you put a source package onto mentors. -- Regards, Dimitri.
Bug#813772: ITP: openssl-ibmca -- libica based hardware acceleration engine for OpenSSL
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: openssl-ibmca Version : 1.3.0 Upstream Author : openCryptoki Project * URL or Web page : http://sourceforge.net/projects/opencryptoki/files/libica%20OpenSSL%20Engine/ * License : OpenSSL-like BSD-4-Clause-like Description : libica based hardware acceleration engine for OpenSSL This package provides an OpenSSL engine to enable hardware acceleration of cryptographic functions in OpenSSL, and all applications that use OpenSSL. This package is specific for s390x architecture. Regards, Dimitri.
Bug#813765: ITP: libica -- hardware cryptography support for IBM System z hardware
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: libica Version : 2.5.0 Upstream Author : openCryptoki project, IBM Corp * URL or Web page : http://sourceforge.net/projects/opencryptoki/files/libica/ * License : Common Public License V1.0 Description : hardware cryptography support for IBM System z hardware I would like to package libica 2.5.0 component of openCryptoki project for s390x Debian port. This is a userspace support library, that provides hardware accelerated cryptography in userspace, with fallbacks when hardware acceleration is not available. This is part of the dependency stack to provide e.g. accelerated openssl on s390x. Improved description for the debian/control file are welcomed, as I lack literacy skills to write those nicely. Currently I have: """ Description: hardware cryptography support for IBM System z hardware libica library provides hardware acceleration for cryptographic functions and is part of the openCryptoki project. """ Regards, Dimitri.
Bug#809362: ITP: opendht -- lightweight C++11 distributed hash table implementation
Hello, On 29 December 2015 at 20:03, Tomasz Buchert wrote: > Package: wnpp > Severity: wishlist > Owner: Tomasz Buchert > > * Package name: opendht > Version : v0.5 > Upstream Author : 2014-2015 Savoir-Faire Linux Inc. > * URL : https://github.com/savoirfairelinux/opendht > * License : GPL3, MIT > Programming Lang: C++ > Description : lightweight C++11 Distributed Hash Table implementation > > A lightweight C++11 Distributed Hash Table implementation originally > based on https://github.com/jech/dht by Juliusz Chroboczek. > . > * Light and fast C++11 Kademlia DHT library > * Distributed shared key->value data-store > * Clean and powerful distributed map API with storage > of arbitrary binary values of up to 128 KB > * Optional public key cryptography layer providing data signature > and encryption (using GnuTLS) > * IPv4 and IPv6 support > Software in general is weightless, unless, of course one prints a hardcopy book of it via a publisher (e.g. MIT Press) and takes it across the border. ( https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Criminal_investigation ) Yet pretty much every project on github claims to be "lightweight", "fast", etc. Would it hurt to drop "lightweight", "light and fast" etc? Do these adjectives have any meaning really? -- Regards, Dimitri.
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.
Bug#777694: RFA: icu -- Development utilities for International Components for Unicode
On Wed, 11 Feb 2015 10:29:24 -0500 Jay Berkenbilt wrote: > Package: wnpp > Severity: normal > > I request an adopter for the icu package as I no longer have time to > maintain the package. > I am happy to help out, not as main maintainer but uploader/contributor. I also contribute to boost. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUg3On3vKYT0tSWbWz6JVACsTiuAqAGG_M58JpHW=eq...@mail.gmail.com
Bug#774744: ITP: obs -- Open Broadcast Software
On 9 January 2015 at 16:02, Carl Fürstenberg wrote: > The frontend is called "obs-studio", though it contains a library called > libobs0, thus I felt calling the source package obs-studio a bit wrong. > At the moment, the binary packages would be obs-studio, obs-plugins, > libobs0, libobs-dev, and libobs0-dbg. > These look like good binary package names. obs-studio sounds like a good source package name as well (it's mostly non-user visible anyway). Thanks! > But true, the source package though could be renamed to obsproject or > similar; I'll have to talk to upstream first what they recommend. > > On Wed, Jan 7, 2015 at 10:20 PM, Dimitri John Ledkov > wrote: >> >> Hello, >> >> On 7 January 2015 at 01:57, Carl Fürstenberg wrote: >> > >> > Package: wnpp >> > Severity: wishlist >> > Owner: "Carl Fürstenberg" >> > >> > * Package name: obs >> > Version : 0.7.2 >> > Upstream Author : Hugh Bailey >> > * URL : https://obsproject.com/ >> > * License : GPL >> > Programming Lang: C, C++ >> > Description : Open Broadcast Software >> > >> > a rewrite of what was formerly known as "Open Broadcaster Software", >> > software originally designed for recording and streaming live >> > video content, efficiently. >> > >> >> obs also means "open build service" and we have "obs-build" already >> packaged. ( a component of it) >> >> Would you mind using a more verbose name for source & binary packages? >> e.g. obsproject or open-broadcast? >> >> -- >> Regards, >> >> Dimitri. > > > > > -- > Carl Fürstenberg -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlugooks-nptv2arj+tnorwvwtj5p-bqeq6vczggawsn...@mail.gmail.com
Bug#774744: ITP: obs -- Open Broadcast Software
Hello, On 7 January 2015 at 01:57, Carl Fürstenberg wrote: > > Package: wnpp > Severity: wishlist > Owner: "Carl Fürstenberg" > > * Package name: obs > Version : 0.7.2 > Upstream Author : Hugh Bailey > * URL : https://obsproject.com/ > * License : GPL > Programming Lang: C, C++ > Description : Open Broadcast Software > > a rewrite of what was formerly known as "Open Broadcaster Software", > software originally designed for recording and streaming live > video content, efficiently. > obs also means "open build service" and we have "obs-build" already packaged. ( a component of it) Would you mind using a more verbose name for source & binary packages? e.g. obsproject or open-broadcast? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhluj_13vdy5j9dzs4utyoadtagmbnlrwh3qzbtk8s50h...@mail.gmail.com
Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot
On 9 October 2014 10:42, Mike Gabriel wrote: > Hi Dimitri, > > > On Do 09 Okt 2014 11:18:30 CEST, Dimitri John Ledkov wrote: > >> On 9 October 2014 08:43, Mike Gabriel >> wrote: >>> >>> Hi Dimitri, >>> >>> >>> On Do 09 Okt 2014 08:45:17 CEST, Dimitri John Ledkov wrote: >>> >>>> Hey, >>>> >>>> On 9 October 2014 05:21, Mike Gabriel >>>> wrote: >>>>> >>>>> >>>>> Package: wnpp >>>>> Severity: wishlist >>>>> Owner: Mike Gabriel >>>>> >>>>> * Package name: obs-build >>>>> Version : Git snapshot (every commit is a release) >>>>> Upstream Author : Michael Schroeder (https://github.com/mlschroe) >>>>> * URL : https://github.com/openSUSE/obs-build >>>>> * License : GPL >>>>> Programming Lang: Perl >>>>> Description : Build DEB/RPM packages for various distributions >>>>> inside a chroot >>>>> >>>>> OBS Build creates chroots and builds DEB/RPM packages for various >>>>> Linux distributions. In Debian, this package fills a gap: it allows >>>>> one >>>>> to >>>>> build packages for the openSUSE/SLES distributions on Debian system. >>>>> . >>>>> Its only task is to reliably populate a chroot and attempt to build >>>>> a package in that chroot. It is used by the Open Build System provided >>>>> by SUSE, but can also be use as a standalone tool. >>>>> . >>>>> Optionally, builds can take place in KVM or XEN instance. >>>>> >>>> >>>> I think we had a mid-air collision: >>>> https://ftp-master.debian.org/new/obs-build_20140918-1.html >>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949 >>>> >>>> I'm happy to co-maintain this package. >>> >>> >>> >>> Yeah. I saw Adams mail early this morning. >>> >>> I have the package nearly ready... Do you have anything packaged, yet? Or >>> shall I just add you to Uploaders: (with what mail address)? >>> >>> I plan to push the packaging Git to collab-maint (or have you already >>> provided a packaging repo there?) >>> >> >> It's in the new queue. > > > Ah... ok... (damn that I did not notice...). > >> I use a combination of git-dpm & dgit. Which although useful, has >> quilt noise committed as patches. (Maybe I should use stand-alone >> branch for dgit/quilt noise). >> >> You should be able to fetch it with: >> $ dgit clone obs-build >> >> Or I've now pushed a "normal" git master branch thus it's >> visiable/clonable with git itself as well: >> http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/ > > > Ok. Thanks. Just did some reading of the debian/ folder. > > I also pushed my latest changes to collab-maint/obs-build.git so you can > introspect them. > >> In terms of patches, I have: >> Use obs-build namespace, similar to your patch. >> >> http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0001-Use-obs-build-in-locations-and-executable-names-inst.patch > > >> I fixed & submitted upstream a bug with createzypp repository script. >> >> http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0002-Fix-Build-Zypp-parsecfg-expected-full-config-file-na.patch > > > >> I do not move project configurations to /etc, as I don't think that's >> right. Released distribution configurations should be frozen, to have >> reproducible builds locally. > > > Ok. That sounds reasonable. > >> Custom/non-upstream distro configs should either be patched/applied in >> the Debian package, packaged separately and install into same config >> location, or passed to obs-build via command-line option. >> We really don't want people to modify build configuration files for >> volatile distribution (e.g. Factory, Rawhide, Sid, etc) and then never >> get upgraded when those change, due to how config-files are handled. > > > Ok. Agreeing on that. > >> Maybe it makes sense to patch obs to support multiple locations? E.g. >> /etc/obs-build/configs and /usr/lib/obs-build/configs? > > > That surely is an option. > > What concerns me most about your upload is the version number. > Yeah
Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot
On 9 October 2014 08:43, Mike Gabriel wrote: > Hi Dimitri, > > > On Do 09 Okt 2014 08:45:17 CEST, Dimitri John Ledkov wrote: > >> Hey, >> >> On 9 October 2014 05:21, Mike Gabriel >> wrote: >>> >>> Package: wnpp >>> Severity: wishlist >>> Owner: Mike Gabriel >>> >>> * Package name: obs-build >>> Version : Git snapshot (every commit is a release) >>> Upstream Author : Michael Schroeder (https://github.com/mlschroe) >>> * URL : https://github.com/openSUSE/obs-build >>> * License : GPL >>> Programming Lang: Perl >>> Description : Build DEB/RPM packages for various distributions >>> inside a chroot >>> >>> OBS Build creates chroots and builds DEB/RPM packages for various >>> Linux distributions. In Debian, this package fills a gap: it allows one >>> to >>> build packages for the openSUSE/SLES distributions on Debian system. >>> . >>> Its only task is to reliably populate a chroot and attempt to build >>> a package in that chroot. It is used by the Open Build System provided >>> by SUSE, but can also be use as a standalone tool. >>> . >>> Optionally, builds can take place in KVM or XEN instance. >>> >> >> I think we had a mid-air collision: >> https://ftp-master.debian.org/new/obs-build_20140918-1.html >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949 >> >> I'm happy to co-maintain this package. > > > Yeah. I saw Adams mail early this morning. > > I have the package nearly ready... Do you have anything packaged, yet? Or > shall I just add you to Uploaders: (with what mail address)? > > I plan to push the packaging Git to collab-maint (or have you already > provided a packaging repo there?) > It's in the new queue. I use a combination of git-dpm & dgit. Which although useful, has quilt noise committed as patches. (Maybe I should use stand-alone branch for dgit/quilt noise). You should be able to fetch it with: $ dgit clone obs-build Or I've now pushed a "normal" git master branch thus it's visiable/clonable with git itself as well: http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/ In terms of patches, I have: Use obs-build namespace, similar to your patch. http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0001-Use-obs-build-in-locations-and-executable-names-inst.patch I fixed & submitted upstream a bug with createzypp repository script. http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0002-Fix-Build-Zypp-parsecfg-expected-full-config-file-na.patch I do not move project configurations to /etc, as I don't think that's right. Released distribution configurations should be frozen, to have reproducible builds locally. Custom/non-upstream distro configs should either be patched/applied in the Debian package, packaged separately and install into same config location, or passed to obs-build via command-line option. We really don't want people to modify build configuration files for volatile distribution (e.g. Factory, Rawhide, Sid, etc) and then never get upgraded when those change, due to how config-files are handled. Maybe it makes sense to patch obs to support multiple locations? E.g. /etc/obs-build/configs and /usr/lib/obs-build/configs? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUjmoN=mamyekzog0efhz3k5lys2sbdbmmxjcbegmub...@mail.gmail.com
Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot
Hey, On 9 October 2014 05:21, Mike Gabriel wrote: > Package: wnpp > Severity: wishlist > Owner: Mike Gabriel > > * Package name: obs-build > Version : Git snapshot (every commit is a release) > Upstream Author : Michael Schroeder (https://github.com/mlschroe) > * URL : https://github.com/openSUSE/obs-build > * License : GPL > Programming Lang: Perl > Description : Build DEB/RPM packages for various distributions inside a > chroot > > OBS Build creates chroots and builds DEB/RPM packages for various > Linux distributions. In Debian, this package fills a gap: it allows one to > build packages for the openSUSE/SLES distributions on Debian system. > . > Its only task is to reliably populate a chroot and attempt to build > a package in that chroot. It is used by the Open Build System provided > by SUSE, but can also be use as a standalone tool. > . > Optionally, builds can take place in KVM or XEN instance. > I think we had a mid-air collision: https://ftp-master.debian.org/new/obs-build_20140918-1.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949 I'm happy to co-maintain this package. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlui2qyhccdx5gryhgnfbyjjxupe+lgs17kdb5gdbfq9...@mail.gmail.com
Bug#762949: ITP: obs-build -- scripts for building RPM/debian packages for multiple distributions
On 26 September 2014 14:58, Neil Williams wrote: > On Fri, 26 Sep 2014 14:19:24 +0100 > Dimitri John Ledkov wrote: > >> Package: wnpp >> Owner: Dimitri John Ledkov >> Severity: wishlist >> >> * Package name: obs-build >> Version : 20140918 >> Upstream Author : Adrian Schröter >> * URL or Web page : https://github.com/openSUSE/obs-build >> * License : GPL-2+ >> Description : scripts for building RPM/debian packages for >> multiple distributions >> >> This package provides scripts for building RPM and debian packages in >> contained environments for various build distributions. These tools >> are use by Open Build Service workers and openSUSE distribution by >> default. >> >> By default it claims very generic paths: >> /usr/bin/build >> /usr/lib/build >> >> I'm planning to keep those as per upstream, if however there are >> strong objections I'd be happy to change those to obs-build. > > Any number of packages could have claimed /usr/bin/build by now, > instead we have sbuild, debuild, pdebuild, make, dpkg-buildpackage, > git-buildpackage and a host of others. I don't see that obs deserves to > be the "one true build" which may be the impression given by an overly > common binary name. > So i've patched obs-build to use obs-build and tested out osc with it. Which turned out hardcoded paths to /var/lib/build in some legacy support checks. Filed bug-report which has been fixed upstream. obs-build uploaded, and should hit new queue soon. Once it's in, I'll propose for osc to cherry-pick that upstream commit, set build-cmd to "obs-build" and depend/recommend/suggest obs-build package. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUjPibkyVnEqB8cQH_wfYgt98=kumxz1a8eogsckcq_...@mail.gmail.com
Bug#762949: ITP: obs-build -- scripts for building RPM/debian packages for multiple distributions
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: obs-build Version : 20140918 Upstream Author : Adrian Schröter * URL or Web page : https://github.com/openSUSE/obs-build * License : GPL-2+ Description : scripts for building RPM/debian packages for multiple distributions This package provides scripts for building RPM and debian packages in contained environments for various build distributions. These tools are use by Open Build Service workers and openSUSE distribution by default. By default it claims very generic paths: /usr/bin/build /usr/lib/build I'm planning to keep those as per upstream, if however there are strong objections I'd be happy to change those to obs-build. This package will enchnace osc by making `osc build' be able to do local package builds against various distributions out there. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878ul61pur@djledkov-mobl1.ger.corp.intel.com
Bug#756758: ITP: lazr.authentication -- library providing middleware basic and OAuth authentication
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: lazr.authentication Version : 0.1.2 Upstream Author : William Grant, Dimitri John Ledkov * URL or Web page : https://launchpad.net/lazr.authentication * License : LGPL (v3) Description : library providing middleware basic and OAuth authentication A self-contained, easily reusable, Python library for basic and OAuth authentication. With it you can protect resources with authentication methods, and stack them as well. This is a small, self-contained and simplistic package, part of the lazr python namespace providing authentication middlewares. I'd like to package it, as it's used in the test-suites of launchpadlib dependencies and having ability to execute complete test-suites is paramount to verify python3 port of launchpadlib. This package will be maintained in debian-python modules team. Stefano is pre-listed as an uploader (as the maintainer of a few other lazr.* packages). Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4v8v2fm@debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28 July 2014 15:05, Andreas Cadhalpun wrote: > On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: >> >> On Mon, 28 Jul 2014, Norbert Preining wrote: >>> >>> On Sun, 27 Jul 2014, Reinhard Tartler wrote: >>>> >>>> In [1], Moritz from the security team clearly stated that he is more >>>> than uncomfortable with having more than one copy of libavcodec in >>>> debian/testing. In consequence this means that any package that builds >>>> >>>> against the ffmpeg packages currently in NEW won't make it into >>>> testing either. I am therefore surprised about the given answer to the >>> >>> >>> "More than uncomfortable" does not mean "will not be included" >> >> >> Yes, it does. >> >> Someone will have to convince the security team somehow, likely by >> offering >> to do the work themselves _and_ convincing them that these new members >> will >> be around for long enough. > > > Michael Niedermayer from FFmpeg upstream volunteered "to help with any > future security issues in FFmpeg packages in debian" [1]. > >> However: >> >> The change in Debian-specific symbol versioning and sonames being done to >> ffmpeg so that it is co-installable with libav *is* a problem. >> >> It has to be done in coordination with the Canonical guys, so that both >> Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol >> versioning. Otherwise, the ffmpeg packages will be of very limited use >> (useless to run third-party binary-only games ;-p). > > > I don't think coordination with Ubuntu will be a problem. > In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov > wrote that Ubuntu won't introduce FFmpeg on it's on, but instead: > "If you wish to see a supported ffmpeg stack in both Debian and Ubuntu, > please become a developer and start maintaining it in Debian." I don't have an opinion about ffmpeg vs libav, apart from how hard the soname transitions are, especially in ubuntu where we somehow ended up with ex-multimedia packages around that either never were in debian, or have been long removed from testing and/or unstable. Thankfully, we have worked to make sure libav is in universe only and thus is not a security maintenance burden. Nonetheless, libav10 transition is still not complete in utopic today. I haven't checked, but now abi compatible/incompatible the two stacks are? cause it would be a pain if they are not drop in replacements, and it would also be a pain if higher up packages link-in both ffmpeg & libav and some clashing symbols are present... and people start requesting to have build variants against both. Has a rebuild of all deps been done? How many build failures there are? (On both debian & ubuntu, ideally) Is hardening flags / toolchain enabled in both, or either of the two? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhluhhhjz7fk26we2qf1h2ss5ynfahwzqx8lfz7wbxsbk...@mail.gmail.com
Bug#754910: cgmanager_0.20-1_amd64.changes REJECTED
On 25 July 2014 15:28, Daniel Baumann wrote: > Serge Hallyn >> Anyway, I'll be posting a new 0.28 release later today, based upon >> which Daniel will post a new package, with himself listed as >> maintainer. We'll proceed from there. > > seems these words are not worth anything. > > instead, Serge uploaded a new version (through Steve) yesterday, and > ftp-master (eventhough being kept in the loop on all mails in #754910) just > happily accepted that right away. > > i spend quite some time on this package, all in vain. hope at least you're > happy with the way you treat people, because i'm not. > I'm sorry you feel this way, however my original complaint against your development around it still stands: please file ITPs in the future, and please use multiarch for any new libraries, and please talk to upstream about packaging things, and please have vested intrinsic knowledge of a given software before embarking on trivial packaging work around it. Debian is way past the point where we rapidly trivially package things to "get it in first". Instead we really are after meritocracy, and making sure the best people available take care of the individual parts of our operating system. I'm sure your patches to cgmanager or any other software in Debian is highly welcome and would be applied/reviewed/NMUed as appropriate. I value your contributions to Debian, especially when it's something extraordinary and new. Redoing readily available debian compatible packaging from scratch, is - all in vain, and I still don't see how that gave Debian or yourself any competitive advantage, apart from ultimately delaying integration of newer core components in Debian. Back when I was not a DD, I was seeking sponsorship through my teams and debian-mentors mailing-list / irc channel. At the time, it was clear that sponsors were setting the standards much higher than what's required and recommended by policy. To the point of refusing to sponsor things, until everything was perfect. As a sponsor today, I try to adhere to the same high standards, but it looks like that may be slipping in the project. Collectively we should be making sure that Debian is more like a zen garden, than a kitchen sink. ps. not sure why leader is added to the CC. If you feel you are not treated well in Debian Project, you should contact Debain Anti Harassment team at antiharassment@d.o email alias to discuss and resolve your concerns. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhluh7g0pv74e3f90wyzojsqeecjkoxmxsmjctyrz1nm5...@mail.gmail.com
Bug#754910: cgmanager_0.20-1_amd64.changes REJECTED
On 16 July 2014 19:30, Thomas Goirand wrote: > Hi Paul, > > Thanks for this message. > > On 07/17/2014 01:00 AM, Paul Richards Tagliamonte wrote: >> Issues with 0.20: >> The -dev package situation is still broken. Either properly split your >> libraries or drop the -dev. Please see the mails from ansgar on this topic. >> This is a blocker for inclusion. > > I'm sorry if this sounds not so cool, but I'm not sure I get this. > Ansgar wrote that there should be a -dev package (on which Daniel wrote > back that he thought it'd be micro-packaging, which is something that > the FTP masters have for a long time advocate against), and now you're > advising that dropping the -dev package could be a solution. At the moment, upstart package is cross-compilable and for it to stay cross-compilable it's build-dependencies should be installable on the host, or ideally co-installable for multiple architectures. Shipping libcgmanager.so.0 in cgmanager package prevents that, since installing cgmanager-dev would install foreign arch cgmanager potentially nuking your init from under ones feet if one is running upstart as pid 1. Hence from upstart/lxc/systemd-shim packaging point of view, I request that in debian libcgmanager0 & libcgmanager-dev [*] are present, and are Architecture:any and Multi-Arch:same. An example of this can be found in the current Ubuntu packaging, but can be implemented otherwise. (this way cgamanger:native can continue to function, whilst for example libcgmanager-dev:armhf can be used for cross-compilation). If believe I've pointed that out as well in my first review of Daniel's packaging. Whilst it may appear as micro-packaging, it is necessary for cross-compilation purposes & to run multiarch binaries (e.g. i386 binaries that link against libcgmanager0 on amd64) both of which have been and/or are ongoing Debian Release goals. [*] these are just semantic names -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUh4qaft+XMairZCmpuFZpGY=ajs49cdht5j4lnvaqm...@mail.gmail.com
Bug#754910: Re: cgmanager: two different maintainers
owner 754910 Serge Hallyn thanks On 07/16/2014 01:08 PM, Daniel Baumann wrote: > owner 754910 Daniel Baumann > thanks > > On 07/16/2014 01:53 PM, Ansgar Burchardt wrote: >> there are currently two different versions of cgmanager in NEW, packaged >> by two different maintainers... It might be a good idea for you to agree >> on how to proceed. > > given that my upload is pending in NEW since March 2014 (with a > re-upload in June), I think it's clear to go forward by processing my > package, drop Serges one. > > Serge and I can work out later on how to collaborate on cgmanager > packaging in Debian. > In debian, we have process to mitigate contention which is ITP bugs. Please file ITP bugs before packaging software and uploading. Also it's rude to take over ownership of the ITP bugs one did not file, or get permission to transfer ownership of. Serge is upstream committer for cgmanager and linuxcontainers projects, and has been maintaining that package in Ubuntu since 20th of January 2014. As well as contributing patches and fixes to integrate cgroups support in systemd-shim, upstart, lxc, systemd(logind) and libvirt. And he is very active in Debian QEMU Team packaging team. Looking at the packaging, the two are mostly equivalent, apart from Daniel's is packaged from scratch using different package names and layouts which would be disrubtive when merging into Ubuntu. Why did you not import Ubuuntu packaging or contact Ubuntu maintainers about it, given that re-packaging in Debian does affect Ubuntu. Or contact ustream about packaging it in Debian? (which would coincidently reach the same person). Specifically in your packaging, libcgmanager0 is not a separate multi-arch:same package which would prevent multiarch binaries and libraries depending on libcgmanager0. Between the two, Serge has better in-depth package knowledge than Daniel, upstream connections and better cooperation with other packages that need/want to integrate with cgmanager (e.g. sending patches to those upstreams and maintainers to optionally use cgmanager), and imho better packaged version of cgmanager, for which he has filed ITP as per debian processes given that it is required to update systemd-shim for impeding v208 api compatibility update. My preference as someone involved in upstart package maintenance in Debian, for Serge and/or Debian QEMU team to maintain cgmanager, for which next upstart update (1.13) will build-depend on. Please review for acceptance Serge's packaging. ps. I sponsored serge's package upload, upon the ITP and mentors.debian.org upload. zigo, who sponsored daniel's upload added to CC. pss. Zigo, can you please ask your sponsorees in the future to always file ITP bugs, contact upstream about packaging software in Debian, and package libraries in co-installable separate multi-arch:same packages. -- Regards, Dimitri. signature.asc Description: OpenPGP digital signature
Bug#746739: ITP: x4d-icons -- X4D Icon set for various online document types
On 6 May 2014 21:41, Bastien ROUCARIES wrote: > control: clone -1 > control: reassign -2 lintian > control: retitle -2 "Please add a piece of advice about free http like > icons : x4d-icons > control: block -2 by -1 > >> Icon set indicating document types and target versions of those >> specifications e.g. HTML, XHTML, CSS, MathML, etc. These are metric >> compatible & naming scheme compatible with other logos used for >> similar purposes. > > Thanks a lot for taking care of it. I have open a lintian bug about this. > Please note i'm also currently initiated dialog with W3C to re licence current W3C icons under a free license. And e.g. HTML5 logo is a free one. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUisrGZ3zhYS4jjaHB6=LcgdtaNUtFGL=rcc8cexece...@mail.gmail.com
Bug#747070: ITP: apt-venv -- apt virtual environment
On 5 May 2014 11:03, Leo Iannacone wrote: > Package: wnpp > Severity: wishlist > Owner: Leo Iannacone > > * Package name: apt-venv > Version : 0.1.0 > Upstream Author : Leo Iannacone > * URL : https://github.com/LeoIannacone/apt-venv > * License : GPL-3 > Programming Lang: Python > Description : apt virtual environment > > apt-venv creates a sort of virtual environment in the user > home directory and forces apt to run under some custom option. > . > A simple use case is collect information about packages > in different Debian and Ubuntu release without surfing the web, > just using calling apt-cache through the virtual environment. How is it different from "chdist" utility from the devscripts package that allows apt-cache lookups and more? http://manpages.ubuntu.com/manpages/trusty/en/man1/chdist.1.html -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUgYqhCEVc_pMW_k_NeudRMWRXZ8u5CCq_YdebCf67c=u...@mail.gmail.com
Bug#746739: ITP: x4d-icons -- X4D Icon set for various online document types
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: x4d-icons Version : 1.2 Upstream Author : Dimitri John Ledkov * URL or Web page : http://x4d.surgut.co.uk * License : MIT Description : X4D Icon set for various online document types Icon set indicating document types and target versions of those specifications e.g. HTML, XHTML, CSS, MathML, etc. These are metric compatible & naming scheme compatible with other logos used for similar purposes. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uqjwfsg@debian.org
Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org
On 1 April 2014 11:38, Mike Gabriel wrote: > Package: wnpp > Severity: wishlist > Owner: Mike Gabriel > > * Package name: apt-get-snapshot > Version : 1.1 > Upstream Author : Leandro Lisboa Penz > * URL : https://github.com/lpenz/apt-get-snapshot > * License : BSD > Programming Lang: Python > Description : Download a specific package version from > snapshot.debian.org > > apt-get-snapshot is a command-line tool that downloads a specific version of > a debian package from snapshot.debian.org. > . > When using debian testing, it is not trivial to get the previous version of a > package after it is upgraded. snapshot.debian.org is the source to go for > these > cases, but it has only a web interface. apt-get-snapshot navigates that web > interface and fetches the desired package. > Does it do GPG verification against the Debian Archive Key of the Releases/Packages which includes the matching checksum binary package? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlujzrab3+ad3w90hgwiv4vf0a2o7vmkdqqwfp5r5r7e...@mail.gmail.com
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 2 March 2014 16:05, Steven Chamberlain wrote: > On 02/03/14 12:19, Turbo Fredriksson wrote: >> Might I suggest that the reason is that these is _completely_ different >> implementation, with >> absolutly no common code? > > Right, so conversely, zfs-linux shares a lot of code already with > zfsutils and it makes no sense for them to be packaged separately or > compete over namespace? > I think it makes sense for myself to go through the differences and propose packaging changes for Robert to review, to simply enable linux-any targets in the existing zfs packages. This thus avoids the packaging conflict all-together, but does impose compatability (e.g. such that end-user binaries have compatible commandline interface, flags, and operations - clearly different zfs api levels / options will be supports, but the common base set should work the same across all supported kernels). If patches are intrusive, then conditionally applying the patches on linux-any might work (as many other profilic packages do - binutils, gcc, etc.) >> if the FTP maintainers [...] say that this is not acceptable, >> then we'll rename it, without any bitching or >> whining or expressing opinions that we can't backup with facts. > >> Basically, their ruling is law. Your opinion is just that - your opinion and >> bear no weight at this >> moment. > > It actually seemed to be an offer for collaboration with you, but I > don't see that working so well now. > No ftp-masters decisions are not laws - rejects usually only happen after contacting the developer, inquiring unclear technical points and mitigating the problems. Quite often, if it's possible to fix, things are reuploaded. it's simply their archive you ask inclusion into and they are free to include things or not and tell you why =))) The maintainer of a package, ultimately has the power to veto what goes into the packages they are maintaining. If you are not sure what or who a maintainer is, here is reference to the policy you are so after https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer Current maintainers and uploads of zfsutils are listed at http://packages.qa.debian.org/z/zfsutils.html Debian welcomes all contributions by everyone, as long as one constructively interacts with Debian. (If you want a reference, here you go https://www.debian.org/intro/diversity ) Since you acknowledge the code differences are small, can you refactor zfsutils required portions as patch series to existing zfsutils package (and hence the related libraries, utils and udebs) ? That would be ultimately easier to maintain, and will go quicker through NEW queue, as it's only the utils and not the kernel module. And then kernel dkms module can go through as a separate package. Not sure if it at all makes sense to ship -dkms module out of the zfsutils package, as I'm expecting linux dkms module to move at a faster pace than the utils. Would that work you? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUh4ij6cN-qBp=U8MF-DSVP5iZmf-gLQBfm=y8bexqq...@mail.gmail.com
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 1 March 2014 15:46, Turbo Fredriksson wrote: > On Mar 1, 2014, at 2:25 PM, Robert Millan wrote: > >> I already explained. Nobody listens... (sigh) > > All I've seen is that you "think" that it "might" be a problem and that we > "might" be better of renaming it... > > > Please give us/me a direct link to the Debian GNU/Linux policy point that > explain that this is not acceptable. Hostile binary takeover is not allowed - that is two separate source packages should not build the same binary package names, even if on different architectures. Since these are two different implementations that should be clearly reflected in the binary package names. There is no need to rename the command-line utilities themself. Typically you'd still declare a common name as a virtual package name provider: Package: zolutils Provides: zfsutils Description: zfs on linux utilities The conflict is there, by virtue of enabling multiarch one can install "zfsutils" for either a linux or kfreebsd architecutre, based on higher version number kfreebsd one will win... thus it's in your own interest to rename zfsutils binary package name. Similarly you can't share library package names, since that will break multiarch installations of those, since versions and files do not match between kfreebsd/linux arches. The packages that are ok, are "-dbg" "-dkms" and "-initramfs". Also, if there is zfs-dkms module available, why existing zfsutils packages just can't enable compilation on "linux-any"?! Which should also reduce the scope of linux specific packages down to -dkms/-initramfs, and maybe an arch specific patch-series. Changes to partman-zfs on linux-any, confuse and surprise me, as that implies providing a pre-build dmks module for the installer's Linux kernel which is not redistributable. DId partman-zfs/linux-any relied on compiling -dkms module? Debian has spent a long time to provide fully free kernels, introducing a non-redistributable component into the installer is a no-go. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUjwWG8riu6pg7fFe=BQoHAmc+U1L4sxd=3vu_+jdwf...@mail.gmail.com
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
Hello,
On 28 February 2014 09:30, Turbo Fredriksson wrote:
> I'm basically Ccing half the world in this (only half sorry about that :) and
> I don't know who half
> of you are :), but there have been very little information on what's
> happening with ZoL in Debian
> GNU/Linux.
>
> Aron (and in some part Carlos) seems to have gone a-wall and the list have
> been VERY quiet. It seems
> like it's only Aron and me that is actually Debian GNU/Linux Developers
> (unless other things have
> happened outside the list that I'm not aware of - Carlos was/is a maintainer
> if I don't
> misremembering and Darik is in the wait queue?). And no actually status
> information/reason from the
> FTP maintainers about why it have been stuck in incoming for so long
> (accepted into incoming Sun, 07
> Jul 2013 16:00:06 - that's more than six months ago!). Have it been rejected?
> Is it held up for some
> reason? What can I/we do to help move it along?
>
Apart from talking to ftp-masters, I don't know.
>
> I'm now the current Debian GNU/Linux Wheezy package maintainer (and have been
> for quite some time)
> for/in ZoL ("upstream" from Debian GNU/Linux I suppose) and I have
> contributed to both the packaging
> (that is already in the Alioth repos) as well as bits and pieces to ZoL code
> (such as SMB and iSCSI
> support - which will be accepted into post-0.6.3 which is due out "very soon
> now" we hope) and also
> wrote support for ZoL to be used as installation target (debian installer,
> part-man) etc.
>
> With that - I have a large vested interest in maintaining this and I work on
> it almost daily, so if
> no one else have the time (Aron, Carlos)
>
> I know that Darik is also very busy working on this, and he already maintain
> (and have for a very
> long time) the Ubuntu packages in ZoL, and much (most, all?) of the current
> packaging is from his
> busy hands.
>
> So I'd prefer to work with him on this (if aron/carlos don't have the
> time/interest that is - I'm not
> proposing to steal the packaging!).
>
>
> Since there have been next to no progress in the Debian GNU/Linux ZoL
> projects, I have done all my
> packaging stuff in the ZoL repos, so if/when this project is revitalized,
> I'll push all my work to
> the Debian GNU/Linux repos as individual commits.
Where is the latest/greatest set of packaging repositories and/or
packages to look at?
I'd love to evaluate it on Ubuntu, after informal discussion with
Ubuntu ftp-master, I got an agreement that ZoL is a technology we'd be
willing to include in the Ubuntu Archive.
--
Regards,
Dimitri.
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CANBHLUi6ynNRU6vayNhC2edwfD1vs79NFw=rdtmtb30qght...@mail.gmail.com
Bug#613706: I have fakeraid cards and patches for dmraid
retitle 613706 ITA: dmraid -- Device-Mapper Software RAID support tool owner 613706 ! thanks -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUizN9xxA0OgANXvF9un29D==tx-cH4=yosmhxuamek...@mail.gmail.com
Bug#738334: RFA: socat -- multipurpose relay for bidirectional data transfer
On 9 February 2014 11:09, Chris Taylor wrote: > Package: wnpp > Severity: normal > X-Debbugs-CC: debian-de...@lists.debian.org > > Unfortunately, due to a lack of time, motivation/interest I am > requesting an adopter for socat. > > I am willing to sponsor the first few uploads if a non-DD would like to > take over. > > Long description is: > > Socat (for SOcket CAT) establishes two bidirectional byte streams > and transfers data between them. Data channels may be files, pipes, > devices (terminal or modem, etc.), or sockets (Unix, IPv4, IPv6, raw, > UDP, TCP, SSL). It provides forking, logging and tracing, different > modes for interprocess communication and many more options. > . > It can be used, for example, as a TCP relay (one-shot or daemon), > as an external socksifier, as a shell interface to Unix sockets, > as an IPv6 relay, as a netcat and rinetd replacement, to redirect > TCP-oriented programs to a serial line, or to establish a relatively > secure environment (su and chroot) for running client or server shell > scripts inside network connections. Socat supports sctp as of 1.7.0. > I also find socat very valuable. Is it ok if I pick it's maintenance up? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugrvcvyjohjy3wnei6t+4rvvs6c28umc+xbyptlgzg...@mail.gmail.com
Bug#736523: Indeed, python-concurrent.futures is the same
On 25 January 2014 17:21, Sandro Tosi wrote: >> Huh? Thomas seemed to be doing the right thing per the DPMT standards >> etc; > > if you change the python helper, you HAVE TO contact who's maintaining > the package and have they ack the change, that's the team standard. > No, one does not within python apps/module teams. It's not the first time when you are over-reacting to team changes in a very aggressive/abusive manner. Honestly, nobody is trying to purposely cause harm to debian packages. >> if you don't want the package to be team maintained, perhaps take >> it out of team maintenance? > > lecturing is not required, thanks > This is not a lecture. You clearly have "maintainer - team" balance swayed way to the maintainer-mandated side of things, which is not shared with anyone else in the debian apps/modules team. I do not share your view that "Thomas Goirand is not welcomed here." on the contrary, the Debian Project welcomes and encourages participation by everyone. We welcome contributions from everyone as long as they interact constructively. When packages that you declared are maintained within the team are touched, at times (and this is not the first time), you demand post-factum that you should have been exclusively consulted first and you demand or threaten for all changes to be reverted. This is not constructive interaction within python apps/modules teams, nor wider Debian Project. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhGR=jkplvio8njsa0r_acekkukvg7bmwrjjkdyg6q...@mail.gmail.com
Bug#733743: ITP: libnih.la -- portable libnih implementation
On 31 December 2013 15:25, cameron wrote: > Dmitri, > > Why do you not use libinotify-kqueue? I know you mentioned not wanting to > have a lot of external dependencies, but I think using that library will > allow other linux applications to more easily port to kFreeBSD. > I have packaged it and attempted to use it. [1] Unfortunately it doesn't provide sufficient compatibility and I see a lot of unit-test failures. Instead of enabling something partially broken, i'd rather not provide the facility full stop and instead implement a native kqueue/kevent. Granted I could spend time improving libinotify-kqueue. At the moment I'm focusing on booting a kFreeBSD/eglibc system with upstart, since file notifications are optional in upstart (well to be precise, they may fail / raise errors at runtime and upstart handles that gracefully) [1] http://packages.qa.debian.org/libi/libinotify-kqueue.html Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUir=xxkxtaln_g1knpm8ksi5th2pj8n5ai81tfsxhz...@mail.gmail.com
Bug#733743: ITP: libnih.la -- portable libnih implementation
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: libnih.la Version : 1.0.4 (git snapshot) Upstream Author : Dimitri John Ledkov (DD), Scott James Remnant (DD) * URL or Web page : https://github.com/xnox/libnih/tree/kfreebsd http://libnih.la/ * License : GPL v2 Architecture: kfreebsd-any (hurd-any - maybe later) Description : portable libnih implementation I would like to package a temporary fork of libnih, which has been ported to kFreeBSD/eglibc platform. My plan for this package is to provide same packages as the src:libnih, but for non-Linux ports only. At the moment I have a port to kFreeBSD/eglibc. This is separate source package as the supported set of APIs is not yet fully same as of the Linux port of libnih. For example kqueue/kevent technology is not yet used to provide, e.g. file level notification as done with inotify in the linux port. Some of my patches have already been accepted upstream (https://github.com/keybuk/libnih), others are under review and some are not ready for submission yet. All libnih test-suite passes on kFreeBSD for those components that have been ported. Together with this effort, I am staging patches for Upstart itself for kFreeBSD/eglibc https://code.launchpad.net/~xnox/upstart/kfreebsd. It compiles, but at the moment is still incomplete. The test-suite does not pass yet and there are no kFreeBSD specific bridges yet (e.g. devd events, instead of udev, etc.). I'm hoping to have a bootable kFreeBSD/eglibc port soon, with full support ahead of Jessie freeze on 5th of November 2014. The requirements for libnih/kfreebsd, at the moment are, eglibc 2.18 & kFreeBSD kernels with fixed waitid/wait6 syscalls. These are all present in Debian experimental. Alternatively, if lower eglibc versions are required I could easily use wait6 syscall directely, without eglibc wrapper. In that case only requirements would be patched kFreeBSD kernels for the kern/184002 http://www.freebsd.org/cgi/query-pr.cgi?pr=184002&cat= bug which I discovered in FreeBSD. It's fixed in current/11, and is on track to be fixed in 9.2, 10 stable updates. I believe patch for that issue is already in debian packaging of FreeBSD kernels. I haven't started HURD port just yet, as I'm more familiar with FreeBSD. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqil13jl@ubuntu.com
