Re: trying to use wireless not from gnome... what's the incantation?
On Mon, 2016-05-23 at 08:28 +0200, Adam Borowski wrote:
> Using low-level tools can indeed be tricky, so while they're more
> powerful than anything NM or wicd can do, they're an overkill and a
> waste of learning time if what you want is regular use of a single
> interface.
I have a new laptop on which only Stretch worked - and then only
partly. Among the things that didn't work were wicd (kept on
reinitialising the interface every 10 seconds or so) and network-
manager (didn't recognise the interface at all). This initially caused
a lot of head scratching and wasted time because I blamed the drivers
of new hardware. But it worked 100% reliably when in desperation I
configured it manually.
If you are posting to debian-devel manual configuration should not be
hard for you. Ensure ifupdown and ifplugd are installed. Add this
into /etc/network/interfaces:
auto wifi_interface
iface wifi_interface inet dhcp
pre-up systemctl stop wpa_supplicant || :
post-down systemctl start wpa_supplicant || :
wpa-driver nl80211,wext,wired
wpa-conf/etc/wpa_supplicant/wpa_supplicant.conf
And add stanza's like this to /etc/wpa_supplicant/wpa_supplicant.conf
for each WiFi network you want to use:
network={
ssid="a-network-i-use"
psk="super-secret"
}
network={
ssid="another-network-i-use"
psk="another-secret"
}
Doing it like this drops the amount of code between you and the metal
by an order of magnitude. Reliability goes up accordingly. Day to day
usage is identical - it just works wherever you are, connecting you to
the local network at boot without you having to raise a finger. Ease
of configuration is a matter of taste - I happen to prefer to being
able to see all my wifi networks in a text editor, so I won't be using
wicd or network-manager for wifi again.
signature.asc
Description: This is a digitally signed message part
Bug#825332: ITP: webjars-locator -- Library to load WebJars transitive dependencies with RequireJS
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: webjars-locator Version : 0.30 Upstream Author : James Ward * URL : http://webjars.org * License : MIT Programming Lang: Java Description : Library to load WebJars transitive dependencies with RequireJS WebJars are client-side web libraries (e.g. jQuery & Bootstrap) packaged into JAR files. They allow one to: * Explicitly and easily manage the client-side dependencies in JVM-based web applications * Use JVM-based build tools (e.g. Maven, Gradle...) to download client-side dependencies * Know which client-side dependencies are used * Resolve transitive dependencies automatically and optionally load them via RequireJS The WebJars Locator library provides a means to load WebJars transitive dependencies with RequireJS. This library is a new dependency of libspring-java. It'll be maintained by the Java Team.
Re: trying to use wireless not from gnome... what's the incantation?
Am 26.05.2016 um 09:16 schrieb Russell Stuart: > partly. Among the things that didn't work were wicd (kept on > reinitialising the interface every 10 seconds or so) and network- > manager (didn't recognise the interface at all). This initially caused > a lot of head scratching and wasted time because I blamed the drivers > of new hardware. But it worked 100% reliably when in desperation I > configured it manually. That might very well be the driver which is at fault here. NM uses the modern nl80211 kernel interface by default to interact with wireless interfaces and maybe your driver has incomplete/broken nl80211 support. If you configured wpa_supplicant manually, it's possible that this used the old wext interface, which in your case worked better with your driver. It's hard to say though. For this we'd need proper debug logs to further investigate this. For testing purposes you can force NM to use wext via wifi-wext-only=true in NetworkManager.conf, fwiw. Regards, Michael -- 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
Re: How long does it take until DNS for .debian.net is reset (Was: Fwd: DDTSS down)
On Thu, May 26, 2016 at 11:46:21AM +0200, Andreas Tille wrote: >echo "ddtp in a 117.121.245.169" | gpg --clearsign | mail > chan...@db.debian.org > three days ago but neither got any response (I think there should be > some kind of automatic notification) nor is the new IP set in DNS. Hi Andreas, I'm not sure what mistake you did exactly, but if you send a wrongly formatted but correctly signed mail to chan...@db.debian.org, change@db.d.o (note the slightly different username) will mail you back an error. And if you mail a correctly formatted and signed it will send you back a success mail. I'm not sure you get a correct reply if you sign incorrectly or not at all. Bottomline: if you've done things right, you get a mail back immediatly. If you dont get a mail back, you have done something wrong. -- cheers, Holger signature.asc Description: Digital signature
Re: How long does it take until DNS for .debian.net is reset (Was: Fwd: DDTSS down)
sorry, I just send the reply to -devel instead of -qa… sorry for the confusion. -- cheers, Holger signature.asc Description: Digital signature
Re: trying to use wireless not from gnome... what's the incantation?
On Thu, 2016-05-26 at 05:26 +, darkestkhan wrote: [...] > It is worth remembering that network manager depends indirectly on > systemd - not all of us have systemd installed. And not all of us know > (or knew in this case) the invocation to bring up the wifi connection. It doesn't require systemd as pid 1. It does, I assume, depend on udev and/or systemd-logind. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: trying to use wireless not from gnome... what's the incantation?
On Thu, May 26, 2016 at 4:35 AM, Andrew Shadura wrote: > On 26 May 2016 at 09:16, Russell Stuart wrote: >> auto wifi_interface >> iface wifi_interface inet dhcp >> pre-up systemctl stop wpa_supplicant || : >> post-down systemctl start wpa_supplicant || : >> wpa-driver nl80211,wext,wired >> wpa-conf/etc/wpa_supplicant/wpa_supplicant.conf > > There's no need in any of this, ifupdown already supports this mode > without anything apart from wpa-conf. > > See /usr/share/doc/wpasupplicant/README.Debian.gz for more details. Ok, this approach does work if rfkill is added to the equation. I tried it originally and it didn't seem to. The problem is that my card boots up with rfkill activated, and ifup doesn't seem to know about this and reacts strangely. After boot, it ends up with the interface activated but not working such that a subsequent ifup fails, then ifdown succeeds, then ifup fails differently (when rfkill not used). Oddly, when an interactive ifup wlan0 fails, the interface doesn't end up partly configured: after turning on the radio, a subsequent ifup wlan0 succeeds. It took a while to sort this out. It seems to me that either: ifup should make sure to rfkill unblock wifi or the like, or ifup should fail and leave the interface fully unconfigured on boot Here's a log showing the current behavior: [bootup] $ su Password: root@debian:/home/bkerin# ping www.google.com ping: unknown host www.google.com root@debian:/home/bkerin# ifup wlan0 ifup: interface wlan0 already configured root@debian:/home/bkerin# ifdown wlan0 RTNETLINK answers: No such process Killed old client process Internet Systems Consortium DHCP Client 4.3.1 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/wlan0/a4:34:d9:c0:1f:f7 Sending on LPF/wlan0/a4:34:d9:c0:1f:f7 Sending on Socket/fallback DHCPRELEASE on wlan0 to 192.168.43.1 port 67 send_packet: Network is unreachable send_packet: please consult README file regarding broadcast address. dhclient.c:2331: Failed to send 300 byte long packet over fallback interface. root@debian:/home/bkerin# ifup wlan0 Internet Systems Consortium DHCP Client 4.3.1 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ RTNETLINK answers: Operation not possible due to RF-kill Listening on LPF/wlan0/a4:34:d9:c0:1f:f7 Sending on LPF/wlan0/a4:34:d9:c0:1f:f7 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 send_packet: Network is down dhclient.c:1966: Failed to send 300 byte long packet over wlan0 interface. receive_packet failed on wlan0: Network is down DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11 send_packet: Network is down dhclient.c:1966: Failed to send 300 byte long packet over wlan0 interface. DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 send_packet: Network is down dhclient.c:1966: Failed to send 300 byte long packet over wlan0 interface. DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 send_packet: Network is down dhclient.c:1966: Failed to send 300 byte long packet over wlan0 interface. DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17 send_packet: Network is down dhclient.c:1966: Failed to send 300 byte long packet over wlan0 interface. DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 2 send_packet: Network is down dhclient.c:1966: Failed to send 300 byte long packet over wlan0 interface. No DHCPOFFERS received. No working leases in persistent database - sleeping. RTNETLINK answers: Network is down run-parts: /etc/network/if-up.d/avahi-autoipd exited with return code 2 Failed to bring up wlan0. root@debian:/home/bkerin# rfkill unblock wifi root@debian:/home/bkerin# ifup wlan0 Internet Systems Consortium DHCP Client 4.3.1 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/wlan0/a4:34:d9:c0:1f:f7 Sending on LPF/wlan0/a4:34:d9:c0:1f:f7 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPOFFER from 192.168.43.1 DHCPACK from 192.168.43.1 bound to 192.168.43.103 -- renewal in 1698 seconds. root@debian:/home/bkerin# ping www.google.com PING www.google.com (216.58.194.164) 56(84) bytes of data. 64 bytes from sfo07s13-in-f4.1e100.net (216.58.194.164): icmp_seq=1 ttl=52 time=105 ms Britton
thoughts on systemd, network-manager, dbus, packagekit, gnome etc.
I realize I'm years late to the party arguing about this stuff , but I had a fine stable old debian laptop so none of it was relevant to me at the time. I honestly came to systemd willing to give it a shot. Hell I can even forgive them for making technical decision designed to serve political ends. I sure wouldn't know how to get sufficient agreement for what they're trying to do myself. I always disliked sysvinit/inetd, and I like a lot things in systemd. I'm going to skip the usual arguments about systemd not because they're wrong or irrelevant but because they're commonly known. My apologies if these other issues are also well-known. Besides those usual arguments, the things that bother me about the above stack of software are: * the relative opaqueness of the big-blob-of-C approach. When it doesn't work its not obvious where it's failing, and when it does work it's hard to tell why. Yes network-manager logs a lot, but that approach can't hope to compete with a script that you can read and maybe set -ex and easily find out what's going on. C is simply the wrong language for most of this stuff. There's no efficiency requirement or need to use C-only APIs. * The relationship between the layers is incestuous. In theory gnome is layered on top of dbus, with network-manager optional, and all of the above independent of systemd, but in practice this is doomed to not be the case. The people who use this stack mostly use all of it, and other approaches are relatively untested. The upstream developers are not only well aware of this situation, but seem perfectly fine with it. They have a record of assimilating dependent projects. * One of debian's major promises involves it's ability to carry forward config files across upgrades. In practice this was always an ambitious promise and could run into trouble for extensively modified configurations over large upgrades, but the situation with systemd is much worse. systemd makes no secret of it's desire to replace various daemons. They talk about /etc-free systems. What happens to debian's promise to attempt to carry forward configuration under these circumstances? I sure hope debian can somehow continue to support alternative setups. It looks to me like it's going to be tough. E.g. I have no idea how debian even handles the udev issue for sysvinit systems, and at the moment I can't afford to break a bunch of stuff finding out. debian should not sell itself short and imagine that this new stack is better than all the infrastructure it built up over the years for doing mostly the same stuff. Britton
Re: trying to use wireless not from gnome... what's the incantation?
On Thu, 2016-05-26 at 10:24 +0200, Michael Biebl wrote: > It's hard to say though. For this we'd need proper debug logs to > further investigate this. You shamed me into doing something about it. But now I test it, network-manager works. It's been 3 months and a similar number of kernels, so who knows what it was. Wicd still doesn't work. If the interface hasn't been initialised with ifupdown, it doesn't seem to realise the laptop has a wifi card. When it does know it has a Wifi card, it can't successfully connect. signature.asc Description: This is a digitally signed message part
Re: thoughts on systemd, network-manager, dbus, packagekit, gnome etc.
On Thu, 26 May 2016 at 12:54:55 -0800, Britton Kerin wrote: > I realize I'm years late to the party arguing about this stuff Sorry to be so blunt, but yes, you are. This is a technical mailing list for discussion of Debian development, and I don't think engaging in the discussion you seem to be looking for (again!) is going to make Debian any better. People who consider some or all of the components you've mentioned to be a net benefit to Debian are unlikely to change their minds based on what you've said; people who consider those components to be a net detriment are unlikely to change their minds either. Please can we pretend the rest of the thread has already happened, and move on? (I also think your message was factually incorrect in places, and I started to reply to that, but I'm not going to get into that because it really isn't the point.) > I sure hope debian can somehow continue to support alternative setups. Debian consists of a lot of volunteers who support different components. If you want a particular component or configuration to remain supported, that means someone, or a lot of someones - maybe including you - supporting it. Components that are a burden to the distribution will tend to get removed; components that are a net benefit to the distribution will tend to stay. If old technologies and designs were superseded as aggressively as you fear, I don't think Debian (1993) and its package build tools (dpkg, 1994) written in C (1972) and Perl (1987) would have much of a future :-) S
Bug#825459: ITP: protobuf-java-format -- Library to serialize protobuf messages to XML, JSON and HTML
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: protobuf-java-format Version : 1.2 Upstream Author : Eliran Bivas * URL : https://github.com/bivas/protobuf-java-format * License : BSD-3-clause Programming Lang: Java Description : Library to serialize protobuf messages to XML, JSON and HTML The protobuf-java-format library provide serialization and de-serialization of different formats based on Google's protobuf Message. Enables overriding the default (byte array) output to text based formats such as XML, JSON and HTML. This package is a dependency of libspring-java. It'll be maintained by the Java Team.
Re: trying to use wireless not from gnome... what's the incantation?
On Thu, 2016-05-26 at 12:15 -0800, Britton Kerin wrote: > On Thu, May 26, 2016 at 4:35 AM, Andrew Shadura > wrote: > > There's no need in any of this, ifupdown already supports this mode > > without anything apart from wpa-conf. > > > > See /usr/share/doc/wpasupplicant/README.Debian.gz for more detals. It does say that. Maybe on Debian stable it even works. However on my laptop something was starting wpa_supplicant as a service at boot, and I had to stop it in order to make it work from ifupdown. > Ok, this approach does work if rfkill is added to the equation. I > tried it originally and it didn't seem to. The problem is that my > card boots up with rfkill activated, and ifup doesn't seem to know > about this and reacts strangely. I had the same problem on a machine running hostapd. I thought it was very odd the system booted with rfkill softly enabled. Unlike you I didn't believe the card or the driver would do something so daft, so I went hunting for the culprit. It turned out NetworkManager soft turning rfkill on at boot, even though the interface was listed in /etc/network/interfaces. The ifupdown stanza for that interface is now (somewhat elided): auto wlan0 iface wlan0 inet manual pre-up nmcli radio wifi off || : pre-up rfkill unblock wifi || : hostapd /etc/hostapd/hostapd.conf Both the nmcli and rfkill lines are absolutely required, and this is on Jessie. They may only be two extra lines, but it took me hours to chase down what was happening so I could get hostapd running and while giving the user pretty GUI interface for the other networks. Given the NetworkManager.conf is as appears below, it seems to be happing despite what the doco says. It is this sort of crap that gives these GUI interfaces a bad name among sysadmins. [main] plugins=ifupdown,keyfile [ifupdown] managed=false signature.asc Description: This is a digitally signed message part
Work-needing packages report for May 27, 2016
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: 717 (new: 4) Total number of packages offered up for adoption: 178 (new: 0) Total number of packages requested help for: 48 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: dhelp (#824977), orphaned 4 days ago Description: Read all documentation with a WWW browser. Installations reported by Popcon: 569 net-luminis-build-plugin (#824824), orphaned 6 days ago Installations reported by Popcon: 6 qmpdclient (#825057), orphaned 3 days ago Installations reported by Popcon: 150 refdb (#824822), orphaned 6 days ago Reverse Depends: refdb-www Installations reported by Popcon: 13 713 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 178 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: athcool (#278442), requested 4230 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 27 awstats (#755797), requested 673 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4178 balsa (#642906), requested 1705 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 660 cardstories (#624100), requested 1858 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 4 courier (#823807), requested 17 days ago Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-imap-ssl courier-ldap courier-mlm courier-mta courier-mta-ssl courier-pcp courier-pop (7 more omitted) Installations reported by Popcon: 2294 cups (#532097), requested 2546 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (63 more omitted) Installations reported by Popcon: 169476 cyrus-sasl2 (#799864), requested 246 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (126 more omitted) Installations reported by Popcon: 190886 developers-reference (#759995), requested 635 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 19150 devscripts (#800413), requested 240 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (28 more omitted) Installations reported by Popcon: 12998 ejabberd (#767874), requested 570 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-mam-mnesia ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-rest (4 more omitted) Installations reported by Popcon: 771 fbcat (#565156), requested 2325 days ago Description: framebuffer grabber Installations reported by Popcon: 209 fgetty (#823061), requested 26 days ago Description: console-only getty & login (issue with nis) Installations reported by Popcon: 2128 freeipmi (#628062), requested 1827 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: conman freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev (7 more omitted) Installations reported by Popcon: 6415 freerdp (#799759), requested 247 days ago Description: RDP client for Windows Terminal Services (X11 client) Reverse Depends: freerdp-x11 freerdp-x11-dbg libfreerdp-cache1.1 libfreerdp-client1.1 libfreerdp-codec1.1 libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1 l
Bug#825469: ITP: libtask-kensho-perl -- metapackage providing recommended modules for Enlightened Perl development
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtask-kensho-perl Version : 0.38 Upstream Author : Chris Prather * URL : https://metacpan.org/release/Task-Kensho * License : Artistic or GPL-1+ Programming Lang: Perl Description : metapackage providing recommended modules for Enlightened Perl development Task::Kensho is a list of recommended modules for Enlightened Perl development. The list is maintained by the Enlightened Perl Organisation. Perl modules that are suggested by Task::Kensho are grouped into several logical categories. Modules are chosen from various top 100 most-used Perl modules lists and from discussions with various subject matter experts in the Perl Community. This metapackage depends on all of the individual libtask-kensho-* task metapackages, but one can install these individually if preferred. The package will be maintained under the umbrella of the Debian Perl Group.
Bug#825470: ITP: basez -- base 16/32/64 encode/decode data to standard output
Package: wnpp Severity: wishlist Owner: Milan Kupcevic * Package name: basez Version : 1.0.1 Upstream Author : Milan Kupcevic * URL : http://www.quarkline.net/basez/ * License : GPL Programming Lang: C Description : base 16/32/64 encode/decode data to standard output BaseZ encodes/decodes base16, base32, base32hex, base64 or base64url data stream per RFC 4648; MIME base64 Content-Transfer-Encoding per RFC 2045; or PEM Printable Encoding per RFC 1421
Re: Vcs-* and shared repos
Hi Stefano, On 25 May 2016 at 17:09, Stefano Zacchiroli wrote: > I'm convinced we will need at some point to document VCS packaging > layouts in a way that allow tools to use that information > programmatically. But right now that information will not be actionable, > whereas the subdirectory already is (for debcheckout and friends). > > By also considering the fact that the "-d DIR" solution does not prevent > to add a "-l" in the future, I think minimality wins here (hence my > "Yay" to your proposal in separate mail). YMMV. What worries me is that some people may mistook those options as arguments to "git clone" (something I already faced and argued against on "debian-mentors"[1]). In that case "-b" is even a valid option for it, but "-d" doesn't exists and "-l" (the same as "--local") does a completely different thing (saves disk space when doing local copies). I can't blame them, as when you see a Git URL the first thing that pops on your head is how to clone it. If this were a pool, I would follow Raphael Hertzog's path and votes for "changing nothing". Regards, Tiago. [1]: https://lists.debian.org/debian-mentors/2016/04/msg00172.html -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
