Re: Vcs-* and shared repos
On Wed, May 25, 2016 at 08:25:09AM +0200, Stefano Zacchiroli wrote: > On Tue, May 24, 2016 at 11:24:43PM +0200, Iustin Pop wrote: > > A potential syntax for the Vcs-* fields would be: > > > > Vcs-Git: https://anonscm.debian.org/git/pkg-haskell/DHG_packages.git/ p/ghc > > I think something like this, or with the equivalent expressivity, would > be useful and welcome, yes. +1 > this point, because I don't think we're ready for the layout bikeshed. About bikeshedding: Power to those who update `debcheckout` and `vcswatch` Groeten Geert Stappers -- Leven en laten leven
Re: Vcs-* and shared repos
On Tue, May 24, 2016 at 11:24:43PM +0200, Iustin Pop wrote: > A potential syntax for the Vcs-* fields would be: > > Vcs-Git: https://anonscm.debian.org/git/pkg-haskell/DHG_packages.git/ p/ghc I think something like this, or with the equivalent expressivity, would be useful and welcome, yes. I just wonder whether we should also take the chance of improving the spec in a way that will allow, down the line, to automatically find the actual packaging code also in other, more complex situations. Specifying a branch is the first thing that comes to my mind. But we have seen in the past that it might also be useful to be able to specify the given layout of the Git repository (i.e., is it a debian/ only, is it split debian/upstream, is it merged debian/upstream, etc). All this considering, here are a few options: 1) URL [DIR] <- what you suggested 2) URL [dir=DIR] where "dir" is an actual string, in keyword-argument style, that makes it explicit what the extra optional argument means. This would allow in the future to have other extra arguments without creating ambiguity. This would allow something like the following: 3) URL [dir=DIR] [branch=BRANCH] [layout=LAYOUT] I really worry that (1) might be something too simplistic that we regret in the future. So (2) might be more wise. (3) is probably overkill at this point, because I don't think we're ready for the layout bikeshed. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Vcs-* and shared repos
Hi all, The Debian Haskell team has migrated a while back from per-package repositories to a single repository which contains the packaging (only debian/) for the vast majority of packages (https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/). This makes sense for us since the packaging is uniform enough that we can do mass-changes to packages. Now, this presents a small problem: Vcs-*, and more precisely Vcs-Git, is supposed to point to a repository which represents only the given package. Vcs-Git has support for branches, but not for subpaths within the repository. This breaks a few (minor) workflows, e.g. vcswatch, so I wonder if it makes sense to extend the policy to support also location within the repository. Maybe other VCSes support this natively by not pointing directly at the repository root, but at least git doesn't. Such a change would touch, for example: - vcswatch which wouldn't look at hardcoded /debian/changelog and /changelog - debcheckout which could say "cd repo/path" after the checkout A potential syntax for the Vcs-* fields would be: Vcs-Git: https://anonscm.debian.org/git/pkg-haskell/DHG_packages.git/ p/ghc or with branch: Vcs-Git: https://anonscm.debian.org/git/pkg-haskell/DHG_packages.git/ -b experimental p/ghc And the associated policy paragraph would now be: "In the case of Git, the value consists of a URL, optionally followed by the word -b and the name of a branch in the indicated repository, following the syntax of the git clone command, and optionally followed by a path specification. If no branch is specified, the packaging should be on the default branch. The optional path name after the branch specification defines where in a (shared) repository the sources for this particular package live." Thoughts? regards, iustin signature.asc Description: PGP signature
Re: trying to use wireless not from gnome... what's the incantation?
On Mon, May 23, 2016 at 2:35 PM, Nikolaus Rath wrote: > On May 22 2016, Britton Kerin wrote: >> Got a new laptop after 10 years of excellent stable ancient debian, >> and my wireless works from gnome, and only from gnome. Unfortunately >> I find that gnome3 is not for me. I've been trying dwm. > > What trouble did you have? Network manager works perfectly well for me > without using Gnome as my desktop environment. It sometimes sor of works under nmcli, but it doesn't behave the same as under gnome. For example trying to bring a connection up with the radio disabled fails completely differently: Under gnome: $ nmcli networking off $ nmcli general status STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN asleep none enabled enabled enabled disabled $ nmcli radio wifi off $ nmcli general status STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN asleep none enabled enabled enabled disabled $ # So with networking off radio shutdown command is silently ignored. Lucky planes don't really care $ nmcli networking on $ nmcli general status STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN connected full enabled enabled enabled disabled $ nmcli radio wifi off $ nmcli general status STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN disconnected none enabled disabled enabled disabled $ nmcli connection up "MotoG3 9820" (process:6447): libnm-glib-WARNING **: async_got_type: could not read properties for /org/freedesktop/NetworkManager/ActiveConnection/3: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist Error: Connection activation failed: Creating object for path '/org/freedesktop/NetworkManager/ActiveConnection/3' failed in libnm-glib. 4 $ If I run dbus-monitor while trying that connection up command it shows a message: signal sender=:1.34 -> dest=(null destination) serial=63 path=/org/gnome/zeitgeist/storagemonitor; interface=org.gnome.zeitgeist.StorageMonitor; member=StorageUnavailable string "net" signal sender=:1.34 -> dest=(null destination) serial=64 path=/org/gnome/zeitgeist/storagemonitor; interface=org.gnome.zeitgeist.StorageMonitor; member=StorageUnavailable string "net" Under my dwm .xsession: # All the same prep commands and responsess as above up to this point: $ nmcli connection up "MotoG3 9820" (process:8697): libnm-glib-WARNING **: async_got_type: could not read properties for /org/freedesktop/NetworkManager/ActiveConnection/10: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist (process:8697): libnm-glib-WARNING **: async_got_type: could not read properties for /org/freedesktop/NetworkManager/ActiveConnection/10: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist (process:8697): libnm-glib-WARNING **: async_got_type: could not read properties for /org/freedesktop/NetworkManager/ActiveConnection/10: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist Error: Timeout 90 sec expired. Nothing so helpful as an indication of what timed out, but I suspect it's dbus-related. I've also had it hang after bringing a connection up (which does work if the radio is correctly enabled). It took me a while to realize the the connection was working and the hang happened later. I don't know exactly how to reproduce that at the moment though. Running dbus-monitor during the connect command under dwm shows no messages whatsoever. A dbus-launch command is being performed on my behalf by whatever code is responsible for launching my .xsession from the gnome-ish login screen: $ ps ax | grep dbus-launch | grep xsession 8298 ?S 0:00 /usr/bin/dbus-launch --exit-with-session /bin/bash /home/bkerin/.xsession $ Once one of these failed connection attempts has been made, /var/log/syslog gets filled with message like this: May 24 11:01:59 debian NetworkManager[1962]: (NetworkManager:1962): NetworkManager-wifi-CRITICAL **: scanning_allowed: assertion 'priv->sup_iface != NULL' failed May 24 11:02:02 debian NetworkManager[1962]: (NetworkManager:1962): NetworkManager-wifi-CRITICAL **: scanning_allowed: assertion 'priv->sup_iface != NULL' failed But this happens for both gnome and my dwm .xsession. Bringing the connection up with nmcli sometimes work but othertimes I get stuff like this: $ nmcli connection up dlink_223_dome_rd Error: Timeout 90 sec expired. 3 $ $ nmcli connection up dlink_223_dome_rd Error: Connection activation failed. 4 $ nmcli connection up dlink_223_dome_rd Error: Connection activation failed. 4 $ nmcli connection up dlink_223_dome_rd Error: Connection activation failed: Creating object for path '/or
Re: Bug#824884: netbase: should not recommend ifupdown
On Tue, May 24, 2016, at 13:03, Ansgar Burchardt wrote: > On Tue, 2016-05-24 at 11:43 -0300, Henrique de Moraes Holschuh wrote: > > On Tue, May 24, 2016, at 10:01, Simon McVittie wrote: > > > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh > > > wrote: > > > > Whatever we do, we absolutely must bring up a fully configured > > > > loopback > > > > interface by default. > > > Happily, our default init system already does that. > > We need to ensure any non-default ones also do that before we drop > > ifupdown from "recommends", because ifupdown + default > > /etc/network/interfaces is the fallback that ensures the loopback > > will be up. > > We are not talking about removing "ifupdown" from the default > installation which includes all "Priority: important" packages (which > happens to include both netbase and ifupdown). > > The only installations affected are debootstrap's "minbase" and > "buildd" variants: these only install "Priority: required" packages and > select extra packages (apt and, for buildd, build-essential). These > would no longer pull in "ifupdown" if "netbase" is installed. As far as I am concerned, ensuring the "master namespace" loopback is configured and up is actually required behavior and it should be enforced by something stronger than "priority important" packages being installed. Systemd got this right. So, yes, I do think it would be best were it done by something in the initscripts package, since systemd is already doing it by itself as well. Also, it is "probably not ok" (as in I fully expect we will end up with people filling severity critical bugs should we do otherwise) to allow ifupdown (and likely netbase) to get uninstalled anywhere it was automatically installed, unless we ensure something else will take up their job. This is not even related to configuring the loopback, but rather to /etc/network/interfaces processing, as well as /etc/services. People sometimes trigger firewall setup and other supplementary network-related setup using the loopback entry in /etc/network/interfaces, because it is guaranteed to happen at the exactly the right time during boot and fully serialized with other interface bring-up. And people do configure network services using names from /etc/services instead of hard-coding port numbers (sometimes by not specifying a port number in the first place, and the service/daemon/application using the IANA-assigned service *name* in that case to look up the port number). That said, I don't expect this to be a real problem right now, but it is something to keep in mind. Obviously, it is not going to be an issue for new installs, but it could be for the next stable upgrade. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh
Re: Bug#824884: netbase: should not recommend ifupdown
On Tue, 2016-05-24 at 11:43 -0300, Henrique de Moraes Holschuh wrote: > On Tue, May 24, 2016, at 10:01, Simon McVittie wrote: > > > > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh > > wrote: > > > > > > Whatever we do, we absolutely must bring up a fully configured > > > loopback > > > interface by default. > > Happily, our default init system already does that. > We need to ensure any non-default ones also do that before we drop > ifupdown from "recommends", because ifupdown + default > /etc/network/interfaces is the fallback that ensures the loopback > will be up. We are not talking about removing "ifupdown" from the default installation which includes all "Priority: important" packages (which happens to include both netbase and ifupdown). The only installations affected are debootstrap's "minbase" and "buildd" variants: these only install "Priority: required" packages and select extra packages (apt and, for buildd, build-essential). These would no longer pull in "ifupdown" if "netbase" is installed. Ansgar
Re: Bug#781984: ITP: libnacl -- ctypes wrapper for libsodium
On Mon, May 23, 2016 at 11:03:37AM +0200, David Douard wrote: > On 05/23/2016 10:49 AM, Colin Watson wrote: > > I've pushed preliminary packaging here: > > > > https://anonscm.debian.org/cgit/collab-maint/python-libnacl.git > > > > David, if I don't hear anything in the next week, I plan to take over > > this ITP and upload to NEW. Of course I'd welcome co-maintainers, as > > suggested by the collab-maint location. > > Hi, > > very sorry for my lack of feedback. Please be my guest and take over the ITP, > there is no way I can find time to make this happen... Sorry, Thanks. I've gone ahead and uploaded this, then. -- Colin Watson [cjwat...@debian.org]
Re: Bug#824884: netbase: should not recommend ifupdown
Simon McVittie writes ("Re: Bug#824884: netbase: should not recommend
ifupdown"):
> On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh wrote:
> > Whatever we do, we absolutely must bring up a fully configured loopback
> > interface by default.
>
> Happily, our default init system already does that.
>
> systemd's authors see the lo device as being less like networking and
> more like part of the "API" of a Linux machine, so pid 1 sets it up
> during early boot, rather than leaving it as the responsibility of
> whichever of ifupdown, NetworkManager, systemd-networkd etc. you're
> using. That seems like a reasonable approach to me.
If we take this approach, the recommendation that is being removed
from netbase should perhaps be moved to sysvinit, or something ?
Ian.
Re: Bug#824884: netbase: should not recommend ifupdown
On Tue, May 24, 2016, at 10:01, Simon McVittie wrote: > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh wrote: > > Whatever we do, we absolutely must bring up a fully configured loopback > > interface by default. > > Happily, our default init system already does that. We need to ensure any non-default ones also do that before we drop ifupdown from "recommends", because ifupdown + default /etc/network/interfaces is the fallback that ensures the loopback will be up. Hopefully we already do that, but it doesn't look like it from a fast look at a jessie workstation. > systemd's authors see the lo device as being less like networking and > more like part of the "API" of a Linux machine, so pid 1 sets it up Which actually makes a lot of sense, as it is in fact a critical networking component on any modern Unix userland. Drop/bring down the loopback, and the world breaks in surprising ways, be it in Linux, the BSDs, or Solaris. > using. That seems like a reasonable approach to me. It is reasonable, yes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh
Re: Bug#824884: netbase: should not recommend ifupdown
On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh wrote: > Whatever we do, we absolutely must bring up a fully configured loopback > interface by default. Happily, our default init system already does that. systemd's authors see the lo device as being less like networking and more like part of the "API" of a Linux machine, so pid 1 sets it up during early boot, rather than leaving it as the responsibility of whichever of ifupdown, NetworkManager, systemd-networkd etc. you're using. That seems like a reasonable approach to me. S
Re: trying to use wireless not from gnome... what's the incantation?
Adam Borowski writes ("Re: trying to use wireless not from gnome... what's the
incantation?"):
> But it's not without problems. The one Britton met is that NM's interface
> is closely married to Gnome. Yes, you can use nm-cli but it's nowhere near
> pretty, so on a laptop or a phone you want a GUI. Wicd's GUI works, NM's
> does not (at least currently or without extra messing).
I'm using network-manager with something that would be xfce if I ran
more of xfce, but is probably best described as a pre-desktop setup.
My window manager is vtwm. The nm-applet sits happily in trayer, and
everything functions pretty much as I expect.
I'm happy with it. (Although I did find a bug in the WPA2 enterprise
passphrase management which I mean to report at some point...)
Although, I am running systemd-logind and cgmanager because lightdm
gave them to me, so maybe that's why n-m works for me. I haven't
found that systemd-logind and cgmanager cause any trouble so I haven't
bothered to avoid them. (I'm running sysvinit.)
> The second is, NM interferes with any complex setup. In newer versions, you
> can now semi-reliable tell it to stay away from your interfaces, but then,
> if you disable it on all interfaces, why do you even have it installed?
I have found that n-m is happy to leave alone my own VPN and my own
pppd 3G setup (which I run sometimes in parallel with wifi). I had to
deinstall modemmanager because it interfered with the modem, even if
I had 3G support turned off in the nm-applet menu.[1]
> But, how is mentioning an alternative and/or recommending to try one FUD?
On the other hand, I am very happy that wicd exists. If
network-manager annoyed me somehow I'm sure I would try wicd.
Ian.
[1] #683839 is tangentially related, but not really relevant, since if
modemmanager had a whitelist rather than a blacklist, it would still
have tried to fiddle with my modem. It appears that #683839 is being
fixed upstream and hopefully stretch has these changes...
Re: Bug#824884: netbase: should not recommend ifupdown
On Mon, May 23, 2016, at 22:54, Simon Richter wrote: > On 21.05.2016 21:06, Michael Biebl wrote: > > Personally I don't see a compelling reason why netbase should pull in a > > specific network configuration system. > > So +1 for dropping the Recommends. > > It should probably pull in at least one -- ideally listing a sensible > default for Desktop installations as the first alternative. Whatever we do, we absolutely must bring up a fully configured loopback interface by default. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh
Bug#825183: ITP: gobgp -- BGP implemented in the Go Programming Language
Package: wnpp Severity: wishlist Owner: Vincent Bernat * Package name: gobgp Version : 1.7-1 * URL : https://github.com/osrg/gobgp * License : Apache-2.0 Programming Lang: Go Description : BGP implemented in the Go Programming Language GoBGP is an open source BGP implementation designed from scratch for modern environment and implemented in Go. It is designed to exploit multicore processors and can be easily integrated with other software through an RPC API.
Bug#825174: ITP: dq -- DNS/DNSCurve query tool
Package: wnpp Severity: wishlist Owner: Jan Mojzis * Package name: dq Version : 20160523 Upstream Author : Jan Mojzis * URL : https://mojzis.com/software/dq/ * License : public domain Programming Lang: C Description : DNS/DNSCurve query tool The dq package provides software for DNS/DNSCurve. This software is derived from djbdns, adds DNSCurve protection and support for IPv6. Contains 2 programs dq and dqcache: Dq is commandline tool similar to dnsq, dnsqr from djbdns. Is used to query DNS/DNSCurve server for specific type of records about a given domain name. Dqcache is recursive DNS/DNSCurve server derived from dnscache. --- This software implements DNSCurve (https://dnscurve.org/). Adds strong end-to-end encryption into DNS comunication and protect DNS packets against: - espionage - packet corruption - sabotage I'm using this software and I'm going to maintain using collab-maint. I need sponsor.
Bug#825164: ITP: golang-github-eapache-channels -- Golang channel helpers and special types
Package: wnpp Severity: wishlist Owner: Vincent Bernat * Package name: golang-github-eapache-channels Version : 1.1.0 Upstream Author : Evan Huus * URL : https://github.com/eapache/channels * License : Expat Programming Lang: Go Description : Golang channel helpers and special types A collection of helper functions and special types for working with and extending Go's existing channels. It is a dependency of gobgp that I would like to package.
