Re: Can a leaf package require SSE2 on i386?
Hi, On Sep 14, 2014 9:16 AM, Michael Gilbert wrote: > > On Sun, Sep 14, 2014 at 2:47 AM, Sébastien Villemot wrote: > > The bottom line is that julia needs SSE2 (and porting it to the x87 FPU > > requires changes that are beyond what I am willing/able to do, see [1] > > for more details). And the presence of SSE2 is not guaranteed on the > > i386 architecture. > > chromium upstream decided to go SSE2-only, but I've reverted that in > the Debian packages for now. I would prefer to not diverge, and would > do so if there were a convenient way to detect and prompt users about > the problem (rather than segfault). How about creating a package named like sse2-support for i386 which fails to install (unless it is forced) on not SSE2-capable hardware emitting a proper error message? Packages requiring SSE2 could (build-) depend on it. BTW steam already requires SSE2. Cheers, Balint
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
Hi All, On 08/26/2013 09:31 AM, Mike Gabriel wrote: > Hi Charles, > > On Di 20 Aug 2013 02:04:40 CEST Charles Plessy wrote: > >> Altogether, it is a lot of work, but if we have enough people for >> doing it, think that it would be very positive for us. > > /me raises his hand for giving his work for longer maintainance of > former Debian stable releases. For customer sites 2.5yrs + 1yr > stable/oldstable does not suffice. Me too. I think we should match the five years Ubuntu LTS offers for at least part of the packages like Ubuntu does with main/universe [1] distinction. Cheers, Balint [1] https://help.ubuntu.com/community/Repositories signature.asc Description: OpenPGP digital signature
XBMC packaging (was: Re: Bug#732159: Should this package be removed?)
Hi Felipe, On 12/18/2013 07:10 PM, Felipe Sateler wrote: > On Wed, 18 Dec 2013 00:10:11 +0100, Andreas Tille wrote: > >> Hi Felipe, > > Hi Andreas, > >> >> I did not checked whether xbmc would be compliant to Debian Multimedia >> policy. My statement was written under the assumption that the package >> is following usual Debian standards which for sure contains the upstream >> source. If this is not the case what about asking Bálint to follow the >> Debian Multimedia policy when packaging xbmc and adopt the result of >> this. (In case I'm repeating something which was discussed before a >> link to this discussion.) > > I haven't really followed the discussion on this. XBMC was at some point > within the multimedia team, but for reasons I don't know it was moved > outside of it (I can't find any relevant discussion on my archives). > > Bálint (and any other people interested in XBMC), you are of course > welcome to join us at the Debian Multimedia team. Thank you for the invitation. I don't know the full story behind XBMC and the Multimedia Team, thus I would like to start maintaining it outside of the team, then when both upstream and the team is satisfied with XBMC's state in Debian I would happily join. I have created a git repository [1] under collab-maint for now. It still does not conform fully to Multimedia policy, but I tried to start the convergence. :-) Cheers, Balint [1] http://anonscm.debian.org/gitweb/?p=collab-maint/pkg-xbmc.git signature.asc Description: OpenPGP digital signature
Re: Should we try to draw more attention on ITAs waiting for sponsorship (with testing removal) ?
Hi, On 01/30/2014 02:25 PM, Neil Williams wrote: > On Thu, 30 Jan 2014 13:51:40 +0100 > Olivier Berger wrote: > >> I myself isn't very motivated to sponsor packages which I don't >> use... but maybe I'm not noticing at all (or didn't read >> how-can-i-help messages ;-). > > That's the crux of it - a sponsor needs some level of interest in the > package, beyond whether it is scheduled for removal. Fly-by sponsoring > is not helpful, the sponsor needs to keep an eye on the package - and > work with the maintainer - for the long term. Currently each package's PTS page lists RFA'd packages among dependencies and I think this is a good way for notifying interested maintainers about RFA-s. Maybe listing RFS-s would also drive interested maintainers towards sponsoring some uploads and even starting to work with the new contributors. Cheers, Balint PS: I assume that PTS support is not there since backupninja's PTS page does not list RFS for hwinfo. signature.asc Description: OpenPGP digital signature
Proposing amd64-hardened architecture for Debian
Hi, I have posted the following idea on my blog [7] to get comments from people not on this list, but obviously this is the mailing list where the proposal should be discussed. :-) - Facing last week's Heartbleed [1] bug the need for improving the security of our systems became more apparent than usually. In Debian there are widely used methods for Hardening [2] packages at build time and guidelines [3] for improving the default installations' security. Employing such methods usually come at an expense, for example slower code execution of binaries due to additional checks or additional configuration steps when setting up a system. Balancing between usability and security Debian chose an approach which would satisfy the most users by using C/C++ features [4] which only slightly decrease execution speed of built binaries and by using reasonable defaults in package installations. All the architectures supported by Debian aims using the same methods for enhancing security but it does not have to stay the same way. Amd64 is the most widely used architecture of Debian according to popcon [5] and amd64 hardware comes with powerful CPU-s. I think there would be a significant amount of people (being one of them :-)) who would happily use a version of Debian with more security features enabled by default sacrificing some CPU power and installing and setting up additional packages. My proposal for serving those security-focused users is introducing a new architecture targeting amd64 hardware, but with more security related C/C++ features turned on for every package (currently hardening has to be enabled by the maintainers in some way) through compiler flags as a start. Introducing the new architecture would also let package maintainers enabling additional dependencies and build rules selectively for the new architecture improving the security further. On the users' side the advantage of having a separate security enhanced architecture instead of a Debian derivative is the potential of installing a set of security enhanced packages using multiarch [6]. You could have a fast amd64 installation as a base and run Apache or any other sensitive server from the amd64-hardened packages! - What do you think? Would adding a new arch be feasible and a good solution? Cheers, Balint PS: There was a long security related thread on -private which I can't refer to and in which Paul Wise proposed a "secondary high-security (but slower) archive", and while I think it is a very good idea it would not allow mixing fast and secure packages using multiarch. [1] http://heartbleed.com/ [2] https://wiki.debian.org/Hardening [3] https://www.debian.org/doc/manuals/securing-debian-howto/ch-automatic-harden.en.html [4] https://wiki.debian.org/Hardening#Notes_on_Memory_Corruption_Mitigation_Methods [5] http://popcon.debian.org/index.html [6] https://wiki.debian.org/Multiarch [7] http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian signature.asc Description: OpenPGP digital signature
Bug#772827: ITP: kerneloops -- kernel oops tracker
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: kerneloops Version : 0.12+git20140509-1 Upstream Author : Arjan van de Ven * URL : https://github.com/oops-kernel-org/kerneloops * License : GPL-2 Programming Lang: C Description : kernel oops tracker kerneloops is a daemon that collects kernel crash information and then submits the extracted signature to the kerneloops.org website for statistical analysis and presentation to the Linux kernel developers. -- I would like to reintroduce the package into Debian. -- 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/5489a860.3030...@balintreczey.hu
Bug#792411: ITP: r-cran-caret -- GNU R package for classification and regression training
Package: wnpp Severity: wishlist * Package name: r-cran-caret Version : 6.0.47 * URL : http://cran.r-project.org/web/packages/caret/index.html * License : GPL-2+ Programming Lang: R Description : GNU R package for classification and regression training Misc functions for training and plotting classification and regression models. -- This package will be maintained within the Debian Science Team. -- 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/55a5283e.9050...@balintreczey.hu
ITP: r-cran-brglm -- GNU R package for bias reduction in binomial-response GLMs
Package: wnpp Owner: Balint Reczey Severity: wishlist * Package name: r-cran-brglm Version : 0.5-9 Upstream Author : Ioannis Kosmidis * URL : http://www.ucl.ac.uk/~ucakiko/index.html * License : GPL-2.0+ Programming Lang: R Description : GNU R package for bias reduction in binomial-response GLMs Fit generalized linear models with binomial responses using either an adjusted-score approach to bias reduction or maximum penalized likelihood where penalization is by Jeffreys invariant prior. These procedures return estimates with improved frequentist properties (bias, mean squared error) that are always finite even in cases where the maximum likelihood estimates are infinite (data separation). Fitting takes place by fitting generalized linear models on iteratively updated pseudo-data. The interface is essentially the same as 'glm'. More flexibility is provided by the fact that custom pseudo-data representations can be specified and used for model fitting. Functions are provided for the construction of confidence intervals for the reduced-bias estimates. -- 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/55a6987e.70...@balintreczey.hu
Bug#792900: ITP: cpluff -- C-Pluff, a plug-in framework for C - runtime library
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: cpluff Version : 0.1.3-3 Upstream Author : Johannes Lehtinen * URL : http://www.c-pluff.org/ * License : Expat Programming Lang: C Description : C-Pluff, a plug-in framework for C - runtime library C-Pluff is a plug-in framework for C programs. It has been strongly inspired by the Java plug-in framework in Eclipse. C-Pluff focuses on providing core services for plug-in interaction and plug-in management. It aims to be platform neutral and supports dynamic changes to plug-in configuration without stopping the whole application or framework. --- This package will be a dependency of Kodi replacing Kodi's embedded version of C-Pluff. -- 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/55ac1ca8.6090...@balintreczey.hu
Bug#793329: ITP: libcec-platform -- CEC Platform support library -- development files
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libcec-platform Version : 1.0.10+dfsg1 Upstream Author : Team XBMC, Pulse-Eight Limited & others * URL : https://github.com/Pulse-Eight/platform.git * License : GPL-2+ Programming Lang: C/C++ Description : CEC Platform support library -- development files Platform support library for libCEC. It includes C++ wrappers for platform-specific atomic operations, threading, sockets and also string utilities. This package provides the necessary files needed for development. --- Upstream uses the "platform" and libplatform name but I found those too generic for the archive and I'm trying to convince them about that here: https://github.com/Pulse-Eight/platform/issues/9 This package is a dependency of next libcec release which is needed by Kodi 15. -- 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/55b00d84.8020...@balintreczey.hu
Bug #782763: RFP: sirius -- Speech and Vision Based Intelligent Personal Assistant
Package: wnpp Severity: wishlist * Package name: sirius Version : 1.0.1 Upstream Author : Clarity Lab * URL : http://sirius.clarity-lab.org/index.html * License : BSD-3-Clause Programming Lang: Python Description : Speech and Vision Based Intelligent Personal Assistant Sirius is an open end-to-end standalone speech and vision based intelligent personal assistant (IPA) similar to Apple’s Siri, Google’s Google Now, Microsoft’s Cortana, and Amazon’s Echo. Sirius implements the core functionalities of an IPA including speech recognition, image matching, natural languageprocessing and a question-and-answer system. -- I originally forgot CC-ing debian-devel, but Iain R. Learmonth already noticed the RFP started working on it [1]. (Thanks Iain!). I guess it is still not late to join the fun. :-) [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782763#14 -- 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/55c0e816.9060...@balintreczey.hu
Bug#794634: RFP: lua-torch -- A scientific computing framework for Lua(JIT)
Package: wnpp Severity: wishlist * Package name: lua-torch Version : No releases yet * URL : http://torch.ch/ * License : BSD-3-Clause Programming Lang: Lua Description : A scientific computing framework for Lua(JIT) Torch is a scientific computing framework with wide support for machine learning algorithms. It is easy to use and efficient, thanks to an easy and fast scripting language, LuaJIT, and an underlying C/CUDA implementation. A summary of core features: a powerful N-dimensional array lots of routines for indexing, slicing, transposing, ... amazing interface to C, via LuaJIT linear algebra routines neural network, and energy-based models numeric optimization routines Fast and efficient GPU support Embeddable, with ports to iOS, Android and FPGA backends -- 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/55c1db97.2090...@balintreczey.hu
Bug#922522: ITP: waylandpp -- wayland compositor infrastructure - C++ development files
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: waylandpp Version : 0.2.4 Upstream Author : Nils Brause * URL : https://github.com/NilsBrause/waylandpp * License : GPL-3+ Programming Lang: C++ Description : wayland compositor infrastructure - C++ development files Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers. This package ships the C++ bindings for the development libraries. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. The package is a build dependency of Kodi 18 for enabling Wayland support. I'd be happy to maintain the package under Debian X Strike Force's umbrella if the team accepts that.
Re: RFC: Support for zstd in .deb packages?
Hi Guillem, On Fri, May 4, 2018 at 11:41 PM Nick Terrell wrote: > > > > On May 4, 2018, at 6:22 AM, Guillem Jover wrote: > > > > Hi! > > > > On Fri, 2018-04-27 at 07:02:12 +0200, Guillem Jover wrote: > >> The following is a quick run-down of the items from [F], not all > >> being important from Debian's perspective, but being for dpkg's: > > > >> * License: Permissive (dual BSD + GPL-2), which makes universal > >> availability possible. > > > > Unfortunately, I've just noticed that the project requires a CLA, > > which means universal contributions are *not* possible. :( I'm not a fan of CLAs either, but as I understand upstream requiring a CLA is not a blocker for compression libraries. > > <https://github.com/facebook/zstd/blob/dev/CONTRIBUTING.md> > > <https://code.facebook.com/cla> > > > > Nick & Yann, I'm assuming this is some corporate requirement from > > Facebook, and it's probably not going to go away? > > Yup, it is here to stay. Nick, thanks for the clarification. Cheers, Balint -- Balint Reczey Ubuntu & Debian Developer
Re: RFC: Support for zstd in .deb packages?
Hi Ian,
On Fri, Apr 27, 2018 at 2:03 PM Ian Jackson
wrote:
>
> Guillem Jover writes ("RFC: Support for zstd in .deb packages?"):
> > * Eternity contract: This would add yet another format that would need
> > to be supported pretty much forever, to be able to at least unpack
> > .deb's that might be available in the wild. This also increases the
> > (Build-)Essential-set.
>
> This means that we should be much slower to adopt new compression
> schemes than projects where data compression is used for transport or
> short-term storage.
>
> I would say that a new compression scheme should be widely used for
> several years before we would consider it for source package and at
> least half a decade before we would adopt it for .debs.
I've updated the dpkg bug [1] to kindly ask for decompression support
in Bullseye which would enable adding compression support in Bookworm
which is most likely due to be released in 2023. Since the Linux
kernel added zstd support for btrfs in 2017 [2] support in Bookworm
would be more than a half decade from what I'd consider wide adoption.
> I am also concerned that we are the target of an advocacy campaign.
>
> Ian.
Cheers,
Balint
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892664#59
[2] https://en.wikipedia.org/wiki/Zstandard#Usage
--
Balint Reczey
Ubuntu & Debian Developer
--
I've updated #892664 (three times :-)) before sending this email to
debian-devel.
https://balintreczey.hu/blog/my-debian-devel-pledge/
Re: RFC: Support for zstd in .deb packages?
On Sun, Jan 10, 2021 at 8:41 PM Bastian Blank wrote: > > Moin > > On Sun, Jan 10, 2021 at 08:20:33PM +0100, Balint Reczey wrote: > > I'm not a fan of CLAs either, but as I understand upstream requiring a > > CLA is not a blocker for compression libraries. > > Well, it means that the library might get incompatible with upstream, > because upstream will refuse patches. I'm not sure if I miss something, but I don't see the strict connection. The current upstream requires CLA, but if they make an incompatible change that they refuse to revert, their current license allows forking the project and fixing it (with or without requiring a different CLA). This is why requiring a _license_ that allows forking makes sense. We have also seen cases where projects refused to take patches even though they did not require a CLA, thus not having a CLA is not a guarantee for taking patches. I'm also willing to sign the CLA and propose a fix if needed. I agree that the CLA is not comfortable, but is hardly a blocker. Cheers, Balint -- Balint Reczey Ubuntu & Debian Developer -- I've closed #929715 before sending this email to debian-devel. https://balintreczey.hu/blog/my-debian-devel-pledge/
Bug#965003: ITP: grpc-proto -- Protobuf protocol definitions for gRPC services
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: grpc-proto Version : 0.0~git20200526.dd2dca3 Upstream Author : https://github.com/grpc/grpc-proto * URL : https://github.com/grpc/grpc-proto * License : Apache-2.0 Description : Protobuf protocol definitions for gRPC services Remote Procedure Calls (RPCs) provide a useful abstraction for building distributed applications and services. gRPC is a modern open source high performance RPC framework that can run in any environment. Protocol Buffers (Protobuf) are a flexible, efficient, automated mechanism for serializing structured data - similar to XML, but smaller, faster, and simpler. This package provides the Protobuf protocol definitions (.proto files) for gRPC services. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. -- Balint Reczey Ubuntu & Debian Developer
Bug#833140: RFP: embroidermodder -- Free machine embroidery software
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: embroidermodder Version : 2.0 * URL : http://embroidermodder.org * License : Zlib Programming Lang: C/C++ Description : Free machine embroidery software Embroidermodder is a free machine embroidery software program. . Features: - edit and create embroidery designs . - estimate the amount of thread and machine time needed to stitch a design . -convert embroidery files to a variety of formats . -upscale or downscale designs -- One could embroider awesome Debian apparel using this package ;-): http://embroidermodder.org/features.html
Re: Porter roll call for Debian Stretch
On 08/22/2016 07:12 PM, Bálint Réczey wrote: > Hi Guillem, > > 2016-08-21 14:02 GMT+02:00 Guillem Jover : >> Hi! >> >> On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote: >>> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for >>> all >>> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu. >>> >>> My assumption was that this set of architectures need the least amount of >>> additional work since they are tested already in Ubuntu, but I would be >>> happy >>> if more ports would opt in for PIE. >>> >>> I plan filing wishlist bugs against dpkg and gcc with the patches >>> after I rebuilt a >>> few packages with the defaults. >> >> TBH I think PIE should in fact be safer to enable globally than >> bindnow, because the latter changes the run-time behavior and things >> might break (perhaps even silently) when failing to load plugins >> or similar. > > Yes, in that sense enabling PIE is safer indeed. Regarding bindnow > I don't expect too many surprises either, since other distributions > already tested enabling bindnow and probably they found > most issues. > >> >> From dpkg PoV enabling both, would at least require a full-archive >> rebuild, for bindnow ideally also a full autopkgtest run (as the >> updated dpkg FAQ states now, after Lucas Nussbaum approached me some >> weeks ago mentioning he was willing to do such archive-wide rebuild). > > The patches at [2] seem to work well and since you expressed that you would > prefer changing both toolchain and dpkg, too, I would like to suggest running > the rebuild with those patches. > > I think Matthias would be OK with the patch since it is very small and brings > Debian's gcc closer to Ubuntu's. > > Lucas, could you please run the rebuild with the three patches? > > I'll attach the patches to the bug reports. For the record I have opened #835146, #835148 and #835149 against dpkg and gcc-6 with the patches. > > [2] https://people.debian.org/~rbalint/ppa/pie-bindnow/ >
Exception for shipping shared libraries compiled with -fPIC for multiple packages
Dear People of Debian-Devel, Current Policy (3.9.8.0) mandates discussion on debian-devel@d.o before changing packages to ship static libraries compiled with -fPIC: --- 10.2 Libraries ... (paragraph about shared libs) As to the static libraries, the common case is not to have relocatable code, since there is no benefit, unless in specific cases; therefore the static version must not be compiled with the -fPIC flag. Any exception to this rule should be discussed on the mailing list debian-devel@lists.debian.org, and the reasons for compiling with the -fPIC flag must be recorded in the file README.Debian. [86] In other words, if both a shared and a static library is being built, each source unit (*.c, for example, for C files) will need to be compiled twice, for the normal case. --- I am hereby asking for exceptions for the following packages: Bug Package Title #586572 libdpkg-dev libdpkg-dev: Please provide a libdpkg shared library #712228 src:ghc Hardening flag -pie breaks compilation with GHC #804254 publib-devpublib-dev: please build libpub.a with -fPIC #837350 src:binutils binutils: Please build libbfd.a with -fPIC #837359 src:ocaml ocaml: Please build libasmrun.a and libcamlrun.a with -fPIC #837363 src:cpputest cpputest: Please build libCppUTest.a with -fPIC #837417 src:ctn ctn: Please build libctn.a with -fPIC #837423 src:jack-audio-connection-kit jack-audio-connection-kit: Please build libjack.a with -fPIC #837424 src:portaudio19 portaudio19: Please build libportaudio.a with -fPIC #837434 src:binpacbinpac: Please build libbinpac.a with -fPIC #837445 src:check check: Please build libcheck.a with -fPIC #837452 src:simgear simgear: Please build libSimGearCore.a and libSimGearScene.a with -fPIC #837489 src:antlr antlr: Please build libantlr.a with -fPIC #837490 src:libpapyrus3-dev libpapyrus3-dev: Please build libPapyrus3.a with -fPIC #837491 src:libgadap-dev libgadap-dev: Please build libgadap.a with -fPIC Converting the mentioned shared libraries to PIC allows rebuilding reverse build-dependencies with PIE and also enables switching several architectures to use PIE by default [1]. I have filed a bug [2] to relax/change policy, but to conform to the current one asking for the exceptions above is needed. There is an active thread [3] about using PIC/PIE generally for static libraries on debian-devel. Please keep this one focusing on the exception. Thanks, Balint [1] https://wiki.debian.org/Hardening/PIEByDefaultTransition [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478 [3] https://lists.debian.org/debian-devel/2016/05/msg00306.html [4] https://lists.debian.org/debian-devel/2016/09/msg00217.html
Bug#845272: ITP: libopenhmd -- API and drivers for immersive technology (shared library)
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: libopenhmd Version : 0.2.0 * URL : http://openhmd.net/ * License : BSL-1.0 Programming Lang: FIXME Description : API and drivers for immersive technology (shared library) OpenHMD aims to provide a Free and Open Source API and drivers for immersive technology, such as head mounted displays with built in head tracking. This package provides the shared library.
Bug#851663: ITP: kodi-addon-webinterface-chorus2 -- Chorus2 web interface for Kodi
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: kodi-addon-webinterface-chorus2 Version : 2.4.1 Upstream Author : Jeremy Graham * URL : https://github.com/xbmc/chorus2 * License : GPL-2.0+ Programming Lang: JavaScript Description : Chorus2 web interface for Kodi Modern web user interface for Kodi. Allows browsing and playing music, movies or tv shows through a web browser. -- This web interface is embedded in Kodi 17 upstream but in a minified form without the original source. Packaging it separately allows providing cleaner source and build instructions.
Bug#862726: ITP: printer-driver-oki -- printer driver for OKI Data printers
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: printer-driver-oki Version : 1.0.1 Upstream Author : Oki Data Corporation * URL : https://github.com/rbalint/printer-driver-oki * License : GPL-2.0+ Description : printer driver for OKI Data printers CUPS filters and drivers supporting OKI Data printers. This driver is known to support these printers: * OKI 24 Pin * OKI 9 Pin * OKI B2200 / B2400 PCL * OKI B4000 / B400 / MB400 PCL * OKI B4000 / B400 / MB400 PS * OKI B6250 / B6500 * OKI B6300 * OKI B710 / B720 / B730 * OKI B930 * OKI C330 / C530 * OKI C3600 * OKI C5550 MFP / MC560 MFP / CX2032 MFP / CX2033 MFP * OKI C6050 / C6150 * OKI C610 / C710 / C711 * OKI C830 / MC860 MFP / CX2633 MFP * OKI C910 / C9600 / C9650 * OKI MB471 MFP / MB491 MFP * OKI MC361 MFP / MC561 MFP / CX2731 MFP This package contains the CUPS filter driver and PPDs for the supported printers. -- I would happily move the package under Printing Team's umbrella. -- Balint Reczey Debian & Ubuntu Developer
Bug#875601: RFP: znc-push -- Push notification service module for ZNC
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: znc-push Version : 2.0.0~rc Upstream Author : John Reese * URL : https://noswap.com/projects/znc-push * License : MIT Programming Lang: C++ Description : Push notification service module for ZNC ZNC Push is a module for ZNC that will send notifications to multiple push notification services, or SMS for any private message or channel highlight that matches a configurable set of conditions. ZNC Push supports the following services: . * Boxcar * Boxcar 2 * Notify My Android (NMA) * Pushover * Pushsafer * Prowl * Supertoasty * PushBullet * Faast * Nexmo * Pushalot * Pushjet * Telegram * Slack * Discord * Custom URL GET requests
Bug#885152: ITP: intel-me-cleaner -- Tool for partial deblobbing of Intel ME/TXE firmware images
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: intel-me-cleaner Version : 1.0+git20171022.g2ff65c1 Upstream Author : Nicola Corna * URL : https://github.com/corna/me_cleaner * License : GPL-3.0+ Programming Lang: Python Description : Tool for partial deblobbing of Intel ME/TXE firmware images The Intel® Management Engine (ME) is a microcontroller embedded in most Intel chipsets manufactured since 2006 that runs independently from the main CPU. It is not removable from the system and it runs a signed proprietary firmware, with full network and memory access, which poses a serious security threat. Even when disabled from the BIOS settings, Intel ME is active: the only way to be sure it is disabled is to remove its firmware from the flash chip. This package allows removing parts of the signed proprietary firmware effectively disabling the Management Engine. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#885220: ITP: debian-dad -- Automated Debian package updater
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: debian-dad Version : 1 Upstream Author : Balint Reczey * URL : https://anonscm.debian.org/cgit/collab-maint/debian-dad.git * License : AGPL-3.0+ Description : Automated Debian package updater Debian's Automated Developer (Dad) is a program preparing updates for Debian packages automating repetitive tasks of human Developers. The automated tasks include: * updating packages to new upstream versions refreshing patches * updating symbols files using Debian buildd logs -- The plan is covering way more automated tasks, please refer to the TODO for details. I also plan creating a team for maintenance and patches are always welcome!
Bug#798489: ITP: kodiplatform -- Kodi platform support library -- development files
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: kodiplatform Version : 16.0.0 * URL : https://github.com/xbmc/kodi-platform * License : GPL-2+ Programming Lang: C++ Description : Kodi platform support library -- development files Kodi platform support library containing utility functions for accessing XML files. --- This package will be a dependency of many Kodi addon packages and will be team-maintained in the Debian Multimedia Team.
Bug#804453: RFP: xul-ext-toggle-word-wrap -- Icedove extension to toggle word wrapping from menu
Package: wnpp Severity: wishlist * Package name: xul-ext-toggle-word-wrap Version : 1.9.1 * URL : https://addons.mozilla.org/en-US/thunderbird/addon/toggle-word-wrap/ * License : MPL 1.1/GPL 2.0/LGPL 2.1 Programming Lang: JavaScript Description : Toggle word wrapping and PRE element wrapping in the message composition and HTML display windows, respectively. -- It would be nice to have this addon packaged since using it is an easy way of integrating Icedove to a git workflow as suggested by git help format-patch .
Bug#808427: RFP: kaldi -- Kaldi speech recognition toolkit
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: kaldi Version : 0.0.0+git20151218 * URL : http://kaldi-asr.org/ * License : Apache 2.0 Programming Lang: C++ Description : Kaldi speech recognition toolkit Kaldi is a toolkit for speech recognition written in C++ and licensed under the Apache License v2.0. Kaldi is intended for use by speech recognition researchers. . Currently, we have code and scripts for most standard techniques, including all standard linear transforms, MMI, boosted MMI and MCE discriminative training, and also feature-space discriminative training (like fMPE, but based on boosted MMI). I have started packaging [1] under debian-science, but I'm not sure how much progress I can make hence the RFP. Help is welcome! :-) Kaldi is a dependency of Sirius [2]. [1] http://anonscm.debian.org/cgit/debian-science/packages/kaldi.git [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782763
Bug#814087: ITP: crossguid -- C++ UUID library headers
Package: wnpp Owner: Balint Reczey , Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: crossguid Version : 0.0+git200150803 Upstream Author : Graeme Hill * URL : https://github.com/graeme-hill/crossguid * License : Expat Programming Lang: C++ Description : C++ UUID library Graeme Hill's cross platform C++ UUID library. -- This package is a (build-)dependency of Kodi 16 which version will be released soon.
