Package tool with systemd dependency
Hey, I want to package a tool* which highly uses systemd and particulary its per-user service feature. The upstream author supports only systemd as init system and recommends to run the tool under user rights. Is it a problem to package the tool with "Depends: systemd" and "Architecture: linux-any"? Best regards, Jan * https://github.com/graysky2/profile-sync-daemon
Re: Package tool with systemd dependency
On Tue, 21 Jun 2016 at 11:11:09 +0200, Jan Luca Naumann wrote: > I want to package a tool* which highly uses systemd and particulary its > per-user service feature. By "per-user service" are you referring to systemd user services, which are children of the per-user service manager, "systemd --user" (aka the system service user@.service, started by systemd-logind)? If you are, then this tool is in the same situation as dbus-user-session, which is an optional/recommended add-on for dbus, and currently only works with systemd. (I'd review patches for other service managers that can guarantee to provide a D-Bus socket early in login, if such things exist, but in practice I think systemd and maybe Upstart are the only ones.) > Is it a problem to package the tool with "Depends: systemd" and > "Architecture: linux-any"? You should probably use Depends: libpam-systemd (which means you get a working systemd-logind somehow, either via systemd-sysv or sysvinit + systemd-shim) together with a Depends or Recommends on systemd-sysv. That's what I did for dbus-user-session. Depends: systemd is not enough, because having systemd.deb installed says nothing about whether systemd was actually used as init. S
Re: Package tool with systemd dependency
On Tue, 2016-06-21 at 10:55 +0100, Simon McVittie wrote: > On Tue, 21 Jun 2016 at 11:11:09 +0200, Jan Luca Naumann wrote: > > I want to package a tool* which highly uses systemd and particulary > > its > > per-user service feature. > > By "per-user service" are you referring to systemd user services, > which are > children of the per-user service manager, "systemd --user" > (aka the system service user@.service, started by systemd-logind)? The upstream repository looks like it provides .service units for a "systemd --user" instance. > You should probably use Depends: libpam-systemd (which means you > get a working systemd-logind somehow, either via systemd-sysv or > sysvinit + systemd-shim) together with a Depends or Recommends on > systemd-sysv. That's what I did for dbus-user-session. AFAIK this is not enough to get a "systemd --user" instance. You would need to depend on both libpam-systemd *and* systemd-sysv. That said I think packages should avoid depending on systemd-sysv if possible. It should be fine to only provide a unit for "systemd --user" and people who don't use systemd or libpam-systemd then have to configure the service start and stop themselves. Ansgar
Bug#827819: ITP: timewarrior -- command line time tracking application, which allows you to record time spent on activities
Package: wnpp Severity: wishlist Owner: Sebastien Badia * Package name: timewarrior Version : 0.9.5 Upstream Author : Paul Beckingham, Federico Hernandez * URL : https://taskwarrior.org/docs/timewarrior * License : MIT Programming Lang: C Description : command line time tracking application, which allows you to record time spent on activities Timewarrior is a time tracking utility that offers simple stopwatch features as well as sophisticated calendar-base backfill, along with flexible reporting. It is a portable, well supported and very active, Open Source project. We currently maintain with Gordon, taskd(server) and taskd(client) from taskwarrior, we may maybe create a team.
Re: Accepted r-cran-pheatmap 1.0.8-1 (source all) into unstable, unstable
Unsubscribe this. Em 21/06/2016 09:00, Andreas Tille escreveu: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 20 Jun 2016 12:06:05 +0200 Source: r-cran-pheatmap Binary: r-cran-pheatmap Architecture: source all Version: 1.0.8-1 Distribution: unstable Urgency: low Maintainer: Debian Med Packaging Team Changed-By: Andreas Tille Description: r-cran-pheatmap - GNU R package to create pretty heatmaps Closes: 827728 Changes: r-cran-pheatmap (1.0.8-1) unstable; urgency=low . * Initial release (Closes: #827728). Checksums-Sha1: b836f6d34d20399eeb3dee267a212e2792a31cb9 2103 r-cran-pheatmap_1.0.8-1.dsc 7064eaa939ee0eedc3822317c446d5a35eaab538 13759 r-cran-pheatmap_1.0.8.orig.tar.gz 9d8bafeba3cc2f1cb5a76fc19d86725801f1bbac 1436 r-cran-pheatmap_1.0.8-1.debian.tar.xz 3e75636c6d80ba3bf8aa18a70336f97c91e26dd0 41542 r-cran-pheatmap_1.0.8-1_all.deb Checksums-Sha256: 156360cad7851f3b329f742e446380c5b715561a616a72ff36380ffb42630918 2103 r-cran-pheatmap_1.0.8-1.dsc 51468765380119c302ee9afd52d0483123c0670297f4b906edc79235939960c6 13759 r-cran-pheatmap_1.0.8.orig.tar.gz 8ac68e2cab603cfaf77d6fb974d8ca74f4514c85436e464a9440d18a75f00d4c 1436 r-cran-pheatmap_1.0.8-1.debian.tar.xz 7712c4a41bf3716a037c8e219e0ecdaaa427e3e12371e16b3cf1d18be427a6d0 41542 r-cran-pheatmap_1.0.8-1_all.deb Files: bc23cf28462cd88447ec6b244eadd75b 2103 gnu-r optional r-cran-pheatmap_1.0.8-1.dsc 134a6f84b94b9aa9bcd77b594f74a438 13759 gnu-r optional r-cran-pheatmap_1.0.8.orig.tar.gz c3c511ccb5ef99ee5c3a2105a23f56ab 1436 gnu-r optional r-cran-pheatmap_1.0.8-1.debian.tar.xz 0ebe38f792de43b0e59c77552458696a 41542 gnu-r optional r-cran-pheatmap_1.0.8-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJXZ8EMAAoJEFeKBJTRxkbRgb0P/320GSP/WfK0/C/1iP0uEXHa 4460lcvzOG13qmj427Z7NE+sW2q4XuOmUEM0viX0XXK0rL63C0dw4s430y8HduuT kR0tb0LNaMO8Pb7vq+Oc2tNBPIBy9tieVaOQYLcr6A3DtDZYFb+IWZkPd2IHbpOi ZjX/EwMIj29mJ2H6vZQDyScz4eKKuwYy97u7MxKCDjRDF0jtXlRagd0TT1LMFhnk 2rAaO+zWGmVMK2YgL9ckLMhSZxdpa+Md7YplfNCbbNfzTLQfnONmv6D4I/rQDppc wSqYoe1z0YYNR5GOx2u0XGXaax9qEnpGoif6DGBaQ9wd7OI4Ud5G3tUM7S3S4kR6 VZt8jbxzGPfT8ZswteryLReBULq3z83csE5jFJrwyGUTXH+RYC65+iQZnYyoE2dA gaoeHJwVY7owfOgMC2Wjb7ymLIAWBfXKil/CtV5yjDX0kurOW+0sHEZ7fGbkoJgl kWv/uHw1ZVN5JvpScWJ1ctMdLJ4Epa6vFcDZJ5/NzUfUPIfmaH1yizKYtCZJI2+m 63OoRigWj9A48kWijGhBQO8Ntx1KT9OwXEwDhl0KAUJL9o0X1185KpvMj4GwIcIZ AVMnfdWwEaaWNDPrkBkQ3WZJJwPhm8OSF7VAWrL9xsOBk0JwREnERSBrvQ13ajmM BPeAth2sQQFBRZAlsU+c =ZboY -END PGP SIGNATURE-
Re: Bug#827819: ITP: timewarrior -- command line time tracking application, which allows you to record time spent on activities
On 21/06/16 13:08, Sebastien Badia wrote: > Timewarrior is a time tracking utility that offers simple stopwatch features > as > well as sophisticated calendar-base backfill, along with flexible reporting. > It > is a portable, well supported and very active, Open Source project. > > We currently maintain with Gordon, taskd(server) and taskd(client) from > taskwarrior, > we may maybe create a team. > I currently have an ITP for bugwarrior (bug tracker <-> taskwarrior integratation) Would be happy to do this within this hypothetical team. (: Thanks, Iain.
Re: Package tool with systemd dependency
On Tue, 21 Jun 2016 at 13:49:27 +0200, Ansgar Burchardt wrote: > The upstream repository looks like it provides .service units for a > "systemd --user" instance. Lots of projects do this; if combined with other ways to start the service (such as D-Bus activation), it certainly doesn't merit a hard dependency on systemd-sysv. (I have no opinion on whether profile-sync-daemon should enforce use of "systemd --user" or not; that's a social rather than technical question, based on what its upstream and its Debian maintainer are willing to take responsibility for.) > It should be fine to only provide a unit for "systemd --user" > and people who don't use systemd or libpam-systemd then have to > configure the service start and stop themselves. Yes up to a point, but not if the "systemd --user" integration is considered to be critical to the specific binary package with the dependency. If you want a D-Bus session without having a systemd --user instance, you can install dbus-x11 and use dbus-launch, or you can install dbus and use dbus-run-session; but you shouldn't install dbus-user-session and expect it to work without systemd --user, because integration with systemd --user is the only thing that dbus-user-session does. If dbus-user-session had the same semantics as traditional D-Bus in terms of what a "session" means, I'd have just included it in dbus with a Suggests on libpam-systemd, but since it isn't 100% compatible, it's a separate package to provide a way to make the newer semantics opt-in. Until/unless someone provides a working non-systemd implementation, it can only do what its documentation says it does by using systemd --user. dbus-user-session does have Depends: libpam-systemd and Recommends: systemd-sysv instead of two hard dependencies, but only to account for the possibility of starting systemd via init=/lib/systemd/systemd. S
Re: opinions of snappy packages
On Sun, Jun 19, 2016 at 09:12:31PM +0200, Raphael Hertzog wrote: > Unfortunately, while they might have done some work to make it available > on other distributions, they have not taken the time to upload the package > to Debian. I'd like to assume that whoever is planning to upload snappy (and I assume that someone *is* interested) is taking their time to get the packaging right for our distro and thinking through integration and whole-distribution issues rather than simply uploading a rush-job to the archive. I'd actually like to see a wider discussion as to the merits of snappy versus flatpak (and others) and the pros/cons of supporting (or otherwise) multiple such things or picking one (or waiting to see whether any get any kind of real-world traction). > $ apt show lxd > N: Unable to locate package lxd > E: No packages found I believe Adnan is working on an lxd package (if I remember the ITP correctly). It is somewhat delayed, but that is largely due to the ITP being squatted by someone else for a year or so, and I can't blame Canonical for particular failing (which is a problem with our processes whereby ITPs can be effectively squatted and contributors put off by others over-promising and under-delivering) -- Jonathan Dowland Please do not CC me, I am subscribed to the list.
Re: Package tool with systemd dependency
On Tue, Jun 21, 2016 at 10:55:52AM +0100, Simon McVittie wrote: > Depends: systemd is not enough, because having systemd.deb installed > says nothing about whether systemd was actually used as init. Is this not analoguous to "Depends: any-daemon is not enough, because that says nothing about whether the service is started on the running system"? We do not normally extend that requirement to the dependency logic for e.g. web apps. -- Jonathan Dowland Please do not CC me, I am subscribed to the list.
Re: opinions of snappy packages
On Tue, 21 Jun 2016 at 14:16:55 +0100, Jonathan Dowland wrote: > I'd actually like to see a wider discussion as to the merits of snappy versus > flatpak (and others) and the pros/cons of supporting (or otherwise) multiple > such things or picking one (or waiting to see whether any get any kind of > real-world traction). (Disclosure of bias: I maintain flatpak in Debian. I think it has a lot of potential, and so does my employer Collabora.) We've had 0install and Limba for years, so I don't think there's any harm in a "collect them all!" approach. Anything that is RC-buggy or that isn't considered to be supportable in stable (whether by its maintainer or the release team) can be removed around freeze time. For me, the big factor that pushes Flatpak and Snappy ahead of the older versions of this concept is that sandboxing the apps is explicitly a goal. They take different approaches: Flatpak uses containerization features (namespaces), while Snappy uses the AppArmor LSM. Either way, the aim is to move their apps out of the trusted computing base, which would be a big step forward. In practice the sandbox is leaky in both cases if an attacker can achieve arbitrary code execution, because both normally pass X11 through; when Wayland and/or Mir finally become widely enough available for app publishers to rely on them, they'll address that concern. If an exploit in a sandboxed app is limited to arbitrary file reading or writing (as opposed to arbitrary code execution and IPC), my understanding is that Flatpak's sandboxing should already be enough to protect you, although there might still be gaps for some specific files. If I understand correctly, on distributions that don't normally enable AppArmor (everything major except Ubuntu and SuSE?), none of Snappy's sandboxing is enforced. This seems like a very significant limitation, and I'm not sure why Canonical consider this to be a good time to promote Snappy as a cross-platform solution despite that gap. I would encourage the Snappy developers to look into using bubblewrap (which is Flatpak's sandboxing/containerization helper, spun off into a separate project so it can be shared by multiple API-users) or some similar namespacing approach. One of the things I've been trying to encourage in upstream Flatpak is making sure it can coexist with its competitors. The Flatpak command-line interface and library are really designed to be "mechanism not policy", with something like GNOME Software providing UI and letting the user choose trusted sources. GNOME Software is the first example I know of for a UI that supports installing Flatpak packages, although the version in Debian doesn't have that enabled yet; its plugin architecture also supports distro (deb/RPM) packages, Limba packages and even Steam games in the same UI, which is encouraging. I'm not sure whether we'll end up with end-user-facing support for Flatpak in Debian 9. If it seems suitably mature by then, we can enable it in GNOME Software and any similar GUIs that support it; if not, I think disabling the UIs and shipping it as a command-line-only, "for advanced users" package that isn't installed by default seems like a reasonable approach. On a purely non-technical level, Snappy's asymmetric CLA makes me wary about contributing to it or encouraging its adoption. I can't help thinking we've been here before with Upstart/systemd, OpenOffice.org/LibreOffice and Mir/Wayland. S
Re: Package tool with systemd dependency
To bring it back to the package at hand, because talking about abstractions isn't helpful here IMHO: On 06/21/2016 02:39 PM, Simon McVittie wrote: > On Tue, 21 Jun 2016 at 13:49:27 +0200, Ansgar Burchardt wrote: >> It should be fine to only provide a unit for "systemd --user" >> and people who don't use systemd or libpam-systemd then have to >> configure the service start and stop themselves. > > Yes up to a point, but not if the "systemd --user" integration is > considered to be critical to the specific binary package with the > dependency. Well, in this case it's rather simple, the units of the software in question have the following effect [*]: - at login a certain command is executed (profile-sync-daemon resync) - from then on the same command is executed every hour - at logout a different command is executed (profile-sync-daemon unsync) Plus the dependencies of the user units are done in such a way that only ever one of these commands is executed at the same time. So what happens here is that profile-sync-daemon is not actually a daemon, but rather a command that is executed periodically to perform a specific action. Off the top of my head, especially considering the guarantee of only ever executing one of these commands at a time, I don't know of anything out of the box that could do that on non-systemd systems. That said, it should really not be difficult to write some simple program that runs in the background, properly handles X11 session termination (i.e. recognizes it and performs actions), and then executes the commands in the same fashion. (And hook that up via /etc/X11/Xsession.d, with a check to disable it if systemd is running, because there you wouldn't need it.) So I think the systemd dependency here is just because the author of the upstream software didn't actually want to write a long running program, and used systemd's features to have an action take place repeatedly. So I see three options for the packager of this software: a) Declare a systemd-sysv + libpam-systemd dependency for now. b) Don't explicitly declare the systemd-sysv dependency (but do depend on libpam-systemd, so that user sessions are enabled on systemd systems), and mention in either README.Debian or so that people will have to figure out on their own how to start it if they don't run systemd. (I would suspect that the program itself doesn't really require systemd, just from looking at my analysis of the units.) c) Create the solution for running this on non-systemd systems yourself. (This would be more work though.) In my personal opinion, b) and c) seem more reasonable to me than a), because while b) doesn't offer Debian's "runs out of the box" experience on non-systemd systems, it at least allows people to install the software and figure it out for themselves. Regards, Christian [*] Technically, since systemd user instances aren't directly tied to sessions, the semantics are actually slightly different, in that login only means the first login, i.e. separate parallel logins e.g. via SSH (while the initial session is still active) don't have any effect, but the "logout" action will only be taken once there are no more sessions of a given user at a given time. (Even if the remaining session wasn't graphical.) Also, if the user enables logind's lingering, this will change semantics again. But on a typical desktop system (for which this is intended), where one logs in graphically and only once, the login/logout semantics I mentioned do apply. signature.asc Description: OpenPGP digital signature
Re: Package tool with systemd dependency
Hey Simon and Ansgar, thank you for your help and input. I think I will use the dependencies that Simon uses for dbus-user-session. Best regards, Jan Am 21.06.2016 um 14:39 schrieb Simon McVittie: > On Tue, 21 Jun 2016 at 13:49:27 +0200, Ansgar Burchardt wrote: >> The upstream repository looks like it provides .service units for a >> "systemd --user" instance. > > Lots of projects do this; if combined with other ways to start the > service (such as D-Bus activation), it certainly doesn't merit a > hard dependency on systemd-sysv. > > (I have no opinion on whether profile-sync-daemon should enforce use of > "systemd --user" or not; that's a social rather than technical question, > based on what its upstream and its Debian maintainer are willing to take > responsibility for.) > >> It should be fine to only provide a unit for "systemd --user" >> and people who don't use systemd or libpam-systemd then have to >> configure the service start and stop themselves. > > Yes up to a point, but not if the "systemd --user" integration is > considered to be critical to the specific binary package with the > dependency. If you want a D-Bus session without having a systemd --user > instance, you can install dbus-x11 and use dbus-launch, or you can install > dbus and use dbus-run-session; but you shouldn't install dbus-user-session > and expect it to work without systemd --user, because integration with > systemd --user is the only thing that dbus-user-session does. > > If dbus-user-session had the same semantics as traditional D-Bus > in terms of what a "session" means, I'd have just included it in > dbus with a Suggests on libpam-systemd, but since it isn't 100% > compatible, it's a separate package to provide a way to make the newer > semantics opt-in. Until/unless someone provides a working non-systemd > implementation, it can only do what its documentation says it does by > using systemd --user. > > dbus-user-session does have Depends: libpam-systemd and Recommends: > systemd-sysv instead of two hard dependencies, but only to account for > the possibility of starting systemd via init=/lib/systemd/systemd. > > S >
Bug#827840: ITP: qstopmotion -- qStopMotion is a free application for creating stop-motion animation movies
Package: wnpp Severity: wishlist Owner: Adrian Knoth * Package name: qstopmotion Version : newer than 2.2.0 Upstream Author : Ralf Lange * URL : http://www.qstopmotion.org/ * License : GPL Programming Lang: C++ Description : qStopMotion is a free application for creating stop-motion animation movies Copy&paste from the website: "qStopMotion is a free application for creating stop-motion animation movies. The users will be able to create stop-motions from pictures imported from a camera or from the harddrive and export the animation to different video formats such as mpeg or avi." We're going to maintain this inside pkg-multimedia-maintainers. qStopMotion-2.2.0 (newest as of 2016-06-21) is still based on gstreamer0.10, but upstream has indicated to get rid of it until August. We'll hold off packaging anything until then. Other technology involved: * Qt5 * V4L (Video4Linux) * cmake
Bug#827841: ITP: mocassin -- Monte Carlo simulations of ionised nebulae
Package: wnpp Severity: wishlist Owner: Roger Wesson * Package name: mocassin Version : 2.02.70 Upstream Author : Barbara Ercolano * URL : http://www.3d-mocassin.net * License : GPL-2+ Programming Lang: fortran Description : Monte Carlo simulations of ionised nebulae MOCASSIN is a fully 3D or 2D photoionisation and dust radiative transfer code which employs a Monte Carlo approach to the transfer of radiation through media of arbitrary geometry and density distribution. It was originally developed for the modelling of photoionised regions like HII regions and planetary nebulae and has since expanded and been applied to a variety of astrophysical problems, including modelling clumpy dusty supernova envelopes, star forming galaxies, protoplanetary disks and inner shell fluorence emission in the photospheres of stars and disk atmospheres. The code can deal with arbitrary Cartesian grids of variable resolution, it has successfully been used to model complex density fields from SPH calculations and can deal with ionising radiation extending from Lyman edge to the X-ray. The dust and gas microphysics is fully coupled both in the radiation transfer and in the thermal balance. Mocassin is a widely used code, with papers describing it having nearly 200 citations in the astronomical literature. The source code is available from 3d-mocassin.net and is licensed under GPL-v2+. I propose to create a debian package which can be maintained within the Debian Astronomy Team.
Bug#827843: ITP: xlogo -- XLogo is an interpreter for the Logo programming language, written in Java.
Package: wnpp Severity: wishlist Owner: Wolf Bergenheim * Package name: xlogo Version : 0.9.95 Upstream Author : Loïc Le Coq * URL : http://xlogo.tuxfamily.org * License : GPL Programming Lang: Java Description : XLogo is an interpreter for the Logo programming language, written in Java. XLogo is an interpreter for the Logo programming language, written in Java. It supports nine languages, (French, English, Spanish, Arabic, Portugese, German, Esperanto, Galacian and Greek) and is licensed under the GPL. Logo is a programming language developed in the 1970's by Seymour Papert. It is an excellent language to begin learning with, as it teaches the basics of things like loops, tests, procedures, etc. The user moves an object called a "turtle" around the screen using commands as simple as forward, back, right, and so on. As it moves, the turtle leaves a trail behind it, and so it is therefore possible to create drawings. Operations on lists and words are also possible. For example, forward 100 right 90 will first make the turtle move 100 steps forward, and then turn the turtle 90° to the right. This very intuitive graphical approach makes Logo an ideal language for beginners, especially children! The debian-live-based distribution Lernstick, that focuses on education, wants to include XLogo. So I thought I'll add it to Debian to give XLogo to even more people. I plan to maintain it on my own, with the help of the Lernstick team or under collab-maint.
Re: opinions of snappy packages
On 06/21/2016 04:31 PM, Simon McVittie wrote: > > On a purely non-technical level, Snappy's asymmetric CLA makes > me wary about contributing to it or encouraging its adoption. > I forget about Canonical's CLA from time to time - but this solely should be a reason to not adopt it in Free software projects.
Re: opinions of snappy packages
Zlatan Todoric writes ("Re: opinions of snappy packages"):
> I forget about Canonical's CLA from time to time - but this solely
> should be a reason to not adopt it in Free software projects.
I think that's up to the individual maintainer.
If the maintainer is prepared to carry the CLA-less patches, even if
that means diverging from upstream and perhaps eventually becoming a
de-facto fork, then the CLA is not a practical problem for Debian's
users and other contributors.
Or to put it another way: normally, if you maintain something in
Debian, you might well ask someone with a patch to take it up with
upstream directly, and you might even decline to carry in Debian a
patch that upstream have technical objections to.
But if you maintain in Debian something with an obnoxious CLA, and the
patch submitter does not want to sign the CLA, I think you're no
longer entitled to refuse to apply the patch just because the patch
can't go to the ultimate upstream.
How much of a practical problem this is for the maintainers in Debian
depends on what the package is, but I think it's a decision for the
potential maintainers, whether they want to put in that effort.
This is why I was not concerned about the CLA for upstart. The Debian
maintainer for upstart was very clear that they would be happy to
carry CLA-blocked-upstream patches indefinitely, and it was clear
they would have had the resources to continue to do that.
Does the prospective maintainer for Snappy commit to do the same ?
Ian.
Re: opinions of snappy packages
On 06/21/2016 06:43 PM, Ian Jackson wrote:
> Zlatan Todoric writes ("Re: opinions of snappy packages"):
>> I forget about Canonical's CLA from time to time - but this solely
>> should be a reason to not adopt it in Free software projects.
>
> I think that's up to the individual maintainer.
>
> If the maintainer is prepared to carry the CLA-less patches, even if
> that means diverging from upstream and perhaps eventually becoming a
> de-facto fork, then the CLA is not a practical problem for Debian's
> users and other contributors.
>
> Or to put it another way: normally, if you maintain something in
> Debian, you might well ask someone with a patch to take it up with
> upstream directly, and you might even decline to carry in Debian a
> patch that upstream have technical objections to.
>
> But if you maintain in Debian something with an obnoxious CLA, and the
> patch submitter does not want to sign the CLA, I think you're no
> longer entitled to refuse to apply the patch just because the patch
> can't go to the ultimate upstream.
>
> How much of a practical problem this is for the maintainers in Debian
> depends on what the package is, but I think it's a decision for the
> potential maintainers, whether they want to put in that effort.
>
> This is why I was not concerned about the CLA for upstart. The Debian
> maintainer for upstart was very clear that they would be happy to
> carry CLA-blocked-upstream patches indefinitely, and it was clear
> they would have had the resources to continue to do that.
>
> Does the prospective maintainer for Snappy commit to do the same ?
>
It is not only would someone take care of it now - but what about it in
further future. Or in other words - it is better to put effort and
energy into "clean" solution (that will probably get more community
behind it) rather than diverging from upstream and having to bother with
"patch or not to patch" things.
Re: Keysigning via Video Conferencing
Jason Thomas dijo [Mon, Jun 20, 2016 at 12:31:57PM +1000]: > Hi all, > > I need to get my key signed, is anyone willing to work with me via > video conferencing. > > I have uploaded my key to keyring.debian.org and I have also signed > this message. > > I have a scan of my government issued drivers licence available. The medium you use to verify your counterpart's identity when performing a signature is completely up to you; I could be perfectly happy with cross-signing with $person via videoconferencing — But what we push, what we *really* expect each of us to do, is to actually *ensure identity*. For some, ensuring identity is a matter of checking a government-issued ID. In this case, Jason is providing a scan of such an ID. Might I add, in case you take on his request: Are you familiar with his country's drivers licenses? How hard are they to forge? How hard would they be to digitally manipulate without other parties noticing? If that satisfies you, please go ahead and sign. Of course, Jason, same for you — Although it suffices for us to have your key "reachable" from the strong set, we really prefer your key being part of the strong set (that is, other keys being reachable from yours). If somebody signs your key, please try to sign theirs as well (if you are convinced of their identity). Now, I have said this too many times, but once more: As keyring-maint, we are not collecting samples of people showing valid-looking ID documents to others. This is one of the issues why we don't have long-queue key signing parties: Just checking the ID of a complete stranger is not real identity validation. My personal guideline is that I will sign your key if and only if I see your face and can think of your name, and the opposite way around. That is, if I have a decently-lasting memory of you. Being my brain so deffective in that sense, it is quite a high bar to pass. But it's also very flexible as well: I can count several dozens of people in this project who could set up a videoconference with me, read a key fingerprint with no further requisites, and have a successful exchange. Just as an example (as he answered to this mail), were Jonas to ever require a key signature from me, he is free to video-call me, even if he decided to burn all of his government-issued papers, as his face is worth more to me than any document. Of course, that gives me the flexibility to also decide to sign pseudonymous keys — I have several friends who are not OK with divulging their official identity. I often don't know their real names. That won't stop me from signing their keys, if their pseudonym's usage is long-term and consistent. I like my personal policy, but cannot enforce it on anybody. I expect us all DDs to be careful and responsible on what we sign. Define responsible as you prefer. Jason, as Jonas said: Where do you live? We are most interested in you getting your key back online. If you want, contact us directly to keyring-ma...@debian.org (or publicly here, if you are OK with it) and we can try to arrange for an in-person meeting between you and somebody else! signature.asc Description: Digital signature
Re: Keysigning via Video Conferencing
Hi Gunnar, I'm basically in Sydney Australia, however finding time to meet people is difficult these days, with work, a wife and two little kids. I live in Penrith NSW, and work in Granville NSW. I do travel up and down the east coast of Australia and around Sydney for work, buts its sporadic. If anyone living in the Sydney area wanted to meet up, I'd be all for it. Thanks. On Tue, 2016-06-21 at 22:57 -0500, Gunnar Wolf wrote: > Jason Thomas dijo [Mon, Jun 20, 2016 at 12:31:57PM +1000]: > > Hi all, > > > > I need to get my key signed, is anyone willing to work with me via > > video conferencing. > > > > I have uploaded my key to keyring.debian.org and I have also signed > > this message. > > > > I have a scan of my government issued drivers licence available. > > > > The medium you use to verify your counterpart's identity when > performing a signature is completely up to you; I could be perfectly > happy with cross-signing with $person via videoconferencing — But > what > we push, what we *really* expect each of us to do, is to actually > *ensure identity*. > > For some, ensuring identity is a matter of checking a > government-issued ID. In this case, Jason is providing a scan of such > an ID. Might I add, in case you take on his request: Are you familiar > with his country's drivers licenses? How hard are they to forge? How > hard would they be to digitally manipulate without other parties > noticing? If that satisfies you, please go ahead and sign. Of course, > Jason, same for you — Although it suffices for us to have your key > "reachable" from the strong set, we really prefer your key being part > of the strong set (that is, other keys being reachable from yours). > If > somebody signs your key, please try to sign theirs as well (if you > are > convinced of their identity). > > Now, I have said this too many times, but once more: As keyring- > maint, > we are not collecting samples of people showing valid-looking ID > documents to others. This is one of the issues why we don't have > long-queue key signing parties: Just checking the ID of a complete > stranger is not real identity validation. > > My personal guideline is that I will sign your key if and only if I > see your face and can think of your name, and the opposite way > around. That is, if I have a decently-lasting memory of you. Being my > brain so deffective in that sense, it is quite a high bar to pass. > But > it's also very flexible as well: I can count several dozens of people > in this project who could set up a videoconference with me, read a > key > fingerprint with no further requisites, and have a successful > exchange. > > Just as an example (as he answered to this mail), were Jonas to ever > require a key signature from me, he is free to video-call me, even if > he decided to burn all of his government-issued papers, as his face > is > worth more to me than any document. Of course, that gives me the > flexibility to also decide to sign pseudonymous keys — I have several > friends who are not OK with divulging their official identity. I > often > don't know their real names. That won't stop me from signing their > keys, if their pseudonym's usage is long-term and consistent. > > I like my personal policy, but cannot enforce it on anybody. I expect > us all DDs to be careful and responsible on what we sign. Define > responsible as you prefer. > > Jason, as Jonas said: Where do you live? We are most interested in > you > getting your key back online. If you want, contact us directly to > keyring-ma...@debian.org (or publicly here, if you are OK with it) > and > we can try to arrange for an in-person meeting between you and > somebody else! > > signature.asc Description: This is a digitally signed message part
Re: Bug#827843: ITP: xlogo -- XLogo is an interpreter for the Logo programming language, written in Java.
On Tue, Jun 21, 2016 at 06:18:09PM +0200, Wolf Bergenheim wrote: > * Package name: xlogo > * URL : http://xlogo.tuxfamily.org > Description : XLogo is an interpreter for the Logo programming > language, written in Java. This name conflicts with existing "xlogo", the thingy people use mostly to check whether their X forwarding works. -- An imaginary friend squared is a real enemy.
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
[adding gitlab folks in cc] On Saturday 11 June 2016 02:16 PM, Alexander Wirt wrote: > On Sat, 11 Jun 2016, Ole Streicher wrote: > >> Pirate Praveen writes: Debian needs feature X but it is already in the e.nterprise version. We make a patch and for commercial reasons it never gets merged (they already sell it in the enterprise version). Which means we will have to fork the software and keep those patches forever. Been there done that. For me, that isn't acceptable. I don't want another Nagios. >>> >>> I agree this is a legitimate concern. I have asked Gitlab Inc for their >>> policy on merge requests to Gitlab CE for features already in Gitlab EE. >>> Based on their reply, we can decide how to proceed. If their reply is >>> positive, I will ask them to make it public, and we can go ahead with a >>> debian.net instance of Gitlab. If their reply is negative, we can drop >>> gitlab and consider Pagure (second best option). >> >> We do patching as part of our daily packaging already: to replace (or >> circumvent) non-dfsg functionality, to integrate into our environment, >> and everything else that upstream is not willing or able to apply >> himself but is good in our opinion. Depending on the package, you may >> find huge patches for our packages >> >> I would not see why a missing functionality of gitlab would be different >> here. > Given my personal expericence with so called opencore software, I do. > > Alex > > Hi Alex, GitLab folks have indicated their interest to consider solving access problems for debian (possibly releasing relevant code as Free Software if we are serious about using gitlab). They would like to have a call with relevant admins (since you being git.debian.org maintainer, your presence would be essential, if we were to do such a call). Would you be open to such a call? Thanks Praveen signature.asc Description: OpenPGP digital signature
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, 22 Jun 2016, Pirate Praveen wrote: > [adding gitlab folks in cc] > > On Saturday 11 June 2016 02:16 PM, Alexander Wirt wrote: > > On Sat, 11 Jun 2016, Ole Streicher wrote: > > > >> Pirate Praveen writes: > Debian needs feature X but it is already in the e.nterprise version. We > make > a patch and for commercial reasons it never gets merged (they already > sell it > in the enterprise version). Which means we will have to fork the > software and > keep those patches forever. Been there done that. For me, that isn't > acceptable. > I don't want another Nagios. > >>> > >>> I agree this is a legitimate concern. I have asked Gitlab Inc for their > >>> policy on merge requests to Gitlab CE for features already in Gitlab EE. > >>> Based on their reply, we can decide how to proceed. If their reply is > >>> positive, I will ask them to make it public, and we can go ahead with a > >>> debian.net instance of Gitlab. If their reply is negative, we can drop > >>> gitlab and consider Pagure (second best option). > >> > >> We do patching as part of our daily packaging already: to replace (or > >> circumvent) non-dfsg functionality, to integrate into our environment, > >> and everything else that upstream is not willing or able to apply > >> himself but is good in our opinion. Depending on the package, you may > >> find huge patches for our packages > >> > >> I would not see why a missing functionality of gitlab would be different > >> here. > > Given my personal expericence with so called opencore software, I do. > > > > Alex > > > > > > Hi Alex, > > GitLab folks have indicated their interest to consider solving access > problems for debian (possibly releasing relevant code as Free Software > if we are serious about using gitlab). They would like to have a call > with relevant admins (since you being git.debian.org maintainer, your > presence would be essential, if we were to do such a call). Would you be > open to such a call? I really prefer async communication like mail. Alex signature.asc Description: PGP signature
