Re: dselect survey
Miles Bader <[EMAIL PROTECTED]> wrote: > The current aptitude, by contrast, seems both powerful and elegant: it > rarely gets in my way, deals well with problem situations, and offers > powerful features should I want them (aptitude of years past could also > be kinda cranky though). The last time I used aptitude (about six months ago, from Testing), I found it difficult to specify how I wanted dependencies (including recommends and suggests) to be satisfied. I like that fact that when I select a package in dselect which has several ways of satisfying its dependencies, dselect lets me choose what gets installed. Just because a package depends on a web server doesn't mean I want apache installed. While aptitude does tell you what it's going to install, and gives you an opportunity to change it, I couldn't get it to give me a list of acceptable alternatives. I am willing to accept that this might just be down to my own stupidity though. Roger (Sorry if I've broken the thread; I'm reading the web archive.)
Re: Why do we still have this on the distribution?
Martin Schulze wrote: > FWIW: This would mean to remove all of Mozilla and friends, since they > don't receive any security support upstream, and neither the maintainer > or the security team are in a position to backport all fixes and correcte > all stuff in the older versions. (upstream does only support the most > recent version, which will be different about one month after the sarge > release). Upstream promised and provided security support for Mozilla 1.0, 1.4 and 1.7 for a period of 1 year after release. However, none of the updates for 1.0 made it into Woody. Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux / Debian / Ubuntu
On Tue, 31 May 2005 21:37:28 -0700, Stephen Birch <[EMAIL PROTECTED]> wrote: > Darren Salt([EMAIL PROTECTED])@2005-05-31 21:49: > > For those who've missed the first three broadcasts today, there's one more > > at > > 01:05 GMT; also see http://news.bbc.co.uk/2/hi/technology/1478157.stm>. > > Why on earth does the BBC force its listeners to all hit its servers > at the same time. Doesn't make sense at all, why not ogg the program > up and put it on its servers so the audience can listen when they > want. Huh? You can listen to the programme any time you like. (Admittedly you're restricted to RealPlayer or Windows Media Player, but at least there are cross-platform players available for RealPlayer.) > Okay, so I know the answer. The BBC is still coming to grips with the > idea that "boradcasting" is dead. The tech generation wants to time > and space shift programming to a convenient time/location. You can do exactly that. The vast majority of the BBC's radio output is available to listen to whenever you want, up to a week after broadcast, and has been for some time. Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing the manpage requirement for GUI programs?
On 04/03/10 20:00, Yves-Alexis Perez wrote: > > Josselin Mouette writes: > > > Letting alone policy issues: what do you propose, *concretely* to > > > improve the situation? A man page containing a *brief* (one or two lines) description of what the program does and pointers to further more comprehensive documentation would be vastly better than no man page at all. > My upstream position is exactly what started the thread: no need to have > duplicate information between --help and manpage, --help strings are > easily translatable (and translated), and they are more likely to be up > to date. And where is the --help option described? Many programs don't provide it at all, and as has already been said there are many different switches used to access the help amongst those that do. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b903963.6020...@rilynn.me.uk
Re: UPG and the default umask
On 18/05/10 11:00, Christoph Anton Mitterer wrote: > Not to speak about, that UPG is anyway a questionable abuse of the > user/group concept. > > Neither to speak about the fact, that in the 17 years debian exists > now,... no majority missed that "feature" (apparently). Debian has been using UPG for decades yet no one has complained about it. Why didn't you raise a bug when UPG was first introduced? People configuring Debian to run in a non-UPG environment can quite easily also change the umask. As Debian uses UPG by default then the default umask should be 0002. If you change one then you can change the other at the same time. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf2ff5c.1070...@rilynn.me.uk
Re: APT do not work with Squid as a proxy because of pipelining default
On 18/05/10 03:10, Robert Collins wrote: > Given that pipelining is broken by design, that the HTTP WG has > increased the number of concurrent connections that are recommended, > and removed the upper limit - no. I don't think that disabling > pipelining hurts anyone - just use a couple more concurrent > connections. But apt has been using pipelining for years. Why has this only just become a problem? Not all proxies dislike pipelining - Polipo is an example of one that works well with it. It also works with at least some proprietary/commercial proxies too. And if transparent proxies can't cope with pipelining then they're broken and not very transparent. I think if this was a significant problem it would have been noticed a long time ago. However disabling pipelining if a proxy is configured is probably a good idea to ensure compatibility and is commonly done in browsers, but it's not necessary for direct connections. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf31d2e.7020...@rilynn.me.uk
Re: UPG and the default umask
On 19/05/10 22:20, Christoph Anton Mitterer wrote: > btw: What happened to the idea of movin umask completely away from > /etc/profile? > I mean regardless of the discussion about UPGs and which value is the > "best" default for umask, I found it to be a good idea to drop it there. This is a good question. When I was changing my umask to 0002 a few months ago web searches told me to look in login.defs, which told me to use pam. So eventually I worked out how to change the umask in pam, but it still didn't have any affect. It was only have further searching that I discovered it was being overridden by /etc/profile. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf5bb38.6050...@rilynn.me.uk
Re: Possible mass bug filing: non-doc packages recommending doc packages
On Fri, May 08, 2009 at 07:00:25PM +0200, Stefano Zacchiroli wrote: > On Thu, May 07, 2009 at 09:47:56PM -0700, Daniel Burrows wrote: > > As a practical matter, downgrading these dependencies will cause > > aptitude and other package managers to believe that the documentation > > is unnecessary and suggest removing it. > > Even if the user marked as non-automatic the involved -doc packages? > > Anyhow, even if it is the case, I'm tempted to just reply "too > bad". The admin will notice that and take it as an occasion for doing > a review of which doc she really wants and which she wants not. As a user, I like being able to mark documentation packages as being automatically installed, so that when I remove the associated packages the package manager will automatically offer to remove the then unneeded documentation packages at the same time. Otherwise there is a good chance the documentation packages will litter the system forever, or at least until I get around to doing a manual cleanup (which might never happen). I suppose another way around this would be to be able to mark suggested packages as being automatically installed so they could be removed automatically when the suggesting package is removed. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Reverting to GNOME for jessie's default desktop
On 07/08/14 23:10, Jordi Mallach wrote: > Popularity: One of the metrics discussed by the tasksel change proponents > mentioned popcon numbers. 8 months after the desktop change, Xfce does not > seem > to have made a dent on install numbers. The Debian GNOME team doesnât feel > popconâs data is any better than a random online poll though, as itâs an > opt-in > service which the vast majority of users donât enable. What proportion of people installing testing or unstable will just go along with the default? Won't most people choosing the default options be using the stable installer? It would therefore be difficult to collect any meaningful data at all from popcon until there was stable release with changed defaults. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/608tbb-4km@silverstone.rilynn.me.uk
Re: PackageKit cleanup: Do you use these functions?
On 11/09/14 14:50, Ansgar Burchardt wrote: > I think it's not realistic to expect upstreams to support online updates > for every application. Once you have plugins or external data, it's hard > to keep working properly after an upgrade. Surely the solution to this is to restart the affected application rather than rebooting the whole computer? Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/inn9eb-fq8@silverstone.rilynn.me.uk
Re: switching from exim to postfix
On 01/05/12 15:10, Chris Knadle wrote: > I think the reason Exim does not do this protocol conversion is that from the > point of view of an MTA author, the point of an MTA is to transmit the body > of > the message without any modification to it once received, and body > modification would be required to convert 8-bit MIME to 7-bit MIME. I seem > to > remember reading something along these lines in the Exim documentation years > ago and I'm having another look through it, but haven't found a reference to > this yet. http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo says: "This option causes Exim to send 8BITMIME in its response to an SMTP EHLO command, and to accept the BODY= parameter on MAIL commands. However, though Exim is 8-bit clean, it is not a protocol converter, and it takes no steps to do anything special with messages received by this route. Consequently, this option is turned off by default." I have enabled accept_8bitmime in every exim I've installed for the last 10 years and no one has reported any problems. I think the risk of encountering a truly 7 bit MTA in this decade is low enough to be ignored for most purposes. Anyone still using one is likely to find that a substantial fraction of their incoming mail is corrupted. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa02fac.7060...@rilynn.me.uk
Re: switching from exim to postfix
On 02/05/12 02:00, brian m. carlson wrote: > On Tue, May 01, 2012 at 07:47:08PM +0100, Roger Lynn wrote: >> I have enabled accept_8bitmime in every exim I've installed for the last >> 10 years and no one has reported any problems. I think the risk of >> encountering a truly 7 bit MTA in this decade is low enough to be >> ignored for most purposes. Anyone still using one is likely to find that >> a substantial fraction of their incoming mail is corrupted. > > I actually use Sendmail's strict 8BITMIME support to help catch spam. I > agree that 7-bit MTAs are essentially gone, but with the volume of spam > I receive, I set my mail software to be extremely strict with regard to > protocols. Legitimate software (of any sort) generally generates > protocol-compliant messages. Malicious and illicit software (and that > created by Microsoft) generally does not. Legitimate software also > generally has a userbase that will complain about rejected data if the > software is not protocol-compliant, which often leads to fixes. > > I've complained to the listmasters that they send 8-bit data that is not > MIME (virtually all of which is spam) under the auspices of the 8BITMIME > extension; they refuse to fix this, and as a consequence they have to > deal with the occasional piece of undeliverable mail. This is not a > knock against the listmasters, just an observation that if you violate > the protocols, some places will reject your data. Many MUAs have options for sending 8 bit mail[0]. Do they take notice of whether the MTA they're talking to is 8 bit capable? It will be a while until I have a chance to experiment. Roger [0] For example, in Iceape: "For messages that contain 8-bit characters, use 'quoted printable' MIME encoding. Leave unchecked to send the messages as is. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/dvgb79-46s@silverstone.rilynn.me.uk
Re: Recommends for metapackages
[sorry for the lengthy quoting below] On 12/07/12 10:10, Gergely Nagy wrote: > Noel David Torres Taño writes: >> Not so minimal if you want your gnome set to be up to date, including new >> applications being installed. > > It is very minimal. 5 minutes of work. Been there, done that, posted the > bulk of the solution, and a general outline of the rest of it to this > list, in this very thread, multiple times. > > Please take some time to read it. But alas, I'll make it easy for you: > > If you want to install a meta-package, but without one of its > dependencies, and want to keep up to date with it too, so you get all > the new stuff added to it, and you also want to be able to remove the > whole thing with one swift sweep, here's what you do: > > - Grab the control file of the meta-package > (~1 line in shell, use grep-aptavail) > - Filter out unwanted packages from depends > (~5-6 lines in shell) > - Create a local package, under a different name, with the updated > information > (~10-20 lines, use equivs) > === 5 minutes so far === > - Push it into a local repository > (~2-3 lines, use whatever, reprepro, mini-dinstall, or cat < - Put the local repo in sources.list > - apt-get update & install your shiny new meta-package > - Hook all that into Apt::Update::Post-invoke > > That's it. The whole thing is under a hundred lines, and easily doable > within half an hour (for the record, I implemented all of the above this > morning in 17 minutes while still half asleep). > > If you want to be super-cool, create a sourcable config file that tells > the generator script what packages to filter out from which metas. Pack > it up, ship a deb, everyone's happy. > > Even better, here's an alternative solution: > > - Grab a list of unwanted packages > - Create a dummy package with an epoch of 99, using the same name the > unwanted packages. > - Install them > - Use the meta-package unmodified > > (Whole excercise doable in 10 minutes tops, including reading the equivs > documentation.) Do you really think these are reasonable solutions for your users? I am not a Debian Developer, and following any of the above instructions would take me several hours. > All of that took a fraction of the time than arguing here on this list, > about things that can already be solved *conveniently* by anyone caring > enough, in multiple ways. Obviously, most people in this thread don't, > as we'd already have a packaged solution if that weren't the case. > > And since noone seems to have cared enough to come up with a solution > that works for *everyone* (upstream, novice and advanced users alike, > and maintainers too), can we drop the subject now? Recommends does work for everyone except you. The arguments against recommends that you keep repeating appear to apply to a small subset of developers running unstable and not the users of your stable packages. Who are you developing for? Other packages use recommends without introducing the problems you have mentioned. It sounds like you think recommends is always useless and should never be used by any package. >> If that package is not a true dependency of the core of the set, >> Recommends is more than justified. > > Upstream considers it a dependency in this case, part of a > platform. If you don't want the full platform, don't install the full > one, select the pieces you need - it is that easy. If I wanted software exactly as released by upstream I wouldn't be using Debian. I expect Debian fix the oddities that upstreams sometimes include and make software work nicely together. > In case of gnome, the package pulls together what upstream considers the > GNOME platform - it is that simple. That's what recommends does. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/njm6d9-ji2@silverstone.rilynn.me.uk
Re: Change default PATH for Jessie / wheezy+1
On 08/08/12 12:30, Thomas Goirand wrote: > On 08/08/2012 06:21 PM, David Given wrote: >> ifconfig (before this discussion I'd never even *heard* of ip) >> > This kind of remark make be say that probably, it'd be > nice to have ifconfig display a warning as this one: > > "ifconfig is deprecated, please use ip instead" That might be helpful if and only if it gave the syntax of the equivalent ip command. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/057bf9-qv3@silverstone.rilynn.me.uk
Re: Possible release note for systems running PHP through CGI.
On 19/08/12 03:20, Charles Plessy wrote: > - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or >php5-cgi. Debian recommends libapache2-mod-php5, but there are still >thousands of installations wich report the use of php5-cgi according to the >Popularity Contest statistics. Many of the users of php5-cgi will be doing so because they are using other web servers. The discussion in #674089 seems to mainly revolve around Apache. How does this affect other web servers? Regards, Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/okj7g9-bb4@silverstone.rilynn.me.uk
Re: greater popularity of Debian on AMD64?
On 05/09/12 18:10, W. Anderson wrote: > It is somewhat surprising and a little disappointing that Debian, or any > other GNU/Linux distribution would be making statements that, in effect, > give great public support to AMD in regard Linux, when the company has > for many years been decidedly ambivalent and generally uncooperative > towards the Linux community, particularly in cooperation with Microsoft > in their negative attitudes and /_actions _/toward Free/Open Source > Software communities. As the only significant competition to Intel in the PC market, AMD need all the help they can get. The more people that run free software on AMD equipment, the more likely they are to look favourably upon free software developers. But, as has already been pointed out, the statement doesn't give support to AMD anyway. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/vhskh9-0u3@silverstone.rilynn.me.uk
Re: status of eligibility of dug lists on lists.debian.org
On 19/09/12 13:50, anarcat wrote: > Andrei POPESCU wrote: >> [x] E: Host lists on their own server in someones basement > > See that's exactly what I'm talking about - *I* can do this, I can host > lists in my "basement" (or my "freedombox", call it what you like), as > I am an experienced sysadmin and developer. But this is not something > anyone can do in their basement. Email is specifically hard to host > behind home connexions - I have been doing it for a while, but it's been > an uphill battle all that time... > > But my concern is: what should a non-developer, non-sysadmin do in this > situation? Aren't we telling our users to go away here? Unless all the members of a group are beginners, isn't this an opportunity for a more experienced member to learn about hosting a server, how email works, setting up a mailing list and using Debian? I first set up a Mailman instance when I had been using Debian for about three years and I was not a sysadmin, although admittedly I do develop embedded software. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s9kpi9-mj1@silverstone.rilynn.me.uk
Re: systemd .service file conversion
On 30/05/13 16:30, Matthias Klumpp wrote: > 2013/5/30 Marco d'Itri : >> The /etc/ /lib/ /usr/lib/ split with files overriding each other, >> invented because RPM systems do not prompt the user on package upgrades >> and Red Hat does not support upgrading to the next major release. > Well, that might have been one reason, but splitting the conf files > has other advantages too. I like that I have the original file as > reference, that I have very small config-override files which can > easily be backed up, and it also simplifies updates, because I don't > have to merge diffs of config files, but just need to adjust them > later, if something has changed. I prefer to be notified of changes to configuration files during upgrades so that I know which configurations need updating, rather than just hoping that the old config will work with the updated package and missing out on any new options silently introduced in a master configuration file which I can't even easily diff for updates. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/evfn7a-03j@silverstone.rilynn.me.uk
Re: default MTA
On 31/05/13 07:50, Jean-Christophe Dubacq wrote: > A utility to scan syslog and convey important information to the user > would be much more useful than configuring all mailers in Debian to read > root's local mail by default. I know how to redirect root's mail > elsewhere, thank you for not making another mail account to check. The mailers don't need to read root's mail, they just need to read the user's own mail, which is something they should do anyway. The fact that many apparently still don't is quite a startling omission. I remember being surprised many years ago that Netscape and Mozilla apparently didn't support reading local mail, which should be a basic function of any Unix MUA. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/lk0q7a-69p@silverstone.rilynn.me.uk
Re: default MTA
On 06/06/13 14:00, Chris Knadle wrote: > On Wednesday, June 05, 2013 15:35:14, Marc Haber wrote: >> On Sun, 2 Jun 2013 19:53:59 -0400, Chris Knadle >> wrote: >> >Attempting to use an FQDN is also troublesome, because Exim tries to use >> >DNS to look up the FQDN, and falls back to using 'uname -n' which returns >> >the local hostname without a domain name. The SMTP RFCs require the >> >HELO/HELO information to contain an FQDN or an IP address in [] brackets, >> >and some mail systems reject connections containing non-conforming >> >HELO/EHLO greetings. >> >> Smarthosts are usually a lot more forgiving in that regard. > > Maybe so, but the smarthosts I run aren't, so I don't have the expectation > that others are. ACL rules for both Exim and Postfix for blocking > noncompliant EHLO/HELO greetings are commonly suggested. The smarthosts run by ISPs that most people will be using by default have to accept mail direct from MUAs such as Outlook and Thunderbird which will often be unable to generate compliant greetings. The pickier settings are more often used on incoming servers which expect to have proper SMTP servers speaking to them. >> >> I don't think you need MAIN_TLS_ENABLE to to TLS as a client. >> > >> >Tested this... looks like this is true. :-) Cool. [I'm pretty sure this >> >wasn't always the case, but I'm glad it is now.] >> >> Afair, it was always the case. > > Okay -- I'll take your word for it. ;-) The upstream spec for Exim 3.30 from 2001 says: "It is not necessary to set any options to have TLS work in the smtp transport. If TLS is advertised by a server, the smtp transport will attempt to start a TLS session." Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/o4878a-c84@silverstone.rilynn.me.uk
Re: x32 “half” arrived… now what?
On 06/06/13 21:10, Adam Borowski wrote: > On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: >> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect >> SUBSTANTIAL porting of packages to be required. Particularly since that >> arrangement is explicitly unsupported by the GNU coding standards: >> >> Similarly, don't make any effort to cater to the possibility that >> `long' will be smaller than predefined types like `size_t'. > > It was the case in old versions of gnulib, but appears to be no more. > Too bad, quite a few packages ship embedded copies of ancient gnulib. > I just submitted a patch in one such case (#711412), it might possibly > apply elsewhere. > > It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 > bug even if its word size is 32 bit, and I'd say he's right. This means > that this problem will bite us the next time another 32 bit arch comes, > so there's no excuse to use this as an argument against x32. Would a better solution not have been to make long 64 bits? This is a perfectly reasonable thing to do on a 32 bit arch, it would avoid the above problem and since the widespread adoption of 64 bit systems most of the cases of software expecting long to be 32 bits should have been fixed. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ueck8a-po6@silverstone.rilynn.me.uk
Re: boot ordering and resolvconf
On 03/07/13 14:30, Ian Jackson wrote:
> Ian Jackson writes ("Re: boot ordering and resolvconf"):
>> 4. Therefore in most installations there should be a local
>>proxy or cache. It should use DHCP-provided, PPP-provided or
>>similar, as a forwarder. The local DNS provider address
>>should be owned by whatever proxy or cache is installed.
>
> Is there some reason not to use dnsmasq for this ?
>
> To do this we would have to:
> * install dnsmasq by default
> * teach resolvconf to update dnsmasq's config rather than
> resolv.conf (but apparently Ubuntu have done this work)
> * make sure that the full-on DNS servers all conflict with
> dnsmasq and listen on 127.0.0.1
Please don't make DNS servers conflict with each other. I have Dnsmasq,
Unbound and NSD all installed. Unbound provides recursive DNSSEC enabled
resolution for the local network, it forwards queries for the LAN domain to
an authoritative Dnsmasq DNS/DHCP servicer running on a different port and
NSD is running on an external interface serving an external domain. I don't
think this is an unreasonable configuration to want.
Thanks,
Roger
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/fnalaa-qlq@silverstone.rilynn.me.uk
Re: let's split the systemd binary package [Was, Re: systemd effectively mandatory now due to GNOME]
On 24/10/13 03:00, Steve Langasek wrote: > On Thu, Oct 24, 2013 at 02:21:25AM +0200, Matthias Klumpp wrote: >> 2013/10/24 Steve Langasek : >> > Well, that's one more reason the init system and the dbus services should >> > be >> > separated out in the packaging. >> Some of the services consume functions and features provided by >> systemd (the init system). > > Which is exactly the kind of embrace-and-extend that Debian should not > tolerate having foisted on them in the default desktop by an upstream > pushing an agenda. How often is the choice of default desktop re-evaluated, and how is this done? Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kogoja-272@silverstone.rilynn.me.uk
Re: Proposal: switch default desktop to xfce
On 31/10/13 09:30, Wouter Verhelst wrote: > Op 30-10-13 23:09, Steve McIntyre schreef: >> So... In that situation, would you care about having more than just a >> netinst available for initial booting? Beyond that, people can get on >> the network to a mirror, or to other machines hosting the DVD images. >> >> I'm thinking we can cut down some more here. Maybe (as Steven >> suggested) we could keep a single bigger CD image around, but I'm not >> 100% convinced that it's likely to give us enough beyond the netinst >> to make me care about it. What else would we want/need on a CD to make >> it compelling here? > > I think having a live-CD (if that is at all possible) might be useful > for those cases where you have an old system without DVD that doesn't > boot anymore. This doesn't need a full desktop environment, just a shell > with some utilities should do. > > I don't think you'd necessarily need more than the netinst CD for > installation, either; but then, if you're going to write a CD image > anyway, why not write the full one rather than waste a CD to half an > image -- so I think having one 650MB image might be useful; I would > suggest adding packages that have a high popcon rating, without > necessarily trying to fit any kind of desktop environment on there. I would like a CD with as much of Required, Important and Standard and as many other popular packages as will fit. Whether installing or upgrading it's useful to be able to download a reasonable amount in advance, especially if you're doing more than one machine or on a slow link. It would also be useful able to install a minimal working system without needing network access, or is this what the netinst provides anyway? I've generally used CD1 for this in the past. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d0raka-1n5@silverstone.rilynn.me.uk
Re: RFC: Making mail-transport-agent Priority: optional
On 15/10/11 22:00, Josh Triplett wrote: > Steve Langasek wrote: > > Needing to send mail through specific per-user smarthosts is the exception, > > not the rule. Most machines have a designated forwarding smarthost based on > > who their ISP is, not based on which email address someone wants to use. > > Every ISP mailserver I've seen, and for that matter almost every other > mailserver I've seen, requires SMTP AUTH to send mail; the SMTP AUTH > credentials vary by user. And for that matter, while most of those > mailservers[1] will allow sending from email addresses other than the > one used for SMTP AUTH, many such servers *will* prohibit sending from > another address at the same domain/service, requiring you to SMTP AUTH > for that address instead. I don't believe this is usually the case in the UK. Most mailservers (both in ISPs and elsewhere) will usually allow unauthenticated connections from machines connected to their networks. Only if they allow users to send mail from elsewhere will they require SMTP AUTH. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/um8rm8-oda@silverstone.rilynn.me.uk
Re: Debian default desktop environment
On 04/04/14 00:50, Stephen Allen wrote: > On Fri, Apr 04, 2014 at 08:18:41AM +1100, Dmitry Smirnov wrote: >> I think Xfce is much better *default* desktop environment (DE) than Gnome. >> >> As KDE fan I do not like Gnome. Those who forget to choose DE in installer >> (just like I did more than once) and end up with Xfce will have a lot less >> to >> remove from their systems shall they choose to use a different DE. >> >> Faster installation is another good reason to stick with Xfce by default. > > Disagree - Gnome 3 I would think for MOST users would be preferable. > Like the OP says Xfce4 is not desirable for most users coming from the > dark side or heck perhaps for most users on Linux that want a modern > desktop. If you assume that most users have previously used MS Windows, then wouldn't KDE be more appropriate? It might also avoid some of the more controversial discussions we've seen here in recent years. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/u1s31b-unl@silverstone.rilynn.me.uk
Re: Having fun with the following C code (UB)
On 14/04/14 14:30, Vincent Lefevre wrote:
> On 2014-04-14 14:14:14 +0200, Raphael Geissert wrote:
>> No, there is no optimisation in that case, so there is no warning. It only
>> warns when it uses the knowledge that "(signed) integer overflow isn't
>> possible" to optimise away some redundant code.
>
> But what I mean is that it's pointless to emit such a warning when
> the effect of the potential integer overflow is already visible,
> for instance in printf below:
>
> m = d * C;
> printf ("%d\n", m);
> return m >= 0;
>
> If there was an integer overflow, you will get an incorrect value
> output by the printf. This means that it is very likely to be a false
> positive. So, one doesn't want the warning.
The purpose of this gcc warning isn't to warn you that overflow might
happen, but to warn you when gcc's optimisations have broken any two's
complement overflow behaviour that you might have expected. Thus if you have
written code that assumes "normal" two's complement overflow you get a
warning when it has been broken by assumptions made by the optimiser. In
other cases you get "normal" overflow so there is no need for this warning.
Roger
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/i2j02b-cn1@silverstone.rilynn.me.uk
Re: systemd-fsck?
On 13/05/14 20:30, Salvo Tomaselli wrote: > In data martedì 13 maggio 2014 19:42:32, David Goodenough ha scritto: >> > service foo works across Linux distributions, with or without >> > systemd, and does the right thing. >> >> The big shame with service is that tab completion does not work properly. >> If I use /etc/init.d/ then tab tells me what is there and spells it right. > > You should install bash-completion Bash-completion has never worked for me from a root prompt. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/qs8d4b-laq@silverstone.rilynn.me.uk
Re: /usr/share/doc/ files and gzip/xz/no compression
On 16/08/11 00:10, Carsten Hey wrote: > bzip2 has a better compression on average for some filetypes, xz[1] has > a better compression on average for others: > >gzip bzip2 xz bzip2+xz[3] > text files[2] 94312922 73496587 77783076 73496587 > other files 16577181 14609893 14275484 14275484 > sum110890103 88106480 92058560 87772071 > > Among the "other files" are also a lot of text files, if we would > compress Debian packages instead, xz would win presumably. > > Anyway, I don't think this difference of 4 MiB on a desktop system is > significant. > > > I would prefer to avoid bloating the set of pseudo essential packages > without a good reason and I think users should be able to decompress all > files in /u/s/d. There are plans to let dpkg depend on liblzma2 instead > of xz and it already depends on libbz2-1.0. If dpkg's dependency on > libbz2 is planned to be removed in future, I would prefer to let libbz2 > vanish from the pseudo essential set and use xz also for /u/s/d, > otherwise I would prefer using bzip2 over xz for /u/s/d. One advantage of gzip /usr/share/doc is that when served by an appropriately configured web server .gz files will be transparently decompressed and displayed by most web browsers. I believe Policy requires Debian web servers to make /u/s/d available at http://localhost/doc/. While this obviously isn't an overriding consideration it is a nice easy way to browse the documentation. Can same be done for any other compression formats? Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7e7rh8-j14@silverstone.rilynn.me.uk
Re: Embedded systems and systemd
On 29/11/14 13:30, Vincent Bernat wrote: > ❦ 29 novembre 2014 12:41 GMT, Alastair McKinstry > : >> One concern I'd have is the lack of flexibility to produce a cut-down >> system. The option of "a dedicated init=/custom-program", but lack of >> an ntpd, for example, because ntp has been absorbed into systemd's >> orbit and other ntpd's bitrotted. > > Unlikely to happen since systemd-timesyncd is not a full NTP daemon. It > lacks ability to act as a server. And it doesn't appear to regulate the system clock frequency, which basically makes it an inaccurate dumb SNTP client which steps the clock when it synchronises. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6e8vkb-j33@silverstone.rilynn.me.uk
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On 09/09/19 14:40, Bjørn Mork wrote: Ondřej Surý writes: Otherwise it doesn’t make any sense to remove external links to logos and JavaScript from the documentation and then send everything to one single US-based provider. Exactly. I'd be worried if anything in Debian came preconfigured with DNS servers of any kind. It apparently already does, although they appear to be used only under certain circumstances. See https://bugs.debian.org/761658 Roger
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On 15/05/2023 19:00, Simon McVittie wrote: > On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote: >> People build things on Debian that are not Debian packages. People >> compile binaries on Debian, and expect them to work on any system that >> has sufficiently new libraries. > > *raises hand* > > Hello, I represent an example of those people. With my $work hat on, > I'm involved in maintaining a family of Debian derivatives (the Steam > Runtime) that is used to run Steam games on arbitrary distributions, > including but not limited to Debian. Some of these binaries are built > on a Debian derivative, but run on an arbitrary other distribution, > using a RPATH[1] to find their non-glibc dependencies. As another much smaller example, which I hope is still relevant, I have taken binaries from Debian stable or oldstable armel and run them for diagnostic purposes on embedded boards which only have Busybox installed and for which I don't have a convenient build environment. Regards, Roger PS Apologies if I've followed up incorrectly - I read debian-devel through an NNTP gateway. - And I screwed up the reply so Simon and the bug got a different copy.
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On 21/05/2023 07:00, James Addison wrote: > On Fri, 19 May 2023 at 22:58, Ansgar wrote: >> One of the problems with popcon is that it draws too much attention to >> old releases which isn't really interesting when talking about future >> developments. If one looks at arch usage per release (as reported to >> popcon) one gets this table: >> >> | Architecture | jessie | stretch | buster | bullseye | bookworm/sid | >> |++-++--+--| >> | alpha | 1 | || |4 | >> | amd64 | 9090 | 17156 | 41137 | 108145 |14800 | >> | arm64 || 1 | 93 | 937 | 203 | >> | armel | 21 | 47 | 67 | 68 | 10 | >> | armhf | 7 | 18 |216 | 429 | 49 | >> | hppa || || |8 | >> | hurd-i386 || ||4 |6 | >> | i386 | 1318 |1231 | 1495 | 3042 | 168 | >> | ia64 || || |3 | >> | kfreebsd-amd64 | 2 | || | | >> | m68k || 1 || |4 | >> | mips | 2 | | 6 | | | >> | mips64el || | 6 |4 | | >> | mipsel | 2 | 1 | 7 | | | >> | powerpc| 13 | 1 | 1 |1 | 18 | >> | ppc64 || ||1 | 28 | >> | ppc64el|| 5 | 16 | | 12 | >> | riscv64|| || | 15 | >> | s390x || ||8 |3 | >> | sh4|| || |1 | >> | sparc64|| || | 11 | >> | x32|| || |2 | >> |++-++--+--| >> | ∑ | 10456 | 18461 | 43044 | 112639 |15345 | >> #+TBLFM: @>$2..@>$>=vsum(@I..II) >> >> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%. >> Also interesting is that arm64 has taken over i386 on bookwork/sid. >> >> We don't know how many people downloaded i386 instead of amd64 as they >> have an Intel CPU. >> >> What is also not clear is the bias of systems having popcon enabled at >> all (it seems to be mostly desktop systems) and how it looks on the >> total population. > > Thanks, those are better statistics (and good notes about their limitations). > > I may be playing devil's advocate, but I do also read from those that > the i386 install-base, even dwindled as it has to ~1%, remains more > popular than many other architectures (within whatever dimension of > users enable popcon) where we do provide install images, and then that > those users tend to upgrade to the latest i386 release of Debian that > they can -- and/or that despite the percentage-of-total trend > reducing, the absolute population of those i386 users is growing (I > guess the former is the larger contributing factor, but it's hard to > determine from the numbers only). The popcon graphs clearly show that the absolute number (not proportion) of i386 reports flattened off in 2008 at about 65000, when AMD64 became popular. The number of i386 reports has been falling since 2014, and is now about 1, most of which are from old releases (oldstable or older). It seems likely that the number of i386 reports from stable will be overtaken by ARM64 during the period of Bookworm. Roger
Re: Policy: should libraries depend on services (daemons) that they can speak to?
On 15/01/2024 18:00, Russ Allbery wrote: > When you have the case of an application that optionally wants to do foo, > a shared library that acts as a client, and a daemon that does foo, there > are three options: > > 1. Always install the shared library and daemon even though it's an >optional feature, because the shared library is a link dependency for >the application and the shared library viewed in isolation does require >the daemon be running to do anything useful. > > 2. Weaken the dependency between the shared library and the daemon so that >the shared library can be installed without the daemon even though it's >objectively useless in that situation because it's the easiest and >least annoying way to let the application be installed without the >daemon, and that's the goal. The shared library is usually tiny and >causes no problems by being installed; it just doesn't work. > > 3. Weaken the dependency between the application and the shared library, >which means the application has to dynamically load the shared library >rather than just link with it. This is in some ways the most "correct" >from a dependency perspective, but it's annoying to do, introduces new >error handling cases in the application, and I suspect often upstream >will flatly refuse to take such a patch. Unless I have misunderstood, I think you may have missed another option: 4. Let the leaf application declare the appropriate dependency on the daemon, because the application writer/packager is in the best position to know how important the functionality provided by the daemon is to the application. This could be considered to be option 2b, and a "suggests" dependency of the library on the daemon may still be appropriate. As a user, I don't like option 1, and think it could result in packagers being asked to provide heavy and light versions of their applications with all their optional libraries linked or not. When installing new packages I tend to assume that applications will have some sort of dependency on daemons which are important to them.
Re: Shall we serve scripts as application or as text?
On 29/08/2021 15:20, Simon McVittie wrote: The major difference is fallback behaviour. If a client (web browser or email client or similar) receives a file with a text/* type for which it has no special handler, in the absence of other context it is expected to treat it like text/plain, and show the file to the user as text. If a client receives a file with an unknown application/* type, it is expected to treat it like application/octet-stream, assume that viewing the file as text would be pointless because the user wouldn't necessarily understand it anyway, and offer to save it or open it in an external program instead. [snip] For scripting languages like sh and Python, I'm not sure: either way could be appropriate. Which is more common: sharing scripts as source code to read and edit, or sharing scripts as executables to download and run as-is? If the former, text/ makes sense, if the latter, application/. It is usually easy to save a text file from a web browser, while it is hard (impossible?) to persuade it to display an unknown application/* type. Thus, even if your latter example is more common, it may be preferable use text/. Roger
Re: [RFC] changes to rsyslog - default to RFC 5424 format
On 18/12/2021 15:00, Michael Biebl wrote: I'm not a user of logwatch, so I don't know, if logwatch nowadays can handle RFC 5424 timestamps, but even if so, I think the benefits outweigh the potential breakage. And it's easy enough for users to create a drop-in config snippet with $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat Such a snippet could even be shipped by packages like logwatch or logcheck, if they can't be fixed to support the newer timestamps. It sounds like you're already going to do this anyway, but please include a commented out line in the config file for how to return to the previous format. For "normal" users, I think this change makes it harder to read and makes the lines longer for very little benefit. Thanks, Roger
Re: Discussion tooling
On 05/10/19 22:20, Samuel Henrique wrote: On Wed, 2 Oct 2019 at 14:51, Antonio Terceiro wrote: Note that email already has a "tree-like" structure, since forever. You just don't see it if you (ironically) use web application email clients like gmail that decided to not show it. Most console/desktop clients that I ever saw do support it. Hm, but I wonder of the ones you saw how much they are used, because from the ones I see people using, I would say less than 5% (by usage) has this. And even then we are talking about tools that are either console or desktop-only, there is still the smartphone user cases and, most importantly, being able to follow the discussions without the need to authenticate and being subscribed to the list, which would be useful for outsiders (and an outsider is someone who will become a contributor eventually). As a non-DD and lurker, personally I like the NNTP interface at linux.debian.devel, which I believe is provided by Marco d'Itri. This doesn't require me to subscribe to the list and avoids clogging up my email, although it does require me to have a news server configured and Usenet is of only minority interest these days. It is better than trying to read the web archives and much easier to reply to. I think the header munging works well enough for my occasional posts to be properly threaded. I should add that K-9 Mail for Android has an option for a threaded view and is moderately popular (5-10 million downloads from Google Play plus more from F-Droid). Roger PS I had forgotten that one does have to be registered with the news to mailing list gateway in order to post through it.
Re: systemd, ntp, kernel and hwclock
On 28/02/17 01:00, Ben Hutchings wrote: > On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote: >> Right, ntpdate for some reason doesn't set the flag to do this. > > There is a very good reason, which is that without continuous > adjustment the system clock cannot be assumed more stable than the RTC. This doesn't make sense to me. Most users are probably not aware that there is a separate hardware RTC. Why would one assume that the clock the user is not aware of is better than the clock the user can see and is presumably happy with? Roger
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
On 10/07/17 19:40, Marvin Renich wrote:
> There is an easy fix to revert the default behavior while still allowing
> knowledgeable sysadmins to get the new behavior. On the other hand,
> those who need to administer systems but are not sysadmins by trade (and
> thus will have to do significantly more research to even know that the
> older behavior is possible) are the ones who need the older behavior as
> the default.
This caught me out on a recent new installation, which gave me these new
names which are too complicated to be usable. I wasted hours working out
what had happened, how to fix it and how to write a udev rules file from
scratch. And having just read this thread, I've discovered that the rules
I've written are themselves apparently unreliable, for example:
SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"
Roger
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
On 13/07/17 12:40, Adam Borowski wrote:
> On Thu, Jul 13, 2017 at 05:17:57AM -0400, Tom H wrote:
> > On Wed, Jul 12, 2017 at 2:40 PM, Roger Lynn wrote:
> > > SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> >
> > It's simpler to use (for example)
> >
> > # cat /etc/systemd/network/77-en0.link
> > [Match]
> > MACAddress=1c:1b:0d:9a:34:98
> > [Link]
> > Name=en0
/etc/systemd/network/ doesn't exist on my system. I presume I would just
need to create it for this to work? I haven't been able to persuade
packages.debian.org to tell me which package it belongs to.
> There's apparently also a package "ifrename" which makes writing these
> rules more user friendly. And doesn't place them in obscure places that
> change every release.
Thank you to both of you and to others for all your suggestions. Of course
if I'd read the release notes first I could have saved myself some time, but
they are usually aimed at upgrades rather than new installations and I
haven't performed any upgrades yet. I am curious as to what mechanism will
be used to preserve names on upgrades when reusing the kernel names is such
a bad idea.
Is everyone using their own custom naming schemes actually a good idea, or
would it be preferable to have some standardised names?
Roger
PS Feel free to tell me to go to Debian-User. I hoped the experience of a
"hobbyist" user would be a useful contribution.
Re: RFC: "Recommended bloat", and how to possibly fix ito
On 06/11/2024 19:20, Bill Allombert wrote: > Le Tue, Nov 05, 2024 at 05:35:59PM -0600, Aaron Rainbolt a écrit : >> Hello, and thanks for your time. >> >> I've been a Debian user and contributor for a while, and have noticed a >> rather frustrating issue that I'm interested in potentially >> contributing code to fix. The issue is what I call "Recommended bloat", >> which in short is what happens when you install a package with all of >> its recommended packages, and end up with a whole lot of stuff installed >> that you don't want and that the package you actually wanted probably >> didn't even need. > > A proposal I made was an option for apt to handle Recommends non > recursively. > That is if A Recommends B and B Recommends C, > apt-get install A --no-transitive-recommends > would install B but not C. This, please! As a user, when I choose to install a package, I am likely to have a reasonable idea of what that package's recommendations do and whether I need them. However, for transitive recommendations, it is unlikely that I will know whether I need those packages. If they in turn have lots of further dependencies then I will probably not install them and take the risk of unwanted breakage to my system. If the top level package that I originally did want needs those transitive recommendations it should recommend them itself, rather than relying on recommendations further down the dependency chain. It would also be helpful if more package descriptions could explain why recommended and suggested packages are needed or helpful and what functionality they provide that would be lost if they were not installed. (Many already do this.) Thanks, Roger PS. I use aptitude, so I can interactively browse through the lists of recommendations, but it's still hard work and it can be a long list of very obscure packages. Do any of the GUI package managers show a graphical dependency tree? That might be really helpful to understand the package relationships and visualise the consequences of various actions. PPS. And the moon on a stick too, please!
Re: Directory structure suggestion for configuration in /etc
On 20/12/2024 12:30, Ansgar 🙀 wrote: > On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote: >> Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit: >> > It also avoids the problem of removed-but-not-purged packages. >> >> With files copied into /etc, you will still have configuration files >> lying around, and *not tracked*. > > That problem doesn't exist if you don't copy unneeded files to /etc. What happens to customised configuration files placed into an empty /etc when the relevant package is removed or purged? Roger
Re: Change the expectation that emails should wrap at 80 characters
On 03/03/2025 19:10, Soren Stoutner wrote: > On Monday, March 3, 2025 11:38:29 AM MST Philipp Kern wrote: >> Mine doesn't wrap properly either, especially on wide screens. Neither >> Thunderbird nor Roundcube. 80 characters are perfectly readable, >> long-lines are increasingly annoying to read. >> >> I can see how that part is a "me" problem. But it also worked perfectly >> fine before. > > As I wrote in another part of this thread, in 2025 any MUA that can’t wrap > received text to > the preference of the viewer deserves a bug filed against that MUA. For > example, every > graphical MUA of which I am aware (like Thunderbird and Roundcube, which you > mention) > can wrap text to the desired length by resizing the viewable window. If your > does not, I > would recommend filing a bug report against your MUA. In the common layout used by most graphical MUAs that I have seen, making the window narrow enough to wrap text at a sensible line length results in Subject, From and Date columns that are too narrow to read. I have just tried an alternative layout in Seamonkey (nee Mozilla) that puts the folder, thread and message panes side by side, which does work (especially if you have a large monitor or you are happy for it to use the full width), but does feel very odd. I expect that Thunderbird has a similar setting (and in reply to Blair Noctis, I am sure that Thunderbird properly supports format=flowed if properly configured (I have disabled it in Seamonkey, but am considering re-enabling as a result of this thread)).
