Bug#279983: general: scsi emulated cdrom ide unit can't be correctly mounted first time
Package: general Severity: important In my freshly rebooted computer (each time I reboot it): Each of the first times I try to do $ mount /cdrom I get an error answer: mount: /dev/scd0 no es un dispositivo de bloques válido (english: non valid block device) If I do # mount -t iso9660 /dev/hdc /cdrom I get another error, but this one is normal and expectable: mount: tipo de sistema de ficheros incorrecto, opción incorrecta, superbloque incorrecto en /dev/hdc, o número de sistemas de ficheros montados excesivo (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?) (english: incorrect filesystem type, wrong option, incorrect superblock or too many mounted filesystems) After that error, any try to mount the cdrom as usual goes OK, but it is always impossible to mount it before doing that. My box is a completely updated sarge. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Desktop poll app [Was: Reverting to GNOME for jessie's default desktop]
On Saturday, 9 de August de 2014 12:04:56 Axel Wagner escribió: [...] > I really think, in these kinds of discussions it would be helpfull to > get some kind of direct community-feedback. This would help *both* sides > in every of these discussions, because it would make it impossible for > either side to claim a widely held opinion that can not be refuted > easily. For example, if we could have a simple survey "do you prefer > the experience of gnome 3 or xfce" which any dev/maintainer/user could I have been thinking on this, and I have come with an idea. I admin possibly a stupid one, but I want to know what do you all think on it. Imagine a Desktop application, than fires on start (on every desktop environment, maybe wxwidgets, I do not care just now) and on first desktop boot after install. It asks these questions: 1) (LOCALIZED) Would you want to help Debian by taking some surveys? a) YES b) NO Only if YES 2) (LOCALIZED) Would you like to take the surveys in English, as soon as they are released, or wait until they are translated to your language? a) English as soon as released b) Wait 1 week for translation, english if not translated then c) Wait 1 month for translation, english if not translated then d) Only when (if ever) translated After this simple per-user configuration, the app (ONLY if YES to question 1) will fire invisibly once a day and check some server via HTTPS (e.g. polls.debian.net) for polls and sets of answers. If any is found there, it is presented to the user, and if the user answers it (there will be an option of "I do not want to answer this poll" in every poll) the answer will be sent to the same server via HTTPS, where it will be stored anonymously. No userid, not even IP stored with the answers. Do you like it? er Envite signature.asc Description: This is a digitally signed message part.
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
On Monday, 11 de August de 2014 16:34:04 Matthias Urlichs escribió: > Hi, > > Lennart Sorensen: > > it needs buttons on windows that people expect to see where they expect > > to see them > > You mean left vs. right side? > > > Would Debian be willing to make gnome3 have different defaults than > > upstream in the interest of actually being useable to new users who are > > used to other operating systems and desktops? > > People who are so afraid of new stuff to learn that they won't even figure > out how to close a window are not Gnome's (or XFCE's, for that matter) > target audience. > If you want that, install KDE and tell it to use one of the > let's-mimic-Windows/MacOS themes. I think we should not care about Gnome's target audience, but about Debian's target audience. Remember Debian Social Contract , #4. Regards er Envite signature.asc Description: This is a digitally signed message part.
Re: Cinnamon environment now available in testing
On Friday, 5 de September de 2014 02:37:18 Cameron Norman escribió: > On Thu, Sep 4, 2014 at 4:51 PM, Adam Borowski wrote: > > On Thu, Sep 04, 2014 at 02:57:16PM +0200, Margarita Manterola wrote: > >> On Thu, Sep 4, 2014 at 9:43 AM, envite wrote: > >> > Does this Cinnamon for Debian include systemd ? > >> > >> Yes, for Linux it includes systemd. For kFreeBSD it should be able to > >> work without systemd, but some packages haven't compiled yet due to > >> missing dependencies. > > > > If Cinnamon can work without systemd, why is it a hard dependency? > > TL;DR `sudo apt-get install systemd-shim` > > You are mistaken, it is not. What I suspect happened is that something > depended on logind (libpam-systemd) and libpam-systemd depends on > "systemd-sysv | systemd-shim". This means that systems will have their > init system switched even if unneeded unless they predict the issue or > track down the dependency tree, then learn they have to install > systemd-shim (which does not exist on Wheezy, so you will have to > install systemd-sysv then another init after the upgrade). This bug > has been reported and marked as WONTFIX for reasons that have not been > fully explained (it is claimed people with init=/lib/systemd/systemd > in their kcmdline will experience breakage due to systemd-shim > conflicting with systemd-sysv, however this is actually not likely at > all according to the shim maintainer). > > Best, > -- > Cameron Norman So we are clearly failing to follow the least surprise (for the user) path. Should not logind depend on systemd-shim | systemd-sysv instead? Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Jessie without systemd as PID 1?
On Wednesday, 3 de September de 2014 16:21:31 Svante Signell escribió: [...] > should be allowed, and I'm trying to find out how many of debian users > and developers are interested in working together with me on such a > solution. Best would be to have an option in the installer (hidden by [...] I volunteer to test this, not for contributing (I am not a programmer), for a very simple reason: I do not want my long-running servers (and those of my clients) to be rebooted for something that should be so simple as upgrading a service or applying some non-kernel security patch. I may have (I agree I have) some conservative thinking. I've been well against network-manager messing my interfaces and I'm against systemd as well, but I really think the Unix way, when properly implemented, is the way to go. And if it does not work, make it work instead of building a dinosaur and force dependencies into it (and yes, I'm pointing at you, Gnome Debian packagers, both for network-manager and systemd). In resume: count on me to test and check and report bugs and triage. Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Cinnamon environment now available in testing
On Friday, 5 de September de 2014 09:57:34 Josselin Mouette escribió: > Noel Torres wrote: > > So we are clearly failing to follow the least surprise (for the user) > > path. > > > > Should not logind depend on systemd-shim | systemd-sysv instead? > > No. Systemd is the default init system. The default dependencies should > reflect that. > > And from a purely functional point of view, it makes more sense to bring > by default the standard, upstream-supported, well-tested solution, than > the Debuntu-specific hack to use it with an inferior init system. > > Cheers, "Inferior" is your personal (and others) opinion. I do not think systemd being clearly superior. It has better points that sysvinit but also worse points (already extensively discussed). So that is not a reason to force users install systemd when they are just upgrading their currently working systems. So: * standard: we chose so (against the opinion of a lot of people), nothing more to discuss about that * upstream-supported: not exclusive to systemd * well-tested: not true. sysvinit is the well tested, and well known one (including its quircks and lacks) * superior: plain no Regards signature.asc Description: This is a digitally signed message part.
Re: systemd, again (Re: Cinnamon environment now available in testing)
On Friday, 5 de September de 2014 21:36:43 Ansgar Burchardt escribió: > Nothing prevents you from a, installing systemd-shim from Jessie before > running apt-get dist-upgrade or b, using "apt-get dist-upgrade upstart". > > I'm fairly sure I saw this question also answered on -user@ once or > twice times (which is also the appropriate list to ask such questions). > > Ansgar So, in your POV, forcing millions of sysadmins out there to take extra pain to keep their systems running as they expect is the way to go? Do you really expect millions of users to read and understand the (sometimes cryptic) release notes explaining that they must perform a not straightforward upgrade just to jave their systems up to date? Do you think it is realistic to expect them all reading some obscure documentation _before_ upgrading? Experience shows us that most of our users just do not read the Release Notes, and those who do that do it mostly after havin encountered some problem. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)
On Friday, 5 de September de 2014 18:52:44 Zack Weinberg escribió: > Abstractly, I believe the ideal situation would be for all init systems > in the archive to be *completely* co-installable, with /sbin/init a > symlink under control of the administrator; under no circumstances would > installing or upgrading any package change that symlink. (It follows > that systems upgraded from wheezy might wind up with systemd > _installed_, but sysvinit would remain the active init until the local > admin changed things manually. Obviously this would need to be > documented.) I was thinking on all of this yesterday, when walking back from work to home, when I realized it: It is just wrong to have dependencies on the init system. If you need dbus, you should Depend on dbus, and systemd should Provides dbus. Then, if Ann programs her Own Dbus Implementation she can package it as aodi (Ann's Own Dbus Implementation) and have aodi Provides dbus. Same for logind (systemd Provides logind and random-package Depends logind), and any other piece of the big systemd ecosystem. Any dependence on systemd or any other init system should be considered an RC bug (except only packages designed to manage the init system, like an imaginary systemd-tweaking-tool). Do you need a cron system for a daily task? Just depend on timely-task, and have both systemd and cron provide timely-task. This way we put the decision, and thus the power to configure their systems, back in sysadmins hands, instead of stealing that power for us. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Cinnamon environment now available in testing
On Sunday, 7 de September de 2014 23:45:12 David Weinehall escribió: > On Fri, Sep 05, 2014 at 12:37:12PM -0700, Cameron Norman wrote: > > On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette wrote: > > > Noel Torres wrote: > > >> So we are clearly failing to follow the least surprise (for the user) > > >> path. > > >> > > >> Should not logind depend on systemd-shim | systemd-sysv instead? > > > > > > No. Systemd is the default init system. The default dependencies should > > > reflect that. > > > > It has already been explained that it being the default makes the > > order switching irrelevant for what you recommend. If people are using > > the default init, the dependency will already be satisfied and life > > will not be disrupted. The same thing should happen if people are > > using a different init: that decision should be maintained unless they > > manually uninstall the package that satisfies the init package's > > dependency. > > Most Debian systems aren't using sysvinit by active choice, but because > it was the default when they installed their machines, so this argument > doesn't really make sense. Does that mean that we can happily break their hand made configurations for their was-default current init system? If our priorities are free software and _our users_ of course not. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: systemd, again (Re: Cinnamon environment now available in testing)
On Sunday, 7 de September de 2014 16:11:02 Matthias Urlichs escribió: > Hi, > > Chris Bannister: > > > If technically feasible, that would be a far better safety net (just > > > tell people to boot with init=/sbin/sysvinit if they run into a > > > problem) than an "oh dear, it's so dangerous that we don't even > > > install it by default" message. :-/ > > > > Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking > > upgrades here, not new installs. > > I am talking "if we decide to use a configurable symlink, then > surely systemd will have the highest priority". [*] > > Yes, that does mean that, if you do not do anything else, your system will > boot with systemd. Which IMHO is as it should be. I do not challenge systemd being the default, but I want my own systems with configured sysvinit scripts not to be switched. Example: having EMC Networker server softare for backups in a sysvinit machine is (relatively) easy, because the scripts for starting and stopping the services are (quite) standard (but very complicated) sysv scripts. Migrating that machine to systemd just renders tens of thousands of euros useless because the backup server software will not start. > > Quite frankly: If you're savvy enough to do something to your init setup > that is no longer supported, and at the same time stupid enough to upgrade > to Jessie without reading the release notes _and_ ignore systemd-sysv's > debconf notice (which doesn't exist yet, but should probably be added), > then that's your own damn fault. Frankly I know lots of people who fall in that category (savvy enough and what you dismissingly call "stupid enough") who would benefit a lot for that debconf notice. We should make sure that it helps also people doing remote upgrades on console command line. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió: > ]] Carlos Alberto Lopez Perez > > > But if you don't (Is not uncommon to have servers on remote locations > > that are only accessible via ssh) and the machine don't boots properly > > you can find yourself in trouble. > > Then surely you test the upgrade before making it live, using kvm > -snapshot or similar functionality? This is simply not possible in physical live, productions servers on remote CPDs. Regards signature.asc Description: This is a digitally signed message part.
Re: Seeking help with OpenVPN scripts and systemd
On Tuesday, 9 de September de 2014 16:51:20 Alberto Gonzalez Iniesta escribió: > AltSubject: For those who care about OpenVPN > > Dear fellow developers, > > This is a cry for help. I've been trying to support systemd in OpenVPN for > some time, but the results are not satisfactory. I'd like to keep the > current (SysV) behaviour in systemd but it's becoming quite an annoying > task. > > I'd love to hear recommendations, receive patches or any other help with > this. Let me explain what the SysV init script did, so you can figure out > what I'd like to achieve. If you aren't interested in the task you may > skip the rest of this mail. > > What was working? > - > > First of all, openvpn in Debian is able to run several VPN daemons. > Depending on the value of the configuration variable AUTOSTART (in > /etc/default/openvpn): - all -> A daemon for each of the configuration > files found in /etc/openvpn - none -> Do not manage any VPN (they can be > started manually or through a directive in /etc/network/interfaces > - A list of the VPNs you want automatically managed (i.e. AUTOSTART="work > home"). The rest can be managed manually. > > In order to be able to control individual VPNs the init.d script accepts a > second argument (after start/stop/...) with the name of the VPN to manage. > I know this was a hack, but it worked like a charm. This is no longer > possible with systemd. > > stop, reload, soft-restart and cond-restart will only affect running VPNs. > The last one is specially important in upgrades, when the currently running > daemons have to restart. That includes those VPNs that are managed > automatically (in AUTOSTART) *and* those started manually or through a > network/interfaces directive. Whereas restart will only affect those > managed automatically unless a VPN name is specified. > > In addition to the init.d script, there are two script in > /etc/network/if-(up|down).d/openvpn that allow for VPNs to be managed when > interfaces are brought up or down. So you may have AUTOSTART=none, or > AUTOSTART="home office", and then enable "work" tunnel when only when using > a specific network interface. > > Where are we now? > - > > The latest version of openvpn's package (in experimental) includes two > service files for systemd. One instantiated (openvpn@.service) allows the > control of single VPNs, piece of cake. > > The main issue is with the other one, openvpn.service, that tries to > replace the old init.d script and all its features. It is, currently, > calling a helper script that (tries to) mimic(s) the former behaviour. > > First of all, the script can only be called with start, stop or reload > arguments. So no distinction can be made between a restart and a > stop-then-start. So there's no way (i.e. on an upgrade) to restart all > VPNs (those in AUTOSTART *and* those manually controlled), since "start" > and "stop" should only manage those in AUTOSTART. > > Another problem is the package upgrade to systemd in a running system, > since the VPNs started with the current init.d script are not recognized > by openvpn@NAME.service. So when upgrading the package from the > non-systemd-enabled package (< 2.3.2-7) to the package with the service > files, we end up with two active VPNs (the one that was running, and one > started by systemd) for each AUTOSTARTed configuration. > > If you know systemd and would like to help with this please Cc: me (since > I'm not subscribed to -devel) or mail me directly. You may find the > current git repo for openvpn in Debian at: > git.debian.org/git/collab-maint/openvpn.git > > Thanks, > > Alberto Hi Alberto openvpn package should Conflitcs systemd in order to avoid systemd being installed and so messing with OpenVPN-working systems, until systemd gets appropiately fixed or you get a workaround. Regards er Envite signature.asc Description: This is a digitally signed message part.
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió: > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote: > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió: > > > ]] Carlos Alberto Lopez Perez > > > > > > > But if you don't (Is not uncommon to have servers on remote locations > > > > that are only accessible via ssh) and the machine don't boots > > > > properly you can find yourself in trouble. > > > > > > Then surely you test the upgrade before making it live, using kvm > > > -snapshot or similar functionality? > > > > This is simply not possible in physical live, productions servers on > > remote CPDs. > > In that case you test on your staging server first... > > Ben. IF you have an staging server... some clients simply do not pay for it. Regards signature.asc Description: This is a digitally signed message part.
Re: Seeking help with OpenVPN scripts and systemd
On Wednesday, 10 de September de 2014 05:25:44 Andrey Rahmatullin escribió: > On Tue, Sep 09, 2014 at 09:26:28PM +0100, Noel Torres wrote: > > openvpn package should Conflitcs systemd in order to avoid systemd being > > installed > > ITYM "to avoid openvpn being installed". No, I mean what I wrote: to avoid systemd to be installed on upgrades to machines where OpenVPN is currectly working fine and whose configuration could not work, as explained by the OP Regards signature.asc Description: This is a digitally signed message part.
Re: Seeking help with OpenVPN scripts and systemd
On Wednesday, 10 de September de 2014 18:55:06 Adam D. Barratt escribió: > On Wed, 2014-09-10 at 17:47 +0100, Noel Torres wrote: > > On Wednesday, 10 de September de 2014 05:25:44 Andrey Rahmatullin escribió: > > > On Tue, Sep 09, 2014 at 09:26:28PM +0100, Noel Torres wrote: > > > > openvpn package should Conflitcs systemd in order to avoid systemd > > > > being installed > > > > > > ITYM "to avoid openvpn being installed". > > > > No, I mean what I wrote: to avoid systemd to be installed on upgrades to > > machines where OpenVPN is currectly working fine and whose configuration > > could not work, as explained by the OP > > At least on a newly-installed system, however, it would have exactly the > effect that Andrey described. > > Regards, > > Adam Yes. Why to install OpenVPN which might not work? aptitude will tell you that they are not coinstallable and the sysadmin will then have the option of switching init system to a non default one, knowing what that means, and having a working OpenVPN config, instead of (possibly) having a failing config and no clue about why. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Trimming priority:standard
On Sunday, 14 de September de 2014 17:04:10 Stefano Zacchiroli escribió: > On Sat, Sep 13, 2014 at 11:17:34AM -0700, Josh Triplett wrote: > > I'm not arguing that "standard" should have nothing in it; it should > > have things that the vast majority of users will 1) expect to find > > present without having to install them and 2) actually use or care > > about. > > I sympathize with the sentiment, but AFAICT the only way to implement > such a specification would be to actually *ask* our users, and (by > definition) a thread on -devel cannot work to that end. It seems to me > that the only way to implement that spec would be something like a > broadly advertised user survey, with specific questions about the > packages you are interested in. > > Cheers. Here it can come back my idea about a desktop survey/poll app. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Thursday, 11 de September de 2014 08:00:57 Marc Haber escribió: > On Thu, 11 Sep 2014 00:04:07 -0300, Martinx - ? > > wrote: > > Also, during Debian 8 installation, please, provide an "altinit" option ( > > > >http://pyro.eu.org/debian/pool/main/d/debian-altinit/ ?), so, people can > >choose between systemd / sysvinit (before 1st boot). I know that it seems > >easy to just "apt-get install sysvinit-core" after install (1st boot) but, > >at least, Debian users will have an option to select a well tested, init > >system, while it is fully supported. > > Please note that our init scripts are going to be a lot less reliable > in a world where only a fraction of our users will actually use them. > > Many maintainers will reduce their priority on the to-do list. > > Greetings > Marc Thay _you_ will reduce their priority in your to-do list does not mean that many will do. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wednesday, 10 de September de 2014 21:26:50 Matthias Urlichs escribió: > Hi, > > Steve Langasek: > > On Wed, Sep 10, 2014 at 08:28:36PM +0100, Marcin Kulisz wrote: > > > What about cases when init scripts doesn't come from any package but > > > are crafted by hand? > > > > It's straightforward to check for init scripts that are not owned by any > > packages. > > … and besides, systemd should just work with them. > If they descend from /etc/init.d/skeleton, that is. > > Not having the requisite metadata at the top of the script might me a more > reliable indicator than not belonging to a package. I would bet that most hand made init scripts do not descend from /e/i/skeleton, and they have runlevels and such crafted also by hand on the specific system where they are deployed. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Trimming priority:standard
On Tuesday, 16 de September de 2014 22:17:51 Joerg Jaspert escribió: > On 13698 March 1977, Didier Raboud wrote: > >> > One thought... there will probably be trademark concerns with > >> > "unix".[1] So we might have to choose a name for the tasksel task > >> > to be someting like "unix-like". > >> > >> Or we could just call it "standard system". > > > > Could we make sure the full "vim" is in that then? I miss it on every > > new installation and I'm quite sure that's not uncommon. > > ONLY if we put emacs there too, cos I miss that way more than any vi* > ever. With vi actually being the first thing to get removed, so that > would be better way out of standard *IMO* > > (*lala*) Trying to start another flamewar? Let's stop this here. There are vi lovers and emacs lovers, and having the freedom to choose is great. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Bug#762116: marked as done (general: Some packages depend on a particular init system)
> I'm closing this bug because this ain't a general bug in Debian. Some packages > depend on Gnome too (or KDE or some obscure OCAML library) and it's no secret > mean conspirancy that they do so, but rather relying on some feature > somewhere. Aka: "business as usual". > > Please direct your energy elsewhere than into useless bug filing. Code changes > the world. So, Holger, are you saying that failure to accomplish our goal of supporting several init systems is not a bug? Would you ask a random user (not a developer) to develop code if he notices that e.g. installing brasero changes his init system? Closing bugs because you do not want to acknowledge that there is really a problem is hardly a solution. systemd is the default we choose, not something we should impose on all users wherever they want or not at the least opportunity. A cd writer changing an init system is not "bussiness as usual". Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: A concerned user -- debian Guidelines
olunteer? Sure as hell Debian will benefit for a new, shiny, well-designed init system in the UNIX principles tradition. Will you write it? [...] > > Especially when this breaks so many of my systems. Of course I could spend > time to learn the new init, a change all of my systems to fit the new init > system. But this will cost me time. Time I will not spend on other free > software projects. It will cost time to so many people. If you do not upgrade to Jessie, nothing will break. And it seems we will make it work not to break anything even on upgrades. > > Yes, making an init-independent system is more work than the easy, "single > init" solution. But I think there are people out there which will be > willing to spend time on this. People with the ability to do it, to face > the challenge and succeed. > Be the first distribution to be init system independent, and propose a way > for users to choose between different init systems. This would allow > integration of other init systems in the future, and make Debian stronger, > safer, more reliable, and once more, more universal. Of course, this means > more work, and maybe delayed releases. But I though that Debian had no > "release schedules". "It's done when it's done". I fully agree with this. How would you contribute to make it happen? > > Other distributions may have chosen the easy single init way, but Debian is > not other distributions. And uniformity is not an option. > Should It be, let's forget about all Linux and GNU stuff, and all of us > move to another system (let's not name it here), for the sake of > uniformity. > But GNU/Linux is NOT uniformity. It is choice. It is alternatives. It is > options. How many window systems can you choose among? How many C libraries? How many *really* different kernels? We are about choice between free software and propietary software, choice between freedom and slavery, but not everything on a Free Software system should (or can) be chosen. I agree, anyway, that we should be able to choose init system and boot loader, but do not put alternatives so high in the stair. [...] > Please make me (us ?) happy again. Happy of using Debian, wearing my Debian > Tee-shirt despite whatever people can tell me about it, and happy of > "spreading the word", making others choose Debian for it's social value as > much as it's technical one. Happy of contributing to free software, if not > directly to the Debian project. What do you really advocate for, that is not being worked in? Regards Noel Torres er Envite Debian Maintainer, Debian (and Mint and Red Hat and Ubuntu and Windows and Solaris and Android) User, Debian (and Tor) Translator, Debian (and KDE) Bug reporter, Debian (and Mint and Red Hat and Ubuntu and Windows and Solaris) Systems Administrator, Debian systemd hater, Debian lover, not a Debian Developer Just open your mind and try to see a bigger picture signature.asc Description: This is a digitally signed message part.
Re: Technical committee acting in gross violation of the Debian constitution
On Monday, 17 de November de 2014 20:20:56 Josselin Mouette escribió: > First, Don, I’d like to thank you for keeping the discussion civil. I > have made a serious accusation, and I don’t want it to be an excuse for > a mudfight. The point is not that you have made a serious accusation. It is your right to do so, if you feel something is wrong. I would even say that it is your duty. The point is that you requested (you 'urged') maintainers to ignore a CTTE decision that has not been overturned. This is not being civil. I strongly support the CTTE decision of systemd being our default, as well as this one. In fact, any CTTE decision. And if I someday find that a specific CTTE decision is wrong, I'll work to overturn it, either by providing further evidence or by convincing somebody of some aspect that they may not have seen. But not by requesting maintainers ignore a decision. I have had a hard moment while writing this, because what I really wanted to write was in a very different mood, but I do not want (another) mudfight. Keep Debian civil. Do what the CTTE has ruled, and if you feel it is wrong, raise the case again, or try to overturn the CTTE decision by the correct means. Have you tried to grab the Secretary's opinion about if the Constitution has really been ignored? I think it has not been, and you think it has, and we can agree that we disagree, but The Right Thing here is not what you did. Regards er Envite signature.asc Description: This is a digitally signed message part.
Re: Bug#769907: general: non-sysvinit init systems are made of fail
On Thursday, 20 de November de 2014 17:53:27 Marco d'Itri escribió: > On Nov 20, Sam Hartman wrote: > > The first issue (fstab now fatally blocks boot) is something the systemd > > maintainers have considered (as I understand it) and rejected. > > The behaviour of systemd will not be changed, but I have plans to add > a fstab sanity check to preinst. Just for my sanity of mind. Is this referring to entries in fstab that have the auto option (either directly or via defaults)? Thanks er Envite signature.asc Description: This is a digitally signed message part.
Re: systemd, fstab, noauto and nofail
On Thursday, 20 de November de 2014 20:44:17 Simon McVittie escribió: > On 20/11/14 19:06, Noel Torres wrote: > > On Thursday, 20 de November de 2014 17:53:27 Marco d'Itri escribió: > >> On Nov 20, Sam Hartman wrote: > >>> The first issue (fstab now fatally blocks boot) is something the > >>> systemd maintainers have considered (as I understand it) and rejected. > >> > >> The behaviour of systemd will not be changed, but I have plans to add > >> a fstab sanity check to preinst. > > > > Just for my sanity of mind. Is this referring to entries in fstab that > > have the auto option (either directly or via defaults)? > > Yes, I'm pretty sure this is referring to entries in fstab that do not > have the noauto and/or nofail options. > > systemd tries to mount each filesystem listed in fstab that does not > have noauto. If one of them fails, it checks for the nofail option; if > given, it carries on regardless and hopes for the best. If nofail was > not given, it considers the failure-to-mount to be potentially serious > breakage, and drops into an emergency shell. > > noauto is appropriate for detachable/removable media that are not > normally present. The other option for such media is to leave them out > of fstab altogether, and use something like udisks to mount them > on-demand: that's what you'd typically do in GNOME or KDE or whatever. > > nofail is appropriate for media that are normally present, but not > important enough to make the boot fail entirely; if you mount > non-essential data directories via NFS then maybe that should be nofail? > > S Many thanks I do not understand, then, how this is different from what sysvinit's mountall.sh does (or at least what I understand it does). Thanks Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: systemd, fstab, noauto and nofail
On Sunday, 23 de November de 2014 15:09:53 Vincent Danjean escribió: > On 20/11/2014 21:44, Simon McVittie wrote: > > noauto is appropriate for detachable/removable media that are not > > normally present. The other option for such media is to leave them out > > of fstab altogether, and use something like udisks to mount them > > on-demand: that's what you'd typically do in GNOME or KDE or whatever. > > I found another issue with systemd and noauto. > I've a card reader that export various hardware port as different devices. > As, when I use it, I want to see my photo in /media/photos whatever > physical card type I use (it depends from which camera the card come > from), I have several lines in /etc/fstab : > /dev/disk/by-id/usb-Generic_USB_SM_Reader_058F412D8PB1-0:2-part1 > /media/photos vfat > noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,f > lush 0 0 /dev/disk/by-id/usb-Generic_USB_SD_Reader_058F412D8PB1-0:0-part1 > /media/photos vfat > noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,f > lush 0 0 > /dev/disk/by-id/usb-Generic_USB_SM_Reader_100-0:3-part1 > /media/photos vfat > noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,f > lush 0 0 /dev/mmcblk0p1 /media/photos vfat > noauto,user,rw,nosuid,nodev,shortname=lower,umask=0133,dmask=0022,utf8=1,f > lush 0 0 > > It always worked for me. I never put several cards at the same time > and I always found my photos under /media/photos. > > But, with systemd, I get at boot time a warning about systemd > not being able to correctly create generators (or something like > that) and, at runtime, my photos are not mounted under > /media/photos or not with the options I specify (I need to check > that exactly) > > Do you think I should do a bugreport ? > > Regards, > Vincent Yes, please do so. Admin should be able to point several media to be mounted to the same mountpoint, and if systemd can not cope with that, it is a bug in systemd. Anyway I see that you do not use the noauto option. Is that on purpose? Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: systemd, fstab, noauto and nofail
On Monday, 24 de November de 2014 07:33:38 Matthias Urlichs escribió: > Hi, > > Noel Torres: > > Anyway I see that you do not use the noauto option. Is that on purpose? > > What? It's the very first option. My fault. My eyes looked for "defaults,noauto" while I was searching for just "noauto". > > In any case, I can see why three entries for the same mountpoint don't > exactly fit systemd's view of the world -- I wouldn't get that idea either, > since "mount /media/photos" doesn't know which device to check. > > Thus, I'd fix this problem in a different way -- either with an udev rule > that sets an appropriate symlink and/or outright mounts the volume when > something gets inserted, or with udisksctl, or by telling your desktop > environment to auto-mount. Agreed, I would have used udev as well. Problem is that udev documentation is not as widely spread as fstab documentation, and also not as easy. Anyway, systemd getting into the Admin's way is a bug. Everytime an app does that, it is a failure either in the app, or in the developer's view of the world. Not the same for the regular users, tough. There usually Admin wants users to be unable to do this or that. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Technical committee acting in gross violation of the Debian constitution
On Monday, 17 de November de 2014 20:45:19 Josselin Mouette escribió: > -- > .''`. Josselin Mouette > : :' : > `. `' > `- On Tuesday, 25 de November de 2014 17:30:38 Stephen Gran escribió: > Cheers, > -- > - > > | ,''`.Stephen Gran | > | : :' :sg...@debian.org | > | `. `'Debian user, admin, and developer | > |`- http://www.debian.org | > > - Why is it that systemd proponents are the ones using this kind of signature? Are they trying to insinuate that Debian is theirs? Transformig Debian in something different than Debian (the community-driven rock-solid Universal distribution we loved to put on our servers) may be allowed by being a majority of DDs, but it is not loving Debian. Systemd is a wonderful system. For laptops. Gnome is a great Desktop. For novel-users laptops. And Debian uses to be a great and wonderful distribution, for servers, desktops, laptops and embedded systems. And it is about to stop being wonderful for servers and embedded systems. This is not a defense of sysvinit. It is venerable, and that implies it is old. Not suitable for some modern tasks. But it happens that those modern tasks are not those needed on servers. I definitely do not want automount nor binary logs on a server. I want an independent time daemon on the server. I want static, trustable network configuration. I want the server not to stop booting if some disk goes wild. I want to be able to SSH into a headless machine as soon as possible, to debug its booting process if necessary. And all that is not the default in the next Debian release (with the exception of binary logs). And I'm not alone with all those "I want". So, forget the question about the signatures. It was just a teaser. Answer the real question. Forget about who our developers are. Who our users are? signature.asc Description: This is a digitally signed message part.
Re: Technical committee acting in gross violation of the Debian constitution
On Tuesday, 25 de November de 2014 19:50:48 Axel Wagner escribió: > Noel Torres writes: > > Why is it that systemd proponents are the ones using this kind of > > signature? Are they trying to insinuate that Debian is theirs? > > Wow! A dipshit crazy conspiracy theory about systemd and its > proponents. Haven't seen one of those in a long time… Sarcasm welcomed :) Anyway, I would like to read your answer to the REAL question written at the end of the message. Regards er Envite signature.asc Description: This is a digitally signed message part.
Re: Technical committee acting in gross violation of the Debian constitution
On Tuesday, 25 de November de 2014 20:15:36 Andrey Rahmatullin escribió: > On Tue, Nov 25, 2014 at 08:03:44PM +0000, Noel Torres wrote: > > > > Why is it that systemd proponents are the ones using this kind of > > > > signature? Are they trying to insinuate that Debian is theirs? > > > > > > Wow! A dipshit crazy conspiracy theory about systemd and its > > > proponents. Haven't seen one of those in a long time… > > > > Sarcasm welcomed :) Anyway, I would like to read your answer to the REAL > > question written at the end of the message. > > I think I'm not the only one who stopped reading your email after that and > so didn't see that question. > Please stop. *Now* that you know there is a real question beyond the sarcasm, which is your answer to it? Citing myself: Answer the real question. Forget about who our developers are. Who our users are? signature.asc Description: This is a digitally signed message part.
Re: Technical committee acting in gross violation of the Debian constitution
On Wednesday, 26 de November de 2014 02:23:20 Paul Wise escribió: > On Wed, Nov 26, 2014 at 3:41 AM, Noel Torres wrote: > > Who our users are? > > Debian's users are the set of people and organisations who use Debian. Exactly. Who they are? The people who chose Debian, are they laptop users? desktop users? sysadmins? The question is important. > That is changing every day as people discover Debian, discover other > systems they like better, discover something about Debian they don't > like, try a system that is new etc. Since there are no monetary or > other restrictions on downloading and installing Debian, we can't know > the exact set of people and organisations who use Debian but there are > some indicators of who they are (see below). But we can have estimates. popcon gives us 98681 installations of libgnomevfs2-common (which may indicate desktop or laptop users) and 96647 installations of apache2.2-bin (which may indicate server users). Not a big difference. > > I expect you don't actually want to know who uses Debian but who the > people involved in Debian want or don't want to be using Debian. > Debian's motto has been "The Universal Operating System" for a long > time and Debian folks often talk of world-domination; I think it is > safe to say that Debian folks want Debian to be used by everyone, > including those who have a particular preference of init systems. I'm sorry but you're wrong here. I actually want to know who uses Debian, not which groups are better suited to the desires of some contraposed groups of developers. > > Here are the set of Debian contributors, presumably most of them use > Debian in some capacity: > > https://contributors.debian.org/ > > Here are some examples of organisations using Debian: > > https://www.debian.org/users/ > > Here are some indicators of how many systems run Debian: > > http://popcon.debian.org/ > http://w3techs.com/technologies/details/os-debian/all/all > http://linuxcounter.net/distributions/stats.html > http://linuxcounter.net/distribution/Debian+GNU_S_Linux.html > https://wiki.debian.org/Statistics#mirrors I already know these. The question is not "how many are there" but "who they are". It is great to know that we have millions of users, but who are they? Specifically, are these machines servers or desktops/laptops? The question is important because most of the distribution about switching to systemd by default has been centered about the important questions of technical feasibility, manpower required to maintain a distribution with more than one init system widey installed, manpower to perform the required changes to support multiple init systems in Jessie, and so on, but it has not been centered about the most important question: our users. It is a gut feeling, one that I share with systemd proponents, that Debian's desktop experience will be better for our users with systemd. It is a gut feeling also, and one that has been widely expresed by others, (with better and worse words) that Debian server admins will not be pleased with an init system which is bigger and does not use shell scripts to start system services. Inconveniences have been stated about binary logs (which has been expressed that it is not true), big binary, tightly related set of binaries, security relying in developers and packagers and not sysadmins, encompassing of not-init-related services, and more. So to know which of these two approachs is better for our users, which is what our Social Contract, 4, impose on us, we need to know who our users are. Without knowing that, we can not be true in deciding about switching or not on upgrades to best serve our users. Regards Noel Torres er Envite signature.asc Description: This is a digitally signed message part.
Re: Technical committee acting in gross violation of the Debian constitution
On Friday, 28 de November de 2014 07:45:29 Josselin Mouette escribió: [...] > This is nothing short of bullying. If you want to help our users, you > can contribute to debianfork, or you can improve your packages in > Debian. But spreading your bitterness on development forums is only > about hurting people. So do you prefer to expel Debian contributors to Devuan if they do not agree to systemd rather than adressing their concerns? signature.asc Description: This is a digitally signed message part.
Re: DE features dependent on Systemd
On Sunday, 30 de November de 2014 13:55:04 Vincent Bernat escribió: > ❦ 30 novembre 2014 12:50 GMT, Ivan Shmakov : > > > PolicyKit rely on logind to know if a user is locally connected. A > > > non-local user won't be allowed things like network management, local > > > device mounting or sound card access. > > > > That looks like a problem to solve, not a feature. > > [...] > > I really don't care. You asked why PolicyKit needed systemd, I answered > that. You are free to not use it. Would it be more correct to say that PolicyKit needs logind, not systemd ? Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Technical committee acting in gross violation of the Debian constitution
On Sunday, 30 de November de 2014 18:05:54 Neil Williams escribió: [...] > Contribute code or stop wasting everyone's time on the mailing lists. Contributing code is not the only way to contribute to Debian. At least to the Debian I love. Please come out of the developer shell. Translators, e.g. are a very important part of the project, even if they have not been give the same voting status as so-called "Debian Developers". Please stop THAT. > > Nothing will change without someone doing the work - whatever the issue. That is true. But no work can be done if nobody realizes that it needs to be done. > If that isn't you, then do everyone a favour and stop posting to these > endless threads. True, these posts are becoming endless. If you read my posts on them, you'll notice I acknowledge for systemd being the default on Jessie. It was our TC decision and I can not do anything but acknowledge it. It does not matter if I like systemd or not. And it does not mater if systemd is buggy or not, fit for release or not. But still there is place to decide a lot of other things about systemd. The GR did not resolve the issue of switching by default or not, to name one. This is my contribution now, to try to raise issues in a calm manner. Exactly the same issues most of our users have and some of our maintainers seem to not address properly. It has been expressed before: This is not only a discussion about technical issues. Regards er Envite signature.asc Description: This is a digitally signed message part.
Re: delete my resume in your web site
On Wednesday, 3 de December de 2014 02:48:33 Jenny zhou escribió: > HI, > > I requested many time. but my resume is still on your web site. > > Can you help me to delete that? > > https://lists.debian.org/debian-devel/2004/07/doc_9rK_X0lC5.doc > Cached > Thanks, > > Jenny Did you sent it to the list in 2004? Regards er Envite signature.asc Description: This is a digitally signed message part.
Re: tzdate 2016d update (released 2016-04-17) for future time stamps
Aníbal Monsalve Salazar escribió: On Tue, 2016-04-19 08:08:22 -0430, German Cardozo wrote: Hi! A new version of tzdata is available, tzdata2016d (released 2016-04-17). The latest version affecting future time stamps: America/Caracas Asia/Magadan Asia/Tomsk In Venezuela we are very interested in the update of this package on Debian 7 and 8 will be soon, because we have many machines installed with this operating system and its derivatives. We thank the team of Debian developers for all the support they can offer. Regards, -- German Cardozo Chirinos ~ memento mori ~ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821147 In case you do not get the update on time (e.g. if your machine follows some strict update policy) you can switch from Caracas to La Paz: "Indicó Arreaza que, en aparatos electrónicos y computadoras, usted puede poner la zona horaria de La Paz, Bolivia, que es -4 UTC." Regards Noel Torres er Envite binLkzqPJqdvi.bin Description: Clave PGP pública
