Re: Concerns about infrastructure for Alioth replacement
On Wed, Oct 18, 2017 at 2:13 PM, Alexander Wirt wrote: > Please don't get me wrong, but even if gitlab packages are recent tomorrow > (which I > don't think) we won't migrate. The work is done and we have all the things in > place to maintain them. So please do me a favour and don't mention alioth as > the reason. I note that the Debian security team doesn't support libv8, nodejs and the stack above it. https://sources.debian.net/src/debian-security-support/2017.06.02/security-support-limited/#L14 In my experience the JavaScript team doesn't appear to be following the nodesecurity.io security advisories. https://nodesecurity.io/advisories What is your plan for avoiding the security issues discovered in libv8/nodejs and gitlab-related node modules? -- bye, pabs https://wiki.debian.org/PaulWise
getconf(1) interface considered cross-harmful
Hi! I recently noticed that the getconf(1) interface is broken by design when it comes to cross-compiling. It always returns the information for the build system (GNU/dpkg terms), via the build system libc. This means that any package using getconf(1) to get build-specific information such as LFS_CFLAGS, LONG_BIT, or many of the other constants will produce at least unexpected results, and at worst can produce broken builds. The exceptions would be for stuff like the _NPROCESSORS_* variables, but not much more. When it comes to LFS, starting with dpkg 1.19.0 you can now use the new «lfs» feature from the «future» feature area (documented in the dpkg-buildflags man page), which properly supports cross-building: ,--- $ export DEB_BUILD_OPTIONS=future=+lfs $ DEB_HOST_ARCH=amd64 dpkg-buildflags --get CPPFLAGS -Wdate-time -D_FORTIFY_SOURCE=2 $ DEB_HOST_ARCH=x32 dpkg-buildflags --get CPPFLAGS -Wdate-time -D_FORTIFY_SOURCE=2 $ DEB_HOST_ARCH=i386 dpkg-buildflags --get CPPFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 `--- I'll be filing a lintian report to emit a tag for any broken use of getconf(1). Thanks, Guillem
Re: getconf(1) interface considered cross-harmful
On Thu, 19 Oct 2017 at 10:50:36 +0200, Guillem Jover wrote: > When it comes to LFS, starting with dpkg 1.19.0 you can now use the > new «lfs» feature from the «future» feature area ... or if your upstream uses Autotools, ask them to add AC_SYS_LARGEFILE to configure.ac, which as far as I can tell does the right thing. smcv
Re: Concerns about infrastructure for Alioth replacement
On ബുധന് 18 ഒക്ടോബര് 2017 02:59 രാവിലെ, Francesco Poli wrote: > Unfortunately, I have basically zero knowledge about Rails, JavaScript > and Node.js: I could not be of much help in packaging GitLab. If you are interested, I could mentor you in learning Node.js packaging. Many Node.js modules are easy to package, the main problem is the number of modules are too large. Any help is welcome. signature.asc Description: OpenPGP digital signature
Re: Concerns about infrastructure for Alioth replacement
On ബുധന് 18 ഒക്ടോബര് 2017 04:08 രാവിലെ, Nicholas D Steeves wrote: > Dear Javascript Team, > > Would you please consider maintaining the "numerous [...] nodejs > modules" necessary for Debian's Alioth replacement to run on a > Debian-built GitLab package? We are facing a scenario that confirms > that Debian packaging is not good enough--even for Debian's own > infrastructure. This is already in progress, if more people joins, we can speed it up. > I would join the team, but it would take me weeks/months to learn > about Javascript and Nodejs, and it seems this transition is imminent. It would take at most a few days. I have taught many people Nodejs packaging in few days. I'd be happy to mentor anyone. Try to follow https://wiki.debian.org/Javascript/Nodejs/Npm2Deb/Tutorial signature.asc Description: OpenPGP digital signature
Re: [Pkg-javascript-devel] Concerns about infrastructure for Alioth replacement
On ബുധന് 18 ഒക്ടോബര് 2017 01:39 വൈകു, Ondřej Surý wrote: > Also please note that Ruby programs are usually very picky about > particular versions of their dependencies. > > I call it a "gem hell" and it was a reason why I gave up helping with > Ruby packaging and switched to redmine from source and bundler. Same for > gitlab. I believe the time can be spent more productively than tackling > with upstream with totally different world views. gitlab upstream is very cooperative and they fund my packaging work (many months of full time packaging work). They usually are responsive to requests for updating gem versions. So if another package needs a newer version of a gem, gitlab folks usually respond to my request for updating that gem to the version we need. > Ondřej signature.asc Description: OpenPGP digital signature
Bug#879101: ITP: node-uniqid -- Unique ID Generator
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-uniqid Version : 4.1.1 Upstream Author : Halász Ádám (http://adamhalasz.com/) * URL : http://github.com/adamhalasz/diet-uniqid/ * License : Expat Programming Lang: JavaScript Description : Unique ID Generator This module is a Unique Hexatridecimal ID generator. It will always create unique id's based on the current time, process and machine name. . Node.js is an event-based server-side JavaScript engine. This is in the dependency chain for gitlab 9.5 signature.asc Description: OpenPGP digital signature
Bug#879103: ITP: doctest -- Light and feature-rich C++ testing framework
Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud
Package name: doctest
Version : 1.2.5
Upstream Author : Viktor Kirilov
URL : https://github.com/onqtam/doctest
License : MIT
Programming Lang: C++
Description : Light and feature-rich C++ testing framework
doctest is a light and feature-rich C++98 / C++11 single-header testing
framework for unit tests and TDD.
.
It is inspired by the unittest {} functionality of the D programming
language and Python's docstrings - tests can be considered a form of
documentation and should be able to reside near the production code
which they test. This isn't possible (or at least practical) with any
other testing framework for C++.
Justification: doctest is a B-D of argagg (ITP #878641)
Package name: doctest-dev, as the package installs /usr/lib/doctest/doctest.h
I welcome suggestions on the source or binary names, as well as packaging :)
Re: Unsustainable debian/rules as official build entry point?
Hi, On 18.10.2017 11:36, Guillem Jover wrote: > Using dpkg-buildpackage as the official build entry point would allow > for much debian/rules refactoring and reduction, and optimizations. The important bit isn't whether dpkg-buildpackage is the official entry point, because that isn't what Policy cares about. Policy defines an interface to be used by whatever build tool is used, and all conforming packages implement this interface. If a package doesn't build correctly without environment variables that aren't part of the interface, then the package is buggy and needs to be fixed. If we want to extend the interface, then we need to change Policy. We can just define that all the variables provided by dpkg-buildpackage are part of the interface now (and I don't have a real problem with that), but I'd rather not delegate the Policy definition of a source package to the dpkg-buildpackage manpage, last but not least because we have multiple versions of that manpage in different releases. Simon signature.asc Description: OpenPGP digital signature
Re: Easy discovery of ‘debian/rules’ build problems (was: Unsustainable debian/rules as official build entry point?)
Ben Finney writes ("Easy discovery of ‘debian/rules’ build problems (was:
Unsustainable debian/rules as official build entry point?)"):
> From the rest of your message I infer that the mention of “one consumer”
> there refers to (current or future) ‘dpkg-buildpackage’, is that correct?
Yes.
> Ian Jackson writes:
> > Important consequences of my views include:
> >
> > * The package-provided rules interface needs to remain managed as part
> > of policy (and to continue to have a controlled approach to updates,
> > etc.).
> >
> > * The interface is not *defined by* dpkg-buildpackage: ie it is still
> > possible for dpkg-buildpackage to have a bug where it does not
> > implement the de-jure interface.
> >
> > * Packages may still need to work around bugs in old versions of
> > dpkg-buildpackage; conversely, new versions of dpkg-buildpackage may
> > need to work around bugs in old packages.
> >
> > * For a long time, packages should try to be compatible with old
> > builders which invoke rules directly, even old builders other than
> > dpkg-buildpackage.
>
> I had been under the impression the build tools (SBuild, PBuilder, etc.)
> invoke ‘debian/rules’ directly, and so are a good way to test that
> compatibility. Evidently that impression is wrong, and the use of those
> build tools is not helping to find such bugs.
I think some of those tools may invoke rules directly some of the
time. I haven't done a survey.
> What tools exist to allow package maintainers – as many as possible – to
> get easy (automatic?) notification when the package they maintain is not
> presenting a compatible ‘debian/rules’ build interface?
I'm not aware of anything.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#879125: ITP: python-requests-file -- File transport adapter for Requests
Package: wnpp Severity: wishlist Owner: Antoine Beaupre * Package name: python-requests-file Version : 2017-04-28 Upstream Author : David Shea * URL : https://pypi.python.org/pypi/requests-file * License : Apache 2.0 Programming Lang: Python Description : File transport adapter for Requests Requests-File is a transport adapter for use with the Requests Python library to allow local filesystem access via file:// URLs. Features: * Will open and read local files * Might set a Content-Length header * That’s about it No encoding information is set in the response object, so be careful using Response.text: the chardet library will be used to convert the file to a unicode type and it may not detect what you actually want. EACCES is converted to a 403 status code, and ENOENT is converted to a 404. All other IOError types are converted to a 400. == I plan on shoving this into py2dsp and co-maintaining it with whoever wants to. I need this to simplify feed2exec local file:// access routines and I think it's a generally good package to have available (and why isn't this in requests in the first place??) I'd be happy to delegate this to the Python team as well of course.
Bug#879154: ITP: r-bioc-protgenerics -- S4 generic functions for Bioconductor proteomics infrastructure
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-protgenerics Version : 1.8.0 Upstream Author : Laurent Gatto * URL : https://bioconductor.org/packages/ProtGenerics/ * License : Artistic-2.0 Programming Lang: GNU R Description : S4 generic functions for Bioconductor proteomics infrastructure This Bioconductor package provides S4 generic functions needed by Bioconductor proteomics packages. Remark: This package is a new dependency to complete the upgrade of our whole set of BioConductor packages. It will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/r-bioc-protgenerics.git
Work-needing packages report for Oct 20, 2017
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1131 (new: 4) Total number of packages offered up for adoption: 156 (new: 0) Total number of packages requested help for: 46 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: darkice (#878718), orphaned 3 days ago Description: Live audio streamer Reverse Depends: darksnow Installations reported by Popcon: 134 Bug Report URL: http://bugs.debian.org/878718 gmediaserver (#878730), orphaned 3 days ago Description: UPnP Mediaserver Installations reported by Popcon: 110 Bug Report URL: http://bugs.debian.org/878730 snmp-mibs-downloader (#878723), orphaned 3 days ago (non-free) Description: Install and manage Management Information Base (MIB) files Installations reported by Popcon: 4666 Bug Report URL: http://bugs.debian.org/878723 snmptrapfmt (#878721), orphaned 3 days ago Description: A configurable snmp trap handler daemon for snmpd Installations reported by Popcon: 164 Bug Report URL: http://bugs.debian.org/878721 1127 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 156 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 323 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 992 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2216 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 683 Bug Report URL: http://bugs.debian.org/642906 cargo (#860116), requested 191 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 503 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 3057 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (68 more omitted) Installations reported by Popcon: 179653 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 757 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (120 more omitted) Installations reported by Popcon: 200093 Bug Report URL: http://bugs.debian.org/799864 dee (#831388), requested 461 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg libdee-dev zeitgeist-core Installations reported by Popcon: 64973 Bug Report URL: http://bugs.debian.org/831388 developers-reference (#759995), requested 1146 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 16044 Bug Report URL: http://bugs.debian.org/759995 devscripts (#800413), requested 751 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (24 more omitted) Installations reported by Popcon: 13059 Bug Report URL: http://bugs.debian.org/800413 ejabberd (#767874), requested 1081 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-pottymouth ejabberd-mod-rest (4 more omitted) Installations reported by Popcon: 604 Bug Report URL: http://bugs.debian.org/767874 fbcat (#565156), requested 2836 days ago Description: framebuffer grabber Installations reported by Popcon: 190 Bug Report URL: http://bugs.debian.org/565156 fgetty (#823061), requested 537 days ago Descript
