Re: Jessie without systemd as PID 1?
Hi! I'm wondering here... Lets suppose I NEED to use sysvinit, with Debian 8. If so, can I just run: `apt-get install sysvinit-core` to get rid of systemd as my INIT? If yes, will this be support until... Let's say, Debian kFreeBSD still remains around...? Also, why not have a system like "/etc/alternatives", or "dpkg-reconfogure alt-init" (just like "dpkg-reconfigure gdm/kdm"),so people can still choose between sysvinit / systemd as their default INIT? Maybe during install time!? Listen, I'm not a systemd-hater (or lover) but, I'm just saying that, for safety, I think we need to keep `sysvinit-core` working until ~2020. Just in case... I'm not saying NO to systemd, I'm just saying, not now (specially if it if brings some level of instability here and there)... Long life to Debian / Ubuntu! BTW, my first message to this list... :-) Thanks! Thiago On 3 September 2014 06:34, Rens Houben wrote: > In other news for Wed, Sep 03, 2014 at 11:11:30AM +0200, Svante Signell > has been seen typing: > > > Some food for thought about systemd: > > ... I thought we'd all agreed to stop bringing up tired arguments that > nobody but the "systemd MUST DIE" crowd really wants to hear anymore. > > > You might have seen this http://ewontfix.com/14 > > but have you seen this http://ewontfix.com/15 > > or this http://boycottsystemd.org/ > > "Open source Tea Party". That explains *so* much... > > > Having a systemd-free option for Debian Jessie is becoming more and more > > important. Otherwise (Debian) users might do as recommended in the third > > link: Boycott distros that use systemd. > > "If we keep systemd, people who want to boycott systemd will boycott > us." Seriously, can we stop with the circular arguments as well? > > -- > Rens Houben |opinions are mine > Resident linux guru and sysadmin | if my employers have one > Systemec Internet Services. |they'll tell you themselves > PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc > > > -- > 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/20140903093421.ga25...@proteus.systemec.nl > >
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
Hi! Yes, please... I vote +1 for *not silently replace* sysvinit by systemd, when upgrading from Debian 7, to 8. 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. I'm seeing that, when with systemd, people are complaining that it does not always work, so, it seems that, when with systemd, Debian will stop working on a system that it always worked previously. Then, if people don't have a option to select the `sysvinit-core` during the installation, this will be a huge step back... They'll be forced to install Debian 7, then upgrade to Debian 8, on those machines that systemd seems to not work. Also, the current Populatiry Contest is unfair, because it shows systemd winning, when it is being pushed. I like the idea of a new init for this century BUT, since systemd developers lack of social skills (read: "Linus already kicked those guys from kernel dev"), it is wise to wait, at least, until ~2019, to replace sysvinit / upstart, by systemd. I'll stick with Debian 8 + sysvinit (or Ubuntu 14.04 with upstart), until ~2019. I'm not against change, I'm already using IPv6 and NFTables on a daily basis... ;-) BTW, if the `sysvinit-core` maintainers will maintain it for, lets say, until kFreeBSD dies, so, why not let people choose between the two? Then, we'll have time to see if this "systemd thing" will become a standard, or not. It is safe to keep two options, until systemd guys proves to the open source community, that they deserve more respect. Also, providing two init systems during Debian 8 cycle (or until kFreeBSD remains around), *will calm down people all over the world*. People already don't like change (not me), and a pushed change is even worse, it will make them very unhappy / disappointed / betrayed. Cheers! Thiago On 10 September 2014 18:36, Nick Phillips wrote: > On Wed, 2014-09-10 at 18:37 +0100, Ben Hutchings wrote: > > On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote: > > > 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. > > > > Then they already accepted the risk of extended downtime during an > > upgrade. > > That doesn't, however, mean that it is acceptable for us to recklessly > cause such downtime. > > It seems to me that there is clearly a large group of users for whom an > automagic change in init system is desirable, and won't even be noticed. > > There is however also a large group of sysadmins for whom a > noninteractive change of init system is a major, annoying issue. If our > priority really is our users, then we can't brush this under the carpet > with "you should have read the release notes" - and certainly not when > the problem has been foreseen. That is simply not how you respond to > someone you actually care about. > > Debian has a good and hard-earned reputation for not messing up > sysadmins' changes; upgrading to systemd - however wonderful it is (and > I confess to having no opinion on that) - without at least a debconf > prompt of a reasonable priority telling them what is about to happen and > offering a bailout, is guaranteed to lose us reputation and users. > > It doesn't matter whether we think that's reasonable or not, it is what > will happen. > > So, is it actually feasible to provide such a prompt? > > > Cheers, > > > Nick > -- > Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 > # These statements are mine, not those of the University of Otago >
Enlightenment DR19 - Maintainers?!
Hey guys! I'm wondering here... Where are the E19 packages for Debian?! :-P I'm so tired of Gnome, Unity, KDE, XFCE, LXDE, Network Manager... hh!! :-) So, why not make a *near to perfect* E19 packages for Debian (or Ubuntu)? Using Econnman by default, Terminology and etc... ??? Right now, I'm using E19 compiled by hand, using my script (forked): https://gist.github.com/tmartinx/86adc8f33b12f163028b#file-nineteen-2-sh Also, I tried this PPA: https://launchpad.net/~niko2040/+archive/ubuntu/e19?field.series_filter=trusty but, it is too different from "original" Debian packages... Lets make a Debian spin based on E19?! Can't wait to try E-Wayland-Only!=D Cheers! Thiago
Re: Enlightenment DR19 - Maintainers?!
Hey Paul, Thanks for your fast reply! On 8 October 2014 00:30, Paul Tagliamonte wrote: > On Wed, Oct 08, 2014 at 12:26:07AM -0300, Martinx - ジェームズ wrote: > >Hey guys! > > And gals! > Sure! :-D > >I'm wondering here... Where are the E19 packages for Debian?! :-P > > You tell us! > > I assume you're related to the recent reddit thread? If so, hi! Welcome! > If not, also hi! Welcome! > haha! Thanks!!! You're very kind...^_^ No, I don't know about this thread on reddit, have you a link to it?! I would like to participate. > I'd suggest contacting the maintainers of e17 and seeing if they want to > work with you. There's also an Alioth group, I think! > Cool! I'll try to reach them... > > >Can't wait to try E-Wayland-Only!=D > > Sounds awesome! > For sure! Xorg consumes too much CPU of my multi-monitor (4) Ubuntu (or Debian too) Desktop... I hate it... hehe =P > >Cheers! > >Thiago > > > > References > > > >Visible links > >1. > https://gist.github.com/tmartinx/86adc8f33b12f163028b#file-nineteen-2-sh > >2. > https://launchpad.net/~niko2040/+archive/ubuntu/e19?field.series_filter=trusty > > Cheers, > Paul > > -- > .''`. Paul Tagliamonte | Proud Debian Developer > : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 > `. `'` http://people.debian.org/~paultag > `- http://people.debian.org/~paultag/conduct-statement.txt > Best! Thiago
Remember when men were men and wrote their own init scripts? =)
Guys, I really do NOT want to start a flame war, I know that you guys are tired about this "init" subject appearing over and over... But, my turn...:-P *First things first: Why I'm with Debian / Ubuntu?* A.: Because *I like the work of Debian Maintainers* (you guys and gals, sirs and madams), about how Debian *compiles and packages* *every single piece of open source software out there* (i.e., its `configure ; make ; make install` from `debian/rules`, I love it). I really don't care that much about what init system I have (I'm using upstart and sysvinit these days, never used systemd - it IS too unstable (I tried it without success, lots of bugs popped everywhere when with systemd), invasive and dangerous to our comunity project (a.k.a. Debian))... But please, guys, DO NOT LOSE "*DEBIAN COMPILATION*"!! I mean, when I read that infamous guy, Poettering, talking about things like this: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html It creeps the hell outta me! Specially this: "...This greatly simplifies application installation, as there's no dependency hell..." - Poettring. So, this guy uses a RPM-based distro, called RedHat/CentOS/Fedora, right?! I feel sorry for him... Poor guy... Only that crap-distro(s) have a "dependency hell", not our shiny Debian. I don't know what that guy is talking about, honestly (well, no, I know - rpm+yum sucks). =P Anyway, I see that there is room for improvements on software installing and updating (binary diffs, cow and etc?) but, wait, systemd instead of dpkg/apt?! I thought this thing was supposed to replace ONLY the init system, nothing more, neither udev (already engulfed)... So, is systemd even trying to replace dpkg+apt too? Come guys... For real?! *Please, do not let this to happen here! Do not lose "Debian Compilation", and packaging, do not lose "[dpkg / apt] / debian/rules", for systemd!* *Also, do not lose `dpkg-buildpackage` for "systemd-buildpackage"!!* This systemd thing *has already gone too far*. Keep systemd at its bare minimum level... Do not let it take over the whole distro. Honestly, I don't fear systemd itself, or binary logs... I fear things like this: Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd: http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA Linux systemd dev says open source is 'SICK', kernel community 'awful': http://www.theregister.co.uk/2014/10/06/poettering_says_linux_kernel_community_is_hostil/ So, lets move on over this systemd thing, *keep it at its bare minimum level...* I'm fine with a new init system, our current state of technology allows us to do that, something like systemd (I like its ideas, but don't like its "Mr. Knowitall" implementation, *it looks really ugly and bloated*), nevertheless, I'll try it later, maybe on 2016~2020, if it proves itself really stable (i.e., a nonissue in the near future) AND upstream developers change their attitude / behavior on bug handling, etc... Please guys, don't take me wrong (no flame wars okay?!)... I'm just concerned about the preservation of our amazing Linux/kFreeBSD distro! Keeping `sysvinit-core` in Debian 8 (9, 10...) *at a reliable level* *is a wise thing to do*. Just in case... (I don't trust RedHat neither the Corporatocracy). So! Let the men write their own init scripts powered by `sysvinit-core` for a long time ahead! Don't throw this away! Also, keep kfreebsd flavor for how long as possible (*without systemd things*, of course)! On Linux, it is fine to have systemd installed and around (like systemd-udev, logind0 and etc) but, sysvinit is important (even upstart is), do not lose it... BTW, *during Debian 8 installation, please, provide a (d-i, tasksel, alternatives, whatever) interface for selecting the initsystem*, *this is important!* I know that it seems pretty easy to just run "apt-get install sysvinit-core" (or preseed it) (to get rid of systemd as init) after the installation but, if that [initsystem selection] option appear (during the installation), *this will make Debian even stronger*, as the only distro that provides, at least, two (sysvinit|systemd) reliable init systems. *How cool is that?!* Also, without an interface for selecting an init system on Jessie, *the popularity contest becomes unfair*. Honestly, I would like to wake up from this systemd nightmare. I'm seeing that there is demand for a brand new Linux distribution, that will sit right in the middle of Debian and Slackware... Something like a Debian fork without DBus, systemd and PAM, but still with dpkg/apt "d-i" and lots of packages. Lets do it?! Lets fork Debian and remove systemd, dbus and pam out from it?! The fork `uselessd` (or a new udev) becomes more and more a necessity. Just for the record, today is the first day that I tested systemd, then, systemd-journal consumed 100% of my CPU (plus rsyslog), something related to GPM and, "ecryptfs" does not umount my home dir anymore, after logout... Is it a system
Re: Remember when men were men and wrote their own init scripts? =)
Sorry man... English isn't my native language, is hard for me to express myself in another language... But yes, those sources aren't the best but, there are more, you know. :-P Best! Thiago On 20 October 2014 15:55, Axel Wagner wrote: > Hi, > > Martinx - ジェームズ writes: > > I really do NOT want to start a flame war > > This statement is evidently false or misguided. > > I'd love to leave it at that (see?), but: > > > Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd: > > http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA > > > > Linux systemd dev says open source is 'SICK', kernel community 'awful': > > > http://www.theregister.co.uk/2014/10/06/poettering_says_linux_kernel_community_is_hostil/ > > Seriously? You are quoting phoronix and theregister as sources? > > Best, > > Axel Wagner >
Re: Remember when men were men and wrote their own init scripts? =)
But I need to act (at least, say something) to preserve our distro and I cannot remain in silence. Sorry... This isn't intended to be fun. Cheers! Thiago On 20 October 2014 16:57, Ondřej Surý wrote: > On Mon, Oct 20, 2014, at 19:34, Martinx - ジェームズ wrote: > > I really do NOT want to start a flame war, I know that you guys are > tired about this "init" subject appearing over and over... > > No, you wanted to add more oil on existing flamewars and you know it. If > you don't want to start the flamewars, you should refrain sending such > emails, please. > > > But, my turn...:-P > > No, please don't. It's neither useful, productive nor funny. > > Cheers, > Ondrej >
Re: Remember when men were men and wrote their own init scripts? =)
Okay, I agree with you. I just find two bugs when with systemd, I'll fill the bug reports. Those problems I'm seeing are reproducible. Please, forgive me, I don't want to make things worse, I just want to *express my concerns* about this "systemd-situation"... I'm with Debian because *it is unique*, stable *and it still have sysvinit*, if it loses its singularity, then, Debian will be killed / forgotten, or forked. Best! Thiago On 20 October 2014 17:16, Ondřej Surý wrote: > If you have the unresistible urge to act, then go fix a bug. Or help > with triaging the bugs - finding reproducible test case also helps. Turn > that urge into something productive. Flaming in the mailing list isn't > helpful, it's exactly the oposite. > > Cheers, > Ondrej > > On Mon, Oct 20, 2014, at 21:00, Martinx - ジェームズ wrote: > > But I need to act (at least, say something) to preserve our distro and I > cannot remain in silence. Sorry... This isn't intended to be fun. > > Cheers! > Thiago > > On 20 October 2014 16:57, Ondřej Surý wrote: > > > On Mon, Oct 20, 2014, at 19:34, Martinx - ジェームズ wrote: > > I really do NOT want to start a flame war, I know that you guys are > tired about this "init" subject appearing over and over... > > > No, you wanted to add more oil on existing flamewars and you know it. If > you don't want to start the flamewars, you should refrain sending such > emails, please. > > > But, my turn...:-P > > No, please don't. It's neither useful, productive nor funny. > > Cheers, > Ondrej > > > > > -- > Ondřej Surý > Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server > > >
Re: Remember when men were men and wrote their own init scripts? =)
Hey Paul, I really appreciate your feedback. Glad to see that at least, systemd in Debian have some boundaries. Whew! Tks! I'll try to disable html messages for all Debian Lists at my GMail account right now, sorry about that. Nevertheless, I'm not flaming (not my intention, really), I care about Debian. ;-) Cheers! Thiago ** We don't need "kdbus @ PID 1". It did not got merged into Linux 3.15... Think about it.* ** uselessd might replace systemd, since it have all that CGroups cool stuff, without systemd's useless bits. We just need a new udev! :-P* On 21 October 2014 02:21, Paul Wise wrote: > Please do not use HTML mail on Debian lists. > > Please do not flame on Debian lists. > > https://www.debian.org/MailingLists/#codeofconduct > https://www.debian.org/code_of_conduct > > On Tue, Oct 21, 2014 at 1:34 AM, Martinx - ジェームズ wrote: > > > tried it without success, lots of bugs popped everywhere when with > systemd), > > Please file bugs about issues you find in Debian packages: > > https://www.debian.org/Bugs/Reporting > > > > http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html > ... > > So, is systemd even trying to replace dpkg+apt too? > > No. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Re: Where to upload official OpenStack Debian images?
On 22 October 2014 11:58, Juerg Haefliger wrote: > Hi, > > On Sat, Jul 19, 2014 at 10:12 AM, Thomas Goirand wrote: >> >> On 07/18/2014 07:49 PM, Steve McIntyre wrote: >> >> [2] I contacted Steve McIntyre privately about it, but he didn't reply. >> > >> > Bugger, sorry. Must have missed the mail totally. :-( >> >> As I wrote on IRC, I thought you were busy with arm stuff, so I didn't >> dare to ask again. It's probably my fault for not insisting. >> >> > I think we could/should have space on cdimage etc. >> >> That'd be awesome! >> >> > - how big are we talking? >> >> 350 / 400 MB for the normal compressed qcow2 image. We could as well >> ship the raw image, but I don't think that's necessary since it's >> possible to convert the qcow2 back into .img using qemu-img. > > I'd love to be able to download Debian cloud images from an official place. > What is missing/required to make this happen? Can I help? > > Thanks > ...Juerg > > > >> Cheers, >> >> Thomas Goirand (zigo) Lets build something like this: https://cloud-images.ubuntu.com/locator/ec2/ but, for Debian, of course... ? I can help. Cheers! Thiago -- 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/CAJSM8J1=-+zwdvrikxgalxafcdixusyw9mxzqrfzm8fnuo_...@mail.gmail.com
Re: Where to upload official OpenStack Debian images?
> Lets build something like this: > https://cloud-images.ubuntu.com/locator/ec2/ but, for Debian, of > course... ? > I can help. > > Cheers! > Thiago BTW, I'm maintaining an OpenStack Guide, here: https://github.com/tmartinx/openstack-guides/tree/master/Juno Within my guide, currently, I register Ubuntu images like this: --- 3.3. Adding O.S. images into your Glance ... # one line: glance image-create --location http://uec-images.ubuntu.com/releases/14.04/release/ubuntu-14.04-server-cloudimg-i386-disk1.img --is-public true --disk-format qcow2 --container-format bare --name "Ubuntu 14.04.1 LTS - Trusty Tahr - 32-bit - Cloud Based Image" --- And I think that it would be awesome to achieve something like this for Debian (including Jessie images with both systemd and sysvinit-core), so, we might have (example): --- # one line: glance image-create --location http://uec-images.debian.org/releases/8/release/debian-8.0.0-systemd-amd64-disk1.img --is-public true --disk-format qcow2 --container-format bare --name "Debian 8 - Jessie - 64-bit - Cloud Based Image - systemd" # one line: glance image-create --location http://uec-images.debian.org/releases/8/release/debian-8.0.0-sysvinit-amd64-disk1.img --is-public true --disk-format qcow2 --container-format bare --name "Debian 8 - Jessie - 64-bit - Cloud Based Image - sysvinit" --- Best, Thiago -- 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/CAJSM8J1eX3-+=6_4sfFGfjrjByFBo0H9xPvc9gngNs_k0tV-=q...@mail.gmail.com
Jessie will need Linux 3.18!
Guys, I was facing a Linux BUG that was fixed only in 3.18. Here it is: https://bugs.launchpad.net/linux/+bug/1362755 So, with Linux 3.16, it will not be possible to use Jessie to create a "VLAN tagged Virtual Network" within a KVM hypervisor itself. It will not route VLAN tagged packets. I manually backported Linux 3.18 from Ubuntu Vivid, into Trusty: https://launchpad.net/~martinx/+archive/ubuntu/linux Then, the problem solved! I tested the Linux versions from 3.13, to 3.16, all have the same problem... Linux 3.18 is okay. I must say that I did not tested Jessie this days but, I know that Linux 3.16 doesn't work. Basically, Jessie can not be used in a production environment on a Corporate Network, for example... All my firewalls, VPN servers, proxies are KVM Virtual Machines. The VLAN tagged packets does not get routed, it started to work only when with Linux 3.18. Please, pay attention into this problem before Debian Jessie release! Best! Thiago
Re: Jessie will need Linux 3.18!
On 4 February 2015 at 19:08, Ben Hutchings wrote: > > [Redirecting to debian-kernel] Cool! Tks! > > > On Wed, 2015-02-04 at 17:36 -0200, Martinx - ジェームズ wrote: > > Guys, > > > > > > I was facing a Linux BUG that was fixed only in 3.18. > > Did you find out what change fixes this? No, I did not bisected the issue... Vlad Yasevich from Redhat (comment #2 at LP #1362755) told me that it is something related to TSO/GSO implementation in the kernel. > > Does this configuration work in wheezy (with Linux 3.2)? I did not tested it with Linux 3.2 but, I can try it next week. > > [...] > > Basically, Jessie can not be used in a production environment on a > > Corporate Network, for example... > [...] > > Please, don't exaggerate. Debian is already widely used with the Linux > 3.16. Apparently certain configurations don't work properly, but we can > probably fix that. Okay, sorry... I was just trying to raise up the drama to catch attention... hehe... To make it clear, Jessie KVM guest, acting as a router, can not be used on top of Jessie KVM host, when you have tagged VLANs... I guess that this topology might be pretty common out there... I worked on a lot of companies that are purely based on Debian / Ubuntu (both hypervisors and VMs). Drama off...:-) Jessie is great! > > Ben. Thiago -- 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/CAJSM8J37tuFbkFWHE4_58wS=_-HtMCre=9-mgadrhsoc_cu...@mail.gmail.com
Re: Jessie will need Linux 3.18!
On 5 February 2015 at 00:03, Thomas Goirand wrote: > > On 02/04/2015 08:36 PM, Martinx - ジェームズ wrote: > > Guys, > > > > I was facing a Linux BUG that was fixed only in 3.18. > > > > Here it is: > > > > https://bugs.launchpad.net/linux/+bug/1362755 > > > > So, with Linux 3.16, it will not be possible to use Jessie to create a > > "VLAN tagged Virtual Network" within a KVM hypervisor itself. > > > > It will not route VLAN tagged packets. > > > > I manually backported Linux 3.18 from Ubuntu Vivid, into Trusty: > > > > https://launchpad.net/~martinx/+archive/ubuntu/linux > > > > Then, the problem solved! > > > > I tested the Linux versions from 3.13, to 3.16, all have the same > > problem... Linux 3.18 is okay. > > > > I must say that I did not tested Jessie this days but, I know that > > Linux 3.16 doesn't work. > > > > Basically, Jessie can not be used in a production environment on a > > Corporate Network, for example... All my firewalls, VPN servers, proxies > > are KVM Virtual Machines. The VLAN tagged packets does not get routed, > > it started to work only when with Linux 3.18. > > > > Please, pay attention into this problem before Debian Jessie release! > > > > Best! > > Thiago > > Hi Thiago, > > The best way forward for this kind if issue is to: > 1/ Open a bug against the Debian linux kernel. > 2/ Provide a patch to fix the issue, attached to the bug. > > Bug keep this in mind when doing so: You need to test under *debian*, > and not just under Ubuntu. From the launchpad bug you've opened, it's > looking like you've had the issue in Ubuntu, and there's no way to tell > what will happen in Debian. Also, you issue seems related to kvm/qemu, > and not only to the kernel. > > Cheers, > > Thomas Goirand (zigo) > Okay Thomas, got it! I'll do the required tests under *debian* and fill a bug against Debian Linux Kernel. But, the Kernel code related to this part of it (network and etc), is very different in Linux 3.18, I'm guessing that it will *easier* to just provide Jessie with Linux 3.18, instead of a patch, but, I'm seeing that it might be too late for that... :-( Yes, I tested it with Ubuntu but, I also tested it using Linux from kernel.org, compiled by myself... Only Linux 3.18 solve that issue. Cheers! -- 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/cajsm8j1jkgcyuwpyjg8djf2cssjbjm5tfsrbw1jexzpvah_...@mail.gmail.com
Re: support for merged /usr in Debian
On 30 December 2015 at 22:51, Marco d'Itri wrote: > We have a reasonably tested usrmerge package which can be used to > convert on the fly a system to merged /usr, and the good news is that > there are only three packages which need to be fixed to work on a merged > /usr system. > > Thanks to my conversion program in usrmerge there is no need for a flag > day, archive rebuilds or similar complexity and we can even continue to > support unmerged systems. > > I welcome your comments, but if you have any questions then please read > the FAQ first: > https://wiki.debian.org/UsrMerge > https://anonscm.debian.org/cgit/users/md/usrmerge.git/plain/debian/README.Debian > > If you want to help then please have a look at the open bugs linked on > wiki.d.o about lintian and policy work. > > -- > ciao, > Marco The "solution" proposed here: https://wiki.debian.org/UsrMerge just stinks. Please, make sure this thing remains an option, never the default. Happy new year!
Re: support for merged /usr in Debian
On 3 January 2016 at 00:25, Daniel Reurich wrote: > On 03/01/16 07:00, Marco d'Itri wrote: >> On Jan 02, Geert Stappers wrote: >> >>> A design with "whole OS on /usr" breaks the good pratice of having >>> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable. >> This is not a good practice but just an historical accident: for details >> see http://lists.busybox.net/pipermail/busybox/2010-December/074114.html . >> grml-rescueboot is way more useful for rescue purposes. > > Perhaps you should read the rest of that thread.. >> >>> In other words: I don't yet see a _good_ reason for "TheUsrMerge". >> Many have been discussed. > > And none of them stand up to scrutiny imho. > > Just because Lennart Poettering and Kay Seivers say so is not a valid > reason. Neither does publishing an opinion piece on freedesktop.org FWIW. > > Because Solaris has done it is no reason to do so either > > Because systemd doesn't work without /usr on the root partition isn't a > good reason either. That just means systemd is broken by design and > needs to be fixed. > > Just because the separation occured way back in time, doesn't mean that > it isn't still useful or beneficial for some or indeed many use cases. > > What I'd like to know is what are the real use cases where a merged /usr > is absolutely required (- where it isn't the result of a lazy and > unprofessional attitude of dis-respecting the environment that exists > and ignorance of the hard learned lessons of long ago.)? > > > -- > Daniel Reurich > Centurion Computer Technology (2005) Ltd. > 021 797 722 > This "UseMerge" just brings more insanity into Debian. What is wrong with you guys?! For God's sake... --- It violates the FHS 2.3 standards. http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html --- Also, if you guys (Debian) reeeally wants to move everything to /usr, so, there is no reason for any symbolic links at the root file system. I am 100% against this insanity. Again, If Debian wants to do that, then, do NOT create any symlink on the root file system. Do not bring CentOS shit to our shiny distribution. Those symlinks: "/bin -> /usr/bin" "/sbin -> /usr/sbin" "/lib -> /usr/lib" "/lib64 -> /usr/lib64" Looks very, very unprofessional. It looks like a huge workaround, created to deal with something that you broke for no reason. One more time, if things are going to be moved to /usr, then, there is no reason for ugly symlinks at the root file system. I vote against "UsrMerge". But, if Debian wants it, do it right, without symlinks (i.e., workarounds). Otherwise, do not touch this and go away. Best, Thiago
Re: support for merged /usr in Debian
On 3 January 2016 at 03:52, ChangZhuo Chen (陳昌倬) wrote: > On Sun, Jan 03, 2016 at 01:23:14AM -0200, Martinx - ジェームズ wrote: >> It violates the FHS 2.3 standards. >> >> http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html > > Can you cite the requirement in FHS 2.3 which is violated by usrmerge. I > only found the requirements that allow us to do usrmerge via symbolic > link. For example: > > http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#Requirements > > The following directories, or symbolic links to directories, are > required in /. > >> Also, if you guys (Debian) reeeally wants to move everything to >> /usr, so, there is no reason for any symbolic links at the root file >> system. > > Symbolic links at the root file system is required by FHS 2.3. Removing > them will violate it. > > -- > ChangZhuo Chen (陳昌倬) > Debian Developer (https://nm.debian.org/public/person/czchen) > Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D Thank you for your time and explanation! I really appreciate it... I just don't get why you guys are pushing this unneeded change. Debian doesn't need this. Systemd doesn't need this either! So, why? Why!? I'm not convinced, even after reading this: https://wiki.freedesktop.org/www/Software/systemd/separate-usr-is-broken/ I don't see any reason to move /bin/bash, to /usr/bin/bash! LOL Some udev rules will silently fail to work if "/usr" is split off and not pre-mounted? So what? This is NO reason to UsrMerge. Just keep "/usr" on the same block device of "/", period. No ugly symlinks on root file system, no Bash at /usr/bin/bash! The problem is that "/usr" is not supported anymore, on a separated partition! Okay, okay... But, moving /bin/* to /usr/bin/* is NOT a solution to this problem, it is a wrong approach. Just tell the users that "/usr" isn't supported on a separated partition anymore (tell users what will happen if they do this / limitations), and do not touch anything else. During install, while partitioning storage, print a message about this, if user tries to separate "/usr". Please, do not bring this UsrMerge thing to Debian. Regards, Thiago
Re: Debian package on Windows
On 30 March 2016 at 14:52, Paul Wise wrote: > On Mon, Feb 22, 2016 at 10:05 PM, Jonathan Dowland wrote: > > > I think your message would be better addressed to the debian-devel > mailing > > list, who I have copied in to this reply so that more Debian Developers > are > > aware of it. (There's also the Apt developer's mailing list at the > > harder-to-discover de...@lists.debian.org who I have not copied in, as > they are > > likely all on -devel anyway) > > > > Personally (although I am not an Apt developer) I think it sounds like an > > interesting idea, and there is some precedent as APT was the basis of the > > "Fink" package management system for Apple Mac OS X. Not re-inventing > the > > wheel is a very good idea, lots of package management problems have been > > discovered and solved with APT already (and it's sad to see things like > Ruby > > gems, Go packages etc. re-discover the very same problems over and over > again) > > Looks like Microsoft went with a Linux syscall emulation layer for the > Windows kernel: > > http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > > Something like this: http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/ Sounds super cool! Finally the "year of Linux on Desktop"! lol I would like to play with this, for sure... :-D
Please, provide a fixed Cloud Image URL for Debian
Guys, When we talk about Cloud Images for OpenStack, both Ubuntu and CentOS provides fixed URLs that never changes. This way, we can easily automate Glance to download images by demand, we can have new images, without adding new images into glance! Exemplifying: CentOS 6/7 fixed image URL: http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2c Ubuntu 16.04 fixed image URL: http://uec-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-amd64-disk1.img Then, on Glance, here is how I'm adding those images: - glance image-create --location http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2c --name "CentOS 7 - 64-bit - Cloud Based Image" --is-public true --container-format bare --disk-format qcow2 - glance image-create --location http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c --name "CentOS 6 - 64-bit - Cloud Based Image" --is-public true --container-format bare --disk-format qcow2 - glance image-create --location http://uec-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-amd64-disk1.img --name "Ubuntu 16.04 LTS - Xenial Xerus - 64-bit - Cloud Based Image" --is-public true --container-format bare --disk-format qcow2 I'm using my own Ansible automation to do this: https://github.com/sandvine-eng/svauto/blob/dev/ansible/roles/os_glance_images/tasks/main.yml The problem with Debian is that there is no fixed URL! Debian images disappears from time to time, which breaks my automation and that "Glance download by demand feature", like this: Debian 8.5 image URL: http://cdimage.debian.org/cdimage/openstack/8.5.0/debian-8.5.0-openstack-amd64.qcow2 This image will be gone, soon as Debian launches 8.6.0!!! This is bad. So, can Debian provides something like this: http://cdimage.debian.org/cdimage/openstack/8/debian-8-openstack-amd64.qcow2 that always points to the latest stable release image of 8 series (Jessie)? For example, this: http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2c pointed to CentOS 6.7, but now, it is 6.8! Glance will download the new image, without any human action. Hope that Debian provides something similar! Cheers! Thiago
Re: Please, provide a fixed Cloud Image URL for Debian
On 11 August 2016 at 01:45, Paul Wise wrote: > On Thu, Aug 11, 2016 at 5:58 AM, Martinx - ジェームズ wrote: > > > When we talk about Cloud Images for OpenStack, both Ubuntu and CentOS > > provides fixed URLs that never changes. > > BTW, there is a debian-cloud mailing list for Cloud discussions. Oh, I wasn't aware of it... I'll re-post this message there instead... Sorry about the buzz!:-)
