Bug#905560: ITP: jaxrpc-api -- Java API for XML based RPC (JAX-RPC)
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: jaxrpc-api Version : 1.1.2 Upstream Author : Oracle Corporation * URL : https://github.com/javaee/javax.xml.rpc * License : CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : Java API for XML based RPC (JAX-RPC) JAX-RPC is an API for building Web services and clients that used remote procedure calls (RPC) and XML. Often used in a distributed client/server model, an RPC mechanism enables clients to execute procedures on other systems. In JAX-RPC, a remote procedure call is represented by an XML-based protocol such as SOAP. The SOAP specification defines envelope structure, encoding rules, and a convention for representing remote procedure calls and responses. These calls and responses are transmitted as SOAP messages over HTTP. This package will be maintained by the Java Team. It partially replaces the axis package which is unmaintained upstream.
Re: Bug#905427: go-sendxmpp -- Go package for sending single messages to an XMPP contact or groupchat
Am Samstag, den 04.08.2018, 18:49 +0200 schrieb W. Martin Borgert: > I wonder, why you want to package go-sendxmpp, if sendxmpp does > the same? Just another implementation language does not sound > like a great reason to have a new package. Maybe you can point > out some advantages, e.g. in functionality, performance, memory > consumption, dependency burden, security? I wrote it as the original sendxmpp had TLS-problems for me and someone else had problems sending to a groupchat with sendxmpp. So I thought an alternative could easily be done. But thinking it over I agree with you that 'just another sendxmpp' isn't a unique feature set that justifies inclusion in Debian. Maybe I was too excited and sent the RFP too quickly. Am Samstag, den 04.08.2018, 19:26 +0200 schrieb Michael Stapelberg: > Let me know how it goes, and I can update the blog post. Seems I also was too quick here. I thought it was one command per codebox on your post but some contain more and it turned out that this command already fails: "gbp buildpackage --git-pbuilder". I would have to search the debian go documentation for details (maybe this command is outdated) but as I am tending to agree with W. Martin Borgert to close this RFP I might do this later with one of my other projects which doesn't have an similar package already included in Debian. Best wishes, Martin signature.asc Description: This is a digitally signed message part
Re: Questions about packaging systemd unit files
On Sun, Aug 05, 2018 at 10:20:38PM +0100, Simon McVittie wrote: > On Sun, 05 Aug 2018 at 16:52:46 -0400, Theodore Y. Ts'o wrote: > > 1) Am I right in understanding that after modifying or adding any > >systemd unit or timer files, I must run "systemctl daemon-reload"? > > Yes, but preferably via dh_installinit (if you also have a corresponding > LSB/sysvinit script, like most daemons) or dh_installsystemd (if not, > like e.g. systemd-cron or quake4-server) rather than directly. There's a comment in the dh_installinit man page: dh_installinit is a debhelper program that is responsible for installing init scripts with associated defaults files. In compatibility levels up to 11, dh_installinit also handled upstart job files and systemd service files. I realize that compat level 11 is the recommended, and since level 12 is still open for development, but it sounds like in the future level 12 isn't going to do automatically handle init scripts automatically? One of the reasons why I hadn't considered using dh_installinit or dh_installsystemd is because the patches submitted upstream for e2scrub[1] currently install the systemd unit as part of Makefile rules. I could move them out of Makefile install rules into the debian directory, but that would be kind of a pain, and would mean trying to keep the files in the debian directory in sync with the ones in the upstream source directory. [1] This is a script to do on-line, background scrubbing of ext4 file systems to looking for file system problems. Also, for a package which is either essential or required, using debhelper commands in the maintainer scripts would mean adding a dependency, which would mean what is currently an "optional" package would end up getting dragged in automatically. Is this acceptable? I would think it might be considered undesirable. Finally, if I have a systemd timer file, as well as a crontab entry, what is the recommended way to decide whether to install/use the crontab versus the timer unit file? Should package maintainers try to use systemd timer files at all, given that complexity and the fact that the right thign won't happen on sysvinit-only systems at all? I've never been a fan of systemd, but it's what Debian is chosen, and my intention is to provide first class support for systemd. What's not clear to me how much support are maintainers obliged to give for non-systemd installations, and what's considered best practices for supporting them. For example, we could say that timer files are strongly discouraged and everyone MUST use crontab entries. Or we could say that on systemd systems, the cron package may not exist and crontab entries are now deprecated. Or we could say that package maintainers must try their best to support both. There's nothing in Debian Policy to give guidance, and I suspect it's too early for that. Any suggestions though would be appreciated. - Ted
Re: Questions about packaging systemd unit files
On Mon, 2018-08-06 at 09:14 -0400, Theodore Y. Ts'o wrote: [...] > One of the reasons why I hadn't considered using dh_installinit or > dh_installsystemd is because the patches submitted upstream for > e2scrub[1] currently install the systemd unit as part of Makefile > rules. I could move them out of Makefile install rules into the > debian directory, but that would be kind of a pain, and would mean > trying to keep the files in the debian directory in sync with the ones > in the upstream source directory. [...] dh_installsystemd(1) says: "It also finds the service files installed by a package…" which implies to me that it will operate on services that were already installed as well as those specified in the debian/ directory. The manual page is not that clear on whether it will operate on other types of already installed unit file, but it does appear to do so. Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. signature.asc Description: This is a digitally signed message part
Salsa token and privacy
Hello, I was using a nitrokey pro + gpg-agent in order to connect via ssh to the debian infrastructure. Now that we have salsa, it seems that the way to go is to use salsa token in order to automake a bunch of tasks. So now I need to put somewhere on a disk my salsa token, in fact on every computer where I want to use this token. And it means a lot. I would like to have something like the previous setup where all my private information are stores on the nitrokey. do you know if the salsa api (in fact gitlab api) can be access more securely than via a token which is copied multiple times everywhere. and if not how are you dealing with this ? Frederic PS: Nothing polemic here please, I have just this concern about the token privacy.
Re: Questions about packaging systemd unit files
Theodore Y. Ts'o: > On Sun, Aug 05, 2018 at 10:20:38PM +0100, Simon McVittie wrote: >> On Sun, 05 Aug 2018 at 16:52:46 -0400, Theodore Y. Ts'o wrote: >>> 1) Am I right in understanding that after modifying or adding any >>>systemd unit or timer files, I must run "systemctl daemon-reload"? >> >> Yes, but preferably via dh_installinit (if you also have a corresponding >> LSB/sysvinit script, like most daemons) or dh_installsystemd (if not, >> like e.g. systemd-cron or quake4-server) rather than directly. > > There's a comment in the dh_installinit man page: > > dh_installinit is a debhelper program that is responsible for > installing init scripts with associated defaults files. In > compatibility levels up to 11, dh_installinit also handled upstart > job files and systemd service files. > > I realize that compat level 11 is the recommended, and since level 12 > is still open for development, but it sounds like in the future level > 12 isn't going to do automatically handle init scripts automatically? > In compat 12, dh_installinit scripts will working with upstart files and systemd services files. Actually, I thought it stopped with systemd units files in compat 11 - I would have to check up on that. Feel free to file a bug against debhelper proposing a better / less confusing way to document this. > > One of the reasons why I hadn't considered using dh_installinit or > dh_installsystemd is because the patches submitted upstream for > e2scrub[1] currently install the systemd unit as part of Makefile > rules. [...] > Ben replied to this and is correct in that dh_installsystemd will look for systemd units installed directly and setup maintscripts for them as well. > > Also, for a package which is either essential or required, using > debhelper commands in the maintainer scripts would mean adding a > dependency, which would mean what is currently an "optional" package > would end up getting dragged in automatically. Is this acceptable? I > would think it might be considered undesirable. > The debhelper generated maintscripts do *not* rely on anything from debhelper itself. In particularly, all commands used in the snippet generated by dh_installsystemd is provided by "Essential: yes" packages, so there is no problem here. Thanks, ~Niels
Re: Questions about packaging systemd unit files
Theodore Y. Ts'o wrote: > Finally, if I have a systemd timer file, as well as a crontab entry, > what is the recommended way to decide whether to install/use the > crontab versus the timer unit file? Unfortunately, there isn't a clean mechanism for that. For systemd unit files, systemd's built-in support for sysvinit scripts automatically ignores a sysvinit script if a corresponding unit file exists, which means you can just install a sysvinit script and a native unit and the latter will supersede the former. However, systemd doesn't have built-in support for cron files; systemd-cron exists, and implements a mechanism to mask cron files if a corresponding systemd timer file exists, but that assumes the use of systemd-cron, which doesn't get installed by default, and it isn't obvious if it's production-ready. (Note that putting a line in your cron entry to exit if under systemd still means cron needs to go run that script and have it exit, which is not ideal.)
Re: Questions about packaging systemd unit files
Am 06.08.2018 um 20:52 schrieb Josh Triplett: > (Note that putting a line in your cron entry to exit if under systemd still > means cron needs to go run that script and have it exit, which is not ideal.) It's maybe not ideal but what I would suggest. The recommended way to check whether systemd is the active init is to check for /run/systemd/sytem, so you could add the following to the beginning of your crontab entry [ -d /run/systemd/system ] && exit 0 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Browserified copy and DFSG
Hi, They are a few package that FTBFS due to lack of browserify under debian [1] The most significant point is to render javadoc FTBFS due to lack of browserified version of pako a port of zlib to javascript. I plan to upload browserify soon but browserify is blocked by: * node-insert-module-globals in NEWS (prod ftpmaster) * node-has-object-spread not yet packaged (i plan to do it) * node-has-template-literals not yet packaged (i plan to do it) Browserify (or webpack) is a static compiler for javascript. I believe that we must use built-using field in order to be policy compliant. I can output a list of javascript module (or file installed in the tree) but I lack the debhelper skill needed to output automatically built-using. Can somebody help me ? Bastien [1] For an approximation see https://lintian.debian.org/tags/source-contains-browserified-javascript.html that also include webpack
Re: Browserified copy and DFSG
Bastien ROUCARIES: > Hi, > > They are a few package that FTBFS due to lack of browserify under debian [1] > > The most significant point is to render javadoc FTBFS due to lack of > browserified version of pako a port of zlib to javascript. > > I plan to upload browserify soon but browserify is blocked by: > * node-insert-module-globals in NEWS (prod ftpmaster) > * node-has-object-spread not yet packaged (i plan to do it) > * node-has-template-literals not yet packaged (i plan to do it) > > Browserify (or webpack) is a static compiler for javascript. I believe > that we must use built-using field in order to be policy compliant. > > I can output a list of javascript module (or file installed in the > tree) but I lack the > debhelper skill needed to output automatically built-using. > > Can somebody help me ? > > Bastien > > [1] For an approximation see > https://lintian.debian.org/tags/source-contains-browserified-javascript.html > that also include webpack > AFAIUI, Built-Using is solely to be used for compliance with licenses (GPL or GPL-like licenses). Are these node modules under GPL or a GPL-like license? If not, there should be no need for Built-Using. Thanks, ~Niels
Re: its dead jim - alioth is gone
Hi Unfortunately, alioth continues to be referenced on various pages, still. Just 1 example: In https://debian-handbook.info/browse/stable/sect.kernel-compilation.html one of the first links points to: GOING FURTHER: http://kernel-handbook.alioth.debian.org/ It would be great if this could be updated as soon as possible. What is the time horizon where these left overs are completed? Cheers michi schnyder On 05.06.2018 21:49, Alexander Wirt wrote: > Hi, > > after more than two years of preperation I am happy to say that > alioth is history now. I finished the archiving of all vcs repos > yesterday - they are now archived [1]. > > SSH logins on alioth are now disabled, if you find that you are missing > something and think it is *really* urgent - get in touch with me and I should > be able to help you. In a few days we will shutdown and delete the vm. > > The redirector was moved to a DSA managed box, updates to the map will still > happen, but only once a week. > > Whats left? > > - deleting the vm > - remove alioth from our docs > - update vcs entries in packages > - improve the salsa docs > - deploy the new sso.debian.org backend > > Thats it folks > > Thanks to all helping hands > > especially ganneff and waldi > > Alex - former alioth admin > > [1] https://alioth-archive.debian.org/ >
