Re-evaluating architecture inclusion in unstable/experimental
Dear ports maintainer, The ftpmaster team would like to clarify which Debian ports should and/or would like to continue to be part of Debian unstable and experimental. As outlined on the Debian Archive Criteria page[0], the key points to consider are whether the architecture has been part of a stable release, whether it is *likely* to be part of a stable release, as well as whether it currently has a sensible number of active maintainers. Whilst you may be happy to continue the work of maintaining the port regardless, don't forget that excess or otherwise unnecessary architectures involve a shared maintenance burden as well as incurring non-trivial requirements on mirror/Debian resources. The statistics and graphs available on the debian-ports page[1] may provide some objective statistics or reflection on the actual suitability of your architecture's continued inclusion. So, in the first instance, would you like to continue being part of unstable/experimental? [0]: https://ftp-master.debian.org/archive-criteria.html [1]: https://buildd.debian.org/stats/ Cheers, Luke Faraone signature.asc Description: OpenPGP digital signature
Re-evaluating architecture inclusion in unstable/experimental
(resending with corrected address for debian-bsd) Dear ports maintainer, The ftpmaster team would like to clarify which Debian ports should and/or would like to continue to be part of Debian unstable and experimental. As outlined on the Debian Archive Criteria page[0], the key points to consider are whether the architecture has been part of a stable release, whether it is *likely* to be part of a stable release, as well as whether it currently has a sensible number of active maintainers. Whilst you may be happy to continue the work of maintaining the port regardless, don't forget that excess or otherwise unnecessary architectures involve a shared maintenance burden as well as incurring non-trivial requirements on mirror/Debian resources. The statistics and graphs available on the debian-ports page[1] may provide some objective statistics or reflection on the actual suitability of your architecture's continued inclusion. So, in the first instance, would you like to continue being part of unstable/experimental? [0]: https://ftp-master.debian.org/archive-criteria.html [1]: https://buildd.debian.org/stats/ Cheers, Luke Faraone signature.asc Description: OpenPGP digital signature
Re: Failed to create sbuild chroot for cross-compiling
Hi, On Sun, 26 Aug 2018, Holger Wansing wrote: > My intention was indeed, to do a source-only upload. But apparently > sbuild builds the binary package nevertheless, even when told to prepare > for a source-only upload. > > So the main point here is: don't use sbuild, it's the wrong tool for this. It might not be very useful to use sbuild to build a source package but it should be able to do it with the following options: $ sbuild --no-arch-any --no-arch-all --source Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Failed to create sbuild chroot for cross-compiling
Hi, Raphael Hertzog wrote: > Hi, > > On Sun, 26 Aug 2018, Holger Wansing wrote: > > My intention was indeed, to do a source-only upload. But apparently > > sbuild builds the binary package nevertheless, even when told to prepare > > for a source-only upload. > > > > So the main point here is: don't use sbuild, it's the wrong tool for this. > > It might not be very useful to use sbuild to build a source package but it > should be able to do it with the following options: > $ sbuild --no-arch-any --no-arch-all --source I managed to build s390 or mips packages on my amd64 chroot with $ sbuild --host=s390x -s -d unstable --source-only-changes --run-lintian (the --host part being documented at https://wiki.debian.org/CrossCompiling). And according to https://wiki.debian.org/SourceOnlyUpload source-only uploads are recommended now and are recommended to be done with pbuilder or sbuild. That procedere seems sensible at least for me. Thanks Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#907389: ITP: pscircle -- visualizing Linux processes in a form of radial tree
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pscircle Version : 1.2.2 Upstream Author : Ruslan Kuchumov * URL : https://gitlab.com/mildlyparallel/pscircle.git * License : GPL-2 Programming Lang: C Description : visualizing Linux processes in a form of radial tree If output is not specified, pscircle will print the resulting image to X11 root window.
Re: Failed to create sbuild chroot for cross-compiling
Hi, Quoting Holger Wansing (2018-08-25 20:30:15) > The manpage of sbuild-createchroot contains commandline examples for several > use cases, but not for cross-compiling. yes, because sbuild-createchroot has nothing to do with cross-compiling. chroots that you use to compile natively or cross with sbuild are exactly the same. That's why creating a chroot for cross compilation is no different from creating a chroot for native compilation. To cross compile with sbuild, you give it the --build and --host arguments on the command line. It will then pick the right chroot for you but that chroot does not need to have anything special in it. Thanks! cheers, josch signature.asc Description: signature
Re: Failed to create sbuild chroot for cross-compiling
Hi, Am Montag, 27. August 2018 schrieb Johannes Schauer: > Quoting Holger Wansing (2018-08-25 20:30:15) > > The manpage of sbuild-createchroot contains commandline examples for several > > use cases, but not for cross-compiling. > > yes, because sbuild-createchroot has nothing to do with cross-compiling. > chroots that you use to compile natively or cross with sbuild are exactly the > same. That's why creating a chroot for cross compilation is no different from > creating a chroot for native compilation. > > To cross compile with sbuild, you give it the --build and --host arguments on > the command line. It will then pick the right chroot for you but that chroot > does not need to have anything special in it. Yes, I already found that out in the meantime. Thanks for clarifying. Why I made that assumption: when trying to get sbuild running for cross-compiling, I got error messages, that made think I would have to create "some special sort of chroot". And why did I get such errors: I used the options in a incorrect form: I wanted to build a package for s390x, and therefore used --build=s390x or --arch=s390x. Using --host=s390x (which would have been correct) did not seemed correct for me and the manpage does not explain it in detail. I thought like one would think when it comes to virtual machines: there the host is the hardware you are running the VM on. And the virtual OS is the guest. Porting this logic to sbuild would mean, --host=amd64 must be correct (my laptop, the "host", is amd64) but it wasn't. Maybe that could be made clearer in the sbuild manpage? The manpage of sbuild.conf says it clear: It uses terms like "architecture we are building on" and "architecture we are building for". I just added an example for cross-compiling to the wiki page of sbuild BTW. Thanks Holger -- Sent from my Jolla phone http://www.jolla.com/
Re: Failed to create sbuild chroot for cross-compiling
Hello, On Mon 27 Aug 2018 at 12:52PM +0200, Holger Wansing wrote: > And according to https://wiki.debian.org/SourceOnlyUpload > source-only uploads are recommended now and are recommended to be done with > pbuilder or sbuild. I don't think this statement is really true. What's recommended is that you do binary builds, before you upload, using sbuild or pbuilder. Since you're doing that anyway, --source-only-changes is a convenience feature to avoid having to run another command to make the _source.changes. There's no advantage to using --source-only-changes instead of plain `dpkg-buildpackage -S`. (An alternative which also has no need for the running another command to make the _source.changes is `dgit push-source`.) -- Sean Whitton signature.asc Description: PGP signature
Re: Failed to create sbuild chroot for cross-compiling
Am Montag, 27. August 2018 schrieb Sean Whitton: > Hello, > > On Mon 27 Aug 2018 at 12:52PM +0200, Holger Wansing wrote: > > > And according to https://wiki.debian.org/SourceOnlyUpload > > source-only uploads are recommended now and are recommended to be done with > > pbuilder or sbuild. > > I don't think this statement is really true. > > What's recommended is that you do binary builds, before you upload, > using sbuild or pbuilder. > > Since you're doing that anyway, --source-only-changes is a convenience > feature to avoid having to run another command to make the > _source.changes. There's no advantage to using --source-only-changes > instead of plain `dpkg-buildpackage'. Ok guys, in that case someone should overwork that wiki page, since it says exactly this!!! I have just quoted what I read there! /me as new DM getting totally confused with all this, one person says something, the other one says exactly the opposite. Hrrr -- Sent from my Jolla phone http://www.jolla.com/
Bug#907405: ITP: cfgrib -- Python 3 module supporting the CF convention in GRIB files
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: cfgrib Version : 0.8.4.4 Upstream Author : ECMWF (European Centre for Medium-Range Weather Forecasts) * URL : https://github.com/ecmwf/cfgrib * License : Apache2 Programming Lang: Python Description : Python 3 module supporting the CF convention in GRIB files This module provides a Python3 interface to map GRIB files to the NetCDF Common Data Model following the CF (Climate and Forecast) Conventions. The high level API is designed to support a GRIB backend for xarray and it is inspired by NetCDF-python and h5netcdf. Low level access and decoding is performed via the ECMWF ecCodes library.
Bug#907408: ITP: node-map-stream -- Create a through stream from an asynchronous function.
Package: wnpp Severity: wishlist Owner: Dhanesh B. Sabane X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-map-stream Version : 0.0.7 Upstream Author : Dominic Tarr (http://dominictarr.com) * URL : http://github.com/dominictarr/map-stream * License : Expat Programming Lang: JavaScript Description : Create a through stream from an asynchronous function. "Construct pipes of streams of events." . map-stream is refactored out of event-stream to be used as an independent module. . Node.js is an event-based server-side JavaScript engine. map-stream is a dependency for node-event-stream (ITP: 885722). Praveen has agreed to sponsor this package. I'm not a member of the Javascript maintainers team and would like to be one. -- Dhanesh B. Sabane https://dhanesh95.gitlab.io PGP ID: 0xB69A98C9C1642329 Fingerprint: 9655 11F2 0D18 E76A 2396 D64D B69A 98C9 C164 2329
Re: Debian/Xen microsprint, Cambridge, 10th September
Unsubscribe Den mån 27 aug. 2018 15:51Ian Jackson skrev: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > Ian Jackson and Hans van Kranenburg will be holding a small meetup to > work on the Debian Xen packages for buster. This will take place on > the 10th of September. Ian will be hosting it in Cambridge, at the > Citrix offices [1]. > > Nothing really formal is arranged. The agenda is: > * Work on the blockers for Xen 4.11 in sid/buster > * Work on other bugs > * Meet a few of the other Xen folks at Citrix, who may drop in > > If you would like to come along, please email me, Ian Jackson, at > the special address y44...@fyvzl.net, so I know to expect you. > > The Citrix office [1] is 4-5km from Cambridge city centre. (Cambridge > is best traversed by bike.) If you would like to stay in a chain > hotel near the Citrix office, the Orchard Park Travelodge[2] and > Premier Inn[3] are a 30-min walk or a <10-min cycle. > > The nearest train station is Cambridge North, 1.3km from the office > (15 mins on foot). That is convenient, although the train service > there is not very frequent and there are no shops or anything. If you > have or want to rent a bike go to Cambridge (Central) instead and > cycle from there. Cycle hire is available from Rutland Cycling at > Cambridge (Central) station [4] and a variety of other places in > Cambridge. > > Ian. > > [1] Citrix, 1st floor, Building 101 Cambridge Science Park, CB4 0FY > https://www.openstreetmap.org/way/28875290 > Entrance is on the N side. > > [2] https://www.openstreetmap.org/way/140358724 > [3] https://www.openstreetmap.org/way/41272790 > > [4] > https://www.rutlandcycling.com/pages/rutland-cycling-cambridge-station.aspx > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAluD/20ACgkQ4+M5I0i1 > DTnRiAf8DWiAgHKfEjtAajmLHegfPuudJua7Cgmt7IbnlG6PgLp8KDgOGt/zG7xN > 80o0jYbk4ngTeusYXHr6qKmMRpcdh4U44mcecEe0YW4DBAELNHglE/3MGcsvKKKj > S9Tb1d1PTSmf8Ebxu5WC414aF72dKj7JkUoQUnTBgri9w5za09tSIszIC/KinEJA > KN2KrF3i9J3uDM9UKTxlXmnXTz+zHt4lQzqVo9QgwfM8zVcFDMYyUUwHqLXWq0X2 > 13D34pqCy7PF3prKrTsNtLCc0ugyr1r+2BqJIX/j+NsQMVAydsWbwFf8yQkTbW4S > R8zp7Albs3wfcAZk6b/j05ACuEEm2g== > =Mfbg > -END PGP SIGNATURE- > >
Re: Failed to create sbuild chroot for cross-compiling
Hi, Paul Wise wrote: > On Sun, Aug 26, 2018 at 4:42 PM, Holger Wansing wrote: > > > Raphael and you told me to not built the package here locally, but just > > do a source-only upload. > > In general, one should build locally and do a source-only upload. This > is so that you confirm the build works and, by testing it manually, > that the resulting package works before wasting upload bandwidth and > buildd time and so that the package is built on the buildds, which > means it is built in a clean environment (regenerated every few days) > and that the build log is published on buildd.d.o. > > sbuild supports doing both of these at once with the > --source-only-changes option or SOURCE_ONLY_CHANGES configuration > variable. > > > But sbuild does not support this use case. > > sbuild supports this with the option mentioned above, AFAICT the issue > here is cross-building. > > You appear to have created an s390x chroot rather than an amd64 chroot > that builds packages for s390x. Ok, thanks for clarifying. That was indeed the problem: I mis-used the different architecture options, as I already answered to Johannes. Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: Leftover in ftp-master.debian.org/dm.txt after DM -> DD transition
Boyuan Yang dijo [Sun, Aug 26, 2018 at 12:17:17PM -0400]: > Hello all, > > My role in Debian recently changed from Debian Maintainer to Debian > Developer. > However, my DM permission record [1] in > https://ftp-master.debian.org/dm.txt are still left untouched. When I try to > remove them, I would receive errors: > (...) > Is there any way to get rid of those records? Hello Bouyan, I think we (keyring-maint) skipped a step in our keyring push last Friday. I believe this should be fixed now - Please tell me if it's not. (And congratulations for becoming a full-DD ;-) ) signature.asc Description: PGP signature
Re: Let's start salvaging packages! -- disucssion phase closing soon.
Hallo everyone, This is a gentle reminder regarding the Salvaging Process discussion! For all of those, who did not yet have read the proposal, but still want to participate in the discussion, please step forward now, as I plan to start to work on finalizing the text after Saturday, September 1st. Many have already edited and tweaked the proposed text to correct typos and weird (for non native speakers) formulations, which is a very good thing. A BIG THANKS for that! Cheers, -- tobi On Tue, Aug 21, 2018 at 03:05:57PM +0200, Tobias Frost wrote: > Dear fellow Debinites, > > many of you know already that there is currently a discussion about > establishing a package salvaging process within Debian. The discussion > is taking place at debian-devel, but I'd like make people aware which > are not subscribed to -devel. > > For those who did not knew about it, the thread starts at: > https://lists.debian.org/debian-devel/2018/07/msg00453.html, > > You can find the proposal and call for discussion here: > https://lists.debian.org/debian-devel/2018/08/msg00277.html > > Pleases use the -devel thread for the discussion! > > Thanks for your attention! > -- > tobi signature.asc Description: PGP signature
Re: Failed to create sbuild chroot for cross-compiling
Hello, On Mon 27 Aug 2018 at 03:13PM GMT, Holger Wansing wrote: > Ok guys, in that case someone should overwork that wiki page, > since it says exactly this!!! > I have just quoted what I read there! I've fixed it -- thanks. > /me as new DM getting totally confused with all this, one person > says something, the other one says exactly the opposite. > Hrrr Well, it's a wiki, so someone was free to write something incorrect :) -- Sean Whitton signature.asc Description: PGP signature
Bug#907435: ITP: antimony -- Computer-aided design CAD tool
Package: wnpp Severity: wishlist Owner: Tiago Bortoletto Vaz * Package name: antimony Version : 0.9.3 Upstream Author : Matthew Keeter and other contributors * URL : http://www.mattkeeter.com/projects/antimony/3/ * License : MIT Programming Lang: C++ Description : Computer-aided design CAD tool Antimony is a computer-aided design (CAD) tool from a parallel universe in which CAD software evolved from Lisp machines rather than drafting tables. Antimony is built on three mostly-orthogonal axes: - A framework for tracking information flow through directed acyclic graphs - A geometry engine for doing CSG - A standard library of shapes and transforms
