Re: Bug#831753: ITP: yuma123 -- netconf/YANG toolchain
❦ 19 juillet 2016 06:55 CEST, Vladimir Vassilev : > One of the tasks carried out during the IETF 96 Hackathon > was to create a debian package for yuma123. In order to > make sure the project was conformant to the debian package > requirements the net-snmp package was used as template. As > follow-up action the package is presented for review of > Debian Developers. Note sure that the NetSNMP package is the best model as it is a fairly complex package. I see that you kept a fair share of complexity. Except if yuma is forked from NetSNMP, it should be simpler to start from scratch. But if you already invested some time in the current packaging, we can also work from that. > Q: are you looking for co-maintainers? > A: Any help is welcome. Is the packaging available on a git repository? Either on alioth.debian.org or on your favorite VCS hosting system. > Q: do you need a Debian Developer sponsor? > A: Yes. Note that this is not really the right place to search for a sponsor. If your package is done, you should upload it to mentors.debian.net and follow the instructions here (file an RFS, request for sponsor). I am quite interested to see that in Debian too but I am currently quite time-constrained. I'll do a review once you have an RFS but feel free to settle this with other people if I am not responsive enough. -- The devil can cite Scripture for his purpose. -- William Shakespeare, "The Merchant of Venice" signature.asc Description: PGP signature
Bug#831753: ITP: yuma123 -- netconf/YANG toolchain
Package: wnpp Severity: wishlist Owner: Vladimir Vassilev * Package name: yuma123 Version : 2.6 Upstream Author : Vladimir Vassilev * URL : https://sourceforge.net/projects/yuma123 * License : BSD Programming Lang: C Description : netconf/YANG toolchain Based on the last BSD licensed version of Yuma (YumaWorks) with additional contributions added features and bugfixes. Provides libyuma - general YANG/netconf API, netconfd - server application with YANG model and loadable module support, yangcli - interactive command line client appication allowing configuration of netconf/YANG devices. Project code link: https://sourceforge.net/projects/yuma123 Wiki link: http://yuma123/wiki Package repository: http://yuma123.org/repos/ One of the tasks carried out during the IETF 96 Hackathon was to create a debian package for yuma123. In order to make sure the project was conformant to the debian package requirements the net-snmp package was used as template. As follow-up action the package is presented for review of Debian Developers. Q: why is this package useful/relevant? A: For Netoconf/YANG the package is what net-snmp is for SNMP. Q: is the project mature? A: The project is stable and is in use by commercial network devices produced by Transpacket AS. Q: if there are other packages providing similar functionality, how does it compare? A: There are no packages providing similar functionality. The project provides open-source alternative to the close-source confd (Cisco) and netconfd-pro (YumaWorks). Q: are you looking for co-maintainers? A: Any help is welcome. Q: do you need a Debian Developer sponsor? A: Yes.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Holger Levsen writes: > until your mail I wasn't aware that Puppet is also split into a free > and a commercial version… The Puppet in "Puppet Enterprise" is the same code as in the open source version. A Puppet Enterprise installation consists of additional omnibus-type packaging (puppet plus all dependencies installed in /opt/puppetlabs) for the agent, a similar installer for the master, plus configuration of mcollective and ActiveMQ, a Web application called the "Enterprise Console", as well as professional support. As far as I remember, only the "Enterprise Console" is non-free software. -- Stig Sandbeck Mathisen signature.asc Description: PGP signature
Orphaning the fedmsg stack (packages + infra) [was: Re: Status of fedmsg for the Debian infrastructure]
* Simon Kainz [2016-07-14 15:03:56 +0200]: > Hello, > > in the QA BoF at DC16 fedmsg was briefly mentioned, and I only found > [0], but could not find out what happened to the project. Has somebody > some more information about this? > > [0] https://lists.debian.org/debian-devel/2013/04/msg00764.html Hi Simon, fedmsg (the software stack) is currently unmaintained in Debian, and I was about to orphan the packages as soon as I came back from vacation. The infrastructure that creates fedmsg events from Debian events is currently kind of working, which means I sometimes restart the service when someone pings me about it. DSA has provided a virtual machine to move this to Debian infrastructure, but I haven't had the time, nor seen the interest from others, to do the migration. Basically, I'm giving up. It was a nice idea, but it seems that people actually like parsing emails. If you want to take over, I'd be glad to let you do so. I know from a corridor discussion at DebConf that there might be some interest from the NM team if the Debian integration is revived. Sadly, -- Nicolas Dandrimont Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c) signature.asc Description: Digital signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
Hi, sorry for the late reply, I ment to discuss this during DebConf IRL and then RL came into the way… On Thu, Jun 30, 2016 at 02:07:13PM +0200, Tollef Fog Heen wrote: > > On Sun, Jun 26, 2016 at 08:50:05PM +0200, Tollef Fog Heen wrote: > > > > > Do you also object to DSA using puppet for configuration management? > > > > I don't. In fact I wasnt aware puppet is under "non-free" CLA as well. > > Your earlier message wasn't about a CLA, but about whether software is > split in an enterprise version and a «normal» version. Puppet itself is > Apache licensed, so it's not copyleft and the need for any sort of CLA > isn't really there to be able to provide a proprietary version. (I'm > not sure if it has a CLA or not.) > > This might come across as splitting hairs. That is not my intention, > I'm trying to understand what you're actually objecting to. I'm not > sure if you'll be at Debconf or not, but if you are, feel free to grab > me for a discussion around this. I'd be interested in what you have to > say. until your mail I wasn't aware that Puppet is also split into a free and a commercial version… I'm not sure whether I would have objected (or even just complained) about DSA introducing puppet some years ago if I had known this back then, because of course (both) puppet (and gitlab) are free software, just with development models I seriously dislike. There's also always other factors, like "features" they implement… Visibility is another thing, the use of puppet is quite hidden and non user facing. Which reminds me of another difference: making DSA switch away from puppet will only inpact a few people, while switching away from gitlab once we have it, will have a much higher impact on people. So, choosing (or objecting) a software always is done based on many factors. (The above also misses some relevant factors…) Oh, and there is another big difference (I believe): there's not much gitlab development outside gitlab.com, while there is quite a lot of puppet development outside puppetlabs. -- cheers, Holger signature.asc Description: Digital signature
Bug#831675: ITP: jaxrs-api -- Java API for RESTful Services (JAX-RS)
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: jaxrs-api Version : 2.0.1 Upstream Author : Oracle Corporation * URL : http://jax-rs-spec.java.net * License : GPL-2 with Classpath exception or CDDL-1.1 Programming Lang: Java Description : Java API for RESTful Services (JAX-RS) The Java API for RESTful Web Services provides portable APIs for developing, exposing and accessing Web applications designed and implemented in compliance with principles of REST architectural style. This package will be maintained by the Java Team. It's expected to supercede libjsr311-api-java.
Bug#831668: ITP: ruby-gettext-setup -- fast_gettext helper for Ruby
Package: wnpp Severity: wishlist Owner: Sebastien Badia * Package name: ruby-gettext-setup Version : 0.3 Upstream Author : Puppet * URL : https://github.com/puppetlabs/gettext-setup-gem * License : Apache-2.0 Programming Lang: Ruby Description : fast_gettext helper for Ruby This package is a internationalization helper using fast_gettext for Ruby. This package is a new dependency of r10k, ruby-puppet-forge and ruby-semantic-puppet. We are going to maintain this package inside the Debian Puppet team.
New default -fdebug-prefix-map build flag for dpkg
Hi *, As part of the Reproducible Builds effort [0], we would like to enable a new default build flag from the reproducible/fixdebugpath feature area in order to prevent issues with build paths. From the dpkg-buildflag(1) manpage: This setting ([currently] disabled by default) adds -fdebug-prefix-map=BUILDPATH=. to CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS and FCFLAGS where BUILDPATH is set to the top-level directory of the package being built. This has the effect of removing the build path from any generated debug symbols. This flag is useful only since gcc-5/5.4.0-4 (#819176, [1]) and gcc-6 [2], as otherwise the produced debug symbols will lack the build path but the option itself will be saved in the resulting debug binary (in "DW_AT_producer"), only fixing the reproducibility problem halfway. Previous versions of GCC accept the -fdebug-prefix-map option but it was stored in DW_AT_producer, reducing the utility from a reproducible point of view. clang 3.8 supports the build flag and does not save the path in DW_AT_producer (although the source path gets included in the .strtab section if the source path is passed absolutely). We asked [3] the clang maintainers whether they would be willing to backport the -fdebug-prefix-path, but in the worst case there are only 3 clang reverse build-deps FTBFS due to this [4]. dpkg-buildflags 1.18.10 has a restriction on the characters allowed in the build path and will automatically and silently disable the option if it finds unsafe ones. This should make it safe against unescaped characters. See #827155 for more insight on this issue. We enabled the reproducible/fixdebugpath feature in the Reproducible Builds CI one month ago and whilst we have about 3k packages yet to build we are already confident that there won't be any major regression related to this other than those 3 packages. Thus, following the dpkg team's policy [5] about adding a new default build flag, I'm seeking a wider discussion to see whether somebody has any concern we haven't already taken care of. I'd like to thank Daniel Kahn Gillmor for leading the implementation of this new build flag which unblocked a real problem in the Reproducible Builds world: allowing us to build packages in different build paths! Thanks for reading, Mattia [0] https://wiki.debian.org/ReproducibleBuilds https://reproducible-builds.org [1] https://bugs.debian.org/819176 [2] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6ceddcd7b87911ddbb942923722af5a735dacedc [3] https://bugs.debian.org/819185 [4] afl, libblocksruntime and libclc [5] https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: wiki about block alignment issues
Daniel Pocock writes: > I've started a wiki about block alignment issues: > > https://wiki.debian.org/DiskBlockAlignment > > Can anybody comment on specific packages / tools that may help people > investigate or update their systems, maybe adding links to the wiki? "lsblk" (one of several ls$something commands) in the "util-linux" package is very helpful. It can show multiple fields, and has values for both storage and discard. ceph-osd-123# lsblk --output NAME,TYPE,ALIGNMENT,PHY-SEC,LOG-SEC,DISC-ALN,DISC-GRAN NAME TYPE ALIGNMENT PHY-SEC LOG-SEC DISC-ALN DISC-GRAN sdadisk 0 512 51200B ├─sda1 part 0 512 51200B └─sda2 part 0 512 51200B ├─vg0-swap lvm 0 512 51200B ├─vg0-root lvm 0 512 51200B ├─vg0-srvlvm 0 512 51200B ├─vg0-tmplvm 0 512 51200B ├─vg0-home lvm 0 512 51200B ├─vg0-varbackups lvm 0 512 51200B ├─vg0-varlog lvm 0 512 51200B └─vg0-ceph lvm 0 512 51200B sdcdisk 0 512 51200B ├─sdc1 part 0 512 51200B └─sdc2 part 0 512 51200B sdddisk 0 512 51200B ├─sdd1 part 0 512 51200B └─sdd2 part 0 512 51200B [...] laptop-with-crypto# lsblk --output NAME,TYPE,ALIGNMENT,PHY-SEC,LOG-SEC,DISC-ALN,DISC-GRAN NAME TYPE ALIGNMENT PHY-SEC LOG-SEC DISC-ALN DISC-GRAN sdadisk 0 512 5120 512B ├─sda1 part 0 512 5120 512B ├─sda2 part 0 512 5120 512B ├─sda3 part 0 512 5120 512B └─sda4 part 0 512 5120 512B └─sda4_crypt crypt 0 512 5120 512B sdbdisk 04096 51200B ├─sdb1 part 04096 51200B ├─sdb2 part 04096 51200B ├─sdb3 part 04096 51200B ├─sdb4 part 04096 51200B ├─sdb5 part 04096 51200B ├─sdb6 part 04096 51200B └─sdb7 part 04096 51200B -- Stig Sandbeck Mathisen
