Re: Proposal: enable stateless persistant network interface names
On Thu, 14 May 2015 09:07:16 +1000, Russell Stuart wrote: >On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote: >> Well, having some of the network traffic (more precisely, connections >> to machines that have an IPv6 address) re-routed to some unknown >> machine on the local network is not a nice feature. >> >> IMHO, such a feature should be enabled only by the network management >> system, not by default at the kernel level. > >Now I've looked up what Marc is referring to in an earlier reply, SLAAC >and DHCP look pretty similar to me. Both have the "re-route your NIC to >some unknown machine" feature. I'm sure everybody here will be the >victim of a rouge router sending NDP responses, just as everybody has >already been the victim of a rouge DHCP server. Good networks know which machines are allowed to send DHCP offers and Router Advertisements and do not allow such packets to enter from unauthorized network ports. ARP and NDP spoofing is way more dangerous since all end systems need to be able to legitimately send such packets, and maintaining a static list between MAC and IP addresses is a significant burden and a significant loss in flexibility. Genereally, you need to trust your LAN. If you don't, you need to restrict access to your LAN (for example by locking your network ports away, not patching unneeded ports, or using technical level network access control such as 802.1x) so that you can trust it. With this in mind, IPv6 is no less secure than IPv4 is. I have to violently oppose any voice that suggests that enabling IPv6 is a security risk. It isn't. >The one difference between the two right now is dhclient make it easy >for the client to watch for changes using scripts. AFAICT, there is no >off the shelf way of doing it for SLAAC. It's easy enough to do - just >have a daemon listen to kernel netlink messages and fire off a script. >The right place to put that now would be in systemd, but if they are >opposed to scripts as Marc says that ain't going to happen. Sigh. They are walking in this direction via systemd-networkd. In systemd terminology, there will probably be a target or a regular unit that will be subjected to some state change whenever the network configuration changes. One will then be able to depend on that target/unit with one's own units, and they will of course be able to call scripts. 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: https://lists.debian.org/e1ysnfy-00076j...@swivel.zugschlus.de
Re: Proposal: enable stateless persistant network interface names
On May 13, "D. Jared Dominguez" wrote: > >- it does not seem to me to provide any benefit over the firmware-based > > names since in practice both would use by default an interface index > > in the common case > Firmware based in what sense? From the biosdevname readme, biosdevname uses: > PCI Configuration Space > PCI IRQ Routing Table ($PIR) > PCMCIA Card Information Structure > SMBIOS 2.6 Type 9, Type 41, and HP OEM-specific types Yes, but how often in practice it is able to provide an emN name while at the same time udev is unable to provide an enoN name? -- ciao, Marco pgpWxaxgx1CBE.pgp Description: PGP signature
Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)
On 2015-05-03 18:58, Guillem Jover wrote: > Hi! > > On Tue, 2015-04-07 at 22:11:18 +0200, Niels Thykier wrote: >> A) Use ".deb" (i.e. the regular extension) with a new "section". > > Is there any problem with using the existing "debug" section? Or is > the different section used to distinguish that these are autogenerated > perhaps? > I picked "debugsym" to ensure it distinguished the automatically generated debug debs from hand-crafted ones while testing it. I am personally slightly in favour of keeping this as an (extra) discriminator. That said, I will not object to using the normal "debug" section. >> B) Use ".ddeb" (i.e. with an extra "d"). > > What where the motivations for using a different extension? I have heard of/can think of two reasons: * it was to have a trivial discriminator prior to unpacking / extracting information from the deb. * backwards compatibility with Ubuntu's setup. > I can > see the motivation for .udeb:s as they need to live in a different > namespace, but that does not seem to be the case for debug debs. > Please keep in mind that there /is/ a desire to keep ddebs trivially distinguishable from regular debs. Among other things, to facilitate putting ddebs in a separate part of the mirror to avoid inflating the size of the metadata on the mirror (for users not using ddebs). > Assuming that any issue with debug .deb:s is fixed in the tools, is > there any remaining reason to use .ddeb:s? > To my knowledge: No - dpkg-genchanges and dak are the only known tools blocking the use of ".deb". To be honest, I am not sure about dak, as I have not tried uploading with an "out-of-band" deb. That said, dak will want to know about them to avoid an explosion in the NEW queue. >> On 2015-04-07 21:10, Niels Thykier wrote: >>> Both have their own advantages and disadvantages. In particular: >>> >>> A) means that almost every existing tool will handle the debug debs >>> like a regular deb (which it is) and will generally work perfectly >>> out of the box. >>> - There are a couple of exceptions, but we are limited to something >>> like lintian and dpkg-genchanges. > > I'd happily look into making dpkg-genchanges allow this. > Thanks. I tried dpkg from git, which now allows them with only a warning. I would certainly be interested in having a (long-term) solution that did not warn about these. >>> - There will be tools that might want to handle them differently. >>> Programs like dak and reprepro might want to (support) put(ting) >>> them in a different part of their repositories. > > They could already do that by keying on the Section, no? Otherwise the > filename is also unique enough to be keyed on («*-dbgsym_*»)? > That is my understanding as well. Note that Ubuntu have a few "manually" generated "*-dbgsym_*" packages (e.g. for the linux kernel). It is my understanding that these are "in spirit" intended to be considered regular ddebs. Accordingly, there ought to be no issue in filtering based on that file name pattern. > [...] >>> >From my point of view, I am not strongly attached to one solution over >>> the other: >>> * I am slightly preferring A), but I am ready to implement either >>>solution in the tools, I maintain. >>> * The difference for debhelper is a single "d" and a section name. >>> * The change for lintian is larger, but B) is the "heavy" solution >>>and I already got a "mostly working" patch for that. > > Barring any strong reasoning behind B) above, I pretty much prefer A). > > Thanks, > Guillem > Great. :) To my knowledge, A) is also the solution that the FTP masters seemed to prefer. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55545904.2070...@thykier.net
Re: Experimental ddeb support in debhelper and lintian
On 2015-04-12 05:31, Paul Wise wrote: > On Sat, Apr 11, 2015 at 3:20 PM, Niels Thykier wrote: > >> As noted on IRC, mentors.debian.net / debexpo will probably need to be >> updated too (at least if we go the "ddebs" route). > > debexpo needs a rewrite to a non-deprecated framework so support for > ddebs is probably a long way off. Support for ddebs is also not > necessary since mentors is mainly a source package based thing and an > easy workaround is available (uploading only the source). > AFAICT, it seems we will be picking the ".deb" version of "ddebs". Odds are that this will not be a blocker for "ddebs". ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5554595f.9030...@thykier.net
Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)
On 2015-04-19 19:10, David Kalnischkies wrote: > On Sat, Apr 04, 2015 at 10:54:09AM +0200, Niels Thykier wrote: >> The resulting debs are installable with dpkg -i ( \o/ ). I have not >> tried anything fancy like setting up a local APT mirror and tried to >> convince APT do install it. > > I did and apt works with ddeb just fine, meaning it can happily > print infos about them, download them and install them with dpkg. > > There are two exceptions as far as I can see: > [... snip minor issues with .ddeb support in various APT tools ...] For reference, it seems like we will be picking the ".deb" route. So even these (minor) issues are unlikely to be a problem. > > > So, super-cow approves (d)debs. \o/ > (In fact, apt-dbg never became a thing as automatic ddebs were always > "very soon now" in existence every time it came up. This time please…) I certainly intend to follow this all the way. > And it especially approves the debhelper branch name. ;) > I could imagine. :> > > [...] > > btw: Is it planed to drop them into their own repository/component or > are we gone blow up our regular Packages files with them? (you might > guess from the wording which way I would prefer). > > > Best regards > > David Kalnischkies > It is my general understanding that most people would (strongly?) prefer that ddebs were placed in a separate component. I would be surprised if we did ended up including them in the current components. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55545af4.6030...@thykier.net
Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)
On 2015-05-02 13:46, David Kalnischkies wrote: > On Fri, May 01, 2015 at 11:46:42PM +0200, Niels Thykier wrote: >> […] ddeb support […] > > +1. \o/ > > >>- apt now properly handles the "pkg:arch" dependency. > > [...] > > I would revert the revert as this is potentially causing more trouble > than the "problems" it is trying to solve (aka: I don't see why a debug > package has to depend on the package it provides symbols for at all. If > any the relation should be 'Enhances'…). > > > Best regards > > David Kalnischkies > I add the depends for the following reasons: * It is what we do with manual -dbg packages today and it is what people seem to expect. * It allows me to trivially deploy a doc-symlink to avoid an extra copy of the copyright file to create policy compliant debs. Now, IRT the "pkg:arch" dependency - it was to ensure that the you get the correct variant of your debug package. I can certainly appreciate that the (original?) Multi-arch spec does not support this for "Multi-arch: foreign"[1]. We have now ended up in a situation where people has made their own interpretation of how to handle this situation rending "pkg:arch" dependencies useless when "pkg" is multi-arch:foreign. It is what happens when people have to guess what something means. :) Thankfully, we got a solution that works perfectly for any other multi-arch value and "foreign" is just a minor inconvenience when APT guesses wrong on the (architecture for the) debug package. Thanks, ~Niels [1] As I recall, it does not really mention the "pkg:arch" dependencies. But it is a couple of years since I last read it, so I am quite possibly wrong here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55545ea6.5040...@thykier.net
Re: Modern Debian packaging system for DevOps: does it exist?
On Wed, May 13, 2015 at 07:14:36PM +0300, Исаев Виталий wrote: > Hello! I'm looking for a convenient wrapper of standard Debian packaging > toolchain in order to automatize the deployment process. We use Ubuntu and > Debian, and the most part of code is written in C++, therefore we need to > compile and build binary debs. Currently our infrastructure consists of: > > 1. Gitlab; > 2. Isolated build environment inside Docker containers (where we >usually do `git clone && mk-build-deps && debuild`); Either: After a clone: gbp buildpackage --git-pbuilder Or: gbp buildpackage --git-builder='sbuild' (gbp is git-buildpackage) > 3. Aptly; > 4. Self-written Python scripts linking all these components; > > At the moment we're trying to collect more information about existing > packaging systems. Our self-written scripts no longer meet our needs. Now we > have faced a choice: either we move our deployment process into third-party > packaging system (if we find the good one), or we get involved into the > development of own full-featured system. > > I would like to put an emphasis on the most in-demand features: > > 1. Lightweight isolated environment (hardware virtualization is not >suitable); sbuild / pbuilder (practically: cowbuilder). It's not exactly isolation. But a chroot is good enough for my packages. pbuilder is simpler to set up and use, but sbuild allows more flexibility. > 2. Git support; > 3. RESTful API (in order to provide clear integration with git hooks >that will launch build process); > 4. Web interface; > 5. Support for a different build backends (Debian default toolchain | >CPack); > 6. Binary package repository integration; > 7. Package version control (support for builds from different branches, >build number incrementation, keep changelog consistent, etc.); > 8. Email notification; > 9. Privacy (ability to deploy the system on the own facilities); Mini-buildd is nice if it fits your workflow. We started using it, but eventually moved on. It's a great start if you have no idea what are all the different bits. We're currently using scriptology based mostly around buildbot. Using it to build both RPMs and debs. Currently still using the default web interface. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150514091623.gx20...@lemon.cohens.org.il
Re: Re: Upcoming mass-bug filing: GStreamer 0.10 removal
Hi Lisandro, > I have just checked qt5's multimedia. The GStreamer 1.0 support will most > probably be part of Qt 5.5.0, due to June/July. > > Worst case scenario: if you decide to go ahead with the removal before we can > get 5.5.0 into the archive then I can simply disable gstreamer support on > qtmultimedia. This means the package remains API/ABI stable, but giving no > real audio/video to the user. Applications will not crash but will lack > features until we can get the GStreamer 1.0 support. Ugly, but... Even if I file RC bugs for GStreamer 0.10 now, it will take a few months before it can actually be removed. So if Qt 5.5 is planned to be released in June/July, there shouldn't be any problem for you. Thanks for updating me about the Qt situation btw, I thought they already finally released a stable version with GStreamer 1.x support. I guess that was just people using the patches on top of older versions then. Sebastian signature.asc Description: This is a digitally signed message part
Re: Modern Debian packaging system for DevOps: does it exist?
On Wed, 13 May 2015 19:14:36 +0300 Исаев Виталий wrote: > Hello! I'm looking for a convenient wrapper of standard Debian > packaging toolchain in order to automatize the deployment process. It would seem to be attainable, but then each use case goes off on a particular tangent: > We > use Ubuntu and Debian, and the most part of code is written in C++, > therefore we need to compile and build binary debs. Currently our > infrastructure consists of: > > 1. Gitlab; > 2. Isolated build environment inside Docker containers (where we > usually do `git clone && mk-build-deps && debuild`); > 3. Aptly; > 4. Self-written Python scripts linking all these components; What is the reason for docker vs chroot, LVM snapshot or VM? > At the moment we're trying to collect more information about existing > packaging systems. Our self-written scripts no longer meet our needs. > Now we have faced a choice: either we move our deployment process > into third-party packaging system (if we find the good one), or we > get involved into the development of own full-featured system. > > I would like to put an emphasis on the most in-demand features: > > 1. Lightweight isolated environment (hardware virtualization is not > suitable); > 2. Git support; > 3. RESTful API (in order to provide clear integration with git hooks > that will launch build process); > 4. Web interface; > 5. Support for a different build backends (Debian default toolchain | > CPack); > 6. Binary package repository integration; > 7. Package version control (support for builds from different > branches, build number incrementation, keep changelog consistent, > etc.); 8. Email notification; > 9. Privacy (ability to deploy the system on the own facilities); Please clarify - is this meant to relate to not using the formal Debian archive but replicating something essentially similar inside a private network where connections between units can be public or do those connections between build system units need to be encrypted? > It seems like none of the well-known open-source solutions (Open > Build Service, Launchpad, Travis CI) meets this requirements. Please > share how exactly you build deb packages from your projects and what > tools do you use? Any help will be appreciated. As you've found, each use case differs substantially. In my last job, we got the the point of writing pybit (which is in Debian) for our needs and it covers some of your requirements - except that development has stalled as the team now have different jobs and different use cases, none of which precisely match. However, if you want a codebase which can get you a start which has the RestAPI, pluggable backends, VCS hook support, Debian packaging knowledge and is able to automatically plug the built .deb files into an internal Debian archive, it is worth considering. You'd likely be forking it at the github level and building up from there. Current code stops at the point where we had a working process for subversion building on two ARM daemons but then upstream collectively ran out of time to push it further. It's not the solution you describe but it could be something which gets you a start on something other than your current scripts. I thought I'd mention it as it started out in just the same way as you describe - we had a need for a particular use case, it just doesn't exactly match yours. Each time a team comes to this problem, a new solution is created. The components are all in place already - pybit uses schroot (same as the main Debian archive) and can use pbuilder etc. - it's the glue tying the bits together which gets hard to adapt to different users. Turns out to be hard to get one system which can be sufficiently flexible. Personally, my own build needs have essentially gone away as my development is now almost exclusively in python (and a tiny bit of perl). git-buildpackage is all we need and this codebase has no requirement for any isolation beyond the simplest chroot - and even that is only actually used for "official" builds. Developer builds for local testing just build from git. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpyCP11vrfbP.pgp Description: OpenPGP digital signature
Re: Modern Debian packaging system for DevOps: does it exist?
❦ 14 mai 2015 14:02 +0100, Neil Williams : >> 1. Gitlab; >> 2. Isolated build environment inside Docker containers (where we >> usually do `git clone && mk-build-deps && debuild`); >> 3. Aptly; >> 4. Self-written Python scripts linking all these components; > > What is the reason for docker vs chroot, LVM snapshot or VM? It's hype! ;-) More seriously, but this needs some additional work, it should be easier to manage persistent build dependencies. The first time you build a package, it retrieves and install all deps. The second time, the build environment is already here. -- Don't comment bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#785303: ITP: chake -- serverless configuration management tool for chef
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: chake Version : 0.6 Upstream Author : Antonio Terceiro * URL : https://gitlab.com/terceiro/chake * License : MIT (Expat) Programming Lang: Ruby Description : serverless configuration management tool for chef chake allows one to manage a number of hosts via SSH by combining chef (solo) and rake. It doesn't require a chef server; all you need is a workstation from where you can SSH into all your hosts. chake automates copying the configuration management repository to the target host (including managing encrypted files), running chef on them, and arbitraty commands on the hosts. This will be maintained as part of the Debian Ruby team. -- Antonio Terceiro signature.asc Description: Digital signature
Re: Modern Debian packaging system for DevOps: does it exist?
On Thu, 14 May 2015 15:45:01 +0200 Vincent Bernat wrote: > ❦ 14 mai 2015 14:02 +0100, Neil Williams : > > >> 1. Gitlab; > >> 2. Isolated build environment inside Docker containers (where we > >> usually do `git clone && mk-build-deps && debuild`); > >> 3. Aptly; > >> 4. Self-written Python scripts linking all these components; > > > > What is the reason for docker vs chroot, LVM snapshot or VM? > > It's hype! ;-) So can be ignored. Good. The remaining options are LVM snapshot, disposable chroot or a disposable VM. Those can be implemented in any number of ways but it needs to be a fresh, clean, predictable start to each build. > More seriously, but this needs some additional work, it should be > easier to manage persistent build dependencies. The first time you > build a package, it retrieves and install all deps. The second time, > the build environment is already here. That's a (serious) bug, not a feature. Either you want clean build environments or you are prepared to build in dirty ones, in which case there's little point using a container at all. A package cache is different, that's what pbuilder uses - that avoids the risk of stale packages being installed, not being updated and breaking the build. Either do it by uninstalling at the end of the build or by using a disposable container (LVM snapshot or pbuilder chroot). At all costs, avoid the false appeal of a dirty container which gets you none of the advantages and all of the problems of building on a developer box with no container at all. Were you thinking of a package cache or a dirty container? Any build system which allows for dependencies of a previous build to exist at the start of the next build is irretrievably broken and unfit for purpose. All you can allow to exist at the start of the build is build-essential. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpWx3GrNTS9p.pgp Description: OpenPGP digital signature
Re: Re: Modern Debian packaging system for DevOps: does it exist?
Regarding the state of containers after the finish of the build process: we surely don't need them anymore. Every container is used just once and removed after a while. We have docker image with preinstalled compilers and packaging toolchain. All the dependencies are being installed every time from scratch. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5554afad.1000...@corp.sputnik.ru
Re: Re: Modern Debian packaging system for DevOps: does it exist?
Hi, Neil, thanks for a prompt reply. I need to clarify our use case indeed. Some of our projects contain both free and proprietary code. So the "Privacy" feature I mentioned in the initial message means that packages built from these projects (currently) is only for internal use. We have private git and binary repositories, so now we are looking for a system that will turn our code into debs. > What is the reason for docker vs chroot, LVM snapshot or VM? First, the use of container virtualization is part of our policy. Also we didn't want to dedicate a distinct machine for packaging, so we decided to dockerize Debian toolchain. Moreover, Docker showed better performance (in contrast with hardware virtualization) and seemed to be the most suitable for fast deployment of the one-off build environment. I learned a lot from your response, I'll try to study all of them, especially pybit. To be honest, I'm not familiar with a package maintenance techniques, but I have to learn it now. Sincerly, Vitaly Isaev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5554b789.4030...@corp.sputnik.ru
Re: Re: Modern Debian packaging system for DevOps: does it exist?
Hello Tzafrir, thanks for pointing the mini-buildd. I've never heared about this tool. Will try to grab more info about it. Sincerely, Vitaly Isaev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5554b7b9.7010...@corp.sputnik.ru
Bug#785317: ITP: tucnak -- VHF/UHF/SHF Hamradio contest logging program
Package: wnpp Severity: wishlist Owner: Colin Tuckley * Package name: tucnak Version : 4.03 Upstream Author : Ladislav Vaiz * URL : http://tucnak.nagano.cz * License : GPL-2 Programming Lang: C Description : VHF/UHF/SHF Hamradio contest logging program VHF/UHF/SHF Hamradio contest logging program Tucnak is a VHF/UHF/SHF logging program for hamradio contests. It supports multi bands, free input, networking, voice and CW keyer, WWL database and much more. This is a new upstream version of tucnak. Prvious releases included the version number in the program name. (We have tucnak2 in Debian which will be removed soon). Tucnak requires libzia which is also in preparation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150514152057.14095.87871.reportbug@grenache
Re: Modern Debian packaging system for DevOps: does it exist?
Le mercredi 13 mai 2015 à 19:14 +0300, Исаев Виталий a écrit : > Hello! I'm looking for a convenient wrapper of standard Debian > packaging toolchain in order to automatize the deployment process. We > use Ubuntu and Debian, and the most part of code is written in C++, > therefore we need to compile and build binary debs. > At the moment we're trying to collect more information about existing > packaging systems. Our self-written scripts no longer meet our needs. > Now we have faced a choice: either we move our deployment process into > third-party packaging system (if we find the good one), or we get > involved into the development of own full-featured system. How about http://jenkins-debian-glue.org/ ? -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/143162.11708.1.ca...@debian.org
Bug#785328: ITP: rexical -- Lexical scanner generator for Ruby
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: rexical Version : 1.0.5 Upstream Author : ARIMA Yasuhiro * URL : https://github.com/tenderlove/rexical * License : LGPL-2.1 Programming Lang: Ruby Description : Lexical scanner generator for Ruby -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150514184535.9494.78196.reportbug@sasalam
Bug#785334: ITP: cdist -- Usable configurating management system
Package: wnpp Severity: wishlist Owner: Dmitry Bogatov * Package name: cdist Version : 4.0.0pre3 Upstream Author : Nico Schottelius * URL : http://www.nico.schottelius.org/software/cdist/ * License : GPLv3+ Programming Lang: Python, Shell Description : Usable configurating management system cdist is a usable configuration management system. It adheres to the KISS principle and is being used in small up to enterprise grade environments. It have following noteworthy features: . * shell scripting configuration language * access to all control structures (if, case, for, while) * idempotent target properties * zero-dependencies: target system need only /bin/sh and ssh * push-based distribution * highly-scalable . cdist is an alternative to other configuration management systems like cfengine, bcfg2, chef and puppet. I use this package to manage home computers. It uses /bin/sh language for configuration, which is more friendly than Ansible's Jinja2. Other known configuration management systems, like well-known puppet are pull-based. I plan to maintain this package myself. I need sponsor. Co-maintainer is not strictly necessery, but of-course welcome. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150514204821.26756.64511.reportbug@sagulo
Re: Modern Debian packaging system for DevOps: does it exist?
❦ 14 mai 2015 14:57 +0100, Neil Williams : >> More seriously, but this needs some additional work, it should be >> easier to manage persistent build dependencies. The first time you >> build a package, it retrieves and install all deps. The second time, >> the build environment is already here. > > That's a (serious) bug, not a feature. > > Either you want clean build environments or you are prepared to build > in dirty ones, in which case there's little point using a container at > all. > > A package cache is different, that's what pbuilder uses - that avoids > the risk of stale packages being installed, not being updated and > breaking the build. Either do it by uninstalling at the end of the > build or by using a disposable container (LVM snapshot or pbuilder > chroot). At all costs, avoid the false appeal of a dirty container > which gets you none of the advantages and all of the problems of > building on a developer box with no container at all. > > Were you thinking of a package cache or a dirty container? > > Any build system which allows for dependencies of a previous build to > exist at the start of the next build is irretrievably broken and unfit > for purpose. All you can allow to exist at the start of the build is > build-essential. For some packages, installing the dependencies can take more time than building the package. This makes use of pbuilder/cowbuilder quite tiresome. If the whole dependencies are already here, this becomes more enjoyable. This is not a dirty container. Only the dependencies needed for the packages are retrieved. If the build environment for the package doesn't exist, a new environment is created. Old environments are removed after a day. Something like that. -- Sometimes I wonder if I'm in my right mind. Then it passes off and I'm as intelligent as ever. -- Samuel Beckett, "Endgame" signature.asc Description: PGP signature
Re: Modern Debian packaging system for DevOps: does it exist?
❦ 14 mai 2015 17:22 +0300, Исаев Виталий : > Regarding the state of containers after the finish of the build > process: we surely don't need them anymore. Every container is used > just once and removed after a while. We have docker image with > preinstalled compilers and packaging toolchain. All the dependencies > are being installed every time from scratch. There is almost zero value in this solution with Docker. You have to reimplement ccache and package cache. -- They spell it "da Vinci" and pronounce it "da Vinchy". Foreigners always spell better than they pronounce. -- Mark Twain signature.asc Description: PGP signature
Re: Experimental ddeb support in debhelper and lintian
❦ 4 avril 2015 10:54 +0200, Niels Thykier : > * There is an experimental branch for debhelper to generate these >automatically available. >- Requires a "export DH_BUILD_DDEBS=1" to trigger the code path >- It applies to *all* compat levels. >- Trying to get the reproducible team to try it out to see if it > regresses anything (incl. reproducible builds) >- It *does* cause dpkg-genchanges to emit warnings about > uninitialized values (I think 3 per ddeb). Related to #781074 >- DOES *NOT* PRODUCE DDEBS FOR PACKAGES COVERED BY AN EXISTING -dbg! >- DOES *NOT* ADD BREAKS/REPLACES FOR MIGRATING FROM -dbg TO .ddeb! >- Branch at [DH-BRANCH] Since it needs a special environment variable to trigger the code path, do you plan to upload it to unstable/experimental soon? -- Don't stop with your first draft. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Debian Jessie netinst does not boot from grub/iso
Hi Norbert, Norbert Preining (2015-05-14): > Hi everyone > > (please Cc) > > I recently switched from a pre-release of the installer images > .../sid_d-i/current/amd64/iso-cd/firmware-testing-amd64-netinst.iso > (taken sometime about a year ago, or so) > > to the final version > ... firmware-8.0.0-amd64-netinst.iso > > and now the system does not boot from USB stick via grub/iso anymore, > telling be that it cannot find a CDROM drive. > > Is this a known issue? I haven't seen any comments concerning > this problem besides old ones not related to the released jessie. Please use the BTS. dd@ really is not where one reports issues with installation images. https://www.debian.org/releases/stable/amd64/ch05s04.html.en#submit-bug KiBi. signature.asc Description: Digital signature
Re: httpredir.debian.org, your mirrors redirector
Arnaud Fontaine (2015-05-14): > I tried to use http.debian.net instead of my local mirror, namely > http://ftp.jp.debian.org, last year and it was redirecting me to much > mirrors not in Japan (Taiwan or Korea). I sent 2 emails to you about > that but never got any reply so not sure if you actually got them. To reiterate from the announce text: Bug tracker: "mirrors" pseudo-package Contact address: mirr...@debian.org KiBi. signature.asc Description: Digital signature
Work-needing packages report for May 15, 2015
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 661 (new: 1) Total number of packages offered up for adoption: 170 (new: 1) Total number of packages requested help for: 58 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: backup-manager (#784851), orphaned 5 days ago Description: command-line backup tool Installations reported by Popcon: 600 660 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: mxml (#784865), offered 5 days ago Description: small XML parsing library Reverse Depends: aj-snapshot dreamchess forked-daapd libadios-bin libmxml-dev libnexus0 libnexus0-dev libnftnl0 nexus-tools paulstretch (5 more omitted) Installations reported by Popcon: 2003 169 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1928 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay packagesearch Installations reported by Popcon: 67420 athcool (#278442), requested 3852 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 38 awstats (#755797), requested 295 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4176 balsa (#642906), requested 1327 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 721 cardstories (#624100), requested 1480 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 13 cups (#532097), requested 2168 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers (64 more omitted) Installations reported by Popcon: 157308 debtags (#567954), requested 1928 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2252 developers-reference (#759995), requested 257 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 16875 ejabberd (#767874), requested 192 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib Installations reported by Popcon: 836 fbcat (#565156), requested 1947 days ago Description: framebuffer grabber Installations reported by Popcon: 160 freeipmi (#628062), requested 1449 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev libipmiconsole2 (5 more omitted) Installations reported by Popcon: 6220 gluegen2 (#783519), requested 17 days ago Description: Tool to automatically generate the Java and JNI code Reverse Depends: libgluegen2-rt-java libjogl2-java Installations reported by Popcon: 1378 gnat-gps (#496905), requested 2450 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 551 gnokii (#677750), requested 1062 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1471 gradle (#683666), requested 1015 days ago Description: Groovy based build system Reverse Depends: gradle libgradle-plugins-java Installations reported by Popcon: 301 gridengine (#703256), requested 788 days ago Description: Distributed resource management Reverse Depends: gridengine-client gridengine-drmaa-dev gridengine-exec gridengine-master gridengine-qmon logol Installations reported by Popcon: 1101 grub2 (#248397), requested 4021 days ago Description: GRand Unified Bootloader Reverse Depends: grml-rescueboot grml2u
Bug#785346: ITP: git-crypt -- Transparent file encryption in Git
Package: wnpp Severity: wishlist Owner: Andrew Ayer * Package name: git-crypt Version : 0.4.2 Upstream Author : Andrew Ayer * URL : https://www.agwa.name/projects/git-crypt * License : GPL3+ with OpenSSL linking exception Programming Lang: C++ Description : Transparent file encryption in Git git-crypt enables transparent encryption and decryption of files in a git repository. Files which you choose to protect are encrypted when committed, and decrypted when checked out. git-crypt lets you freely share a repository containing a mix of public and private content. git-crypt gracefully degrades, so developers without the secret key can still clone and commit to a repository with encrypted files. This lets you store your secret material (such as keys or passwords) in the same repository as your code, without requiring you to lock down your entire repository. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150515035122.15317.65413.report...@wagg.int.beanwood.com
