Re: AucTeX
On 7 Jan 1998, Davide G. M. Salvetti wrote: > AucTeX is listed as orphaned in wnpp; I'm willing to take over its > maintenance if nobody objects. I think this might be because teTeX has now replaced AucTeX as the Debian TeX/LaTeX distribution of choice. Of course TeX/LaTeX is so darn complicated I'm not really sure about this. Btw, if you have ever managed to make dvi files with ps images print right through magicfilter, I would love to hear how you did it. > > I'll be able to ship release 9.8i --- the latest one, I think --- in a few > days; I guess I'm able to fix all outstanding bugs I am aware of. > > I've a bunch of questions about this package which may well be just > newbie's questions, so I'm carbon copying to debian-mentors as well: > please, let's talk there about this if it isn't appropriate to > debian-devel. > > Questions: > -- > > 1) AucTeX has many .el's which should be shipped byte-compiled: should I > compile them with some specific Emacs flavor or doesn't it matter which > Emacs I'll use? (Please consider that, AFAIK, XEmacs comes with its own > AucTeX, so AucTeX should probably care only about GNU/Emacs; I'm not sure, > about that, though, mainly 'cause I don't use XEmacs :-).) > > 2) Should I remove byte-compiled source files in the binary package in > order to minimize its size? (It's a matter of some 600k; current AucTeX > package behaves this way.) > > 3) Current AucTeX package puts its data (.elc's) in /usr/lib/emacs/common; > should I put them in /usr/share/emacs/whatever_is_more_appropriate or > something else instead? (Please, consider FHS and FSSTND, and the fact > many packages already put stuff in /usr/share.) > > 4) AucTeX needs to periodically scan (La)TeX style files to keep itself in > touch with what one has installed on his machine; it does this by > cron.weekly. Current AucTeX package puts resulting files under /usr > (precisely just where it puts its data: /usr/lib/emacs/common); I believe > I should put things under /var, instead: any comments, please? > > 5) Current AucTeX package puts its configuration files directly under > /etc/elisp: is this still good behavior? > > 6) Current AucTeX package asks specific questions to the user in preinst > (stead of postinst) under certain conditions (namely if the user has > already installed some custom AucTeX version, or if he's upgrading from > really old package versions): I think its really the right place to ask > that and it does not go against policy (not all user are asked these > questions, just the ones who have conflicting software installed), but I'd > like to have some feedback from someone more experienced than me. > (Obviously all of the other general questions that are necessary to ask are > asked in postinst.) > > Waiting for comments, > > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: AucTeX
Your right about AucTeX, heck I've used it many times now. We did just switch LaTeX distributions though didn't we? > > Btw, if you have ever managed > > to make dvi files with ps images print right through magicfilter, I would > > love to hear how you did it. > > Is there really a ps2dvi program? Or do you mean the other way round ? dvips is invoked by magic filter, but the new LaTeX includes standard packages for including ps graphics. The .dvi docs for the graphics package say some additional commands (besides including the graphics package) may be needed to tell LaTeX what driver you are using (dvips in this case) since colors and graphics are really implemented there. Magicfilter has a feature called fpipe which the magicfilter docs state as being useful for 'programs which require seekable input, such as dvips, or which need to do multiple passes over an input file, such as grog'. I have once read something in the Linux Journal about using multiple passes to get embedded ps images to print right. I'll have to dig that up again, because for me the the images get left out, while all the text (including captions) appears. The pictures appear when previewing with xdvi though. What goes on exactly I do not know. > Marcus > > -- > "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ > Marcus Brinkmann http://www.debian.orgmaster.debian.org > [EMAIL PROTECTED]for public PGP Key > http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 Britton -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: NSA's Secure Linux Distribution
Pardon my paranoia, but even if it was worth making all the changes they are talking about (which are pretty extensive), I'd want to see anything coming from the NSA audited carefully before being included. Britton Kerin __ GNU GPL: "The Source will be with you... always." On Fri, 22 Dec 2000, Jacob Kuntz wrote: > from the secret journal of Brent Fulgham ([EMAIL PROTECTED]): > > No doubt most of you have seen the NSA's secure linux posting > > on Slashdot this morning. > > > > Looking at: > > http://www.nsa.gov/selinux/docs.html > > > > there appears to be several utilities that have been updated > > to provide enhanced security. > > > > Should we be merging these patches into Debian, assuming they > > appear to be compatible with our policy, etc.? > > > > unless we have a policy against security, it should be fine. :) it's all > gpl. > > -- > jacob kuntz > [EMAIL PROTECTED] > underworld.net/~jake
Re: NSA's Secure Linux Distribution
On Fri, 22 Dec 2000, Jacob Kuntz wrote: > from the secret journal of Britton ([EMAIL PROTECTED]): > > > > Pardon my paranoia, but even if it was worth making all the changes they > > are talking about (which are pretty extensive), I'd want to see anything > > coming from the NSA audited carefully before being included. > > > > Britton Kerin > > you're pardoned. i'm sure we're all a little wary of No Such Agency right > now, with carnivore and all. > > but what fact are these fears based in? would the nsa really plop a backdoor It wouldn't be paranoia if it had a basis in fact :) > in an opensource project, hoping it missed and accepted with the rest of the > code? i doubt it. their whole (advertised) motive was to protect against the > possibility of Trusted (AIX|Solaris|PalmOS|whatever closed os) going belly > up. Agreed. But past things like the weird unexplained DES s-boxes show that NSA is at least not afraid of doing things that are blatantly suspicious. And a lot of insiders there have the attitude that no one outside a project ever really looks closely enough at things to detect problems unless something is noticably broken. With Linux and open source that assumption is probably more wrong than ever before, but still with a grain of truth in it. > of course i plan on running this monster on a throwaway machine before i > make form any real opinions. Good thought. I guess if it seems to work we could offer an alternate kernel package, and perhaps one huge package with all their patched utilities or something? Trouble is a lot of them are kind of buried in other debian packages and would not be easy to substitute for. > jacob kuntz > [EMAIL PROTECTED] > underworld.net/~jake Britton
unsubscribe
__ GNU GPL: "The Source will be with you... always." Britton Kerin
Re: plagiarism of reiserfs by Debian
Keep in mind you're talking to a bunch of people who are amoung the staunchest free software advocates around. Unlike you, most of them make $0 for all their contributions. Your implication that we're somehow profiting from the removal of credits is ludicrous. In any case, there is already a widely accepted defacto standard for credits in software circles, much as their is in the academic press. Try sending your next paper off with the condition that it be pulished only if the journal prints the names of all the contributors in really big letters together with a solicitation for money all on a page of its own. Well maybe if you were Einstein they would publish it. But ReiserFS is a long way from being a technical necessity. In fact its got a reputation for causing problems. Noisy licenses (and noisy arguments about noisy licenses) certainly benefit you; their usefulness to the community is questionable. Britton Kerin __ GNU GPL: "The Source will be with you... always." Britton Kerin On Mon, 21 Apr 2003, Hans Reiser wrote: > It is really a question of, do you respect the authors? > > Stallman never imagined that anyone in the free software business would > be other than a gentleman. Then the OS rather than just the kernel got > named Linux by those who found his politics inconvenient to their > business, and the k got dropped from all the kde utilities by persons > not the authors of them, and it is a lot easier to imagine that > presumptuous persons who are not gentlemen would take it upon themselves > to remove credits because they find it inconvenient that the authors be > given the attention and notice rather than the distros. > > Feel free to make the credits more CPU efficient, reformat them to fit a > screen, animate them, anything that adheres to the academic attribution > spirit of respecting those who contributed years of their lives at the > cost of substantial reductions in their lifetime incomes so that users > (I don't care in the least about distros) could be free to modify the > code, and the poor able to afford the same information infrastructure as > all the rest of us. > > If you want to add attributions (perhaps mentioning the inventors of > balanced tree algorithms, etc.), or add a statement that Debian feels > the listed persons didn't deserve the credit and somebody else did, I > will respect any honest endeavor in that regard (and maybe even use the > improvements in the crediting in what we distribute on our website). > Simple deletion is hard to respect though. > > You'll note that the changes don't significantly affect me (as long as > it is called ReiserFS I am getting at least my share of credit). It > mostly affects all persons other than me who aren't getting their fair > share of credit as it is. > > Academia, while it respects the right to modify knowledge, has never > respected failures to attribute, and hopefully most of you do not either once > it is brought to your attention. > > Now, another person has suggested that this was due to an error rather > than deliberate action. I would be happy to apologize if this is the > case. I am not sure it is. > > Please inform me whether Debian respects the authors of free software, > as much as Stallman naively but understandably imagined everyone would > without any need for anything to be said about it. > > I wish Stallman would hurry it up with GPL V3. He probably wishes > people were gentlemen enough that it would not be needed. He does not > spend much time with marketeers wearing suits and counting brand > presence in dollars I think, sigh. I really did not expect this from > Debian of all distros You should not imitate RedHat in this. > > -- > Hans >
reactivating my debian developer account
I would like to reactivate my debian developer account. Ive been MIA for a while unfortunately, but have now rearranged my life so I have time to program for fun again. Is there a standard procedure for doing this that someone can point me to? Thanks, Britton Kerin -- Britton Kerin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
On Thu, 12 Jan 2006 14:23:31 +0100, "Thomas Viehmann" <[EMAIL PROTECTED]> said: > Hi, > > first of all, thanks for taking the initiative I think the matter is too > important to be left alone just for avoiding to step on anyones toes. > > Anthony Towns wrote: > > Random ideas for negative consequences might include forced > > orphaning by overriding maintainer fields to debian-qa, removal of > Maybe this should not only be limited to packages with RC bugs... For a > lot of packages with inactive maintainers, it might be best to not > release them in etch. Unlikely in general at least. A lot of buggy packages work and are being used by people, so dumping them outright is probably not going to work. What we might try is making the BTS info even more accessible by somehow integrating it with synaptic or dpkg. The BTS record is one of the most important peices of information about a package and isn't available for browing directly from synaptic. At some point we're also going to have to face the fact that the current package-the-world-then-fix-every-rc-bug-in-it approach doesn't scale arbitrarily. With the current definition of RC bugs (including security holes, data loss, and breakage of unrelated packages), we will eventually be in a situation where we have packages that we don't have time to fix, but aren't broken enough that the few users who have been using them for years will be best served by our dumping the packages. If we had a way to flag such packages 'deprecated' or 'very-buggy-your-on-your-own-if-you-try-this-one' (obviously we'd have to think of some better names :) it would prevent new users from being misled into trying the package without inconviencing existing users. Britton > > Kind regards > > T. > -- > Thomas Viehmann, http://thomas.viehmann.net/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- Britton Kerin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
returning emeritus developer, no response from [EMAIL PROTECTED]
I send an email to [EMAIL PROTECTED] over a week ago, as described here: http://lists.debian.org/debian-devel-announce/2005/02/msg3.html so far not even a response telling me I'm in a queue. Is the procedure described above still the right one? Thanks, Britton -- Britton Kerin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
helix player package for debian?
is anyone working on packaging helix player? I'd like to see RealPlayer packaged also, though it would have to go in non-free of course. I saw an old resolved RFP for helix, but searching in synaptic doesn't show up any matches for helix. Britton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: helix player package for debian?
I thought I saw some stuff on their web page about helix being GPL now. Not so? Britton On Wed, 08 Feb 2006 22:14:39 +0100, "Daniel Baumann" <[EMAIL PROTECTED]> said: > Britton Kerin wrote: > > is anyone working on packaging helix player? I'd like to see > > RealPlayer packaged also, though it would have to go in > > non-free of course. > > I'm working on the rest of the helix-tools and real-player too. I'm in > contact with Real to fix the helix-player license and to get an > acceptable license for real-player for its inclusion into non-free. > Unfortunately, such things take a very, very long time.. > > -- > Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist > Email: [EMAIL PROTECTED] > Internet: http://people.panthera-systems.net/~daniel-baumann/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eiffel.
This is pretty exciting, especially for people like me who loved Eiffel when we were young idealistic students but wandered away due to the fragmented community and the pain of having to write a wrapper every time you want to use a library. Will ISE release the Gtk wrappers they obviously have and the OpenGL wrappers they presumably do? If people make a fork to add ++, break, and continue, and everyone uses them, will B. Meyer finally become slightly less uptight and embrace them as well? :) Britton On Wed, 12 Apr 2006 07:48:22 +0200, "Daniel Baumann" <[EMAIL PROTECTED]> said: > Kari Pahula wrote: > > I can assume that Eiffel Software is arguing that anything compiled > > with Eiffel Studio is a derived product and needs to be under GPL too. > > Not that I've investigated this myself at all. > > It is correct, parts of the runtime are in every binary, so every binary > is a derivated GPL work of that and must be distributed unter the GPL > too. > > Nevertheless, as GPL doesn't exclude and ISE (the firm behind > eiffel.com) did not clearly say, you can distribute commercial > applications. > > -- > Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist > Email: [EMAIL PROTECTED] > Internet: http://people.panthera-systems.net/~daniel-baumann/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
status of application for reinstatement of my developer account
I have applied and completed the questions I was supposed to complete months ago now. I've sent a couple of follow up emaile to [EMAIL PROTECTED] asking just to know the status of my application. I've gotten no response whatsoever. Is there any reasonable hope of getting my account reinstated? It gets a bit irritating to be totally ignored after taking the time to answer all the questions on the reinstatement test. If random volunteers aren't worth bothering with thats fine, but don't ask them to spend their time and then ignore them. Sincerely, Britton Kerin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#886238: Please introduce official nosystemd build profile
On 1/3/18, Steve Langasek wrote: > On Wed, Jan 03, 2018 at 09:13:24AM -0500, Paul R. Tagliamonte wrote: >> Conversely, if the patches are invasive and unmaintainable, its not on >> Debian to merge them. > > Moreover, defining an official nosystemd profile in Debian signals that we > are willing to support it, which means any maintainers who refuse such > patches will immediately become the targets of abuse from anti-systemd > zealots. > > Building a derivative around the exclusion of libsystemd from the > filesystem > is not technically defensible. This is a purely political fork, and it's > politics that we should stay entirely clear of. As a random long-time user, I recently bought a new pre-built laptop with debian and got the systemd fun for the first time. Decided no more debian for me in the future. I'm pleased to hear that there are derivative distros that resist systemd and encourage debian to *allow* them, assuming people are willing to do the work. *Not* allowing this is the politics-driven position. Britton
Bug#886238: marked as done (Please introduce official nosystemd build profile)
> -- Forwarded message -- > From: Bastian Blank > To: 886238-d...@bugs.debian.org > Cc: > Bcc: > Date: Fri, 5 Jan 2018 11:50:23 +0100 > Subject: Re: Bug#886238: Please introduce official nosystemd build profile > On Wed, Jan 03, 2018 at 03:12:51PM +0300, Hleb Valoshka wrote: >> Please introduce official nosystemd build profile so downstream >> distributions can send patches to package maintainers with >> systemd-less build instead of keep them in home. > > As you have been already told by several people, Debian supports > systemd-less systems. If you find bugs running in this mode, please > file bug reports. > > Apart from that, I don't see that you managed to describe what a > "nosystemd" profile would actually do. This would be the least we would > need from such a bug report. > > However what I see is, that you and others instead of actually engaging > in discussions just referred to personal attacks. I and others consider > this unacceptable behaviour on our technical mailing lists and our bug > tracker. Please be adviced that I will ask both the BTS owner and the > list masters to block you from ever posting again if this behaviour > continues. > > As I don't think anything new will come up, I'm closing this bug report. > Don't reopen it, this might just expedite your fate. Yeah no more debian for me in future. That last comment is priceless. Britton
Bug#886493: general: debian should support nosystemd build profile
Package: general Severity: normal If debian is remotely serious about keeping non-systmed use an option, is should support a nosystemd build profile. There's no other real way to guarantee that packages don't use it. Sure they don't *have* to link against it, but in practice many will and this is the obvious clean way to ensure that none do so. As a long-time user I'm highly interested in this feature, and preventing others from working on it for idealogical reasons is indefensible. Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.4 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.5.emp3 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system)
trying to use wireless not from gnome... what's the incantation?
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. No combination of nmcli ifconfig iw ip rfkill unblock wpa_supplicant /etc/network/interfaces etc. that I've tried makes wireless work outside of gnome, and I've googled much and tried many of them. It seems like a waste of time, since clearly nm-applet and/or NetworkManager knows the magic spell. I'm posting here both in hope of a solution, and because this seems like a bug. How come this only works from gnome? nmcli in particular looks like it's trying to be a general-purpose solution, but somehow it too only works from gnome. Here's what NetworkManager puts in syslog when bringing wireless up: May 22 20:26:11 debian NetworkManager[1959]: enable requested (sleeping: no enabled: no) May 22 20:26:11 debian NetworkManager[1959]: re-enabling... May 22 20:26:11 debian NetworkManager[1959]: (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] May 22 20:26:11 debian NetworkManager[1959]: (eth0): preparing device May 22 20:26:11 debian NetworkManager[1959]: (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] May 22 20:26:11 debian NetworkManager[1959]: (wlan0): preparing device May 22 20:26:11 debian NetworkManager[1959]: NetworkManager state is now DISCONNECTED May 22 20:26:11 debian NetworkManager[1959]: (wlan0) supports 5 scan SSIDs May 22 20:26:11 debian NetworkManager[1959]: (wlan0): supplicant interface state: starting -> ready May 22 20:26:11 debian NetworkManager[1959]: (wlan0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] May 22 20:26:11 debian NetworkManager[1959]: (wlan0): supplicant interface state: ready -> disconnected May 22 20:26:11 debian NetworkManager[1959]: (wlan0) supports 5 scan SSIDs May 22 20:26:15 debian NetworkManager[1959]: Auto-activating connection 'dlink_223_dome_rd'. May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) starting connection 'dlink_223_dome_rd' May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started... May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0] May 22 20:26:15 debian NetworkManager[1959]: NetworkManager state is now CONNECTING May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting... May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0/wireless): access point 'dlink_223_dome_rd' has security, but secrets are required. May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0] May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) complete. May 22 20:26:15 debian NetworkManager[1959]: (wlan0): supplicant interface state: disconnected -> inactive May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started... May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0] May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting... May 22 20:26:15 debian NetworkManager[1959]: (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0/wireless): connection 'dlink_223_dome_rd' has security, and secrets exist. No new secrets needed. May 22 20:26:15 debian NetworkManager[1959]: Config: added 'ssid' value 'dlink_223_dome_rd' May 22 20:26:15 debian NetworkManager[1959]: Config: added 'scan_ssid' value '1' May 22 20:26:15 debian NetworkManager[1959]: Config: added 'key_mgmt' value 'WPA-PSK' May 22 20:26:15 debian NetworkManager[1959]: Config: added 'psk' value '' May 22 20:26:15 debian NetworkManager[1959]: Activation (wlan0) Stage 2 of 5 (Device Configure) complete. May 22 20:26:15 debian NetworkManager[1959]: Config: set interface ap_scan to 1 May 22 20:26:15 debian wp
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 $ $
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: make ping executable by normal users?
On Thu, Jun 2, 2016 at 2:33 PM, Santiago Vila wrote: > On Thu, Jun 02, 2016 at 01:56:08PM -0800, Britton Kerin wrote: >> On my old debian system I could ping as a normal user. The ping >> binary had the suid bit set. Now I get: >> >> $ ping www.google.com >> ping: icmp open socket: Operation not permitted >> 2 $ >> >> presumably because the bit isn't set. >> >> What's the right fix? I could setuid it but then if I understand >> correctly it might get changed back by an upgrade. Does it use >> capabilites or something? > > Yes, it uses capabilities. The simple fix is to do this: > > dpkg-reconfigure iputils-ping Well, that works, thanks. But I really don't get the overall behavior. It says this: root@debian:/home/bkerin# dpkg-reconfigure iputils-ping Setcap worked! Ping(6) is not suid! root@debian:/home/bkerin# And then ping works for non-root users. How, just by executing dpkg-reconfigure, did I tell it this is what I wanted? If that's the default, why wasn't it that way to begin with? More generally, is it somehow possible to still run debian without capabilities? I hate them. The simple root-or-not security model is much simpler and doesn't promise more than it can really deliver. I'm sad to see capabilities now as the default. Britton
