Re: mercurial-buildpackage, now with pristine-tar support
2009/12/2 Jens Peter Secher > > Executive summary: mercurial-buildpackage can now recreate pristine > upstream tarballs. > Does it support 3.0 (quilt) and puts them into mercurial queues? That would be IMHO a killer feature (me is sad that git is getting used for packages so much I am still hoping hg or bzr will overtake git in DVCS package management) -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
2009/12/6 Patrick Schoenfeld : > > Actually the point is what a random package should do if it is beeing > purged in order to undo what it has done on installation in the > corner-case when ucf is beeing removed. > > Regards, > Patrick > My opinion If ucf is just removed then any dangaling files from other packages should stay under ucf responsibility. If ucf is purged ucf package should nuke all / any dangaling files which were touched by other packages. Maybe i don't understand something.... -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560088: ITP: python-portio -- low level port I/O for Linux
Package: wnpp Severity: wishlist Owner: Dmitrijs Ledkovs * Package name: python-portio Version : 0.4 Upstream Author : Fabrizio Pollastri * URL : http://portio.inrim.it/ * License : GPL-3+ Programming Lang: Python, C Description : low level port I/O for Linux Wrapper for the port I/O macros like outb, inb and other provided by the C library on Linux x86 platforms. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560088: ITP: python-portio -- low level port I/O for Linux
2009/12/8 Ben Hutchings : > I do hope not; this should never be used in production. But it may yet > be useful in hardware development. > > Ben. > I'm working on a parallel LCD interface with my custom PCB and I wanted interactive way to use parallel port. Found this decided to package it for myself and anyone else. Should my packaging be changed to i386 & amd64 only? -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: licensecheck and debian/copyright
2009/12/9 Jérémy Lal : > Hi, > is there a way to automatically remove from licensecheck ouput all > the files already described in debian/copyright (when it's properly > formatted) ? > > Jérémy. > Doesn't know how to parse debian/copyright because it could be free-form. There isn't DEB-5 debian/copyright parser available. So this cannot be implemented in licensecheck yet. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
DEP5: Change of status to "Candidate"
Dear all DEP5 is quite stable now (no updates for a while). Implementation format exists and is being used by quite a few packages now. Shall DEP-5 be changed to "Candidate" status? Do we have rough consensus? I believe changing status to Candidate will drive further adoption & testing as well as helper tool development. Quote from DEP0: ### DRAFT state: discussion * every new proposal starts as a DRAFT * anyone can propose a draft * each draft has a number (next free one from document index) * normal discussion and changes to the text happen in this state * drafts should include *extra* criteria for success (in addition to having obtained consensus, see below), that is, requirements to finally become ACCEPTED DRAFT -> CANDIDATE: rough consensus In order for a DEP to become CANDIDATE, the following condition should be met: * consensus exists for *what* should be done, and *how* it should be done (agreement needs to be expressed by all affected parties, not just the drivers; silence is not agreement, but unanimity is not required, either) -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is tabular data in binary format acceptable for Debian ?
2010/1/20 Jean-Christophe Dubacq : > Charles Plessy a écrit : >> Dear all, >> >> I would like to ask on this list a question I asked to the FTP team last >> December, and for which I have not received answer yet. >> >> Is tabular data in a binary format that can be read, written, modified and >> exported using free software acceptable for Debian, or shall we contact the >> upstream author to check if he used an intermediate format (be it text, or >> binary like .odt or .xls) and require the addition of this file to the >> source, >> or shall we provide a text export? > > I had a question similar to that for a program which comes bounded with > a trained neural network. There are files with raw weights. It is > possible to retrain on build the program, but it would take a very long > time, and the resulting network wouldn't even be the same. What is the > "source" in this case? I do not see what "editing" means in this context. > Oh yeah, I remember that thread =) was quite interesting. If you are not sure do not make assumptions.. and that's what ftpmasters did. As for that neural network stuff do it in post-install scripts =) make the users happy as for why dpkg is using all cpu cores forever on that package. *just kidding* -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#582884: ITP: usb-creator -- Live USB creator
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, usb-creator-hack...@lists.launchpad.net, ubuntu-instal...@lists.ubuntu.com Owner: Dmitrijs Ledkovs * Package name : usb-creator Version : 0.2.23 Upstream Author : Evan Dandrea * URL : http://launchpad.net/usb-creator * License : GPL-2, GPL-3 Programming Lang: Python Description : Live USB creator Utility for converting Live Linux CDs into bootable USB sticks for example Ubuntu and Kubuntu. This utility can partition USB stick to allow storing user files in persistence mode. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikfwteinx22glcre7v2u1nvug3dtgznud1be...@mail.gmail.com
Re: Bug#515154: ITP: gitg -- git repository viewer for gtk+/GNOME
2009/2/15 Gunnar Wolf > > Tollef Fog Heen dijo [Sat, Feb 14, 2009 at 06:42:37PM +0100]: > > | when i've had to do this in the past i think i did something like > > | ~.git.. this way you get lots of relevant info, the > > | fact that it's a prerelease of , the date the snapshot was taken, > > | the fact that it's a git snapshot, and the sha sum. and of course it's > > | sortable. > > > > If you use $vers~$ymd.git.$sha or something like that, please do make > > sure the version number slightly bigger than zero. Having version > > numbers that are positive and less than 0 sometimes breaks tools. > > Given that I kept staring at your message thinking something just went > wrong, I suppose somebody else might fall in that logic trap: How can > something be "positive but not bigger than zero"? 0~20090215 is. Nice > math-breaking rules we had to introduce here :) Is it the -0 from the limits theory =D Or -0 is negative? What sign the expression +0-0 will have in limits theory for a function f(x)=x? > > -- > Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 > PGP key 1024D/8BB527AF 2001-10-23 > Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > -- With best regards Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525760: ITP: vitables -- graphical tool to browse and edit PyTables and HDF5 files
Package: wnpp Severity: wishlist Owner: Dmitrijs Ledkovs * Package name: vitables Version : 2.0 Upstream Author : Vicent Mas * URL : http://vitables.berlios.de/ * License : GPL-3+ Programming Lang: Python Description : graphical tool to browse and edit PyTables and HDF5 files ViTables is a component of the PyTables family. It is a graphical tool for browsing and editing files in both PyTables and HDF5 formats. . ViTables capabilities include easy navigation through the data hierarchy, displaying of real data and its associated metadata, a simple, yet powerful, browsing of multidimensional data and much more. . One of the greatest strengths of ViTables is its ability to display very large tables. Tables with one thousand millions of rows (and beyond) are navigated stunningly fast and with very low memory requirements. So, if you ever need to browse very large tables, don't hesitate, ViTables is your choice. I hope to manage this package as part of the Python Apps Packaging Team. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty-backports'), (500, 'jaunty') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530549: ITP: glosung -- dispay words from the bible for each day (also known as Losungen)
Package: wnpp Severity: wishlist Owner: Dmitrijs Ledkovs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: glosung Version : 3.4.1 Upstream Author : Eicke Godehardt * URL : http://www.godehardt.org/losung.html * License : GPL-2+ Programming Lang: C, GTK+ Description : dispay words from the bible for each day (also known as Losungen) This is a small application which has calendar-like functionaliry and for each day it shows words from Bible. German Losungen (combination of words from old and new testaments) are supported and a few other downloadable "daily" bible files. You would run this as one the session login applications. Optionally it has an option to open verse in Xiphos (GTK fully-feature bible study software) so that full verse / context can be read and notes taken. This application will be maintained in the Crosswire packaging team. Xiphos is already maintained by this team. - -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty-proposed'), (500, 'jaunty-backports'), (500, 'jaunty') Architecture: i386 (i686) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJKGtDZAAoJEIh7YGGLPBaud+8P/jfcCzw3sNuPc5FXRt/kWGfz lAkrnvTfoh92EoYOVUcn04XCSsykycqHrBFxFFLDzrnODwjwbZUHJBR5gti3cFA8 3HqIMrqmPEEBIkKYqasyPNwJn1QTVWQQoJplyf3GVDcMeGTQ1BygKpCHMN/xbnVG eYhvxTIk9WziX1UYJ3foyw7DY44A+bvdQWl0OWDd+yuGjoJUlHybw/eFuYcrF51V wapewRRTZhkdxi5Q8r0S/O0uEg29DasM6i1deuWGU3sbIL2Zqbi6Ia9fKCULznLp h547tX8dWkFz4ow/iIKEsDvL3PSDSkHRJVt3o6FljNPEjtGiTKM21euDFDfuf7b4 fVJpdNu7QMIc3xSIwSZ08SEwvJzzXEy4btfCYxDcqk66YA7GItUCNhOiPxn8BQ6/ SqCNGxKKiHLllcj4yqeFT61ds4t9MQKUUlWe/lwxV6J+vSpFR4xbJMcGYbIxA7BI QZKJad/uSDwpKU5NdQmxLYj507pV2O2Xw0oOAVkdx7V7f+W5gLNqsbI6kxbX8Pwl pdoddfRPRzO1eHoVuFo4v0X6At1t3tKkROMFxyHLirqXg4ZvzS2lgMpty2eg+K4Z jgjO7JsAupI7o65xWDP+5AvG9f5rJMcpR+MjmCt3o5rvZLN/vLx+IJ5bsAQbiCSQ JG50/qk34LI6nXzDzb+a =Rw98 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
MIA check for John Francesco Ferlito (johnf)
Dear all, I noticed that offlineimap was a few upstream releases behind. I filed a bug report on the 19th of April, offering to update the package, go through bug reports, and maintain the package. There was no response from the current maintainer, John Francesco Ferlito. His packages have little RC bugs, many normal bugs, warning from lintian/etc. Is John Francesco Ferlito still active? I'm planning on uploading NMU for offlineimap. I'm not sure about other packages. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: MIA check for John Francesco Ferlito (johnf)
On 25/04/12 18:37, Dmitrijs Ledkovs wrote: > Dear all, > > I noticed that offlineimap was a few upstream releases behind. > > I filed a bug report on the 19th of April, offering to update the Just to clarify, I filed MIA query, not because I am impatient since 19th of April 2012, but because according to mia-query last seen activity was on the 26th of August 2011, almost one year ago. > package, go through bug reports, and maintain the package. > > There was no response from the current maintainer, John Francesco Ferlito. > > His packages have little RC bugs, many normal bugs, warning from > lintian/etc. > > Is John Francesco Ferlito still active? > > I'm planning on uploading NMU for offlineimap. I'm not sure about other > packages. > -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Moving /tmp to tmpfs makes it useless
On 27/05/12 14:53, Thomas Goirand wrote: > On 05/25/2012 03:29 PM, Josselin Mouette wrote: >> Which means a *huge* performance >> improvement. Do the measurements yourself, it works with basically >> anything that makes heavy use of /tmp. >> > I have yet to know what application you are talking about. > Who's doing heavy use of /tmp exactly? > $ du -s --si /tmp/temp-lintian-lab-7B9v6Qamm8/ 448M/tmp/temp-lintian-lab-7B9v6Qamm8/ -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc23303.60...@debian.org
Re: Debian documentation permalinks
On 30/05/12 17:17, The Fungi wrote: > On 2012-05-30 13:20:24 +0100 (+0100), Philip Ashmore wrote: > [...] >> By the way, this extends to man/info pages too, but as they're >> versioned, you can refer to a specific version through the package >> version. > [...] > > I've always liked the way OpenBSD provides Web-indexed manpages > versioned by OS release, so I can refer someone to documentation for > a particular command in the context of how it worked and what > options it supported as of a particular stable release version. > > Granted, they have the luxury that their manpages for the core > distirbution are aggregated together in any given release already, > not scattered amongst numerous individual packages. > Isn't it possible to extract those from snapshot.debian.org per-release/per-time ? -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Debian documentation permalinks
On 30/05/12 17:45, The Fungi wrote: > On 2012-05-30 17:35:14 +0100 (+0100), Dmitrijs Ledkovs wrote: >> Isn't it possible to extract those from snapshot.debian.org >> per-release/per-time ? > > Sure, or archive.d.o, but at my day job a lot of the admins I work > with would be hard-pressed to be able to retrieve and extract the > docs from an arbitrary DEB without a lot of instruction... they're > just fine with using Web browsers though since that's how they get > to "the Google" already. > > It sounds like Ubuntu already have a good solution at manpages.u.c, > and have worked through a lot of the tougher issues (like > internalionalized indexing, which I hadn't even thought about). > What I said was a comment w.r.t. bsd's manpages are core to their system. As in, since we have snapshot.debian.org can we not use that platform to extract and serve useful stuff over http directly / easily viewable, e.g. manpages using ubuntu's or some other code. And/or possibly change logs / news files, etc. As in, snapshot.debian.org is just as central to debian infrastructure as things bsd has in place. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: MIA check for John Francesco Ferlito (johnf)
Dear John, On 04/06/12 00:33, John Ferlito wrote: > Hi Dimitri, > > Just noticed you uploaded a new package. WOuld you like to officially > take over maintainership? > Yes, I would. Many debian developers use this package. All of your expertise with the package would be highly appreciated, as the list of bugs is still large. Regards, Dmitrijs. > On Thu, Apr 26, 2012 at 09:50:09AM +1000, John Ferlito wrote: >> Howdy, >> >> I'm around, I was married recently so the last few months have been a >> bit chaotic. I'll look over all my stuff over the weekend. Feel free >> to upload an NMU in the meantime though and I'd be more than happy to >> have another maintainer. >> >> Cheers, >> John >> >> On Wed, Apr 25, 2012 at 06:37:38PM +0100, Dmitrijs Ledkovs wrote: >>> Dear all, >>> >>> I noticed that offlineimap was a few upstream releases behind. >>> >>> I filed a bug report on the 19th of April, offering to update the >>> package, go through bug reports, and maintain the package. >>> >>> There was no response from the current maintainer, John Francesco Ferlito. >>> >>> His packages have little RC bugs, many normal bugs, warning from >>> lintian/etc. >>> >>> Is John Francesco Ferlito still active? >>> >>> I'm planning on uploading NMU for offlineimap. I'm not sure about other >>> packages. >>> >>> -- >>> Regards, >>> Dmitrijs. >>> >> >> >> >> -- >> John >> Blog http://www.inodes.org >> LCA2012 http://lcaunderthestars.org.au > > Cheers, > John > -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Fwd: Processing of libavg_1.7.1-1_amd64.changes
Dear all, I have uploaded libavg_1.7.1-1 into delayed/7 queue. After that it will hit new, as it was previously removed. Previously this package was removed due to being RC buggy and not used. The maintainance of this package has been picked in Ubuntu. I am now reintroducing this package back into Debian. All bugs are fixed ;-) And there are ~900 users in ubuntu popcon, which suggests that this package is still useful. Thanks a lot OXullo for maintaining this package in Ubuntu. Thanks a lot for Torsten for maintaining it before then. All three of us are listed in Maintainer/Uploaders fields. Regards, Dmitrijs. Original Message Subject: Processing of libavg_1.7.1-1_amd64.changes Date: Thu, 14 Jun 2012 20:20:55 + From: Debian FTP Masters To: x...@debian.org libavg_1.7.1-1_amd64.changes uploaded successfully to localhost along with the files: libavg_1.7.1-1.dsc libavg_1.7.1.orig.tar.gz libavg_1.7.1-1.debian.tar.gz python-libavg_1.7.1-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org)
Re: Fwd: Processing of libavg_1.7.1-1_amd64.changes
On 14/06/12 22:37, Cyril Brulebois wrote: > Dmitrijs Ledkovs (14/06/2012): >> I have uploaded libavg_1.7.1-1 into delayed/7 queue. After that it >> will hit new, as it was previously removed. > > Why the seven days delay? It looks to me like you could/should skip > that. (dcut has “reschedule” for that.) > I was undecided whether a new ITP is required or not and whether this will be classed as a hijack. So I left 7-days for debating on debian-devel. If there is consensus that it's ok, then I will consider resheduling. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fda5a16.6010...@debian.org
Re: Malloc and security
On 18/06/12 21:11, Jamie White wrote: > Hiya > > Just a quick question, which malloc, is there anyway that this function > (used in C) could allocate memory into already allocated memory, such as > the stack - or code space! > > Jamie > > Cross posting offtopic email to two mailing lists (ubuntu-devel and debian-devel) is not nice. If you want quicker response times IRC would have been more appropriate. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fdf9254.5080...@debian.org
Re: Malloc and security
On 18/06/12 21:25, Jamie White wrote: > Hiya > > Just a quick question, which malloc, is there anyway that this function > (used in C) could allocate memory into already allocated memory, such as > the stack - or code space! > > Jamie > > sorry, not to two mailing lists. to the same one twice in a very short space of time. Could have been a user / mail client error. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fdf92ae.3080...@debian.org
Re: build-time testing of pure arch:all packages
On 22/06/12 19:23, Goswin von Brederlow wrote: > Yaroslav Halchenko writes: > >> On Fri, 22 Jun 2012, Goswin von Brederlow wrote: archive-wide rebuilds of arch:all packages as we routinely do rebuilds of arch:any packages. (Cc:-ing Lucas, for his great work on QA rebuilds.) >>> Are archive wide rebuilds done on anythiong but i386/amd64? >> >> IMHO if archive-wide rebuild could be carried on at least one >> representative big-endian architecture (e.g. sparc) -- it might already >> be quite useful. >> >> Do we also have some time share on one of the top3 HPC boxes [2] + >> Lucas#2 to take care about it? ;-) >> >> [2] http://en.wikipedia.org/wiki/TOP500 > > My boss recently came back from a conference and he brought back a flyer > about 2U arm server with up to 192 cores and 192 GB ram (on 12 planes a > 4 quad core cpus and 4x 4GB ram each) with 10 Gbit networking. > > I wonder: How long would an archive wide build take with 192 armel > buildds? > 1 day, 5 hours, 48 minutes, 54.3 seconds libreoffice build in ubuntu amrhf https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.3-0ubuntu1/+build/3458035 Regards, Dmitrijs. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe4bbcf.2030...@debian.org
MIA ping Jürgen Rinas (sinfo)
Dear all, sinfo package is not RC, but it hasn't been updated in a while. Jürgen Rinas or Gaudenz Steinlin do you intend to continue maintaining it? -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe52739.2090...@debian.org
Re: MIA ping Jürgen Rinas (sinfo)
On 23/06/12 07:47, Gaudenz Steinlin wrote: > > Hi Dimitrijs >> >> sinfo package is not RC, but it hasn't been updated in a while. >> >> Jürgen Rinas or Gaudenz Steinlin do you intend to continue maintaining it? > > Thanks for the heads up. Jürgen do you still intend to maintain sinfo in > Debian? The last contact we had was quite some time ago and back then > you were still interested. I can do an occasional update, but as I'm no > longer using it myself I won't do too much (especially if there are no > bugs reported). If someone wants to fill my role as sponsor and > occasional co-maintainer just contact me. I'm happy to hand this over to > more interested parties. > This package came up: * FTBFS with ld --as-needed http://bugs.debian.org/638598 Fixed in ubuntu, patch submitted to debian * NMU FTBFS with gcc 4.7 (0.0.42-1.1) Fixed by doko, merged in ubuntu by me for boost1.49 transition. I would appreciate if fix for #638598 is uploaded into debian, then the package would be in sync in ubuntu. There is a new upstream release. After that, let's find a maintainer for this package: Jürgen, RFA/someone new, orphan... At least if it's orphaned people, QA uploads can be done. -- Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe656f4.8000...@debian.org
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On 27/06/12 14:20, Ben Hutchings wrote: > On Wed, 2012-06-27 at 14:09 +0300, Serge wrote: >> 2012/6/25 Ben Hutchings wrote: >> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2 and they use it in CFLAGS/CXXFLAGS. >>> >>> Presumably as a workaround for build systems that do not respect >>> CPPFLAGS. >> >> I actually noticed that because it's "-Wp,-D...", not "-D...". But I guess >> you're right, it's in CFLAGS because many build systems support CFLAGS, >> but only autotools support CPPFLAGS. >> >>> GNU make's implicit rules use CPPFLAGS. If other build systems or >>> overriden rules don't use it, it's a bug. This can of course be >>> worked around in debian/rules. >> >> Well, such argument can be applied to any build system. For example: Cmake >> uses CMAKE_C_FLAGS, but GNU's make does not use it. It's a bug. > > GNU make is the standard build sequencing tool for the GNU system (i.e. > for Debian). CMake and the others probably ought to follow the platform > conventions. > > [...] Actually CMake *does* honour CFLAGS and copies them into CMAKE_C_FLAGS, it doesn't do this for CPPFLAGS though. Look at the other cmake packages how hardening flags are handled there. Something like copying the set CPPFLAGS into CXXFlags or something. >> Talking just about autotools: >> * CPPFLAGS without CFLAGS are used only by ./configure script >> * CPPFLAGS without CFLAGS are used only for some conftests >> * -D_FORTIFY_SOURCE=2 means nothing for those tests >> * -D_FORTIFY_SOURCE=2 does nothing at all without -O2 >> So even for autotools there's no reason to keep -D_FORTIFY_SOURCE=2 in >> a CPPFLAGS variable. It can be easily dropped. > [...] > > I do take the point that it's not obviously useful to separate out > CPPFLAGS. > > Ben. > -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
On 29/06/12 18:21, Mehdi Dogguy wrote: > Package: wnpp > Severity: wishlist > Owner: Mehdi Dogguy > > * Package name: ben > Version : 0.6 > Upstream Author : Mehdi Dogguy and Stéphane Glondu > * URL : http://ben.debian.net/ > * License : AGPL-3+ > Programming Lang: C, OCaml > Description : toolbox for Debian maintainers > > This is a collection of useful tools that Debian maintainers can use > to make their packaging work easier. They all work with regular > Debian package list files, and should be useful for Debian > derivatives as well. This package ships a single executable, "ben", > with the following subcommands: > * download: download a set of package list files from a mirror > * monitor: monitor the status of a set of packages across several > architectures (useful for transitions) > * query: query packages using their metadata (similar to grep-dctrl, > but uses a dedicated query language) > * tracker: frontend to multiple monitors > > > Yes! Please package this I am in ecstasy =) With respect to names, You could name it something boring like: debian-transition-tracker or something along the lines. I will file loads of wishlist bugs, and maybe even help fixing them! Who knows ;-) -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#683979: ITP: clusterit -- utilities for distributed computing and management of clusters
Package: wnpp Owner: Dmitrijs Ledkovs Severity: wishlist * Package name: clusterit Version : 2.5 Upstream Author : Tim Rightnour * URL or Web page : http://sourceforge.net/projects/clusterit/ * License : BSD-4-clause Description : utilities for distributed computing and management of clusters . A collection of utilites that help manage large sets of machines over SSH protocol. It includes utilities to execute the same command(s); to execute in sequence; to schedule a queue of tasks across all machines. A distributed virtual terminal is also included. . This package can be used as an alternative to parrallel-ssh for managing cluster of machines. It also can be used as a lightweight distributed computing environment similar to Hadoop or any other MapReduce implementation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw817xyi@canonical.com
Re: node-like file conflicts
On 6 August 2012 14:37, Jakub Wilk wrote: > The following package pairs: > 1) are co-installable, > 2) both ship binaries with the same name, but in different directories > within $PATH (e.g. one in /usr/bin, another in /usr/sbin): > > sethdlc: ax25-tools dahdi > crm: crm114 pacemaker > cutter: cutter-testing-framework-bin cutter > gearmand: gearman-job-server gearman-server > update-locale: gosa-dev locales > sendpage: hylafax-client sendpage-server > rpcinfo: libc-bin rpcbind > lid: libuser id-utils > nfsiostat: nfs-common sysstat > vmware-user-suid-wrapper: open-vm-tools open-vm-toolbox > ptest: pacemaker parmetis-test > siggen: siggen tripwire > tcpd: tcm tcpd > vuname: util-vserver umview > > Any volunteers to file bugs? > Does this include search across all components of standard $PATH and across all packages? How did you run this check? I would be interested in duplicates (shipped by the single package or different packages) across /bin & /usr/bin; /sbin & /usr/sbin; /lib & /usr/lib and etc. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluj53vhj9ogysz1r-4f-4n5c-0-vgae-u6svhdef0xv...@mail.gmail.com
Re: adopting a recently removed package
On 15 August 2012 23:45, Jerome BENOIT wrote: > Hello List: > > I would like to adopt a recently removed package: > The package have still a Sid webpage, but accordingly there is no more > maintainer; > but there is a maintainer in its Squeeze webpage. > > How may I proceed to adopt it ? > I really don't know, and I am a DD. So once I wanted to salvage a package which was removed in testing & unstable. I uploaded into delayed & sent an email to debian-devel, only to be hinted that I should have simply salvaged it (uploaded it without asking any questions). If the package was removed, and you are not a DD, I'd recommend to prepare the package changes, upload to mentors and file RFS bug and wait for sponsorship or comments. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlui9bjfuqigft+mt7xqflwagfzudsdpkz0tpdhzkibj...@mail.gmail.com
Re: [proposal] use xz compression for Debian package by default
On 29/08/12 15:01, Jon Dowland wrote: > On Tue, Aug 28, 2012 at 12:56:47PM +0200, Vincent Lefevre wrote: >> Before wondering whether PNG files should have an additional >> compression level, is there any reason why a better PNG compression >> isn't used in the first place? For instance, "optipng -o9" tries >> various parameters and keeps the best one. > > So recompress upstream PNGs and suffix +dfsg to the source version? There > might > be some disadvantages to this. If you are using VCS to manage the package, you > are probably carrying the upstream PNGs in that already, so there's an > appreciable increase in repository size to carry the optimized PNGs too. > Another approach could be to inject optipng into the build process and treat > the outputs like compiler output (packed into binary packages, thrown away on > clean), but then repeated builds could be CPU-expensive. Perhaps getting > upstream to carry better-compressed PNGs in their next release is a good idea. > > Better to create a dh_ plugin to do this. I think there is something like that already floating around for PNGs, at least on Ubuntu the pkgbinarymangler does re-compress all PNGs. I don't think it's worth +dfsg, and CPU cycles will only be wasted once on the maintainer side, since most of PNGs are in arch:all packages anyway. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Changes to cia.navi.cx -> cia.vc
Dear all, cia.navi.cx is deprecated, but now has stopped working. You should use cia.vc instead. Looking on vasks there are many team tooks that submit to cia.navi.cx (mail mail or RPC), please update those to use cia.vc. hostname instead. Alioth SVN: axel/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx debianjr/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx modconf/hooks/ciabot_svn.py:server = "c...@cia.navi.cx" pgp-tools/hooks/ciabot_svn.py:server = "http://cia.navi.cx"; pkg-bet/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-evolution/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-freedesktop/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-glibc/hooks/ciabot_svn.sh:cia_address="c...@cia.navi.cx" pkg-grub/hooks/ciabot_svn.py:server = "http://cia.navi.cx"; pkg-gstreamer/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-lighttpd/hooks/ciabot_svn.sh:cia_address="c...@cia.navi.cx" pkg-multimedia/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-multimedia/hooks/svnmailer.conf.bak:cia_rpc_server = http://cia.navi.cx pkg-ocaml-maint/hooks/ciabot_svn.sh:cia_address="c...@cia.navi.cx" pkg-parsix/hooks/svnmailer.conf.gnome:cia_rpc_server = http://cia.navi.cx pkg-parsix/hooks/svnmailer.diff:-cia_rpc_server = http://cia.navi.cx pkg-pulseaudio/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-ruby-extras/hooks/ciabot_svn.py:server = "http://cia.navi.cx"; pkg-ruby/hooks/ciabot_svn.py:server = "http://cia.navi.cx"; pkg-utopia/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-vim/hooks/ciabot_svn.sh:cia_address="c...@cia.navi.cx" pkg-voip/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-xfce/hooks/ciabot_svn.py:server = "http://cia.navi.cx"; pkg-xfce/hooks/svnmailer-corsac.conf:cia_rpc_server = http://cia.navi.cx pkg-zenoss/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx pkg-zope/hooks/ciabot_svn.py:server = "c...@cia.navi.cx" ssmtp/hooks/svnmailer.conf:cia_rpc_server = http://cia.navi.cx Are broken Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhxqg_dk90oyvg7odoqtxv8ntjtvrixx+fa_kxv1kq...@mail.gmail.com
Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package
On 10 September 2012 13:46, Jon Dowland wrote: > On Sat, Sep 08, 2012 at 10:01:17PM +1000, Dmitry Smirnov wrote: >> When building for as many architectures as we have, situation when some >> dependencies are missing (or can't exist) on some architectures is not rare. >> >> However we still want to build our packages with all features possible. > > You should have two (or more) binary targets, each of which excludes the > architecture(s) that do not support the particular feature. E.g. if baz is > not available on hurd: > > Package: foo > Architecture: any !hurd > Build-Depends: bar libbaz-dev > > (I forget the precise syntax for excluding an arch here) > and > > Package: foo-hurd > Build-Depends: bar > Architecture: hurd > > Or possibly in some circumstances > > Package: foo-minimal > Build-Depends: bar > Architecture: any > > …where foo without baz might be useful for someone on any architecture. > Sure, but is that allowed? Specifying Build-Depends in the Package stanzas? My understanding was that Build-Depends are specified in the Source: paragraph. The "-full / -minimal" binary package split, gets rid of the optional run time depends, but this does not remove the build-time dependency. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluht1nbwk5vma1-x3wx0ujvcjfahx9vcodkdp0bfxez...@mail.gmail.com
Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package
On 8 September 2012 09:30, Adam Borowski wrote: > On Sat, Sep 08, 2012 at 05:08:34PM +1000, Dmitry Smirnov wrote: >> Package: wnpp >>Package name: optional-dev >> >> >> >> There are situations when some of the libraries listed in Build-Depends >> are optional i.e. build system is smart enough to avoid failure when >> such library is missing. >> >> Often some development libraries are not available on all architectures >> in which case maintainer should know beforehand which architectures may >> satisfy this dependency and maintain an up-to-date list of architectures >> for such packages, like in the following example: >> >> Build-Depends: libchamplain-gtk-0.12-dev [!m68k !sh4], >>libopenipmi-dev [!hurd-any !arm] > [...] >> All the above problems may be addressed by using this package as >> alternative to optional build dependency like in the example below: >> >> Build-Depends: libchamplain-gtk-0.12-dev | optional-dev, >>libopenipmi-dev | optional-dev > > (Using "Build-Depends: libfoo-dev | optional-dev" below.) > > I'm afraid this is a bad idea for three reasons: > > 1. you'd get a misbuild if libfoo-dev happens to be temporarily >uninstallable due to a transition of something it depends on, >it or one of its dependencies happen to wait for a co-installed >multiarch package, and so on > > 2. same, if libfoo-dev is not yet built. It can happen if it has just been >uploaded, we're in the middle of an archive rebuild (a new arch, some >derivative), etc. > > 3. don't certain build modes (sbuild IIRC) ignore any alternatives in the >first place? If so, you'll cause a FTBFS. 4. the optional-dev can then be only used once, as once it's installed to satisfy one OR dependency you will not get the "real" once any more. I had a valid reason to use such "fake" or dependencies. When a -dev package splits into two & you want to build across distribution releases without modifying your packaging. gtkhtml was split into gtkhtml and gtkhtml-editor, to use single packaging across distro releases I did a dance of: gtkhtml-editor-dev | gtk-dev, gtkhtml-dev. And didn't specify gtk explicitely as it was pulled in by gtkhtml anyway. [1] [1] package names are for demonstration purposes only from my head, I am sure their real names are slightly different, but you get the point. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhsielhd_wz1xko4_+minhkk-dt+eeh5s-tohidr7v...@mail.gmail.com
Re: "X-" Prefixes deprecated by RFC 6648.
On 13 September 2012 00:55, Charles Plessy wrote: > Dear all, > > I would like to share with you the recently published RFC 6648, which > deprecates the use of "X-" prefixes in "application protocols" > > BEST CURRENT PRACTICE > > Internet Engineering Task Force (IETF)P. Saint-Andre > Request for Comments: 6648 Cisco Systems, Inc. > BCP: 178 D. Crocker > Category: Best Current Practice Brandenburg InternetWorking > ISSN: 2070-1721M. Nottingham >Rackspace >June 2012 > > >Deprecating the "X-" Prefix and Similar Constructs > in Application Protocols > > Abstract > >Historically, designers and implementers of application protocols >have often distinguished between standardized and unstandardized >parameters by prefixing the names of unstandardized parameters with >the string "X-" or similar constructs. In practice, that convention >causes more problems than it solves. Therefore, this document >deprecates the convention for newly defined parameters with textual >(as opposed to numerical) names in application protocols. > > Full text available at http://tools.ietf.org/html/rfc6648 > Release Goal to purge all references to X from all packages? Regards, Dmitrijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhb3bttgcv-_9txif4rrusu+jl89ckwq4wnv3rrb0l...@mail.gmail.com
Upstart & kFreeBSD port for Debian
On 21 May 2013 21:53, Lucas Nussbaum wrote: > Hi, > > On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote: >> Hello, >> > - Neither systemd nor upstart are likely to be ported to kfreebsd soon, > as they both rely on many Linux-specific features and interfaces. > Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I have discussed the state of the kfreebsd possibility a few times over the past year or so. It boiled down to: if we have waitid & inotify it should be possible to have a reasonable stab at doing a kfreebsd port for the system-wide upstart init (with libnih and mountall). For session init we currently do use prctl to set subreaper, but one can still have session upstart init without that syscall. Was there something else needed? Or can anyone else spot other "big incompatible" chunks of code? As it happens, waitid has been recently implemented in the FreeBSD 9.1 kernel [1]. While inotify is not-essential, it's still very nice to have and it can be reasonably & sufficiently be implemented for upstart's needs using FreeBSD's kqueue/kevent. It was also roughly felt that code base can be kept reasonably tidy by using weak symbols to encapsulate bsd/linux specific parts of the code base, not dissimilar from how other large projects sometimes choose to handle such portability. [1] If I am correct to trust http://www.freebsd.org/cgi/query-pr.cgi?pr=170346&cat= Not sure if it is or when it will be available in debian's kfreebsd port Regards, Dmitrijs. Ubuntu, Debian and Upstart Developer. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUgm++e4185+a1J=rpy4cpdivvhtkx7uowx0ds66znc...@mail.gmail.com
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On 13 May 2013 19:14, Russ Allbery wrote: > Philip Hands writes: > >> No matter what the technical merits, the inevitable flame war regarding >> copyright assignment seems very likely to render upstart a non-starter >> as an essential element of Debian. > > Debian already uses many packages as part of its essential set that > require copyright assignments. coreutils springs immediately to mind. I > realize some people see a distinction between assigning copyright to the > FSF and assigning copyright to Canonical, but I think the distinction is > relatively fine, and certainly not strong enough alone to make it a > non-starter, at least IMO. > I have signed Canonical's and Python Software Foundation's contributor agreements. But I have no intention to assign copyright to FSF at the moment, given it's past well documented bad practices at doing things for the sake of it, instead of benefit of the wider free software community. I'm sure there are people who hold a different opinion. Luckily Debian source package formats handle patches very well and all projects covered by above agreements are sufficiently open sourced for Debian main as per Debian's Social contract & DFSG. If one day I write a patch against an FSF project, my opinion might change depending on the value of the patch. But I am yet to write such a patch, FSF projects are quite good. But I don't see it being productive to measure "hypothetical unwritten patches" and automatically attribute those to copyright agreements. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjTVO0vjzkH0gh-oX=5_egcoyxfy-2j3c4c_sb2dj-...@mail.gmail.com
Re: Upstart & kFreeBSD port for Debian
On 22 May 2013 01:16, Michael Biebl wrote: > Am 22.05.2013 02:00, schrieb Dmitrijs Ledkovs: >> On 21 May 2013 21:53, Lucas Nussbaum wrote: >>> Hi, >>> >>> On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote: >>>> Hello, >>>> >>> - Neither systemd nor upstart are likely to be ported to kfreebsd soon, >>> as they both rely on many Linux-specific features and interfaces. >>> >> >> Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I >> have discussed the state of the kfreebsd possibility a few times over >> the past year or so. >> >> It boiled down to: if we have waitid & inotify it should be possible >> to have a reasonable stab at doing a kfreebsd port for the system-wide >> upstart init (with libnih and mountall). For session init we currently >> do use prctl to set subreaper, but one can still have session upstart >> init without that syscall. >> >> Was there something else needed? Or can anyone else spot other "big >> incompatible" chunks of code? > > https://lists.debian.org/debian-bsd/2009/07/msg00122.html > Going down the list: - inotify - internetz tell me kevents/kqueue is the way to go - waitid() - issue closed in FreeBSD in February 2013, is it usable? - epoll, eventfd, signalfd, timerfd - again internetz tell me kevents/kqueue can do all of this, better yet there is libevent that can do those portably across linux and bsd - ptrace - FreeBSD does have ptrace - differences in api/capabilities? I didn't know about either of these =) looks awesome. Need to look into how upstart is using those, to see how necessary those are and how to implement them on FreeBSD. - netlink proc connector - netlink udev interface > Nothing really happened since 2009, so I wouldn't hold my breath > regarding a *BSD port. > Apart from FreeBSD folks implementing just recently waitid()?! =))) That's huge. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUj-bgXPfJ=uneDR4Nk=5jerSZOHzptvJ=hfcub731s...@mail.gmail.com
Re: Upstart & kFreeBSD port for Debian
On 22 May 2013 03:09, Guillem Jover wrote: > Hi! > > On Wed, 2013-05-22 at 01:47:42 +0100, Dmitrijs Ledkovs wrote: >> On 22 May 2013 01:16, Michael Biebl wrote: >> > Am 22.05.2013 02:00, schrieb Dmitrijs Ledkovs: >> >> On 21 May 2013 21:53, Lucas Nussbaum wrote: >> >>> On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote: >> >>> - Neither systemd nor upstart are likely to be ported to kfreebsd soon, >> >>> as they both rely on many Linux-specific features and interfaces. > >> >> Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I >> >> have discussed the state of the kfreebsd possibility a few times over >> >> the past year or so. > > I started porting libnih and upstart to GNU/kFreeBSD some months ago, > just for fun, whenever I had nothing else to do. But then I'm not > interested in assigning my copyright to a for-profit company that is > not employing me (and no, this is not a job request); so I didn't > post anything yet, because I don't use upstart, didn't want to promise > anything (still don't), and it would present as an _interesting_ > situation for the Debian upstart maintainers (either reject the > patches or carry them forever as a small fork...). > For libnih: fork it, push it, merge propose into https://github.com/keybuk/libnih As Steve already mentioned, Scott is the upstream for libnih. >> >> It boiled down to: if we have waitid & inotify it should be possible >> >> to have a reasonable stab at doing a kfreebsd port for the system-wide >> >> upstart init (with libnih and mountall). For session init we currently >> >> do use prctl to set subreaper, but one can still have session upstart >> >> init without that syscall. >> >> >> >> Was there something else needed? Or can anyone else spot other "big >> >> incompatible" chunks of code? >> > >> > https://lists.debian.org/debian-bsd/2009/07/msg00122.html > > I think I've posted this multiple times, whenever those items lists > are posted: > > <http://www.hadrons.org/~guillem/debian/ports/porting> > And somehow I have missed it up until now. Very nice guide. I like it a lot. Concise pointers =) Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhwJQKsshXv+_5UkrH=8kyxbdr3vmpr1otl0hu-eij...@mail.gmail.com
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On 22 May 2013 03:32, Paul Tagliamonte wrote: > On Wed, May 22, 2013 at 01:16:29AM +0100, Dmitrijs Ledkovs wrote: >> I have signed Canonical's and Python Software Foundation's contributor >> agreements. >> But I have no intention to assign copyright to FSF at the moment, >> given it's past well documented bad practices at doing things for the >> sake of it, instead of benefit of the wider free software community. > > The FSF's end goal is Free Software[1], whereas Canonical's is cold, > hard, cash. Nothing wrong with that, but you have to admit that they > don't really care about ideology or ethics, but providing a distro > people will use (and buy services / devices / support for). > > I don't see how you can see the FSF as worse than Canonical in terms of > respecting your code and end user freedom. > > Relatedly, the PSF is great. > > I responded with my Ubuntu address to drive this point home clearly - I > support what Canonical and Ubuntu are doing; so much, in fact, I've > spent over 5 years of my life helping make that happen. > > That being said, I don't grok your argument. > > [1]: OK. Not Free Software as such, but Free Software as a means to an > end -- namely, free users. > My stance is reverse. IMHO Canonical has done more to promote free software among people, companies, businesses, non-for-profits, governments and NGOs than any other free software company or organisation. It can be seen from the amount of pre-installed machines shipped with Ubuntu from all Tier-1 hardware vendors and many other smaller hardware vendors. Oracle is a company with a "cold, hard, cash" goal. Canonical whilst striving to be self-sustaining, evidently spends most of its profits/money on new Research&Development be it Linaro, Unity, Juju or the SaaS offerings like U1 & Landscape suite of services. Some produce more open source software than others, and all of these will be ranked differently by each person differently, am I still yet to be screwed by Canonical's projects. Please correct me if I am wrong, but none of Canonical CA covered projects yet to (a) change their license or (b) go proprietary. Since Canonical's CA inception, it has been modified to grant less rights to canonical and counter keep more to the authors, thus adjusting the balance based on community feedback. And more and more software is released as open source. Contrast with what Oracle has been doing in the past years. FSF on the other hand: * GFDL fiasco - because clearly the world cannot live another day without RMS essay, and oh my one shouldn't generate GCC documentation from code comments * SSL licensing - the combination of gnutls going v3 & v3 still being incompatible with OpenSSL and/or v2 * Clang/LLVM - moving gcc to v3 & thus making Apple contribute/develop LLVM instead of continuing to use gcc (/me is on gcc camp, thus it's fsf's negative point. Others might cheer for this move, which gave the birth to Clang, eventually) * GNU Project mismanagement/micromanagement - (GnuTLS & sed & others) https://lwn.net/Articles/529522/ https://lwn.net/Articles/530460/ These are just a few grudges I have against FSF. I like FSF EU division though. As you say, "Relatedly, the PSF is great". So CA alone, is really not a cause or reason for one's actions. In general, I like CAs as it assigns liability to a 3rd party that can afford lawyers. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluiawahrejt6mpr_4c2gjdixpbjw+cjiizthkdyhthu...@mail.gmail.com
Re: using upstart in Debian [was, Re: Debian systemd survey]
On 23 May 2013 10:37, Ole Laursen wrote: > Steve Langasek debian.org> writes: >> Sorry you ran into trouble with upstart. > > Not a DD, just a happy Debian user, hope you'll excuse me, but on the topic > of Upstart, I have some technical comments on why, surprisingly, I think it > may not be mature enough yet. > > A couple of years ago I was doing emergency consultancy work for a company > using Red Hat and upstart. The dev dude there was really on top of new tech > and had made Upstart scripts for starting his Python web apps (which I > thought was a great idea, this was back when Upstart looked like THE > alternative to sysvinit). > > However, when debugging it, we had some weird lock-ups from Upstart, > basically you'd ask Upstart for the status of the job and it would lock up > really hard (IIRC Ctrl-C wouldn't work). After much swearing, it wasn’t > immediately obvious why Upstart would be the culprit, I found this (at the > time) old bug: > > https://bugs.launchpad.net/upstart/+bug/406397 > > Upstart couldn't track the forks going on inside a started process reliably. > As one commenter notes: “I’m wondering why this bug has a importance of > “low”, as it renders using upstart for many daemons (including apache, > postfix and others) as impossible.” This bug doesn't appear to be fixed yet. > > So unfortunately, I don't think Upstart is ready for handling a server boot > with native job files. I had a look at the apache2 packages for Ubuntu > raring, and there’s a sysvinit file, but no Upstart job. > > I'm telling you the whole story here to explain that this isn't just a minor > problem for packages shipped with the distribution, it's also a potentially > big problem for ISVs. > Yes, it's a real bug and as clearly stated in the bug report comments above it is due to using ptrace to count/track forks. The best way to run daemons under upstart is in foreground, then correct PID is tracked and the complete stdout/stderr is properly collected and stored in /var/log/upstart/$job.log (even early boot output). How to establish fork counts & the consequences of getting it wrong are well documented in the upstart cookbook (see below). As far as I understand (correct me if I am wrong), systemd instead of counting/tracking forks uses cgroups to keep track of the started processes. > > Also on technical merits although more philosophically, with Upstart you're > expressing yourself in an event-based DSL rather than writing configuration > files. It's pretty generic. But unfortunately, that means it's also not > entirely straightforward, and, I believe, easier to get wrong. Scott had > some explaining blog posts before he left Canonical that I still find > confusing (from the POV of just getting a job file done): > > http://netsplit.com/2010/12/20/events-are-like-methods/ > http://netsplit.com/2010/12/03/event-matching-in-upstart/ > Since those blog posts were published a coprehensive documentation book was written and is constantly kept up to date. http://upstart.ubuntu.com/cookbook/ It actually guides & explains upstart concepts in a coherent and straight-forward manner with a very large section of examples on how to achieve various goals & tasks. > Lennart Poettering wrote in his initial blog posts on systemd about why he > thought this fundamental model of Upstart wasn't entirely spot on, and while > I thought this might have been NIH BS at the time I've later come to the > conclusion that he's probably right. Taking as much confusing logic as > possible out of the job files does seem like a win. > Blog posts are interesting to read, but at times I'd like to look up reference manuals which are more than bear minimal man pages. Whilst systemd ships manpages, the website has either incorrectly formatted wiki-pages and/or eventual links to lennart's blog posts. Where is systemd's documentation? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhbgvwkp8tsgicgmq2zermb61idbjgwd6261euohqn...@mail.gmail.com
Re: systemd .service file conversion
On 24 May 2013 23:16, Игорь Пашев wrote: > 2013/5/23 Helmut Grohne : >> * stdout/stderr to syslog redirection >>This is possibly implementable, but needs more than a line of shell. > > In Solaris SMF each service has its own log file with SMF messages > *and* all stdout/stderr > > pashev@bok:~$ find /var/log/svc/ Ditto with upstart under /var/log/upstart/ Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujicd-jtbpseaylxft2kcuwc6xqo6m_d61xohdcksx...@mail.gmail.com
Re: Default desktop for jessie Was: Re: Debian/Wheezy general rant ...
On 5 June 2013 23:02, Russ Allbery wrote: > Svante Signell writes: > >> Not everybody agrees to that, there is a split opinion about this. >> Please lift this discussion a little higher: Which would be the default >> desktop for jessie? > > Because we weren't having enough fun with systemd vs. upstart and the MTA > discussion. :) Maybe if we can start all the flamewars at once, we'll > get destructive interference! > > udev sucks! Debian should hire a developer to replace all uses of CDBS > with dh! Perl should be replaced with Python in essential! All packages > need to switch to 3.0 (quilt)! Native packages should be banned! No one > should ever be allowed to NMU anything ever if the maintainer says no! > > Did I miss anything? > Both Perl and Python should be replaced by C. Abolish concept of maintainership, simply all DDs have upload rights to all packages collectively. All packages must run dh_autoreconf, no more usage of upstream generated 'configure/config.*/Makefile.in'. Allow source uploads only. And I want hard candy merchandise with debian swirls. Regards, Dmitrijs. ps. every joke has at least a portion of a joke, the rest might actually be true. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugozlznr6fuehc1m_gf6vxysnbbnoeauag_odj3qzn...@mail.gmail.com
Re: Default desktop for jessie Was: Re: Debian/Wheezy general rant ...
On 5 June 2013 23:42, Jakub Wilk wrote: > * Russ Allbery , 2013-06-05, 15:02: > >> udev sucks! Debian should hire a developer to replace all uses of CDBS >> with dh! Perl should be replaced with Python in essential! All packages >> need to switch to 3.0 (quilt)! Native packages should be banned! No one >> should ever be allowed to NMU anything ever if the maintainer says no! >> >> Did I miss anything? > > > The Freeze Was Too Damn Long! > The Unfreeze is getting long now as well. Are we freezing at Debconf? =) Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhuj9ako2vdaz_oje-3wamw29ajt4hdltayjoqkz_u...@mail.gmail.com
On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
Debian policy was updated some time ago [1] to include provisions for
supporting alternative init systems with a section specific to
supporting upstart init system. [2] In essence update-rc.d / incoke-rc.d
/ service commands must be used, as they properly understand and can act
upon init.d scripts or upstart job files as appropriate, regardless of
which init system is installed or currently in use at runtime.
But since both init.d scripts and upstart job files will be present
simultaneously, one should not invoke init.d script directly, especially
when a given service is instead managed by a native upstart job.
The section §9.11.1, thus requires for packages that ship both init.d
scripts and upstart jobs, to have conditional guards in the init.d
scripts to check if upstart is currently pid 1 and thus insure that
init.d script does nothing (exit with 1, or 0 for stop).
lsb-base 4.1+Debian3 and up provide a convenience function
init_is_upstart as part of the /lib/lsb/init-functions "library", thus
currently recommended way to implement upstart compatible init.d script
is by including a call to init_is_upstart [3]. More or less including a
block like this:
if init_is_upstart; then
case "$1" in
stop)
exit 0
;;
*)
exit 1
;;
esac
fi
Thus in a bug report 712763 [4], included below, I instead propose
instead shipping slightly larger block of code in the upstart package
which is sourced by /lib/lsb/init-functions from init-functions.d
directory. Something along the lines of:
if init_is_upstart; then
upstart_job=/etc/init/$(basename ${0:-}).conf
if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
case "${1:-}" in
start|restart|force-reload)
exit 1
;;
stop)
exit 0
;;
esac
fi
fi
Thus there is no impact on packages that have both sysv init and upstart
jobs, on system that are using sysv init. Since above snippet is not
present / not sourced by init-functions. But once upstart is installed
and running, those packages correctly integrate with upstart and all
init.d scripts that source init-functions execute above snippet.
I here would like to consult with Policy maintainers and the wider
Debian community if this is an appropriate and welcomed way to implement
Debian Policy §9.11.1, as shortly after starting to propose upstart
integration patches I was met with strong resentment with respect to
modifying existing init.d scripts.
I understand that there are packages that at the moment do not use
/lib/lsb/init-functions, and those packages should use the checks as
outlined by Debian Policy §9.11.1 [2] if they simultaneously ship
equivalent upstart job, or start sourcing /lib/lsb/init-functions.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791
[2] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-upstart
[3] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763
Regards,
Dmitrijs.
Original Message
Subject: upstart: implementing Debian Policy §9.11.1
Date: Wed, 19 Jun 2013 10:58:38 +0100
From: Dmitrijs Ledkovs
To: Debian Bug Tracking System
Package: upstart
Version: 1.6.1-1
Severity: normal
Reading Debian Policy §9.11.1 [1] and the recommendations on
implementing it [2] results in a few undesirable properties:
* one needs to modify sysv init.d scripts
* the code in the init.d scripts does nothing when upstart is not
installer or not running
* the init.d scripts becomes less portable
But considering the fact that If upstart is not installed, initctl
will not be present in the $PATH and thus init_is_upstart will always
return 1, as well as the init-functions providing hooks directory
/lib/lsb/init-functions.d the debian policy can be implemented in an
alternative way:
* upstart package ships /lib/lsb/init-functions.d/70-upstart with
contents similar to the attached file
If upstart package is installed, all init.d scripts will continue to
work correctly or will abort with the appropriate status if upstart is
managing that particular job.
If upstart is currently PID 1, yet upstart package was removed, the
system is in flux anyway as upstart's binaries are gone and it will be
hard to do a clean shutdown.
No changes are required to init.d scripts and packages correctly
integrate with upstart, once upstart is installed. Unless init.d
script does not source /lib/lsb/init-functions, in that case one
either migrates to do so, or executes the check as per policy.
[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit
[2] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
Regards,
Dmitrijs.
upstart-lsb.sh
Description: application/shellscript
signature.asc
Description: OpenPGP digital signature
On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
Debian policy was updated some time ago [1] to include provisions for
supporting alternative init systems with a section specific to
supporting upstart init system. [2] In essence update-rc.d / incoke-rc.d
/ service commands must be used, as they properly understand and can act
upon init.d scripts or upstart job files as appropriate, regardless of
which init system is installed or currently in use at runtime.
But since both init.d scripts and upstart job files will be present
simultaneously, one should not invoke init.d script directly, especially
when a given service is instead managed by a native upstart job.
The section §9.11.1, thus requires for packages that ship both init.d
scripts and upstart jobs, to have conditional guards in the init.d
scripts to check if upstart is currently pid 1 and thus insure that
init.d script does nothing (exit with 1, or 0 for stop).
lsb-base 4.1+Debian3 and up provide a convenience function
init_is_upstart as part of the /lib/lsb/init-functions "library", thus
currently recommended way to implement upstart compatible init.d script
is by including a call to init_is_upstart [3]. More or less including a
block like this:
if init_is_upstart; then
case "$1" in
stop)
exit 0
;;
*)
exit 1
;;
esac
fi
Thus in a bug report 712763 [4], included below, I instead propose
instead shipping slightly larger block of code in the upstart package
which is sourced by /lib/lsb/init-functions from init-functions.d
directory. Something along the lines of:
if init_is_upstart; then
upstart_job=/etc/init/$(basename ${0:-}).conf
if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
case "${1:-}" in
start|restart|force-reload)
exit 1
;;
stop)
exit 0
;;
esac
fi
fi
Thus there is no impact on packages that have both sysv init and upstart
jobs, on system that are using sysv init. Since above snippet is not
present / not sourced by init-functions. But once upstart is installed
and running, those packages correctly integrate with upstart and all
init.d scripts that source init-functions execute above snippet.
I here would like to consult with Policy maintainers and the wider
Debian community if this is an appropriate and welcomed way to implement
Debian Policy §9.11.1, as shortly after starting to propose upstart
integration patches I was met with strong resentment with respect to
modifying existing init.d scripts.
I understand that there are packages that at the moment do not use
/lib/lsb/init-functions, and those packages should use the checks as
outlined by Debian Policy §9.11.1 [2] if they simultaneously ship
equivalent upstart job, or start sourcing /lib/lsb/init-functions.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791
[2] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-upstart
[3] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763
Regards,
Dmitrijs.
Original Message
Subject: upstart: implementing Debian Policy §9.11.1
Date: Wed, 19 Jun 2013 10:58:38 +0100
From: Dmitrijs Ledkovs
To: Debian Bug Tracking System
Package: upstart
Version: 1.6.1-1
Severity: normal
Reading Debian Policy §9.11.1 [1] and the recommendations on
implementing it [2] results in a few undesirable properties:
* one needs to modify sysv init.d scripts
* the code in the init.d scripts does nothing when upstart is not
installer or not running
* the init.d scripts becomes less portable
But considering the fact that If upstart is not installed, initctl
will not be present in the $PATH and thus init_is_upstart will always
return 1, as well as the init-functions providing hooks directory
/lib/lsb/init-functions.d the debian policy can be implemented in an
alternative way:
* upstart package ships /lib/lsb/init-functions.d/70-upstart with
contents similar to the attached file
If upstart package is installed, all init.d scripts will continue to
work correctly or will abort with the appropriate status if upstart is
managing that particular job.
If upstart is currently PID 1, yet upstart package was removed, the
system is in flux anyway as upstart's binaries are gone and it will be
hard to do a clean shutdown.
No changes are required to init.d scripts and packages correctly
integrate with upstart, once upstart is installed. Unless init.d
script does not source /lib/lsb/init-functions, in that case one
either migrates to do so, or executes the check as per policy.
[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit
[2] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
Regards,
Dmitrijs.
signature.asc
Description: OpenPGP digital signature
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 20 June 2013 16:32, Tollef Fog Heen wrote:
> ]] Dmitrijs Ledkovs
>
>> if init_is_upstart; then
>> upstart_job=/etc/init/$(basename ${0:-}).conf
>> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>
> Why the -L ?
>
! -L = not a symlink, upstart jobs cannot be symlinks. Above is a
very basic sanity check.
I haven't checked, but if above is implemented, the logic of checking
"equivalent upstart job is available" should match the one already
implemented in the update-rc.d / incoke-rc.d / service commands.
So consider above more of a working proof of concept, rather than
final code proposal.
Regards,
Dmitrijs.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANBHLUgc0mNkGRej0w+ECmwrh-RfDw+eV=x=jrhdddox2bu...@mail.gmail.com
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 20 June 2013 18:26, Russ Allbery wrote:
> Dmitrijs Ledkovs writes:
>
>> Thus in a bug report 712763 [4], included below, I instead propose
>> instead shipping slightly larger block of code in the upstart package
>> which is sourced by /lib/lsb/init-functions from init-functions.d
>> directory. Something along the lines of:
>
>> if init_is_upstart; then
>> upstart_job=/etc/init/$(basename ${0:-}).conf
>> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> case "${1:-}" in
>> start|restart|force-reload)
>> exit 1
>> ;;
>> stop)
>> exit 0
>> ;;
>> esac
>> fi
>> fi
>
> Libraries, even shell libraries, should generally not call exit. It's
> very surprising behavior. The overall program flow should remain under
> the control of the main program.
In general I agree, and I think this was one of points of including
helper-free check in the policy & including a helper in the
init-functions, which one can call as appropriate.
Another fundamental question is: should direct invocation of
/etc/init.d/ be outright deprecated? and thus even stronger
safe-guards put in place (e.g. something at the scale of chmod -x
/etc/init.d/*)
or shall we allow people shooting themselves in the foot and allow
init.d scripts not to have upstart-safeguard if a maintainer does not
wish to include one? E.g. update-rc.d / incoke-rc.d
/ service works correctly with sysv-init & upstart, but if one invokes
init.d scripts directly and they happen to be managed by upstart,
leave those users on their own? At the moment policy is a must: "SysV
init scripts for which an equivalent upstart job is available __must__
query the output of the..."
Regards,
Dmitrijs.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANBHLUgzgF+YvnsZXxv4hYvEx-jm4M_p=kTZv=yaqjuuq18...@mail.gmail.com
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 21 June 2013 11:24, Chow Loong Jin wrote:
> On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
>> On 20 June 2013 18:26, Russ Allbery wrote:
>> > Dmitrijs Ledkovs writes:
>> >
>> >> Thus in a bug report 712763 [4], included below, I instead propose
>> >> instead shipping slightly larger block of code in the upstart package
>> >> which is sourced by /lib/lsb/init-functions from init-functions.d
>> >> directory. Something along the lines of:
>> >
>> >> if init_is_upstart; then
>> >> upstart_job=/etc/init/$(basename ${0:-}).conf
>> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> >> case "${1:-}" in
>> >> start|restart|force-reload)
>> >> exit 1
>> >> ;;
>> >> stop)
>> >> exit 0
>> >> ;;
>> >> esac
>> >> fi
>> >> fi
>> >
>> > Libraries, even shell libraries, should generally not call exit. It's
>> > very surprising behavior. The overall program flow should remain under
>> > the control of the main program.
>>
>> In general I agree, and I think this was one of points of including
>> helper-free check in the policy & including a helper in the
>> init-functions, which one can call as appropriate.
>>
>> Another fundamental question is: should direct invocation of
>> /etc/init.d/ be outright deprecated? and thus even stronger
>> safe-guards put in place (e.g. something at the scale of chmod -x
>> /etc/init.d/*)
>> or shall we allow people shooting themselves in the foot and allow
>> init.d scripts not to have upstart-safeguard if a maintainer does not
>> wish to include one? E.g. update-rc.d / incoke-rc.d
>> / service works correctly with sysv-init & upstart, but if one invokes
>> init.d scripts directly and they happen to be managed by upstart,
>> leave those users on their own? At the moment policy is a must: "SysV
>> init scripts for which an equivalent upstart job is available __must__
>> query the output of the..."
>
> I think printing out a noisy warning and allowing people to shoot themselves
> in
> the foot would be good. I reckon a significant number of legacy
> (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo
> directly.
> Perhaps allowing the sysadmin to choose the desired behaviour via debconf
> would
> do..
>
I'm not sure I understand you.
> One point of concern that just occurred to me is that on an Upstart-booted,
> running system that was just upgraded to include this init-functions snippet,
> Upstart wouldn't know about init.d-started services, and wouldn't be able to
> stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ], you
> wouldn't be able to stop the process using the traditional sysvinit script
> either. You'd end up needing to kill the service manually or trawl through the
> init script to figure out how to kill it properly.
>
Only if both are present:
/etc/init/myservice.conf
/etc/init.d/myservice
The /etc/init.d/myservice, should exit/do nothing if and only if PID1
is upstart, since upstart is managing myservice via a native upstart
job.
If there is no equivalent upstart job (as I think is the case in your
example above), the init.d script must continue to function correctly
as per debian policy (including start/stop/restart).
Thus the init-functions.d snippet above does a check of if upstart is
PID1 and the '/etc/init/myservice.conf' exists, and only then adds the
appropriate exit 1/0. And in the case of upstart-booted system it will
indeed be managing "myservice".
Are you talking about a case where a package is upgraded from
sysv-init.d only to an upstart&sysv-init.d capable version? As per
current recommendations, such services are stopped in preinst (cleanly
via init.d script) & started in postinst (potentially by upstart). [1]
Maybe I didn't understand the scenario you described. Can you please elaborate?
[1] https://wiki.ubuntu.com/UpstartCompatibleInitScripts
Regards,
Dmitrijs.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/canbhlugvkssirjxadahg+bgycgtz1berqstyeyqkpyiub+m...@mail.gmail.com
Re: On upstart implementing Debian Policy §9.11.1 on behalf of sysv init scripts
On 21 June 2013 15:05, Chow Loong Jin wrote:
> On Fri, Jun 21, 2013 at 11:52:40AM +0100, Dmitrijs Ledkovs wrote:
>> On 21 June 2013 11:24, Chow Loong Jin wrote:
>> > On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote:
>> >> On 20 June 2013 18:26, Russ Allbery wrote:
>> >> > Dmitrijs Ledkovs writes:
>> >> >
>> >> >> Thus in a bug report 712763 [4], included below, I instead propose
>> >> >> instead shipping slightly larger block of code in the upstart package
>> >> >> which is sourced by /lib/lsb/init-functions from init-functions.d
>> >> >> directory. Something along the lines of:
>> >> >
>> >> >> if init_is_upstart; then
>> >> >> upstart_job=/etc/init/$(basename ${0:-}).conf
>> >> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then
>> >> >> case "${1:-}" in
>> >> >> start|restart|force-reload)
>> >> >> exit 1
>> >> >> ;;
>> >> >> stop)
>> >> >> exit 0
>> >> >> ;;
>> >> >> esac
>> >> >> fi
>> >> >> fi
>> >> >
>> >> > Libraries, even shell libraries, should generally not call exit. It's
>> >> > very surprising behavior. The overall program flow should remain under
>> >> > the control of the main program.
>> >>
>> >> In general I agree, and I think this was one of points of including
>> >> helper-free check in the policy & including a helper in the
>> >> init-functions, which one can call as appropriate.
>> >>
>> >> Another fundamental question is: should direct invocation of
>> >> /etc/init.d/ be outright deprecated? and thus even stronger
>> >> safe-guards put in place (e.g. something at the scale of chmod -x
>> >> /etc/init.d/*)
>> >> or shall we allow people shooting themselves in the foot and allow
>> >> init.d scripts not to have upstart-safeguard if a maintainer does not
>> >> wish to include one? E.g. update-rc.d / incoke-rc.d
>> >> / service works correctly with sysv-init & upstart, but if one invokes
>> >> init.d scripts directly and they happen to be managed by upstart,
>> >> leave those users on their own? At the moment policy is a must: "SysV
>> >> init scripts for which an equivalent upstart job is available __must__
>> >> query the output of the..."
>> >
>> > I think printing out a noisy warning and allowing people to shoot
>> > themselves in
>> > the foot would be good. I reckon a significant number of legacy
>> > (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo
>> > directly.
>> > Perhaps allowing the sysadmin to choose the desired behaviour via debconf
>> > would
>> > do..
>> >
>>
>> I'm not sure I understand you.
>
> I'm saying that some people may have custom scripts, cronjobs or whatnot
> calling
> /etc/init.d/ directly, and may not be very pleased about /etc/init.d/ scripts
> losing their +x permissions and breaking these scripts.
>
I see, ok.
> Hence, rather than completely disabling the init.d scripts, I'd rather that
> invoking an init.d script directly prints out a big fat warning on stderr that
> lets the admin know, while still doing something sane (starting the service
> anyway). Kinda like how Ubuntu's sysvinit.d scripts currently operate right
> now.
>
Unfortunately doing that is not possible, whilst also simultaneously
supporting sysvinit and upstart in the archive. Because as per policy
at the moment we must preserve fully working sysv init scripts.
>> > One point of concern that just occurred to me is that on an Upstart-booted,
>> > running system that was just upgraded to include this init-functions
>> > snippet,
>> > Upstart wouldn't know about init.d-started services, and wouldn't be able
>> > to
>> > stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ],
>> > you
>> > wouldn't be able to stop the process using the traditional sysvinit script
>> > either. You'd end up needing to kill the service manually or trawl through
>> > the
>> > init script to figure out how to kill it properly.
>> >
>>
>> [...]
Re: Reporting 1.2K crashes
On 25 June 2013 19:21, Alexandre Rebert wrote: > Hi, > > On Tue, Jun 25, 2013 at 2:03 PM, Dmitrijs Ledkovs > wrote: >> From Ubuntu point of view, we'd also be interested in a similar >> analysis. Unlike Debian we provide automatically generated packages >> with debug symbols. >> Similar to debian, we would most interested for development series to >> be tested, currently saucy. At least main (~3000 packages) or universe >> as well (total size than ~ same as Debian) > > It's great to see some interest from other distributions. We would > love to run Mayhem on Ubuntu binaries as well. I'm wondering how > different Debian and Ubuntu packages are though (forgive my > ignorance). > > There are some issues (pointed out by Marc Harber [1]) about identical > bugs being reported bugs by multiple distributions that we need to > consider as well. Feel free to contact me directly so that we can talk > about this in more details. > There is a set of packages that are unique to debian and unique to ubuntu. Toolchain is slightly different, w.r.t. to security and hardening options (but that difference is becoming smaller) There are packagesets that are ahead or behind debian. Overall scanning ubuntu main should be small amount of packages and capture majority of above distro differentiating divergences. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjA_c_xYrahzhHwdJr=nfkejxsleogptcpjdamkj7h...@mail.gmail.com
missing-build-dependency dpkg-dev (>= 1.16.1~) Re: vtk_5.8.0-13.1_amd64.changes REJECTED
Dear all, On 30 June 2013 23:21, Debian FTP Masters wrote: > > > vtk source: lintian output: 'missing-build-dependency dpkg-dev (>= 1.16.1~)', > automatically rejected package. > vtk source: If you have a good reason, you may override this lintian tag. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > dpkg-dev is at 1.16.10 in stable, so above check is only relevant for security uploads for old-stable & squeeze[-backports[-sloppy]]. Can above check please be disabled for uploads to stable-p-u / unstable / experimental? Also I got above reject 5 days later, since I uploaded into delayed queue. This is not nice, since I could have reuploaded 5 days ago Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujjzk_sjr4xe3gz_faj02hkfb78onqkitefdfq5vil...@mail.gmail.com
Re: Berkeley DB 6.0 license change to AGPLv3
On 2 July 2013 17:58, Nick Andrik wrote: > 2013/7/2 Russ Allbery : >> I don't believe the AGPL was ever intended to be used for libraries. >> Quite a bit of the license is very difficult to interpret as applied to a >> library. (For example, does that mean that every application using the >> library has to provide a URL to download the source of the *library*? Is >> the user interacting with the library directly over the network?) >> >> I think this one is all on Oracle. They're using a license that was never >> intended for a basic infrastructure library, quite possibly in an attempt >> to make it obnoxious and excessively onerous to use the open source >> version, or to create a situation where nearly all users of their library >> are violating some technical term of the license (or at least are close >> enough that a lawsuit wouldn't be immediately thrown out) and therefore >> can be shaken down for cash if Oracle feels like it. > > Since AGPLv3 is really similar to GPLv3 but mostly oriented for > webapplications, would it make sense to contact Oracle with the > concerns raised in this thread and ask for clarification and possible > consideration to change to license to GPLv3 instead? > > There could be some possibility that the choice of AGPL over GPL was > not well considered by their part with all the issues that raises. > > On the other hand, with Oracle one can never be sure, but at least > contacting them will make the problem more widely apparent and their > ittentions more clear. > Looking at db5.3 copyright file, I see copyright holders: INRIA, France Telecom The President and Fellows of Harvard University The Regents of the University of California Oracle So is the whole code base re-licensed? or only the changes that Orcale is making here-after? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluiok18hp34xbvp+t9gq+p9n3yrzgee7o1+icruv4pk...@mail.gmail.com
Re: Pepper Flash for Chromium
On 7 Jul 2013 12:05, "Stéphane Glondu" wrote:
>
> Le 07/07/2013 08:39, Scott Leggett a écrit :
> >> you may not (and you may not permit anyone else to) copy, modify,
> >> create a derivative work of, reverse engineer, decompile or
> >> otherwise attempt to extract the source code of the Software or any
> >> part thereof, unless this is expressly permitted or required by
> >> law, or unless you have been specifically told that you may do so
> >> by Google, in writing.
> >
> > Specifically, downloading the chrome .deb from google and doing
> > anything other than simply installing it (like extracting the flash
> > plugin and copying it elsewhere) would be creating a derivative work
> > and is thus forbidden.
> >
> > Additionally, the EULA says this ('Services' here includes the
> > software itself):
> >
> >> Unless you have been specifically permitted to do so in a separate
> >> agreement with Google, you agree that you will not reproduce,
> >> duplicate, copy, sell, trade or resell the Services for any
> >> purpose.
>
> Has anyone considered asking Google to distribute separately the flash
> plugin?
>
I believe similar was requested before for the
adobe-acrobat-code-google-code pdf plugin that comes with chrome. Can't
find reference on my phone, but google engineers responded saying their
legal department didn't provide a response about mixing chromium with
chrome's binary plugins. (Was it on the bug tracker?!). Apart from
~="google doesn't distribute such combination at the moment". Having google
offer/ship binary plugins with/for nightly chromium would be a big win.
Regars,
Dmitrijs.
Re: abi-compliance-checker and abi-dumper to track API/ABI
On 9 July 2013 10:18, Paul Wise wrote: > On Wed, Jul 3, 2013 at 4:24 PM, Andrey Ponomarenko wrote: > >> So it is no need to create any input XML descriptors and compile header >> files of a library anymore. >> >> However, this approach has some drawbacks. Perhaps the main drawback is the >> inability to perform some compatibility checks. For example, there is no >> possibility to check for changes in the values of the constants (defines as >> well as const global data), since their values are inlined at compile time, >> and not presented in the debug information of the binary ELF-object. In >> general, there can be checked about 98% of all compatibility rules. > > Is there any way to automatically generate the XML stuff from dpkg/apt > data so that these extra compatibility issues can be checked > automatically? One of the "library descriptors" that a-c-c supports is a list of includes/directories. Thus for $most packages just installing -dev package and pointing a-c-c at the list of: dpkg -L $pkg-dev | grep include lib should do the right thing (more or less) But I haven't gotten far enough to have this working automagically as dep8 tests. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUgMDuoRWZfPVX+KMHLsK7bf+5wwuvGycNY=x44caia...@mail.gmail.com
Re: abi-compliance-checker and abi-dumper to track API/ABI
On 10 July 2013 09:20, Paul Wise wrote:
> On Wed, Jul 10, 2013 at 4:08 PM, Andrey Ponomarenko wrote:
>
>> There is a simple Perl script to do that:
>
> Thanks, what about including this capability in a-c-c itself?
>
I'd take a patch to dh-acc ;-)
>> my $Version = `dpkg -s $Package|grep Version`;
>> chomp($Version);
>> $Version=~s/\AVersion:\s*//g;
>
> This would be better:
>
> dpkg-query -W -f='${Version}' $Package
>
> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/CAKTje6G1YemXb+tNYEUi_vZu-HSpRXQc98o=e5eX5=xt-p4...@mail.gmail.com
>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/canbhluivgsonazfs-97pfrjkgnz-bqrw5x7kcrcoyogrpbx...@mail.gmail.com
Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports
On 16 July 2013 17:07, Roger Leigh wrote: > On Tue, Jul 16, 2013 at 05:37:09PM +0200, Paul Wise wrote: >> On Sun, Jul 14, 2013 at 10:38 PM, Roger Leigh wrote: >> >> > I don't think that we agreed on merging /usr at all. I have written >> > some patches for initramfs-tools to permit fsck and mount of /usr >> > in the initramfs in addition to the rootfs, but that's as far as this >> > has gone. There's no merging here, just changing where /usr is >> > mounted in the boot process. >> >> Is this implemented by just mounting /usr, by discovering which >> partitions need mounting for each binary that is to be run from the >> initramfs or by copying stuff from /usr into the initramfs too? > > Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr > using that information. When init starts, /usr is therefore > available from the beginning. Note that the objective here isn't > to allow the initramfs to run binaries from /usr, but to ensure > that /usr is available at all times when the system is running-- > this means that all programs, libraries, modules, datafiles etc. > are available before init starts. > > There are some complicating details: > - we need to ensure that the modules needed to mount /usr are > available in the initramfs (copy the needed modules and > mount helpers into the initramfs) > - we can't fsck /usr when mounted, so this needs doing in the > initramfs (/ and /usr are fscked, with the appropriate > helpers copied into the initramfs) > - fsck's -R option updated to skip /usr as well as root. > - /etc/init.d/checkroot.sh updated to handle /usr as well > as root (e.g. remounting r/w). > Up to here, all sounds good. Making the $mountpoints which above are treated / mounted in initramfs, makes sense. To be able to default to "/" only and change to "/ and /usr" if one desires. And even plugin in the feature below. > - using the same infrastructure, it's also possible to > mount /etc in the initramfs so that you can have e.g. a > separately encrypted /etc filesystem. This is a separate > feature though and can be split out. > Imho the overhead between having just "/etc" vs "/" encrypted is small, if "/var", "/usr", "/home", "/opt" are separate mountpoints. Thus to me, treating "/etc" separately is a misfeature, considering a mounted "/" assumes /etc must be present. At least, it would go against my expectation. I haven't yet reviewed the 17 patches log patch series on [1]. But is "/etc" handling clearly separated in it already, or some rebasing/reshuffling needed? Regards, Dmitrijs. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhRPUcnhK11MstzuVTWY_=ttvt4onwrhbzrul90zwk...@mail.gmail.com
Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports
On 16 July 2013 19:39, Roger Leigh wrote: > On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote: >> On 16 July 2013 17:07, Roger Leigh wrote: >> > Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr >> > using that information. When init starts, /usr is therefore >> > available from the beginning. Note that the objective here isn't >> > to allow the initramfs to run binaries from /usr, but to ensure >> > that /usr is available at all times when the system is running-- >> > this means that all programs, libraries, modules, datafiles etc. >> > are available before init starts. >> > >> > There are some complicating details: >> > - we need to ensure that the modules needed to mount /usr are >> > available in the initramfs (copy the needed modules and >> > mount helpers into the initramfs) >> > - we can't fsck /usr when mounted, so this needs doing in the >> > initramfs (/ and /usr are fscked, with the appropriate >> > helpers copied into the initramfs) >> > - fsck's -R option updated to skip /usr as well as root. >> > - /etc/init.d/checkroot.sh updated to handle /usr as well >> > as root (e.g. remounting r/w). >> >> Up to here, all sounds good. >> >> Making the $mountpoints which above are treated / mounted in >> initramfs, makes sense. >> To be able to default to "/" only and change to "/ and /usr" if one desires. >> And even plugin in the feature below. >> >> > - using the same infrastructure, it's also possible to >> > mount /etc in the initramfs so that you can have e.g. a >> > separately encrypted /etc filesystem. This is a separate >> > feature though and can be split out. >> > >> >> Imho the overhead between having just "/etc" vs "/" encrypted is >> small, if "/var", "/usr", "/home", "/opt" are separate mountpoints. >> Thus to me, treating "/etc" separately is a misfeature, considering a >> mounted "/" assumes /etc must be present. >> At least, it would go against my expectation. > > This is certainly the case at present. The rationale for doing this > is that if you have / and /usr on a single filesystem, but you want > to encrypt the content of /etc, you can now encrypt just /etc. It > also means you can have the rootfs read-only with a writable /etc, > have /etc as a writable overlay or separate fs on a common image for > cluster environments, etc. For encrypting stuff, it's moving the > boundary from one of simple convienience (/usr) to where it's actually > needed. But I can accept that this won't have universal appeal. > Thinking about it more, it's possibly not the encryption case which might be most prominent here. I have seen containers / images made readonly, with /etc mounted using overlayfs to provide easily clonable machines (chroots, lxc-containers, "cloud-images"). Not sure, but probably, capser was used to do the mounting there. >> I haven't yet reviewed the 17 patches log patch series on [1]. But is >> "/etc" handling clearly separated in it already, or some >> rebasing/reshuffling needed? > > It's just patch number 11/17 with some minor documentation comments in > patch 12/17, so it can be easily dropped without problems (intentionally). > However, even if applied, it's a strictly optional feature that won't be > used by default unless you provide etc= options to match the root= > options on the kernel command-line. > Ok, thanks for the heads up. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjRojxuo7FmnRrQ76VugG29bjFP31eF=bawbpum_pz...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 17 July 2013 17:04, John Paul Adrian Glaubitz wrote: > On 07/17/2013 05:38 PM, Marc Haber wrote: >> >> >> I would not have posted if that had been the first time I found Joss' >> advocacy offensive. It is, however, a repeated pattern. > > > From which I would infer you shouldn't take it as a personal offense. > He usually has a point, even though he is exaggerating sometimes. At > least he isn't swearing as bad as Linus [1] ;). > > And, really, you shouldn't take that too serious. > > Adrian > >> [1] https://lkml.org/lkml/2013/7/13/132 > Thanks for pointing out, but the way Linus interacts is not OK. And he has been called out on it. http://marc.info/?l=linux-kernel&m=137390362508794&w=2 Multiple people are retweeting/G+/resonating with Sarah's comments. Unlike LKML, Debian has actually accepted a Diversity statement [2] and I'd rather see Debian adhere & excel at what it calls for. [2] http://www.debian.org/vote/2012/vote_002 С уважением, Ледков Дмитрий Юрьевич. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhPvHueff7G0K8MY1ORaX65UTyVrM0xmjPiacCYT_um=w...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 18 July 2013 21:14, Cyril Brulebois wrote: > Thomas Goirand (2013-07-19): >> So that brings me to ask: do you have an idea of how much work it would >> be to have Upstart ported to kFreeBSD or Hurd (even if that would mean >> loosing some of the functionality (obviously cgroups comes to mind))? > > Surely, you could have tried “porting upstart kfreebsd” in your favorite > search engine, and you would have found Scott's mail from 2009 addressing > that particular question. Right? > > http://lists.debian.org/debian-bsd/2009/07/msg00122.html > And this was pondered again not that long ago: http://lists.debian.org/debian-devel/2013/05/msg01227.html I see that 9.1 and 10 kernels are available in experimental so an upstart port to kfreebsd can be approached. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhukrq4ixxpptbvvhhgcqtf8jsk3pxi4ai7kgauffo...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 22 July 2013 10:17, Josselin Mouette wrote: > Le lundi 22 juillet 2013 à 10:45 +0200, Gergely Nagy a écrit : >> systemd being installed does not mean it will be used as init. The >> package happens to contain a few tools the GNOME Shell needs, that is >> all, to the best of my knowledge. It's a harmless dependency if you >> don't use systemd, one that is only "scary" on paper. > > If you don’t use systemd, logind will be non-functional, and you lose > all features that require the system to know who is logged on what. Such > as shutting down the system, mounting USB devices, and so on. > If packaged right, this is not the case. I am running my machine with logind and upstart as system & user session init. Most of upstream packages were modified to correctly check for logind presence, instead of systemd presence. (Many thanks goes to pitti). Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluialjedcgquy-7p5ii5bnrmp-x0erlosgm1qkrdc91...@mail.gmail.com
Re: Status of deb(5) format support in Debian
On 1 August 2013 15:40, Adam Borowski wrote: > On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote: >> [...] in preparation to add non-gzip compression support for control.tar > > May I ask why would you want that? > > There's a lot of extra complexity, incompatibility with existing tools, > added moving parts... and I'm not aware of any gain. > > xz, while vastly superior to gzip and bzip2 for bulk data, suffers from > slow start: for files a few tens of kilobytes or smaller, xz compresses > worse than gzip. Thus, control.tar.xz is hardly ever a good idea. > > On the other hand, control files compress pretty well, so you want _some_ > form of compression. For files this small, CPU costs are totally > negligible. > > Thus, with .tar.gz being either the best or very close to the best, > what would be the point of this change? > For debian-installer (et. al. components) at the moment control.tar.gz is often larger than data.tar.xz since "templates" are very long and include a lot of translations. So for that package group it's valuable to have control.tar.xz. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUgTASqMtq9w=iBsSo42Fqeo+DK7o0rfqpEB4-h1Ff=1...@mail.gmail.com
Re: Status of deb(5) format support in Debian
On 1 August 2013 16:21, Adam Borowski wrote: > On Thu, Aug 01, 2013 at 03:52:38PM +0100, Dmitrijs Ledkovs wrote: >> On 1 August 2013 15:40, Adam Borowski wrote: >> > On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote: >> >> [...] in preparation to add non-gzip compression support for control.tar >> > >> > May I ask why would you want that? >> > >> > There's a lot of extra complexity, incompatibility with existing tools, >> > added moving parts... and I'm not aware of any gain. >> > >> > xz, while vastly superior to gzip and bzip2 for bulk data, suffers from >> > slow start: for files a few tens of kilobytes or smaller, xz compresses >> > worse than gzip. Thus, control.tar.xz is hardly ever a good idea. >> > >> > On the other hand, control files compress pretty well, so you want _some_ >> > form of compression. For files this small, CPU costs are totally >> > negligible. >> > >> > Thus, with .tar.gz being either the best or very close to the best, >> > what would be the point of this change? >> > >> >> For debian-installer (et. al. components) at the moment control.tar.gz >> is often larger than data.tar.xz since "templates" are very long and >> include a lot of translations. > > Hmm... indeed, some udebs have monstrous control tarballs, the biggest one > being 1167360 bytes long (uncompressed). > >> So for that package group it's valuable to have control.tar.xz. > > Still, total gains for all udebs (jessie netinst amd64) are only 1.22MB. > Should I try this for regular debs? > libc6 compressed control.tar.gz is 66kB It has uncompressed 111kB symbols, 68.5kB templates. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluifsouuw0s7vgghk4bvtw_rddu6yxxn9jysivoglm_...@mail.gmail.com
Re: C++11
On 6 August 2013 14:41, Pau Garcia i Quiles wrote: > Hello, > > I am the maintainer of Wt [1], a C++ web development library (think of Qt or > Gtk+ for the web) and web server. > > My upstream [2] sent me a mail asking about mixing C++03 and C++11. My > understanding is it is not possible for a variety of reasons, unless all > players take great care (see [3], for instance). > > The specific case upstream asked about is Boost.Signals2, which provides a > different and ABI-incompatible implementation [4] depending on whether Boost > was compiled as C++03 or C++11. I expect users and Wt to use more and more > C++11, to the point where Wt may not even be compilable as C++03. Given that > Wt depends on Boost, I can foresee a problem: > > - Application may be C++11 or C++03, depending on what the user is doing > - Wt would be C++11-only > - Boost would be compiled as C++03 in Debian > - Wt (C++11) would depend on Boost (C++03), which but this mix is broken > > I'm talking about Wt + Boost in this e-mail but this will arise as other > combinations for other packagers: log4cpp, Xerces, SOCI, ACE (which I > co-maintain), Gtkmm, ZeroC ICE, POCO, etc > > I have googled but so far I have found no clear conclusion about this for > Debian. What are we going to do with C++11? Are we goint to provide C++03 > and C++11 using multiarch (is that even possible?) ? Everything C++11? > Fingers crossed? > At the moment gcc-4.8 C++11 abi is still experimental and has not been declared stable. 4.8.1 did bring a few advances, but the stdlibc++ is still not C++11 complete. There are further ABI breakages planned to happen in 4.9, and hopefully with 4.9 it will become default. Currently the default boost version in Debian is 1.49, the transition to boost1.54 is planned soon. At the moment, compiling with C++11 enabled, will result in binaries which are not abi stable, since toolchain abi will change and all of those packages that use C++11 will have to be recompiled (a big pain). I guess one could use gcc-4.8.1 with libc++ from llvm project, but libc++ doesn't seem to have complete test-suite pass on linux (if their website results are the current ones) and libc++ doesn't support the complete range of support Debian architectures. In short, I am not expecting compiling with C++11 by default in Debian until after gcc-4.9 is default and libstc++ is api/abi stable for C++11. In practice, you can enabled c++11 but you get to keep the fallout from abi mismatches between said package, its dependencies and reverse depends / build-depends. (some packages started doing this in ubuntu, and it has been a pain > E. g Microsoft took a very pragmatic decision: C++11 is enabled by default > and it is not possible to disable it. > I'm not sure how that applies to linux distributions though. There is no package management per-se and one either depends on platform libraries from micrsoft or bundles their own copies. On Debian we need to ship something that works across 12 odd architectures and 30 000 packages. Some additional points: http://gcc.gnu.org/wiki/Cxx11AbiCompatibility Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugygbouqwkvdhxewmdm_bexzazmdu+fwk172dsy9_s...@mail.gmail.com
Re: UTF-8 in jessie
On 12 August 2013 01:51, Adam Borowski wrote:
> On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
> I propose the following sub-goals:
>
> 1. all programs should, in their default configuration, accept UTF-8 input
>and pass it through uncorrupted. Having to manually specify encoding
>is acceptable only in a programmatic interface, GUI/std{in,out,err}/
>command line/plain files should work with nothing but LC_CTYPE.
>
> 2. all GUI/curses/etc programs should be able to display UTF-8 output where
>appropriate
>
> 3. all file names must be valid UTF-8
>
> 4. all text files should be encoded in UTF-8
>
What about locales though?
* C.utf8 locale should be always available
* C.utf8 locale should be the default/fallback locale
* utf8 locale variants should be default / available / preferred
(where appropriate)
(this is rough idea, adjust above as appropriate & feasible at this
point in time)
Regards,
Dmitrijs.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/canbhluhz9rezyipz1ze5zrptb5zccrspmdf9aoaygqyjvk1...@mail.gmail.com
Re: jessie release goal: verbose build logs
On 17 June 2013 23:58, Dmitrijs Ledkovs wrote: > tags 680686 patch > thanks > > On 14 June 2013 12:35, Matthias Klose wrote: >> >> - Fix debhelper not passing --disable-silent-rules by default. >>#680686 >>I think cdbs already does this. > > Patch attached for autoconf dh build system. cmake dh build system > seems to be already enabling verbose makefiles. > Is there any reason this hasn't been applied yet? Can I NMU this, as debhelper is marked as LowNMU package. The patch itself is a trivial one-liner and fixes a Jessie release goal. The bug report itself was filed a little over one year ago. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluij3-_x_fe0dq6v2nu7duma9gfsh_ze7yeogit9abf...@mail.gmail.com
Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
On 13 August 2013 14:36, Joey Hess wrote: > Dmitrijs Ledkovs wrote: >> Is there any reason this hasn't been applied yet? >> Can I NMU this, as debhelper is marked as LowNMU package. > > Not for reasons such as allowing patches like this. > Ok. > Making all builds verbose by default has both advantages and > disadvantages. > I agree, there should be a way to toggle this. > The disadvantages include making builds possibly so noisy that when one > runs them during daily work, once ignores all output. Including > important compiler warnings. > We have build log analyzers running for the build logs. And the important compiler warnings (errors) fail the build. If we make this opt-in, we will fail to achieve this goal. As when one is debugging a failed build (e.g. the failure in the last hour of webkit/qt/libreoffice compile on armhf porter box, or by hand ./debian/rules build) that's when one would start caring & wishing to have the verbose output would have been set, but it would be too late. The way I interpret this goal is to have the build logs verbose by default and/or opt-out. Making this opt-in, will need many machines modified - potentially all the builders / CI integration. It's not just about Debian buildd network, but anyone who rebuilds debian packages or derives from Debian. Including all the ways people integrate and build debian packages. > (This is the same reason why it's a bad idea to let a codebase > accumulate a lot of compiler warnings!) > > I'd be ok with DH_VERBOSE enabling the verbose behavior, and the buildds > could then enable it. > I'm against re-using DH_VERBOSE variable: * DH_VERBOSE has explicit meaning to control output of dh_* commands. DH_VEBOSE=1 should print how/what dh_auto_* commands invokes. It should not change the commands it invokes. * this debian goal is not debhelper/cdbs/etc specific, but helper/build-system agnostic. How about a new DEB_BUILD_OPTION="silent" which opts into silent build log? Does that sound reasonable. For a policy change, I am hoping to mandatory require verbose build by default, and optionally supporting DEB_BUILD_OPTION="silent". Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujxxzznj6tbmwvosrgra4jbdaa2oxtqi6futyf7t7z...@mail.gmail.com
Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs
On 13 August 2013 19:59, Julien Cristau wrote: > [why oh why are you breaking threading?] > > On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote: > >> We have build log analyzers running for the build logs. And the >> important compiler warnings (errors) fail the build. >> If we make this opt-in, we will fail to achieve this goal. As when one >> is debugging a failed build (e.g. the failure in the last hour of >> webkit/qt/libreoffice compile on armhf porter box, or by hand >> ./debian/rules build) that's when one would start caring & wishing to >> have the verbose output would have been set, but it would be too late. >> > I don't see how. Either dpkg-buildpackage -nc or re-running > debian/rules build with the option set would give you what you want. For well behaved build-systems that would only show flags for the yet to compile object, where the bug might be in the flags/libs used for the already compiled objects. (i don't have an example here, something like mixing with/without -fPIC but we get warnings which objects are at fault anyway) For less behaved build-systems this may cause a reconfigure and restart the whole build. Which is suboptimal. In the past there have been random bugs / build failures which are not reproducible on re-runs (but I've yet to see one which depended on build-flags, unless one gets different flags =/ on reruns which wouldn't know about) In controlled environments, one doesn't get to re-run a build, as the instances are stripped-down and destroyed on build failure E.g. all the jenkins instances running debian package builds, PPAs, auto-package-tests, automated cross-builders. One would have to modify each and every deployment of those... Somehow we lived fine with verbose build-logs, until automake silent rules and a few other build-systems started to become more silent. I can understand the appeal of silent builds for upstream developers, but it makes zero sense for a distribution or package maintainers or our downstream. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUi1+Q8PVTJF2TvhGKBLQh-y=elhrzpuv-7ntjlypch...@mail.gmail.com
Bug#720209: ITP: libinotify-kqueue -- inotify compatible implementation using kqueue
Package: wnpp Owner: Dmitrijs Ledkovs Severity: wishlist * Package name: libinotify-kqueue Version : upstream snapshot from 20120419 Upstream Author : Dmitry Matveev * URL or Web page : https://github.com/dmatveev/libinotify-kqueue * License : MIT/BSD Description : inotify compatible implementation using kqueue This package provides an implementation of sys/inotify.h using kqueue. This is kind of reverse of libkqueue package, as it allows to compile software on kFreeBSD which otherwise is using Linux specific inotify API. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eh9py3tu@debian.org
Re: Introducing dgit - git integration with the Debian archive
On 23 August 2013 00:38, Charles Plessy wrote: > Le Thu, Aug 22, 2013 at 08:52:10PM +0100, Ian Jackson a écrit : >> I'm pleased to announce that dgit 0.7, which is a version of dgit >> suitable for alpha and beta testers, is available in unstable. >> >> >From the manpage: >> >>dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir] >>dgit [dgit-opts] fetch|pull [dgit-opts] [suite] >>dgit [dgit-opts] build|sbuild [build-opts] >>dgit [dgit-opts] push [dgit-opts] [suite] >> >>dgit treats the Debian archive as a version control system, and >>bidirectionally gateways between the archive and git. The git >>view of the package can contain the usual upstream git history, >>and will be augmented by commits representing uploads done by >>other developers not using dgit. This git history is stored in >>a canonical location known as dgit-repos which lives outside >>the Debian archive (currently, on Alioth). > > Thanks a lot for this development ! > > For the packages that I maintain with Git, I commit build logs (the local one > for the uploaded binary packages, plus the buildd ones) in separate branches. > In some cases I found it quite useful. Have you considered integrating logs > in > dgit ? In a somehow similar goal (finding difference between builds), have > you > also considered committing the contents of the unpacked binary packages in > other branches ? > Apart from designated release dgit branches, it's a normal git repository into which one can push whatever one wants: pristine-tar, various git/quilt patch management branches, build-logs, upstream branches et. al. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhxyz9qkbbbwsvejcbsre9azss5e5ymgpcnpqkxpie...@mail.gmail.com
Bug#720547: ITP: ocaml-estring -- Estring: OCaml development platform
Package: wnpp Owner: Dmitrijs Ledkovs Severity: wishlist * Package name: ocaml-estring Version : git snapshot Upstream Author : Jeremie Dimino * URL or Web page : https://github.com/diml/estring * License : BSD-3-Clause Description : Estring: OCaml development platform estring, which stands for `extended strings' is a syntax extension allowing to prefix string literals with a specifier to change their meaning. . This package used to be part of the batteries project. Regards, Dmitrijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9k8lm4d@debian.org
Re: Custom Reload command/signal in upstart
On 31 May 2013 22:44, Ondřej Surý wrote: > > It's pretty much equivalent with one exception – I need to send USR2 on > reload. Does upstart already have the support for custom reload signals? > Upstart 1.10 released today has the following new stanza thus you will be able to specify: "reload signal SIGUSR2" Once 1.10 is uploaded in Debian. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluis2jp-bvv6g5p2o-br2-ci6+2v4yhz0ybuvbho5nm...@mail.gmail.com
Re: Introducing dgit - git integration with the Debian archive
On 25 August 2013 12:04, Raphael Hertzog wrote: > Hello, > > On Thu, 22 Aug 2013, Ian Jackson wrote: >> I'm pleased to announce that dgit 0.7, which is a version of dgit >> suitable for alpha and beta testers, is available in unstable. >> >> >From the manpage: >> >>dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir] >>dgit [dgit-opts] fetch|pull [dgit-opts] [suite] >>dgit [dgit-opts] build|sbuild [build-opts] >>dgit [dgit-opts] push [dgit-opts] [suite] >> >>dgit treats the Debian archive as a version control system, and >>bidirectionally gateways between the archive and git. The git > > Basically, this is "Ubuntu Distributed Development" (UDD) but for Debian & > Git (instead of Ubuntu & bzr). > > Have you looked at UDD? They have been doing this for multiple years and > have much more experience than us here. I'm sure there a quite a few > things to learn from what they did to not redo the same mistakes. > Things to learn from UDD: 1) the fact that debian didn't have a _standartised_ VCS repository format, for UDD workflow all debian packages had to be imported, such that lp:debian/package can be merged into lp:ubuntu/package. 2) 3.0 (quilt) causes problems: - we had to go with committing .pc directory in the unpacked tree. As otherwise, new patch end up at the start of the quilt series and can cause the rest of series to fail to apply - debian/patches/series.$vendor is evil, often series.ubuntu were not updated/refreshed/rebased causing dpkg-source -x to fail with DEB_VENDOR=Ubuntu - Merging two quilt series is a pain, as there is no $ quilt merge. We end up unapplying both quilt series, merging the branches and throw conflicts in debian/patches/series at the developer and asking them to figure out what patches to apply and refresh quilt series themselves. - versioning .pc directory is a pain, especially when quilt is updated. E.g. newer versions of quilt added pointless .timestamp files in the .pc directory which where not present in the automatic lp:ubuntu/* and lp:debian/* branches which used older quilt - a valid git/bzr patch may not be a valid quilt patch, and it turn may not be a valid "patch" as considered by dpkg. It's getting better with patch(1) starting to support git format-patch style patches. Thus cherry-picking from upstream becomes a pain, I have multiple times applied upstream cherry-picked patch, only later find out that e.g. +x flag was not preserved, or fuzz is generated, or files are not renamed. - tarball inside tarball packaging is evil & must die 3) Automatic importer is part of the UDD workflow, only because there was no standartised developer created rich-VCS history on Debian side which fully matched the archive state. And basing ubuntu branches, on something that doesn't match debian uploads into the archive was a no-go. 4) automatic importer was necessory to import Debian history and well it was not perfect: http://package-import.ubuntu.com/status/, pristine-tar used to fail (importer was running on stable, now upgraded and much better), dpkg-source -x sometimes fails, operational issues (timeouts, OOM, etc), unreconcilable history (developer rebases old tags, and importer can no longer reconcile it's state), - history can be odd: UDD discovered where referenced uploads didn't happen, or experimetal got ahead & then behind sid and has a really hard time figuring out when, if ever, experimental got merged into sid. (sometimes it's just abandoned) I think james can give more examples. The best UDD workflow seems to work with native packages: As a highlight I can give example debian-installer. All debian-installer git repositories are homogeneous and follow the same layout. All of d-i projects are imported into bzr branches https://code.launchpad.net/d-i And then Ubuntu Installer team maintains branches where Ubuntu diverges, e.g.: lp:~ubuntu-core-dev/apt-setup/ubuntu which frequently merges in debian changes from lp:apt-setup In a similar manner packages which use 1.0 format without a patch system work really well with lp:ubuntu/* and lp:debian/* branches. I have maintenance access to UDD & have filed a few bugs about it, and all I can say is that dgit so far is getting a lot of things right: 1) round-trip tree guarantee same is required for UDD, and automatic importer can fail to get the state right when developers push different tree in the VCS vs what dpkg-source -x produces. Don't forget, e.g. git doesn't commit empty directories. I have seen a case where bzr-git was used to push commits without empty directories into lp:ubuntu/$pkg branches & then dpkg-source -x not matching the state of the vcs, resulting in the automatic importer failing. 2) removing automatic importer forcing all the checks on the developer side & forcing VCS commit to match the src upload is a massive win. It means that one can actually trust the archive & VCS commits. And they will always match. (Well one can even verify that by unpac
Re: Introducing dgit - git integration with the Debian archive
On 22 August 2013 20:52, Ian Jackson wrote: > I'm pleased to announce that dgit 0.7, which is a version of dgit > suitable for alpha and beta testers, is available in unstable. > I have now started daily PPA builds for dgit, for all supported Ubuntu releases. add-apt-repository ppa:xnox/dgit Since dgit dependencies are so simple, it should also be safe to use that PPA on any debian release as well, e.g.: deb http://ppa.launchpad.net/xnox/dgit/ubuntu precise main deb-src http://ppa.launchpad.net/xnox/dgit/ubuntu precise main With the following archive key 1024R/4031D287 2D9DF1E22F3416238D46F49F157951FE4031D287 http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x157951FE4031D287 Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjGfENtc3ne+Cupwvgc4DtN3+_8kcJ=21oxxwzksd8...@mail.gmail.com
Re: Introducing dgit - git integration with the Debian archive
On 25 August 2013 17:31, Steve Langasek wrote: > On Sun, Aug 25, 2013 at 12:51:31PM +0100, Dmitrijs Ledkovs wrote: >> I have maintenance access to UDD & have filed a few bugs about it, and >> all I can say is that dgit so far is getting a lot of things right: > > > >> 2) removing automatic importer >> forcing all the checks on the developer side & forcing VCS commit to >> match the src upload is a massive win. It means that one can actually >> trust the archive & VCS commits. And they will always match. (Well one >> can even verify that by unpacking the .dsc and comparing it to the >> Dgit: commit id) After all the archive will always be authoritative, >> as that's that gets GPG signature, is mirrored and gets deployed to >> the users. > > I don't think "removing the automatic importer" is an improvement at all. > If we want VCS branches for the whole of Debian that we can rely on, > something / someone needs to update them automatically when a package is > uploaded. > Under dgit: push = (git push + dput *.changes). Thus the failure mode is much sooner and in general it's more strict. For uploads done without using dgit, it can synthesise "upload granulaty" commits with reproducible / stable commit ids. Thus the branches are maintained up to date, without the need to rely on automatic importer. One can trivially add automatic importer for uploads done without dgit. > The problems with the UDD automatic importer have all been around its > failing to cope with any kind of manual changes to the bzr branch. I.e., > if even once the importer sees an upload before it sees the corresponding > commit on the bzr branch - because a maintainer did a bzr push --overwrite, > or because of a race between the upload and the branch propagation, or > because of a bug on the server - then that package is forever after in > "manual" import mode until someone with admin privileges can kick the > machine. This is a pretty bad failure mode; but it's a failure because the > importer can't cope with changes to the branch, not because automatic > importing was being done. > >> And one is free to push pristine-tar (if makes sense/easy to >> generate), and/or any other branches into the repository (git-dpm, >> git-quilt, etc) > > I would have expected dgit to support pristine-tar > directly/automatically/unconditionally. Any system that requires me to > download the same information (== the upstream source) both from a VCS > repository and the archive in order to get a fully-formed source package for > upload is a non-starter. > if pristine-tar can recreate the tarball, without size penalties. Since it's just a git repository, one can do $ pristine-tar commit and push that into the dgit repository. At the moment it's not a requirement. >> I am exited about dgit, as for the first time it will be possible for >> derivatives to centrally share history with Debian. > > I am as well! > >> In practice one doesn't actually care how far back the history goes, >> as the history that is interesting is where developers get to do >> intermediate commits between the two uploads to granulise the >> changes > > I don't agree with this at all. I have regularly made use of the UDD > branches to examine the history of packages (and not just the Ubuntu > history, but also the Debian history). Being upload-level granularity makes > it less useful than if it were at the granularity of a VCS branch being > committed to natively by the developer, but it's still *very* useful for > understanding the uploader's thought process at the time a change was made. > > The fact that git will allow us to graft the developer's own VCS on to these > dgit repositories in a way that UDD never did is an important improvement, > but as this is *optional*, not importing the package history from the > archive would make dgit much less useful for the common case than UDD is > today. > Ok. Given that we have snapshots.debian.org & graft points we can create "import level" history in retrospect. But I find merging existing history more interesting: either upstream, or existing git/svn packaging repositories. For new packages with dgit, I start my repository on top of upstream git reposity, which gives full history of the project in the dgit repository. Imho shared history with upstream projects is more interesting than debian packaging upload history. Ideally one would have both =) Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhypp-aaq-k1oihougwok+itswxkq2fsjl0qdk9gmf...@mail.gmail.com
Re: UTF-8 in jessie
On 12 August 2013 01:51, Adam Borowski wrote: > > 3. all file names must be valid UTF-8 > Case in point errors from ubuntu UDD package importer: """ Packages containing non-UTF-8, non-ASCII filenames. This is a problem. It is unclear how to sensibly map these into Bazaar. anon-proxy aspell-is aspell-pt aspell-ro cvsnt dacco egroupware ewiki firebird2 fortunes-pl fslint glest-data gmoo ii-esu ispell-fo jpilot kdeedu liblingua-de-ascii-perl magyarispell mtink ooohg openverse phpgedview phpgroupware projectl qcad qdvdauthor tatan tuxpaint uae xblast-tnt xblast-tnt-levels """ Not sure how up to date this list is (it could be a historic package version that has non-UTF8/non-ASCII filenames.) Test & file bugs? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlui_ch-z7y+ga4f2ui81if2gjog-cxccmfzuzumpzjf...@mail.gmail.com
Re: Less dinstall FTW?
On 28 August 2013 21:58, Joerg Jaspert wrote: > Hello Debian world, > > there is currently a discussion within the FTP Team and we appear to > have two opinions on it. As we are open on the outcome and it basically > affects the whole project, we came up with the following summary to > solicit feedback, opinions and other ideas. > > The proposal at hand is: > * Lower dinstall frequency to two times a day. Can dinstall be run every hour please? For me, if anything dinstall is not frequent enough. If it takes longer than hour to execute, can it be optimised and sped up? > * Have incoming.debian.org be an apt-able location (actually the buildd >locations, so it is suite/archive specific, not one global queue)[1] No opinion, as I don't actually understand what that means. As in, will that enabled buildds to fetch/use packages from incoming.d.o? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhdkqak19sb4k-odegthlxveun3gjppzo7fvnk2snp...@mail.gmail.com
Re: Less dinstall FTW?
On 29 August 2013 10:55, Luca Falavigna wrote: > 2013/8/29 Dmitrijs Ledkovs : >> Can dinstall be run every hour please? For me, if anything dinstall is >> not frequent enough. > > No, dinstall takes more than an hour to finish... > Ok. >> If it takes longer than hour to execute, can it be optimised and sped up? > > ... and even if it can be reduced, there are more problems this would > introduce (mirror pushes, snapshot pushes, ...) > Is incoming.debian.org mirrored? From my end (UK) it looks like it's hosted in the USA, well 17 hops away with a ~10% packet loss along the way (could be blocked mtr/pings) So I will not be pulling from incoming.debian.org. Since I usually aim to work << 12h a day coding, as a developer it means that at most I'll be able to see updates once a day. And my own upload only the next day. I don't want to build packages using local apt repository of uploads, since e.g. I don't want to upload something that was build against earlier uploaded $foo, which got rejected by ftp-masters for example. Currently, it's sometimes possible for me to see updates twice a day (e.g. my morning upload in the evening). Can incoming be mirrored on e.g. eu & jp UploadQueue boxes? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluivckvjrzptj114bc2wse4cv_pn2pzw2xomldz+3ba...@mail.gmail.com
Re: How git performs when you throw all of Debian at it
On 30 August 2013 20:55, Steven Chamberlain wrote: > Hi, > >> [...] using git instead of the file system for storing the contents >> of Debian Code Search. The hope was that it would lead to fewer disk >> seeks and less data due to gits delta-encoding > > Wouldn't ZFS be a more natural way to do something like this? > > A choice of gzip, lzjb and more recently lz4 compression; snapshots > and/or deduplication both reduce the amount of disk blocks and cache > memory needed. > > I've pondered before at this overlap in functionality between packing by > Git, and those features of the ZFS filesystem. They are doing much the > same thing but with different granularity. It would be neat if they > could work together better. I haven't finished packaging bedup - btrfs deduplication tool. Anybody have benchmarked that, if that's any good and/or comparable to zfs deduplication? lzo compression is also available. And well available in linux kernel. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluibdvtshc5dbtwobf67xdexnjpumafcpvx1auj37te...@mail.gmail.com
Re: Bug#723307: flash-kernel link with -L/usr/lib
Dear YunQiang Su, It looks like this class of problems is reported against a lot of packages now. Did you consult on debian-devel before doing this mass bug filing? Regards, Dmitrijs. On 17 September 2013 11:34, YunQiang Su wrote: > Package: flash-kernel > Version: 3.11 > X-Debbugs-CC: wzss...@gmail.com > > This package has one or more -L/usr/lib in its build system, > which will make it ftbfs if there is libraries under /usr/lib, > while is not the default architecture, mips* for example. > > On mips* systems, /usr/lib is defined as place to hold O32 > libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. > > Beside the way, on the multiarch system like Debian, user may install > libraries under /usr/lib by hand. > > Please use the default search path if you can, and please consider fix > this. > > I will try to fix this bug, while if you can help to fix it, > It will be very appreciative. > > The attachement is the buildlog of this package on mips64el platform. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluibcrrhbelcyedxpdybzwse5gbzc1-ll5fqv2erwvj...@mail.gmail.com
Re: Bug#723307: flash-kernel link with -L/usr/lib
please ignore this thread. I've now noticed these bug reports were raised to debian-devel in the " link with -L/usr/lib" thread. Regards, Dmitrijs. On 18 September 2013 02:54, Dmitrijs Ledkovs wrote: > Dear YunQiang Su, > > It looks like this class of problems is reported against a lot of > packages now. Did you consult on debian-devel before doing this mass > bug filing? > > Regards, > > Dmitrijs. > > > On 17 September 2013 11:34, YunQiang Su wrote: >> Package: flash-kernel >> Version: 3.11 >> X-Debbugs-CC: wzss...@gmail.com >> >> This package has one or more -L/usr/lib in its build system, >> which will make it ftbfs if there is libraries under /usr/lib, >> while is not the default architecture, mips* for example. >> >> On mips* systems, /usr/lib is defined as place to hold O32 >> libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. >> >> Beside the way, on the multiarch system like Debian, user may install >> libraries under /usr/lib by hand. >> >> Please use the default search path if you can, and please consider fix >> this. >> >> I will try to fix this bug, while if you can help to fix it, >> It will be very appreciative. >> >> The attachement is the buildlog of this package on mips64el platform. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhf=BO=u=6mknot2fcz8qwrdwkqahvfuuyiennctix...@mail.gmail.com
Re: Call for Jessie Release Goals
On 18 September 2013 03:42, Mathieu Malaterre wrote: > On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire wrote: >> Release goals are areas of functionality which developers would like to see >> as an aim for the next release. They will not hold up the release, but >> allow the bugs opened for that goal to be of severity 'important'. > > I am not sure if this qualify as "Release goals". So I'd like to ask > first what people think of using C++11 in the next release. > > I know of a couple of C++ libraries which could be compiled with the > new gcc compilation option. And I have at least one application (no > shared lib) which requires C++11 to compile properly. Since C++11 > introduce an ABI incompatibility [*], this may not be a Release Goal > but simply a tech-ctte decision. > > Comments ? > I think I have replied about similar requests before (not sure if it was on these mailing lists). In essence, at the moment we do not have any compiler & stdlib with complete and stable ABI for C++11. It is expected that gcc4.8 will break C++11 ABI to further implement the standard. Other non-default compilers also are fully featured at the moment (w.r.t. C++11 compiler features). Thus at the moment we cannot consider switching. One can compile with C++11 enable where one must, but also one then gets to keep the ABI incompatibilities down the road (boost / template libraries especially). While one would want to start using C++11, it's not default at the moment and not feasible to make the default standard level C++11. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUgYHMH6OymwjNc-b2O_ryuv6i_wKqDd=cnvmgzdb07...@mail.gmail.com
Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))
On 11 October 2013 20:32, Steve Langasek wrote: > severity 726009 serious > thanks > > This remains a serious bug. Your package, which previously built on > multiple architectures, is now failing to build due to memory exhaustion. > While in some circumstances it is permissible to remove the old binaries and > drop support for an architecture, this remains a serious bug until this has > been done. (And anyway, your package won't reach testing in the current > state, so is de facto unreleasable.) > > On Fri, Oct 11, 2013 at 09:00:36PM +0200, Anton Gladky wrote: >> severity 726009 wishlist >> retitle 726009 Yade requires too much RAM for building >> thanks > >> thanks for bug-report. The problem is, that all build-failures are due >> to insufficient RAM on build-machines [1]. I do not really know how to >> "fix" that except of backlisting of some machines, as was suggested by >> Julien [2]. The same package builds fine on Launchpad's PPA. It seems, >> the package builds only on machines, where >4Gb RAM is available. > > This diagnosis is incorrect. The error you are hitting here is not that you > are exhausting the available memory on the machine, it's that you're > exhausting the *address space* on the machine. Adding more memory to the > buildd would have zero effect, because you're on a 32-bit system which has a > limit of 4GB of address space anyway. (In practice, I believe this is 3GB > for userspace and 1GB for kernel on i386.) > > The buildd almost certainly has swap already, giving it total available > memory in excess of 4GB, but that doesn't help if you have a single process > - in this case g++ - that needs more than 3GB all to itself. > > If this same package version built on Launchpad but is failing to build in > Debian unstable, then you should look at differences in toolchain versions > between the two. It's possible that Ubuntu has a compiler fix that isn't > yet available in unstable; it's equally possible that the successful builds > in Launchpad were done with an earlier toolchain, and that there's a more > recent regression in g++ memory usage. Either way, it's not the buildd's > fault. I'm not sure, but launchpad is running 64-bit machines even when compiling for the i386 architecture, and then launchpad supports PAE only and thus can get >4GB of address space. I think debian buildds are also all 64-bit apart from one (or something like that) thus it shouldn't be a problem there. Last time I spoke with Colin about yade FTBFS due to memory exhaustion, the recommendation he gave was to reduce translation units and thus to reduce the compiler memory usage. GCC memory usage can go very large and has regressed since 3.3 when templates are used http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850 It has been done before for some other packages, but i haven't yet had time to look more into yade. I think that's the best way to go for yade, to address it in the source-code / restructure it to use less memory at compile time. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUj6+mjT2itJTdaMZtHFSuJdCVHHGC8Lpgp_5nFkicHK=q...@mail.gmail.com
Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))
On 11 October 2013 22:34, Ben Hutchings wrote: > On Fri, Oct 11, 2013 at 09:55:34PM +0100, Dmitrijs Ledkovs wrote: > [...] >> I'm not sure, but launchpad is running 64-bit machines even when >> compiling for the i386 architecture, and then launchpad supports PAE >> only and thus can get >4GB of address space. > [...] > > Which bit of 'Physical Address Extension' do you not understand? > ignore me, friday evening. the parts where virtual address space is limitted to 4gb per process none the less. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujadw1epezxg0f8oheb8ly_vy496l4ncwffgg-tmz+...@mail.gmail.com
Re: systemd effectively mandatory now due to GNOME
On 24 October 2013 10:59, Adam Borowski wrote: > On Thu, Oct 24, 2013 at 09:11:30AM +0100, Jonathan Dowland wrote: >> On Thu, Oct 24, 2013 at 02:09:46AM +0200, Adam Borowski wrote: >> > And I for one heavily use vservers >> >> It's a professional shame of mine that we are still trying to get rid of >> some old vserver instances at $WORK. > > lxc is still nowhere close to vserver (or openvz) functionality. It lacks > even basics like "vserver enter" (you can't access a container more than > once other than via ssh or similar), not to speak about holding hostile > root. vserver probably is too heavily in maintenance mode to pretend to > satisfy this anymore, but not catching all intentional attackers doesn't > mean not stopping unintentional breakage -- or even intentional but > not sophisticated enough intruders. > http://linux.die.net/man/1/lxc-attach $ sudo lxc-attach --name mycontainer -- login if you wish to gain full login prompt. It has been around at least since 2012. And you can have multiple ones What do you mean by "holding hostile root." ? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUiYf+GJ=e-OmXiRNA+nfvuw1vgGj=cghlb7qukfwav...@mail.gmail.com
Re: [ANNOUNCE] git-deb: a Git importer for Debian packages
On 24 October 2013 14:18, Gabriel de Perthuis wrote: > Hello, > I've written a tool to import Debian packages into Git: > > git clone deb::mypackage > > It does a faithful import of the package history from > snapshot.debian.org. There is some agressive caching built-in, and a > bit of logic to rebuild the history graph from changelogs. It is also > able to deal with most quirks in the upload history, like missing source > packages, missing .dsc files, and obsolete keys. > > On the git side, the --depth option is supported. Incremental imports > (both new releases and deepening the history) aren't yet, but the shared > cache helps rebuild branches faster. > > It's available here https://github.com/g2p/git-deb and on PyPI. Is it compatible with Ian's dgit ? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluiaskvjt_x7qxw4qhwg2lrdxjd7fkvxqzz12ji2ctn...@mail.gmail.com
Re: [ANNOUNCE] git-deb: a Git importer for Debian packages
On 24 October 2013 15:15, Gabriel de Perthuis wrote: > Le 24/10/2013 15:57, Dmitrijs Ledkovs a écrit : >> On 24 October 2013 14:18, Gabriel de Perthuis wrote: >>> Hello, >>> I've written a tool to import Debian packages into Git: >>> >>> git clone deb::mypackage >> >> Is it compatible with Ian's dgit ? > > I only know what dgit does from reading the source code. dgit works > server-side and is only available to DDs; as I understand it it creates > a new, canonical repo, imports the current version and uses that as a > base for new uploads. It's useful as part of a maintainer's workflow. > My tool is useful to get a git view of any package, without waiting for > anyone to convert their repo. Yes, sure. But it starts off a repository by taking the latest .dsc file and generating a commit out of it. The cool thing about how it generates the commit, is that it's reproducible and generates stable SHA-1 id by setting GIT time variables & author variables from the .dsc. Such that it doesn't matter who/where/when runs the import as the commit tree / commit id will be the same (well sans parenting information, but that could be easily fixed with graft points) Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUgL7seZVFZV867JCLf05s5EkfPZRFS4KpWsKWfp1-h=g...@mail.gmail.com
Re: Proposal: switch default desktop to xfce
On 24 October 2013 17:38, Svante Signell wrote: > On Thu, 2013-10-24 at 18:31 +0200, Lucas Nussbaum wrote: > >> What's the the status of XFCE regarding accessibility? >> >> That was a big strengh of GNOME for a long time, though I've heard >> rumors (sorry not to be more specific) that gnome-shell has some >> unsolved issues in that regard, which is a problem since GNOME >> classic/fallback mode is gone in 3.8. > > An even stronger reason to move away from Gnome if the classic mode > disappears. > > I thought it was _back in_ 3.8.. E.g. see Classic at https://help.gnome.org/misc/release-notes/3.8/ Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUgTSrUDN3v8zBsp8=wh0t283R=bjabbsh0_senamqx...@mail.gmail.com
Re: away_0.9.5+ds-0+nmu2_multi.changes ACCEPTED into unstable
Hello, On 25 October 2013 07:23, Rene Engelhard wrote: > Hi, > > On Fri, Oct 25, 2013 at 01:18:18AM +, Debian FTP Masters wrote: >> Changed-By: Andreas Moog [...] >> away (0.9.5+ds-0+nmu2) unstable; urgency=low >> . >>* Non-maintainer upload >> - d/p/01_fix_makefile: $LIBS need to come after $SRC while linking to >>fix building with ld --as-needed (Closes: #634323) > > A NMU for a MINOR bug is NOT something which should be done. > I quietly accepted the dbs one, but this is over the line. > I sponsored Andreas' patch as NMU, on my own initiative. > It builds fine. When some distro bogusly introduces changes which make > all kind of packages breask they can fix them up; but this is not a reason > for NMUing it in Debian. > You mean Debian right? Cause --as-needed is a linker flag available in Debian's default toolchain and there is a lot of ongoing work done to enable it by default. https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ld-as-needed;users=debian-...@lists.debian.org Bogus or not, it's an upstream linker option which reduces amount of linked libraries, and overwhelming majority of well behaved packages do build with --as-needed in ever increasing amount of distributions, e.g. OpenSuse, Fedora, etc. It's not default in Debian toolchain, but there are no good reasons why it shouldn't be. I understand that "away" package did not even handle CFLAGS, CPPFLAGS, LDFLAGS, and DESTDIR until last nmu, but why not improve a package or at least reply to the bug report? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlui-x4x0z_rgm-qerglogqsfyluvzapxkgxeybig+td...@mail.gmail.com
Re: let's split the systemd binary package
On 25 October 2013 10:00, Olav Vitters wrote: > On Fri, Oct 25, 2013 at 03:33:56PM +0800, Thomas Goirand wrote: >> Seems I misunderstood what logind was about. I thought it would force to >> use specific Xdm implementations that would support it. So you do >> confirm that it's not the case, and that we aren't forced into using >> GDM? Or is it that other Xdm implementations all have logind support >> these days? What exactly Gnome requires? > > logind is basically the replacement of ConsoleKit. However, it also will > do more. It will handle VT switching, something which we want/need for > _optional_ Wayland support[1]. ConsoleKit was mainly maintained and > started by GNOME developers. > > E.g. XFCE either wants ConsoleKit, or logind. If you look at ConsoleKit, > you'll notice it is NOT maintained. For the last 1.5 years, no > development. See http://cgit.freedesktop.org/ConsoleKit/log/ for > details. > > I wrote about logind and systemd in more detail at: > https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ > > I find it quite sad that on debian-devel the majority seems focussed on > emotional arguments such as conspiracy theories, hidden agendas, etc. > Sure, but it doesn't help "logind" case though when: - it's maintained in "the systemd daemon collection" - it's pam module called "pam_systemd" instead of logind - plently of packages that had to be fixed to check for "logind" presence instead of "init is systemd" presence, when deciding to enable logind support vs consolekit/none - using XDG_* environment variables, instead of LOGIND_* or SYSTEMD_* variables I think from above points you can see, that it's not unreasonable to easily mistake that systemd brings logind, instead of "logind is part of the systemd software collection" & that all of "the systemd daemon collection" somehow is required / endorsed by FreeDesktop project. I don't know if it works on older kernels and/or without cgroups and/or how portable /just/ logind is, or other individual daemons in "the systemd daemon collection". Debian doesn't ship single binary package "GNOME" with all modules and apps build and included in the single binary package, in the same way it is not reasonable to maintain "systemd daemon collection" as a single binary package. It already splits udev into separate library/daemon packages, but at the moment logind is not. Debian is a Universal OS, that supports multiple kernels, and a pleaora of configurations, as one of Debian's core values. It is perfectly acceptable for Debian installations to exclude/include udev, cgroups, consolekit/logind, etc. Preserving that core value is important to Debian. And Debian does take pride it the amount of architectures and kernels it supports. > Simple question: logind is maintained, ConsoleKit is not. I have not > seen anyone raise this. Why? That one is easy. Both are written by the same predominantly mayor author and in some ways one project is superset of the other, and/or compete to provide same feature. It's not unreasonable for one author to pick to work on the superset and stop work on the other one. Then later switching one major desktop environemnt to support new one and not the old one and boom: old one goes from "stable/feature complete" to "dormant/obsolete/unmaintained/legacy" project. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhdkLSnz1phNHTtWHogT1=9kvitcj42_pwb9qv_p_6...@mail.gmail.com
Re: let's split the systemd binary package
On 25 October 2013 13:13, Simon McVittie wrote:
> On 25/10/13 11:52, Dmitrijs Ledkovs wrote:
>> - using XDG_* environment variables, instead of LOGIND_* or SYSTEMD_*
>> variables
>
> I assume you mainly mean XDG_RUNTIME_DIR here, since the rest are
> basically user-level rather than system-level.
>
No, I mean:
XDG_VTNR=7
XDG_SESSION_ID=c1
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SEAT=seat0
Above variables are specific to logind and pollute XDG_* namespace.
And well all logged in graphical user sessions evnironment is polute
which leaks everywhere (e.g. sbuild build-logs). Non-graphical
sessions have less variables, but still there shouldn't be any.
XDG_RUNTIME_DIR is absolutely fine as well as all the other variables
defined in the XDG Base Directory Spec
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> The point of the XDG_* family of variables is that they're intended to
> be a cross-desktop, multi-implementation standard. I think pam_systemd
> and its communication with systemd-logind might be the only
> implementation of XDG_RUNTIME_DIR we have right now, but there'd be
> nothing to stop someone writing a pam_xdgruntime that did it in-process,
> analogous to pam_mkhomedir.
>
XDG_RUNTIME_DIR has also been implemented by
https://launchpad.net/pam-xdg-support project.
The VTNR, SESSION_ID, SESSION_PATH, SEAT_PATH, SEAT are logind
specific at the moment, no standard published by FreeDesktop, nor has
multiple implementations, which kind of comes from not having a
cross-distro spec in the first place.
> The advantage of XDG_RUNTIME_DIR is that it makes any specification that
> refers to it simpler. For instance, if it had existed all along and been
> a prerequisite for D-Bus, we could say "use the Unix socket
> $XDG_RUNTIME_DIR/dbus/session" rather than "There's a socket somewhere,
> probably in /tmp or something, or it might be abstract, who knows? Use
> $DBUS_SESSION_BUS_ADDRESS to find it, and make sure that variable gets
> set correctly, otherwise you lose".
>
> The disadvantage of XDG_RUNTIME_DIR, which sets it apart from the other
> XDG_* variables, is that there's no good default if it isn't set: it
> requires that something on the system creates a suitable directory,
> potentially requiring privileges to do so. In contrast,
> XDG_{CACHE,DATA,CONFIG}_* can all have sensible defaults (a
> dot-directory in $HOME, which applications can create when needed).
>
> The reason that XDG_RUNTIME_DIR potentially requires privileges is that
> unprivileged users can't guarantee to be able to create a directory on a
> fully-featured local Unix filesystem with Unix sockets, fifos, atomic
> rename, etc. (as opposed to NFS or VFAT or something similarly limited).
> systemd-logind guarantees that by using a tmpfs, which has those features.
>
I think above is unnecessory. I am well aware of RUNTIME_DIR benefits
and that's not the issue I am raising.
>> I think from above points you can see, that it's not unreasonable to
>> easily mistake that systemd brings logind, instead of "logind is part
>> of the systemd software collection" & that all of "the systemd daemon
>> collection" somehow is required / endorsed by FreeDesktop project.
>
> To clarify, freedesktop.org is (at least) two things:
>
> * specifications: a set of desktop-agnostic would-be-standards for
> "APIs" that desktop environments benefit from sharing (window manager X
> property conventions, .desktop files to describe applications, XDG_*
> search paths for data/configuration, etc.). I suppose the ideal for
> these could be expressed as "not having a competing standard because
> nobody needs one".
>
Sure, where is the spec for logind specific variables? Or
implementations that is desktop-agnostic, or more specifically for
Debian - OS/kernel agnostic.
> * software: a hosting site for projects that aspire to be used in a
> cross-desktop way, analogous to a more focused
> Sourceforge/Github/Alioth. Some of these remain current (systemd,
> Telepathy, D-Bus, LibreOffice, Xorg, lightdm), some get deprecated as
> their authors realize they had design issues (ConsoleKit, HAL), some
> never really got wide adoption in the first place (Ytstenut, APOC,
> arguably Geoclue). Many of these projects have long-term competitors
> (systemd/Upstart/OpenRC/etc., NM/wicd/ConnMan/etc.,
> lightdm/gdm/kdm/etc., Xorg/Wayland) and that's fine.
>
> With hindsight, it would have probably been better off with two separate
> names for those things, but it's rather too late.
>
yeah, it's a hosting service for a clique of developers, not quite
public open
Re: automatically cross-grading lib32nss-mdns to libnss-mdns:i386?
On 1 November 2013 13:28, Simon McVittie wrote:
> If cross-architecture dependencies are allowed in the archive (and don't
> break dak or britney) these days, then it's easy:
>
> Package: libnss-mdns
> Architecture: any
> Multi-Arch: same
>
> Package: lib32nss-mdns
> Architecture: amd64
> Depends: libnss-mdns:i386 (= ${binary:Version})
> Description: ... transitional package ...
>
> I thought I remembered an announcement that cross-arch dependencies were
> OK for jessie, but I couldn't find it, so that might just be wishful
> thinking?
>
This one is allowed:
Depends: python:any
Actually spelling out the arch, is not.
> The only other option I can think of is to imitate Wine:
>
> Package: libnss-mdns
> Architecture: any
> Multi-Arch: same
>
> Package: lib32nss-mdns
> Architecture: amd64
> Depends: libnss-mdns-i386 (= ${binary:Version})
> Description: ... transitional package ...
>
> Package: libnss-mdns-i386
> Architecture: i386
> Depends: libnss-mdns (= ${binary:Version})
> Description: ... transitional package ...
>
> but that requires yet another content-free package, and a trip through
> the NEW queue. So, before I upload that: is there a better way?
>
That's the currently supported way of doing such migration.
Regards,
Dmitrijs.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANBHLUiOMaGdfTEa0gNJrLmy1aAcw8w3Zc06P83acmbDmN2=n...@mail.gmail.com
Bug#650436: ITP: openerp6 -- Enterprise Resource Management
Package: wnpp Severity: wishlist Owner: Dmitrijs Ledkovs * Package name: openerp6 Version : 6.0.3 Upstream Author : OpenERP S.A * URL : http://www.openerp.com/ * License : AGPL Programming Lang: Python Description : Enterprise Resource Management OpenERP is a collection of open source software which facilitates business operations, such as: * CRM (Customer Relations Management) * Accounting * Point of Sale * Project Management * Warehouse Management * Human Resources * Purchasing * Manufacturing * Marketing * Invoicing I would like to introduce Ver.6.0 stack: server, web-client, gtk-client and certified addons from this source package. At a later stage I may reintroduce Ver.5.0 stack, because it is still maintained by upstream and there are many people using. [citation needed] I would like to maintain it part of Python Apps Team. (currently v6.0 cannot be used as a python module/library at all and it doesn't make sense at all to have openerp in system path / byte-compile for multiple versions). Current packaging is injected into the Python Apps Team svn repository. But it's not ready yet. Working on it. This packaging is based on: - debian openerp5 packaging - OpenERP S.A. packaging changes - credativ Gmbh & Ltd v5 & v6 internal packaging - Stable updates from upstream It also adds dbconfig-common & wwwconfig-common integration, secure default configuration and better integration with debian based systems, when comparing deploying from branches. I'm active user of OpenERP, develop customisations for eat both for personal use-cases and at work. There are a couple of my friends who are interested in helping me out with this. There are still unresolved issues. Currently migration path is still to pay for support contract from OpenERP S.A and let them do it. But given enough time & interest using Pentaho ETL or writing migration scripts for modules or extending/completing migration addon. I do understand that this is a massive package to maintain. And I do need/want help. So request for help bugs will be filed straight away with first upload. Cause there are plenty of things to do on it. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2029191003.10090.82306.report...@kursk.surgut.co.uk
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 12 October 2012 13:03, Adam D. Barratt wrote: > I'm struggling to see what point you believe you're making here. > The point he was trying to make that he either caught a mirror during update, or his connection was flaky, as he didn't fetch the complete file, nor verify it's gpg signature. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugp6ep6e+d0obqfdx0n8h8oezopbjr05jnpm07jqbr...@mail.gmail.com
Re: Poll (was: Popularity of bzr-builddeb and dh-make)
On 12 October 2012 13:52, Hideki Yamane wrote: > On Fri, 12 Oct 2012 14:46:41 +0200 > Jelmer Vernooij wrote: >> The workflow doesn't have to involve Launchpad either - I'm not using >> Launchpad at all for my Debian packages. Just because the majority of >> Bazaar users host their branches on Launchpad, doesn't mean that a >> Bazaar workflow has to involve Launchpad. > > Okay. I'm wrong. > > BTW, most people uses svn or git, what is prefer you to use bazaar? > I'm curious. > well the fact that it works nice out of the box and has nice command line syntax. pristine tarball is on by default. auto detects: native/non-native and full source vs debian/ dir only packaging by default auto fetches tarballs: from the pristine tar, from apt, from servers with get-orig-tarball, with uscan builds packages in a sane way, even if you have uncommited changes: bzr bd (for debuild), bzr bd -S (for src package only) Simple to make it split-mode: e.g. if you are both upstream and packager, you can do $ bzr bd --split, which will create original tarball sans debian dir and build proper non-native package (this is very hard to do with other tools) bzr-bd supports merging packages really well when you fork sid & experimental and what to keep both forks in sync, or finally fold experimental into sid, without loosing changelogs. (BTW I hate how some maintainers do not keep NMU changelog entries) bzr-bd can deal with quilt patches sensibly by auto applying & removing them depending on your preference, the default is sane as well. also great support on ubuntu-udd mailing list and ubuntu-motu irc channels using it for most core packages in ubuntu helps as well. The list goes on =) With svn/git/hg/mnt-buildpackage I have yet to see all of these little features work so well out of the box with no or little configuration. I wish hg-queues would be better integrated into hg-buildpackage, or bzr-bd had pipes/looms support for top class quilt patch management. But none other tools get it right either. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUicU2BJYe7x4HNQQPwT4Q1=24txl8pn_byqnuiov6n...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 15 October 2012 18:46, Michael Gilbert wrote: > On Sun, Oct 14, 2012 at 9:08 PM, Christoph Anton Mitterer wrote: >>> If so, please submit >>> bugs, and we will look at fixing them. Otherwise, speculation gets us >>> nowhere and actually wastes time. >> Well I had once a discussion (around March this year) here about >> blockin/downgrade attacks... which, AFAICS, both are possible in secure >> APT right now but there was no real outcome. >> Unforunately it seems that people do not take these higher-level attacks >> really serious even though the danger they impose is quite high. > > Are there bug reports with a clear description of the problem, > preferably with a proposed fix? Discussion doesn't really get us > anywhere. Useful info and actual efforts at fixing problems do. > So far no bugs or problems were uncovered. So nothing to file or fix ;-) I can think of adding SHA-3 hashes... but none of the tools support it yet, so it's future wishlist bug, which I am sure will be acted upon at an appropriate time and doesn't need a bug filed at present time. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugzqkk5li8k4xr67g25dlntedivrxlwxatguzosfap...@mail.gmail.com
Re: Poll (was: Popularity of bzr-builddeb and dh-make)
On 17 October 2012 03:05, John Paul Adrian Glaubitz wrote: > On Oct 17, 2012, at 1:03 AM, Barry Warsaw wrote: > >> On Oct 12, 2012, at 02:22 PM, Benjamin Drung wrote: >> >>> How does bzr-builddeb depend on Launchpad? bzr is integrated into >>> Launchpad, but you can use bzr without Launchpad as every other DVCS. >> >> $ bzr branch debianlp:mypackage >> >> is one way to use Launchpad with bzr for Debian effectively. It's certainly >> not *required*, but often works out pretty nicely. > > And how do I use bzr *without* Launchpad when I don't want to? > > I'm not against LP per se, but I don't like tools limiting my choices in > development that way. > > Adrian Here is documentation on using bzr *without* Launchpad specifically for packaging: http://jameswestby.net/bzr/builddeb/user_manual/ Note that none of the tutorial has launchpad in it. There is one place where it offers you to merge upstream bzr branch + with pristine-tar delta on top, but that is optional. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugrwejfdei+xcach+2p3thnbk7eis3pmkigju6bovq...@mail.gmail.com
Re: Discarding uploaded binary packages
On 17 October 2012 19:30, Christoph Egger wrote: > Hi! > > Joerg Jaspert writes: >> Its for after wheezy, definitely. >> Also, there are some open issues to be solved for this to happen. >> The most important is being able to deal with arch all packages. And >> worse - arch all packages able to build only on certain architectures. >> But thats outside dak and my area. Goto the buildd/wanna-build people to >> help for that. > > Also remeber, there are packages like cmucl that can only be built by > the same upstream release of itself and can currently survive in Debian > because the maintainer can upload a bootstrapped binary package along > the source See Debian Policy 7.8 Additional source packages used to build the binary - Built-Using [1] Is exactly what should be used here. And the bootstrap package should be uploaded into Debian, to facilitate downstream users and distributions to bootstrap that package by themselves as well & provide a clear lock-step build-deps. [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujckg-xsogfjevdn_bax0jvzy8jkouavvhphrkmyr7...@mail.gmail.com
Re: Popularity of bzr-builddeb and dh-make
On 17 October 2012 22:55, Philipp Kern wrote: > Paul, > > am Wed, Oct 17, 2012 at 05:48:39PM -0400 hast du folgendes geschrieben: >> > With the danger of being sued if you put up the result onto the public >> > interwebs. >> Could you please expand on that? Logo / trademark reasons or license >> issues? > > it's not very hard to find https://dev.launchpad.net/LaunchpadLicense > > It's designed not to be run outside Canonical except for development. > And it's not just the logo/trademark, no. I'd completely understand that. > Huh?! Please read it again. Code is licensed under under the GNU Affero General Public License, version 3 Image and icon files are copyrighted, but can be used in dev environments Similar to how e.g. Firefox is Iceweasel in Debian. So yes you can run in outside of Canonical as long as you provide your own images & icons (there are not that many and readily replaceable with tango icons) @Jeremy I don't think you are missing anything =) Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluifyhoaxydbnk9rdkd7ketbj9y+jpjbq0a4ui5jeok...@mail.gmail.com
Re: Popularity of bzr-builddeb and dh-make
On 17 October 2012 09:57, Игорь Пашев wrote: > For git we have gitweb, gitolite, git-daemon, pristine-tar. > I'd like to have similar for bzr, hg and svn. > bzr-builddeb gives pristine-tar support bzr serve is the equivalent of git-daemon and it is builtin loggerhead is replacement for gitweb Above three are packaged in debian. Loggerhead is used @ http://anonscm.debian.org/loggerhead/ as well as savannah and launchpad. gitolite - 3 replacements are listed here http://serverfault.com/questions/325721/something-like-gitolite-for-bazaar (I wouldn't be expecting them to be 100% feature complete, but actually it's easier in bzr since branches are direcories and code repository can be separate form the branch, you can simply use POSIX ACL on the folders, yet share the main repo with stacked branches) > It's not about technology, but about collaboration. > > That's why I prefer git. > Huh, these two contradict each other unless you somehow imply that all of the people you ever would want to collaborate with use git. Regards, Dmitrijs. > 2012/10/17 Marc Haber : >> On Thu, 11 Oct 2012 16:31:00 -0700, Steve Langasek >> wrote: >>>The popularity of subversion >>>for packaging is a measure of inertia and/or ignorance, not of the >>>appropriateness of the tool. >> >> I find this attitute improperly offensive. The choice of tool is the >> decision of the maintainer, and subversion does version control rather >> well for most uses. >> >> Greetings >> Marc >> -- >> -- !! No courtesy copies, please !! - >> Marc Haber | " Questions are the | Mailadresse im Header >> Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ >> Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 >> >> >> -- >> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org >> Archive: http://lists.debian.org/e1tonac-0001xl...@swivel.zugschlus.de >> > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/call-q8xzg7_se9yuprgh_a5asu8v+ktzxy6j5_q0gzk+0cq...@mail.gmail.com > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUgfpgDkJq0c-1UjXM1Q=5k+owkcon1ma-zisjf0n5w...@mail.gmail.com
Re: Popularity of bzr-builddeb and dh-make
On 18 October 2012 07:27, Tollef Fog Heen wrote: > ]] Dmitrijs Ledkovs > >> loggerhead is replacement for gitweb > > As one of the alioth admins, I'd like to contest this statement. > > loggerhead is a replacement for gitweb in the same way that crawling is > a replacement for sprinting. > > Yes, we «run» it, but it's memory-hungry, slow and crash-prone. It also > wedges randomly and sometimes forgets about half the repositories that > exists on alioth. > True. Sorry if the statement did not come out as neutral as intended. Yeah, I did end up using nginx & uwsgi workers to actually host it together with hosting bzr smart server as well. I'd merely wanted to say there "actually there is approx. functionality for web browsing the bzr branches". Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluiugwzsfytfvoj2zkthlitzy7+ltfazxbp+1_q82no...@mail.gmail.com
