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)
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#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
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
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, 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
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 $ $
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
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]
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]
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]
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]
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]
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]
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]
